FlatPress

Note: this post is WIP. Will update to fact check, and add photos where relevant.

I shall preface this with: while I would welcome advice from anyone and everyone, as I have little direct experience with what I want to do, the intention of this project is not to make life easy for me. In fact, finding easy solutions appear to, for the most part, be against my goals. I joke about being a masochist when it comes to my projects. There is some truth to this, but the primary point is that I am learning. I find it far, far more fun to take the difficult route and learn all of the pitfalls along the way. I am not under any time constraints, so why should I do it quickly and learn nothing? I’ll take the easy route when it comes to my professional life. Now, I have no deadlines. For these reasons, if anyone suggests things like, using SD card adaptors, emulators, or anything else ‘modern’, I will probably ignore, or argue with it. I am fully aware that these things would make my life easier, but allow me a little pain, ok?

There is also a LOT of yak shaving going on. Most of it for the same reasons as above.

So, what is the project? What are the end goals?

The end goal would be something particularly difficult. I don’t expect to actually get to this point but: Develop homebrew VR games for the Atari Jaguar.

In case you don’t know, the Atari Jaguar, launched in 1993. It claimed to be a 64 bit games console, while other manufacturers were still producing 16 bit machines. This was (mostly) a lie. It ran on the same 16 bit Motorolla 68000 CPU as the Sea Genesis/MegaDrive, Atari ST series, Amiga, Portable Macintosh computers, and much, much more. True, it did have two custom chips which were 32 bit (2x 32 = 64 bit I guess?) but often these were barely used as they were buggy and awkward to use for developers. In mid ’90s, Atari teamed up with VR specialists Virtuality to develop a VR headset for the Jaguar. Along with th headsets, two games were developed for the Jaguar that made us of the hardware. One is apparently lost to the giant bitbucket of time. The other is Missile Command 3D, which, it seems, shipped with VR code, just that it requires the headset to be plugged in to be able to run it in VR mode.

So what happened to the headsets? It turns out that only two prototypes were made, before the flop of the Jaguar caused the project to be cancelled. There are other places online where you can read about this story, so I won’t do it disjustice in trying to piece it together here. The two prototypes occasionally show up, one has red trim, one has blue trim. A few more preproduction shells exist, but these are empty.

“So,” I hear you say, “you want to code for an obscure old games console, which experienced developers at the time struggled with, and you want to do it specifically for a peripheral of which only two exist? You’re write, that is crazy and masochistic.” to which I would respond with the eternal “but wait, there’s more”

You heard me. More. That insanity is no enough for me. That on its own is ALMOST achievable. I just have to find a ROM of Missile Command 3D (done - and I own a genuine one, before anyone complains about piracy), disassemble it (in progress) to figure out how it communicates with the headset, reverse engineer the headset, create a reproduction, which I only have a single use case to test it against, then start writing my own games. All in assembly, on one processor I have no real world experience with, and two weird custom chips that are gimped by their shared bus, and the strange hardware bugs. Nope. Too easy.

We’re doing this old school.

In fact, that’s not even entirely true. We’re going at this, Atari-style.

Modern Jaguar development (yes, it still exists) uses a Windows/Linux based toolchain, derived from the original DOS toolchain that was ubiquitous ‘in the day’ with Jaguar developers. Testing is done on the Virtual Jaguar emulator, and then transferred onto real hardware using something like a Skunkboard. This is fairly similar to how development is done for all classic consoles and computers now. Use a modern computer with all the mod cons, test in an emulator, then deploy to a modern flash memory based solution for running on metal.

Not I.

The ORIGINAL toolchain, possibly unsurprisingly, was released for the Atari ST. It makes sense, Atari computer, to develop for an Atari console. Both are m68k based. Simple. From what I can tell no-one used it. I want to. I now own three of the ST range, so this is, in part, an excuse to say that they are useful for more than gathering dust. However, if I use my ST, I can then wave emulation goodbye. Not a chance I can do that on an ST (interestingly, there were plans to put the ‘Tom and Jerry’ chips that make up the Jaguar into a computer, but this never happened. If it had, it would have been an ideal Jaguar dev machine) Unfortunately, getting official dev hardware, which will allow me to talk to the Jaguar from my ST appears to be a quest that is beyond me. I think there MAY be some contacts I have that might get me closer, but I’m not holding out hope.

So, where does that put me? I have the Jaguar toolchain set up on my 4160 STE. The STE is upgraded to TOS 2.06, as required by the toolchain. I can compile, certainly for the m68k on the Jaguar, but I assume also for Tom and Jerry. I cannot write to it (yet) though. There are many ways that I could do this. One way is to modify the console so I can squirt data directly into the RAM on it. This is possible, but has limitations (for example, I then lose the RAM for runtime data, as it houses game code). The other obvious solution is the cartridge port. One limitation here is that the Jaguar does have some rudimentary copy protection. HOWEVER. Atari did provide the community with a general purpose program header, meaning that any game ROM we make can run on a consumer Jaguar. Nice. So, how do we get the ROM onto a cartridge? The simplest solution is to get a blank cartridge, burn som ROM chips, stuff them in the sockets, and away you go. This is certainly possible, and what I will be doing to test my toolchain. But the iteration time is not good enough for me. To have manually reset the console, pull the ROMs, burn the, resocket them etc… nope.

So I want my ST to be connected to the cartridge. Thankfully the cartridge itself is a pretty simple design. A brief re-acquaintance with it suggests 24 bit address bus, 32 bit data bus. There is also, crucially, a reset pin. So, the plan is to have a small ROM on the cartridge, and a small amount of RAM of some type. To begin with, these will be wired directly to the edge connector on the cart. The ROM will just display a simple holding screen on the Jaguar, until some data appears in the RAM. What gets put in there would probably be little more than enough to display a progress bar. What happens when the progress bar is full? The console resets. Wait. What? The cartridge will be receiving power from the ST, so power cycling the Jaguar will mean that I can basically bank switch while it’s busy restarting. I could just to a jump back to the beginning of the ROM, and switch the ROM during the jump, but timing that seems more difficult than timing a reset. So, the idea that there is a small processor on the cartridge. Which is currently undecided. I might be lazy and go for an ATMega, or I could go for an 8 bit m6800, or a 16 bit m68k. The specifics of this plan I am yet to work out. Given what it will be doing, the chip is mostly irrelevant. The processor will be what will be in communication with the ST. It will receive the ROM, either over serial or parallel (parallel would be quicker, serial might be easier though) and dump it into RAM that is hiding from the Jaguar. The processor also will update the RAM that allows the holding screen to display information. The access sharing on this I don’t fully understand yet, but I know it is a solved problem so I am not worried. When the transfer is complete, the processor will trigger the console to reset, and then perform the bank switching. I am not sure what the easiest way to do this is, but my current plan is just to use logic gates to switch from the loader ROM to the game ROM. There are also some other pins on the cartridge which suggest that I might be able to get a serial console out of the cart port. If this is true, and I can write to it from the game, then that would be VERY helpful for debugging. I don’t think I’m likely to be able to get more than that.

So I’ve added yet more custom hardware to my todo list (on top of the VR headset which is the original goal) but custom hardware means I will have to write custom tools, at a mimumum, to do the data transfer. Ideally I would like a nice, integrated toolset though. So great, I’ve added more work for myself. Surely that must be it though. I have a toolchain. I want to build custom dev hardware. There’s not much more, is there?

Well, I will ignore the fact that I do not know how I’m going to be generating graphics yet. I have this idea that I might want to use one of my other STs though, as I have a monochrome high resolution monitor on my 4160 STE so I can code more comfortably. But I have a colour monitor set up for another one. So, assuming that I find tools to do the graphics work, rather than me writing absolutely everything from scratch…

There’s still one more thing.

Developers these days are spoilt with github, bitbucket etc. Even Perforce, which for some reason is favoured by most game studios I’ve worked at. Version control is a wonderful thing. Even when you’re developing on your own. Atari ST, to the best of my knowledge, has no version control system that I can use. Given the limitations of the ST, I am not going to be able to implement git, but maybe there is something I can do. I own three STs (for now) and want to be able to potentially use two of them for the project. Therefore not only do I want history, but some way to work collaboratively. What if… I write a version control server? That means I need some form of communication between the three machines. But I can have one machine connected to a harddrive, and its sole task is to maintain the history of the project, and serve the latest (or previous) versions of the files to the clients. The plan is then that the clients will launch from a floppy disk. That will start a RAM disk, connect to the server and pull the latest files from it. Compilation etc will happen on the RAM disk. Then a menu option will allow pushing of changed files back to the server. Yes, that means I need to figure out how I’m going to network the STs, including locking communications so that only one can communicate with the server at once. Again, my options are parallel or serial. Or I could use the MIDI ports. My decision here might influence the choice for the dev cart and vice versa. For reference, I also have a parcp USB device, so I will not be solely relying on aging platters of spinning rust, but backing the repository up to more modern, reliable media. But the important part is that this is an external thing, and not part of the primary development loop.

And that, finally, is that. I haven’t explained what game I’m going to be making, because quite honestly I don’t know. I want to get things set up and hopepfully when they are, I will have learned enough about the system so that I can make an educated guess as to what I think I can get working.

Also, there is the fact that this is a mammoth undertaking and I probably won’t have time. It is nice to plan though.

So, despite the fact that I have said I will ignore the most sensible of you, does anyone have any comments?