EEC-IV and EEC-V Hardware Notes/talk

[jsa]

You mentioned disassembly as you emulate. The bins contain plenty of unused code that will normally be bypassed by emulation.

Cal console check is in 8065 bins, so they likely continued to use it. CART, EBC or whatever does not have the bandwidth or features of full datastream and control provided on J3.

[DWS]

Yes, if all logic paths are branched and covered, and "code" is never hit, then from the cpu's point of view the code doesn't really exist and it just filler. I've seen dead code in SAD, marked it for disassembly and it's stripped code that the main structure exists but the registers and memory addresses are junk, been a while since I poked at that, but I think it was filled with R0's and such. I'm unsure if there's other ways to jump to code that isn't in the actual code, for example, the code I was posting before loads part of the rom data into ram, then runs from ram. The ram data would be disassembled as it runs, but the actual data source on the rom would be a special case to work out, like mark it as code but maybe identify it as loaded from rom to ram to mark it as a "ram" program in some way, or something along those lines. I'm sure there's several special cases like that which are hard to catch (SAD doesn't catch the orig ram code either I'm pretty sure, I'd have to double check source rom address if that's outside of the current design).

Interesting about the cal console on later computers. I haven't poked around that area yet.

[jsa]

Your explanation of SAD not handling RAM executed code is why I'm interested in the ID details. Zero chance of SAD getting a fix without the bin to run development versions against.