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.