Something simple to emulate

[Rockthesmurf]

Does anyone have any suggestions of something relatively simple to emulate? I have an interest in this area, but getting into it is quite hard. I thought finding something as simple as possible to emulate, that I can do based on hardware documentation etc. would be rather interesting. I've never looked into this area before, so it really does have to be something crazily simple to start with (so please no Dreamcast, PS2, Xbox, etc. recommendations). Something with a simple, single CPU, blitting directly to VRAM, that has a very limited instruction set. I'm not looking to bring something new to the table, just do a bit of tinkering.

Any ideas?

Steve

 

[crow_riot]

chip-8 is said to be the "starter project" for emulation:

http://en.wikipedia.org/wiki/CHIP-8

http://www.multigesture.net/articles/how-to-write-an-emulator-chip-8-interpreter/

i've wanted to write an emulator for this on my own, like you, just to touch the area a bit. let me know how it goes

 

[elwing]

http://en.wikipedia.org/wiki/Pokémon_mini ?

edit: hardware and instruction description part:

http://wiki.sublab.net/index.php/Pokemon_Mini

re-edit: hum maybe not a so great idea, there's a PRC...

 

[Rockthesmurf]

http://en.wikipedia.org/wiki/Pokémon_mini ?


edit: hardware and instruction description part:

http://wiki.sublab.net/index.php/Pokemon_Mini

Potential problems:

'The hardware as engineered entirely in-house'

'The system is built around a 4mhz custom CPU'

'Through intensive reverse engineering the Pokémon Mini was hacked'

Sounds like it maybe quite a challenge for a first foray into this area. I feel it would be better to look at something with a fully documented CPU (gut feeling).

 

[EssoAir]

Write an emulator for an 8bit microchip. Like, where you write assembly (or machine) and it displays the output

 

[_jr_]

How about a CPU simulator first, perhaps like http://skilldrick.github.io/easy6502/ or http://www.visual6502.org/JSSim/?

I remember my brother showing me a graphical (well text mode with the CBM graphical char set) simulator of a simplified 6502 on his CBM 8032. That was totally cool

 

[CocoCreekFisherman]

CYBIKO emulator?...please?

 

[sebt3]

for myself, I would go an write a 68k emulator. But that might be because that's the only sane ASM I know. Also knowing the CPU would probably help me. Beside, the 68k is very well documented and have been emulated to death already. But the 68k is already an advenced CPU it might be already too complex for a start. maybe a 8bit CPU would be easier, i dont know.

Beside, are you looking to emulate the CPU or the full system (with IO, IRQ, bios and all) ? sure if you're looking for a full system, I wouldnt recommand a mac, so i guess a 68k will be too much

EDIT : that CHIP-8 sound cool. I would probably follow that track if I were you

 

[pmprog]

How about writing a scripting language/compiler/interpreter? This let's you build you own VM style, that you could also embed in your games to give you modding options etc.

 

[ekianjo]

Emulate a ZX80. That's a good place to start.

 

[Exophase]

Emulate a ZX80. That's a good place to start.

Yeah, something like this, if you want a device where the CPU blits into VRAM. I was actually going to recommend ZX Spectrum.

If you want to foray a little further into a console with real but very simple video and audio acceleration I recommend going with Sega Master System. If you start with Spectrum you'll even get to reuse the z80 emulation. The original Gameboy falls along similar lines, although a little more complex than SMS since you have to deal with cart mappers and somewhat more featured audio.

 

[ZXDunny]

Emulate a ZX80. That's a good place to start.

Yeah, something like this, if you want a device where the CPU blits into VRAM. I was actually going to recommend ZX Spectrum.

If you want to foray a little further into a console with real but very simple video and audio acceleration I recommend going with Sega Master System. If you start with Spectrum you'll even get to reuse the z80 emulation. The original Gameboy falls along similar lines, although a little more complex than SMS since you have to deal with cart mappers and somewhat more featured audio.

I'd recommend the Spectrum too. It's ridiculously simple to get going to the point where you can enter and run BASIC code, but gets more and more complex the more software you want to support right up to complex disk interfaces and complicated graphics routines that require T-State perfect emulation to run correctly (and you never know - you might discover something previously unknown; at least two models of Spectrum are nowhere near 100% accurately emulated yet).

That being said, I have a Chip-8 emulator written in Pascal you can crib from for ideas if you like

D.

 

[Rockthesmurf]

Wow, lots of suggestions, more than I anticipated. At the moment CHIP-8, followed by ZX80 seems like a reasonable direction to go in. Originally I was wondering about the Z80 or the 8080 but from a quick look CHIP-8 seems like it could be the easiest starting point.

The only reason I specified blitting directly into VRAM is for simplicity; I obviously know nothing about emulators at this point (hence the post) but my thinking was if it is just blitting directly into VRAM then I don't have to do any GPU/graphics emulation, I just make a texture from the VRAM and draw it to the screen. If I ever get to the point where I have the most basic stuff working, perhaps I'd be encouraged to look at something slightly more interesting.

 

[Exophase]

chip-8 is the easiest (you could probably get it up and running within a few hours) but frankly I say don't bother. I think it's beneath you, and not something you need to start with. It's a fake platform for which no native hardware exists and while it was around as a legitimate VM many years ago these days it's mostly just there to give coders a sense of satisfaction. I don't think you'll really learn much you don't already know.

 

[crow_riot]

I was also thinking abou if it was possible to emulate the whole chip-8 using opengl es, shader code and textures and fbo's, cause that would've been a novel approach (?) on doing this.


but then again, i know nothing about emulation and have dropped that ambition and am meanwhile back at playing around with emscripten

 

[Rockthesmurf]

@crow_riot completely off-topic but I recently added Crossbridge support to our engine at work, so we can now run all of our games in a browser albeit within a Flash window. I did very briefly look at Emscripten but had some difficulties getting it up and running on my Windows box (surely possible, but I decided to look at Crossbridge first). There is something quite weird/magical about seeing your full games running in a browser window somehow. If you have good experiences with Emscripted please share, I am still tempted to add support for it at some point, I love the idea of being able to run our games in a browser with no plugin.

@Exophase hmmm, I'll have a look at ZX80 and see how complicated it looks. Having something simple as a first stab is appealing. I wonder if I'll take on ZX80 and end up with nothing on screen and a lot of pain working out why.

I am tempted to document my progress tonight when I take a look at it, I am 99% sure it is going to read as a diary of shame of stupid mistakes, but if it is too embarrassing I can always keep the diary in the private domain. The more advanced parts of emulation interest me, but a mountain to climb before investigating those areas is possible.

 

[ZXDunny]

Getting a solid Z80 emulation is the starting point - but you have to plan beforehand. If you're only interested in ZX80 support then you'll not need to be terribly accurate, but if you plan on re-using your z80 core then you'll need to start looking at a minimum of 4 Tstates (clock cycles) accuracy for interleaving other hardware. The ZX80 didn't use anything special in the way of video hardware - it only supported text by writing bytes representing characters into video-ram - so if you're planning to stop there then you could have the emulation done inside of a week.

That said, if you're doing the ZX80 then it would be a shame not to add ZX81 support which was quite similar - and could do graphics but requires special synchronisation that would mean rewriting your z80 code if you've not planned for it. Spectrum is an altogether different beast and gets very complex as accuracy increases, to the point where we still haven't discovered everything that it could do, or how it gets those things done. The later Spectrums (+2A, +3 et al) are pretty much undiscovered country as far as CPU->RAM->ULA interaction goes.

Have fun

D.

 

[skeezix]

Arcade machine hardware is very dedicated, so is a good place to start imho. At least, it was where I started 20 years ago or whatever

ie: A Space Invaders emu is not so bad .. single cpu, some basic vblank based timing iirc, and a mono bitmapped screen buffer; you can get all the good bits from the mame (say) drive .c file, which should be very short for space invaders.

Or Phoenix, which uses a simple character-slot display; theres a image layer with a bytge value per cell, and a colour layer to map it through a colour PROM, IIRC. The graphic layer .. theres two really, one for scrolling background (module%register, very easy to do, to get the effective y address of image to display), and the sprite layer. Very easy to decode sprites and render everything.

Anyway, those are my suggestions; some machins are deceptively complex .. like Atari 2600 or Vic-20, but some are easy as heck.

jeff

 

[skeezix]

And remember.. a basic emu is just a statemachine. A cpu emu is..

- fetch (read from memory_array [ address ] ) .. though memory may be mirrored, mapped through devicves etc.. so you use a macro or if/switch/tableetc to handle the lookup and map it to the right thing

- decode (mask out the good bits, to figure out what the opcode will be, and if it needs another byte or not etc.)

- handle the opcode (if its a sum, and you've got a couple registers, add 'em up)

... repeat

opcodes are very specific, so not hard to implement.. but theres a lot of them and a lot of similairy (you'll have 16 or 30 sum operations, all nearly the same but different opcodes.. indexed throgh memory, or immediate, or whatever.)  I usually ended up writing a simple human-readable macro file, and having a script convert it into code and write out all the boilerplate. Used to be you'd do crazy loop unrolling and minimize functiona call ov erheads to get speedups, but with modern caching and such.. dont' get clever   The actual harder part is keeping track of timing (incrementing your cycle counter properly for each opcode use), handling interupt and NMI's (if the cpu has that) .. but somethign like a 6502 is pretty darned easy to implement in a few hundred lines of code.

jeff

 

[Rockthesmurf]

Decided to start with Chip-8, which is probably an indication of a my downward decent by ignoring Exophase's first piece of advise. My thoughts were if I end up doing it very quickly and not learn anything then at least I didn't use much time. If it ends up taking some amount of time, I will likely be learning so it is all good.

About 2h 30m in so far and have some instructions being decoded, been making some notes of what happens on the way, already had lots of impressive errors, like the fact I haven't used raw C file IO in a very long time (used to going through in house file API), and couldn't work out why fread refused to read the amount of bytes I asked file, eventually remembered about "r" vs "rb".  Also didn't bother checking endian before starting, that wasn't clever, but not too costly either... At my current rate of progress, I am guessing it will be around 5-10 hours to implement the rest of the instructions. And then probably another 5-10 hours to tie up what is required to render to texture, take input etc. My ideal result is some very bad code that manages to load my test pong ROM. Hopefully I'll know why the code is bad and be ready to take on the next difficulty level machine...!