English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.WinUAE (http://eab.abime.net/forumdisplay.php?f=5)
-   -   Cadaver Save Disk (http://eab.abime.net/showthread.php?t=38308)

zeGouky 24 May 2019 20:27

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 24 May 2019 20:38

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:

Code:

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 24 May 2019 20:48

Thanks Toni!

jotd 24 May 2019 22:53

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 25 May 2019 00:42

Quote:

Originally Posted by jotd (Post 1323523)
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 25 May 2019 02:13

Quote:

Originally Posted by Toni Wilen (Post 1323495)
This is how game does the disk write:

Code:

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 25 May 2019 08:30

Quote:

Originally Posted by ross (Post 1323552)
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.
Quote:

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 25 May 2019 09:45

Quote:

Originally Posted by Toni Wilen (Post 1323563)
DSKLEN write logic works like this:

Thanks :)

Quote:

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 25 May 2019 10:12

Quote:

Originally Posted by ross (Post 1323565)
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 25 May 2019 10:48

Quote:

Originally Posted by Toni Wilen (Post 1323571)
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)?.

Quote:

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 25 May 2019 13:55

Quote:

Originally Posted by ross (Post 1323576)
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 04 August 2019 13:46

Hi Toni,

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

Thanks!

Octopus66 11 January 2021 23:51

FYI this is still occurring in WinUAE v4.4


All times are GMT +2. The time now is 08:08.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.

Page generated in 0.07871 seconds with 11 queries