I am about to do something that, at first, sounds ridiculous.

I love programming the 6502, and the OS I am writing works with it, and I'd like to make programs I happen to write for my OS available outside of the 6502 series CPUs without rewriting. That being said, I want to be able to empower my OS to use some of the enhanced features of alternative platforms such as PCs with multi-megabyte memory availability and fast disks, while still being a 6502 OS.

Here's my possibly silly idea: a 6502 emulator with a twist. I want to write a 6502 emulator that will faithfully emulate a 6502 with 32K of RAM and 8K of ROM. That's the part that has been redone a billion times. The twist is this: I want to provide external services to my OS in the emulator via a series of I/O ports and memory-mapped I/O pages from the 6502's point of view. Paging data in and out, banking memory in and out, being able to use a virtual device protocol of some sort to access a folder or disk image on the PC's hard drive directly...basically, it will run the OS on the PC or Alpha or Sparc or whatever, but instead of emulating an existing architecture, using the existing OS on the computer to expand its capabilites beyond that of practically any 6502 system that may ever exist. Granted, external hard drives and 16MB RAM 65816 systems exist for established architectures, but this would effectively allow the 6502 OS to exploit the capabilities of the host computer such as running at MHz speeds the 6502 will never reach, being able to run tons of programs at once, not worrying about severe memory constraints, etc.

Maybe it would be totally pointless, but I think it could be useful and interesting for all us hobbyists to have a virtual 6502 platform that offers features we may never see in a real one.

After all, every emulator I've seen stays constrained to emulating existing hardware. I've never seen one yet that was written specifically to scale out and use the host's full potential instead.

My $0.02, deposit as needed.

Thanksfully, some emulators have their sources available, so you can use as a base engine.

why limit to 8K of rom space? go for the code gusto, I am into 32krom, 32k ram with some ram space removed for io madness, like 256 bytes....

_________________
"My biggest dream in life? Building black plywood Habitrails"

Because you can't fit 64K of ROM/RAM plus processor state information plus the emulator program in one 64K 65816 page. One of the ideas is to have a 6502 emulator that can run multiple virtual 6502s in one 65816.

No but the nice thing about the 816 is multiple pages. you can keep the base code and then tables and other things on other pages.

One original concept I wanted in my SBC was getting 4 megs of code by allocating an 8K block of rom memory space that was bank switched by a single location, allowing major access fun. I may still go that route for a later board design. It is easy to implement using 8 bit latches such as the 74374.

_________________
"My biggest dream in life? Building black plywood Habitrails"

There is nothing silly about this. Indeed, this is (I believe) precisely why WDC reserved the COP opcode for. In a real-world hardware implementation, COP acts like BRK, and traps to the OS. In a software implementation, or in a customized hardware 65xx implementation, it could be anything you want it to be.

Your idea is not quite ridiculous enough to be interesting. Try this: run your virtual 6502 natively on PC hardware (no OS underneath and no virtual hardware, only real PC hardware directly controlled by 6502 code).

Actually, the idea of running a PC natively from a virtual 6502 implementation would be a bit too exotic. You're talking about enumerating PCI devices, handling ACPI tables, running Ethernet adapters, babysitting USB devices, and more from a system that can only natively address 64K of space in total. You're talking about rewriting drivers for PC devices in 6502 assembly when a 6502-based system is very highly unlikely to use a significant number of those devices (let's face it, no sense in expecting a 6502 system to run AGP or PCI-E.)

Well, you can basically ignore capabilities you don't want to use. The PC BIOS takes care of basic initialization. For a basic setup, you'd just have to write a floppy and/or IDE driver (pretty easy, and been done on 6502 systems) and some code to read a PS/2 keyboard. For video, just leave it in text mode.

Ethernet and networking protocols would be a bear to implement from scratch, but perhaps you can find suitable 6502 code already written. Also, you don't necessarily have to use assembly for everything. C is available via the free cc65 compiler.

A lazier approach would be to run on top of an MS-DOS clone using a DOS extender. That's not quite "running bare", but it's a lot closer to bare than running under Windows/Mac/Linux.

At least you would be completely safe from all known PC viruses.

I use the WDM instruction to provide host OS debugging control for lib65816, which my Kestrel emulator uses. A Kestrel-1 emulator I wrote as a VERY quick hack used memory-mapped I/O to write to the Linux console. It's not difficult to implement.

Where do you perceive the difficulty?