Re: VIC20 core talk

For me it usually gets worse after some time.

Re: VIC20 core talk

JimDrew

Wrong again, 1541 was not always sold with C64 Color:
http://scacom.bplaced.net/Collection/1541/15412p.jpg

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.

133

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.

135

Re: VIC20 core talk

Here the latest binary I have :

Post's attachments

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

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

136

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)
#CLOCK = NTSC
#

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.

Kevin.

139

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.

Kevin

Re: VIC20 core talk

Give the man a board and SVN access! big_smile

142

Re: VIC20 core talk

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

Re: VIC20 core talk

Not sure if you sent me an E-Mail, I've been off on holiday for a couple of weeks and I've only just finished catching up on E-Mail, but I didn't spot anything in my inbox or junk...  I'm still happy to do what I can with regards to fixes smile !!

144

Re: VIC20 core talk

I thought I had. I'll do so again now!

Re: VIC20 core talk

Opening up an old topic here.. why the 2 and " keys don't work on certain ports of the VIC20 core !  I see this issue on my port running on a MAX10 and at some point a fix was suggested by wsoltys in the T65 6502 core which involved setting SaveP <= '1' in T65_MCode.

However it seems this is a bad fix because that breaks the T65 core and causes it to not set the zero flag in certain circumstances (e.g. DEC $900E) .

I'm curious as to how it was determined that setting SaveP was a fix ? My original VIC20 core port ran fine with the 2 key working and it seems to be changes to the VIA code that actually prevent it from working, not the 6502, however the core has moved on and now I've been unable to find a version of the 6522 that gives me a working 2 key so I can't compare to try to determine the issue!

As I'm working in VIA fixes I want to properly understand the issue with the 2 key, especially if it is really a VIA issue !   The only potential issues reported for the T65 for my compile are inferred latches on the Q2_t variable in the ALU, which I'll look at, but any history on the issue is appreciated!

146

Re: VIC20 core talk

non working keys imply that one of the portbits is being pulled low when it shouldnt. i'd look at the joystick port and everything connected to it. (you can make 2 not work by pulling one of the joystick lines)

Re: VIC20 core talk

Thanks for the feedback ,but unfortunately its not as simple as the joystick interfering..   On further investigation this is really an issue for the MIST board, however from the T65 bug thread on this forum it seems wolfgang worked with wsoltys on the issue for the MIST board and its only the MIST source that has the modified T65 with the additional SaveP that actually breaks the operation the 6502 !! I don't have a MIST board on which to verify if the 6502 is broken in the same way as my port, but I suspect it is !!

The 2 key issue would appear to be down to timing, if I read the keyboard matrix directly via manipulation the VIA ports the matrix reads just fine.   But if I read the matrix via a bit of assembler that disables the normal interrupt routine and loops calling the kernel keyboard scan function then only very occasionally will I see a "2" key press, its very random, so its a problem with the way the kernel scans the keyboard matrix and a function of the timing of its interaction with the VIA's.

I suspect the issue may come down to the different RAM used in the PS2 to VIA interface code, which is Mike's originally and is used on the MIST board, my port and other ports of the VIC20 core, e.g. ZX-UNO, but NOT on the Replay board.

It's interesting as the ZX-UNO code seemingly has no reported issues and is using unmodified PS2 and T65 sources, the difference could be that the UNO is a Spartan FPGA and the MIST is an Altera Cyclone.   The PS2 interface code uses a Xilinx RAM16X1D primitive for Xilinx FPGA's and plain VHDL for an equivalent (uninferred) Altera RAM - I am thinking something related to this RAM is the root cause and I'm now trying to simulate the whole PS/2 interface to see if I can see where the issue may lie !

148

Re: VIC20 core talk

Very odd. I can modify the vic RTL to remove the RAM16X1D. If you can simulate it that would be awesome.
I'm a bit sick at the moment, but I'm still trying to fix a board for you. I have the parts now.

Re: VIC20 core talk

Mike - Thanks - but I already have a version of VIC20_PS2_IF.vhd that does away with the Xilinx RAM16X1D RAM and from what I can see in simulation today that seems to be behaving correctly, so I'm not sure that it comes down to the RAM.

Today I've been playing with and hacking the kernel keyboard routines and the issue may relate to LSR not correctly setting the carry flag under certain circumstances, but I can't understand (yet) why LSR works correctly for other keys in the matrix that produce the same ROW value..   More debugging and a clear head is required I think!

Re: VIC20 core talk

With a clear head it was easy to see the issue.. the problem was with the replacement for the Xilinx RAM, in Mike's original code there were 8 x RAM16X1D's, but the VHDL for the non Xilinx equivalent was actually an 8x8 array.  Most of the time the RAM is accessed with a 3 bit address, but not always - hence the issue and corruption of RAM contents.  Change the RAM to a 16x8 and all is good !  It was timing dependent as to if RAM address 7 got corrupted, and the corruption was also only for bit 0, hence why 2 (row/col 07) didn't work.  So the MIST VIC20 core is bad, as well as other ports non Xillnx ports of the VIC20!  No issue here for the Replay version because its T65 core is good and the PS2 to VIA interface code is completely different to the MIST.