So I saw a post on a forum somewhere, awhile ago, and it set a train of thought in motion. Which has led me to take on a programming project. I can't reveal too many of the details here, in case the original poster is reading this and twigs to what I am doing. But, the hardware platform is the BBC Micro, a popular 8-bit machine in the 1980s, and the project -- described in its most abstract terms -- consists of a relational database with three main tables; a visual editor; and a report generator.
One of the tables will be populated by some external means (because I can't be bothered to design a visual editor for it right now) by translating an input file from a standard format. Another will be fairly static, and will govern the visual representations of items that may be described in the input table. The third table will store the user's creative input which, in accordance with rules defined in the first table, govern the arrangement and interactions of items which are represented visually according to the second table.
(Don't worry if you don't understand any of that. It will probably get a bit more obvious.)
Rather than get an actual BBC Micro at this stage, and have to put up with slow cassette and disc loading times and possibly replace the machine if I can't fit it into the model B into which I was initially determined to shoehorn it, have to get a Master 128 instead and get into a last-minute bidding war, I've decided to use an emulator. In this case, the excellent BeebEm (instructions given for Ubuntu; but as a build-from-source, the second half should work on anything once you have the relevant packages and their -dev or -devel companions -- yes, you are a developer.)
Of course, it helps that I grew up with a BBC Model B and know enough BASIC and 6502 assembly language to get the job done. I've also got a slight advantage as my visual editing isn't going to require fast-moving multi-coloured sprites or anything else that cannot be rendered using universally-acceptable OS calls. It can all be made completely out of the lines and triangles (yes, 32KB of ROM and the most complicated shape a Model B can draw is a triangle) that the operating system can already produce. I'd get no benefit out of hitting the display memory directly; it's not as though I could write a faster triangle-drawing routine than Sophie Wilson and Steve Furber already did. So by keeping to "legal moves", if I can't fit it into a 32K B, I can retarget it seamlessly at the 128.
First off, I'm going to start with the visualisation, because that will give me some important clues for structuring the data in Table Two.
Because I refuse to accept that 45/46 is a failure
