I have a dead TerribleFire accelerator with a 68030. What is the easiest way to test if the CPU is still alive and something else on this device is broken…?
#commodore #amiga500 #retrocomputing #TerribleFire

@root42 68k CPUs tend not to die... It's likely the hardiest chip on that card.

Note that testing for bus activity & things might not be a good solution on the m68k, as when the system is broken around it and it can't read code right, the CPU tends to run into a triple fault right after boot, and just stop itself. If the HALT pin is low, that's probably a good sign that the chip has ran into this condition. (It's probably also a sign, that it at least somewhat works.)

@chainq is there a NOP tester for 68k chips? The don’t have any other 68030 machines I can test it with.
@root42 I've seen one for a 68000, but I've never seen one for more advanced 68ks. Theoretically one can make one, for sure, although it might not be entirely trivial, given the complexity of the more advanced chips. The bus protocol is more complex, there's caching involved, and so on. It's probably possible to make a NOP runner that disables/ignores most of that, but then you still did not test the chip fully, so even if it passes the tester, it might not work in "the real world".
@chainq No of course it wouldn't work "per se".
Maybe I just need to probe it more thoroughly with the scope. Just attach some flying wires to the first few address lines and see what happens.
@root42 On boot, the 680x0 reads two longwords from the start of the address range. Addresses 0 and 4. The first longword is the supervisor stack pointer, the second is the jump vector where the processor continues execution after reset. Not much to see there, just by looking at the address bus. You can probably see the read cycles better by observing the address strobe and data strobe pins (/AS, /DS). It would be curious to how many of those you see, before the chip stops executing. Maybe.
@chainq yeah, I might try that! Thanks.
@root42 Also again, the 68030 is a complex beast, supports SMP operation, has a co-processor interface, etc. Point being - there's a lot of external ways to keep it from running (granting bus access to something else) by holding various pins, which are normally used for bus control. If the card around it is broken, the bus control CPLD might be holding something which keeps the 68030 from running and booting, even if it's alive. So your tests might not be conclusive. Just saying... 😅
@root42 And one last thing - there's the 68030 User's Manual, it's readily available online, chapter 7 and 8 describes the Bus protocol/arbitration and Exception processing, including reset. Have fun digging through all that... 🙃
@root42 swap the CPU out. if the device then works, you have your answer. if it still does not, you have your answer.
@infosecdj if I had a 68030 yes. :) I was more wondering if something like the 6502 NOP tester would be viable.
@root42 I hope you get it fixed and running again !