Thinking of a SuperCPU VIC

TLovskog · Post by **TLovskog** » Tue Nov 08, 2011 2:26 am

A second joystick port and SD-card support, o.k., but I don't think HDMI is necessary. I've converted my VIC-20 to S-Video, and that is all about you need to get the video in good quality out of the base unit.

Need and necessary is one thing ... daydreaming and what can technically be done ... is another one

My daily work is very much about doing the right stuff in a commercial perspective. That is why it is so fun to do totally the opposite (well almost) at home ...

I have not done any HDMI designs yet, so it would have been a fun part.

But I see the wisdom in your comment.

As long as there is no FPGA re-implementation of the VIC which is confirmed to have exact the same behaviour down to cycle level, I'd want to keep the original.

That would then be the 2nd fun part to create. Although perhaps a too big step and to much time.

Mike · Post by **Mike** » Tue Nov 08, 2011 4:49 am

TLovskog wrote:Need and necessary is one thing ... daydreaming and what can technically be done ... is another one

Indeed it is.

In the last years, some nice hardware projects have been done on the VIC-20. Mega-Cart, Ultimate expander, Behr-Bonz, FE3 specifically for the VIC, the various SD2IEC solutions which also work on the VIC-20, several attempts to enhance the video quality with S-Video output, and my VFLI mod.

It is natural, that at some time an acceleration of the CPU might come into focus. But as you see, this opens a can of worms, especially if one likes to incorporate or keep the other enhancements already done before.

My daily work is very much about doing the right stuff in a commercial perspective. That is why it is so fun to do totally the opposite (well almost) at home ...

I agree. Some balance against work always is good. If a hobby touches the sphere of what you're doing at work, then at least something of the hobby should differentiate well at some point (that's the 'well almost').

I have not done any HDMI designs yet, so it would have been a fun part.

Unless you also replace the VIC, you have an analogue signal at some point. The place where you'd convert it into a digital HDMI signal is largely insignificant, that could also happen in an external box.

Mike wrote:As long as there is no FPGA re-implementation of the VIC which is confirmed to have exact the same behaviour down to cycle level, I'd want to keep the original.

TLovskog wrote:That would then be the 2nd fun part to create. Although perhaps a too big step and to much time.

It's surely not entirely impossible. MikeJ's FPGA project (and SwinSID as another example) show, that the core components of the CSG with their mixed-mode (analog/digital) circuitry *can* be recreated.

However, somewhere you cross the point nothing significant of the original hardware of the VIC-20 is left over, so what's then the difference to using an emulator like VICE? Only the emulator thrives on hardware that's already there (your PC), is embedded into another OS, and data exchange also is easier.

TLovskog · Post by **TLovskog** » Tue Nov 08, 2011 5:20 am

Unless you also replace the VIC, you have an analogue signal at some point. The place where you'd convert it into a digital HDMI signal is largely insignificant, that could also happen in an external box.

Totally agree. A HDMI output is only interresting if you replace the "source", the VIC chip.

eslapion · Post by **eslapion** » Tue Nov 08, 2011 5:05 pm

If we're going for a new MoBo, the way to avoid having to have a different power connector for various versions of the VIC is to impose a new one.

I would like you guys to pay attention to the fact that on the 2-prong VICs, the PAL and NTSC power connectors are different and the VIC-20 Cr constitutes a 3rd type of connector.

If you guys are going the S-Video way then I suggest we finally use a C-64 type of video connector where composite, luma and chroma constitute 3 different lines.

eslapion · Post by **eslapion** » Thu Nov 10, 2011 11:19 pm

Is this project already in sleep mode?

TLovskog · Post by **TLovskog** » Fri Nov 11, 2011 1:26 am

Sorry, but the time I can spend on my VIC is limited and right now it is fully allocated to the GCart, the internal 8k addon board to that and a USB Joystick/Joypad to VIC 20 9-pin DSUB Joystick/Paddle adapter.

However, I couldn't help it but dig up the old Spartan 3E development board. I will try out MikeJ VIC 20 in a FPGA the coming weeks.

Mike · Post by **Mike** » Sun Nov 13, 2011 5:36 pm

Here's another surprise: the mainboard of the VIC-1001. It might have a similar schematic to the 'standard' 2-prong (5K RAM in 10 2114s, etc.), but the components are arranged in a completely different way ... yet another reason to go for a completely new mainboard.

eslapion · Post by **eslapion** » Tue Nov 22, 2011 7:30 pm

Mike wrote:Yet another reason to go for a completely new mainboard.

In the past, I had a VIC-20 with PET style keyboard who's insides was configured like that.

However, I see that this project is now dormant.

I believe this is because this project has taken a turn for the excessively complex.

I know you guys want a new board but my opinion is that the simplest way is the best because it makes the project available to the greatest number of people.

I believe the simplest SuperCPU for the VIC-20 is one that plugs in the cart port and we know now that can be accomplished by removing the 6502 and replacing it by a simple board with 40 pin headers and a few logic chips to deal with the clock signals.

AFAIK, except for VICs with the CPU soldered, this config works with both PAL and NTSC systems and any revision of the mainboard.

Its a good idea to want to replace the whole board but in order to have a starting point, we need to keep things simple.

I suggest we create at least ONE cart based SuperCPU and then make the move to a complete MoBo replacement IF we feel its worth it.

How about that?

TBCVIC · Post by **TBCVIC** » Wed Nov 23, 2011 9:47 am

I'd buy one of those carts, definitely. How many softsprites can I have on the screen then?

RobertBe · Post by **RobertBe** » Wed Nov 23, 2011 12:33 pm

eslapion wrote:...my opinion is that the simplest way is the best because it makes the project available to the greatest number of people.

I believe the simplest SuperCPU for the VIC-20 is one that plugs in the cart port and we know now that can be accomplished by removing the 6502 and replacing it by a simple board with 40 pin headers and a few logic chips to deal with the clock signals.

That makes sense.

I suggest we create at least ONE cart based SuperCPU and then make the move to a complete MoBo replacement IF we feel its worth it.

I like that idea.

On the road to Portland, Oregon,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug

Mike · Post by **Mike** » Fri Nov 25, 2011 5:27 am

eslapion wrote:I believe the simplest SuperCPU for the VIC-20 is one that plugs in the cart port and we know now that can be accomplished by removing the 6502 and replacing it by a simple board with 40 pin headers and a few logic chips to deal with the clock signals.

"know" in quotes, really. It is the first thing to test, i.e. one would have to design the CPU socket logic board, with the extra address lines going to the external cartridge, and then having an functional external CPU - even when it does not accelerate the VIC-20. Then there's a solid basement to expand upon.

Besides giving some hints how to proceed further, my means and - in some sense also the - motivation to delve more in the actual hardware is rather limited. I've got only one VIC-20, this my working VFLI-modded one, with a socketed 6502. That and other RL constraints and you see what happens ...

@RobertBe and @TBCVIC: I need to say you both have a rather naive point of view. This piece of hardware is not even beyond the first design stage - there's not even a final consent about which chips are going to be used and how the logic between them has to function exactly. Thus giving a quantitative answer to the question, how much speed improvement could be expected, would be rather pointless at this stage.

eslapion · Post by **eslapion** » Fri Nov 25, 2011 7:43 am

Mike wrote:"know" in quotes, really. It is the first thing to test, i.e. one would have to design the CPU socket logic board, which the extra address lines going to the external cartridge, and then having an functional external CPU - even when it does not accelerate the VIC-20. Then there's a solid basement to expand upon.

Please, tell me what needs to be done with the clock signal inside the VIC-20 and I'll use one of my 44 pin with .156" spacing development boards to do just that.

Besides giving some hints how to proceed further, my means and - in some sense also the - motivation to delve more in the actual hardware is rather limited. I've got only one VIC-20, this my working VFLI-modded one, with a socketed 6502. That and other RL constraints and you see what happens ...

I have a total of 4 VIC-20s, one of which is a PAL, all 3 others are NTSC.

Would you be happy with an NTSC VIC-20? I should also send you a spare replacement keyboard, seeing what happened to your "7". Please PM me your shipping address.

@RobertBe and @TBCVIC: I need to say you both have a rather naive point of view. This piece of hardware is not even beyond the first design stage - there's not even a final consent about which chips are going to be used and how the logic between them has to function exactly. Thus giving a quantitative answer to the question, how much speed improvement could be expected, would be rather pointless at this stage.

What would be truly easy for me is to work with GAL22V10 chips. Are you comfortable with generating jedec fusemaps?

Mike · Post by **Mike** » Fri Nov 25, 2011 8:18 am

@eslapion: PM sent

RobertBe · Post by **RobertBe** » Fri Nov 25, 2011 10:06 am

Mike wrote:I need to say you both have a rather naive point of view. This piece of hardware is not even beyond the first design stage...

Not naive but rather giving encouragement to Eslapion. After finishing the SUX 6400 project, I know how much work goes into producing a piece of hardware.

Still in Portland, Oregon,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug

eslapion · Post by **eslapion** » Sat Nov 26, 2011 9:04 pm

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)

On the NTSC VIC-20, Pin 38 and 39 of the VIC chip appears to receive a 14.31818MHz signal. This signal, assuming we use a VIC's built-in clock signal is therefore the theoretical maximum speed. AFAIK, the same clock speed as an Amiga 1200.

On the PAL VIC-20, this signal is 8.86MHz so you end up with a slower SuperCPU but still about 9 times faster than the normal speed.

Also, the policies I wanted to establish and described in my earlier posts are, I believe, in the domain of the wishful thinking.

The SCPU-VIC will have 32k of ram and 32k of ROM. The 32k of RAM will be mapped at $0000-$7FFF and the ROM will reflect the content of the ROM of a real VIC and will be mapped at $8000-$FFFF.

It will behave as a machine that has both a 3k RAM expansion and 24k ram expansion plugged in simultaneously as I don't want to add right now the necessary logic to activate/deactivate various areas of RAM expansion. BLK5 expansion will be temporarily disabled but a cartridge's content could be copied in the 32k ROM at the corresponding address.

Here's what I see:
All accesses except for the upper half of BLK0 ($1000-$1FFF) and the upper half of BLK4 will be redirected to the fast bus. When the CPU uses the fast bus, the slow bus is either stuck to a dummy read to $FFFF or to $0000

The upper half of BLK0 and the upper half of BLK4 are designated as "the exception areas" and are recognised by the following characteristics:
A15=X
A14=0
A13=0
A12=1

When the CPU accesses the exception areas, the CPU is halted for a period of at least half a slow cycle and up to a complete slow cycle.

All accesses to the exception areas are accepted only when S02 is low (the VIC's half cycle) but they are made effective (presented to the VIC-20) only when S02 is high (the slow 6502's half cycle). If a request is made when s02 is high then the CPU is halted and the information is only accepted at the following half cycle.

Registered logic will accept access requests to the exception areas when S02 is low and load-in the requested address and type of transaction and present it to the slow bus on the next rising edge of S02.

The result of the transaction (if its a read) is presented to the fast CPU on the following falling edge of S02.

If the operation performed was a write then the registered logic is reset and the slow bus returns to the dummy read status.

Then the RDY line goes back to high and the operations continue.

This is as simple as I can make it, AFAIK.