Commit Graph

33 Commits

Author SHA1 Message Date
brandman211 fd6201c703 Implemented what to do on an interrupt. This seems to be logical as it tries to execute a GSWD instruction, but it takes the interrupt too early because I haven't figured out when to turn INTRM on / off. 2012-08-13 03:47:08 +00:00
brandman211 0d20c133a5 -Moved the reset address to the CP1610 and made RegisterSP/PC private.
-Created helper functions for indirect ops; Indirect_Set will be needed for interrupts.
2012-08-06 15:51:35 +00:00
brandman211 a19b76e6cc Added Interruptible and assigned it for every op. 2012-08-05 07:04:03 +00:00
brandman211 e9a8980f0c -Throw exceptions for TCI, SIN, and BEXT.
-Added and logged INTRM, BUSRQ, BUSAK, and MSYNC.
2012-08-05 06:47:00 +00:00
brandman211 b83bb1901d -When neither the cartridge nor hardware responds to a read, it now returns 0xFFFF instead of throwing an exception.
-I will now assume that 0x7000 is not mapped for the sake of continuing on. I will need to implement a mapper system shortly though.
--Did the same thing for 0x4800.
-AND@, MOVR, CMP enabled.
-Made the logging separator generate before an instruction instead of after the register states. This is quite petty, but I don't like the separator at the end of the file.

I hit an infinite loop, and I'm very very certain it's happening because I don't have an interrupt system yet. Time to stop avoiding that!
2012-08-05 05:59:55 +00:00
brandman211 f66d92f2a5 Started filling the gaps in the Memory Map, getting up to 0x7FFF. Once complete, a lot of TODOs remain, the most important being the actual mapping of the cartridge. 2012-07-30 22:25:00 +00:00
brandman211 8306768c76 Enabled SWAP. Works as expected, but the next instruction is an MVI@ that wants to read from 0x7000, which I think is made available to cartridges. Not sure where to go from here. 2012-07-30 02:34:53 +00:00
brandman211 b1db1b7a69 -Reversed the double byte data bytes. It now works properly.
-Set the D flag to clear one instruction after it's set; SDBD is a prefix instruction.
2012-07-29 00:02:06 +00:00
brandman211 53c0dd5ee0 -Enabled the ops that merely set / clear flags...there's no way I could have messed those up.
-Tested and implemented the MVO op.
-Implemented the other direct ops.

I think my double byte data handling isn't working. Will diagnose.
2012-07-28 17:50:32 +00:00
brandman211 748efbcd20 -Fixed the overflow calculation for ADDR, SUBR, and CMPR.
-Implemented the remaining XXX@ ops.
2012-07-28 17:20:16 +00:00
brandman211 188e5662ca It seems that indirect writes decrement the stack pointer BEFORE reading memory. 2012-07-28 17:06:06 +00:00
brandman211 0d10eee747 -Implemented branching and tested BNEQ. BEXT not implemented.
-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.
2012-07-28 04:18:13 +00:00
brandman211 4864aaa291 -Enabled and tested DECR.
-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".
2012-07-27 04:46:44 +00:00
brandman211 4d1f0114c4 R4-R7 now auto-increment for all of the indirect opcodes. My documentation is inconsistent on whether R6 increments or decrements on right, but in any case, my output now matches my source until the DECR, which hasn't been implemented yet. 2012-07-27 04:07:06 +00:00
brandman211 3a56f65c3f Implemented the XXXR opcodes. As of now, I have Jump, MVO@, MVI@, and XORR enabled and tested. There might be an off by one error with MVO@. 2012-07-27 03:33:24 +00:00
brandman211 b96e014327 -Reverted disassembly printout as it'll now match up with my comparison.
-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.
2012-07-24 05:29:24 +00:00
brandman211 d469a4e568 -Put the disassembly in parenthesis and put the opcode to the left of it in the logs. This is uglier, but it's initially easier for comparison this way.
-RegisterSP now increments in MVO@ instead of decrements. I'm not sure how this allows the stack to function properly, but it seems to work.
2012-07-24 03:05:57 +00:00
brandman211 743480e26f -Logging now uses a static StreamWriter instead of building the string and writing on destruction.
-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.
2012-07-22 18:40:28 +00:00
brandman211 9f2bcf3318 -Fixed logging.
--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.
2012-07-22 18:08:10 +00:00
brandman211 60c5a1ce58 Added logging for the CP1610. Not working for some reason. 2012-07-22 17:18:11 +00:00
brandman211 0a0763966c -Refactored of the executor / disassembler / Intellicart to use more descriptive variable names and types to clear up a lot of confusion.
-Added implementation for NOP (6 cycles of nothing).
-Made SWAP actually store the result (Still disabled).
-Added breaks to the swap / shift / rotate cases (Yikes).

Instruction disassembly:

JSRD R5, $1026
MVI@ R7, R6
JSR R5, $1A83
MVO@ R5, R6
MVO@ R0, R6
MVO@ R1, R6
MVI@ R7, R4
MVI@ R7, R0
JSR R5, $1738
MVO@ R5, R6
XORR R5, R5 <- Needs implementation.
2012-07-21 05:25:52 +00:00
brandman211 259ec356bd -Updated the disassembly based on a more accurate resource.
-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.
2012-07-20 23:06:59 +00:00
brandman211 610acf6ad6 -Made MVI@ and ADD@ follow the stack and immediate mode rules for incrementing / decrementing the SP / PC.
-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.
2012-07-20 07:22:41 +00:00
brandman211 b2323458ba Implemented / tested MVI@ and AND@.
-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?
2012-07-20 05:02:26 +00:00
brandman211 10274734f9 -My jumping seems to work, so I enabled it in Execute.
-Finished the disassembler except for branching.
-Merged the XXXI instructions with XXX@ for R7 as the address register as they are redundant.
2012-07-19 06:58:14 +00:00
brandman211 9b8a9d93f1 Opcodes up to 0x07F. 2012-07-09 03:27:27 +00:00
brandman211 bb532aa2d9 Opcodes up to 0x5F. 2012-07-08 21:49:09 +00:00
brandman211 61cada6190 -Made HLT throw an exception.
-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.
2012-07-08 19:52:12 +00:00
brandman211 a4912e66c0 -Wasn't supposed to actually increment the PC in the disassembler.
-Cleaned up the 0x004 (Jump) disassembler.
-Implemented 0x004 in the executor.
2012-07-08 08:42:32 +00:00
brandman211 778274a12d -Set up the disassembly decoder just like the executor.
-Disassembled opcodes up to and including 0x7.
2012-07-08 08:17:07 +00:00
brandman211 8d254113c2 Finished the opcode decoder. Over a thousand lines in one day...now just to make them do stuff! 2012-07-08 03:53:12 +00:00
brandman211 1c480c98b4 -Created functions for calculating the flags.
-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.
2012-07-08 01:58:06 +00:00
brandman211 2457c68ed7 Starting IntelliHawk with the CP1610, using the other processors in BizHawk, BlissJ, and this (http://wiki.intellivision.us/index.php?title=CP1610) page as references.
-Definitions.
--Registers, Flags, TotalExecutedCycles, PendingCycles, ReadMemory, and WriteMemory.
-Execute.
--Implemented opcodes 0x001-0x027 with the exception of 0x004 and 0x005.
2012-07-08 00:36:16 +00:00