Macintosh Performa 430 - Part 1

In my last post, I mentioned that I had worked on three projects, one of which was a Macintosh Performa 430.  Now I should state up front, I'm not at all familiar with the classic Mac OS.  I've been using Mac OS X since 10.3, but I had never even touched one before that.  As a long-time Windows user, I didn't find the Mac OS X interface compelling at first, and the lack of a command line, multitasking, and other sort of "power user" features made the Mac OS a non-starter for me.  But then a good friend of mine told me about Mac OS X and it's Unix base, and that's what turned me around on the operating system.  And I've generally been a satisfied user for the past 15 years or so (though I will admit that the more iOS-focused releases have made me think of jumping ship).

So at the same time that I decided to install Mac OS 9, I also decided I wanted to try out System 7.  Why?  Well, to some degree because of my Apple IIgs that I acquired about two years ago.  It was the first time trying GS/OS and not only was I surprised at how much the interface reminded me of Macintosh, but I also found I liked this interface that was closer to the classic look and feel.

With my decision to try System 7, I just had to find a machine, so off to eBay I went.  Of course, as I explained in my last post, my rush to get an iBook left me with a model that couldn't actually run OS 9, so I wanted to avoid that this time.  Unfortunately, that's where I ran into the "model hell" of 90's Apple Computer.  The Performa line, for instance, isn't a line of computers in any meaningful way.  They aren't a series of computer with similar or gradually increasing specifications.  They're just a set of computers that Apple arbitrarily applied the label Performa to.  So when looking at an eBay auction, unless you know the particulars of Apple hardware and the auction is good enough to list everything, it can be hard to know what you're getting, or how this compares with other models.

Stock photo of an SE/30

But I finally found a unit I liked, a Macintosh SE.  It seemed a bit underpowered, but I'd always that style of case.  I had heard somewhere on one of the many retro podcasts that I listen to that a Macintosh SE/30 was recommended, but I couldn't find any that were both cheap and tested to work, so I figured the SE would do.  Also I have a Floppy Emu unit (more on that later), which can emulate a hard drive as well as floppy for an SE, and I really do prefer to replace hard drives with solid state devices if at all possible.  But an eBay sniper got it from me.  It sat at $40 until the last few seconds and then suddenly jumped to $100 and beyond my bidding limit.

Photo on the eBay auction

So back to the eBay drawing board.  I knew I wanted a 68k machine and not a PowerPC, since I already had two PowerPC iBooks.  Again, the dizzying array of models confused me, but I finally found another machine I liked maybe even more than the SE, the Performa 430.  It didn't have the all-in-one case of the SE, but the "pizza box" design really appealed to me.  It also has a 68030 at 16Mhz, so twice the speed (and the same as the recommended SE/30), and could support up to 10Mb ram instead of just 4 for the SE.  The maximum ram is not as good as the SE/30 by a long shot, but the Performa 430 was considered a lower-end Mac when it was introduced.  And the best part: It was tested and cost about $50.

I ordered it on Thursday and it actually, much to my surprise, got here on Friday, but unfortunately though it had been tested it had quite a few problems.

1. It squealed while powered on.  It emitted a sound that was reminiscent of a radio being tuned, the high-pitch squeal when the radio operator can't quite find the frequency and keeps turning the knob.
2. The floppy didn't work.  
3. The hard drive worked, but when the unit was left on for a relatively short period of time (5-10 mins), then it wouldn't boot properly until it had 20 mins or so to cool down.  I discovered this while trying to diagnose the floppy issue, because I rebooted several times.  Or I tried to.  When I rebooted the first time it had been on for a little while, it would try to start up, then stop and reboot on its own.  And it would just keep rebooting until I finally turned it off.
4. Not a problem with the Performa, but an obstacle for me: I didn't have a Mac monitor.  The Mac's of this period use a DB15 for video output, but it is in two rows instead of VGA's three, so it can't connect to a standard monitor with just a VGA cable.
5. The PRAM battery was dead.

So when I got the Performa, I of course rushed to set it up.  The video connector was the first issue that hit me, so in some frustration I ordered a connector and assumed I'd have to wait several days before I could play with my new toy.  But then I remembered that I actually had such a connector (the adapter to the left in the picture to the right).  I'm not sure why I have it, I think it might be in relation to the Apple IIgs (even though it doesn't use it, I think at the time I thought it did), but it did the trick.  I was able to connect the Performa to an older VGA flatscreen I have and it detected the resolution and worked well.  The only thing I noticed was flickering in the image.  It was perfectly usable, but not great.

When the connector that I ordered arrived (the one to the right), I set the jumpers for an LC II model (Performa models 400-430 are just an LC II model under a different name and a different software configuration, an example of the confusing mess that was Apple's method of naming models) and hooked it up.  It worked wonderfully.  The flickering was gone and the image displayed perfectly.  So if you're trying to hook up an old Macintosh to a VGA monitor, definitely go for the connector with jumpers pictured above, a Mitsubish AD-A205 instead of the simpler model above.  

With the video problem resolved, I still had to get my Performa up and running.  Fortunately, it uses an ADB keyboard and mouse, as does the Apple IIgs.  I had purchased an Apple Extended Keyboard II unit and an ADB mouse for my IIgs when I first got it, so I scavanged those for my new Macintosh.  And with that, the unit booted like a champ into System 7.

At first, I was excited, of course.  Buying off eBay is always a bit of a risk, even when you're buying from someone with a good reputation and the unit was tested.  To see it boot was a relief...until I realized it had problems.  The squeal presented itself almost immediately, and a quick search of the Internet revealed that it wasn't unique to my device.  And that there wasn't a great solution.  The floppy drive issue came up when I decided to test it by popping in a floppy disk, and this led to the discovery of the rebooting issue when it had been on for a while.  The floppy disk got stuck in the drive, so I shut it down and ejected it manually with a paper clip.  When I turned it back on, it got all the way through booting to the desktop...and then suddenly rebooted.  After that, it wouldn't even get that far before it rebooted again.

One final thought: With all the problems this machine has, did the eBay seller lie?  Technically no, and even in spirit I don't think so.  As I indicated, when I first saw it boot, I thought it was working.  And according to his description, that's pretty much all he did.  He didn't test the floppy or run a stress test over hours to see how it would respond, but he also didn't pretend he'd done this.  When we buy an old computer off of eBay, we know we're taking a risk.  A seller might say he tested the computer, but unless he specifies that he fully tested and how he did so, then we have to assume we're getting at least a partially untested machine.  So I think the seller was honest in explaining how he tested and what he saw.  

I'll talk about how I resolved each of these issues in the next entry.

My iBook and Mac OS 9

So I'm back and working on some new retro projects.  I am blaming my long silence on kids, but things have changed such that I now should have a quite a bit more free time.  By "kids," I mean my god-children, specifically the twins Harmony and Trinity.  Some time ago they and their mother had moved out to live with her fiance (a very nice guy who is also great with the girls), but they were still attending the same school so as a consequence spent every other night with me.  So while they went to bed by 8, by that time I was generally too tired to do much of anything.  But now they're attending a school close to their new home, which is about 45 minutes away in clear traffic, so they come over here a lot less.

As much as I miss having the kids around, it does have the nice benefit that I have a great deal more free time, especially during the week.  So this weekend (the kids were at their father's for Easter) I tackled a few new projects.  On Friday I received a Macintosh Performa 430 I had purchased off of eBay; on Saturday I started putting together my RC2014 kit; and on Saturday I installed Mac OS 9 on an iBook that I had gotten several weeks ago but hadn't done anything with.  I'll talk about the first two projects in later posts, but I'll talk about the iBook now since it's the simplest.

I got the iBook off of eBay (the source of all vintage computers, at least for me) several weeks ago with the express purpose of using Mac OS 9 on it.  Why did I get it?  Well, I recently discovered the joys of cheap semi-old computers on eBay.  By "semi-old" I mean computers between 10-20 years old, not old enough to be considered truly "vintage" but not new either.  I bought a Dell Latitude D610, a 12-year old computer that I promptly upgraded to 2 GB of ram and the latest version of Lubuntu, a lighter Ubuntu distribution.  I also picked up a 12" G4 iBook with Max OS X 10.4 installed.  Both I got for under $50 including shipping.  The Dell I had specific plans to use for Node.js development, but I didn't really having any plans for the G4.  It was an impulse buy, pure and simple.  I didn't even have any great excitement over using an old version of Mac OS X.  I'm primarily a Mac OS X user, and 10.4 was the first version I used when I switched from the PC.  But I didn't have any great desire to jump back in time to 10.4.

Then a thought occurred to me: What about Mac Classic OS?  Prior to Mac OS X, I always eschewed Macs in favor of Windows.  There were many things I didn't like about the old Mac operating system.  I didn't know much about them honestly, but what I did know I didn't like.  I didn't like a single button mouse.  I didn't like the lack of true preemptive multitasking.  I didn't like the lack of a command-line.  Mac OS X solved all of these for me, with I guess the exception of the single-button mouse.  But then I learned about the Ctrl key, and Mac OS X (and maybe classic Mac OS did as well) supported multi-button mice just fine, so even that was resolved.

So anyway I decided to install Mac OS 9, since it is the last version of the classic operating system.  But then I discovered that my iBook didn't support OS 9, it could only run OS X.  Also the CD-ROM drive didn't work, so installing anything would be much more challenging.

So back to eBay where I found a 12" G3 iBook, and I confirmed beforehand that it did support Mac OS 9.  $50 and several days later, I had it in my hand.  I booted up the Mac OS X 10.4 that came on while I burned a Mac OS 9.2.1 iso image I found online.  But when I booted from the image and tried to install, it said it couldn't install on this computer.  Then I tried just Mac OS 9.0.4.  Same outcome.  Then System 8.6.  Same thing.  Finally after much searching I found out that Macs (at least classic Macs) are very tied to their particular version of the operating system.  On the PC side, you can install later version and even earlier versions of an operating system on any PC.  You can even boot into DOS on a modern computer!  But with the Mac, it has to be the version that the model shipped with or later.  My iBook shipped with 9.2.2 so it had to be that version and nothing earlier.  So I downloaded a 9.2.2 iso, but it actually had an install for 9.2.1 and an upgrade for to 9.2.2, not a direct install of 9.2.2.

I did some searching and found out about the Mac OS 9.2.2 Universal Install cd.  I downloaded this, followed the instructions, and they worked perfectly!  The final thing I did, after the OS was completed, was to upgrade the machine from 256 MB ram to 640 MB, which cost about $15 on eBay for the ram module.

But alas all was still not well in my Mac OS paradise.  My iBook has an AirPort card, but I don't seem able to connect to my WiFi.  I don't think it's the card though.  In the AirPort setup, it sees my network and says it connects, but then fails to find the DHCP server, saying that it can't check the status of the network.  My theory is that it doesn't support WPA2 security protocol, which wouldn't be surprising since it is quite old.  However, when I plug a network cable in, it sees the network just fine and I can get out to the internet.  Rockin' the Internet with IE 5.5! 😁

Still, not all is happiness and cupcakes.  I tried to connect the iBook to my iMac, running the latest Sierra, but the AFP protocols aren't compatible.  I tried a few things on the net, but nothing worked.  Finally I reverted to non-secure FTP.  I have a non-secure FTP server setup on my iMac to serve up files for my DOS machines (I can't use Sierra's built-in FTP server because it is secure, so DOS client can't connect to it), so I just fired it up, made a Macintosh directory, and the iBook could pull down files without a problem using Internet Explorer.  I even downloaded Fetch, a popular FTP client from back in the day.

But one small ray of sunshine in this otherwise cloudy day network incompatibility: My G4 iBook with Mac OS X 10.4 can connect to both the Mac OS 9 iBook and my iMac!  So I can use FTP to download from my iMac to the iBook, and on the rare circumstances that I need to go the other way, I can use the G4 iBook as an intermediary.  Why not just upload via ftp, you ask?  Because I can't figure out how to configure the ftp server I'm using to allow it.  I tried multiple times while playing around with my DOS machines, and finally just gave up.

So now I have a G3 laptop running Mac OS 9.  I installed Codewarrior Pro 7.1, so I hope to do some development for it.  But as I have other projects brewing at the same time, I don't know when I'll get back to this machine.

RC2016/10: Challenge proposal

I know I'm a little late on joining the Retrochallenge, but I've been dealing with the flu the past few days, so I haven't really had the energy or state of mind to write up my proposal.  But here I am, better late than never!

For this challenge, I'm going to try something different than my last few entries.  Instead of a programming challenge, I'm going to try for a bit more of a nostalgia trip.  For the month of October, I'm going on an extended flashback to the early 90's with DOS and Windows 3.1.  My original concept for this challenge was to only use DOS/Windows 3.1 for everything non-work related, but I quickly determined that just wasn't feasible.  The web is just too big a part of our lives now, and the lack of strong encryption and support for modern web standards makes a lot of it inaccessible.

So I'm going to take a middle road.  Although I'll still be using my iMac for my online surfing, I'm going to perform several specific tasks using DOS and/or Windows 3.1 and blog about those.  The tasks will be:

1. Manage my personal budget.  I currently do this in Google Sheets, but for the month I'll use some DOS or Windows-based program such as Excel or Quattro Pro.
2. Manage my weekly game with friends.  Once a week, I play a role-playing game named Champions with a group of friends.  I have two Java programs that I wrote that I use to help me run this game, so I'll come up with DOS or Windows replacements.
3. Computer games.  Even though my first computer was a Commodore 64 and I have fond memories of playing games on it, my greatest affection for old games really comes from the early DOS and Windows years.  Civilization 1 & 2, Colonization, Harpoon, and Doom, among others.
4. This blog!  While I won't be able to post it online using Windows, I'll author it on my DOS/Windows machine and then post it using my iMac.

So that's my challenge, to jump back 20 years digitally and see how much of my life I can manage using software that's 20+ years old!

CP/M on an emulator TRS-80 Model 4P

My TRS-80 Model 4P: You can't really see it but that's CP/M
running off of the FreHD that you also can't really se on top
of the machine.

So as I mentioned in my last blog post, I took an unplanned six-month rectrocomputing siesta.  I had only recently acquired a cool old-but-refurbished TRS-80 Model 4P with a FreHD (an SD-based hard drive emulator) that was already setup to book LS-DOS and CP/M.  Since I'd been wanting to play with CP/M, and I really like the TRS-80 Model 4P, this seemed like a perfect match.  But after some early frustration with trying to transfer CP/M software to the 4P, and with other things coming up IRL, I dropped retrocomputing for a while.

CP/M Emulation

So in my last post, I mentioned that I was kind of itching to do some software project, but due to my current situation, I was really looking for something emulated, not a physical machine.  My TRS-80 Model 4P immediately popped in my head, of course, but my last time I really had problems with emulators.  This was mostly because they wanted me to supply the ROM, but I still didn't have a way to exchange data between my 4P and my Mac.  Well, after some Internet digging (I swear I am the worst googler in the history of humanity), I finally found a working Model 4P ROM.  (Yes, I downloaded the ROM, even though it's copyrighted.  All I can offer is that you trust that I really do own the machine, as evidenced by the photo above.)

So with the 4P ROM in hand, digitally speaking, I tried out the TRS32 emulator first.  Although I'm a Mac person, I do have Windows running both in VMWare and in Boot Camp, so being a Windows-only program isn't necessarily a deal breaker.  And to be honest, it's a good program.  I had a few minor complaints with the interface, but overall it was very functional and easy to setup.  The only real issue I had is that it's shareware, costing $69 to register, and hard drive support was only included in the full version - something I knew I would want, since my 4P had FreHD.  Also, the guy does TRSTools for free, which is a nice little program to read/write TRS-80 floppy disk images.  I'm not opposed to paying for software, and his gift of TRSTools to the community made me even more interested in throwing him some cash, but $70 for an emulator seemed steep to me.

Then I found SDLTRS, an open source cross-platform emulator based on xtrs, an X-Windows emulator.  It is open source, and seems to do everything the full version of TRS32 does, including hard drive support.  The Windows and Linux interfaces are a bit spartan, but the Mac interface is pretty nice, though I wish the Mac supported the same keyboard shortcuts the Windows version does and was a little less mouse-driven.  In any case, it was as easy to get up and running as TRS32 was, and seemed every bit as functional.  So it became an easy choice, and so far I haven't regretted picking SDLTRS over TRS32.

Getting CP/M Running

As you might guess, this was basically just grabbing a disk image, popping it into the virtual floppy drive in SDLTRS, and booting up the VM.  But which CP/M?  There are several for the 4P, the two most common being CP/M Plus and Montezuma Micro's CP/M.  CP/M Plus was limited to CP/M 3.0, and since I already knew I was going with CP/M 2.2, that left only Montezuma's CP/M.  Here's where I got my CP/M image, and in fact most of the CP/M software that I downloaded.

Now before you hop out to that site and start downloading everything like I did, you may want to pause a bit to avoid some mistakes I made.  First, you don't need every CP/M boot disk that's out there.  I just got the last of the Montezuma Micro CP/M boot disks, and that's what I used.  Second, disks will be labeled as either of type COM, DSK, or DMK.  COM means that it's actually going to come as a binary program, not a disk image, so you'll need to copy it to a disk image to run it.  There are two ways to do this, which I'll discuss below.  DSK and DMK are two virtual disk image formats, so either of these are potentially usable in SDLTRS.  However, while SDLTRS does support DMK, I noticed that a lot of them were larger than the 166k floppy drives that the emulated machine supported, so it was hit-or-miss as to whether these worked out of the box.  All the DSK's I downloaded worked without an issue, though, so if something comes in multiple formats, always pick the DSK.  If it does come in DMK only, all is not lost.  It may very well work, so go ahead and try it.  But if it doesn't. the DMK will probably work in TRSTools, so you can copy the files to a temporary directory, then open a blank DSK and copy the files to that.  The DMK may be a larger size than the DSK, so you may have to pick which files you don't need or copy them to multiple DSK images.  I had to do this with the Hard Disk Drivers disk, which was larger than a DSK.  I put the executables on one DSK and the docs on another.  (I'll talk about setting up the hard drive in my next blog post, but at this point, just make sure to grab that disk image.)

Incidentally, I mention using a blank DSK above, but I didn't originally have a blank DSK image.  SDLTRS Floppy Management tools does allow you to create a blank floppy, but I couldn't get these to load once I'd created them, so after a few failed attempts, I gave up with that.  Now TRSTools does say it supports the Montezuma Micro disk format, which it does seem to, but I couldn't see how to create a usable disk image with it.  To get around that, I just made a copy of one of my working DSK image files, opened it in TRSTools, removed all the files, and made sure it was not flagged as write protected.  Then I just renamed it blank.dsk and would just make a copy of this every time I needed a blank floppy.

Now I mentioned above that some software will come as files instead of on DSK or DMK images.  On the download page above I referenced, Zork I could only be downloaded this way, and the first copy of Turbo Pascal 3 I found on another page came as a zip of files.  There are two ways to deal with this.  The first is to use the cpmutils, which is a set of utilities written for xtrs, the base of the SDLTRS emulator, while other way is to use a blank disk image and add them using TRSTools.  

In the SDLTRS distribution is a subdirectory called diskimages, with a disk image called cpmutils.dsk.  Now, annoyingly, this disk image didn't load for me in MM CP/M, but I used TRSTools to copy the files to a usable blank disk image (you can download the result of this here, if you don't want to do this yourself).  This has a bunch of files on it, but the three COM files are EXPORT, IMPORT, and XTRS.  These are special CP/M programs that take advantage of hooks in the emulator to be able to transfer files to and from the local filesystem.  So, for example, to make a disk image for Zork I, all you'd have to do is download the ZORK1.COM file, copy a blank disk image, and then type IMPORT ZORK1.COM ZORK1.COM.  This works in that you don't get any errors, and something is copied, but when I tried to execute ZORK1, it gave me weird, inconsistent results.  (This was after also copying ZORK1.DAT, which you need as well).  When I then used TRSTools to copy the files to a disk image, this worked, so I have to conclude there's some issue with the IMPORT.  If anyone has any clue, please leave a comment.  I should mention, btw, that I did use EXPORT several times successfully, though I wasn't copying any COM files, only text files.

It's too bad that I couldn't get the IMPORT working though.  TRSTools is nice, but as I'm a Mac user, it's a tad of a pain to use.  I use VMWare Fusion to run Windows on my Mac, but I don't usually have that running, and having to switch to the Windows desktop (I don't run the unified desktop because that annoys me too) when I want to use TRSTools bugs me.  But I keep disk images I'm working on in my shared folder between the Mac and Windows VM and that makes it easier.

Building a 4-Drive System

So now that you have a working CP/M system booting off floppy, and a way to transfer files, the last thing I'll mention is about changing your emulated system to a 4-drive system instead of the default 2-drive.  Now as I mentioned in my last blog, I am not very familiar with CP/M, and certainly not familiar with Montezuma CP/M.  So there may be a better way of trying to accomplish what I did.  If so, please let me know in the comments.  But this is what I had to do to get things to work so I could load up disks in four virtual drives.

BTW, if you haven't done so yet, make a copy of the CP/M boot disk image you're going to use.  Also make sure you're working image is not write protected.  This is set in the image file itself, not by the base operating system.  You'll know if it loads in SDLTRS and when you look at the floppy management screen and it has an asterisk beside it.  I didn't see any way to uncheck this in the Windows version, though in the Mac version you can unlock it.  For Windows, you can use TRSTools and just go into Disk Properties under the File menu.

Boot up CP/M and run CONFIG and you'll see the following menu:

Select F for Disk drive definitions and you'll see:

Select 'C' and enter 4 when it asks, "How many drives?"  That should bring you back to the same screen, but showing 4 physical drives instead of 2.  His the ESC key (in SDLTRS, ESC is mapped to the BREAK key and Shift-up arrow is mapped to TRS-80's ESC), and you'll be back at the main menu shown above.

Go ahead and hit 'G' at this point, which will take you to the Disk format definitions menu:

Now you'll notice that you do have four drives defined, A - D, but A and C seem mapped to the same drive, device 0, and B and D to the same device 1.  Now someone who knows more about CP/M may understand this and how to work with this, but for me it just meant I couldn't get and disk images to read correctly in C and D.  So if you're following what I did, select 'C' and you'll see:

The first two options match our new 4-drive disk definitions, but the two DATA format drives don't seem to work, so I set the C and D drives to 'A' to match the two drives that do work.  

Once you've done all that, use ESC to get back to the main menu, and then SAVE THE CONFIG!  It the 'H' option on the main menu.  It's easy to just jump all the way back and forget this; I did it several times.

At that point, hit F10 to reboot and you have a 4-floppy drive system.

In my next post, I'll go through setting up a hard drive for my emulated system.

Running silent

As I'm sure no one has noticed, I haven't posted in a while.  I would like to say that I've been so busy with retrocomputing projects that I just haven't had time to post, but the truth would actually be the opposite.  I haven't done anything with retrocomputing for the last four to six months, so I just haven't had anything to post.  There were a number of reasons for me going silent.  My living situation has been in a bit of an upheaval during this time.  I've been sick several times, and my overall energy level has been down (which, for me, is saying quite a bit, since I'm not normally what one would think of energetic in the first place).  And, honestly, I just haven't really been inspired to do anything with retrocomputers.

That started to change about two weeks ago, when I started getting a hankering to do some sort of software project.  I looked around for several things, and started working on a cloud-based web project, until that pissed me off and really sucked away all my interest.  Several other ideas also occurred to me, but finally I decided to come back to the platform I was just getting into when I stopped retrocomputing, the TRS-80 Model 4P.  More specifically, CP/M on the Model 4P.

The Road to CP/M

I used CP/M only briefly back in the day.  When I was a senior in high school, I took a few classes at the local community college, including an introduction to computers which featured CP/M.  I believe they used DEC Rainbows, though I'm fuzzier on that so I could easily be wrong.  But I very clearly remember the cover to the book we used, The CP/M Handbook.  That was it, one semester in one class, and I never used CP/M again.  But being a computer history buff, I read a great deal about CP/M and Gary Kildall and always had a great respect for the man and his contribution to computers.

Before my break, I decided I wanted to explore the world of CP/M, specifically I wanted to do some programming with early Turbo Pascal.  I bought a Kaypro II, but that had a bad second floppy, and Kaypro's CP/M was really built for a two-floppy system.  So I bought a second Kaypro II, which did have two good floppies, though the first one was very slow to load anything.  Also it didn't have the little kickstand that my first Kaypro had, and that bugged me much more than it should have.  So I had the bright idea of putting the good drive from the second machine into the first machine.  I was defeated by two rusted screws, after trying everything I could think of.  The two Kaypro's sit, still disassembled, just a few feet from where I write this, mocking and taunting me.

The Model 4P: A Great CP/M Machine or the Greatest CP/M Machine?

I had read somewhere that the TRS-80 Model 4/4P was an excellent CP/M machine, and I found a nice sale on eBay.  It wasn't the cheapest unit, but the person had cleaned the inside and outside of it, guaranteed that the unit worked, and also included a FreHD unit (a hard drive simulator for the TRS-80 computers using an SD drive, for those who don't know) with the ROM upgraded to take full advantage of it.  As I said, it wasn't the cheapest deal, but just having someone who seemed knowledgeable attest that it is completely functional is worth some extra cash, to those who have experience buying retro computers on eBay.  It even had the latest LSDOS and CP/M as bootable hard disk images on the SD card.  And, sure enough, when I got it it booted up very nicely into both OS's.  The only problem was that while the LSDOS image had a lot of software, the CP/M included the base OS and that was it.  

Well, that's no big deal, thought I.  I can find tons of CP/M software on the net, and I'll just load that up.  Of course, the 4P only has 5.25" drives, and none of my modern machines has a 5.25" drive, so "sneaker net" is out.  Of course, I thought about transferring it through a serial connection, but I couldn't get that to work.  And I couldn't figure out how to transfer anything to the hard drive images on the SD card.  FreHD is a cool device, but the documentation leaves much to be desired.

That's pretty much where I left it, when I began my unplanned, months-long absence from retrocomputing.

In my next post (hopefully within a day or two), I'll follow up with what I'm up to now and what I plan to do.

My newest acquisition and newest project

Early last month I ordered a 6502 single board computer off of eBay, and it finally got here yesterday.  It was designed and built by Wichit Sirichote, who lives in Thailand, which is why it took so long to get here.  I've been playing with it a little bit and so far it looks like it works exactly as advertised, and I'm hoping to really dive pretty deep into this machine.

If you check out the guy's web page, at the bottom he links to two PDF documents that go along with this system.  The user manual explains how to operate the machine and presents some technical information, while the second document gives 10 sample programs to help learn about the machine.  I spent last night manually typing in the hex form of the programs, which was fun, but by program 9 they were getting big enough that this was getting annoying.  The keyboard is just a bunch of soft buttons with a sheet of some kind of sticker paper on top, so it's really about as good as a membrane keyboard.  So it's good enough for playing around, but it really isn't good for any real programming.

So today I actually figured out how to upload a program.  This wasn't difficult; the user manual explained the process well enough.  But the computer expects the uploaded file to be in Intel or MOS hex file format.  I wasn't familiar with either of these, but a quick Google search turned up what I needed to know.  Both are a text file format to encode binary data in hexadecimal form.  They're very similar formats, differing only slightly.

Here's an example of the Intel hex file format of a simple program from the book that I ran through the assembler:

    :0E020000A9008500A5008D0080E6004C0402D8
    :00000001FF

The format is actually pretty simple once you break it down.  If you're curious I recommend checking out the Intel HEX Wikipedia entry.  The above, however, is just 14 bytes that are loaded into memory at address $0200 (hexadecimal value, or 512 in base-10); the second line is the end-of-file record.  As I said, the MOS hex file format is very similar.  The only difference is that it starts with a ';' instead of a ':', and the record type (the fourth byte, with each two characters comprising one byte) isn't there.  Also the end-of-file line has a slightly different format.

Now the webpage for this kit includes a download with the TASM assembler, which is an older shareware assembler that, as near as I can tell, isn't available for sale anymore.  But the problem is, I think it's a 16-bit DOS app.  When I run it under Windows 7, it says it's incompatible.  I did run it under DOS in VMWare and got a simple little program to compile, but obviously this isn't a long-term solution.  By the way, the irony that a DOS-based assembler is not usable for a guy who's into retro computers (including DOS-based machines) is not lost on me.  All I can say is that I would be happy to do the development in DOS except for two things: I don't have a serial port to upload the program available in my DOS environment (VirtualBox under Mac); and it would just be clunky to have to transfer my program from DOS to an environment where I could upload the program.

With TASM eliminated, I'd really like to use a modern assembler, something that is cross-platform and still supported.  I looked and didn't find any 6502 cross-assemblers that would directly output Intel hex file, so I decided I'll just have to convert my assembled program into Intel hex as a second step in my build, which means I can use any assembler.  So which one?  I've used the assembler with cc65 before, but I wasn't thrilled with it.  cc65 is great for C programming, but less great for assembler, though it's a completely functional assembler.  I looked at several, and decided to try KickAssembler.

Now as a 6502 assembler, KickAssembler seems very C64 oriented, especially since it only generates either a simple binary file or a C64 compatible PRG file.  But for my purposes the PRG should actually do nicely.  It's about as simple a format as one could imagine.  The first two bytes indicates the starting address; the rest is just the raw binary.  I searched for a utility to convert a binary to Intel hex, but didn't find one I liked, so I decided to write one myself.  So the PRG really does work very well, since it contains all the information I need and nothing more.

So what are my plans with this little board?  Here's a rough projection of what I'd like to do (though given my record of being distracted, it's not likely I'll actually finish all this):

1. Write bin2ihex
2. Build an emulator using C and Qt (emulators are so much easier for testing/debugging)
3. Write a new monitor that uses the serial port

That's obviously a good bit of work, especially the new monitor.  I would like to do an interpreted environment like BASIC, but not BASIC as I'm not really a fan of that language.  Maybe Forth or else some other simple language.  

I'll keep posting as I progress.

Eulogy for a retrochallenge

If you've been following my retrochallenge at all, then you have come to one of two conclusions: Either I'm making progress but not blogging about it, or I'm just no making progress.  Unfortunately it was the latter, not the former.  My last blog earlier this month discussed all the progress I had made: I developed my tool chain and created a Makefile that automated the build process and would be flexible as the project grew.  But this turned out to be pointless since my project never grew.

Why didn't the project go anywhere?  Well, there are a lot of reasons.  I was unexpectedly busy at work, so I didn't have quite as much free time as I normally would.  But more significantly, being so busy at work just left me less motivated to program on my own, since programming is what I do professionally.

Another reason is that, although I had a full LMweek off from work and the family was gone, this turned out to offer me less free time than I had anticipated.  My hobby stuff, including all my retro stuff, was crammed into my "man cave" upstairs in the house, but some rearrangements meant that I could take over the office down below, so I spent part of my free week moving my stuff into my new digs.  This is a big improvement for me, because it allows me to setup two or three retro systems at one time, whereas before I was really limited to only one or maybe two if the second one didn't take up much space.  And I still have my "man cave" which will now become my ham shack (as in ham radio, not pork).

Which leads me into my third reason: Distractions!  Early in the month I purchased a 6502 SBC, so I got distracted by that.  Then @Retrochallenge started tweeting about his ham radio activities, and that inspired me to get back into that hobby.  And even just recently, I purchased a Kaypro 2000.  Although this hasn't arrived yet, I started looking into this system as well.  So basically I lost focus early on and just never really got back to my project.

This is my second retrochallenge, and so far I'm 0 for 2 in terms of completing my project.  But even though I didn't complete last year's either, I felt a lot better about that.  My project involved a lot of reading and learning of the PDP-8 and OS/8, which turned out to take a lot more time than I had expected.  So even though I didn't finish, I learned a lot and felt like I had accomplished a lot.  This time, though, was almost a complete bust.  I did relearn a bit of the xBase platform, and the project skeleton I made for kBase will be usable for future cc65 projects, whether they be for the Apple II or for other 6502 platforms.  I also got a copy of Tom Raidna's TUI library, which I think will be useful for future projects.  So I do feel like I at least gave myself a bit of a step up for future projects, but I definitely didn't really accomplish much.  So I feel pretty unsatisfied with my work this month.

So is this the end for kBase?  Honestly I don't know.  I still like the idea of the project, but I just don't have the motivation to work on it right now.  There are just too many other things I'm playing with at the moment.  And this is a hobby, not work.  But I can't predict what ideas will grab me in the future, and I enjoy working on interpreters, so there's every possibility that I'll come back to this project.  Maybe just in time for Retrochallenge 16/07!

RC 2016/01: My development tools, part 2

In my last post, I talked about some of the tools I would use - specifically cc65 and AppleCommander.  But at the time of that post, I hadn't actually done any development yet.  Now I have, though admittedly I still haven't gotten very much done.  I have refined the build process that I used with other cc65 projects so that it's a bit more logical and flexible, and I've incorporated a library from one of my Retrochallenge "competitors"; more on that below.  Nevertheless, I still have a lot of work to go and it's already 12 days into January.  I knew the first half of the month would be slow going, given everything else I have going on, but I've made even less progress than I'd expected.  I'm hoping I can catch up during the second half of this month.

If you're interested in taking a look, check out the repository on Github: https://github.com/hculpan/kbase.  Note that if you build and run it, it's actually a slightly modified version of the A2 CARDIAC program (see my Prepping for the Challenge post for more information on this).  Obviously this will change, but I just wanted some code to test out my build process.

In this post, I'll talk about my build tool, editor, and emulators that I am using.

Make

For my build tool, I went with the Make utility.  There are almost certainly better tools out there for C development, but honestly I'm reasonably familiar with Make so it's just easy for me to use.  I also like that it makes no assumptions and I'm in complete control of what build targets are available, what commands get executed, etc.  In my professional life as a Java developer, I use Maven, which really does most of the work for you.  I'm happy with that build tool, but it can be a pain when you want it to do something that it doesn't want to do.  But with Make there are no such issues; it does only what I tell it to do and nothing more.  For a larger project, like those I work on in my job, this could be bad and hard to manager, but for a small project like kBase, this is much easier.

Of course, with Linux you almost certainly already have Make installed, and on Mac OS X, it gets installed when you install Apple's command line development tools (see cc65 above).  With Windows, though, it's a bit more of an issue.  My solution is Cygwin, which is one of the first things I install on any Windows machine anyway.  If you don't want to install Cygwin, there is MinGW.  Otherwise, I'm not really sure how to get Make on Windows, but that's just because I don't generally do C/C++ on Windows, and when I do I happily use the Cygwin tools.  There are also other newer cross-platform build tools, but since I'm happy with Make, I haven't really investigated alternatives.

Atom editor

For code editing, I use the relatively new Atom editor.  Overall I like the editor, but honestly it's two best features for me are that it's cross-platform and that it can be launched from the command line.  This last is a rare feature among editors, and for a command line guy like me, a welcome one.  I can type "atom ." at the command line (and I always have a command prompt open), and it will open with all the files in the current directory listed in the left panel, ready for me to select.  It's almost like having a project manager built into the tool without having all the constraints of a full-blown IDE.  Otherwise, I just use it as a text editor.  I haven't installed any plugins to launch builds from my editor or anything else.  It does have C and Makefile syntax highlighting built in, which is nice.

One way I think I'm different than many other developers is that I'm actually pretty neutral about my editor.  I can use anything from Vi to a full IDE without too much complaint, as long as it's not Emacs.  During my last Retrochallenge, I even began to like TECO, the PDP-8 editor, so really I'm pretty flexible when it comes to my editor.  As a side note, it is a little ironic that I hate Emacs but like TECO, since Emacs actually started as a set of macros for TECO.

Emulators

As I've said, I'm doing development on both Mac and Windows, and this is the one category of tools that I really couldn't find a good cross-platform solution.  However, there are good emulators for both platforms, and I chose probably the two most obvious choices, AppleWin for Windows and Virtual II for Mac.  They are both good emulators and both do what I need, at least so far.  But honestly most any emulator would probably do what I need.  The only issues I would be likely to run into would be printer support and extended memory, since I'm pretty certain I won't be implementing dBase III+ in 64k.

Having said all that, I will say that Virtual II may be the best emulator I've used for any platform so far, and it is the only one that I paid for (the others all being open source, not that I've been using them illegally).  Honestly, I haven't used much of its advanced features, but it comes the closest of any emulator to really feeling like a real retro computer.  Overall I love the interface, and I love the sounds it uses to simulate a real disk drive.  So if you're looking for an Apple IIe emulator for Mac OS X, I would recommend you give it a try.

The Real Hardware

The final tools I wanted to mention are the actual hardware that kBase will be running on.  That will be primarily an Apple IIgs with 4 MB of ram, both 5.25" and 3.5" floppy drives, and a Classic IDE for Apple II emulator my hard drives (though I have a CFFA3000 on order).  Obviously I usually run GS/OS, but for this project I'll be using it as a standard Apple II.  I also have an Apple IIc with 512k ram, which is usually packed up but will also be used as another test platform for this project.

TUI Library

Finally, I wanted to mention that Tom Raidna (@TRaidnaComputes on Twitter, blog at https://traidna.wordpress.com/) nicely offered to share his project with me, since we're both working with cc65 and I will need a text interface for kBase.  His project, Retro C IDE, is going to allow you to layout a text-based interface and then generate the C code for that interface from his Windows-based application.  Now since it is Windows-based, that's less useful for me, but as it turns out he's generating code for his TUI Library that he had earlier developed - and this library is definitely of use to me.  So he has shared this library with me, which I hope will simplify my efforts to develop the interface for kBase.  So kudos to Tom!

Next Steps

Hopefully in my next blog post, I'll be able to report some actual progress with kBase.  First, I'll build the basic user interface (the "." prompt) and a simple parser to interpret commands.  After that, I'll hopefully be at a point where I can read a dBase database file.

RC 2016/01: My development tools, part 1

In my first blog of this retrochallange, prior to the start of the actual challenge itself, I talked about what tools I'll be using to develop kBase for the Apple IIe/IIc platform.  I haven't actually started coding my challenge yet, as this has been a busy week.  I'm hoping I'll be able to start this weekend.

I have done a "practice" project (discussed in my prior post) to refine my dev tool chain and tackle some technical issues.  With that accomplished, I wanted to take some time to discuss my development tools in more detail, so that people who were interested in C development for the Apple II might have a bit of a head start.  Or at least they could look at my project and know what NOT to do... :)

This is the first of two posts on this topic.  Here I'll discuss cc65 and AppleCommander.  In the next, I'll talk about my build tool, editor, and the emulators I'll be using.

First, a quick note about my development platform: I will be primarily working in Mac OS, so my tools will need to be Mac compatible.  However, I will at times be working in Windows as well, so I will need tools that are either cross-platform or platform-specific equivalents.  As it turned out, pretty much everything I use is available for both platforms, with the exception of the emulator I use for testing.  But there are good emulators for Apple II available on both Windows and the Mac, so that wasn't an issue.

cc65

The first major thing to discuss is the C compiler I'll be using, cc65.  This tool, which includes a C compiler, assembler, and a linker, runs on most modern operating systems.  I personally use it on both Mac OS X and Windows, and it will build on Linux and pretty much any Unix machine out of the box.  For Windows and Linux, this Getting Started page will tell you what to do.  For Mac OS X, it's essentially the same, but there is an additional step if you haven't already installed Apple's dev tools, as discussed here.  No matter your OS, it's really pretty simple to get cc65 installed and working.

I'm still learning my way around cc65.  It is has a lot of features, so despite my having done several small projects in it, I still feel like I don't know it very well.  For now, I'm pretty much just using the default configuration and standard features, but as kBase grows that will most likely change.  So you'll probably hear a lot more about cc65 as time goes on.

AppleCommander

For building Apple II disk images, there are a number of tools, but the gold standard seems to be CiderPress.  While it's a great tool that I've used for a number of things, it has two problems when used for development.  First, it's Windows only, which is a problem if you're not developing on Windows - and I'm not.  Second, it's gui-driven, not command-line-driven, so it's hard to automate.

For development, especially with cc65, AppleCommander is really superior.  It's functionality is accessible using the command-line, and it even has a special option for cc65 programs.  A general tutorial on AppleCommander is certainly beyond the scope of this post, but I will outline how I'm using it.

One small issue that I ran into resulted from the fact that AppleCommander comes bundled as one jar without any installation utility.  Since I do work on several different machines (2 Macs and 1 Windows), managing the location of this became something of a small headache.  Since the jar file itself is less than 500k in size, which by today's standards is pretty small, my solution was to actually include it in my source branch in the root directory, so I always know where it is no matter which machine I'm on.  When I clone it from Github, it will just be there; it's one less external dependency I have to worry about.

Initially, I had AppleCommander creating blank 140k disk images that I then loaded my binary on to, but for some reason the AppleWin emulator didn't want to read these disk images.  My workaround was to use the emulator to create a blank disk image, and then I just copy the files I need onto it every time I do a build.  I created a sub-directory called "prodos-raw" where I put the blank disk image.  Using AppleCommander I also extracted binary copies of BASIC.SYSTEM and PRODOS, which I also put in the prodos-raw subdirectory.  So when I create my application's disk image, I copy the blank disk image to my build directory, copy PRODOS and BASIC.SYSTEM on to it, and then finally copy my application's binary file.  I can then just boot this disk image in the emulator and load my application.  This is, of course, done in my automated build process, so I don't actually do any of this except testing it in the emulator.

To build my kBase disk:
cp prodos-raw/blank.po ./kbase.po
java -jar AppleCommander-1.3.5.13.jar -p kbase.po PRODOS SYS < prodos-raw/PRODOS
java -jar AppleCommander-1.3.5.13.jar -p kbase.po BASIC.SYSTEM SYS < prodos-raw/BASIC.SYSTEM

The above assumes that the AC jar is in the current directory, which for my project it will be, as I discussed above.  Also the two files being copied, PRODOS and BASIC.SYSTEM, are specified as type SYS, not BIN.  Another little oddity to AC is that when copying a file onto a disk from the command line, you actually pipe it in from stdin; you don't specify the local file name.  The -p (for put) is what tells AC to put the file on the disk image from stdin.

Then to copy my binary to the disk image:

java -jar AppleCommander-1.3.5.13.jar -d kbase.po kbase

java -jar AppleCommander-1.3.5.13.jar -cc65 kbase.po kbase BIN < kbase

The first command removes the existing kbase binary on the disk image, if there is one; it does nothing if it's not there.  In my Makefile, I only create the disk image if it doesn't already exist, so the same disk image is reused many times during development unless I do a clean.  Unfortunately, AC's put command won't overwrite an existing file, so you have to do this first if the file may already exist.  The second command is what actually copies the newly built binary onto the disk image.  It's the same as a put command, but instead uses the -cc65 command instead of -p.  I'll be honest, I don't completely understand what impact this has, though the AC help does have some information.  I just don't understand the format of ProDos and cc65 binaries enough to know exactly what it means.

One final thing to note, if you're not familiar with AppleCommander, is that it is a Java application, so you will need to have Java installed.  The web page says the minimum Java is 1.4.2, but if you're using that old of a version, you desperately need to upgrade.  I run it using Java 8 and it runs fine, so no reason not to use the latest and greatest.

To be continued...

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.