Jetpac annotated disassembly released

[cmal]

Great job MrCook. I'm looking forward to delving into the disassembly. I once tried to disassemble Starquake with the Spectacular debugger and pen & paper and got absolutely lost!

[Seven.FFF]

... why did Ultimate do this unneeded instruction all the time, just causes problems

They had some cross-development system which allowed them to assemble the code on another computer, and send it up to the wire to the Spectrum, and then remotely debug from the other computer. Port $7d, being unused on the 16K and 48K Spectrums before the 128K models were invented, was how they interfaced and controlled the Spectrum side of the debug hardware. It only started causing problems when the 128K model was invented.

They really shouldn't have left the debug instructions in the release versions of the games though, if they were practicing defensive coding (they weren't). A while back I did a similar thing with the Parasys remote debug hardware. The code I left in checks the serial port to see if there is a byte ready to be received. Without a debugger attached there should never be any bytes to be received, but I found if I left my game running overnight, sometimes there was random electrical noise picked up that caused the code to wait for a byte that never arrived, so my game would very occasionally hang.

[Ast A. Moore]

I found if I left my game running overnight . . .

Holy smokes, Robin. That’s some rigorous software testing right there.

[Quazar]

They had some cross-development system which allowed them to assemble the code on another computer, and send it up to the wire to the Spectrum, and then remotely debug from the other computer. Port $7d, being unused on the 16K and 48K Spectrums before the 128K models were invented, was how they interfaced and controlled the Spectrum side of the debug hardware. It only started causing problems when the 128K model was invented.

Ah ha! Thanks for explaining!

[XoRRoX]

[mention]mrcook[/mention] Wow - very nice Thanks so much for doing and sharing this

Seeing recent comments regarding the out ($fd),a, could you update the listing to reflect this so others aren't thrown off by it?

[Nienn Heskil]

Port $7d, being unused on the 16K and 48K Spectrums before the 128K models were invented, was how they interfaced and controlled the Spectrum side of the debug hardware.

Doubt it. They use OUT (#FD),A in very specific spots - reading the keyboard, just before an IN A,(#FE), with 'A' holding the keyrow byte. You can see this picture in all of their early games (Tranz Am, Jetpac, Cookie, Pssst, Jetman, even Knight Lore). It seems more likely that they simply had incorrect info in regards to how keyboard reading is done on the Spectrum, thinking you were first supposed to OUTput the keyrow byte to #FD.

[mrcook]

Thanks for all the feedback!

I should clarify that before I started this disassembly I had no prior experience with assembly on any system. This project was a way for me to learn a little more about it so there's likely plenty of mistakes and misunderstanding on my part

I'm stumped by your description of this OUT in various places

I just thought it was another way to read the keyboard, and figured the brothers knew what they were doing

They had some cross-development system which allowed them to assemble the code on another computer, and send it up to the wire to the Spectrum, and then remotely debug from the other computer.

Considering this was 1982/83 I'd be surprised if they had any kind of remote debugging. I'm sure it'd be just a case of squirt the code to the speccy, manual test, rinse and repeat.

They use OUT (#FD),A in very specific spots - reading the keyboard, just before an IN A,(#FE), with 'A' holding the keyrow byte. You can see this picture in all of their early games (Tranz Am, Jetpac, Cookie, Pssst, Jetman, even Knight Lore). It seems more likely that they simply had incorrect info in regards to how keyboard reading is done on the Spectrum, thinking you were first supposed to OUTput the keyrow byte to #FD.

Sounds plausible considering there would have been very little developer docs around at the time. It also seems there are differing ideas on what this OUT is doing so I'll leave the annotations as-is for now, until there is a definitive answer.

Seeing recent comments regarding the out ($fd),a, could you update the listing to reflect this so others aren't thrown off by it?

I don't see any option for editing posts on this forum, but I will try to clarify the README on github.

Cheers,
Michael

[XoRRoX]

[mention]mrcook[/mention]
I meant the source listing on github;)

[uglifruit]

[mention]mrcook[/mention] This is very interesting.
How hard would it be to reassemble Jetpac into uncontended memory, I wonder - and would there be an appreciable speed boost.

[D-Type]

Is the HTML disassembly hosted online anywhere or do I have to install SkoolKit? (Which I don't really want to do, but if needs must I will. I'm currently using dasmfw for 8-bit reverse engineering, but it's Motorola/6502 family.)

Thanks!

[mrcook]

Is the HTML disassembly hosted online anywhere

I never generated the HTML stuff. Except for a few formatting niceties I think opening the .skool file in an editor is more useful, and easy to navigate.

You don't need to install Skoolkit, unless you really want those HTML docs, or need to build a tape file.

[Joefish]

@mrcook This is very interesting.
How hard would it be to reassemble Jetpac into uncontended memory, I wonder - and would there be an appreciable speed boost.

The cartridge version is effectively running from uncontended memory (the ROM space). I don't know if that appears to run any faster, or has been deliberately slowed down. May be worth comparing the code from the cartridge with that from the cassette version.

[mrcook]

The cartridge version is effectively running from uncontended memory (the ROM space).

The whole game is copied to RAM first. Here's the loader from the start of the ROM:

Code: Select all

$0000 di
$0001 ld a,$3f
$0003 ld i,a
$0005 ld sp,$5cf0
$0008 im 1
$000a ld hl,$2000
$000d ld de,$4000
$0010 ld bc,$1b00
$0013 ldir
$0015 xor a
$0016 out ($fe),a
$0018 out ($fd),a
$001a in a,($fe)
$001c cpl
$001d and $1f
$001f jr z,$c01a
$0021 ld hl,$004d
$0024 ld de,$6000
$0027 ld bc,$2000
$002a ldir
$002c jp $6000

First the splash screen, then the game code.

The game also utilises self-modifiying code (the NewActor routine at address $6971), so needs to live in RAM.

[Alessandro]

I like these Skoolkit disassemblies when they come as formatted HTML and are available with decimal numerals. Much easier to read and to understand for Assembly semi-literates like yours truly

[Lethargeek]

I like these Skoolkit disassemblies when they come as formatted HTML and are available with decimal numerals. Much easier to read and to understand for Assembly semi-literates like yours truly

blasphemer! loathsome decimal heresy (except counters) in z80 disassembly must be eradicated with fire!

[popeymon]

I will definitely be looking at this Jetpac disassembly.

If you hadn't done any assembler before, you took on a big challenge!

I am doing a disassembly using SkoolKit of Horace Goes Skiing. The READ_KEYBOARD routine disassembly is https://popeymongames.co.uk/2021/04/23/ ... -at-28234/.

And you've given me an idea to consider using GitHub to publish it. I was just going to put it on my PopeyMon website and add to the above, using some other tools that other SkoolKit users have used.

But GitHub is another option. Not something I've used and I need to weight up the pros and cons of using it, and making it readable for non-coders (sort of).

[Alessandro]

blasphemer! loathsome decimal heresy (except counters) in z80 disassembly must be eradicated with fire!

Hey! The Taliban are coming!

[Mpk]

There's a whole bunch of disassemblies at https://skoolkit.ca/disassemblies/ Speaking as a shameless code voyeur it'd be great to have everyone's disassemblies in one place.

Maybe there's some sort of Spectrum Computing site that could host them all, if skoolkit.ca isn't appropriate.

[Morkin]

There's a whole bunch of disassemblies at https://skoolkit.ca/disassemblies/ Speaking as a shameless code voyeur it'd be great to have everyone's disassemblies in one place.

Maybe there's some sort of Spectrum Computing site that could host them all, if skoolkit.ca isn't appropriate.

I noticed that the one I finished recently for Avalon was automatically put in the game's entry as 'source code - remote link' alongside Steve's Graftgold site link. I guess others may go onto ZXDB as links in the same way?

I've also noticed how people keep their disassemblies in different formats. GitHub seems to be quite popular (I'm not sure how to use it TBH). Others are Skoolkit's standard HTML page output, hosted on people's sites. I guess the main problem is that over the years sites can disappear.

I did add an .asm file for download on request as well - to be honest I wasn't sure what the best format is for a single disassembly file. Is it an .asm file or something else?

Of course, as Alessandro has now mentioned it , there's always the additional discussion about whether it should be in decimal or hex...

[Mpk]

as now mentioned it , there's always the additional discussion about whether it should be in decimal or hex...

The skoolkit format ones have a link at the bottom to switch to Hex/Dec, so that solves that issue.

The multiple site problem is why I think it'd be peachy if they could get hosted here somehow, as surely this site will remain forever? And github's just a chore for all involved.

[Einar Saukas]

I noticed that the one I finished recently for Avalon was automatically put in the game's entry as 'source code - remote link'

Notice it's also marked as "Source code repository - Disassembled".

I guess others may go onto ZXDB as links in the same way?

All disassemblies are stored in ZXDB this way.

If I missed anything, please let me know!

[mrcook]

I like these Skoolkit disassemblies when they ... are available with decimal numerals. Much easier to read and to understand for Assembly semi-literates like yours truly

I understand what you mean, I used dcimal numbers for my first forays into disassembly. The thing is, assembly language starts to make way more sense when work in hex numbers. It honestly doesn't take too much time to get your head around it, and your dis/assembly efforts will be rewarded for it.

[mrcook]

Maybe there's some sort of Spectrum Computing site that could host them all, if skoolkit.ca isn't appropriate.

I did bring together a bunch of old disassemblies (some from wayback machine, some I had in my own backups, some existing sites), I converted them to Skoolkit format (some I even reverse engineered from HTML only to .skool files!) and put them on github here: https://github.com/mrcook/zx-spectrum-games

I did think out adding more, but wasn't sure if the owners would be happy with that.

I would personally recommend uploading your disasemblies to a site like Github/Gitlab/etc. Other sites, even personal ones, often disapear or are updated with some new framework (Wordpress, or whatever the latest cool is) and often files like this just disapear. Sure, Github could disappear too, but at this stage it'll probably outlive all of us.

The Skoolkit HTML sites are fine, but anyone serious about understanding how a game works really needs to see the plain ASM/skool source code files.

[Mpk]

https://github.com/mrcook/zx-spectrum-games

This is awesome, I hadn't seen some of these before. I was playing around with AticAtac & skoolkit last night, but I see now it's already been done.

The Skoolkit HTML sites are fine, but anyone serious about understanding how a game works really needs to see the plain ASM/skool source code files.

I'm not sure what is missing from the HTML sites though, compared with the .skool files. Isn't the content the same, just easier to read/browse in the html?

[SkoolKid]

The skoolkit format ones have a link at the bottom to switch to Hex/Dec, so that solves that issue.

Just to clear up a possible misconception: the base-switching links in the page footers is not an automatic feature of SkoolKit - which explains why only the disassemblies I've written and published actually have them.

I have now documented how to add base-switching links to your own disassembly, though:

https://skoolkit.readthedocs.io/en/late ... -switching

That 'Base switching' section will be in the manual for 8.6, but the instructions should still work for earlier versions of SkoolKit as well (if you grab bases.ref and bases.py from the GitHub repo).