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.