CHIPCE-8: CHIP-8 interpreter for the PCE

[trapexit]

https://github.com/trapexit/chipce8

Something I was tinkering with a while back and finally got around to finishing. This version is currently done in HuC but I've got an assembly version in the works as well for comparison.

I also took the opportunity to document different CHIP-8 derivatives which were scattered among several sources for those interested.

Once I finish the assembly version I'll probably try to get SCHIP-8 fully implemented. Main issue is graphics.

[Necromancer]

Nice one.  Now rover won't have to finish his. 

[NightWolve]

Benefits of this are ?

[trapexit]

Benefits of this are ?

The ability to play shitty CHIP-8 games on the PCE.

[NightWolve]

Heh. Pass...

[trapexit]

I really had no expectation that people would actually use this. CHIP-8 wasn't very good when it was new. Fun learning about it and the COSMAC systems though.

I was thinking of attempting a RCA Studio II emulator. I've had one for years and it's similar to the COSMAC systems. That too would be for the fun given it's awful as well. Years ago I made a simple PC Parallel to PCE BRAM transfer app and cable. Was considering doing that again but with an Arduino. The bigger project I have in mind is recreating Bloodlust Software's pong game Nogginknockers. I'm friends with the artist so I could probably get him to modify the graphics for me.

[esteban]

I was not expecting this development. Hmmmm....

[Bonknuts]

Trap, this is really cool. I've looked over Chip-8 and it looks like a fun little system to emulate. At least for the sake of making an emulator/simulator/whatever.

The problem I'm seeing, is that some websites show the 64x32 res are square pixels (so a wide screen format) and some show this as rectangle pixels (0.5 pixel aspect ratio, full screen). Which one is correct?

[trapexit]

This is your new top priority, only with USB instead of Parallel.

Go ahead. Get started right away!!!

For real. This has been the unicorn I've been hunting for since the early 90's. You would be my hero, and that alone  would make the endeavor worth the effort, right?

Hah. I need to investigate Arduino more on how I could get the data to the PC. With my original I just had a simple cable connected to the joy port and parallel on the PC side with some simple software on each side (Linux for the PC). I actually was going to look into that next. I originally wanted to write something for the Turbo Everdrive but writing a FAT driver is more work than what I've in mind. Though raw writing to an SD card with the TE wouldn't be hard but not as nice.

Anyway... I'll look into it next.

[trapexit]

The problem I'm seeing, is that some websites show the 64x32 res are square pixels (so a wide screen format) and some show this as rectangle pixels (0.5 pixel aspect ratio, full screen). Which one is correct?

"fairly square"

http://www.old-computers.com/museum/doc.asp?c=543

128 is the maximum vertical resolution. Since video data was passed to the 1861 with an interrupt routine this vertical resolution could be lowered by passing the same row several times. Usually this resulted in resolutions like 64 x 16 (popular on single board Elf computers with only 256 bytes (!) RAM since this uses only 128 bytes for video memory). Typically 64 x 32 (256 bytes video RAM) or 64 x 64 (512 bytes video RAM) were used.
Only 64 x 32 produces huge, but fairly square pixels. All other modes are somewhat limited in use by the odd aspect ratios of the pixels. That and the video memory of one whole kilobyte made the maximum resolution of 64 x 128 fairly useless. The pixels were extremely wide and flat.

[trapexit]

User megatron-uk has a great start on a FAT driver. Semi functional if I recall correctly. It would be amazeballs if you could benefit from his work. I'd personally be fine with bram to sd.

Yup. I accidentally started an argument on the TEd forum about all that. Had just gotten my TE recently and asked for the firmware code to enhance the experience. In part to provide builtin bram transfer support. Got attacked for asking.

Anyway... I saw his work and forked his github repo. As last I checked write support was lacking. Just needs some love I'm sure. I did some quick research into working with SD cards a while back but got distracted with chipce8.

[Bonknuts]

Hmm.. so

If the PC Engine supported a resolution of 512x256 then we'd be able to map CHIP-8 pixels to all white or all black tiles. The closest we're able to get to that is 512x224 leaving us with a CHIP-8 pixel being 8x7 PC Engine pixels. Slightly lopsided but not distractingly so. Given the layout of pixel data in VRAM this works out reasonably well.

 If they are square, then you should be able to do a 64x32 nicely with an hsync interrupt. Run a 512 pixel res mode with a 64x32 tilemap. Two tiles (one all black pixels, one all white pixels) is all you need. 512/8 = 64 horizontal pixels. The 32 tall map is 256 pixels tall; too much for the PCE display. But since the pixels are square, just use an hsync line to cut them in half (only show 4 rows of pixels per map line). That should give the nice square pixel with wide screen look easily. Or is that what you're already doing?

 There's also a way to do this without hsync interrupts: by setting up the VDC line length to be shorter than the real length, halving the display by skipping every other line - works in mendafen too. I mean, if HuC is the problem here (h-int routine).

 Anyway, cool stuffs. Is there a library of games to try out for the SCHIP emulators?

[trapexit]

I created an 8x7 pixel at 512x224. Then just write directly to the tile's vram. It was easy and sufficiently fast.

Hadn't thought about about those ways. I've read quite a bit about the VDC but don't have much practical experience. Perhaps I should fool with those ideas.

chipce-8 doesn't yet support SCHIP-8. Once I figure out a good way to do 128x64...

I believe chip8.com has a big collection. I will be adding all the documentation I've found and roms to github soon. Seems chip8.com is down right now...

https://drive.google.com/file/d/0BxNcO7ALeiejeFVuU2VJWkk2Mm8/view?usp=sharing

[Bonknuts]

The reason why I bring it up (writing to the tilemap as pixels, rather than writing to tiles themselves), is that you can do 128x128 @241 color bitmap mode on the SGX. On the PCE, it's 64x128 @ 241 colors, or 128x64 @ 16colors (these two modes as setup different from each other). Coupled with VDMA, you can have an alt map in vram to write to and use VDMA to copy it over during vblank - giving a free double buffer bitmap function. With XOR patterned tiles (which is what the tilemap write references), you could double those colors or more (XOR dithering for 512 pixel mode looks decently convincing to a solid color). The best thing, is that you're only writing to the tilemap (or tilemap buffer in vram) with a fast single or double byte write for 1 or 2 pixels (depends on the setup you use). It's pretty fast.

[trapexit]

The reason why I bring it up (writing to the tilemap as pixels, rather than writing to tiles themselves), is that you can do 128x128 @241 color bitmap mode on the SGX. On the PCE, it's 64x128 @ 241 colors, or 128x64 @ 16colors (these two modes as setup different from each other). Coupled with VDMA, you can have an alt map in vram to write to and use VDMA to copy it over during vblank - giving a free double buffer bitmap function. With XOR patterned tiles (which is what the tilemap write references), you could double those colors or more (XOR dithering for 512 pixel mode looks decently convincing to a solid color). The best thing, is that you're only writing to the tilemap (or tilemap buffer in vram) with a fast single or double byte write for 1 or 2 pixels (depends on the setup you use). It's pretty fast.

I understand the concept. I originally wanted to do something like that but I'm not following how I can display the whole 64x32 or 128x64 tile map.