This is part one of my Retrochallenge 2016/10 journal, where I’m working towards loading ROM images to an Intellivision from an Atari 800. To jump to the very beginning, click here.

Getting Started

Here we are 13 days into this Retrochallenge. Traveling out-of-state to visit family in the first weekend and doing minor home renovations on the second weekend has my project started flat-footed. And the usual “I need to work on my Retrochallenge” is losing its Force-like magic of persuasion. On top of that, everything I’ve done so far seems tangential to the real goal of transferring Intv binary files from an Atari 800 to an Intellicart! cartridge emulator connected to a Mattel Intellivision.

But here’s what I’ve been up to:

1. Evaluating which DOS to use on the Atari 800
2. Solve a DRIVE NUMBER ERROR message
3. Deciding which emulator to use on my Linux laptop for initial development
4. Creating the most convoluted cross-compiling development system possible
5. Learning a little about the Action! programming language
6. Pulling together the required code for the Action! Window Gadget library

I’ll cover those first two items in this journal entry.

Pick a DOS

There’s no shortage of Disk Operating Systems for the Atari home computers. Even though I used Atari DOS 2.5 and MyDOS4 throughout my Atari 8-bit days, after a lifetime of using Unix and MS-DOS, I find the old menu-based operating systems painful. I’d prefer a command-line DOS.

The serious Atari hackers use SpartaDOS X, but I don’t think it’s a good fit for this project. One variation of it requires a cartridge, but I’ll be using the cartridge port for the Action! language supercart. And with all its features, I’m doubtful it works as well on the 48K Atari 800 as it does on, say, a 128k Atari 130XE.

For a previous project, I used SpartaDOS’s more 48K-friendly distant cousin, BeweDOS v1.30. This is what I had planned on using at the beginning of the month. However, it uses a SpartaDOS-compatible disk structure that departs from the standard Atari DOS 2.0s format expected by some disk image tools I may use. In the end, I did find it can access Atari DOS 2.0s files via its menu interface, but not the command line. I admit I am enamored by seeing its time-stamps applied to files. While I don’t have a physical R-Time 8 clock cartridge, emulators emulate it.

But, really, since I’m using Action!, a programming system published by Optimized System Software, it seems fitting that I should use one of the disk operating systems released by the same small company of brilliant developers. Besides the original menu-driven Atari DOS which they created on Atari’s behalf, they later released their own command-line operating systems OS/A+ ver 2, OS/A+ ver 4, and DOS XL. My heart was set on using OS/A+ ver 4, for which I have a bona fide physical floppy and user manual. Unlike DOS XL, it hails more from the 48k Atari 800-era and represents a courageous attempt to start with a clean slate and push the Atari platform forward. For example, the authors envisioned being able to exchange data files between Atari and Apple II computers from the same floppy disk. But I’ve been unable to successfully modify its drive table to enable multiple disk drives. (It’s supposed to be updated by running “CONFIG” and then “@WRITESYS” but this hasn’t worked for me).

So, with a mild bit of reluctance, I’ve opted to go with OSS’s Warp DOS XL ver 2.42w, for which I also have a physical copy and manual. In fact, I don’t think this version exists in the normal software archival sites. My documentation’s title page states it’s version 2.30 which *is* archived. I think this “Warp” version takes advantage of Atari 1050 floppy drives with the “Happy” ROM enhancement. (Hm. I see the Atarimax store still sells “Happy” upgrades and my 1050 is now unhappy).

Fix a DOS

The Atari home computer supports up to 8 floppy drives (D1 thru D8 – which would be an awesome sight to behold). So when using DOS XL, I was perplexed why I was receiving a “DRIVE NUMBER ERROR” when trying to access any devices after D2 (as shown in the image above). I was getting the same error when experimenting with OS/A+ version 2 and 4. My first RTFM moment had arrived.

Turns out DOS XL and OS/A+ ver 2 have a system variable called DRVBYT at address $070A that enables or disables D1 through D8. (OS/A+ ver 4 has a more complex data structure.) DRVBYT is a bitfield with the least significant bit representing D1 and on up through the most significant bit representing D8. If a bit is set, then the corresponding floppy drive is enabled. The default is $03 (D1 & D2 enabled) and is set when the file DOS.SYS is loaded into memory. To change the default requires modifying DRVBYT in RAM and dumping a region of RAM back to the file DOS.SYS. This task sounded a bit more onerous than it turned out to be. But it gave me a chance to do a little Action! and DOS XL work.

Tasks to set DRVBYT in DOS XL:

1. Write a short Action! program to modify the memory location and run it.
2. Un-protect DOS.SYS so we can overwrite it.
3. Run the DOS XL “Init” tool and write a DOS.SYS file only
4. Protect DOS.SYS

Action! Program to Modify DRVBYT

Action!’s variable declaration is counter-intuitive to what I’m used to. In Action! you define the variable name on the left side of the assignment operator (okay, I’m good with that). On the right side, you define it’s storage address, not its value (okay, that’s weird – but cool). The same task could’ve been accomplished using Action!’s immediate mode, but this is more fun.

Here’s the code.

And the results. Nothing surprising.

Update DOS.SYS

Remove the write protection from DOS.SYS and run the DOS XL INIT tool.

Write out a new DOS.SYS file from memory.

Re-Protect DOS.SYS

Don’t forget to re-apply protection to DOS.SYS. Write protection is signified by the leading asterisk in a directory listing.

Fixed DOS

And now I can access D3 (and D4).

D3 (and D4) now are enabled – yea!

Up Next

I need to capture the serial output of the Intellicart! data transfer.