Thinking of a SuperCPU VIC

[eslapion]

@Mike:
As I indicated, I intend to place a 6502 on the cart port but I still await your recommendations concerning the logic circuit I should use for the reproduction of the clock signal on the internal CPU socket.

[Mike]

@eslapion: PM sent

[RobertBe]

I have begun studying the VIC-20's clock and address decoding signals with a digital storage scope.

I have decided to stick with my original idea. If I am to create a SuperCPU for the VIC-20 then it will adhere to the KISS philosophy. (Keep It Super Simple)

How have your studies gone in regards to this project? It's very nice to think of this for the VIC's 35th anniversary.

Happy New Year,
Robert Bernardo
Fresno Commodore User Group
http://www.dickestel.com/fcug.htm

[eslapion]

This project is more or less in limbo because I noted the W65C02 from WDC has enough instruction set differences with the MOS 6502 to cause compatibility significant problems.

The W65C02 is required because only IT can run at up to 14MHz (in reality it can be overclocked safely to 16MHz).

Now, however, there are a couple of open source projects for the C64 which include a VHDL model of the 6502 which are complete enough to even include illegal opcodes.

A SuperCPU/VIC would probably be feasible using a couple of FPGAs or CPLDs of the XC95288XL family. It certainly would be a much less complex project than the Turbochameleon so its possible.

Practical to do is another matter entirely as the FPGA Arcade project includes VIC-20 replication.

[RobertBe]

This project is more or less in limbo because I noted the W65C02 from WDC has enough instruction set differences with the MOS 6502 to cause compatibility significant problems.

Aw, that is too bad.

Practical to do is another matter entirely as the FPGA Arcade project includes VIC-20 replication.

AFAIK, the FPGA Arcade isn't in commercial distribution (though MiST is being sold and has a VIC-20 core).

Happy New Year,
Robert Bernardo
Fresno Commodore User Group
http://www.dickestel.com/fcug.htm

[groepaz]

also none of these free 6502 cores is really timing accurate... nor made to work as an actual CPU replacement.

I'd look at andre fachats CPU replacement for the PET - that can probably be adapted to the VIC20 without too much work. and if you really care about backwards compatibility, add the original CPU and make it switchable. for the VIC20 it probably doesnt matter much that some old games will not work with the acceleration.

[eslapion]

also none of these free 6502 cores is really timing accurate... nor made to work as an actual CPU replacement.

I'd look at andre fachats CPU replacement for the PET - that can probably be adapted to the VIC20 without too much work. and if you really care about backwards compatibility, add the original CPU and make it switchable. for the VIC20 it probably doesnt matter much that some old games will not work with the acceleration.

I will have to see where things are going. I assume the Turbo Chameleon supports illegal opcodes since it emulates the whole machine.

FPGA arcade replicates both the VIC-20 and the C64 so I suppose a good implementation of the 6502/6510 will be demanded by the clients on both the replicated computers and 1541 drive.

The 6502 implementation included in the 1541U 1/2 is good enough for just about everything, IMHO. Starting to look for fleas in the carpet is an exercice best left to overly purists ripe for a good dose of antipsychotics.

As for Andre Fachat and his CPU replacement, if you are referring to this project: http://www.6502.org/users/andre/pet816/index.html

... then it uses the 65816 which has similar compatibility problems as the W65C02. That's normal since it is made by the same company.

Right now the only "reasonable" accelerator I can think of for the VIC would run on a 4 MHz R65C02 from Rockwell which is easy to find on feePay. It doesn't support illegal opcodes but the timing is ok and standard instructions are the same as with an NMOS 6502. I guess we could generally say it shares the same bugs.

[DrVeryEvil]

If I may be of assistance, I would like to suggest taking a look at my post on 6502.org forum, which is probably a more suitable location for a discussion like this. If you are not against updating the voltage regulator circuitry with a simple switcher circuit, you can make plenty of room for added boards inside the old style VIC 20. All of those huge heat sinks can go away. A board that plugs into the CPU socket can now extend towards the expansion port that can hold a lot of memory as well as a CPLD or FPGA. In your discussions, I see a lot of the same ideas I have for my VIC 65816, so take a look at this and see what I have done, and how it ties into the VIC 20 schematic. If you really understand the VIC 20 design, you can work around a lot. The VIC 20 can run using the two clock signals coming off the 6560.

http://forum.6502.org/viewtopic.php?f=4&t=3521

If you think you can do it, then by all means, try and learn.

[groepaz]

The 6502 implementation included in the 1541U 1/2 is good enough for just about everything, IMHO.

its certainly not good enough if you want it to be 100% compatible for non accelerated stuff (for example, even the timing for legal relative branches isnt 100% correct. (atleast when i checked 2.6k firmware) which means tons of timing critical stuff will break). and more importantly: its also not meant to serve as an actual cpu replacement.

Starting to look for fleas in the carpet is an exercice best left to overly purists ripe for a good dose of antipsychotics.

not quite. in many cases it is exactly what makes the difference between "works" and "works not".
that said, its not a good idea to refer to the 1541u (or any other drive emulation) for this matter - because you can get away with a lot of half working stuff on the drive side. (eg the VIA emulation in VICE -or 1541u for that matter- is pretty broken, yet the drive works fine).

Right now the only "reasonable" accelerator I can think of for the VIC would run on a 4 MHz R65C02 from Rockwell which is easy to find on feePay. It doesn't support illegal opcodes but the timing is ok and standard instructions are the same as with an NMOS 6502. I guess we could generally say it shares the same bugs.

*afaik* the 65C02 has the same problems the 65816 has in that regard - for example it doesnt write back the original value for RMW instructions (eg INC/DEC) - which breaks some common programming techniques. (this is the main reason for why a lot of games need patching to work on the SCPU). no idea how much of a problem that is on vic20, but i'd assume the same programming techniques being used there too. (ie: even the standard instructions are not actually doing 100% the same, and it _will_ break things)

[eslapion]

*afaik* the 65C02 has the same problems the 65816 has in that regard - for example it doesnt write back the original value for RMW instructions (eg INC/DEC) - which breaks some common programming techniques. (this is the main reason for why a lot of games need patching to work on the SCPU). no idea how much of a problem that is on vic20, but i'd assume the same programming techniques being used there too. (ie: even the standard instructions are not actually doing 100% the same, and it _will_ break things)

Incorrect. The R65C02 will not support illegal opcodes but it does share the same branching bugs as the MOS 6502.

In all the WDC CPUs, the branching bugs are fixed.

http://www.oxyron.de/html/opcodes02.html

See "The 6502 bugs"

As for the 1541U 1/2, I couldn't care less about incomplete VIAs, my sole interest is the CPU and gideon's implementation does support illegal opcodes, it does replicate the 6502's bugs so its pretty good.

[groepaz]

Incorrect. The R65C02 will not support illegal opcodes but it does share the same branching bugs as the MOS 6502.

RMW instructions are completely unrelated to these branching bugs. the NMOS chips write the original value first, then the modified value. the CMOS chips only write the modified value. this is often used eg to acknowledge interrupts with a RMW instruction - and it will no more work with a CMOS chip.

it does replicate the 6502's bugs so its pretty good.

as said, it fails even the lorenz tests for some of the legal opcodes (eg the branches). and its *still* not designed to work as an actual CPU replacement.

[eslapion]

I have an NTSC VIC-20 here equipped with a R65C02 and it runs everything I can throw at it. When equipped (temporarily) with a W65C02, most cartridge games will work but loading/saving from tape or disk just freezes the machine.

Did anyone test various 6502 with the Wolfgang Lorenz's test suite? R65C02, W65C02, W65C816 ?

Anyways, if creating an accelerator for the VIC, the CPU it uses does not need to be "an actual CPU replacement" because of all the glue logic involved. I can easily see an FPGA running a VHDL 6502 with its surrounding access/bus control, separate RAM and ROM and clock generator.

I find it surprising that the 1541U's 6502 would have branching or other differences compared to a MOS 6502 yet be able to run without error all the specialized code that it runs successfully. All the special game loaders, JiffyDOS, Super Snapshot V4, V5, vorpal, as well as copy protections.

[groepaz]

Anyways, if creating an accelerator for the VIC, the CPU it uses does not need to be "an actual CPU replacement" because of all the glue logic involved.

wat. srsly, are you sure you know what you are saying there?

I find it surprising that the 1541U's 6502 would have branching or other differences compared to a MOS 6502 yet be able to run without error all the specialized code that it runs successfully. All the special game loaders, JiffyDOS, Super Snapshot V4, V5, vorpal, as well as copy protections.

as said already, you can get away with a lot of things on the drive side - an occasional one cycle difference doesnt really matter, because thats still less than eg the different rotation speeds of various drives will cause.

[eslapion]

@groepaz
Your alternative solution is?

I may not know a lot of things but other than (maybe... a BIG maybe) Bandits I don't know of anything on the VIC-20 who might be affected by inexact cycle instructions. Branching one page off is far more problematic...I suspect.

I strongly suspect even tape loading and saving would be unaffected for the same reason drive activity isn't.

Please don't bump into the flowers on the carpet.

[darkatx]

...I'm mainly bringing the mainboard redesign into play, as the external cartridge solution would - in a certain sense - anyway 'degrade' the original mainboard into a graphics adapter card for the external computer.

I was thinking maybe doing the opposite...instead of trying to make a SuperCPU why not just conecentrate on one thing and make a SuperGPU. A cartridge that could possibly implement Mike's VFLI or Hursts Software Sprites - though you'd still have to open up the case and make the needed adjustments plus C128 BASIC 7.0 graphic commands would be a bonus.

Just something that could render then copy its memory into the VIC memory within the available half cycles without having to mess with the overall timing too much similar to what was mentioned earlier.

The CPU would be freed up to concentrate on everything else instead of rendering and 3D math, etc. That in itself might be a huge performance boost when running apps or games. This issue is will people write stuff to support it? Just a thought?