New: fully documented source code for Lander

[MarkMoxon]

I am delighted to present my latest project: the first-ever fully documented and annotated disassembly of Lander on the Acorn Archimedes.

Lander.png (7.51 KiB) Viewed 1330 times

As you all know, Lander was the very first game released for the ARM platform, and is arguably the only game ever written explicitly for the original ARM1 processor (there are famously no MUL instructions in there). And, of course, it's the second bona fide classic from the genius of David Braben, as this is the game he wrote next after his astonishing work on Elite.

I will be adding a number of deep dives to the site over the coming weeks, but for now, I hope you enjoy the results, which you can see here:

https://lander.bbcelite.com

As always there is also a GitHub repository containing fully buildable source code that you can play with:

https://github.com/markmoxon/archimedes-lander

I've used vasm to assemble the code, but I wanted the source to be as close to the original style as possible (which I assume would have been the BBC BASIC assembler given that the Zarch source in sirbod's videos is in that format). So I've added a simple Python pre-processor to convert the Acorn-style source code into vasm-compatible code on-the-fly that vasm can then assemble into the final game binaries. It works pretty nicely.

Note that this is a first draft of the commentary and there are definitely some areas that I haven't explained well and there will be mistakes. Still, I hope you enjoy exploring the insides of Lander as much as I have!

Mark

[spanners]

Sweeet!

[davidb]

Very nice!

Looking forward to reading more about the game as you expand the site.

[iomanoid]

Beautiful!! (Just waiting for Mazhar to turn up and ask about sound now )

[Cybershark]

Next up: a teletext Beeb version?

[MarkMoxon]

Next up: a teletext Beeb version?

Ha, yeah, don't give me ideas.

Though I do genuinely wonder whether Lander could be tweaked to run in an ARM co-pro in a Beeb, sending graphics commands to the BBC Micro over the Tube instead of saving them into bin-sorted graphics buffers. Because then we could have the following:

https://archive.org/details/AcornUser06 ... 4/mode/1up

I mean, how amazing would that be?

Mark

[iomanoid]

https://archive.org/details/AcornUser06 ... 4/mode/1up

Hahaha! That’s vicious

[spanners]

Well, Virus runs on the Speccy... https://spectrumcomputing.co.uk/entry/5 ... trum/Virus

[MarkMoxon]

Well, Virus runs on the Speccy... https://spectrumcomputing.co.uk/entry/5 ... trum/Virus

That is true! It's amazing. I thought that was an April Fool's joke when I first saw it - I guess that the Acorn User article was closer to reality than they thought!

I've always fancied finding an actual use for the ARM1 co-pro on my PiTube, though a native Beeb version would be even cooler. Think that might be a challenge for the real 6502 wizards out there…

Mark

[jms2]

This is brilliant! I have found your other game disassemblies really interesting and revealing, but in those cases I more or less understood the hardware of the underlying machine. Although I've had Archimedes machines since about 1990, I have never really had the same connection to the hardware and never grasped what kinds of tricks the games were using. So this new project is super interesting for me.

[VectorEyes]

This is fascinating. Thank you Mark for all of the amazing information you are publishing, and in a wonderfully readable and browseable format.

[dpsharp]

Amazing effort, well done and thank you for sharing it with us!

From working through the codebase did you get a feeling for how hard it would be to increase the visible play area or optimise the frame rate per the improvements being attempted on Zarch? (viewtopic.php?t=10313)

[MarkMoxon]

Thank you for all the kind words, everyone! It means a lot when people are interested in this little niche of ours.

From working through the codebase did you get a feeling for how hard it would be to increase the visible play area or optimise the frame rate per the improvements being attempted on Zarch? (viewtopic.php?t=10313)

Good question! I don't know anything about the graphics code that's used in Zarch, but from what I've read in that thread it looks very similar to Lander, so things like increased landscape area and faster triangle plotting should improve things in pretty much the same way (there are no doubt improvements in the Zarch code compared to Lander, but it's unlikely to be radically different).

While I write the deep dives I'm planning to keep an eye out for hard-coded values for things like row and column counts on the landscape, and I may try to pull them out into configuration variables so that the landscape size could theoretically be changed. I'm not sure how possible that is, but it's definitely worth a go.

It's early days, really - first I have to write down what I know so I don't forget it, and hopefully then it will be easier to answer this question!

Mark

[garfield]

Great attention to detail. Excellent to see assembly source for Archimedes games becoming available (whether decompiled, or new projects).

[kieranhj]

Fantastic work Mark! Thank you for continuing your immense investigative journeys. They are always a ton of fun to read and most illuminating.

[MarkMoxon]

Fantastic work Mark! Thank you for continuing your immense investigative journeys. They are always a ton of fun to read and most illuminating.

Thank you Kieran! This is why I had to park 3D Elite for a bit; that's next on the list after the deep dives for Lander are done.

Talking of which, here's one I just added on the 3D landscape algorithm:

https://lander.bbcelite.com/deep_dives/ ... scape.html

It's more clever David Braben maths. Enjoy!

Mark

[MarkMoxon]

From working through the codebase did you get a feeling for how hard it would be to increase the visible play area or optimise the frame rate per the improvements being attempted on Zarch? (viewtopic.php?t=10313)

I've managed to increase the size of the visible play area. It's a bit slower, obviously, but is still flyable on an ARM3 (just about).

I've pulled out the landscape size as configuration variables, so it's pretty easy to change (there's only one tweak needed to the code beyond setting the landscape sizes, and that's a two-line fix to the tile-colour routine to let it cater for the greater depth). Turns out Lander was written with landscape flexibility in mind!

If you want to build this version yourself, then it's in the big-landscape branch of the repository:

https://github.com/markmoxon/archimedes ... -landscape

or if you just want to cut to the chase, you can download it here:

https://lander.bbcelite.com/versions/bi ... Lander.zip

Incidentally, does anyone know of an Archimedes emulator that lets you run the machine at the full speed of the modern host, rather than capping it to, say, an ARM3 or A5000? It would be fun to see this running quickly...

Mark

[james]

That looks amazing!

[baz4096]

Incidentally, does anyone know of an Archimedes emulator that lets you run the machine at the full speed of the modern host, rather than capping it to, say, an ARM3 or A5000? It would be fun to see this running quickly...

Will it run under RPCEmu recompiler? That goes pretty darn fast...

[MarkMoxon]

Incidentally, does anyone know of an Archimedes emulator that lets you run the machine at the full speed of the modern host, rather than capping it to, say, an ARM3 or A5000? It would be fun to see this running quickly...

Will it run under RPCEmu recompiler? That goes pretty darn fast...

Hmm, I've never managed to get that part of RPCEmu working - it just sits there with the RISC OS 48MB banner, doing nothing, mocking me. Not even sure what it's supposed to do, to be honest; the interpreter version works fine, so I've always stuck with that.

Mark

[SarahWalker]

Have you configured it for StrongARM? That's the only CPU the recompiler works with.

[MarkMoxon]

Have you configured it for StrongARM? That's the only CPU the recompiler works with.

Ah, that will be it. I just did the “run it straight out of the box” thing… thanks Sarah!

Mark

[MarkMoxon]

Have you configured it for StrongARM? That's the only CPU the recompiler works with.

Ah, that will be it. I just did the “run it straight out of the box” thing… thanks Sarah!

Mark

The recompiler version of RPCEmu now works, thank you!

Unfortunately neither the original !Lander nor big-landscape !Lander do anything other than show a black screen on either version of RPCEmu, so I guess it just isn’t RPC-compatible in the first place. Lander works OK on 3.11, but not on 3.5+.

Possibly not that surprising, looking at all the hard-coded screen addresses in the original? I’ve not done any assembly coding for 3.5 and up, so this is all new to me…

Mark

[spanners]

Looks like screenBank1Addr/screenBank2Addr need to be calculated using the result of OS_ReadVduVariables 149.

D.

[timw]

Incidentally, does anyone know of an Archimedes emulator that lets you run the machine at the full speed of the modern host, rather than capping it to, say, an ARM3 or A5000? It would be fun to see this running quickly...

ArcEm seems to run quite fast, compiled from the 2012 v1.50 source on x64 linux - 220+ MIPS reported here by !ARMSI, though the original Lander only looks to be running about two or three times as fast as it would on an ARM2 machine (maybe inaccurate vsync timing?)

Thanks for the super interesting articles!

Tim

[dpsharp]

Possibly not that surprising, looking at all the hard-coded screen addresses in the original? I’ve not done any assembly coding for 3.5 and up, so this is all new to me…

Wow! Looks great with the larger landscape, really pleased to see it so easy to adjust.

As for making it 3.5+ compatible, take a look at Jon hacking the Zarch source code to make it compatible with more modern versions of RISC OS/hardware on this video https://www.youtube.com/watch?v=hyUWmdPfJhM&t=458s. Some of the routines he's editing look remarkably like the ones in Lander!

[MarkMoxon]

Possibly not that surprising, looking at all the hard-coded screen addresses in the original? I’ve not done any assembly coding for 3.5 and up, so this is all new to me…

As for making it 3.5+ compatible, take a look at Jon hacking the Zarch source code to make it compatible with more modern versions of RISC OS/hardware on this video https://www.youtube.com/watch?v=hyUWmdPfJhM&t=458s. Some of the routines he's editing look remarkably like the ones in Lander!

Yeah, those videos have been interesting for this disassembly. But I'm not sure I'm up for modernising Lander so much as documenting how it works. My heart is still in RISC OS 2, to be honest! They lost me when they dropped the spring-bindings from the PRMs...

Mark

[sirbod]

Yeah, those videos have been interesting for this disassembly. But I'm not sure I'm up for modernising Lander so much as documenting how it works.

There's a few bugs in the Zarch code, such as an STM^ which may or may not have come over from Lander. The code is largely the same though...ie an undocumented mess.

You'll see my progress on the Zarch hacker thread, but I've done things like use MUL / MLA, replace the triangle routine and fill routines, I've also added a quadrilateral routine for the landscape. There's all sorts of analytic graphs in that thread to accompany the changes.

Regards running Lander quicker, provided you've fixed the STM^ bug if it exists, it should run on a modern machine (Pi etc) under ADFFS at 1000+fps. You probably just need to wrap the !Run with *GOARM3JIT 0 / *GOARM3JIT and possibly add a *ADFRemapVideoMemory 13 160 if the screen address is hardcoded. eg. a !Run with:

Code: Select all

ADFRemapVideoMemory 13 160
GOARM3JIT 0
<run Lander>
GOARM3JIT

[MarkMoxon]

Regards running Lander quicker, provided you've fixed the STM^ bug if it exists, it should run on a modern machine (Pi etc) under ADFFS at 1000+fps.

Thank you Jon! I'll be giving that a go. Lander doesn't contain any ^ instructions, so hopefully that bug is unique to Zarch.

And thank you for your super-detailed analysis of all that amazing optimisation work you've done for Zarch. Absolutely incredible stuff, very inspirational. It's all well beyond my coding skills - I think I'm better at documenting the mess than fixing it!

Mark

[sirbod]

And thank you for your super-detailed analysis of all that amazing optimisation work you've done for Zarch. Absolutely incredible stuff, very inspirational. It's all well beyond my coding skills - I think I'm better at documenting the mess than fixing it!

I just wish I could release it.

Given your documentation skills, perhaps you could figure out how to up the frame rate and keep everything in sync...its eluded me so far as there's so many hard-coded values for time and rotation.