RC 2016/01 Update: A change and prepping for the challenge

It's a little more than a week before the start of my challenge, but over two weeks since I announced it.  I haven't been idle in that time, however.  I've been thinking a lot about the project, which has led me to some changes and issues.

Changing the Challenge

I've decided to make a change to my challenge.  Instead of developing my dBase for the IIgs, I will be developing it for the IIe/IIc - or, more specifically, for ProDos 8 instead of GS/OS.  There are several reasons for this, but the biggest is that I really don't want to exclude using my IIc.  I love my IIgs and it is the machine that I have use regularly, but the IIc was the first Apple II machine I purchased, and I still like it a lot, even though it's packed away.  I just really don't want to write a system that would preclude my using it on that machine.

Another reason I want to do it for ProDos 8 is because the emulators are just better.  I've used all the emulators for the IIgs that I'm aware of (kegs, gsport, sweet16), and honestly they pale beside the IIe emulators like AppleWin and Virtual II.  More specifically, if I did the project for the IIgs I had planned to use ORCA/C, which doesn't seem to work as well on the emulators.  It compiles C code just fine, but it has odd graphical issues in the editor when I move the mouse or the text cursor.  It makes it very difficult to use.  These issues don't occur on my real IIgs, but it's consistent across all the emulators, so I'm not really sure where the issue is, but in any case I really don't want to debug into the emulators or ORCA/C to try to figure it out.

As a result of my switch, I will be calling my project kBase instead of kBaseGS.

Development System

I have switched to using CC65 for my development.  For those who are not familiar with this tool, it's a full C compiler, assembler, and linker targeting many of the 6502-based machines.  As a modern tool, it runs on all the modern OS's - Windows, Linux, and Mac OS X - but generates binaries that can be executed on the old 8-bit machines or their emulators.  It includes most of the common C libraries, each of which has been recoded for each of the target platforms.  So you can write code that is reasonably portable between the Apple II, C64, and Atari platforms, for example.  That's not my intent, as demonstrated by the fact that I'll be using 80-column text mode on the Apple II, which doesn't exist on the C64 or Atari systems.  

Toward that end, I've already started doing some development - not on kBase itself, but on a CARDIAC simulator that will give me a good chance to learn some of what I need to know.  If you're not familiar with CARDIAC, you should really check it out.  It's a simple machine with 10 instructions, 100 memory addresses, and an accumulator as it's only register.  It's a base-10 system rather than binary, and each memory address can hold from 0 to 999.  It was produced by Bell Systems in the late 1960's to help high school students learn how computers work. 

Because it is so simple, it's something that can be knocked out very quickly, and you can see the program running to the right.  You can't really make it out too clearly, I'm afraid.  The 5 columns of numbers on the left are all 100 memory addresses, and on the right side is the program counter and the accumulator.  At the very bottom is the input (numbers only) and the output.

For me, the biggest benefit of this program (other than just the fun of writing it) is playing around with the 80-column mode and seeing what I can do with the text output routines that CC65 contains.  It has a version of the CONIO library included, so it does do quite a bit.  Next I want to work with the file input/output routines, volumes and directories, etc., which again will be necessary for kBase.

Incidentally, the pictures above do show A2 CARDIAC running on my IIgs.  I did my development on my iMac using Atom as my editor, and then used AppleCommander to transfer the binary to a floppy disk image that I tested using the Virtual II emulator.  I then used ADTPro to transfer the disk image to my IIgs so that I could load it off of a floppy.  The build process is managed using Make, which builds my binary, links in whatever libraries I need, and copies the binary to a disk image.  I handle loading it up in Virtual II manually.  If you're at all curious, feel free to check out the project on GitHub, and I'd love any feedback or suggestions.

dBase III issues

As I've been exploring dBase III Plus more, I have found some issues.  The biggest is the DATE data type, which stores years as a 2-digit number.  For 1985, this was fine, but of course all of us remember the Y2K discombobulation.  And given that we're now living in the 21st century, I'd much rather use a 4-digit year than 2-digit.  But I also want to maintain as much compatibility with dBase III as possible.  I'm considering doing a sort of add-on field.  That is, when you add a DATE field to your database, the system would automatically add a 2-digit numeric right after to represent the century.  In kBase, this field would be hidden and just treated as part of the DATE field.  In other xBase systems, this would then just appear as an additional numeric field, but hopefully the name of the field would be enough to suggest what it's purpose was.  I'll have to think about this, and maybe I'll come up with another option.

Retrochallenge 2016/01: kBaseGS - A dBase III Plus clone for the Apple IIgs

The Challenge

I'm going to write an xBase system, named kBaseGS, that will be compatible with dBase III Plus (the standard early dBase product, and the one that most early xBase products - including FoxPro - emulate).  My eventual goal is to write a fairly complete xBase system that is capable of running full programs, but there's no way I can achieve that within the time span of this challenge, so I'm going to have more modest goals.  By January 31st, I hope to support the following features:

• A system that allows interaction through a command prompt.  It may be text-based, or it may use a graphical command prompt; I haven't decided yet.  
• Create a table (DBF file) that is readable by another dBase III Plus compatible system using standard dBase commands
• Read, sort, and filter tables using standard dBase commands.  Because I won't be adding indexes (see stretch goals below), performance will not be a consideration here.  I will assume that this system will only handle a relatively small number of records in the area of <1000.
• Support only the CHAR, NUMERIC, DATE, and LOGICAL data types.  This excludes only MEMO from what was available in dBase III Plus, which uses a second file that doesn't seem to be well documented.
• Allow inserting, updating, and deleting records using standard dBase commands.  This will be functionally similar to dBase's facilities, though the interface for data entry may look different.
• Build a reporting engine that will support only a subset of the dBase reporting functionality, enough to display a basic list with a header and/or footer and output this to the printer.

This certainly seems like more than enough work for one month, given that this is being done only in my free time (i.e., after the kids go to bed), but I do have two things going for me.  First, the family will be gone for a week in January, which I'm already planning to take off from work, so I'll have 7 or 8 days with no distractions (other than the tv, computer games...well, you get the idea).  Second, I'll be writing this using the ORCA/C compiler, not in assembler, so development should go faster.  C is a faster language for development than assembler to begin with, and on top of that, while I can happily do assembler, I'm just far more comfortable in C.  I've used it for so many years on a number of different platforms, so much so that I think I feel more comfortable in that than in Java, which is what I've been using professionally for over a decade.

So with that in mind, and being a naturally optimistic person (okay, not really, but certainly a naturally delusional person), I have two stretch goals:

• Implement an indexing system.  Ideally this would use the dBase's NDX files, so I would just be able to read in an index generated by dBase III Plus, but this is poorly documented, so that may not really be feasible.  Failing that, I'd create my own indexing system with it's own file format, a KBX file.
• Implement SET RELATION that allows linking two tables based on a common key.

As I indicated, I'll be doing this in C, so by the end of the challenge, I will post the code on GitHub, along with whatever else is needed to build and use the system - documentation, build files, etc.

What I'll be Doing Until January 1st

Obviously I won't be writing code for kBase.

But I have a good bit of prep work to do.  First, I have to learn about dBase III Plus.  As I talk about below, my background in the xBase world is FoxPro and even that was over 20 years ago.  I've ordered the dBase III Plus Handbook, which I'll use as my primary guide, and I've installed dBase III Plus on an MS-DOS 6.22 VirtualBox instance that I have setup (along with Doom - just couldn't install DOS without Doom!), so I have a system to experiment with.  And I'll do some research into the dBase file formats as well as any other dBase details that might be necessary to my project.

I also have a good bit to learn about Apple IIgs development.  I've had the system for a few months, but frankly it's only been really usable the past few weeks when I changed from using the composite output to the RGB-to-VGA output.  Under composite, GSOS looked like crap, but now it looks quite good.  I've been reading some books, Programming the Apple IIgs by Mark Andrews, and the ORCA/C manual.  But I haven't actually written anything more extensive than a "hello world" program yet, so I'll spend some time getting acquainted with the IIgs as a developer and actually sit down a put together a more substantive program.  I have a few small projects in mind.

So there it is, my project for RC 2016/01!

If you're curious as to what led me to this project, read on...

The Long-Winded Explanation for Why I'm Doing This

Originally I had "The Challenge" section at the end, but this turned into a much longer explanation than I had expected, so I decided to move this part to the bottom for those who don't really want to know why I decided to do this.  

Reliving the "bad" old days of FoxPro

My first job as a computer professional was at a small consulting firm in a small town.  When I was there in the early 90's, it had less than a dozen people, including the owner/managers, and we serviced small businesses with whatever IT needs they had - hardware and software.  It wasn't the best place to work, but I did learn a lot that I wouldn't have at most other places, especially in the area of PC hardware and networking.  For programming, I learned probably more about what not to do instead of what to do.  I had been a self-taught hobbyist up to that point using BASIC, C/C++, and Pascal, but the company used an xBase clone called FoxPro for most of their custom software.  I worked there for roughly 18 months, and I never went back to FoxPro.  That was more than 20 years ago, and I honestly don't remember that much about FoxPro - other than I thought it was mostly a bad language.  So despite several people that I respect who say good things about xBase languages, I have happily stayed away from the xBase world for the 20+ years since then.

Enter the Kaypro

But then I got a Kaypro.  Or, more precisely, as of this writing, I've ordered a Kaypro - but it hasn't actually gotten here yet.  But I started reading up on it a bit, and I noticed that among the CP/M software that I was getting with it was a copy of dBase II.  Now, bearing in mind that I still have no love for xBase systems, I decided that it might be a bit of a nice stroll down memory lane to do a project in dBase, which would also help me in learning the Kaypro and CP/M.  So I decided to do a dBase II application to inventory my retro collection and other electronic stuff.

There was just one wrinkle: I really wanted the ability to print out a report, but I didn't have a printer for the Kaypro.  Now, of course, I could buy one, but I really don't want to.  I'd already spent enough on the Kaypro itself and some other sundry items (e.g., more software, serial cables, a book), but more importantly I just don't have the room.  I have a "man cave" where I can do my retro stuff, but despite it being mine, I really share it with the kids - twin 4-year old girls and a 7-year old boy.  This leaves me with only enough room to setup one complete system, with a little leftover space for a "secondary" system if I'm so inclined, i.e., I can have this second system setup and hooked up to the monitor, but it will be cramped, and I can't have much in the way of accessories setup.  And right now my main system is an Apple IIgs.

The Apple IIgs

Over the past few months I haven't been blogging much because I've been pretty busy, but I have not been inactive in my retro activities.  These activities have mostly centered around the Apple II line of computers, and in particular the IIgs.  When the Apple II was actually available, it was too expensive for my family, so I had a Commodore 64.  My only experience with Apple II's back then was playing on one a little bit at a friend's house, and in my senior year at high school when they had replaced all their TRS-80's with Apple IIe's.  But honestly I can't really remember wanting an Apple II.  I remember wanting - but not being able to afford - other computers back then, but not Apple's.  They just seemed pretty limited compared to my C64, and to my teenage eyes they looked kind of ugly.  So when I got into retro computing a year or so ago, the Apple II was no where near the top of my list.

But then I saw an eBay auction for an Apple IIc, which I talked about in two earlier posts: My Latest Retro Acquisition and ADTPro and the Merlin assembler.

I had been happy with the IIc, but then I saw a cheap auction for a IIgs base system - no monitor, keyboard, floppy drives - just the base ROM 01 unit and the original Apple memory expansion card.  I bought an ADB keyboard and mouse and hooked it up to my monitor using the composite out and I had a functioning unit with 512k ram.  I added a 3.5" drive, a Classic IDE for Apple II card (an IDE interface card for use with hard drives or, as I use it, an IDE-to-Compact-Flash adapter), and a 4 MB memory expansion card, so now I'm running GSOS.  More recently, I ditched the composite cable and ran the RGB output into a GBS-8220 to convert it to VGA (using the instructions found here that were easy to follow), which improved my video display tremendously.  And I've ordered a CFFA 3000 and an Uthernet II and am anxiously awaiting for both of them to arrive.  And only about two weeks ago, I got an ImageWriter II dot matrix printer that works very nicely.  And, finally, I ordered the Opus II ByteWorks software set, which includes among other software a IIgs assembler and C compiler.

So I've really gotten hooked on the IIgs and the Apple II line in general.  It's a good system with impressive expansion possibilities, and I think it nicely straddles the fence between retro 8-bit systems and more modern systems.  It's still an understandable system that you can effectively program in assembler, but you can see in it the beginnings of a lot of the aspects of modern software and hardware that we use today.

So why am I going on about the IIgs when my project ostensibly involves dBase II on the Kaypro?  Well, as I talked about earlier, my idea for a project was to do an inventory application in dBase, but since I don't have a printer for my Kaypro and don't want to get one, I decided not to use dBase II or the Kaypro.  I would like to do this on my Apple IIgs, where I do have a nice printer, but there is no xBase platform for the IIgs that I could find.  Of course, there are other database applications, but I really want to do this on an xBase system.  Thus the decision to write my own.

ADTPro and the Merlin assembler

As I mentioned in my last post, I got a nice Apple IIc off of eBay a few days ago.  So far I'm quite pleased with it, but it hasn't actually been that much fun or useful.  The previous owner (who apparently took very nice care of it) was a user, not a developer.  He bought it new and used it to run his business for many years, and then when it was no good for that it became a game machine for his kids and grandkids.

Unfortunately I'm not really much of an arcade gamer, and in any case the bundle didn't include a joystick (he told me that it didn't work any longer).  And the only other software that came with the machine were applications: AppleWorks, Quicken, and a set of utility programs.  But no development tools or anything that I would be interested in.

So of course I looked into ADTPro.  I just didn't have the cables to hook it up however, and I didn't have the parts to build a DIN connector.  I could have cut the modem cable, and I do have the parts for a DB-9 connector, so I could have made a cable.  But I actually have some hope of eventually using the modem to connect to one of the few remaining dail-up BBS's around, so I didn't want to ruin the cable.

In any case, I ordered the cable from RetroFloppy.  Incidentally, although I didn't talk to any of the guys there, I would recommend them if you need anything.  When I ordered the cable through PayPal, it charged me a pretty hefty shipping charge of around $10.  Well, I didn't think too much about it, but the next day I got an email from one of the guys there who informed me that PayPal had estimated too much for shipping and they gave me a nearly $4 refund.  Honestly, the money isn't that big of a deal, but still it's always nice when a company is honest.

So the cable arrived today and of course I hooked it up as soon as I could.  And it worked without a problem.  I already had a USB-serial converter, so I plugged that into my iMac and ran the ADTPro cable to my Apple IIc.  I launched the ADTPro server and followed the instructions and soon enough I had an ADTPro client bootable disk.  I then created a ProDOS v1.9 System Utilities disk (the Apple IIc came with a much older copy of ProDOS), and two floppies for Merlin-8 v2.58.  It was all simple and worked flawlessly.

So now with Merlin-8 transferred (an Apple II assembler, if you're unaware) I can start doing some development.  I've had the Merlin-8 disk images for a while, and I actually also own a copy of the Virtual-][ emulator (a very nice emulator, btw - highly recommended for a nice, retro feel).  I've got a copy of Roger Wagner's Assembly Lines, so now I plan to start working through that.  Of course, I could have already been doing so using the emulator, but for some reason I really didn't want to until I had a real computer I could use.  But with my Apple IIc and Merlin-8 assembler in hand, I hope to start working through the book.

Stay tuned...

My latest retro acquisition

As a quick note to those who may have only read my PDP-8 Challenge blog, this blog is my general blog on whatever topic I want to write about - mostly things related to vintage computers.  I haven't updated this in a while because I've really been focused on the PDP-8, but that will probably be changing for a little bit now.

So I'm happy to introduce my latest retro acquisition, a very nice Apple IIc.  I got if off eBay for a pretty decent price, and as a bonus the seller lived in my city so I was able to pick it up the day after I won the auction.  The machine itself works flawlessly, except for a sticky keyboard (more on that below), or at least I haven't found a problem yet.  The bundle came with a bunch of floppies, including 10 blanks, two power supplies, a carrying case, a 1200-baud modem, cables, and manuals.  The previous owner wasn't a developer, so it just included application software - AppleWorks 3.0 & 2.0, Quicken, and other miscellaneous programs and utilities.  A MultiRam C card had also been added, expanding the memory to a total of 256k.  Overall, a good bundle and the guy had clearly kept things in good shape and organized.  This was really good for me, because I have no real experience with the Apple II platform, so finding a good collection like this is a good starting point.

So even before I took possession of my new machine, I ordered enhancements.  I got a 256k upgrade for the MultiRam C card, an Apple mouse, and an external drive.  The drive in particular I was quite interested in, because I have this fear of floppy drives failing.  They're just so loud and of course have many ways to fail, so every time I use one I'm just paranoid it will be the last time.  It's odd because back in the day I never really thought about it, but now of course the drives are much older - and, to be frank, I'm just not used to something making that much noise.  Today, noises like that coming from a computer would pretty much mean we'd be buying a new hard drive at a minimum.  That's why I have purchased SD card readers for every retro platform that I've worked with, and the Apple IIc is no exception.  Unfortunately I'm going to have to wait until October or maybe November before it gets here.  So in the meantime I figured I'd use an external drive so that, if a floppy drive had to fail, the external drive would be a lot easier to replace than an internal drive.  Unfortunately I didn't realize until I got the external drive that I can't really boot off of it, so I can't get around using the internal drive.  But hopefully the external drive will at least allow me to minimize how much I use the internal drive.  And having a second drive is just so much more convenient anyway.

One of the other upgrades I got was an extra 256k for the machine.  I wish I could say I honestly needed that much ram, and maybe I will find a good use for it, but certainly at the moment the 256k that the machine already came with would be more than adequate.  But it was cheap, so I figured why the hell not.  So once I got that, I went ahead and installed it - and resolved my keyboard issue at the same time.  

As I mentioned the keyboard was the only problem with the machine.  It worked, but it was very sticky, making any kind of quick typing impossible.  I did some googling and found that I wasn't the only one who had such a problem, and thankfully I found some answers.  And in the process I also discovered that this was an original version of the Apple IIc, so most of the solutions didn't actually apply to me.  When I started to pop off the key caps, I found a black rubber membrane underneath, and under that a burgandy metallic sheet (see the picture).  Apparently the early version of the IIc had those as a guard against liquids splashing between the keys and damaging the electronics underneath.  But this also apparently caused problems with keys sticking, so it was removed in later models.  So I felt reasonably confident in removing it, but that didn't actually solve my problems.

As I hope you can see from the photo to the right, each of the keys has a little metallic clip.  I have no idea what this is for, but once I removed them from all the keys, they worked fine.  It took me about 30 mins to remove all the clips, but it was well worth the effort since now the keyboard works great.

With the keyboard issues fixed, I then went on to adding the ram.  Following the instructions from the MultiRam C  manual, I opened up the IIc and, lifting the keyboard, exposed the main board.  The picture below shows the main board with the MultiRam C board removed.  It's a bit hard to see, but the bottom two large slots are actually where the CPU and MMU chips go.  But the CPU and MMU fit on the MultiRam C and the card plugs into those two sockets.  You can hopefully see this in the photo of the MutliRam C card itself.  On the MultiRam C card, it had only one row of the ram chips (the smaller chips on the left side).  I added the second row, put the card back in the machine, and that was it.  I then ran the MultiRam diagnostics and, sure enough, I now have 512k.  Additionally when running AppleWorks it reports 365k free, which is of course more than the machine had originally, so clearly it sees the new ram as well.  It's cool to have 512k ram in a retro computer.  Now I just have to figure out what to do with all that memory.

By the way, just to demonstrate that retro computing isn't just for old guys, here are my twin 4-year old girls playing on the my new Apple.  They like to use AppleWorks to type out their names and ABC's.  They even now know how to load floppies, though I haven't yet been able to get them to remember to NOT TOUCH THE EXPOSED PART OF THE DISK!  I swear I nearly have a heart attack whenever they do that - and trust me, with my blood pressure, that's not a minor concern!

If you're curious, that's Trinity in the top picture and Harmony in bottom one.  And that's a Commodore 64 in the background, and the back of a Commodore 1571 disk drive under the monitor.

Retrochallenge?

Right now, the oldest computer in my collection is a (alas, non-functioning) Atari 800, at least in terms of when the model was introduced, not necessarily when the machine I have is made - although even by this measure it's still likely the oldest.  The Atari 400 and 800 were both introduced in 1979.  But most of the computers I've been playing with have come from the 80's - the CoCo launched in 1980, the VIC-20 in 1981, and everything else later than that.  And everything I've played with so far has been a personal microcomputer.  So it's been a bit of a change of pace for me over the past few days to really spend some time playing around with the PDP-8 and PDP-11.  Not real machines, of course, but using the simh emulator.

I've wanted to play around with the DEC PDP series for some time.  These minicomputers figure prominently in computer history, most notably perhaps with the development of both Unix and C on the PDP-7 and PDP-11, respectively.  And then with the 50th anniversary of the PDP-8, it's also gained some renewed interest in the vintage computing community.  Case in point, this very interesting PDP-8 emulator running on a Raspberry Pi with a front panel almost exactly like the original PDP-8's front panel.  I've been on the mailing list for this kit since I first saw it months ago, and I'm very anxious to get it towards the end of July when he's announced it will be ready.  By the way, this is from the same guy who supplied me the KIM Uno kit that I had some fun with some months back.

With the Retrochallenge Competition coming up, I had thought about doing a minimal Forth implementation on my VIC-20, but then Earl Evans decided to do a Forth implementation on the C128 (something I'm very interested in seeing, given my interest in the C128), so my VIC-20 project seemed too similar.  It's not really.  Despite using essentially the same processor, the C128 and VIC-20 (especially unexpanded) are very different machines, and their Forth implementations would be very, very different.  But still, I didn't want to do something so close to what someone else was doing.

Enter the PDP.  I have it in mind to do a multi-user game running on a PDP that can be connected to via telnet.  My requirements: I want multiple users to be able to connect and play the game at the same time.  I'm uncertain yet whether the game will require all users to be logged in, or if it will just support having multiple users logged in to complete their turns.  I specifically want to do this in some language I am not familiar with, one with history that may - or may not - still be in use.  COBOL was my first thought, but finding a COBOL for any PDP has so far proved challenging.  I am consider DIBOL, though; that is DEC's competitor to COBOL for the PDP-8.

So my first thing is just to get a PDP environment up and running.  I've got a PDP-8 running with both OS/8 (not multi-user) and TSS/8 (multi-user).  My only issue with these is finding the language I'd like to use.  I do like the idea of using a PDP-8, though, so I haven't ruled out either of these.

For the PDP-11, I've got both Unix v6 and v7 running.  Unix appeals to me just because of my history with Linux, and it would be interesting to play around with a considerably older version, but I've got issues here as well.  I've v6 running in a multi-user environment, but trying to find any software for it has been challenging.  It's got a C compiler and an assembler installed, of course, but no other language.  And the only editor is Ed, a line editor (think MS-DOS's old EDLIN).  That would be very painful to develop in.  Of course, I could write a full-screen editor, but that would keep me from writing the game.

I've got v7 running as well, but only in single-user mode.  I would like to enable multi-user, but I'm running into a problem.  I'm using a tape image to boot up Unix, and then using a disk image once it's booted.  During the process of configuring the system, I copied a bunch of stuff from the tape image to the disk image to be mounted as /usr.  This includes, among other things, the source for the system, which is important because I'll need to rebuild the system to enable multi-user support.  While I'm setting up the system, all the data on the /usr is present, but once I boot up, it's all gone.  I don't know whether it's an issue with my disk image, with my Unix install, or with my simh configuration.

Right now, I'm probably slightly leaning in favor of the PDP-8 with OS/8.  That means (unless I can figure out MULT-8 or MULTOS or one of the other multi-user systems that use OS/8) that I'll only have one person logging in at a time.  Also I'm uncertain at the moment of whether OS/8 supports user accounts.  Right now, as far as I can tell, it just supports terminals with no differentiation between users.  But OS/8 has several advantages.  There's a lot of software out there for it, and there's a lot of documentation.  It seems to have been the standard operating system for the PDP-8, so support for it is pretty extensive, relatively speaking.

If I can find software for Unix v6 or I can get my multi-user issues worked out with v7, then I'd probably use one of those instead.  I could even live without multi-user on v7, but the issue I'm having with the /usr mount really hampers the effectiveness of the system.

This will be the first Retrochallenge I've entered, and my obstacles are not insignificant.  First, I've never worked on a PDP-8 or 11 and know almost nothing about them.  Fortunately, I'm not looking to become a PDP expert, but obviously some familiarity with the machine will be required.  Second, while I might use C (given the age of the systems, it would be a noticeably different dialect than I'm used to), I'd prefer to use a language I don't already know - COBOL, Algol, Fortran, something like that.  And, third, I've got to come up with a game that I'll find interesting enough to play, i.e., not TIC-TAC-TOE or something simple, and it has to be something that can be played with other people.  And it's got to be interesting enough as a text-based game.

The Retrochallenge starts July 1st, so I really have some decisions to make.  I have to decide on my computer and operating system, I have to decide on my language, and I have to decide what game I'm going to write.

And then there was...the VIC-20!

I haven't had much to post in the past few weeks, as I've been pretty busy, but that doesn't mean I haven't done anything with vintage computers.  My biggest accomplishment has been to purchase a VIC-20 off of eBay.  While I haven't been actively trying to acquire a VIC-20, my favorite brand of vintage computers is Commodore, and the VIC-20 was the first computer I ever owned.  I bought it at a HamFest in the early 80's, and it came with a 24k expansion module but no storage device.  And because only the C2N Datasette was usable, but not particularly cheap at the time, I couldn't afford to buy one.  I ended up not doing much with it and actually sold it not long after at another HamFest.  But this one on eBay was cheap (<$50 including shipping), and I've got an unused SD2IEC (1541 emulator that uses SD cards for storage) that should work with it.

I haven't actually gotten the computer yet though, even though I purchased it on May 27th.  After about a week of nothing, the seller actually emailed me and apologized for the delay and said they would include a C2N Datasette with it, which is pretty cool both that they did so and also that I'll finally have a Datasette after 30+ years.  Checking the auction, I noticed that a shipping number had finally been assigned to my order, but when I checked the progress, it never went anywhere.  It said that the shipping hadn't actually dropped off the package yet.  It stayed like that for over a week again, and I was about to send a message to the seller again, but then finally it's moved.  As of Friday, it finally departed a USPS facility in Federal Way, WA.  So I've probably still got a while before it gets here.  The auction said it had been tested, so I'm hopeful that it will work and looking forward to playing with it.

Toward that end, I've been doing some reading on the VIC-20.  If you're a Commodore afficionado, then you've undoubtedly been to DLH's Commodore Archive.  This is a great site because it has a huge archive of books in PDF form relating to all of Commodore's computers.  That's where I got my library of PDF's for both my C128 and C64, and the site didn't disappoint for the VIC-20 either.  I'm currently working my way through "VIC-20 Machine Language Guide" by Roy Wainwright and Arnie Lee.  I like the book because it seems to focus less on actually teaching 6502 machine language and more of how to use it with the VIC-20.  This is good for me because while I'm not 6502 assembler expert, I do know enough to be beyond a beginner's book.  But a book that discusses how to interface with the VIC-20 from machine language is useful.

All this is for my new project (which will probably end up like most of my other projects, unfinished) which is a Forth implementation for the VIC-20.  Now there's already VIC-Forth, but it came out in cartridge form, which means that it had access to most of RAM.  But I was curious if I could write a usable Forth implementation, even a limited one, on an unexpanded VIC-20 that would be loaded from disk.  This means that, instead of residing in ROM as a cartridge would do, the Forth environment would have to reside in RAM along with the program that the user is building.  In a 5k machine (really 3.5k once you factor in screen/color RAM), this will be tough.

My collection

I talk to a particular friend of mine frequently, and he seems more fascinated by the number of computers I now own instead of what they actually do.  So I thought I would write down a quick summary of my hardware collection, so that the next time he asks how many computers I have, I can answer.

Commodore

I started with Commodore both back in the day, and more recently when I picked up vintage computing.  In terms of expense, this is still my largest group.  In terms of computers, I have:

• 1 C64C
• 1"breadbox" C64
• 1 C128 (my favorite computer out of all of them, though I'm really liking the CoCo - time will tell if the C128 hangs on to the top spot)

The two C64's were actually my original computers from back in the day.  One was mine, one was my Mother's, and when she passed I got both.  The C128 was my first vintage acquisition off of eBay, and I mainly got it because I was listening to the Retrobits podcast at the time and Earl Evans did a show on it where he stated it was his favorite computer.  So I purchased one and pretty quickly found that I shared his enthusiasm for it, even though I actually don't use it much anymore.

In terms of peripherals, both old and new, I have:

• 2 1541 floppy drives (one non-functional, both from original collection)
• 1 1571 floppy drive (purchased with C128)
• 1 SDIEC (SD card drive for the C64/C128)
• 1 1541 Ultimate II (SD card/USB reader and more - easily the best of all the new hardware upgrades I've purchased for any platform)
• MPS802 dot-matrix printer (from original collection - actually went through the effort of buying a new printer ribbon for it, but haven't yet tested it)
• Teknika MJ-10 monitor (from original collection - composite video works but chroma is off, use an LCD tv now instead)

Atari

I started reading a little bit about Atari computers but never actually used one until recently.  I did not have good luck with getting Atari computers, and I think that's why I actually don't use them that much, though I still have an interest in them.

• 2 Atari 800's (both non-functional, first machines I picked up but neither worked)
• 1 Atari 130xe (semi-functional - it generally works, but the Reset/Select/Option keys above the main keyboard do not work.  In fact, clearly someone has modified it because there are actually two keys labeled "Reset", replacing the Start key.  None of them work.  But the computer did boot and all the other keys worked.  This is the Atari computer I actually wanted to use, btw.  128k and I like the look of it better than any of the other models.)
• 1 Atari 800xl (Works!  This was the last computer I got, but by the time I did my interest in Atari had waned somewhat because of my prior bad luck.)

My list of peripherals is very small:

• Atari 410 (non-functioning, came with one of the non-functioning 800's - yeah, that was a bad purchase)
• Lotharek's SIO2SD (SD card unit for Atari computers)

Tandy

Although I really associate myself much more with Commodore computers, I go back a long way with Tandy computers.  The first computer I ever programmed on was a Color Computer 1, but it was my brother-in-law's computer, not mine, so I didn't actually do a whole lot with it.  But when I got to housesit for a weekend, I sat down with the "Getting Started With Color BASIC" book and went through it all.  It was my introduction to computers and programming.  A little later, I did a fair amount of programming and gaming on both a TRS-80 Model I and Model III, but neither were actually mine.

• Tandy 102 Portable Computer
• 32k Color Computer 1
• 64k Color Computer 2
• 512k Color Computer 3 (most recent acquisition)

Peripherals:

• Cassette drive with cable
• CoCo SDC

Honorable mentions

What I list above are all the actual vintage computers I own, but there are some other computers that fall sort of into the vintage computing area.

• Apple 1 Replica - A replica of the Apple 1 done by Briel Computers, I purchased the initial version (assembled) a long time ago.  When I first got it, I didn't know much about electronics and didn't actually get it running.  I could get it to work with the AT power supply I had.  Since picking up electronics more recently, I pulled it out and hooked up a 5v power supply that I built and was able to connect to it from a serial terminal on my Mac.
• KimUno - An emulator of the Kim-1 that I purchased in kit form.  It was built with all modern components, of course, and was considerably smaller than an actual Kim-1, but it had the same button layout and used a hexadecimal display like the original.  It used an Atmel328P (the same chip that powers the Arduino Uno - thus the Uno in the name) to emulator the 6502.

So what am I missing?

I feel like the two biggest gaps in my collection right now are an Apple computer and a Z80/CP/M machine.  With the Commodore and Atari computers, I've obviously done a lot with the 6502, and I really like the chip, and I like those computers a lot as well.  But obviously Apple was really the biggest producer of 6502-based computers, and I would really like to play around with one.

As for the Z80 and CP/M, I'm pretty familiar with the 6502 and am learning the 6809 now with the Tandy CoCo computers, but I still don't know much about the 8080 or Z80.  I've done some assembly coding on more modern Intel cpu's, but nothing before the 386.  I'd be interested to see what the 8080 looks like and how the Z80 improved on that platform.  And with the Z80, I'd really like to explore the CP/M world.  I used CP/M only a little bit back in the day, but there's a lot of software for it, and since I'm not really a big gamer, it's an environment that I'd still find interesting.  Incidentally, I'm aware that my C128 does have a Z80 processor and is capable of running CP/M, and I've actually used it to do so.  But I'd still rather have a dedicated CP/M machine.

I'm also quite enthusiastic about the PDP-8 emulator that is being developed by the same guy who did the KimUno kit.  In addition to just emulating a PDP-8, it will have LED's and switches on the front panel to really give the feel of working with a basic PDP-8.  When that kit comes out in July, I intend to add it to my collection.

Wrapping it up

So there you have it.  I have 8 working computers, or 11 if you include the non/semi-functioning ones, with far too little space to actually set them all up.  I generally only have 1 or 2 out at a time, and the rest end up getting kind of stuffed into a closet.  I definitely need to organize them and probably will move some of them down to the garage (e.g., I don't need my CoCo 1 or 2 since I now have a 3).  But I don't see myself getting rid of any of them.

CoCo 3 and 512k of ram!

It's here, my brand-spanking-new (to me) Tandy Color Computer 3!  It came as a standard model, so it only had 128k, but as I mentioned in my previous post, I had also ordered a 512k ram upgrade.  Coincidentally, my memory upgrade (and 6309 cpu, more on that below) happened to come today as well.  So I turned on the CoCo3 long enough to test it (everything seems to work), then started to remove the top to install my 512k module.  

And that's where my first problem popped up.  The case is actually pretty easy to remove, just 5 screws on the bottom and the top pops right off.  Or at least it's supposed to.  You can't really see it in the picture to the right, but the white top of the case fits on the board around the keyboard.  Around the keyboard are four cylinders connected to the top but that hold the keyboard in place.  They're not screwed there, they just rest there.  But it appears that a prior owner spilled something like glue which caused the top by the Ctrl and Right Shift to stick to the keyboard itself.  Even worse, one of the cylinders I mentioned, the one to the lower left of the keyboard, was also stuck, so the top wouldn't come off.  I couldn't figure out any way to unstick it, so I finally ended up breaking it.  That's the hole in the picture to left.  On the picture just below, if you look closely near the lower left side of the keyboard, you can see the plastic riser that used to fill that hole.  I tried to remove it without damaging the top, but after quite a while of fruitless effort, just snapped it off.

With the top finally off, I moved on to installing the memory module.  That's the 512k module in the picture to the left, the blue triangular circuit board just above the keyboard.  It was a little nerve-wracking to install, because it required removing 4 IC's and cutting two capacitors.  It was the latter requirement that made me nervous, because if I cut the wrong capacitor, it wasn't going to be easy to fix.  Putting back in an IC is easy (assuming I wasn't clumsy enough to snap off a chip leg or anything, which thankfully I was not - this time), but replacing a capacitor is not such an easy task for me, especially these because they're actually pretty small.

But fortunately it went smoothly and the memory upgrade worked without a problem.  The machine booted up as normal and gave me its standard memory output in Disk BASIC.  Of course, since that's in the neighborhood of 22k, that's not really an indicator if all 512k is available, though obviously its a good sign.  The memory module did ship with a memory test program, but unfortunately it was on a 5.25" floppy disk, and I don't have a floppy drive for the CoCo.  I have my SDC, but that requires a disk image, and for some reason Cloud 9 didn't have it available for downloaded.  But thankfully a quick Google and I had the disk image.  A little amusingly, the program was written to use 80-column text mode, which turned out to be all but unreadable on my screen.  Fortunately, it was readable enough for me to confirm that it had found all 512k.

So the other upgrade I purchased was a 63x09E cpu to replace the 6809.  Unfortunately, once the top was off, I realized that the 6809 is soldered on the motherboard, not socketed, so I'll have to desolder the existing cpu.  Looking back at the Cloud 9 page, I do see where it clearly says that, but I must have missed that.  I'm reasonably confident that I can remove it, but after struggling with the case, I decided I wasn't in the mood to tackle the cpu.  In any case, I want to wait until I can get a socket since I'll want to use that instead of soldering the new cpu directly to the motherboard.

So with that, I put the top back on and now I have a nice CoCo 3 with 512k of ram.  I did notice that the Right Shift is a little finicky, but that's a minor problem at best.  It does work, but you just really need to press it firmly.  Not sure about the Ctrl or Alt keys yet.  I press them while in Disk BASIC and a @ and = show up.  I don't know if this is normal behavior, but that's what happens in MESS when I type those keys, so I assume so.

As you can see from the photo, the hole is still visible, though it's not too bad.  At least I won't have to wrestle with the case again, when I finally get up the energy to replace the cpu.

Ok, another new computer...

So I got another new computer, a Tandy Color Computer 3, the third and final in the Color Computer line.  I hadn't actually planned on getting one, mostly because they tend to be a bit expensive, but I found one reasonably cheap on eBay.  They're actually kind of difficult to find.  They don't show up on eBay that often.  (Note the photo is just one I snagged off the Internet; I haven't actually gotten my computer yet.)

This one was good because, as I said, it was relatively cheap (about $100), and the seller (who did have a high feedback score) said it had been tested and worked.  So I figured I had to scarf it up since such an opportunity wasn't necessarily going to come by again.

So how is the CoCo 3 better than 1 or 2?  Well, to be honest, I'm not 100% sure.  The CoCo3 does come with 128k ram, but as I discussed in a prior post, I'm unsure how to use that from BASIC.  It also comes with a better video device, so higher resolutions are available.  And, thankfully, it has a composite video output, so I can ditch the RF modulator.  With the CoCo 1/2, I was actually connecting via an RF modulator, which amusingly gave me the unexpected nostalgic experience of banging on the table or tv to improve the picture.  That's something I haven't had to do for decades, but I guess that's part of the point of these older machine, to re-experience the old.  But no matter how hard I hit the tv, the picture only got so good.  So I'm looking forward to using composite again.  It may not be as good as vga or hdmi, but it's worlds better than the antenna input.

So in anticipation of receiving a functioning CoCo 3 system, I also purchased a 512k ram upgrade and a 63x09E replacement cpu from Cloud 9.  The 512k ram's benefit is fairly obvious, since what is true today was also true back in the day - more ram is better.  But 512k ram seems to be kind of the standard now, or perhaps more precisely the minimum for most CoCo3 users.  There are several pieces of software that I'm aware of that require 512k (including a nice port of Donkey Kong).

The benefit of the 63x09E, however, may be less obvious.  It's a replacement cpu that can fit in the socket of the 6809 that's in the CoCo 3.  It apparently has two modes of operation.  The first is strict 6809 emulation, so it acts just like a 6809 for software that is looking for this - which I assume is most CoCo 3 software.  But in 6309 mode, it's apparently an enhanced 6809, with more instructions, registers, etc.  Apparently some CoCo 3 software will take advantage of this if available and will therefore run faster, but will still run fine on a 6809 system.  Since it was only $16, I decided to go ahead and grab it, especially since I was already getting the 512k ram module anyway.

So really looking forward to getting my new toys and seeing what I can do with it.  The peripherals I've already purchased for my CoCo's (the Edtasm++ cartridge, cassette player, DriveWire cable, and the SDC) should all work just fine in my CoCo 3, so I should be off and running when it gets here.

New CoCo...well, new to me

So got my new CoCo yesterday.  It's a 64k CoCo2 that I purchased on eBay for about $60, including shipping.  And I'm happy to report that after some testing, it seems to work completely.  The only thing I haven't tested yet is the cassette interface.  I also got 3 cartridges with it.  One of them, a personal information manager, works, but the other two do not.  The cartridges do not have labels, so I don't actually know what they are, but I didn't really care, so no big loss there.  I did confirm that both my Edtasm+ cartridge and, more importantly, CoCo SDC work.  And as far as I know, the CoCo1 and CoCo2 are pretty much interchangeable.  There's nothing that one can do that the other can't, so it really is a drop-in replacement.

So then why a new CoCo?  Well, first I got it pretty cheap, so there's that.  Also, this is known to be 64k.  My grey CoCo1 is either 32k or 64k, but because of the peculiarities of the CoCo platform, I'm not sure which.  I'm sure someone more knowledgeable about the Tandy Color Computer could figure it out pretty quickly, but there doesn't seem to be a real easy way to do so, at least not one that I'm aware of.  So at least with this CoCo I don't have to wonder.

The other reason is just the size.  Desktop space is at a premium for me, and the CoCo2 is substantially smaller than its predecessor.  When I'm not using it, it just slides back pretty easily and still leaves me with substantial desktop space to use.  This was much less the case with the grey CoCo.  The one downside?  The keyboard feels better on the CoCo2 but is much, much louder.  And I'm already a loud typist, even on the quietest keyboard.  I expect to get noise complaints from the neighbors with this one. ;-p

CoCo SDC

So I got a item for my CoCo: A CoCo SDC.  This is a nifty little cartridge that plugs into my computer that adds virtual disk capabilities.  Essentially it includes Disk Basic functionality, but instead of going to real floppy disks, it goes to disk images on the SD card.  I don't know a whole lot about it at the moment, but still it's pretty cool.

A little ironically I got an Edtasm+ cartridge at the same time.  The irony is that the cartridge form of Edtasm+ is specifically for cassettes.  I got this off of eBay because I kind of assumed that the SDC would take longer to arrive than it actually did.  I play with several different retro platforms and have ordered SD card readers for each, and they always take a few weeks.  This one, however, got here within just a few days - the same day, in fact, as the Edtasm+ cartridge.  So the cartridge is kind of pointless unless I just get a hankering to do some programming to cassette.  

And I might.  It's the only retro computer I have with a cassette, and I kind of want to use it - though certainly not as my main storage device.  I suspect that in the end whatever assembler programming I will be done either using a cross-assembler or disk-based Edtasm+ - or maybe another CoCo-based assembler.

The weirdness of 64k in the CoCo

Although I've been playing around with vintage computers for a while now, I'm very much new to both the Tandy Color Computer and the 6809 platform.  Now every system has its oddities, but I have to admit that the way the CoCo handles 64k is the oddest thing I've seen with any vintage computer.

Now my understanding (and please someone correct me if I'm wrong) is that the CoCo does not directly address all 64k of ram, but instead effectively has two banks of 32k.  I believe this comes from Tandy's decision to use non-functioning 64k chips in their early machine.  When I say "non-functioning", I don't mean the chip doesn't work at all, just that not all the ram works.  But if one of the 32k block works, then they put it in the machine as a 32k chip, and then just use a switch to tell the machine whether to use the upper or lower 32k block.

But as the CoCo's production run wore on and ram chips fell in price, they started putting fully functioning 64k chips in, but still only advertised them as 32k machines and still only made one bank immediately addressable.  So even if you have a 64k CoCo, it will actually appear at first glance that you have a 32k machine.  For example, the screen shot to the right is from XRoar, but it's setup as a 64k CoCo, not 32K as the 24871 free ram might suggest.

So how to tell if my machine is actually a functioning 64k CoCo?  Well, as far as I understand, there's no easy way to tell.  I could open the box and check out the chips inside, but even if it has 64k ram chips, that doesn't mean it's a fully-functioning 64k memory module.  I also can't access all 64k from BASIC, so can't do anything there.  The only way I'm aware of to check is to write an assembly program to do so, since assembly is the only the only way to access all 64k.  But at present, I know almost nothing about 6809 assembly and even less about the intricacies of the CoCo architecture.  So I guess that's a future project...

Still it just seems like such an odd architectural limitation of the CoCo platform.  My understanding is that the CoCo 1 & 2 are basically the same, so I'm assuming the same limitation applies to both.  I don't know about the CoCo 3, but I'm unlikely to ever get one so my interest is more academic than practical for that machine.

CoCo Edtasm+

Having recently acquired a CoCo 1 with 32k of ram (though possibly 64k, not sure about that yet - the CoCo seems to have some odd quirks when it comes to ram) and with only a cassette recorder for storage, I decided to buy the cartridge version of Edtasm+.  I'm actually pretty happy as I found a relatively cheap cartridge on eBay, and I hope to have it by next week.  As I looked at Edtasm+, I found that it comes in both cartridge and disk form, but since I only have a cassette the choice was pretty simple.  The downside to it, though, is that based on what I read you can't really include files, so all your source has to be in one file.  This makes sense, since you don't have dynamic file access with a cassette like you do with a floppy drive, but it is limiting.  It also means that you can't really build a library of macros and procedures, which is very important for any serious assembly language programming.