[U64/U2/U2+] Epyx Fastloader fails sometimes (Example: Space Taxi)

[Jumpman64]

Here's the report David posted on fb: "I have problem loading game with Ultimate II+ with Epyx Fastloader. Many games does not work with the Epyx Fastloader (maybe 20%) and it does not come from UII+1541 drive emulation but the Cartridge emulation In the video I used Epyx Fatloader from Utilmate II+ and my 1541 drive for a test and a real Epyx Fastloader and 1541 drive for the second. I use a real 1541 drive to demonstrate that the problem is not the UII+ drive emulation but the cartridge (Epyx fastload) emulation. I did try on 2 C64, 1 C64c, in PAL and NTSC mode with 2 UII+ cartridge and different firmware..."

--

I reproduced this on a U64 rev1.2 and U2 with actual firmware (2020-03-29) too. Space Taxi loads ~46 sec and just before the first ingame screen should appear it quits out to READY.

st_for_testing.zip

[GideonZ]

I can reproduce it also. I have been playing around with different timeout values, but it doesn't seem to be the problem. The problem may be in the used ROM file. I can see that in case of space taxi, the code jumps to $02B1, but there are zero's there, so the CPU runs into a BRK. There is a small routine in the rom that copies data to 02B1, but my 10-second bus trace does not contain writes to 02B1. So maybe this was overwritten by the loading before my bus trace started? I don't have time anymore today to dig deeper into it.

[GideonZ]

Drive seems to make very odd searching noises, however. Is that normal during loading of space taxi? Also, the loading screen is not there; ah that seems to depend on the value of 0x4000? Hmm..

[GideonZ]

@Jumpman64, could you provide the ROM content of your Epyx cartridge?

[Jumpman64]

@GideonZ sadly i don't own the cartridge. We maybe have to ask David Smith on facebook, who found the bug and reported it initially: https://www.facebook.com/groups/1541ultimate/?post_id=10157514812827753

The available cart dumps look all the same. I've checked a lot of the roms out there. These binaries "Cartridge_Speeder_all_rr.c64.org.rar" should be all we need: https://rr.pokefinder.org/wiki/Epyx_FastLoad I even flashed the .crt and .bin files on the U64 as custom rom but it all leads to the same fail. All the cart images run fine on emulators. I used Hoxs64. Maybe David Horrocks could provide some thoughts? (Fun fact: i helped him with testing to make the latest 1.1.0.x version run on Win7/DX11 again.)

Found another .bin dump here: http://retrohackers.com/viewtopic.php?f=8&t=440&start=15 there's a "fastload_update.zip" [1.25 MiB] containing "fastload.bin" but it didn't work. Converted it with the vice "cartconv" to crt but it just outputs a flashing "READY." Gideon, you've posted there in 2007 - time traveling is so cool! :)

Lemon64 user logan789 (pretty sure it's David S. :) ) reported the Epyx Fastload problem in 2016 already: https://www.lemon64.com/forum/viewtopic.php?t=70903&sid=19eb808be69d8c8f1f20fc6e221e47a7

The Space Taxi main file "TAXI/CMD.PRG" starting at $4000 loads the other parts and quits out at the end. You know that already but me (as an assembler noob) is trying to boil that down to some level of comprehension. :)

[Jumpman64]

Drive seems to make very odd searching noises, however. Is that normal during loading of space taxi? Also, the loading screen is not there; ah that seems to depend on the value of 0x4000? Hmm..

Sounds like the behavior, when you already loaded Spaxe Taxi once and try to load again. The basic loader "taxi/loader.prg" peeks $4000 and checks if the "taxi/cmd.prg" is already in memory then doing SYS16384 directly before even printing the load screen. This fails over and over again the 2nd time. You need to power off/on to make it load again correctly.

[GideonZ]

Or simply POKE 16384,0

[ghost]

could you provide the ROM content of your Epyx cartridge?

I read out the original epyx-fastload ROM (see picture) with the epyxdump-tool. The content is identical to the built-in one. (without the first two bytes / loading address)

epyx-fastload-dump.zip

[GideonZ]

Thanks to Markus, who noticed that an access to IO2 (DF00-DFFF) should not discharge the capacitor and enable the ROM, this issue seems to be fixed. (To be tested.)

[GideonZ]

Leaving out IO2 from the equation to discharge solves the issue. Will appear in the upcoming firmware release.