I Like Old Computers
A recent acquisition finally arrived this past week:
An Amiga 500. This one is from the UK originally, so it's a PAL model. Most people seem to agree that getting a PAL model is probably best because most games for it were developed and sold in PAL regions due to the Amiga's overwhelming popularity there. That being said, switching from NTSC to PAL mode as needed is easily done with some of the later Kickstart versions from what I gather.
Pretty ghetto setup for using it on my desk at the moment, as I'm both short on space and waiting on some additional things to arrive so I can clean things up (most notably a shelf so I can slide the Amiga back a bit and have the monitor raised up).
While there are a lot of cool games available for it, I intend to use it for programming primarily. And actually, I will try to write code for it on it, using period-appropriate editors and compilers.
I'm still waiting for a number of additional things to arrive such as additional software (Blitz Basic, AMOS Pro, various books, 512KB memory expansion, HxC floppy emulator, RGB cable, ...).
Anyway, why an Amiga 500? Or, why an Amiga at all? What's with the old computer interest?
A variety of different reasons really. First off, I should confess that I did not actually grow up with Amiga computers at all, 'nor Commodore computers either. Aside from the fact that Amiga's were more popular in Europe, the first computer that I can remember my family getting was a 386 in the very early 90's. I seem to recall that we might have had some older "green-screen" type computer before that but my memory is really not helping me with it (was likely some kind of IBM PC, but it was not something that any of my siblings or I ever used).
Anyway, I suppose that a large part of interest is nostalgia. I quite fondly remember my initial foray into programming in the mid 90's, which for me was learning QBasic with a book I had bought for $0.50 from my school's library. Of course, it didn't teach programming for QBasic specifically as it was published before QBasic ever existed, and so that complicated my learning somewhat (I recall there was a Tic-tac-toe game in the last chapter that I couldn't get to work due to some syntax differences... but I didn't understand that was the problem at the time).
We didn't get a dial-up internet connection until a couple years later at which point I remember the first thing I searched in AltaVista was "QBasic." Internet time was extremely limited for me however as my parents were pretty strict on that, mostly because they didn't like the phone line being tied up for long periods. So what I would end up doing is downloading as much games written in QBasic as I could (which didn't end up being much, due to our really poor, slow dial-up connection... even by dial-up standards at that time) and then spend lots of time studying them, modifying things, copying bits and pieces, etc. I remember at some point a year or two later my dad bought me another book specifically about QBasic when I was with him in some computer store and that helped a lot.
Later on, my dad also bought me a book on C
which came with a disk which had a Watcom C compiler on it... and the disk didn't work completely so my dad ended up
contacting the publisher who sent another copy. I remember spending a bunch of time learning C, but eventually going
back to QBasic... the ability to simply hit a single key and run your program right then and there was really
attractive to me compared to using MS-DOS EDIT
to edit code then having to quit out and run a compiler and sift
through compiler errors, and then remember them and open back up EDIT
and fix the problem, etc. I think at the time,
it was just too much for my younger self to deal with as a hobby and the aforementioned attractiveness of QBasic's
edit->run cycle was just way better.
Of course QBasic was slow. Getting into games and graphics, you quickly realize that. Around 1999 or so, I took my
first jump into x86 assembly and writing VGA mode 13h (aka SCREEN 13
) graphics routines, assembling and linking
them into .QLB
libraries and seeing what a world of difference it made. My parents had become somewhat less strict
about internet usage so finding information out online was easier and that really helped things along. That also
eventually lead me to using existing libraries such as DirectQB, Future.Library, and even a few years later on UGL
instead of rolling my own.
Compared to today, where so much more is possible and more easily done without caring much about memory usage, code
efficiency, etc, I just feel "ho-hum" about it all. The feeling of power from writing code that runs "on the metal"
so to speak, POKE
'ing bytes into memory to make things magically happen, having to write lean code over nicely
abstracted, cleaner looking code because you literally don't have anywhere near the required amount of CPU cycles to
spare on stuff like that... a very different feeling that is lost. A different type of challenge. Makes me wonder
why I got into web development at all, and not into something like embedded systems, heh. At the same time, it makes
me happy I learnt programming when I did and not today. A part of me feels sorry for people learning today, probably
starting with something like Javascript or Python or what have you, where you never really get into the nitty-gritty
details about what is going on under the hood. No appreciation for the abstractions we take for granted today that
makes things like the web and the plethora of web frameworks even possible. Some new programmers probably do get
into that eventually, but I'd bet the majority don't (and they don't actually need to either technically speaking).
I briefly entertained the idea of getting a 386 or 486 PC to toy around with as an old school programming machine. I still might do that one day, but for now I wanted to try something a little bit different but still stick to a machine that is quite constrained hardware-wise but still has a plethora of development documentation and tooling available for it... and most importantly, something resembling a community. After all, being able to talk about your experiences with others also interested in it is worth something.
I've always been fascinated by the Commodore machines like the 64 and Amiga. The Commodore 64 especially piqued my interest when I first heard of one when I was younger as it was explained to me that "the OS is just a BASIC interpreter." Since I was learning QBasic at the time, the thought of the whole computer running BASIC sounded awesome to me.
Never heard of an Amiga until some time later but it, like the Commodore 64, sounded fascinating to me but for slightly different reasons. Mainly the fact that when it first came out it was so ahead of it's time. I also liked the fact that there was still an enthusiastic community for it (even if said community does seem excessively enthusiastic to the point of seeming somewhat delusional). Also that it was more capable than a Commodore 64, NES, or Atari, etc., but still quite limited. It had multiple options for development, with various BASIC options, C was in many respects a sort of "primary" development language for it, and of course 68k assembler which is one of the nicer assembly variants out there.
I'll probably dive into the world of Commodore 64 at some point down the road also as that's really such a quaint little machine and I do want to get more into 6502 assembly at some point (since I can then also tackle a large NES game project or two). But for right now, the Amiga seems like a nice option to focus on, diving into a whole world of computing that I missed by a few years.
So, as mentioned above, I actually intend to do development on the Amiga itself. We'll see how long that lasts I guess (heh), but I figure it'll be fun for a while to limit myself like that. I went with the 500 instead of a 600 or 1200 (which is what I think most people would probably recommend). This is because, from what I gather, by far most games for the Amiga were written with the 500 in mind. It was also I believe the model that was sold the most. As well, I feel like getting a more souped-up model kind of defeats the entire point of this "old school development" adventure to me.
To sum all of the above up: basically it's about looking for a nostalgic "old school" development experience that is in some ways familiar to what I remember growing up with, but different in other ways so as to present a new type of challenge.
I'm going to start with BASIC (either AMOS or Blitz Basic, I intend to try them both) and then work my way into C/assembly once I become more familiar with the hardware and it's capabilities/limitations... similar to what I did all those years ago with QBasic really now that I think about it.
Since I'm still waiting on stuff to arrive as I mentioned above, all I could really do for now is mess around with Amiga BASIC.
Amiga BASIC
This is just going to be my initial thoughts on it and will not be very in-depth as I don't intend to spend a lot of time with it. Most people from what I've seen tell people not to bother with Amiga BASIC at all. It's apparently buggy, slow and all around not very good. Since I cannot do anything else quite yet until more stuff I ordered arrives this coming week, I decided to play around with it a bit anyway for now.
It is interesting, having been created by Microsoft as there is definitely a "QBasic-like" feeling to it. Obviously not as polished though as this predates QBasic.
Support for integers, longs, single-precision, double-precision, strings, arrays, SUB
s, QBasic-like graphics
routines like PSET
, LINE
, CIRCLE
, GET
and PUT
, SCREEN
(well, the Amiga variant of it), file I/O that feels
pretty QBasic-like, LIBRARY
which is used to include and call external system library functions, ability to call
pre-assembled assembly routines via CALL
, VARPTR
and SADD
(QBasic CALL ABSOLUTE
-like functionality basically).
Again, it feels very QBasic-like to me. Though it is lacking a lot of niceties such as DO-LOOP
, SELECT CASE
,
TYPE
. Debugging support is obviously primitive with single stepping + the use of immediate mode to inspect variable
values being your only debugging assistance. But even that for the time is pretty cool.
Graphically, as mentioned above there are a lot of built in functions but it's all really slow. I typed in a quick
example from one of the manual PDFs I found which draws a cosine wave using LINE
to draw each vertical line from
y=0
to y=COS(x)
across a 320 pixel width and it took several seconds to run where you could see each line being
drawn, heh. I tried changing the example to use all integers and pre-calculating all of the COS
values so that the
drawing loop would just be doing some quick x/y calculations (addition and one multiplication), but no calls to COS
of course and it barely made any difference. I'd guess the bottleneck was the actual call to LINE
which is probably
not optimized at all.
This doesn't surprise me given what I've read about Amiga BASIC (I understand it was probably a quickly-done port from some variant of Microsoft BASIC perhaps).
There is some support for the Amiga's blitter (and possibly also the built in 8 hardware sprites?) through the use of
a bunch of different OBJECT
commands such as OBJECT.SHAPE
, OBJECT.X
, OBJECT.Y
, etc. After playing around with
these for a while, putting together a quick little demo to move a ball shape in 4 directions around the screen via the
keyboard I arrived at the conclusion that either this set of OBJECT
commands is not very fast either, or the entire
thing is hamstrung by the overall performance (or lack thereof) of the Amiga BASIC interpreter... probably a
combination of both really. Not that I was expecting much.
Anyway, kind of fun to fiddle with, but obviously very limited. I'm looking forward to being able to play with AMOS and Blitz Basic hopefully this coming week (pending my 512KB memory expansion arriving since they both won't run without it!).