REQ: Emu coding

[Madman]

Im curious about emulator programming. Is there some website to get one started ? Prolly quite a dumb question, but i got no idea what to start with ?

Opening roms and parsing the contents ?

What about the code ? Dont i have to code the chip somehow ?

Would greatly appreciated any help and or hints on this topic.

[Agozer]

Nowadays, you don't always have to code the CPU code from scrath, since someone has most likely done it for you. http://www.zophar.net/windos.phtml

 

Check under CPU.

 

Sadly, Zophar doesn't want to admit that the site is basically dead when it comes to news, and their TechDocs section is out of commission it seems.

[Madman]

yeah, Zophar lol, i wonder why that site is still online. Sure has some nice pages, but its way outdated.

Anyway, problem for me is,the sourcecode for a fully working emu is a bit much. It has dozends of lines of codes one doesnt understand, unless you know the hardware of the emulated system in and out, up and down.

 

I found a rather plain intro here: http://fms.komkon.org/EMUL8/HOWTO.html

 

But i must admit that this sounds more like hard work than fun

Sure, cant beat that feeling, when your emu actually plays something, but i dont know all these details about any consoles or comps hardware that seems to be needed, so screw it. Im not the guy who finds it interesting, to know how many dots an odd or even scanline may system X have in PAL and/or NTSC mode.

Maybe i can learn to know some system, when i have nothing to do at work. Is an hour now and then, so maybe some day...

 

Now I'd would be nice to know, what system is the most easies to emulate ?

My guess would go on GameBoy here, afaik it has a 6502 CPU, same that was used in the C64 days and i even did some assembly back then.

Sure forgot like everything about it in the past 15 years

[Agozer]

Gameboy is by far the easiest to emulate out of all the handhelds/consoles.

[Madman]

yeah, it sucks too, but its something to start with

[Madman]

Oh well, i found some GameBoy emu with source in VB.

Its like VB6 and way outdated, but well, the sourcecode looks like its more like a pain to code an emu than fun. Looks like you simply (?) line up a ton of if-then-else querys. See attached file, especially 2nd half.

 

Well, i think i forget about emu coding then.

Grfx.txt

Edited October 24, 2005 by Madman

[TheChuckster]

I thought Gameboy had a Z80. I learned a lot porting Stella to the DS. Emulation is a black art. There aren't any books or tutorials on it. What you need to know is how a computer WORKS. You need to know Assembly and what the various components like the CPU, RAM, and various I/O devices do and how they interact. You also need to know how to perform arithmetic on hex and binary numbers.

 

The best way is to learn Assembly. It doesn't get much lower level than that. You don't have to code your emulator in Assembly, but it is a very good teaching tool for the above prerequisite knowledge.

 

Really what you want to do is parse the ROM and load ("copy") it into an array representing the machine's memory. To emulate the CPU, begin by declaring registers, setting the Instruction Pointer, and fetching and "emulating" each opcode.

 

Let's say you encounter C3 at the IP location. On the Z80, that is the opcode for jp. Easy enough. Fetch the next 2 bytes and change the IP to the address stored in them. Eventually you're going to want to count cycles so that you have consistent timing going.

 

You're probably going to want to expand on the CPU to do something more than just jump. You'll need interrupts emulated as well. Games use interrupts such as the VBlank and Timer interrupts to do event-based routines. The RAM might be more complicated as well. Reads and writes will need to consider mirrored memory, read-only memory, hardware mapped memory (I'll get to that in a second), and bankswitching/paging.

 

As far as video goes, lets say we have a framebuffer (easiest example) that contains bits representing a 256x128 monochrome display at say memory address 300000. What you need your emulator to do is to check the contents of that every frame and update the onscreen display using routines for what ever graphics library you're using (SDL? libnds?).

 

Data can be anything. It's all about how we (the user and the programmer) interpret it. To the computer it could be code or a piece of stored information such as a document or sprite (to stick with the game theme). Knowing that "philosophy" is key to knowing the computer at its lowest level.

 

That's programming an emulator in a nut shell. Providing you're not hand-coding every opcode or squashing that minor glitch bug that you just cannot seem to figure out the cause to, emulator programming can be quite a fun and worthwhile pursuit. I hope somebody finds what I have written useful to them. It should give you a good start.

[Madman]

Yeah wll, i know some Assembler, but that was like 15 years ago, on 6502. I remember very few commands like STX, STY, JSR and the like, but i think, to learn all this low level stuff, you must be either in business of game programming or be addicted.

Im a big emu fan, but i dont have the time to learn that much about any console in detail.

 

The reason why i considered doing an emu, is the lack of some project to work on. Im into VB.NET/C# and want to do something on it, but heck, i dunno what to code.

I dont have the intense to code the millionth calculator, zipper or other crap. I need something i am hooked on and willing to work on. So far i did not find anything. Its annoying.

 

I was thinking to bless the scene with a useable SID manager, but there is hardly any info on the sidplay lib.

[TheChuckster]

Yeah, I'd say I'm addicted...

[Madman]

Good thing that is. But with a wife and 2 kids, you'd be low on time too

[Weirdy]

yeah and usually the gui's are made in C++ or C, everything else is assembly