Saturday, January 30, 2016

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!

Tuesday, January 12, 2016

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:  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.


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.


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 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.

Thursday, January 7, 2016

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.


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.


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- -p kbase.po PRODOS SYS < prodos-raw/PRODOS
java -jar AppleCommander- -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- -d kbase.po kbase
java -jar AppleCommander- -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...