Silly bugs and an amazing coincidence
I added a ROM checksum routine to my JLP diagnostics. I debugged it in the simulator, and then tried it on the real JLP. When I ran it on JLP, one ROM hunk in the middle failed. I was puzzled.
Now, I know these dsPIC33s and PIC24Hs have a small number of flash erase/reprogram cycles. So, I tried my spare chip and it also failed in precisely the same way. That meant I had a real bug. It was then that it clicked what the bug was.
I pack my 4K x 16 ROM hunks into 2731 word payloads in flash. I do this because the flash is 24 bits wide. This makes the most use of my flash storage. I pack words so that two 16-bit words are stored in the lower 16 bits of two output words, and a third word is stored straddling the two in the upper 8 bits. It works out pretty well.
Well, that's until that third word has its two halves on opposite sides of a 64K boundary. See, the PIC24 is a 16 bit machine at its heart, and so the upper 8 bits of the flash read address come from an 8 bit "table page" register that's separate from the index register. If you want to read two bytes from opposite sides of the 64K boundary, you need to update that other register manually. Otherwise you'll read the wrong byte. And that was what was happening. (It also explained why it was the ROM segment in the middle, since this is a 128K part and I'm filling it up as much as possible. 64K is smack dab in the middle of 128K.)
Rather than muck with that other register, I decided instead to pad out my ROM hunks to make them an even number of 24-bit words. That way I can ensure that any given pair of output words never straddles a 64K boundary. The padding word? 0xC0FFEE :-)
That makes my ROM hunks 2732 words long. Old school hackers should recognize that number. 2732 is the part number of the 4K EPROM that was ubiquitous back when this system was new, and is indeed the EPROM that they used on the old T-Cards. How's that for a coincidence?
And on a different note: JLP ran fine for 3 days straight on my Intellivision I. Now I'm running it on my Intellivision II and so far it seems to be running just fine.
Now, I know these dsPIC33s and PIC24Hs have a small number of flash erase/reprogram cycles. So, I tried my spare chip and it also failed in precisely the same way. That meant I had a real bug. It was then that it clicked what the bug was.
I pack my 4K x 16 ROM hunks into 2731 word payloads in flash. I do this because the flash is 24 bits wide. This makes the most use of my flash storage. I pack words so that two 16-bit words are stored in the lower 16 bits of two output words, and a third word is stored straddling the two in the upper 8 bits. It works out pretty well.
Well, that's until that third word has its two halves on opposite sides of a 64K boundary. See, the PIC24 is a 16 bit machine at its heart, and so the upper 8 bits of the flash read address come from an 8 bit "table page" register that's separate from the index register. If you want to read two bytes from opposite sides of the 64K boundary, you need to update that other register manually. Otherwise you'll read the wrong byte. And that was what was happening. (It also explained why it was the ROM segment in the middle, since this is a 128K part and I'm filling it up as much as possible. 64K is smack dab in the middle of 128K.)
Rather than muck with that other register, I decided instead to pad out my ROM hunks to make them an even number of 24-bit words. That way I can ensure that any given pair of output words never straddles a 64K boundary. The padding word? 0xC0FFEE :-)
That makes my ROM hunks 2732 words long. Old school hackers should recognize that number. 2732 is the part number of the 4K EPROM that was ubiquitous back when this system was new, and is indeed the EPROM that they used on the old T-Cards. How's that for a coincidence?
And on a different note: JLP ran fine for 3 days straight on my Intellivision I. Now I'm running it on my Intellivision II and so far it seems to be running just fine.