ATK Bug on CDTV

[8BitDreams]

Hi there, found ATK bug on Amiga CDTV: Program freezes when it's started from IDE. Tested on Viper 530, TF536 and MooseHead accelerators. Same issue may be reproduced on WinUAE - it just freezes when IDE is active. It is not a 2.35 ROM issue, because it fails the same way with 2.30 ROMs. If you disable the Extended CDTV OS ROM (J15) - ATKit loads fine with Viper 530 IDE enabled. This points to an issue ATKit is having with the CDTV OS ROMs enabled..
Would de great if it is possible to fix it..

Also maybe it is possible to add a Feature to scan RAM on memory card for Savegames?
It has no autodetect routine and It's hardcoded in bookmark.device (and hence also cardmark.device):
CARDMEM equ $E00000
MAXCARDMEM equ $080000
There will be RAM cards available soon, would be nice if we are able to check them with ATK..

[keirf]

Thanks, if repro'able in WinUAE it shoudl be possible to work this one out for sure.

[C4ptFuture]

If you need any additional info while debugging about what specific CDTV resident modules do (or CDTV related info in general) do let me know. I can also email you a WinUAE config that can trigger the bug (or post it here, but that will have to wait because I need to clean it up a bit :-) ), but a 68030 based CDTV config with a Gayle IDE drive with a WB install should do the trick. Just invoke AmigaTestKit from the CLI after booting from IDE and you should encounter the bug. Symptom: The startup screen shows but no text is rendered and the application seems unresponsive.

[keirf]

You know what, this rings a bell. Perhaps it was on CD32 though. But anyway it was when loading from CD. The problem was an IDE IRQ after ATK has taken over the system. And since ATK can't handle it I think it ends up as an IRQ endless loop. Possibly this could be detected and turned into a crash, or actually handled!

The workaround was to copy the executable to ramdisk, pause a few seconds and then run from ramdisk.

[C4ptFuture]

One thing that is odd is that it works fine with IDE when you disable the CDTV ROMs, so that the CDTV player acts like a regular Amiga (at least with the Viper 530 accelerator I tested with), so it seems this bug is something that only occurs when the CDTV ROMs are enabled, but I have no clue how it is related.

Speaking of interrupts. I know that the Triport chip on CDTV will spam INT2 interrupts 75 times/sec unless you tell it to stop doing so by issuing CMD_STOP to cdtv.device. Depending on the INT2 handler, this frequency of INT2s can easily drown the system in interrupts. However, I seem to recall the Triport chip only does that when booting off a CDTV title, so I'm not sure how that could be the cause, because I just booted off IDE. Anyway, just keep it in the back of your mind whenever you get down and dirty with the debugging ;-)

[keirf]

Related to #69 but this bug is more tractable because it involves standard Amiga hardware. If we know more about it we should be able to disable the interrupt at source. Whereas arbitrary Clockport devices, not so much.