CD32Load

[Toni Wilen]

Originally Posted by jotd

and it locks up while trying to initialize CD drive. I have made several tries using HRTMon and checking AKIKO registers and could not init the drive, whereas the AKIKO registers seem identical in Agony (init OK) or Second Samurai (init KO => lockup).

Does it lock up because of stuck interrupt? (both $b80004 and $b80008 has same bit set)

[jotd]

Interrupts are disabled it locks up because it tries to initialize cd drive again and again and fails.
Since psygore doesnt reply to my messages I will have to reverse engineer his cd code. Won t be the first time im doing that...

Btw the version on the cd isnt functional. There is another bug also visible on winuae. But tests can be conducted with it.

[Toni Wilen]

Can you check (with hrtmon) CD command circular buffer contents when it hangs? ($b80014 pointer, Burning Rubber uses address $130000)

130000 to 1300ff (receive) and 130200 to 1302ff (transmit) (130100 to 1301ff is subchannel which can be ignored). Make sure buffers don't contain any random garbage before cd32load runs, makes it easier to decode it.

Check also all data buffers ($b80010 pointer), if they all are empty, it confirms it hangs before any data gets loaded (my guess is before or during TOC reading). Remember that Akiko always selects highest available buffer. (=$b80010 value + 15*4096)

Include also Akiko register contents, matching them with emulation may help to find where exactly it hangs.

[jotd]

Ok but that garbage thing gave me an idea.
The fact that cdbuffer is not at 1e0000 could be the clue thus explaining that aga games fail and ecs dont.
Cdbuffer memory is NOT zeroed by cd32load and that could be the problem if cd routine is buggy and reads stuff before writing it. That would explain a lot.

[Amigajay]

Totally unrelated to anything you are currently talking about, but I'd thought I'd mention it because it may be related to 'something' and may help somewhere! Excuse if it doesn't.
Me and Statmat were trying to figure out why the whdload version of son son-shi worked (albeit with the odd flash loading) via the AMS compilation builder, and not via Statmats startup with AGS2, turns out the only difference was having 'doublespeed' in the startup helped it load up.
Again it probably has zero todo with helping with cd32load, but I thought it strange just by the speed of the drive helped a game load and not at all on the other disc?

[jotd]

Found what the problem was (I think): I zeroed the memory manually for Burning Rubber and it started!!
So Psygore's loader needs a zero-initialized buffer to start with. It must read some AKIKO registers values before they're set. If it's zero then no problem, if it's $CCCCCCCC or garbage then ouch!!

The reason why it generally works, it's because ECS games (and Body Blows Galactic too!) use $1E0000 as buffer address, high enough to be zero.
With specific AGA special buffer settings it locks up but depends on the startup. AGS has a different memory footprint compared to boot without startup...

WinUAE is not affected by garbage in buffer. What's the interest in emulating this? none I think, but a million thanks Toni your talk about garbage value gave me that idea.

Amigajay the doublespeed stuff is maybe related to how much time is needed by the drive to end the transfer DMA or something. Since WHDload does not handle that at all (only through the delay stuff), it can make a difference.

[Toni Wilen]

Originally Posted by jotd

Found what the problem was (I think): I zeroed the memory manually for Burning Rubber and it started!!
So Psygore's loader needs a zero-initialized buffer to start with. It must read some AKIKO registers values before they're set. If it's zero then no problem, if it's $CCCCCCCC or garbage then ouch!!

So it is bug in loader because hardware does tell when buffer's transfer has been completed. ($b80020.w bit mask, 0=complete/not started, 1=pending, loader only needs to remember which bit was set to one, when bit changes back to zero = buffer transfer complete)

WinUAE is not affected by garbage in buffer. What's the interest in emulating this? none I think, but a million thanks Toni your talk about garbage value gave me that idea.

Garbage comes from internal properties of DRAM chips after powerup. It is not 100% random. I am not sure if this can be emulated accurately enough without internal details of used memory chips.

[jotd]

Anyway, I'll try to burn a CD tonight to test AGA games. I'm really hopeful this time.

[jotd]

v0.26 final in the zone. Tested a few games, seems all right now even with AGA games.

- Burning Rubber AGA: works fine, loads fast
- Chaos Engine 2 AGA locks up, I'll investigate
- Jurassic Park AGA started but got "grinding", will retry
- Second Samurai AGA: works fine!!

[Vot]

Originally Posted by jotd

v0.26 final in the zone. Tested a few games, seems all right now even with AGA games.

- Burning Rubber AGA: works fine, loads fast
- Chaos Engine 2 AGA locks up, I'll investigate
- Jurassic Park AGA started but got "grinding", will retry
- Second Samurai AGA: works fine!!

Awesome.

[jotd]

Yes, I'm really happy about that. Chaos Engine AGA locks up even WinUAE (it used to work). So it will be easier to investigate. That's more and more the case now that all hardware differences have been workarounded.

[Amiga1992]

Great work jotd and Toni!
I haven't kept up with the news, is the source of grinding detected?

I wish Psygore would care a bit and give out the source/contribute to the conversation

[Toni Wilen]

Originally Posted by jotd

Yes, I'm really happy about that. Chaos Engine AGA locks up even WinUAE (it used to work). So it will be easier to investigate. That's more and more the case now that all hardware differences have been workarounded.

It looks like loader got "out of sync", $b80020.w has bits set (=CD block transfer(s) pending), then DMA was switched off, something was done, DMA back on and then loader wrote to$b80020.w again to start new transfers. But because at least one CD sector transfer was already pending, loader got confused when it got mismatched transfer interrupts.

I assume following code is your DMA off code? Try clearing also bit 26 (now it only clears 27). Clearing 26 aborts all pending CD transfers immediately and finally write zero to $b80020.w. (Clear possible pending CD block transfer complete interrupt). You can probably re-enable bit 26 immediately after zero write if you don't have any other way to re-set it before calling loader again.

Only way to force clear $b80020.w (= abort all pending sector transfers), is to temporarily clear bit 26 of $b80024. I assume loader wanted to prefetch sectors and it returned before all transfers finished. (ROM loader does the same and it will break some games if CPU is too fast, game takes over the system, prefetch finishes, interrupt 2 triggers, game does not know what to do with it..)

001F0D70 0293 f7ff ffff           AND.L #$f7ffffff,(A3)

[jotd]

Toni, it also fails with WinUAE I assume that's emulated then?
Edit: the code you're showing is not mine, must be RN or Psygore loader.
I perform a (as you instructed)

AKIKO_DMA = $B80024
AKIKO_DMA_STOP = $13ffffff   ; clear bits 31, 30, 29, 27, 26 mask

	and.l	#AKIKO_DMA_STOP,AKIKO_DMA

after CD operation.

And if a level 2 interrupts arrives because of AKIKO I test it:

	move.l	AKIKO_INTENA,d0
	and.l	AKIKO_INTREQ,d0
	beq.b	.skipakiko
	; avoid game from hanging by clearing AKIKO_INTENA if Akiko interrupt arrives
	move.l	#0,AKIKO_INTENA

The only thing I forget to do is to bypass it when found! I've fixed that.


@Akira: no way Psygore shares his code (whdload slaves or cdloader). I asked him several times. He only shared his NVM read/write code. I'm quite sure he successfully reverse engineered RN loader and built his on it (with some bugfixes on TOC fortunately, with partial file read, but also grinding !!!)
grinding seems to happen when small files / small blocks of files are read.
I have a case where it "grinds" everytime: Double Dragon 2. I'll have to be fast to dump akiko registers for Toni when it happens.

So far this damn grinding bug is the last big difference between real HW and WinUAE on CD32load.

Edit: I could run Double Dragon II for the first time on real HW today. Just added READDELAY=1000 (1000 beamdelays = 25/30ms), probably put space between 2 motor/lens commands (only guesswork here) and it worked without grinding!!! (maybe sheer luck, I'll run it with and without in a row to confirm)

I'll add this value by default and will retest the other "grinding-prone" games (Cannon Fodder 2, Great Courts 2...)

[Toni Wilen]

Originally Posted by jotd

Toni, it also fails with WinUAE I assume that's emulated then?

I don't know if this is exact same but it does hang in winuae

Edit: the code you're showing is not mine, must be RN or Psygore loader.
I perform a (as you instructed)

Ok, so it never gets there. I guess this is bug in the loader, assuming your code never gets control between last read and next read. Or do you call loader to load something, then it returns and then you immediately call loader again to load new file? Delay here probably helps, or doing above abort "command" (which probably is more optimal, no unnecessary delays)

It is possible this actually depends on location of files on CD. If seek time is long enough, problem won't happen.

[jotd]

I already perform the abort command, did not help grinding.
I don't load 2 files in a row on purpose, but the game can do that. Load file 1 and load file 2 right afterwards. Or read a small bit of the file1 and immediately read another bit (when FILECACHE is off)

Small delay helps, as I guessed and as you half-confirm: it leaves time between CD accesses and fixes problems.
Seek time could also explain why the grinding/lockup happened more with ISO created with mkisofs than with ISOCD (even with ROM routines, it happened that mkisofs-created CDs won't boot 2 times out of 3)

Well, I'm hopeful about this. A 30ms delay won't be noticeable, specially if it prevents grinding bug / read errors (I still have "file errors" on some games which work perfectly on winuae, no grinding, just read error, I suspect/hope this is the same problem)

100% of OK games on real hardware is possible now

Edit: Moktar which gave the "grinding" bug, now works (load is slow but still...) with a small delay. Good lead! Time to re-test all games where grinding occured and burn a new RUGCD for everyone.

[jotd]

Done some testing with READDELAY parameter set at 1000: no grinding in more than 1 hour testing a lot of games, a lot more games work flawlessly.

Just forgot to set READDELAY, and Super Off Road loaded and loaded and loaded... Put it back and got the title picture, then grinding F**K!!

Edit: with 2000 it works! I'll stick to 2000.

Check https://docs.google.com/spreadsheets...4LI/edit#gid=0 you'll see a lot of green there.

most games working on WinUAE work on real HW. Some "interesting" exceptions remain, though.

[Toni Wilen]

Have you found some (almost) guaranteed "grinding" test case? I'd like to check what the laser mechanism does when it happens. My guess is that sound comes from constant seeks but I'd like to confirm it.

How to enter hrtmon? NMI only?

[jotd]

Okay. Just run Double Dragon II with any of my RUGCD if you have downloaded one and wait till the story scrolls. 100% grinding if no READDELAY is set.
HRTMon works from "\" key.
Prepare your "m $B80000" so you can recall it later.

Howto: boot RUGCD with RMB down (not a good idea, I have changed to LMB now). After a while, black screen + drive on: you are in hrtmon: exit
then enter DoubleDragon2

cd32load doubledragon2 data=data-pal readdelay=0

(0 is default ATM but that will work for future versions)


When you get the grinding enter HRT with RMB or "\" key and recall the m $B80000 line to get akiko regs
(the grinding continues during several seconds even when hrtmon is active)

you can even record the grinding noise and emulate it with winuae

[Amiga1992]

Originally Posted by jotd

Check https://docs.google.com/spreadsheets...4LI/edit#gid=0 you'll see a lot of green there.

Sooo much green duuude!


Good job jotd!