-Separated cartridge logic into a separate ICart named Cartridge.cs.
-Made WriteMemory return a bool to match ICart.Write. It currently returns true if either the cart or the core responded.
TODO: Parse the vanilla Intellivision ROM, which will hopefully include the read / writability of the data segments. adelikat seems to think that I just need to send the bytes to $5000, but I'm not convinced.
-Made it so that the indirect ops other than MVO@ decrement R6 when it's the mem address. Indirect write means writing to a register apparently, so maybe the documentation don't contradict itself.
-Fixed my disassembly of branch; I wasn't thinking in hexadecimal. >_<
-Subtracted 1 from the negated offset when branching in reverse. The next op is "BNEQ $FFFC".
-Fixed the branching disassembly; the direction just negates the offset and the second parameter only belongs to BEXT. All of my sources contradict each other, but this seems sensible.
-Applied to the old Gameboy core. Why not? It at least fixes that annoying bug from before if we ever care to use it again.
-Both logs are now written to different files.
--It now just builds a strings and writes on finalization.
-Fixed up format strings.
-As RegisterPC already increments upon reading the third decle, I now just store PC as the return address for jumping instead of PC + 1.
-Retrieved the double bit from the swap / shift / rotate instructions in a more proper way.
TODO: Use more specific variables; most of them suck, and with these docs, I have better names for them.
-Disabled Intellicart hook for ReadMemory, which seemed to be interfering.
-Implemented MVO@.
-Several instructions are now executed in succession until it hits the unimplemented "XORR R5, R5".
I should probably refactor Disassemble and Execute to label registers as source / destination to avoid further confusion at some point. My disassembly might have the source / destination registers flipped as well.
-They both seem to work, but the operands for AND@ are both 0, so this seems fishy.
-I don't know for sure if AND@ executes cycles in the same way that MVI@ as the documentation isn't clear on this, but I assumed it did.
According to my disassembler, the first 5 instructions run on the Executive ROM are:
JSRD R5, $1026
MVI@ R7, R6
ADD@ R6, R1
JSR R5, $1A83
HLT
Considering that I hit a HLT, I figure something is going terribly wrong. Perhaps it has to do with my lack of an interrupt system?
-Added bytesToAdvance assignments to the relevant opcodes I added yesterday.
TODO: Implement more stuff in Execute and use the Executive ROM as a test case.
-Fixed disassembly for JMP:
--Now it uses the parameter pc, not RegisterPC.
--I was loading both the second and third value from the second's address.
--Casting the calculated addresses to bytes when addresses are 16-bit was a bad idea.
--Removed a closing parenthesis I accidentally stuck in the formatting.
It seems that I've gotten far enough to use the Executive ROM as a test case! Now to go instruction by instruction and see if they work as planned and hope this will all eventually make something.
--Afterwards, the data is reconciled, right now by chucking out the core value if the cart responded.
-WriteMemory now writes to both the core and the cart unconditionally.
--Each case now breaks out of the switch statement in case we want to do more complex things at the end of the function later on.
-All default paths in both functions now throw an exception.
-Implemented the final CRC check.
I didn't get around to implementing bank-switched ranges, but I don't think it's worth worrying about that right now considering that the Intellicart is not marked as readable at the initial PC, so something is either wrong or I need to implement more things before this will work. I think I'll put Intellicarts on hold and try to get a .int / .bin to run in the meantime.
--In my test case, only a few segments were set to readable and nothing else was set. 0x1000, which is where the PC is initialized to, certainly isn't in a writable page.
--Although I've read that these memory attributes affect the Intellivision and not the Intellicart, I'm pretty sure this has to be implemented in the Intellicart so that my Read/WriteCart functions can choose to respond / not respond depending on these attributes. I very well could be wrong.
-Hooked Read/WriteCart into Read/WriteMemory.
-Implemented memory attributes into Read/WriteCart.
--TODO: Bank-switching.
TODO: Fine address table and memory attribute / fine address checksums.
adelikat