Hello, Im working on a project to incorporate a Commodore 64 emulation into an x86 protected mode operating system kernel. The project code is here:

https://github.com/xlar54/emudore64

There is an ISO there, which will boot your old dusty x86 laptop directly into a Commodore 64. The emulation is lacking, specifically in serial bus routines, but I am working on adding access to FAT32 formatted ATA drives. I did not write the emulation, nor the OS layer. Im just a guy trying to fit a round peg into a square hole.

Why? Well, Ive always felt that the Commodore OS could live on beyond the original hardware. We do it with emulators now. But I want a more authentic experience, so why not turn the emulation into the OS. It also mixes two interests of mine, OS development and classic computers. Im also very nostalgic (as we all are) of the beloved 6502 family of processors. And it would provide the 64 with access to modern hardware, making it do things it could never do before. For instance, ditch the cassette routines, and replace them with a port that talks to a USB driver, or audio, ethernet, or whatever. Tinkering could be fun again

There's much I want to do, but Im not the greatest at all these things. If anyone would like to contribute, I would be grateful. I did a similar project a few years back with a Raspberry Pi, but it fell short due to speed of the emulation and lack of documentation for the Pi (https://techcrunch.com/2014/04/11/turn- ... modore-pi/). Id just love to see this one really take off.

Also, I know this is primarily a 6502 group, so my apologies if this is borderline out of scope. Mods can delete if they think it is.

Thanks

For C64, you'll have a lot of 6502 code in it, right? It's a good fit.

I don't have much to contribute on it, but I wish you success.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Welcome Scott! Nice idea. Booting directly into a full-screen framebuffer emulator is a nice idea!

This is an excellent idea.

So we have:

1) Real Commodore 64
2) FPGA Commodore 64
3) Custom OS running Commodore 64 emulator (not mainstream)
4) Linux/Windows/Mac running Commodore 64 emulator
5) Linux/Windows/Mac running web browser running Commodore 64 emulator

#1 will always be the best. #2 can be great but get expensive and complicated.

#3 (what you seem to be doing) is a great compromise. If you can completely remove the modern OS stack (Linux, Windows, etc.) then this could be very efficient and cheap way to enjoy a modern C64.

Keep us posted!

_________________
Cat; the other white meat.

Yes, thanks. For disk IO, Im at a point where I can choose one of the following options:

1) Try an IEC emulation. This is difficult as I only have some documentation and other emulator code to reference. Not trivial at all (at least for me). But it would provide most compatibility
2) Modify the kernal routines to skip IEC and just send commands to/from the OS layer to talk to the drives. Easier, but loses some compatibility

#2 is very tempting because most software used fastloaders anyway which required more than the stock kernel routines. i suppose thats why some software has issues with SD2IEC devices. There is an area at $DE00-$DEFF that is supposedly for additional IO routines (I/O Area #1, memory mapped registers or machine code routines of optional external devices (256 bytes). Layout and contents depend on the actual device.) which sounds like a good fit. One of the tradeoffs necessary for this to work, I suppose. Ill keep working with it and see what makes sense. Right now, I use a rudimentary BASIC wedge to send a signal to a specific memory location to signal a load of the directory - just as a test and to get something working (that code hasnt been implemented in the github repo yet as Im still figuring out where I want to go with it). But if anyone has any other ideas, Im definitely open to anything. Thanks for the support guys!

Scott

- usb legacy mode in (or ripped from) some bios - beware that on most 'modern' *kuch* crap *kuch* systems parts of the hardware also have to be turned on with propriatory non-disclosed registers on propriatory (the new word for crap) chips. (compatibility issues arise when dropping out of real mode)
- bios disk routines (limited to the first few 100 megabytes or fist few gigabytes of diskspace, depending on the version, also real mode only in most cases)
- bootloader + int21h ripped from freedos, microsofts dos 2.0 sourcecode, or cpm (actually it has the same api)
- c64s (vice doesn't have a dos port afaik). now the thing is that c64s -came- as a dos exe file but the guy is kinda weird when it comes to releasing new versions of it or making it open source. also it's not 100% 'compatible' but who cares, it's not 'compatible' in a good way (as in it can run at the maximum cpu rate and skip the loading time from disks and tape and stuff).

i would be more in favour of picking -one specific- target (let's say some thinkpads and/or dell optiplexes, both of which are business systems and will be available in the same configuration for years to come) and just making it work -on those-, as making it work on each and every single pc out there is just a pain in the butt. there are at least 3 different chips for that 'usb' stuff alone, and 100s for sata/scsi/etc (sure most of them will happily pretend to be a 1982 disk controller and work with the bios function up to certain sector/head/cylinder limitations but that's about where it ends. also in as far as vga cards are 'standard' the results of the obtainable 'standard' modes may not be satisfying.

pcs lately seem to lack any and all compatibility (just look at the growth of the linux kernel trying to keep up with all the different chips at different locations) and also haven't come with an 'ibm pc technical reference guide' with schematics and datasheets and stuff in ages.

as long as you pick -one specific- pc model, either pressuring the manufacturer to give you all the required datasheets and memorymap or reverse engineering the thing is worth the trouble. making it work on all of them would be like maintaining the linux kernel it's actually easier to just make new c64's in atx form factor. (hell we'd only need to order 3 chips back into production for that, the vic, the sid, and the 6526 as that's all that's missing).

we can get our serverfarm to do quite a few things in assembly... but. that's only because those are all the same, we've used those chipsets and their predecessors for decades, etc but don't think our server deployment code would work on the average workstation or laptop. initializing all those chips, there being a ****load of different disk controllers, video chips, memory controllers, pci bridges, etc on the market, hell there are 3 different methods to pull reset on a pc alone. and usually just one or 2 out of them work on a specific system. you'd spend a year trying to get your code to pass post on everything and have a rom several megabytes big by that time just to run the memory test on every possible pc. (as obviously the end goal would not be to run it as an os from a disk or ssd, but to run it instead of the bios. where it belongs).

the problem with the entire 'pc platform' is that once you drop out of real mode any still remaining 'ibm compatibility' goes out the window. instantly. other than having a 'somewhat simular' cpu core and a somewhat simular holes pattern in their mainboards pc's barely have anything in common with each other nowadays. and the ibm pc compatible 'real mode' isn't really good enough for such things. there are more differences between 2 random pcs than between an amiga and atari st

- no network (100s of different chips)
- no video (vga isn't even standard and in as far as it is considered a standard only a few modes are supported)
- very limited and slow disk access, using only the first parts of each drive

all of which could be fixed if a single manufacturer would go 'screw that all from now on all our systems will be backwards compatible to our system xxxxx over here, which we will fully document' which would then set and become a new standard and attract the entire games industry to it, but so far none of that is happening. instead just more incompatibilities pop up every day.

One fixed model you could write to could be whatever VMWare/DOSBox/etc support. It would still ideally work with a lot of real hardware, but anybody could boot up such an emulation environment if they weren't compatible themselves. Plus, turnaround time during development would be faster.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor