Afterburner enhanced mod and cheat loader.

[evapowah]

This loader requires Afterburner "MCM" tape distribution (not included).
Usage: Play the loader. Then play original tape.
Compatibility: Tape. Real machine or emulation.

Features:
- 48K/128K: lives and ammo refill cheats. See keys when the game tells about how to activate pause.
- 128K: single load of all levels.
- 128K: MUSIC + FX option, with proper AY chip channel priorities.
- 128K: option to toggle AY and beeper FX. See keys in the screen before game start.
- 128K: fixes the intro so it does not cut the music periodically and does not take forever to switch screens.

This is a little tribute to the fact that the distribution of the game is denied. And to the effort of Keith Burkhill to make the highest FPS conversion of the arcade back then.

Source code included.

If you like the effort feel free to donate. Paypal: [email protected]

Enjoy.

Note: If the right person reads this and thinks it is good enough, please feel free to include it for download in the page of the game.

Download link:

[goodboy]

as I recall the dsk version contains two melodies

[Old-User]

@evapowah:

Great work!
The mod delivers a much better gaming experience.
Thanks, I have enjoyed it very much.

[evapowah]

Update:
There was one more thing to fix related to the lack of integration of the music programmer.
The AY FX code uses a priority system, so a new FX code overrides a previous one only if new code is lower or equal. This results in unwanted masking of FX sounds.
While the beeper FX code always overrides an old FX with a new one. In practice this scheme proves superior.
So to remove priorities in AY FX: In music module in page 3 of RAM: POKE 60923,0.

In source code: find "JP 59912", before that add "LD HL,60923"; "LD (HL),0", assemble file (SJASMPLUS was used). Old LEN=512 bytes; new LEN=517 bytes.
In BASIC program: Use a FOR to poke 23760 to 23760+512-1 to 65 ("A)" to allow editing BASIC line, but do not touch the big REM, it would be limited in size to 4xx bytes. Grow BASIC REM line by 5 bytes by adding another "REM :" before main one so that it reads "10 REM :REM AAA...", check that PEEK 23757+256*PEEK 23758=517+2=519, load new binary at 23760, save program back executing line 999.

I'm not going to post updated files because I did not get any donation.

[Slider]

Virtual TR-DOS contains extended TR-DOS version of this game (2022, many music from Atari ST etc)
I don't public a link because game is denied

[evapowah]

Oh, virtualization. Tape release is the remedy. Every gram of fat is paid as more loading delay. "There is an undisputable leader in virtualization, they used to have their headquarters in Redmond".

I actually have Atari ST and an original copy of Atari ST Afterburner. Would anyone fix the sluggish graphics code? Sometimes it drops to 5 FPS.

"I tried to make a TR-DOS release". But the amount of RANDOMIZE USR 15619 did not fit in the space left for BASIC loader. Making a custom loader was mandatory. But then it was no longer compatible with tape or other machines!! Speedlock in disguise!!

"I tried to make a +3 DISK release". But it needed 128K loading, +3 DOS uses extended memory for disk cache, which cannot be suppressed, so a custom loader was again required, making it no longer compatible with other machines. Speedlock in disguise!!

[Nienn Heskil]

Thing is (and I'm sorry to point out something so obvious) but sticking to these '''loaders''' only gets you so far. ¯\_(ツ)_/¯ Like, I get the idea but who cares LOL, just do a proper release where everything is as it should be. Otherwise, there's still tons of stuff out there that can be enhanced/sped up ofc, that much should be clear, I think...

[evapowah]

Oh, so everything about past idiosyncrasies, conflicts, etc, portrayed by the authors into the software decades ago, incidentally or intentionally, is now fixed!! I don't know how to do that without medication, or without someone that takes medication for me!!

[Old-User]

Virtual TR-DOS contains extended TR-DOS version of this game (2022, many music from Atari ST etc)
I don't public a link because game is denied

Music from the Atari St version is much better than the original used but could a standard 128K play it?

If it can then maybe evapowah's version could be enhanced and that would be great for 128k users.

[Seven.FFF]

"I tried to make a +3 DISK release". But it needed 128K loading, +3 DOS uses extended memory for disk cache, which cannot be suppressed, so a custom loader was again required, making it no longer compatible with other machines. Speedlock in disguise!!

You can disable the disk cache and RAMdisk at the start of your disk loader. Call DOS_SET_1346 with zero in both hl and de. I used this in the +3 disk loader for one of my 128K games that uses almost all of the 128K RAM. (I also had to use compression and a bunch of decompression in place and switcheroo in order to get it all in the right locations.)

[evapowah]

You can disable the disk cache and RAMdisk at the start of your disk loader. Call DOS_SET_1346 with zero in both hl and de. I used this in the +3 disk loader for one of my 128K games that uses almost all of the 128K RAM. (I also had to use compression and a bunch of decompression in place and switcheroo in order to get it all in the right locations.)

The documentation states that cache size can be set to zero at the expense of a big performance penalty. I don't have a +3 to check. That's another problem. For loading a few files of a dozen or so Kb size sequentially can it be expressed in seconds w/ cache vs. seconds w/o cache?

[Seven.FFF]

cache size can be set to zero at the expense of a big performance penalty

There's no great benefit to having a cache when you're just reading a bunch of different files once to fill 128K banks.

Performance after running DOS_SET_1346 is fine. My game loads all the 128K banks within a few seconds. To me it seems comparable to commerically released disk game loading times.

You should definitely write and test it on a real +3 though.

I believe that even after disabling the cache and ramdisk, calling ROM disk routines still uses the sysvars and some of page 7, which was already in use by the game before I started working on the disk version. So I compressed all my data with ZX7 and loaded it into locations that didn't overwrite anything that stopped the disk routines from working. Then I after it was all loaded and I didn't need to make any more ROM calls, I decompressed everything in its final location. ZX7 allows you to decompress in place with quite a large overlap, so it's not as tricky as you'd think, although it did take some working out and testing.

I set up a workflow where I could create an entire disk image programmatically with scripting. I have a PC 3.5" drive as my second drive, and use DSDD 3.5" disks for most things. I can write images to these on my PC's USB floppy drive, eject the disk, put them into the +3 drive and load them. You have to buy DSDD 720K floppies, DSHD 1.44MB floppies won't work as they have a higher magnetic flux density.

If you have an old PC with a real floppy controller chip you can read and write normal +3 40 track images, but USB floppy drives won't read them. However there's an alternate 42 track format that works with these and real +3s as well. I use CPCDiskXP to work with images, both with the GUI and automated in my build scripts.

For the final 40 track .dsk image I also create it the same way, but with a different format number in CPCDiskXP. To make physical 3" disks I have a blank formatted 3" disk in the +3's A: drive and a 3.5" 42 track disk I created the above way in the +3's B: drive, and use Garry Lancaster's MSDOS v1.2 utility to copy individual files from B: to A:. It helps if you also have an external storage device like divMMC to quickly load your utilities like MSDOS.

Rather than messing around with binary boot sectors like some commercial games do, I have a simple basic boot program called DISK. I typed it directly in BASIC on the +3 and saved it to a 3.5" disk with SAVE "b:DISK" LINE 0, and read it back off using my PC. Generally the boot program isn't going to change too much once you have it set up, so creating it manually is fine.

It's similar to a tape loader program:

Code: Select all

10 CLEAR 40959
20 INK 0:PAPER 0:CLS:BORDER 0
30 LOAD GTSQZL4E" SCREEN$
30 LOAD "8K0W3G8Q" CODE 40960
40 RANDOMUZE USR 40960
50 SAVE "b:DISK" LINE 0

I use random filenames for all the files on the disk apart from DISK. GTSQZL4E is a regular loading screen, 8K0W3G8Q is my machine code loading stub that takes over, calls DOS_SET_1346, and loads all the the other files into their respective banks and decompresses them with ZX7.

[evapowah]

There are many wrongs I don't want to do.
- I want to do things/fixes that were already possible in the past with the software and machines available, but someone rushed someone not to do it, but to do a new project instead. I don't want to use a modern supercomputer with complex scripting to generate highly monolithic and polymorphic 8 bit and 16 bit apps, with a dozen variants of the same thing.
- 3" +3 DISK system was the key for Spectrum +3 market failure. I don't want to make a monument to 3" +3 DOS. I don't want to make a +3 DOS version of every program. I don't want to write a script for every program. I don't want to make a "disk protection system" that only I can read easily.
- I have all my hacked/repacked collection made with BASIC loaders. I want to keep it like that if i want to test it on disk.

So how far one can go by simply copying the files from tape to a disk?
I wrote a "disk" program that executes some assembly code to initialize +3 DOS with no cache and no RAM disk. Then it loads the desired program.
The area between 56064 and 58880 in bank 7 is what remains still compromised. For the slow it is, +3 DOS uses 2.8K RAM. It seems slow as if no RAM was used.
The program allows to load from disk, unmodified, every program that does not use 56064-58880 in bank 7.

Further development could be made like trapping calls between BASIC and +3 DOS for swapping data area to 16384 or the like.
Huge complexity for freeing those 2.8KB. Packing data seems a better approach.

https://drive.google.com/file/d/1CO0iah ... drive_link

[Old-User]

@evapowah :

Thank you for updating the loader!