Update.....

Well I'd like to say I'd been fighting the good fight, fixing lots of little things and taking care of business.

Alas - this is not the case. Work, family, other obligations cut down my 'computer time' to so little that it hasn't been worthwhile to switch on and sit down most days.

This is one of the busiest times of the year for me, so everything needs to take a back seat. Summer is on it's way and bringing the blistering heat that has destroyed more than one of my PC's over the years, and so Amiga programming will have to be done in the relative cool of the evening.

Some things have been worked on, several things have been tweaked slightly - all the blitter collision routines have been written - and implimented for the bullet vs rock collisions. Some graphics have been worked on in my spare time, and various linked list routines have been updated since my re-reading of Amiga System Programmers guide. There is a limit to what I can rewrite though - so some concepts will have to be implimented at the ground level next game.

EVA is still very much alive, although this months progress has been less than stellar.

Month 2

It's officially 2 months into the project. 2 of 12 - 10 to go.

Over the weekend I sorted out the double buffering routines, and updated everything to run with it - there are a few tweaks here and there to get everything running and drawing the way it all should, but I'll get those sorted out over the next week.

I've not put an updated demo on Underground Arcade for a while, if I did it would look pretty much exactly the same - and I'd find myself throwing more rushed code in to make it 'look different' - something I don't want to do anymore.

The jump code was started, but needs some fine tuning, and buggy controls in general need to be fine tuned. The devil is always in the details. I do think it looks strange with it's wheels spinning in mid-air, which lead me to changing the animation while it jumps.

Currently the animation system works pretty well, even the 'cludge' I've thrown in for the rocks changing size when hit - adding multiple animations for each object is something I should have added in earlier, but sort of rushed past in order to get something to show. This week will be spent going over the animation system yet again to make it more flexible, and hopefully faster.

So again, lots of coding going on and if all goes well by the end of the week I should have most of these things knocked out - and of course the end result, if all goes well, will look EXACTLY as it does this week!

Seeing something on the screen working is always motivating - but having to go back and wade through rubbish code and re-write everything is totally UNmotivating. It's not like hundreds of people are looking at the in-progress demo anyway. Maybe 3 total. I'm more than happy to fly under the radar and get things done the way I want them.

In the end I have to just do this for myself - and noone else.

Double dat buffer!

I'm excused for being a little remiss in my dev diary. Things are getting done, life marches forward.
I've been spending a lot of my time at work lately backing up files / projects / file footage because my entire edit system was being replaced. For anyone interested I've gone from using an Avid Adrenaline to an Avid Nitris Symphony. The big difference between the systems is a much expanded capacity for the ability to do High Definition video editing, and I'm enjoying the 9Terabyte storage :)

For those not interested (well you read through that already so too bad!) - suffice to say I've been VERY busy both at work and studying out of work for the transition.

In the big, mind numbing, whirlwind of the last two weeks I'd forgotten something I was going to add to EVA but had slipped my mind:

Double buffering the display screen (it's dual playfield display - so the front only needs it). I found this out while writing the jump code algorithm. As the buggy hit it's apex the top would be cut off.

I tweaked around and found the problem was pretty localized - my map code was still in testing so you had 4 rocks, the buggy, 2 bullets, rock explosions - all having backgrounds buffered, being drawn, being cleared - the bullets were doing a no-destination blit when they passed into the bounding box of the rocks.... and in this stress test when the buggy was being drawn high on the screen (the LAST thing to be drawn) it was being drawn above a point that the scanline (drawing the screen) had passed. Because after each game loop it waits for the vertical blank - then ERASES the old graphics before redrawing, the top of the buggy would never be redrawn.

So, double buffering - I keep 2 foreground screens in memory, draw to a back screen - wait for the vertical blank, swap back screen to the front.... erase the old graphics and draw again.

It's a memory overhead, but a necessary one - and at 320 x 200 pixels and 3 planes only, not a HUGE one.

The upside is knowing exactly how my code is running.... I'm doing an 8 level paralax scroll, blitting with mask and background merge over 10 blitter objects, doing both math AND blitter based collision detection on several objects - as well as any updating overhead for this... in the time it takes the beam to travel down 30 lines of the screen......50 times a second.

All in all - I'm rather pleased with the code... it could be optimized, of this there isn't any doubt, but at this point I've done around 70 percent of the 'hard grunty coding' - and only using around a fifth of the time afforded me to still run at full frame rate. So for now I'll go with robust easy to read code over optimization until I have to.

This week I'm putting ALL projects on hold until I rewrite all drawing routines to use double buffering (now I'm REALLY happy about changing all those drawing routines last week!)

Cheers

Sig.

Bugs bug me

No sooner had I thought I'd put the rock code 'to bed' for now, I noticed something slightly out of place.

I was running a quick test of the map code (to start on craters) and noticed a graphics glitch - I'd forgot to replace the error check at the end and it was seeing the new map-code as another rock.

Also, there were only 3 rocks on screen at once... not 4 as there should be. I'd realized with some playing that it would be WAY too difficult to shoot down 4 anyways - so hadn't given it much thought past that... nope something was amiss.

Part of me by this stage is saying 'well - it works with 3... that's good enough.. just don't put 4 in the map close together! - problem solved!'.. But I knew that 1) this would sit in the back of my head and annoy me - and 2) EVA isn't so much about 'getting a game done' - it's about solving a specific set of problems with robust and modular code I can use in future project.

If I was trying to just get it working and that was that I would just set them up 'manually' and blit them - done.... instead I've borrowed concepts I've learned in my time away from the Amiga and assembly programming in C and other languages.

Each graphic in EVA has it's info placed in a memory structure (just like a C struct - see below about RS directive and addressing modes) - every graphic, be it a block, a bullet, the buggy - all contains info about how it's to be drawn, it's size, etc. Each structure has the ability to be expanded with specific info to further define it if needed - while retaining all the original info shared by all graphic objects (an oversimplified version of inheritance you find in C++ and other languages).

Further - all are grouped into linked lists. Each graphic element contains a pointer to the next element in it's series. Somewhere this wasn't working as it should.

It brings up the question that I was asked a lot back when all my friends were making demos, 'why? why not just blit it and be done?'

Well, it makes several things possible - automation being one of them, I can feed the address of say, the top level bullet into my draw routine and have it animate and draw ALL them - by simply passing ONE address.

Clarity in code - each routine does one thing, and does it well (or as good as I can make it), and each routine is named for what it does - concepts I learned from UNIX. As you work up from the machine level basics, the code becomes easier to read - 'fetch_next' 'draw_object' 'update_rocks' - each of these routines contains others that break it further, until you hit the bottom line at the machine level - where it's 90% moving to registers and other things. Things learned from programming MOO's and other online games.

Scalability. As it stood a week ago in the 'get it working' stage - to add just a single rock element required changes to 7 different bits of code..... setup, initializing, drawing, clearing, updating,collision detection, and of course allocating memory. Now it only needs one - setup.
Setup creates X amount of objects of that type and links them - every other routine automatically runs down the list - updating what needs updating, drawing what needs drawing, doing collision checks where needed.

And of course - portability. All the graphics routines could be lifted in a single file and used in the next game, and all I'd need do is draw new graphics and fill in the setup data. All basic animation, drawing, moving, etc.

Eventually I found my bug - and fixed it - a mistake in when I was checking for the end of the list... I guess another bonus in taking the long road was that the error itself told me where to look, and although it took me some time to work out what I'd done wrong - it was all fixed by changing just 3 lines of code.

Guess there's some benefit to taking the road less travelled. One of them being that I shouldn't have to travel down it again for some time.

Rockin'

Finally caught up the code I lost, and managed to get some time in between work and home to get to the next milestone. A simple level map puts different sized rocks on the screen which change size as they're blasted with the missiles.

The scoreboard still doesn't update - mainly because it's still not 'set in stone' - and I'm not 100% happy with the look or layout.

It's starting to look more like a game, with very basic playability.


Time can be spent now tweaking the buggy movement - rate of increase on the scrolling background, and acceleration of the buggy.

I've never liked the jerky stop-start that a lot of games had on their main sprite. I'll be working on some code that does a subtle speed up and slow down.

Jumping can now be added, and later craters. Collision detection for the main buggy still needs adding, and missile to rock collision is still only a math check on the bounding box.. when the buggy can jump, another level of detection using a mask will have to be added.

Disaster Strikes

Not a HUGE disaster - but a big setback nonetheless.

2 days ago the hard drive on the 2000 gave up the ghost. Luckily I backup the entire thing every weekend - so I only lost a couple of days of work.

I'd just managed to get another Harddrive and was hoping to run them both, so now I've been spending the last couple of days installing it, getting it running, and slowly getting things installed and back up to speed.

Coding should continue tonight, or tomorrow - although real life commitments will make getting much more than replacing work already done hard over the next week.

Sig.

Taking the backseat.

Just as you think you're hitting a routine, life throws you a curve ball it seems.

No sooner had I been basking in the glory of a month of steady coding and re-learning, I hit a speed bump.  My work - real work - the one that pays the rent - has been rather lazy lately - affording me a good amount of time for reading up on things, thinking things over, etc.  Not that I'm sitting doing nothing - just not flat out busy.

Things are a-changing for the next few months with several projects landing on my desk with quick turnaround times.  By the time I get home I'll be pretty much mentally spent, and needed to have my head in the right place by the next morning.  This is the problem with jobs that rely on a fair amount of creativity... you have to bring it every day - and if it's not in you that day, you have to force it out.  This doesn't leave a LOT left over for thinking about code by the end of the day.

EVA will have to take a backseat for a week or so while I sort this out.  This doesn't mean I won't be working on it at all - only not with the regularity I have been.... still there's a LOT of little tweaks I can work on in the meantime - and leave the major code till later.

Still no screenshots (I'll save that till the end of the week when hopefully more visible progress is made) - but last night I got some of the bugs out of my first-pass collision detection for bullets and put up a 'test rock' to shoot at.

It's not perfect - but it's working.  Progress is made.  Life goes on.

Monthaversary!

Well, it's been a month since I started... when I put it in that perspective I've done quite a bit. From rebuilding the computer, finding docs and programs, to having a decent system friendly setup, scrolling background, a fair bit of graphics work done, as well as the main sprite moving, animated, and firing.

There's still a lot to go, but it's starting to come together into something that may become a half-decent game.

I managed to get a full printout of the devpac manual and have been pouring over it the last few days - reremembering bits and peices like setting up proper macros. Rebuilt a few of mine, as well as getting the whole startup code to work with the include files a bit better.

I also came across a nifty directive: rs. and rsreset.

Basically rather than declaring a block of space, it just gives you an offset, which may sound a little useless (why get that when you can just declare the space and be done with it?) - but is REALLY useful. Since leaving the Amiga I've gone on to learn other things, and other styles - such as C, whose data structures are REALLY useful. RS gives you a way to do that in Amiga assembly.

If each lable past RSRESET gives an offset, you can use it to address indirectly, and if you have an RS with a value of 0, you can calculate the size of the whole - which means I can write just ONE structure for bullets, declare the space for each, then with a single routine, manipulate all of them by just changing the base address.

It's one of those things where you'll either read it and say 'Oh yeah!' or you'll say 'huh?'.... and no amount of explaining will change it..

Anyways - the upshot is that I've been rewriting all my buggy, bullet, and movement routines to use this - it's actually brought the code size down considerably - and each time I find myself re-writing the same code I look to my object structures and say 'what can I add to make this more modular?'

Lots to do over the next month - the main focus will now be on objects like craters and rocks, bullet collision and minor tweaks to movement, firing, and special effects...

Cheers.

Another step forward..

No fancy screenshots today - it's nearly 7am and I have to start getting ready for work in another half hour or so... enough time to type some rubbish, listen to a few more mod files and have another coffee.

Progress is coming a little more quickly now - not sure if it's me getting back into the swing, or that enough of the 'machine level' routine are enough in place. Either way, converting the buggy from a straight 'copy blit' to a 'cookie cutter' blit that leaves background intact - setting up the initial horizontal rocket and getting it firing, moving, and resetting was all done between the hours of 3am and 6am this morning.

A strange time, but it's working for me. I've hooked up with a group of folks that want to write new games for the Ami at Underground Arcade. I'm hoping maybe I can get some help when the time comes. I'll keep and eye there and post game updates etc, hopefully they'll be a motivating factor (or me on them) - Even 'back in the day' it was rare to see anyone muster the dedication for the long haul (myself included... grand plans that never reached fruition). But it doesn't hurt to try - the worst that happens is I continue alone.
Anyways, the topic of 'not enough time' came up in reference to coding - as I said 'you have to MAKE time for it', as I get older time becomes less available. Getting up at 3-4am is working at the moment, gives me time to wake up before work too.

Anyways - time to re-fill the coffee and think about the day ahead.

cheers!

Motivation

Somedays willpower simply isn't enough.....

It's not that easy being a one-man dev team on 20 year old hardware.  Although if you can write a basic scrolly demo - you have 90% of the technical skills to write a game.. The killer is the scale.
That's what sucks about taking the step into a dark tunnel - knowing you have many more steps before you see the light.

If noone goes first, noone will follow... Doesn't even mean my game has to be good - if it sucks I can say 'well -- at least I finished it....' and maybe someone will get pissy enough to do something better.  While they wait for someone else to go first... the platform is slowly dying.  Which is a shame.

So you work in vaccuum pretty much - you don't want to tell the community your working on something - because you won't please EVERYONE no matter what you do, and if you just give up like everyone else, you become on of those false promises..... no..... much better to work in silence until something is done.

Lucky for me - others do the same thing in their own way.  During my vacation there were a few days of wondering if I'm just wasting my time.  The answer eventually presented itself more eloquently than I could put it:



Thanks Eric.

Buggy Blitting

Ahhhh back at work again - after a nice 'stay-cation' of a week, the first in 2 years - I'm nearly glad to be back.  Backwards as it sounds, development time should INCREASE now that I'm back at work.

Spending an hour or two after the stresses of work to 'wind down' is quite acceptable... spending 12 - 18 hours locked in 'the manfort' isn't.... besides, timing my vacation to coincide with my birthday (42) and my wedding anniversary (11) sort of took care of a lot of the 'spare time' I'd have on my hands.

So - buggy blitting.. most my coding time was spent re-aquainting myself with the blitter.  It's little quirks (being one of the first of it's kind - it's allowed to have some) like it only blitting to short word (2 byte) boundries, and the barrel shifting needed to make pixel adjustments are in the very top 4 bits of it's control register....  while the math to pull round the address and pull the pixel offset is in th every BOTTOM 4 bits of an 'x-coordinate'... that all screen offsets and modulos are given in BYTES and all blitter start locations are on WORD boundries...  lots of little problems to scratch your head over - none of them huge - but each one time consuming.

Anyways - we now have buggy motion forward and back - linear at the moment - and the background scrolls accordingly... speeding up and slowing down as needed.

Starting to look more like a game now!

Parallax finished - well....kinda

Most of last week was spent busy at work - trying to get enough ahead so I don't bust a braincell when I go back in a weeks time... So, after the list of 'honey-do's' and other household things are taken care of - I'll be able to make some solid progress on EVA.

Nearly all the programming time I've slipped in has been with bug hunting. The change over to ECS showed a couple of sloppy mistakes that took some time to find - I'm keeping my eyes open and constantly revising the code.

Progress was made though - tonight I finished the parallax scroll routines and incorporated a version of a scoreboard. There's a lot of copper stuff going on - more copperlist than program.

Enough progress has been made to give it a 'checkmark' in the notebook - but more tweaks can be done:

Varying the color palette on each 'strip' - and separate each strip into its own graphic (currently they are all in one 'picture')

By making various frames for each strip - it's possible to animate the background graphics with little processor overhead - just change some bitplane pointers and I could have the lava bubbling as it scrolls by.

I'll wait on these until I feel like having another 3 day 'graphics binge' - for now I need a break from scrolling backgrounds and DPaint - and I have just the challenge:

Foreground main ship object and animation system.. the next 'check-mark' entry...

Minor Setbacks - Visible progress....

Well the upgrade to ECS threw some spanners into the code I'd been working on - A day of debugging and thinking brought it all back into line again..

Piru's setup - as I expected - worked flawlessly, and I narrowed the problem down to a few differences that I'm glad surfaced... first was the way I was setting the DMA, fine under OCS, but didn't take into account other bits that would be used later - this was a major one as it caused it to crash. The other minor issue was my checking for the vertical blank period - once I narrowed both down to test/change exactly what I needed, everything worked fine. I should have payed closer attention rather than 'do it till it works'.

The upside was that this gave me time to work on some graphics above and beyond 'test drawings' (which are usually a handfull of one color shapes to see if something works) - so once I got the everything up and running, I had some pretty pictures to work with.
Graphics aren't my strongest hand, but being a one-man-band at the moment gives me time to improve - on my side I have patience, as I'm usually doing the graphics while I either think or have the machine tied up doing something else.

Now I have to start the lengthy weekly back up of the Amiga to the PC, and work tomorrow. So over this coming week I'll run it through the emulator and get some screen shots of what little I have going so far.

I have some much needed vacation time coming up soon - so progress should accelerate through that time.

Caught Up and the Trials of Hardware!

So this brings us to the present - from March 10th till today.

We've gone from a black and white only Amiga with no development software and no working floppies to a halfway decent dev setup... but there's more to do.

As you read I'm running a classic OCS Amiga - with 1/2 meg chip ram, and thanks to a good deal on Ebay, 4megs of fast ram and an 030 accelerator.

Today the last of some hardware bits came in so I'm going to delve in and open the box again:

4 gig HD - alas it has a different SCSI connector on it! So this gets put to the side - 80megs is enough for now anyways.

Fatter Agnus Chip - able to handle 1meg of chip ram
Super Denise - handling screen modes and finishing out the ECS setup for the 2000
1 chinon floppy drive.

Hardware at this level makes me nervous - I'd already cut off the battery and resoldered a lithium watch battery and holder into this box, and I was sweating like a whore in church.
Discussing all this on Amiga.Org didn't make me feel better as I heard tales of brittle chip sockets - shorting out chips - breaking and bending pins off legs....

As it was - the operation went very smoothly - so what follows is what to do if you want to update a A2000 rev 4.5 motherboard to the ECS chipset:

1. In my case I went from 2 floppies that didn't work to one - so Jumper 301 (next to the floppy cable) is set to open (so DF1 will appear on external if I add one later) - the drive is jumpered to DS0 and connected to the 'twisted' end of the cable.

2. Ground yourself by touching the powersupply - put on a static wrist band.... now WITH A PLCC EXTRACTION TOOL (can't stress that enough - it only costs 4 bucks!) take out the old Agnus chip (labled FAT LADY on the board) - note it's orientation - one corner of the chip will be 'ground down' - take the new Agnus and carefully put it in the socket and gently press it down to seat it - make sure it's seated well.

3. Using the tool of your choice (mine is a jewellers flathead screwdriver with some anti static foam around it) lift the DENISE chip up - note the orientation (there's a little depression in one end that's easy to spot) - line up the new chip and seat it - be careful to avoid bent pins!

4. Locate Jumper 101 - it's near the power supply socket. Set it to the pins closest the power socket.

if you test as you go along - because like me you're paranoid - your ami will boot up until step 4. You won't notice anything new unless you look in Sysinfo - but when you do step 4 it will stop booting until you do the next (and final step)

5. (And this is the fun one!) Locate J500 near the CIA chips - it's a jumper trace (2 solder pads and a fine connection between them) - with a sharp exacto knife or other tool of choice, cut/scrape/break that connection between them.

Then reassemble and boot - voila - 1 meg chip ram!

Code Shell

The first thing to do is write a code-shell, or skeleton. A framework that handles all the tedious setup and exit that can be reused and expanded upon for all future projects.

There's several ways to do this - you can save all the relevant bits and peices such as DMA, interrupts, copperlists ect. then shut everything off and do as you please. Most demos did this - and a lot of demos don't run very well across the board on all Amigas.

Another way is to set yourself up as a proper process, do all the system relevant setup, then set yourself at a very high priority and run your code - and do system friendly cleanup. This is a lot more work - especially if you no longer have all the Rom Kernel Manuals.

The latter is my approach.

A lucky find, all the RKM's in a nice web friendly format : right here

After an afternoon of pouring over exec libraries, process structures, trial - error, and slow going I decided to take a break, have a coffee, and do some stress relief Googling. Back in the day a good friend, Colin Bell - aka Ziggy (to my Siggy) helped me make the leap from demo-style hardware banging to system friendly, nearly C like assembly programming. One of the most gifted Amiga Assembly programmers I've ever met.

A quick Google found his article in the Amiga Text Mag; HowToCode7
(His is the article on reading C)
And voila - what do we find? Some startup code!
It's quite nice and fairly complete - some of the assembly options balked a little my other code - but getting the whole package from Aminet also yields a nice CIA timed mod player.

It's nice - it has some features I need - but it is around 11 years old. Its fine for someone writing a straight forward demo, but will need some reorganising, reformatting, and other bits to fit into my project.

Part of coding is putting your ego aside and accepting that somewhere someone has done it better than you - sometimes better than you can ever do. When that happens you should take what you can and study it in hopes of bettering your own skills.

My search brought me around to a usual haunt, Amiga.org - I did a quick forum search and came up with Piru's Startup - this guy has rewritten exec, he knows his stuff, and this was just what I wanted - more thorough than the former code and needing very little change (only changing some library call formatting to use Devpac 3 system macros - because I find them orderly and neat).

With the system takeover sorted, I did some quick copperlist and bitplane setups - made a chunk of memory for the test screen, a mouse click test and a wait for the vertical blank... and all ready to go!

We can setup and leave the system nice and cleanly - and have enough tests that it should work on all classic Amigas.

Project #1 - EVA

The good thing about setting up this computer is that it gives me time to think - I've pretty much automated the task of importing ADF's from the PC and unpacking them to virutal floppies - and copying directories full of files are now just a drag 'n drop from my PC.  This gives me plenty of time to think about stuff, like where I've gone astray in the past.

Idea's are a dime a dozen for me - I literally have notebooks full of them.  Getting them to completion has been the problem.

Some ideas are too big, you get lost in the 'big picture' when you start planning it - or when you actually work on it there is never an end in sight.
Sometimes there's no 'end' to reach - I programmed a MUD for nearly 4 years, there was always just 'one more idea' to put in before I run it.
The project that's too ambitious - you get bogged down in too many problems to solve and eventually give up.

Starting from scratch there are a lot of problems to solve - a lot of things to set up - that will be used again in future projects.  So best to do them as well as I can the first time and work on something that will be interesting and challenging, but at the same time introduce the least amount of 'new problems' to the mix.

To this end I've decided to start with the last project I had on the Amiga 11 years ago - a variation on 'Moon Patrol' called EVA.  I no longer have any of my original code, or graphics, but I had already solved many of the problems before I sold up and moved to the US.

It's going to be a simple one directional scrolling game.
- Only one direction to worry about, but it will be parallax and variable speed.

-To simplify scrolling and collision detection I'll be using dual playfields - which on the OCS chipset I currently have will be 8 colors in the foreground and 8 in the background.

- I'll be making a very simple mapping system to plot rocks, craters, and aliens. A very simple path system for aliens to follow. And a simple 'set and forget' animation system for objects (since each object will follow a looped animation that won't change).

The main object of this game will be the basics - setting up a system friendly coding environment that's compatible with as many Amigas as possible - basic screen manipulation routines - basic blitter routines - and simple joystick input.

To this end I'll be giving myself a 1 year deadline to finish EVA.  It sounds doable.  So, time to start coding.

Starting Point

Ok, so these posts are pretty much 'catch up info' - and not on the days (nor times) they actually happened... But seeing as I don't expect folks to read this anyways, and this is totally a motivational exercise for me - it doesn't matter.

At this point we have most the software needed installed - HiSoft's Devac3, Deluxe Paint IV, Protracker, and a handfull of IFF/RAW converteres from Aminet - none of these does EVERYTHING that I want it too, but I lack the info to write one myself at this point - so they'll do for now.

Everything you need to start writing a game, albeit a basic one, right there.

So why go to all this trouble? I could just as easily do this in WinUAE - or UAE and Linux - Amithlon - or some other much easier way. Why don't I just set up AROS and do something for a developing operating system, or screw it - why not do something on the PC for Windows or Linux?
Like I said in the first post - it's not about the outcome, it's about the journey. The object isn't REALLY to write a game - the object is to reclaim a little of the fun I remember. That fun wasn't found writing for Linux, certainly not for Windows, it was found programming 68k Assembly on the Amiga.. that being said, WinUAE doesn't recapture the 'experience' for me totally either - Amithlon or UAE under Linux came close - but not entirely. The only way to 100% capture that is to go back to roots and go 'old school'.
Besides - if I'm going to make something for the Amiga, then shouldn't that be 100% compatible for it? What better way than to develop on the real machine?

So - with the machine in place and running, software at the ready, the next question is..... what to write?

The woes of software

No floppy drives, no CD rom, and a ton of software to upgrade before I can even get the project on the starting block....  I could wait for the new stuff to arrive, but knowing ebay and shipments from Canada that could be weeks.

 By this stage I'd received my Kickstart 3.1 rom and installed it.

No way to network - I have no network card in it, and to put one in would cost over a hundred bucks.

No terminal software - so not even xmodem or kermit can help me out.  
Amiga Explorer looked like a likely solution - an extension of Windows Explorer that lets you browse, drag - drop copy files to your Amiga over a null modem cable.  It can do quite a bit more too - but most importantly you can set it up on the Amiga side by using just a few DOS commands.

Well and good - but with wb1.3 I couldn't get it working beyond step-2 of the setup.  Could be something with the software - could be something with the setup left behind on this machine. Maybe something to do with the new rom and the old WB software.
I'll have no way of knowing.   Mind you it did give me enough insight into the process to work out what it was trying to do - and with a bit of fudging and googling I came across another method.

ADF-Sender is a similar program (though less featurefull) for sending files, and more importantly it goes into the methods and problems you might have... So after some messing around with it, I managed to get AREXX across to the new machine - and with something to actually PROGRAM with, a few hours later I was able to send the new WB disks and virtual floppy utilities across - Install the new Workbench software, setup Amiga Explorer and start transferring files - all the software I'd been accumulating and testing on WinUAE to begin the project!

Sure I could have waited a few weeks, but from past experience I know that if I set a project aside for a while, the enthusiasm wanes until it becomes a project I'll 'get around to' - and some projects, like replacing my old Amiga - can sit around for 11 years before I get back to them...

Ack Pfffft!

I think Bill the Cat would have been proud of the noises that came out of me while cleaning out the 'beige box' - a thick layer of 10 year old dust was so deep I had to use 2 cans of compressed air just to find half the screws to dissasemble the beastie.

When all was said and done, I was able to take stock in what I had.

Rev 4.5 motherboard - OSC chipset.  The battery hadn't leaked, which seems to be the common demise of these systems -- several critical traces lie just under the old nicad battery.  I'd lucked out,  the corrosion of the old battery hadn't made it down the stems to the board yet.. a quick 'snip snip' and now it never will.

I grabbed my trusty soldering iron and put a new style lithium battery in there and did a good clean of the board with air and some alchohol swipes.

Tested the Floppy drives, they are pretty much shot.  DF1 reads occasionally with errors, DF0 refuses see disks, on the 1 in 6 occasion that it actually realises it HAS a disk shoved in it....

A crappy old bridgeboard got taken out, as well as a 5 1/4 drive - I mean why would I emulate a xt on a 10 year old Amiga when I can emulate an Amiga on my PC?  Replaced the old SCSI controller with a G-Force 030 that has 4 megs of ram on it.

My wife laughed at that figure... a whopping 4 megs!  Her machine having 2 gigs, and mine having 4.. it does seem funny, but when I start to explain the differences in program size - machine layouts - design paradigms - her eyes glaze over and you can nearly see the 'other thoughts' bubble appear over her head... She has as much interest in that stuff as my dog has in comic books.

A quick look up Google and a trip to Ebay and all missing components are on their way, hopefully soon.  ECS chipset is pretty much a requirement, that 1 meg of chip ram makes developing easier.

Besides, half of this is about re-creating the fun I used to have, and the first step in that is re-creating the old machine...

In the beginning........

My wife is looking at me strangely as I carefully lift the 'beige box' out of it's packing. It's seen better days, but the 'new to me' Amiga 2000 is pretty much just how I remembered it. I set it up on the kitchen table and powered it up - no monitor cable so it's in black and white - neither disk drive will boot up - and it's sporting the uber-old Workbench 1.3 logo. It's gonna need some TLC.

So... why? Why buy a computer that's probably 20 years old and barely working?

Nostalgia I guess - I'm at a point in life when I keep looking back at how much fun I used to have messing around with computers - and how now it's just a functional part of my life.. my life being where I go to work - edit commercials all day long, come home, eat, check the web, watch TV and then sleep.

The last huge creative rush I felt was when I first hit up Second Life, probably 4 years ago (this is the EARLY Second Life - not the realm of scam artists, hucksters, and sexual deviants it is now). Linux had it's rush back in the late 90's - but thats faded, and so I look back to the first computer I got really passionate about programming.....

And there it is in a nutshell.

So what am I going to do with it? What I always enjoyed doing - creating and programming. Which brings us here - Somewhere I can post my journey, and hopefully keep myself a little motivated for the (hopefully) long journey ahead... In SubGenius terms, I'm trying to take back a little slack in my life - reclaim a little fun and productivity that's been missing for a while.

More to come..... for now, Cheers!