I’ve been spending some time porting EmuTOS, an open source version of Atari TOS, to the AlphaSmart Dana portable laptop word processor typewriter thing. It runs really well, and will run (some) original Atari ST software. And, I’ve done it all on video! It’s about 38 hours of me talking about code.
TOS is a simple but elegant single-tasking operating system for the 68000. The kernel’s got about the same sort of functionality as MS-DOS but it’s got dramatically improved graphical capabilities (that is, it’s got graphical capabilities) and there’s a standard GUI called GEM. Yes, it’s the same GEM that you could get on the PC, except TOS’s version is in ROM.
The Dana, meanwhile, is a laptop electronic typewriter thing (it’s part of a style of portable computer which doesn’t really have a good name) from 2002. It’s a 32MHz DragonBall VZ 68000-based computer with either 8MB or 16MB of RAM depending on model, a 560x160 black-and-white touch screen, a full sized keyboard and two (two!) SD card slots. It’s also got IrDA, USB host and device, and some versions have wifi, although it’s not new enough to do WPA and is therefore pretty useless. Natively it runs a modified version of PalmOS which works beautifully on the big screen.
PalmOS is extremely quirky, and one of those quirks is that it likes to keep all of its state in RAM. This means that if the power goes out you lose all your data. The version the Dana has does allow you to put some state on the SD card but it’s still annoying whenever the battery goes flat. So, when I discovered that the DragonBall VZ has a hard-wired debug port which allows you to control the processor via a serial link bypassing the ROM completely, I realised that this would be a good candidate for an alternative operating system. I decided on EmuTOS because I’ve always rather liked GEM and it looked cool.
You can find it on GitHub. It hasn’t been upstreamed yet.
There is some brief documentation. The short version is that you’ll need to prepare two SD cards, one for PalmOS and one for EmuTOS; the PalmOS one needs to have the EmuTOS kernel and a bootstrap tool called DanaRun on it. Then, power on the Dana, run the tool, and EmuTOS will boot.
Be aware that:
the Dana’s RAM will be wiped (of course). So you’ll lose any documents that PalmOS has stored.
there is now power control or battery management. The Dana hardware has no switch, so the only way to turn off the machine once EmuTOS is running is to remove the battery and pull the plug.
in fact, I would strongly suggest that you always run EmuTOS with the battery removed and run the Dana off mains power via the USB or charger port. If the battery controller is misprogrammed there is a faint but non-zero possibility of damaging the battery, or even causing a fire. I have no experience in this area.
You will also need to calibrate the touchscreen before it’s usable. The EmuTOS source repository has a tool in it called DanaCal. Compile this with your favourite Atari TOS toolchain, put it on the EmuTOS SD card, and then run it on the Dana. It’ll prompt you to touch the screen in three places. After this is done, with luck, it should work.
- my touchscreen is broken, and I could only do minimal testing here…
⇡Using it in practice
Currently EmuTOS is in a pretty alpha state and is riddled with bugs. You probably won’t want to do real work on it. That said, it hasn’t actually crashed on me very much.
The biggest problem is that there’s not very much Atari ST software which will run on it, because:
it’s not an Atari ST and a lot of old school software tries to talk to Atari ST hardware directly… which isn’t there
the screen is too small.
The last is the worst issue. Productivity software on the Atari ST tended to require a 640-pixel wide screen to allow 80 column text. The Dana only has a 560-pixel screen, so this software complains. Also, the minimum height of an Atari ST screen is 200 pixels, and the Dana’s screen is 160 pixels high, so even the software which does run tends to be a bit problematic. First Word Plus, for example, makes its window too big to fit, and the resize controls are off the edge of the screen and are inaccessible.
⇡Accessing the debug port
It seems that AlphaSmart have done the sensible thing and exposed the DragonBall VZ debug port internally as unpopulated pads. Soldering wires on is straightforward and that gives you everything you need for access (see video #1). (From seeing pictures of the board online, it looks like other AlphaSmart devices have the same port.)
The pinout is as follows. There’s not a lot of vertical room and you won’t be able to, e.g., solder on headers.
RTS are the DragonBall’s UART1 and are at TTL voltages,
so they can be connected directly to a 5V TTL UART to USB converter.
is the reset line; ground this for the obvious effect.
/BRK is the
DragonBall’s EMUBRK line. If this is grounded when the board boots, the
DragonBall will drop into bootstrap mode, and can be controlled by sending
commands via the UART.
The command protocol is straightforward but slow and very limited; to do anything interesting (like reading the Dana’s memory) you have to upload a code fragment and execute it. The bad news is that the bootstrap code executes before the RAM is initialised! But there is a 32-byte on-chip RAM buffer explicitly for this purpose; except that it’s cursed, and according to the huge errata document, any write on the bus with a low nibble of 0..31 will also update this buffer, rendering it useless for a lot of purposes.
But I did eventually make it work, and you can find my client also on GitHub.
You don’t need this for running EmuTOS, as I got the PalmOS boot loader
working. However, if you really wish, you can use dbztool to upload an EmuTOS
ROM image to anywhere in memory and then run it (it automatically relocates to
the right place). Remember to initialise the RAM first before trying to upload
anything (with the