Kickstart ROM's chipram test

[robinsonb5]

I'm currently working on porting the Minimig FPGA core to new hardware and have come up against some "interesting" issues. I currently have the core working well enough to run Spaceballs 9 fingers and a few games - but when it first starts up the Kickstart ROM detects some kind of issue with chipram and gives me a green screen with blinking power LED for a few moments before eventually giving me the "Insert Disk" screen.

Does anyone know precisely how the Kickstart ROM tests the chipram? Knowing that will make it much easier to track down where my design's failing.

[Toni Wilen]

Test is simple write/read test, my crystal ball says problem is in ROM overlay which is not getting disabled.

[Leffmann]

The memory test writes a longword 0 to address 0, then tests the memory in blocks by writing some random-looking longword marker just past the end of the current block, and if it can read back this marker, and read 0 from address 0, and is not past the predetermined range to test, then it will continue with the next block.

The mechanism it relies on has to be that a write past the mapped chip memory will either end up at 0, or can not be read back correctly.

KS 1 tests the memory in blocks of 4K, and KS 2 and 3 tests in blocks of 16K, I don't know how these sizes are determined but I guess it's simply a tradeoff between performance and thoroughness.

[robinsonb5]

Originally Posted by Toni Wilen

Test is simple write/read test, my crystal ball says problem is in ROM overlay which is not getting disabled.

Thanks for that - I have checked the OVL signal from the CIA, and it seems to be dropping, next I'll double-check that its state is actually being acted upon by the address decoding logic. Does the overlay map the entire ROM into chipram, though, or just enough to get the program counter jumping into the real ROM space?

Originally Posted by Leffman

The memory test writes a longword 0 to address 0, then tests the memory in blocks by writing some random-looking longword marker just past the end of the current block, and if it can read back this marker, and read 0 from address 0, and is not past the predetermined range to test, then it will continue with the next block.

The mechanism it relies on has to be that a write past the mapped chip memory will either end up at 0, or can not be read back correctly.

KS 1 tests the memory in blocks of 4K, and KS 2 and 3 tests in blocks of 16K, I don't know how these sizes are determined but I guess it's simply a tradeoff between performance and thoroughness.

Many thanks for the detailed explanation - that'll be a great help in narrowing it down

[Toni Wilen]

I forgot some important details..

After ROM checksum check and overlay being disabled (and before actual chip ram check) exec writes early exception vectors from address zero to about 0x100 and then does second pass and compares them. If any value is wrong -> green screen.

Main chip ram test also checks for aliasing (for example if 512k chip, first address after 512k is same as address zero)

Entire ROM is mapped if overlay is enabled.

[hooverphonique]

Originally Posted by Toni Wilen

Entire ROM is mapped if overlay is enabled.

is it not only the lower 512k that is mapped? I didn't think the upper 512k @ $E00000 was (on amigas with 1M rom support).

[robinsonb5]

Originally Posted by Toni Wilen

I forgot some important details..

After ROM checksum check and overlay being disabled (and before actual chip ram check) exec writes early exception vectors from address zero to about 0x100 and then does second pass and compares them. If any value is wrong -> green screen.

Oh! Many thanks for that - that could well be related. I've already had to deal with a spurious interrupt from the Action Replay component, which has its own overlay, so that could have something to do with it.

[robinsonb5]

Thanks for the input, everyone. It turns out the problem was indeed interference from the Action Replay component. I'll figure out at some point why it was being activated without being asked, but for now just removing that module fixes the green screen issue