Re: VIC20 core talk

For me it usually gets worse after some time.

Re: VIC20 core talk


Wrong again, 1541 was not always sold with C64 Color:

anyways, I got you. I can Exchange the ROM if I want to.

Re: VIC20 core talk

You don't know much about Commodore (who I worked for in 1983-1984).  CBM used left over cases until the inventory was depleted.  This is why the first batch of "Silver Label" C64's had tan colored VIC-20 function keys instead of the traditional grey color that was found on the next 16.98 million machines.

Re: VIC20 core talk

you are funny smile

What does it matter if they cleared out inventory - it came to market as White Version first, labelled 1541 (some may even say 1540 on the back Label), so what I said is and will be 100% true. So they do not came out with the 1541 to match the Brown case in the first place (like you said), they did not care about the Color at all. So you are wrong, no matter where you worked or what you say. You can also see that when you open the case, White Versions have older board layouts (ASSY) and chip date codes then Brown ones. At least as far as I know of my 50 or whatever 1541's

Now, please, do not tell me any more except you have some relevance source exept "working there" - I doubt you assembled on the line in Japan or was a Manager who "found" 1540 cases in 1983-84 and ordered them to be sold as 1541.

I don't believe that, also the silver Label has nothing to do with the Keyboard. I don't think they counted oh we have 45.000 orange Keyboards left, we now make 45.000 silber Labels. They did not care, there is a silver Label with Grey keys also. I have one. And others too.

Re: VIC20 core talk

The 1541 came to market as a white version first to get rid of excess white plastic in the inventory.   CBM *never* produced white cases for the 1541, only the grey color cases.  The white colored cases were left over from the 1540 production run.  Just like they *never* produced tan colored function keys for the C64 - those were left over from the VIC-20 production.  The 1541 also used the same "long board" as the 1540, and then went through 3 more revisions (none of which were ever in the 1540).

I worked for Commodore as the educational support director and service manager for the largest Commodore service center on the west coast (2nd largest service center in the U.S.)  I know exactly what inventory we had for new products going to schools, and what parts we had for service.

Yes, there were silver label C64's with grey function keys... those appeared after the inventory of tan colored function keys was depleted.

You clearly you don't know how Commodore worked.  Do a search.  You will find a lot of information on the silver label C64's, the tan colored function keys, the various case colors, etc.

131 (edited by spotUP 2016-02-01 20:17:49)

Re: VIC20 core talk

Guys, take it easy, this isn't really related to the Vic20 core is it?
Let's not fight in this thread.

Re: VIC20 core talk

I just started to play with the nov2015 release.

I have some issues:

- the black screen issue: just want to state here that it occurs 99% in the OSD, and that it is content dependent. Some OSD pages are really bad, others work quite well. On the bad pages it also gets better when I just move the cursor to the next item.

Maybe the video timing is just out of spec somehow, and certain screen content is easier to sync as other? Maybe it would help just to change some colors of the OSD? Or add some lines with content which is nicely syncable? Maybe some clean lines?

- loading prgs does not work for me. Or I don't get it.. I press return on the prg file name, then I am back on the vic-20 and then? just typing run doesn't start anything at least.

- I found a floppy image with games, which generally works. However I have a hard time listing the content. I miss a break key to stop the listing at some point, preventing the first part of the list being scrolled off screen. The pause/break key creates a scrambled screen (see photo), which can be recovered by pressing it again.

Post's attachments

vic20.jpg 103.34 kb, file has never been downloaded. 

You don't have the permssions to download the attachments of this post.


Re: VIC20 core talk

Are you using DVI or analog (DVI-A to VGA) ? Generally DVI struggles with some modes. Suggest you try this first and then we'll look at it.

There is a binary checked in 18 aug 2016, but I don't think there are any major differences. I'm going to have a play, but I need to finish shipping boards this weekend first.

Re: VIC20 core talk

I use VGA on a 50 Hz compliant Monitor which works well with other cores (at least c64/amiga/pacman/galaga).

This binary is not on the public svn, so I cannot test, unfortunately.


Re: VIC20 core talk

Here the latest binary I have :

Post's attachments

loader.bin 728.72 kb, 2 downloads since 2017-03-12 

You don't have the permssions to download the attachments of this post.


Re: VIC20 core talk

(I'll change the build script so it's not called loader actually, bit confusing)

In the .ini file for the core,  the "bin = xxx" points at the binary.

info = "---- Joystick in Port A ----"
info = "-Keyboard in lower PS/2 in -"

bin = loader.bin

# sets initial clocking (PLL)

Re: VIC20 core talk

Thanks! Tested that core, did not change anything...

However, don't get distracted too much. There are other cores I'd like to see evolve more urgently wink

Re: VIC20 core talk

Hi - does anyone have any good feeling on the level of compatibility of this core to the original hardware?

I'm not using the FPGA source Arcade source or hardware but I do have a port of the original VIC20 FPGA core on my own Altera MAX10 hardware that is based off the MiST source and I'm finding out that probably around 50% of games have issues.  From what I can gather the MiST source is a branch of the original and the FPGA Arcade versions should really be the 'master' and  therefore best at this time ??

I've fixed quite a few things myself, but I admit I'm struggling to fix some of the more obscure issues.  To try to identify issues I have been running the test programs from the VICE emulator which does highlight obvious differences with the VIA's and VIC chips for one, but I don't know if they are really a problem when it comes to games.  The VIA FPGA implementation for example can't be that bad because I can load games from an SD2IEC SD drive connected to the serial bus of my MAX10 board !!

I was hoping to be able to provide fixes and improve the compatibility of the core for others, but I'm lacking in VHDL experience and the whole purpose of porting the VIC core to start with was to learn VHDL !!

I appreciate that the VIC core isn't a priority when it comes to FPGA Arcade, but would anyone be interested in me highlighting things that don't work for me and validating if they don't work with the FPGA Arcade version ??  If problems exist on the FPGA Arcade builds of the core as well I'm willing to try to do what I can in order to address the issues and I would welcome being able to talk with others to brainstorm ideas !

Any thoughts appreciated.



Re: VIC20 core talk

I haven't looked at the MIST code, but it may well be based on mine. Wolfgang re-wrote it for Replay.
I'm certainly open to look at any issues, and I'll check what's released compared with the internal svn.

Re: VIC20 core talk

Thanks Mike, yes the MiST core is all based off your original code, and it isn't that different to your source I can see in your public SVN.  I thought I would approach you as the original author rather than the MiST folks, but most fixes are probably applicable to both cores.

Right now I have some VIA fixes that address some of the failures in the viavarious tests that are part of the VICE emulator test suite.  These VICE tests are good because they answer some of the questions in the VHDL as to when timers are reloaded etc.  There are still issues with the VIA VHDL - especially around timer 2 when it changes mode from pulse counting to a one shot countdown timer and vice versa, but I'm still working on those issues.

Is there a good way to get details to you ?  I should be able to indicate which change to the VHDL fixes specific tests in the viavarious test suite, so if you can run a .prg file on your VIC20 core you should be able to easily validate that the issue exists and that it's properly fixed by my changes.


Re: VIC20 core talk

Give the man a board and SVN access! big_smile


Re: VIC20 core talk

I'll mail him this evening, very happy to get help backporting fixes etc.