FlatPress

As I am human, I have many failings. Some of them are even relevant to what I ramble about here. There is one that I would like to discuss here.

I Could Do That Better.

I have been a ‘professional’ developer now for ten years. While that is a fraction of what some of my colleagues have done, I think it now gives me a decent amount of experience. I can, and have, seen full projects from conception to release, I have lead some of those projects. I have seen what works, and what doesn’t. There is always the kind of naïve thing when you have a piece of software that doesn’t quite work how you want it to, to assume you could do it better. There are probably reasons why it’s done that way, either because the way you’re considering has some kind of fundamental flaw in the design, or because it just proved too complex (ie expensive) to develop. Usually. Sometimes of course, you can do things better yourself.

That is not really what I’m talking about. But it is related. What I’m talking about today is when I’m looking at developing for a classic platform, taking the Atari ST as the example here.

Generally speaking, you have three ways to attack this:

1. Cross compile and test on an emulator
2. Cross compile and test on hardware
3. Compile on actual hardware

For some platforms, such as consoles where you physically cannot compile on the target device, you might be limited, but generally those are open for most machines with a keyboard. The middle option seems a little bit strange in this case, and my gut feeling is that most people would do either the first or the last. I guess which camp you fall into depends on what kind of person you are.

I am very much the latter person. I own the hardware, so I want to use it. I also find that often in emulation you find little glitches which just get irritating over time if you use it a lot.

But I have definitely been spoilt by modern programming practices. Specifically version control. If I cross compiled, I could easily use version control on the host machine but I don’t really want that. I could also use something like my PARCP-USB to copy data to/from my ST and have the version control repository on a modern computer. I would then have to remember to copy files to and from it and, it’s using modern hardware which, in this case is just about acceptable, but still bothers me a little.

So I’m looking at this problem and thinking “I Could Do Better”

The problem here is, if you haven’t already picked up on this, if I work on this, it will detract any development effort I might have from my actual development project. But anyway, let’s explore it

At this point, I have a small collection of sixteen bit Atari machines. Specifically a 520 STFM, one of each 520, 1040 and 4160 STE, and a MegaST2. As a programmer I want to be able to code comfortably, that is done most easily using a high resolution monitor. I happen to have a monochrome SM124 monitor, so this works. However, if I’m trying to make a game, I will want to have colour graphics, so I’ll need a graphics workstation. I have a colour SC1224 monitor so I can hook that up to a second ST. I probably want to use the 4160 as my primary development machine, as I can set up a RAM disk, so I can compile quicker, and I can use the 1040 STE then as a graphics workstation, possibly with a smaller RAM disk. I even have the 520 STE which I can use on a TV with a SCART converter as a test device, as it will be the theoretical minimum spec.

This is all good. This works. I have a SCSI drive which came with my 4160 STE, with an ACSI-SCSI converter cable. I could easily store the project on there. But then, how do I share the project with the graphics workstation, and how do I run it on the test machine? I could unplug the drive and switch it between machines, but the drive is old, and the constant power cycling is probably a good way to shorten its life expectancy. The normal way to do this is to copy what I needed onto a floppy and take it to the machine I need it on.

If this is a project which only I am working on, this is technically feasible. I could reasonably trivially keep track of which is the latest copy of whatever I’m working on. It does not, however, lend itself to quick iteration, as writing to floppy and the physical transfer of disks is tedious. Also it is prone to errors, not least as floppy disks are easy to corrupt.

What I would really like is something like a version control system. Now, I should be clear that I’m not talking about making git for TOS, there are a number of technical limitations which I think make that unfeasible, but something more straightforward and server/client based like CVS, SVN or Perforce, where there is a separate server which handles all of the heavy lifting, and the client just says “got some new files for you”. This means that I could have a relatively small client program on the ST I’m working on, which just handles things like transferring files, and possibly checking whether files have changed.

To be complete here, the server in my scenario would probably run on my MegaST, as I quite like the idea of the keyboard-less thing being a server sitting in the corner. The feature set for the server would probably be particularly minimal, probably storing whole changed files, rather than delta patches, as I would presume that resolving the deltas for a get would be prohibitively slow after a while. I would have to look at what a sensible way to do this would be. It would probably support commit messages, and some basic history logging and management. As this is running on a separate computer though, I have all of that machine’s resources to play with, so it’s more limited by my programming time rather than hardware limitations, I should think. At least, I think I’ll run out of the former first.

One more thing to consider, as I mentioned above, I’d be storing this on an old hard drive. I have little trust in them, and wouldn’t be surprised if the platters just turn to dust next week. For this reason, I would be using modern hardware to do some backup. What I would probably do is, using something like the PARCP-USB, set up some system by which I can take a snapshot of the repository and back it up somewhere, in a way that I can restore it later. The minimum viable product is just to do this step manually, which is trivial with the PARCP-USB, so I’m not too bothered by this.

The final thing to consider I think, is how to get the computers to talk to each other. No ethernet, no TCP/IP. I basically have three possible communications channels:

• Parallel
• Serial
• MIDI

I am, of course, immediately drawn towards parallel, as it is, in theory, quicker to transfer, so for quick iteration times, this would be ideal. However serial already has RS485, which is relatively easy to convert to from RS232, so I should be able to make some kind of network with that. I think this is probably the best option I can come up with. MIDI also seems like a sensible option, as there is both an IN and an OUT on the ST, so I could quite easily chain the computers, but that does mean that I couldn’t, at a later date, add a music workstation to the network, so I quite like this idea. Also, freeing up the parallel port means that I am able to use it solely for communication with the Jaguar, if I ever get as far as working on that.

So, what do people think? Does anyone happen to have any experience writing version control systems and feel like helping? Does anyone have experience creating multi-node serial networks? And who thinks I’m being stupid and should just use git on a modern PC, and cross compile to an emulator?