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.
Crazy 6502 emulator idea
-
Nightmaretony
- In Memoriam
- Posts: 618
- Joined: 27 Jun 2003
- Location: Meadowbrook
- Contact:
-
Nightmaretony
- In Memoriam
- Posts: 618
- Joined: 27 Jun 2003
- Location: Meadowbrook
- Contact:
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.
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.
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.)
daivox wrote:
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.)
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.