yo dawg i heard you like emulation so i put an emulator in your emulator so you can emulate while you emulate
++~~**//ROM DOWNLOAD\\**~~++ hardware controller bug fixed
Quick control overview:
Start to go forward a ROM
Select to go backwards a ROM
I manually gave each ROM a custom control layout which hopefully is intuitive (as the system officially contains 16 keys).
What on earth is this?
The "Super Chip8x" (name subject to change?) is an emulator for the Chip-8
written for the SNES as a homebrew ROM. It's capable of emulating all (regular) chip-8 ROMs including sound.
The chip-8 ROMs are included within the homebrew ROM as the system isn't really copyrighted.
What is the chip-8?
In very simple terms, it's a virtual system which uses a 64x32 screen to display stuff. The system actually doesn't physically exist, but the specifications are simple and adequate enough for emulation. It's like the "hello world!" of programming. I referred to this document
for the technical specifications.
How are its memory and opcodes?
The memory is a feeble 0x1000 bytes, 0x200 of which is "reserved for the interpreter". In modern emulation, it contains the 0-9A-F characters at offset 0.
It may be a feeble 0x1000 bytes, but it's more than enough room for the chip-8. Each opcode (including its parameter) is two bytes, and sprites are at least 1 byte, at most 15 bytes - each byte is one row of pixels of the sprite drawn.
How do the display and sprites work?
The system isn't tile-based. It doesn't tell the screen to "draw a tile at X Y with graphics Z" or whatever, rather, it's pure coordinate-based pixel drawing. The screen is one big tile, if you will.
The pixels that are drawn on the screen are "sprites". Sprites are 8 tiles wide and 1-15 tiles high and can be drawn anywhere on the screen. There's no actual memory which keeps track of sprites.
The pixels only have two colors, "on" and "off" for simplicity's sake. The system XORs pixels to the screen i.e. if you write a pixel to a coordinate which contains a pixel already, the existing pixel gets un-drawn. This sets the collision flag. Thus, this is how the system also checks for collisions between sprites.
This means that if you want a 'moving' sprite, you'll first have to undraw the existing sprite (by drawing over the exact copy of the sprite over the existing sprite), increase some value in the RAM, then draw the sprite on the screen again. This is what causes the flickering of moving sprites.
What is its clock speed?
There is no defined speed, so it is up to the author of the emulator to define one. 10 opcodes per frame is the sweet spot for me.
Here are some more screenshots:
There are more ROMs, some of which are debug ROMs (such as keypad, RNG and BCD testing).
The "VBRIX" game sometimes doesn't spawn the ball and I absolutely have no idea why. It's seemingly random. The VBRIX ROM itself might need debugging.
The "RUSH HOUR" game seems to have trouble handling two button presses at the same time. You need to press a button and use the D pad to move blocks, but you can't seem to do that on my emulator. It's weird because I don't think the system is supposed to keep track of multiple button presses to begin with, but I could be wrong, in which case I'll have to rewrite the entire controller subroutines just to make this game work ®_®
The screen setup
I was really worried about how I would present a 64x32 screen on the SNES, until p4plus2 mentioned I could use mode 7 and scale the screen 2x. I thought it was a pretty damn good idea.
I spent an entire day trying to this one out. Once I started to draw squares/a grid on my whiteboard it finally hit me: My math should be made from two portions: one which selects the SNES tile number, and one which selects the pixel within that tile.
One opcode behaving weird until I looked closer
Don't forget your RTS and RTL, people.
The entire project
I'm surprised I got this far to begin with. I've never completely finished a SNES homebrew ROM before. I guess I can cross this off on my bucket list now.
I originally was looking into emulation in general because I had a certain SNES project in mind (which you'll probably see some other C3?). Google Now suggested me a certain chip-8 article which sparked my interest and I got sidetracked from there thinking "hey, this system could very well be emulated on the SNES!". I finished this in less than a month.
I did have to reference the source code of other emulators in the beginning but it was a learning process to begin with. I also had to borrow 2-3 routines from SMW which I think is pretty funny.
All in all, being able to legitimately write the words "written entirely in the 65c816 assembly language" makes me proud as a programmer.