I've finished my cpu emulator, and made some tests on it and I can say it's fairly complete and ready to be used on a host system development.
Which system would you say is simpler and easier to emulate? (e.g. Atari VCS, Atari 8-bit, Apple II, C64, NES, BBC Micro, etc. )
I don't want to do a 100% complete and down to the cycle accurate emulation, just the bare minimum to make games or apps show on the screen and be able to run somewhat decently.
I'm not even expecting to emulate sound at all.
This would be just an experiment, to gain knowledge to implement more complex systems.

Choose a simple system - of those, Apple II is probably the simplest. The Superboard or the Apple I are good choices too. Your aim would be to get BASIC running, using simple input and output. Video comes after that.
Cheers
Ed

As someone who has written NES and Apple ][ emulators, and who has looked into the Atari 2600 VCS and the C64, and has almost no knowledge of the BBC Micro, I'm going to suggest that your best bet will be either the Apple ][ or the BBC Micro. Well, sortof.

Here's the breakdown:

• For the Atari 2600 VCS, you need to be simulating the video on a per-CPU-cycle basis in order to get pretty much any game to run at all.
  
• I don't know much about the Atari 400/800, but they've almost got to have some custom funky video/audio chipset. I really don't know what's involved at all.
  
• The Apple ][ can be gotten working fairly easily in text mode with just the ROMs. The keyboard interface is dead simple, there are no interrupts (IRQ or NMI) in the basic system, and so on. Expansion cards such as the Disk ][ controller or the Language Card get a bit tricker, of course, and the graphics modes get a bit tricky, but for just being able to run BASIC it's a dead simple system to set up.
  
• The C64 has a scanned keyboard array, some sort of bankswitched memory, custom video and audio hardware, a 6522 "user port", interrupts... Not a good choice for an initial system.
  
• The NES uses an NMI as part of the video system, which is not simple and will need to be simulated on at least a per-scanline basis (every 113 and a quarter? three quarters? CPU cycles) in order to handle more than the simplest games (the first Super Mario Bros. game, for example, uses raster effects), and you will be simulating bankswitched memory hardware basically immediately (unless you stick to so-called "mapper 0" games, but pretty much all of the interesting games use some sort of hardware expansion).
  
• I don't know anything about the BBC Micro, so I can't help you there.

On reflection, I'd put a word in for the PET too.

(And also on reflection, the BBC is not so simple: the ROMs are bank-switched and the OS requires a regular IRQ from a VIA)

Edit: oops, the PET also needs a regular IRQ. Note that a Beeb with just OS + BASIC doesn't need to do any of the bank-switching.

For my own Propeddle project (real 6502, real RAM, everything else emulated), the Apple 1 was by far the easiest machine to emulate (and the only system emulated so far ). You only need to monitor 3 addresses in 6502 memory space: one where the 6502 writes a character to the video "terminal", one where it checks if there is a new character from the keyboard, and one where it actually gets the last character that came from the keyboard. Once you can emulate that hardware and you can map the Krusader ROM image into memory, you have a running system with an Assembler/Disassembler and BASIC. If you don't want to do video or a keyboard, you can emulate it through a serial port and all software will still work because it simply doesn't expect to have anything else than character-in character-out: the original system didn't have any manipulation of the screen or cursor; all you could do was push a button to clear the screen, and that button wasn't wired into the 6502 circuitry: it was part of the tv-terminal circuitry. The Apple 1 uses no interrupts.

The Ohio Scientific (OSI) Superboard II a.k.a. Challenger a.k.a. UK101 should also be very easy to emulate: The video is memory-mapped text-only with a 256-character font that's ASCII based, but is a bit weird: the screen is 32x32 characters but the ROMs pretend that it's only 25x25. The keyboard uses only one location in memory (basically if I remember correctly the 6502 writes a value to a location that enables a row, and then it reads the location back to see which column is connected to that row because a key switch is down). Even without the keyboard emulation, you'll see a startup message "D/W/C/M". The only other peripheral that's on-board is a 6850 UART which should be easy to emulate. And in fact with some small changes to the ROM it's possible to run the system with just the UART and no video or keyboard emulation; Grant Searle has done this here. The OSI also uses no interrupts.

The Commodore PET (or 4032, 8032, and other early monochrome Commodores) should also be fairly easy but you will need a memory-mapped text screen that generates PETSCII characters, not regular ASCII. You will need a matrix keyboard connected through a 6520 (or was it 6521) to make it work, but without keyboard or VIA/PIA it should still show the COMMODORE BASIC / READY" message when you start up. Besides the keyboard PIA/VIA, there are two more interface chips that are used for the IEEE-488 interface and for the cassette ports; they're not needed to bring the system up. The PET uses interrupts for timekeeping: a 60Hz (or 50Hz) clock is generated from the mains input.

If you don't want to bother with video, you can go for a Kim-1 emulator (or a similar system like the Elektor Junior or the SYM or AIM-65). The KIM-1 uses two 6530 RRIOT chips (ROM RAM I/O Timer) which are impossible to get, but you can use (or emulate) a 6532 RIOT (RAM I/O Timer) instead. Vince Briel did this for his MicroKim, based on research done by Ruud Baltissen. A single RIOT is enough, most programs only use one of them: the one that's connected to the on-board keyboard and the six 7-segment displays. If you don't even want to bother with the display or keyboard, you can just use the serial port which is bitbanged by the software in the ROM and has a reasonably well-working automatic baudrate detector. The KIM-1 doesn't need interrupts.

I'm not very familiar with the Apple II family of computers, there are many of them. I believe they have many video modes including graphics and color, so true emulation may be a bit more work than the ones mentioned above. I think it comes up in text mode though, so as long as you don't run graphics programs, you can get started pretty easily.

Systems like the Commodore 64, Atari VCS (2600), NES etc. all have pretty complicated custom audio/video chips; they would take a significant amount of work to emulate if all you have now is a 6502. However some people have already done this; for example Jeri Ellsworth's DTV was an FPGA-based Commodore 64 emulator (but it's closed-source, unfortunately). The nice thing is that these systems are available for cheap on eBay so you could just get one, plug your emulator into the 6502 slot (except in the NES -- the 6502 is physically part of the main chip there) and get started. Then one by one you write emulator code for the other chips until your system is all by itself.

Hope this helps!

===Jac

Hi Petruza,

on which system (Windows, LInux, FPGA, PIC, AVR,...) is your emulator running? In any case I would say the basic emulation of an Apple II is fairly easy. For the built-in IO they only used TTL ICs and this can be emulated with little effort. Depending on your host system I would say Video is the most difficult element (I might say for all systems with a built-in video controller, video is always the most complex part). When it comes to peripherals it can be challenging. A Language Card is easy to implement, Apple IIe Memory mapping needs a little more effort.

Most of the other systems require that you emulate 65xx peripherals as well. Most notably the 6522 and it's companions (6532, 6530).

Cheers

Peter

Hi, and thanks to everyone for the comprehensive ansers.
I'm developing the emulator core in portable C independent of any platform.
Even the platform dependent code like rendering I'll try to implement on as portable as possible code, say OpenGL or SDL.
That being said, I work on MacOS and that's the first platform I'll try to run my emulator on, but I intend to make it multi-platform, or at least work on Windows too.

See: www.fpgaarcade.com

This is something I am working with, and it has FPGA cores for a lot of various systems - Amiga, C64, VIC-20, Atari 2600, Collecovision, various coin-op arcade machines, etc. ALL of the cores are open-source and available.

The simpler system is actually the BBC 6502 second processor, not the BBC I/O processor. Then you just have CPU, RAM, ROM and trap all the API calls and pass them up to the emulator.

_________________
--
JGH - http://mdfs.net