NES/other console emulators on an 8086..?

[Raven]

I'm using a VGA card in the 8086 I was talking about, btw.

It's a Tandy 1000 RL/HD which I popped a VGA card into to make usable, as the wonky PCjr-style CGA I had no monitor for.

 

[carlsson]

the 8088 needs 4 cycles per memory access and CGA video memory requires a wait state -- the end result would be unusably slow.

Hopefully the 8088 machine code will be slightly more efficient per cycle than 6502 (well, 2A03) code is. That means even if the CPU takes a lot of clock cycles, perhaps it gets more done without shuffling registers and accumulators back and forth. An IBM PC also runs at 4.77 MHz compared to a NES at 1.78 MHz, so what takes 4 clock cycles on a 8088 may not take more than 1.5 cycles on a 6502.

 

[Trixter]

Hopefully the 8088 machine code will be slightly more efficient per cycle than 6502 (well, 2A03) code is. That means even if the CPU takes a lot of clock cycles, perhaps it gets more done without shuffling registers and accumulators back and forth. An IBM PC also runs at 4.77 MHz compared to a NES at 1.78 MHz, so what takes 4 clock cycles on a 8088 may not take more than 1.5 cycles on a 6502.

Unfortunately, it's a bit worse than that. A C64 and a 4.77MHz 8088 are roughly the same overall speed because most instructions on 8088 take an average of 8 cycles to execute (4 for the opcode fetch, 2-4 to execute). Memory taking 4 cycles per byte really blows. Compare that to the c64 in which most instructions and memory accesses are, what, 1 or 2 cycles?

The only advantage an 8088 has over a C64 (in terms of processing speed) are a real MUL, DIV, and 16-bit registers.

8086s have more "awesome" because they can fetch two bytes in 4 cycles as opposed to one byte. I remember with one benchmark, my 7.16MHz 8086 clone was 1.9x faster than my 4.77MHz 8088.

I really need to find some time to write that benchmark :-/

 

[Fallo]

Unfortunately, it's a bit worse than that. A C64 and a 4.77MHz 8088 are roughly the same overall speed because most instructions on 8088 take an average of 8 cycles to execute (4 for the opcode fetch, 2-4 to execute). Memory taking 4 cycles per byte really blows. Compare that to the c64 in which most instructions and memory accesses are, what, 1 or 2 cycles?

The 8088 _is_ faster than a 6502, but only by a little bit.

The only advantage an 8088 has over a C64 (in terms of processing speed) are a real MUL, DIV, and 16-bit registers.

And a much bigger address space (64k against 1MB) and a bigger and easier to use instruction set. The MUL and DIV instructions are very slow and useless since the 8088 has no hardware multiply or divide, and relies on microcode for them. You'll get better performance using bit shift instructions (which is how multiplication and division are done on the 6502, anyway), although it takes a bit more memory.

 

[barythrin]

Kind of interesting when you think about it. I've never done emulation coding (I'm not any cpu/ML expert, just an infrequent code junkie that used to write quick PoC stuff for kicks). So my initial assumption was that an emulator would read the bytes of the binary file and then emulate things live. Obviously taking a few extra cycles to convert commands, etc.

I was trying to think what one could do to optimize this, and while it would take longer load time, what if it read the file and wrote a converted output to run. I guess it'd just be a cross-compiler instead of an emulator but THEN all the code is realtime, no conversion necessary. Then I wonder what it'd be like (besides color palettes being kinda wrong and I'm not sure what could be done for sound).

 

[Mike Chambers]

However, I'd LOVE to see someone try and emulate an NES on a CGA 8088 computer, the graphics sprites are could very well be possible being as the NES uses only 4 "colors" for each sprite out of the total pallet. The problem lies more in graphics speed and the ability to process multiple streams of data at once that create the "virtual machine" so to speak. A NES Emulator does more than just run code, it converts the I/O to work with standard PC Peripherals, changes the video to look as accurate as possible, controls all NES-type memory operations, plays back sound, and all the other things. That's why an 8088 based emulator is at least next to impossible in practice.

I know this thread is ancient, but I'm necroposting because it's a funny idea and I've done it.

Not using CGA, that would be slower... but 256x256x8 VGA mode. I ported my Windows NES emulator to DOS and ran it on my IBM XT just to see exactly how slow it would be. The answer is "brutally". It takes almost a minute to render a full frame. It's a slow emulator compared to something like NESticle. It needs a Pentium 2 to be playable, but even with extreme optimization there's no way you'll get anything near playable on an 8086/8088. Even with rendering disabled totally, it takes about 3-5 seconds to emulate one frame's worth of game code. Here's proof it works though.

:twisted:

If you want to actually watch it in "action" if you can call it that, here is a video of it rendering the SMB1 title screen:

So, now we have our (admittedly obvious) answer. The biggest problem is indeed the graphics rendering. It's quite CPU intensive. While drawing the background it has to do calculations for H/V scrolling, and calculate the background nametable to take the tile values from based on that, and then determine the actual pixel inside that tile to draw... for each of the 256x240 pixels on the screen. Each background and sprite pixel also has to pull data from multiple places in video memory, do some bit-shuffling, combine a few bits from each source into one value, then prioritize the background sprite, background field, and foreground sprite, check for transparencies, and draw the correct pixel, as well as increment scroll registers, address registers, etc. in the NES PPU. I'm utterly amazed that NESticle can even do what it does on a 486.

 

[barythrin]

lol.. and the winner for the most confused technology picture goes to.. ;-) (IBM PC with 5.25" drive with 3.5" floppy and CDs sitting on it, running an NES game on an LCD screen!)

 

[Mike Chambers]

lol.. and the winner for the most confused technology picture goes to.. ;-) (IBM PC with 5.25" drive with 3.5" floppy and CDs sitting on it, running an NES game on an LCD screen!)

hahaha. I didn't even think about that. It's even worse than that really. That's actually a DVD and there's also a 4 GB SDHC card sitting on that floppy sleeve.

Yeah, that bench is a warzone.

 

[eeguru]

An HD set top box on the market from a company that shall remain nameless had a port of FCEU with a Legend of Zelda ROM ported by me. It was triggered by a debug menu and ran on a 300 MHz MIPS R4Ke. Was in software releases for nearly a full year before I finally removed it fearing legal issues. It ran at roughly 80% CPU and supported the NES/Famicom USB type game pads.

 

[Mike Chambers]

An HD set top box on the market from a company that shall remain nameless had a port of FCEU with a Legend of Zelda ROM ported by me. It was triggered by a debug menu and ran on a 300 MHz MIPS R4Ke. Was in software releases for nearly a full year before I finally removed it fearing legal issues. It ran at roughly 80% CPU and supported the NES/Famicom USB type game pads.

That's one of the coolest things I've ever heard! :D