Rockthesmurf
Advanced Member
Just my internal notes, nothing useful to anyone else, but my fumbles so far..
3rd September, 2013
18:52 Create Visual Studio Project
18:54 Reading http://en.wikipedia.org/wiki/CHIP-8
19:00 Implement switch table for instructions
20:00 Find a ROM to run through our disassembler
20:10 Pong rom seems tiny! Is this right???
20:20 Running pong through asserts on bad instruction
20:25 Trying to find out endian of machine
20:27 Assuming endian flipping required, it then generates 16 sensible instructions:
Set v10 to 2
Set v11 to 12
Set v12 to 63
Set v13 to 12
Set i to 0x2ea
Draw sprite at v10,v11 width 8, height 6
Draw sprite at v12,v13 width 8, height 6
Set v14 to 0
Call sub routine to 0x2d4
Set v06 to 3
Set v08 to 2
Set v00 to 96
Set delay timer to v00
Set v00 to value of the delay timer
Skips next instruction if v00 equals 0
Jump to 0x2cd
It then read garbage (it doesn't follow jumps at this point, so it would
appear some non instructions follow before 0x2cd or 0x2d4)
From Wiki:
Memory : 200h to FFFh <-- So jumps to 0x2cd/0x2df are possibly assuming ROM loaded at 0x200 ?
20:31 Thinking it would be best to allocate a chunk of memory, then index into this
memory, so first instruction would be at g_Memory[ 0x200 ]
20:34 Also wondering if endian flipping required for addresses in format NNN
20:35 Start fixing up instructions
20:47 Quick debug revals sub routine address of 0x2d4 so don't need to endian flip
20:53 Realised this rom (which seems tiny) pong.ch8 is 0x200 -> 0x2f5 so address
0x2d4 is past end of ROM, hmmmmm
20:57 Maybe 0x2d4 is a byte offset, not a 16 bit pointer offset.
21:03 With byte offset addresses we end up with recurisve sub routines calls to 0x200..
21:06 Recursive 0x200 calls just a bug, however 0x2d4 isn't going to valid instruction,
checked rom in hex editor and offset 0xd4 has data, must be doing something stupid
when loading.
21:11 ROM loading wrong, trying to work out why (haven't used bare C IO for ages)
21:18 Ah, "r" vs "rb" when opening file...! Has anyone ever not wanted the 'b' version?!
21:19 Doh, 0x2d4 is of course valid (less than 0x2f5 was getting confused by bad fread)
21:20 Sub routine seems to call propery now with stack pointer being restored, only
implemented half a dozen instructions so far.
21:34 Code gets as far as waiting for delay timer to reach 0, although timers are
implemented yet. Going to implement some more of the easy instructions first.
21:36 Stopping for dinner.
22:30 Looking into carry/borrow flags.
Thoughts:
Carry:
u8 a, b;
u16 r = a + b
reg carry = r > 0xff
u8 result = r & 0xff
Borrow
u8 a, b
u8 result = a - b
reg borrow = b > a
22:40 Implementing sound/delay timer registers
22:50 Now have program waiting for input.
23:15 Implemented everything except:
- Screen clear
- Calls RCA 1802 program at address (different from jump or sub routine call how?)
- Draw sprite
- Skip instruction if key pressed
- Skip instruction if key not pressed
- Await key press and then store
- Set I to location of 4x5 font sprite for character in reg X
23:16 Finishing up for the night, would like to look at getting some GFX on screen next.
18:52 Create Visual Studio Project
18:54 Reading http://en.wikipedia.org/wiki/CHIP-8
19:00 Implement switch table for instructions
20:00 Find a ROM to run through our disassembler
20:10 Pong rom seems tiny! Is this right???
20:20 Running pong through asserts on bad instruction
20:25 Trying to find out endian of machine
20:27 Assuming endian flipping required, it then generates 16 sensible instructions:
Set v10 to 2
Set v11 to 12
Set v12 to 63
Set v13 to 12
Set i to 0x2ea
Draw sprite at v10,v11 width 8, height 6
Draw sprite at v12,v13 width 8, height 6
Set v14 to 0
Call sub routine to 0x2d4
Set v06 to 3
Set v08 to 2
Set v00 to 96
Set delay timer to v00
Set v00 to value of the delay timer
Skips next instruction if v00 equals 0
Jump to 0x2cd
It then read garbage (it doesn't follow jumps at this point, so it would
appear some non instructions follow before 0x2cd or 0x2d4)
From Wiki:
Memory : 200h to FFFh <-- So jumps to 0x2cd/0x2df are possibly assuming ROM loaded at 0x200 ?
20:31 Thinking it would be best to allocate a chunk of memory, then index into this
memory, so first instruction would be at g_Memory[ 0x200 ]
20:34 Also wondering if endian flipping required for addresses in format NNN
20:35 Start fixing up instructions
20:47 Quick debug revals sub routine address of 0x2d4 so don't need to endian flip
20:53 Realised this rom (which seems tiny) pong.ch8 is 0x200 -> 0x2f5 so address
0x2d4 is past end of ROM, hmmmmm
20:57 Maybe 0x2d4 is a byte offset, not a 16 bit pointer offset.
21:03 With byte offset addresses we end up with recurisve sub routines calls to 0x200..
21:06 Recursive 0x200 calls just a bug, however 0x2d4 isn't going to valid instruction,
checked rom in hex editor and offset 0xd4 has data, must be doing something stupid
when loading.
21:11 ROM loading wrong, trying to work out why (haven't used bare C IO for ages)
21:18 Ah, "r" vs "rb" when opening file...! Has anyone ever not wanted the 'b' version?!
21:19 Doh, 0x2d4 is of course valid (less than 0x2f5 was getting confused by bad fread)
21:20 Sub routine seems to call propery now with stack pointer being restored, only
implemented half a dozen instructions so far.
21:34 Code gets as far as waiting for delay timer to reach 0, although timers are
implemented yet. Going to implement some more of the easy instructions first.
21:36 Stopping for dinner.
22:30 Looking into carry/borrow flags.
Thoughts:
Carry:
u8 a, b;
u16 r = a + b
reg carry = r > 0xff
u8 result = r & 0xff
Borrow
u8 a, b
u8 result = a - b
reg borrow = b > a
22:40 Implementing sound/delay timer registers
22:50 Now have program waiting for input.
23:15 Implemented everything except:
- Screen clear
- Calls RCA 1802 program at address (different from jump or sub routine call how?)
- Draw sprite
- Skip instruction if key pressed
- Skip instruction if key not pressed
- Await key press and then store
- Set I to location of 4x5 font sprite for character in reg X
23:16 Finishing up for the night, would like to look at getting some GFX on screen next.
.
