Happy Holidays and Merry Christmas

I wanted to take a minute and thank all of my visitors who support this project and wish everyone the best this Christmas and New Years.  As we go into the season, I will likely have less time to spend on the project, so updates will be a little less frequent, at least until next month.  But please keep sending your comments or ideas.  We will definitely continue into 2018!

New video

Here's the famous synthy program running:

Its a little slow because this machine is an old Pentium 4 machine.

Floating point crash on Atom processor

Tried the OS on a small netbook, but it halted before the emulated screen was to be rendered.  After some tracing, I found the problem is when the system is scaling the screen.  Floating point numbers are needed for that code.  The halt was right at a floating point operation.  This was just a little Aspire One netbook, so I found it odd that it would stop right there.

If anyone has any ideas on why this might occur, please do let me know.

SID a little better

So the PC speaker isnt great... but if Id use an actual correct formula for sound it would be a little better.

So I did.  Sound much better (try the pac game as below)

POKE 313,255

RUN

Also, F12 will turn skipping 10 frames on.  This is best for slower /older machines.

Updates

This weekend saw a few updates - nothing spectacular:

1) Some VIC fixes to adhere with proper data values (such as color registers and the upper 4 bits always being set)

2) Im now using the timer interrupt to slow things down for fast machines.  The easter egg game is actually playable now.  Timing isnt perfect, but its much closer.  (If you are running an older machine and it's too slow, I have removed frame skipping in this build.  If you complain enough, I can add it back in).

3) All three SID voices cause the speaker to make noise now.  And its not very pleasant.  For simple notes, the speaker works, but for (more commonly) SID music and such, it just doesnt even come close.  Eventually...

4) A new color palette - the last one seemed a little dark.  Also, I added scan lines.  I may map that to an ALT-S or something down the road as its more personal preference.  (or memory map it?)

5) Found a bug hiding inside the screen render code.  I have a test machine that gives a junk screen when it boots.  Something to do with the screen_refresh() function in the IO class.  Im thinking that that machine's video is higher and outside the range for whatever variable Im using when Im scaling the screen.  Ill come back to that, but if you have that problem, let me know.  QEMU, VirtualBox and other test machines I have dont do this, so not exactly sure just yet.

Spent most of my free time working on timing and testing various programs to see how well the VIC emulation is working.  There's still a few strange things which I hope to work through.  A good example is when relocating the screen to bank 3 and copying the character ROM.  Something goes goofy when it gets to the later 128 characters.  Any programmers out there want to take a shot at this, I'd appreciate it:

And here's the program:

20 fori=1to33:reada:poke49151+i,a:next
30 gosub200
40 poke56576,peek(56576)and252
50 poke53272,44
60 rem
70 poke648,200
80 printchr$(147)
90 fori=53236to53245:reada:pokei,a:next
100 poke53246,peek(792):poke53247,peek(793)
110 poke792,244:poke793,207
120 fori=0to255:poke51400+i,i:poke55496+i,1: next
125 rem
130 forj=lto8:fori=61439+jtoi+2048step8
140 pokei,0:nexti,j
150 fori=61440toi+2048:pokei,peek(i):next
160 gosub200:end
200 poke56334,peek(56334)and254
210 poke1,peek(1)and251
220 sys49152
230 poke1,peek(1)or4
240 poke56334,peek(56334)or1
250 return
300 rem
310 data169,0,133,251,133,253,169,208,133,252,169, 240,133,254,162,16
320 data160,0,177,251,145,253,136,208,249,230,252, 230,254,202,208,240,96
330 rem
340 data72,169,4,141,136,02,104,108,254,207

Interrupt timer added

Not of much interest to ordinary users, but I have added a PIT to handle the timer interrupt, allowing me handle time in a much more efficient manner than reading from CMOS every so often.  Basically it fires off IRQ 0 as often as I need it to.  Originally I wanted to use it to help with overall system timing, but that didnt work out so well.  Maybe Ill revisit that at some point.  But it's good to know it's there when I need it.

Also, as an easter egg, try the following:

POKE 313,255

RUN

Its got some issues still, but its somewhat playable.  This wont remain in the build for long, but it will give you an idea of how well the emulation is working.  And why being able to manage the system clock is so important :)

Added real time clock driver

Just something minor, but it continues to demonstrate how we can incorporate modern hardware into the emulated system.  In this case, Ive added a real time clock driver.  The time values are located in RAM locations:

820 - Month

821 - Day

822 - Year (hibyte)

823 - Year (lobyte)

824 - Hour

825 - Minute

825 - Seconds

Right now, it is polling...which I dont care for because of possible performance issues, but it can optimized later, maybe using interrupts.  Also, these values are located in unused RAM location...locations that some programs may want to use.  So I will aim to BCD these to the CIA real time clock or some other ROM location.

Here's a few screen shots:

VGA terminal (debugger) screen returns, and faster reset

This weekend, after losing the VGA text mode due to the new screen resolution, I needed to put it back in so that I could do more debugging.  So, it's been added back in (ESC key).  Also a fast reset (F10) has been implemented.

Next I will be working on timing and some optimizations.  On an older Pentium 4 machine, its rather slow at reading the keyboard due to the display resolution.  Then I can get back to some of the integration features (harddisk drives 9-11, partitions, USB, networking, etc).  Ive also been trading some improvements with the original emulation author.  Great guy to work with.

I was able to get a pretty cool game running with all the VIC-II fixes put in.  Its a pacman clone.  Here's some pics:

16 bit color!

So due to the previous issue, I decided to go full-on VESA modes (in this case, 800x600) via GRUB2, including 16 bit color.  The net effect is that the resolution should work on most VESA compliant machines, and the colors should look much more like the original C64.  Here's a screenshot:

Tweaking the optimizations and skipframes needs to be worked out a little.  On older machines, ive been able to out-type the system.  Will keep working on this to improve timing.  Cycle-exact would be ideal, but not there just yet.

I've compiled this for 640x480x16, 800x600x16, and 1024x768x16 and it scales fine.  I picked 800x600 because it gives a reasonable performance and render.  Those of you who are looking at the source, the loader.s file contains the requested resolution.  Multiboot is supposed to try to give the requested resolution or provide a near option, but Id say most support 800x600.

Again, this means that the old text mode (ESC key) isnt available at the moment.  The purpose of that screen was to aid in debugging, so I will probably go ahead and generate it again so I can use it and also have access to an ML monitor and disk functions.

Widescreen issue

Seems the last build might cause some problems for people with widescreen machines such as below:

First, my apologies.  Should have been tested first :)

Im working on a fix and will have something soon.

Also - Happy Thanksgiving!  (for those in the USA)

Lots of VIC-II fixes

So the current build has some improvements in the VIC-II emulation core.  Notably:

• Smooth pixel scrolling in the x & y directions
• 24 line mode
• 38 column mode
• Double width and double height sprites
• 800x600 resolution via multiboot
• VIC-II border
• Extended background color mode

These fixes have also been passed along to the original author on his repo (https://github.com/marioballano/emudore).  Great guy and I really appreciate his work and support.

Here's a double height/width sprite, and a split screen raster test:

I havent yet done many tests on multicolor or bitmap modes... bouncing around from thing to thing.  I have so many test programs right now though, that I need to get back to the DOS commands (making/changing subdirectories, deleting files, renaming, etc).  I just bounce around from task to task.

Return of the border...

This past weekend, I decided that it's a bit of a waste to run this on modern hardware if you cant see the C64's border.  We just have to have it.  So, I went in and started working on it.  For awhile I was switching modes using a custom VGA driver, which worked fine between text mode and 320x200, but I was having a good bit of trouble switching to 640x480 or beyond.

Next I started looking at multiboot under GRUB.  Im already using GRUB, so the video mode is really easy to set.  In short time, I had the emulated system running at a nice 800x600, with scaling, to provide a full screen, with borders.  It looks rather nice actually.   The only downside is that I cant reliably switch back to text mode.

In order to solve for this, I think Ill just do away with the built-in text mode, and generate my own, on the same 800x600 framebuffer. (In time we wont really need the text screen anyway, but for debugging, it is handy).  The code is not ready yet, so stay tuned.  But here is my test machine running 800x600 with borders:

A future advantage to this, is that OS64 isnt going to be constrained to 320x200.  We can add memory mapped IO port that lets the user access the 800x600 screen.  Compatibility with enhanced features :)

Also, I did some tests on the emulation with regards to rasters.  I went out to Bombjack and ran some sample programs.  Some things worked great, while some had some issues.  Im thinking the ones that had issues were timing related.  Will revisit those in time.

Joystick #2 via cursor keys

I've added joystick support via the cursor keys (joystick #2) and the shift key for fire.  It works by setting the values in $DC00 depending on which key has been pressed.  Eventually when USB gets added, we can read those instead of cursor keys, but this will do for now. 

Silent No More

Ive added basic SID support via the PC speaker.  Yes, its a far cry from the greatness that is SID... but it works.

Naturally the PC speaker cant do ADSR stuff, or even variable volume (I dont think anyway), so it's just a tone generator at the moment.  Also, it only has one voice.  In other words- its not at all ideal and where we want to end up. But its a start.  Later Ill add actual sound card support, but for now, this will at least get our system making some noises :)

Another note - VirtualBox and some other virtual machines cant emulate the PC speaker.  I dont know why (seems like a silly limitation).  So SID programs for OS64 will only work on real hardware.

Here's a couple of videos:

This one was my first test.. a little underwhelming - just a few notes being played.  The only values I needed to POKE were the SID chip for voice 1, volume (anything > 0) and the hi/lo values for notes.  ADSR and waveform stuff can be ignored as they dont do anything.

This next one is 'Mary Had A Little Lamb':

RESTORE and Reset

Ive updated the code to provide for a RESTORE key, mapped to F9 on the PC keyboard.  Also, F10 will perform a hard reset.  Saves on the power on/off switch.

Serial driver added

Tonight I added a serial driver to the codebase.  It is not yet tied into the CBM emulation though, as Im still figuring out how this ought to be done.  Two options come to mind:

1) Map the settings (2400 8N1) to zero page locations, and then use an 8-bit IO port (memory mapped address) to send and receive data.  This is the easiest route, but has no compatibility with existing terminal programs

2) Integrate it properly through the Kernal routines for device #2.

Naturally #2 is where I want to go.  May need to go with #1 initially in order to test things out quickly though.  The only thing Im not sure about is if I need to use interrupts for this or not.  The code is there if I want to use them for recieve.


Also, this does not mean that USB isnt on its way.  It definitely is.  But baby steps...

Stay tuned.

Proper Keycode Scanning

OS/64 has been updated to properly utilize keycode scanning for the emulated OS.  Prior to now, we were just injecting the PETSCII code into the keyboard buffer, which worked, but it disregarded the control that the CIA1 chip has over the keyboard.  For completeness-sake and better compatibility to code, this needed to be changed to proper keycode scanning.  Ive modified the ROM to move some keys to their proper PC keyboard location (SHIFT-2 = @).

Im going to be testing on a number of machines, but if your test machine has issues with the keys, let me know.  Some keyboards are just strange.  Laptops come to mind.

Drives, Partitions, and Subdirectories

Working with the hard disk, Ive run into a few issues - nothing major, but they do set a precedent that will be important as we go forward.

Disks

So the 64 has up to four drives, numbered 8-11.  In order to access a CD-ROM, other disks etc, I think we will enumerate physical drives using those numbers.  There can be up to four IDE drives, which maps nicely to 8-11.  (The current code only deals with the primary-master as drive 8).

Partitions

Older dual drives, such as the 4040 used a drive number when accessing them such as:

LOAD"0:Filename",8

or

OPEN 15,8,15,"S1:filetodelete"

I think I may use this scheme to access different partitions. 

Subdirectories

For subdirectories,  I thought about doing things the way the 1581 did them.  But that probably wouldnt work out so well and would be less intuitive (as intuitive as any of this is).  So Im thinking instead that the drive...being "intelligent"... maintains its current directory unless changed:

OPEN 15,8,15,"CD0:subdirectory1" : CLOSE 15

CD= change directory
0 = first partition

The other option is to do it in the LOAD/SAVE string:

LOAD"somedir/someotherdir/myprogram",8

Maybe a combination of both would work.  Will have to test out and see what works best. 

A Working SAVE

I have some more tests to do, but we now have a working SAVE. Combined with LOAD, its now possible to do much more, and start building a test suite of programs.

Next, I will probably work out PRINT#, GET#, and INPUT#.  Then I may take a slight break from DOS and work on a User Port interface to the PC serial port.  It would be nice to be able to import programs from another system and save them to the drive. 

As I jump around though, Ill probably start using the bug list in the repo.  So I dont forget some of the things Im leaving for the moment.

Also, I wanted to thank you guys for the support on this project.  I've had some very nice comments about it.  Especially, I want to thank the original emulator developer.

RUN/STOP Key...finally!

I really need to revamp how I'm handling keyboard, but for now Ive added the RUN/STOP key via the Left ALT key.  Also, my kernel LOAD code now properly checks the status byte ($91) and returns FILE NOT FOUND if it can't locate a file on disk.

I still need to solve for the RESTORE key, so RUN/STOP-RESTORE doesnt work just yet.

Also, I need to tackle SAVE, which I will soon.  Im jumping around a little bit to solve some of the annoyances that Ive had lately with it (such as the VGA flicker yesterday).

Some of this code is, admittedly, a bit hackish.  But Im ok with that for now.  Iterate, test, refine.  Goal is to get something working, then come back to it and clean it up as best I can.   But I continue to welcome others who want to get involved in this project to help make it better.

Goodbye Screen Flicker

I still want to switch to using a VESA graphics mode, but for now, the screen flicker was just annoying me too much.  Ended up buffering the virtual screen.  I know performance will take a hit here, but on a real (older) machine, I don't notice any slowdown at all.  My test machine is an old Pentium 4 1.6Ghz and a few older laptops.

New Video - LOADing a BASIC program

The code is quite rough internally, but as you can see, it's working :)

New Project Name: OS/64

I have renamed the project OS64, as it (I believe) better represents where I want this project to go.  It's meant to be an actual operating system... based on the original Commodore OS.  Although it will have additional capabilities, it should still remain as compatible as possible to the original.

As of now, I have the emulation working, and a FAT32 driver so I can read and write to the harddisk.  It even works in LBA48 mode.  Maybe later Ill add FAT16 support.

Today I added some new functionality to the driver:

1) Delete files
2) Rename files

And to the 80 col function screen (for lack of a better name):

1) Load a BASIC program
2) Save a BASIC program

They properly set the basic pointers after loading, so you can continue working on code.  Nice.

But, this 80 col screen isnt intended to be here forever.  Soon Ill have to start modifying the 64's kernal source to allow the BASIC 2.0 LOAD and SAVE commands (and OPEN, etc) to work with the harddrive.  That's a whole new kind of "ugh". 

What will be interesting is the CBM dos command "N" (as in OPEN15,8,15,"N0:...).  What this command ought to do is format the drive.  But this doesnt take into account partitions, so I suppose the assumption will be that the drive is already partitioned.  Will see.

Harddrive Access!

Major milestone here as we introduce being able to access an IDE harddisk.  Here's a video:

Right now Im communicating to the driver by POKE-ing to location 2 (unused on the 64), but that will change later as we modify the kernal to support the drive.

Emudore 64

Commodore 64 native emulator operating system for the x86 PC

WHAT:

This is a C64 emulator that I stripped down to run bare metal on a PC. Turn your blazing fast PC into a Commodore 64 by booting up via CD-ROM or flash drive. Why? Well, why not? We have linux and android running on everything, so why not a C64? We have taken a core OS, and mashed it up with a C64 emulator as the kernel.

STATUS:

Emulation works, although CIA2 doesnt do IEC.

DEMO:

As a working demo, just burn the iso to a CD-ROM, and boot it up, or use something like rufus to convert to a bootable flash drive. You should quickly be seeing the ol' C64 screen. Attach an IDE ATA drive (primary master), formatted to FAT32, and you should be able to load and save to drive 8. This does not currently work with AHCI SATA drives.

TO DO:

• Proper keycode scanning - right now we are just injecting into the keyboard buffer
• IO to load and save - this will undoubtbly be the biggest area of work
• Scaling so that the border can be rendered. Right now the code works at 320x200 disallowing the border
• Take advantage of the multitasking and other low level OS features to provide new & interesting capabilties
• Continue to work with the emudore team to improve emulation
• Consider a different core OS layer, depending on needs over time
• Cross compiling for different architectures
• QEMU and some real hardware wont switch properly to 80 col text mode when ESC is pressed. Not sure why.

BUILDING:

• Code compiles for an x86 linux system using gcc 4.8.4
• Will automatically initiate VirtualBox and start a VM called "emudore64" (see makefile)

UPDATES:

9/21/17: Fixed some keyboard codes so that double quotes, home, and backspace work

9/23/17: Fixed color palette & more keycodes

9/24/17: Text mode screen can now be activated by pressing ESC key. Will later use this for an ML monitor and other functions like loading D64 images, etc. Appears to be some issues with this switch on various systems.

9/25/17: Keyboard code moved, start of ML monitor

9/29/17: Prep work adding rudimentary FAT32 filesystem. Eventual capability to load/save

10/31/17: Large amount of work done adding support for LBA48 drives, and FAT32 support. Work continues.

CREDITS:

• The OS portion was from the video series: https://www.youtube.com/watch?v=1rnA6wpF0o4&list=PLHh55M_Kq4OApWScZyPl5HhgsTJS9MZ6M&index=1
• The emulator code is from: https://github.com/marioballano/emudore
• All credit for emulation to Mario Ballano. I just stuck stuff together to see if it would work.