Wednesday, February 6, 2019

Its been a year since my last post and people have asked if I will be returning to this project.  If you check my various github repos, youll see Ive been active in a number of projects, so Im still around and have been busy.  Some of my other recent projects include:

* A library for talking to the Ultimate 64 dos and networking functions
* RHML - a web-like browser for the 64 and 128 (and possibly other 8 bits)
* A PC-based SID music making application (WIP)
* Contributing to cc65 and the Ultimate II+ application repos

I found today that another member of the scene (from the Lemon64 Emulation forum) has developed a VICE emulation bare metal for the raspberry pi.  While not x86, I encourage you to check his project out:

Seems like bare metal 64 emulation is really taking off!  And thats a great thing for all of us.

As for OS64, no doubt *yes* I will be back to it - it is not abandoned.  I simply have so many ideas and projects (plus real life stuff) that it's difficult to live in one world for a very long time.  If anyone has interest in helping further OS64 development, I will certainly add you as a contributor.  This code works, as we have discovered, and it's not going anywhere.  So we will get the train moving again soon!

Thank you all for your support and keeping an eye on the project.  Commodore will always carry on. with people like us staying involved.

Monday, February 5, 2018

Temporary Hiatus

Hey folks, currently I've been deep in some real life work projects that has my attention elsewhere.  I had wanted to focus on USB drivers among other fixes and enhancements, but it will have to wait for now.  Probably a few more weeks before I can get back to it.  So stay tuned - just a pause, not a stop!


Tuesday, December 12, 2017

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!

Tuesday, December 5, 2017

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.

Monday, December 4, 2017

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


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


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