Mark Seelye has ported ScottFree to the Commodore 64. This more-or-less direct port does not perform better than the official Scott Adams or Brian Howarth releases for the platform, but does offer 8-bit users the opportunity to play some newer .dat format Adams games.
Prebuilt disk image with Adams Sampler 1 and Ghost King
Prebuilt 1581 disk image with all Adams and Howarth games plus Ghost King
I’m impressed that it works on a constrained platform like that. That’s clearly very efficient C code!
Doesn’t work for me unfortunately. When I try to load Ghostking, it fails at some point. Same happens on a real C64 btw. Not sure about the loading routine… is that meant to be a fastloader? Or does it flash just for… well… for looking good? I have a stock C64 equipped with JiffyDOS. But Jiffy shouldn’t be the problem here. It would be the first program I encountered in 30 years where Jiffy fails.
Nice one!
I did a TRS-80 port last year, cross compiling with sdcc. I managed to get save and load working recently as well.
Can’t replicate your crash, even with JiffyDOS in various flavors on various hardware.
It’s no VICE issue. As you can see I can replicate it on real hardware. Well kinda. This is an Ultimate64 Elite. No additional peripherals nor REU emulated. Same issue in VICE as posted earlier already. This is the D64 image. I’m not emulating the 1581 drive.
I was asking whether it’s a Fastloader because it could have been interfering with Jiffy. Never heard of something like that but you never know. There’s always a first time.
Have you applied the Jiffy ROMs to both Kernal and 1541-II? Also… are you NTSC or PAL based? I’m using a PAL machine.
We cannot replicate your issue on a myriad of emulated and real NTSC and PAL equipment, including my own U64 (which yes has Jiffy applied to both kernal and emulated drive.)
Try downloading the .d64 again and/or try the .d81 in VICE.
md5 of the .d64 should be a9a6d4181a6ff3588d5bbb0cb88e4c0f
And I can replicate the bug on a myriad of emulated and real PAL equipment, including my real breadbin which I connected now just for testing. The file had the correct checksum, but I downloaded it anyway again, result as seen on this picture.
No worries, it’s fine. ScottFree and I won’t become friends then. This is notably the first time since shortly after the dinosaurs vanished that I won’t get something running on a C64. I’m definitely not the problem here, just pointing out the issue, whatever the cause may be.
What happens with sampler1.dat?
run:rem -d sampler1.dat
Would you mind PM’ing me the precise kernal and drive ROM you’re using? I will drop them into my own VICE and U64 settings to try to replicate this.
@8bit_era Hey, thank you for helping us diagnose this! I’d like it if we could find what the gap is, as I want this to work for anyone willing to actually try it.
Hi Mark, I’m happy to help! I can provide ROMs of my config in both VICE and U64E, which hopefully enables you to understand the issue. It’s basically a special Jiffy ROM I am using. I’m working with it for five years now and I never had a single issue with something not working. I develop games for retro systems so my stuff has to work well. It’s this Kernal release https://csdb.dk/release/?id=137938 - the 1541-II ROM I’m using is the stock Jiffy.
You might want to try the patch yourself but if you wait a day I should feel a bit better. I had a inflamed wisdom tooth removed today and the painkillers just left me alone with my hurting jaw, so I can send the ROMs tomorrow 
@8bit_era Ah, it is quite likely that Jiffy ROM. We can give it a go, but it might not be as easy of a fix as it is likely some incompatibility with how the cc65 libraries handle drive operations. I did not write any load/save routines, the port is very nearly just cc65 compiling the SCOTT.C source.
Thanks again, there is no real hurry. I’m thinking this may help others with problems with that Jiffy image who are writing cc65 programs too, so it’s worth the wait.
So, I setup that franken-jiffy and added some additional debug prints. Whatever that JiffyDOS hack is doing, it seems to read the header just fine, some subsequent access to the drive (calls to cc65’s fscanf) read fine, but eventually fail because (I think) they hit the end of the file. ~
The un-patched JiffyDOS seems to work fine.
I would dig into why the franken-patch-jiffy doesn’t work, but I don’t have the time right now. Maybe the creator of that patch can fire up cc65 and make a test program that fails and use frankenjiffytest to try and fix it. It’s doing something weird to disrupt the disk access when it reads that blank line repeatedly with fscanf. Something that without that jiffydos, seems to work.
Again, thanks for your help Stefan!
(several ninja edits)
So, for some reason with this Patched JiffyDOS it is dropping reads, for the 12th action there should be three zeros like “1962 62 26 0 0 0 750 0” but for some reason it is reading “1962 62 26 0 0 750 0 1962” with that second 1962 being the start of the next number in the file.
Quick/simple test program that can reproduce issue with FrankenJiffyDOS + GenuineDriveJiffyDos:
That’s very, very interesting. It’s unfortunately a very popular Kernal replacement, because of the fancy look and the combined features it offers. I hope someone is being able to fix this. I think I’ll switch to regular Jiffy for the time being. At least until someone comes up with a patch.
