Strange issue with DD2 on C64U

[raelik]

I've been using this for a few days on my C64 Ultimate, and I'm having an odd issue. Every so often, when I turn my C64U on, DD2 will set the parallel port to disabled. Namely, if I hit F8 or type @X immediatelt after it boots it displays this:
02,R+:F+:V+:P-:,00,08

There doesn't appear to be a rhyme or reason to this, it happens randomly, though I would say it is more consistently off than on. Simply doing @XP+ to re-enable it fixes the issue, but it's something I'm having to check every time, which is odd.

[donnchawp]

Did you try the original ROM too? The 1.0 release is the same binary you'll find elsewhere online. I didn't modify that. I'd be interested to hear if that has the same problem.

I don't have a C64U to test it on but I do have an old 64 Ultimate I bought 6 years ago. It's hopelessly out of date though. TBH I wouldn't know where to start debugging that problem.

[donnchawp]

I let Claude have a crack at this and it came up with a plausible answer. Maybe there is a way to fix this!

The DolphinDOS flag registers at $6000-$6003 in 1541 RAM (R, F, V, P flags) are never initialized on boot. Their values depend entirely on whatever the RAM contains at power-on.

How it works

The @x status display (1541.asm:9474) reads $6000,X for each flag:
2a86 bd 00 60 lda $6000,x ; load flag value (X=0:R, 1:F, 2:V, 3:P)
2a89 c9 12 cmp #$12 ; $12 = DISABLED
2a8b f0 03 beq $2a90 ; if $12, show '-'

The P flag lives at $6003. Value $12 means disabled (P-), anything else means enabled (P+).

The parallel mode detection (1541.asm:9137) uses the same check:
27d4 ad 03 60 lda $6003 ; Read parallel mode register
27d7 49 12 eor #$12 ; XOR with $12
27d9 f0 30 beq $280b ; If result=0 ($6003 WAS $12), SKIP parallel init

The only code that initializes $6000-$6004 is the @x+ command handler (1541.asm:9424), which the user must explicitly send:
2a1f 9d ff 5f sta $5fff,x ; zero out $6000-$6004 (loop X=5 down to 1)

Why it's random on the Ultimate64

On real DolphinDOS hardware, the SRAM at $6000+ likely powers up with consistent bit patterns (often all zeros or all ones), so $6003 rarely/never equals $12. On the Ultimate64's emulated 1541, RAM initialization is
different — sometimes $6003 happens to contain $12, disabling the parallel port.

The fix

The 1541 DolphinDOS ROM needs to explicitly initialize $6000-$6003 to $00 during the drive's reset/boot sequence. This is what the @x+ handler already does — it just needs to also happen automatically at startup.

Without a C64U to test, you could:

1. Find where DolphinDOS hooks into the 1541 reset vector
2. Add a short init sequence that zeros $6000-$6004 before jumping to the original reset code
3. Ask the issue reporter to test a patched ROM

Want me to dig into where the DolphinDOS patches hook the 1541 reset vector so we can identify where to add the initialization?

[donnchawp]

@raelik I created a PR that might fix this in #6. You can grab 1541.rom from there by clicking the "Raw" button which will download it. Copy that to your C64U and try it out for a few days.

[raelik]

Excellent! I'll try that at some point today and let you know.

[raelik]

@donnchawp So I tried that ROM this morning, and it causes the machine to hang when running the @X command to view the status registers.

[donnchawp]

Ah no. The only other thing I would suggest is using the rosm from the first 1.0 release. If that works, then we know it's a problem with kernal.rom (and not 1541.rom).

[raelik]

Did you want me to just use the kernel rom from 1.0, or both? EDIT: I tried using the v1 kernel rom with your new 1541 rom, same result. Running @X causes it to hang. In either case, the kernel rom DOES appear to load, I get the DOLPHINDOS 2.0 text in white (or light blue if running v1). I haven't tried actually mounting a disk image or anything like that, since I wanted to verify the registers before I did that.

[donnchawp]

I meant to say to try the 1541.rom from the 1.0 release. :)

I think it's fixed now, at least 1541.rom loads in Vice and I was able to load a couple of demos. It appears the RAM of the emulated 1541 can sometimes have non-zero bytes that mess with the parallel port settings, so this might be a bug in the original DD2, but it wasn't an issue because the hardware drives always zeroed out their RAM.

[raelik]

That appears to have done the trick! This morning, my C64U was booting with P- set, but now it's being correctly cleared. @X works and otherwise it seems to be working flawlessly, loading disks with the usual speed.

[donnchawp]

Great to hear @raelik ! I won't merge the PR just yet. I'll give it a few days just in case you notice anything else.

I must get my Ultimate 64 out, update the firmware and give that a go too!