-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.
-Fixed JMP disassembly; I need to return on an invalid opcode because I was breaking out of the inner switch statement, not both that and the outer one.
-Made all instructions in the executor, even implemented ones, throw exceptions. I will get rid of the exceptions as I test the instructions.
-Added instructions up to and including 0x57 to disassembly and executor.
-Implemented ADCR.
-Decoded all opcodes up to 0x23F.
TODO: Try vecna's idea of testing the instructions by running a game and implementing instructions as I need them...but first I'll need to implement loading of an Intellivision game.
-Definitions.
--Registers, Flags, TotalExecutedCycles, PendingCycles, ReadMemory, and WriteMemory.
-Execute.
--Implemented opcodes 0x001-0x027 with the exception of 0x004 and 0x005.
-Made it so that the log only opens when logging is true and that the file closes upon destruction.
--Still, BizHawk says that it can't open the file again when I load a game again. This is because the emulator class gets recreated without deleting the original one every time you load a game.
---adelikat convinced me not to care about this.
-Fixed the initial state of the GB CPU:
--It was setting AF to 0x01, not A. This is effectively setting F to 0x01, which gets overwritten later anyway.
--Two BIOS flags were used in different places; merging them gets the PC to start in the right place.
-By fixing the initial state, most of the log now matches up.
--The only differences are the VBA has some repeated records (Where all of the registers, including PC, are the same as the previous record) whereas BizHawk doesn't.
--This very well might be an issue with how I'm logging it
--Alternatively, it could be some kind of lagging mechanism.
--I'm not sure which version is even correct...VBA is far from accruate.
--All in all, considering that the vast majority of the diff comes out as the same, I think I fixed the biggest CPU related bug. Will investigate more later.
MOS6507: now executes instructions on the last cycle. This corrects a syncing issue with the TIA
TIA: added ball data, partially implemented HMOVE, implemented VBLANK
It is quite insufficient, but at least, we have to increment program counter appropriately.
For immediate addressing mode, it will be correct. For other addressing modes, I don't know whether they access memory, so further investigation will be needed.
brandman211