Cadaver Save Disk

[zeGouky]

Dunno when it stopped working; will try a few previous build.

Do you have the code snippet that do the save by anychance ?

[Toni Wilen]

Fixed. During write index pulses were not generated. It seems to have been broken at least since 3.0..

This is how game does the disk write:

00C1A106 1039 00bf dd00           MOVE.B $00bfdd00,D0
00C1A10C 1039 00bf dd00           MOVE.B $00bfdd00,D0
00C1A112 0800 0004                BTST.L #$0004,D0
00C1A116 67f4                     BEQ.B #$f4 == $00c1a10c
00C1A118 33fc d955 00df f024      MOVE.W #$d955,$00dff024
00C1A120 33fc d955 00df f024      MOVE.W #$d955,$00dff024
00C1A128 1039 00bf dd00           MOVE.B $00bfdd00,D0
00C1A12E 1039 00bf dd00           MOVE.B $00bfdd00,D0
00C1A134 0800 0004                BTST.L #$0004,D0
00C1A138 67f4                     BEQ.B #$f4 == $00c1a12e
00C1A13A 33fc 4000 00df f024      MOVE.W #$4000,$00dff024
00C1A142 33fc 0002 00df f09c      MOVE.W #$0002,$00dff09c

Value written to DSKLEN makes Paula write about 150 words too much (which would overwrite "beginning" of sector) if not aborted by disk sync check.

[zeGouky]

Thanks Toni!

[jotd]

Cadaver V1.0 (not v0.1) saves in standard format IIRC not the shitty format they used (why did they do that when the game itself uses Rob Northen standard format...), and doesn't have protection. Use that, or whdload install

[Foebane]

Originally Posted by jotd

Cadaver V1.0 (not v0.1) saves in standard format IIRC not the shitty format they used (why did they do that when the game itself uses Rob Northen standard format...), and doesn't have protection. Use that, or whdload install

Yeah, I too would recommend the WHDLoad install of any game, as most errors in original game code will have been fixed by then.

[ross]

Originally Posted by Toni Wilen

This is how game does the disk write:

00C1A106 1039 00bf dd00           MOVE.B $00bfdd00,D0
00C1A10C 1039 00bf dd00           MOVE.B $00bfdd00,D0
00C1A112 0800 0004                BTST.L #$0004,D0
00C1A116 67f4                     BEQ.B #$f4 == $00c1a10c
00C1A118 33fc d955 00df f024      MOVE.W #$d955,$00dff024
00C1A120 33fc d955 00df f024      MOVE.W #$d955,$00dff024
00C1A128 1039 00bf dd00           MOVE.B $00bfdd00,D0
00C1A12E 1039 00bf dd00           MOVE.B $00bfdd00,D0
00C1A134 0800 0004                BTST.L #$0004,D0
00C1A138 67f4                     BEQ.B #$f4 == $00c1a12e
00C1A13A 33fc 4000 00df f024      MOVE.W #$4000,$00dff024
00C1A142 33fc 0002 00df f09c      MOVE.W #$0002,$00dff09c

Hi Toni, as known HRM recommends to set #$4000,DSKLEN for idle mode after a write (or to break DMA on disk as in this case).
But there would have been some difference using instead a MOVE.W #$0000,DSKLEN?
It is perhaps to avoid that assembler optimization uses clr.w (double access on 000) on this write only register?
Any differences using MOVE.W #$10,DMACON to forcibly stop DMA?

[Toni Wilen]

Originally Posted by ross

Hi Toni, as known HRM recommends to set #$4000,DSKLEN for idle mode after a write (or to break DMA on disk as in this case).
But there would have been some difference using instead a MOVE.W #$0000,DSKLEN?
It is perhaps to avoid that assembler optimization uses clr.w (double access on 000) on this write only register?

DSKLEN write logic works like this:

If bit 15 was already set previously and new value also has bit 15 set: start DMA. Write enable also requires bit 14 being set in both writes or it becomes read DMA.
If bit 15 is not set (old value = don't care): stop DMA immediately.

I am not sure why HRM recommends $4000. Your guess may be true (read access counts as write with "random" contents or in worst case $ffff) or perhaps there was some Portia or pre-release Paula bug.

Any differences using MOVE.W #$10,DMACON to forcibly stop DMA?

DMACON only "pauses" the DMA (Paula stops sending Agnus disk DMA requests and DSKLEN is not counted down), DMA would continue when re-enabled.

[ross]

Originally Posted by Toni Wilen

DSKLEN write logic works like this:

Thanks

DMACON only "pauses" the DMA (Paula stops sending Agnus disk DMA requests and DSKLEN is not counted down), DMA would continue when re-enabled.

This is interesting.
So with some well crafted code and an untouched real blank floppy you can theoretically replicate some impossible to copy "weak bits" protection.

[Toni Wilen]

Originally Posted by ross

So with some well crafted code and an untouched real blank floppy you can theoretically replicate some impossible to copy "weak bits" protection.

I don't think it works with DMACON because I am quite sure RW head is still being driven (floppy write gate signal is active). I assume it is bit 14 that controls it + DSKLEN being in "active" state.

But I guess you could stop writing temporarily by clearing bit 14 of DSKLEN (but keeping bit 15 set), if bit 15 is kept set, new DSKLEN value gets loaded in internal disk length counter without interrupting active disk DMA. EDIT: But switching read<>write on the fly probably causes other side-effects because afaik read and write uses different Paula internal fifo logic.

[ross]

Originally Posted by Toni Wilen

I don't think it works with DMACON because I am quite sure RW head is still being driven (floppy write gate signal is active). I assume it is bit 14 that controls it + DSKLEN being in "active" state.

Yes you are certainly right.
Have you ever found any code that you use directly DSKDAT ($26)?.

But I guess you could stop writing temporarily by clearing bit 14 of DSKLEN (but keeping bit 15 set), if bit 15 is kept set, new DSKLEN value gets loaded in internal disk length counter without interrupting active disk DMA. EDIT: But switching read<>write on the fly probably causes other side-effects because afaik read and write uses different Paula internal fifo logic.

Maybe in the past someone tried it and failed? Who know..
Anyways are just free thoughts on a Saturday morning

[Toni Wilen]

Originally Posted by ross

Yes you are certainly right.
Have you ever found any code that you use directly DSKDAT ($26)?.

None. I don't think CPU can access DSKDAT or DSKDATR. It probably works like AUDxDAT, Paula ignores all CPU accesses if channel's DMA is enabled. Disk part probably don't implement extra logic(?) needed to support CPU accesses because it would make no sense, there is no flag that tells when write buffer needs new data.

[zeGouky]

Hi Toni,

I was wondering if you were able to fix this bug? Seems to still happening in latest.

Thanks!

[Octopus66]

FYI this is still occurring in WinUAE v4.4