Thinking of a SuperCPU VIC

[TLovskog]

Forgive me for assuming you wanted to discuss the idea from all angles. I just wanted to vent my opinion about doing it all inside and with SMT components, since you needed to modify the VIC anyway. I didn't catch, until later, that you had ruled out the internal as an option.

Just wanted to have a discussion around building an internal accelerator, since I was thinking along those lines prior to settling for a cartridge.

When it comes to the actuall fit, I have of course TESTED it. Otherwise I wouldn't had been so sure of the fit.

I tested it with plugging in a board (1.6mm thick FR4) in the CPU socket. The board has a rather high thruhole pinheaders soldered. On top of it is some standard logic.

The bottom of the board is standing 5.4mm over the socket. Then we have the 1.6mm of PCB and the components on top is 1.55mm.

The components I had in mind is even lower than that. Any large capacitors or inductors could be fitted on the underside of the board. The PCB could also be made much thinner, say 1.2mm.

I hade no problems closing the case at all. Tested on all three of my "development" VICs. 2 with the 2-prong power and one with the DIN version.

That said the ROMs short edge is located much closer to the PCB edge than the CPUs longside edge. Perhaps that is the missing link. Also I do not know if there exists 2-prong versions with an even thicker keyboard.

Edit: Some spellings, better wording and corrections.

[eslapion]

I just wanted to vent my opinion about doing it all inside and with SMT components, since you needed to modify the VIC anyway.
...
When it comes to the actuall fit, I have of course TESTED it. Otherwise I wouldn't had been so sure of the fit.

Well, it is "possible" to fit something like that inside the VIC. I did succeed in placing a JiffyDOS in my old generation VIC but that made it a very special kind of ultrathin JiffyDOS. A lot of extra work.

Also, some VIC-20s have the CPU socket rotated by 90 degrees relative to the older design. I suspect having the accelerator in the CPU socket designed for the older VICs will cause physical conflicts in the VIC-20 Cr.

I want a solution that will work on all versions of the VIC-20 except perhaps, those which have the CPU soldered to the board.

And last but not least, I have a neurological disorder. Working with SMT is nice when I only have to do it every now and then. Making a bunch of SMT devices by myself is a pain. I am biologically forced to go the "through hole" way.

@Mike

Assuming your project is still in the beer-and-pizza phase, I thought you were open for suggestions and maybe hints how to proceed further.

Your opinion and hints are welcome. However, I do have a pretty clear idea where I want to go and your suggestions had been ruled out for many reasons.

I know its important to defend your position in a given project but at the same time, it is very time and energy consuming for me, given my neurological disorder to justify my position.

To me, this is quite simple:
- While you are technically forced to make the accelerator a form of 6502 replacement, there is no room inside the VIC to put it there. Even if there was, the contradictory space requirements makes it nearly impossible to make an internal accelerator who's PCB will fit in all VICs.

- Assuming only 2 address lines are missing on the cart port to put your processor replacement there, how difficult can it possibly be to replace the original 6502 with a simple device that carries the logic chips to deal with the clock signal properly and put on this device a small 2 pin connector that will provide the new accelerator with the missing lines on the cart port?

... then I gladly confess that unless you present a hardware prototype I am not going to contribute to the discussion in this thread any further.

This simply illustrates how extremely difficult it is for me to explain to people what I have in my mind and how disorganised it can appear to normal people.

Your reaction was not only to toss aside what I am trying to show, which is an extremely difficult job to begin with, but also to tell me explicitely that because I can't explain what I have in mind in a manner that is up to your standards then you will deny the precious help that I was seeking from you.

Nice job!

Thank you for your help and understanding...

[eslapion]

Wether we create a device that will connect to the cart port of the 6502 socket, this is what I think we need:

-A W65C02S based computer with its own 32k static RAM and own 32k PROM which contains a modified copy of the VIC's kernal, BASIC and CHAR ROMs.

-A system which will slow down the W65C02S to 1 MHz and synchronize it to the VIC-20's CPU bus everytime it requires access to memory areas $1000-$1FFF and $9000-$9FFF. These specific memory areas are characterized by the following values on the address bus:
A15 - X
A14 - 0
A13 - 0
A12 - 1

Also, the CPU of our new system runs at 10MHz or more but it will receive IRQ signals generated by a much slower architecture. How do we accomodate that?

Added edit:
BLK5 is a special case. It cannot contain data directly accessible by the 656X but its not RAM either. It can be a plugged in cart.

I suggest we deal with it in the same manner as "shadow firmware" was with early x86 PCs. We modify the VIC's kernal to copy at 1MHz the content it can find at this address range to 8k of high speed SRAM located at the same address. Once copied in faster RAM, this area then becomes fast access and read only just like BLK6 and BLK7.

Or... in other words: At powerup the BLK5 reads go out the standard 6502 bus at 1MHz, all writes go to a fast 8k x 8 SRAM at full speed. Once the copying process is completed, all writes are ignored and all reads go to the fast 8k SRAM.

Hence if you try to use a cart with the accelerator, its content is copied into fast SRAM and it too becomes accelerated.

BLK5 is characterized by the following values on the address bus:
A15 - 1
A14 - 0
A13 - 1

[TLovskog]

Well, it is "possible" to fit something like that inside the VIC. I did succeed in placing a JiffyDOS in my old generation VIC but that made it a very special kind of ultrathin JiffyDOS. A lot of extra work.

Also, some VIC-20s have the CPU socket rotated by 90 degrees relative to the older design. I suspect having the accelerator in the CPU socket designed for the older VICs will cause physical conflicts in the VIC-20 Cr.

I want a solution that will work on all versions of the VIC-20 except perhaps, those which have the CPU soldered to the board.

And last but not least, I have a neurological disorder. Working with SMT is nice when I only have to do it every now and then. Making a bunch of SMT devices by myself is a pain. I am biologically forced to go the "through hole" way.

Well that is of course a different story, and sorry to hear about the problems.

In my case, I have been working with design of mobile devices. Hardware, software, PCB design, Prototypes, etc all my 25+ working life. So I suppose I have a different angle altogether. SMT with 0402 and smaller is the bread and butter of life

I did do some mock-ups before shelving the idea ... for the time being.

The CR version with a rotated CPU will work. It is rotated the "right" way and the PCB part covering UD8-UF8 on the 2-prong version would now fill the void of the case with no PCB in the CR version.

Since an internal thingy is then, for good reasons, ruled out we are back to your cart/internal fix solution.

I will have to get back to you for the discussion on that with the glue logic for the clock signals. There are some tricky situations now when we try to feed the signals backwards into the VIC. However, as you point out most of the stuff (the C* signals) goes directly from the cartridge port to the CPU.

[eslapion]

SMT with 0402 and smaller is the bread and butter of life

Ouch! 0402!! That's jewelry by my standards!!

The CR version with a rotated CPU will work. It is rotated the "right" way and the PCB part covering UD8-UF8 on the 2-prong version would now fill the void of the case with no PCB in the CR version.

Since an internal thingy is then, for good reasons, ruled out we are back to your cart/internal fix solution.

I "see" where you're going.

Please note the vertical space premium problem on the 2-prong VIC is much more prevalent when you have a PET style keyboard. The second and third generations of keyboard do not suffer this problem as much.

Although the 3rd generation of keyboard almost only appears on the VIC-20 Cr

I will have to get back to you for the discussion on that with the glue logic for the clock signals. There are some tricky situations now when we try to feed the signals backwards into the VIC. However, as you point out most of the stuff (the C* signals) goes directly from the cartridge port to the CPU.

That is essentially the idea. So I guess it doesn't matter that much wether we go for an internal or external solution.

Modding the kernal requires some software expert.

[TLovskog]

Ouch! 0402!! That's jewelry by my standards!!

Then this might be interesting. It is a 01005 (Imperial) on my Junghans wristwatch. The white spot on the 'G' in Junghans is dust.

Please note the vertical space premium problem on the 2-prong VIC is much more prevalent when you have a PET style keyboard. The second and third generations of keyboard do not suffer this problem as much.

Auch to ... hm ... Was the PET Style common for the VIC or was that the first run only? Is there a foolproof way of knowing which style of keyboard you have? Like serialnumbers or similair. Or is the fontstyle enough?

[eslapion]

Auch to ... hm ... Was the PET Style common for the VIC or was that the first run only? Is there a foolproof way of knowing which style of keyboard you have? Like serialnumbers or similair. Or is the fontstyle enough?

The PET style keyboard was on all VIC-1001 and all VIC-20s sold in north america in 1981.

The font is pretty reliable when it comes to distinguishing them but there is an unmistakable way to know and that is the sound.

The PET style keyboards produce a steely "ka-tong ka-tong" like sound that no other keyboards produce, except, perhaps original IBM PC keyboards.

Its too bad there are no sideway pictures on the wiki to show the internal difference.

[sjgray]

Just a thought: On the PET a few expansion boards (like the SuperPET board) connect to the 6502 via a short ribbon cable and then mount the 6502 on its own board. Wouldn't it be possible to support both VIC models by relocating said proposed CPU board to the back of the machine where all the space is?

Steve

[eslapion]

Just a thought: On the PET a few expansion boards (like the SuperPET board) connect to the 6502 via a short ribbon cable and then mount the 6502 on its own board. Wouldn't it be possible to support both VIC models by relocating said proposed CPU board to the back of the machine where all the space is?

That sure is possible.

But, as me and Thomas have discussed, most of the CPU lines are on the cart port anyways.

The most important problems are getting a 14MHz CPU to get connected to a 1MHz bus, as I indicated earlier.

Nobody seems to have an answer to the technical challenges I indicated and Mike has decided that he was angry at me because I communicate with people as the autistic man that I am...

This is not going anywhere...

[PhilRanger]

What about adding some buffers for the address and data bus for the 1MHz stuff, and detecting these address to launch an interrupt that would basically just wait for the data to be processed?

[eslapion]

What about adding some buffers for the address and data bus for the 1MHz stuff, and detecting these address to launch an interrupt that would basically just wait for the data to be processed?

I guess that's the general idea. I indicated above what could potentially trigger such "interrupt" (please note this has nothing to do with IRQ or NMI) but the problem is the low level electronics.

Assuming you've detected an access to the upper half of BLK0 or upper half of BLK4, what electronic chips or logic circuits do you use to deal with this properly?

[Mike]

I had a short PM exchange with Francois, and we were able to clear up the matter.

Assuming you've detected an access to the upper half of BLK0 or upper half of BLK4, what electronic chips or logic circuits do you use to deal with this properly?

While not many programs use the bottom 1K RAM to hold video data, the VIC is able to access that, too.

But in that case, slowing down zero-page and stack-accesses would be rather counterproductive, so we could rather declare the lower 1K as fast RAM.

It depends whether the new CPU allows to stretch a memory access cycle. I'd set a CPLD on the CPU side of the address bus, data bus, and clock lines. It fakes a non-destructive read cycle to the mainboard while the CPU accesses fast memory. When slow memory or I/O is accessed, it needs to hold the CPU:

1. while VIC takes its half cycle, or
2. when the CPU does the access not right at the beginning of its own 'original' half cycle.

granting access as soon as VIC releases the bus, and stretching the cycle until VIC wants to have the bus again. Acknowledging point 2. ensures, that the slow RAM and I/O are able commit register changes without problems. Also, when their registers are read out, the data on the bus is able to settle. As mentioned above, there should be a local read-only copy of BASIC and KERNAL ROM, so it can be accessed fast. Maybe it is sensible, to cache the character ROM, too.

That way, the mainboard logic never 'sees' signals with less than 500 ns cycle time. Effectively, you have 3 busses now: the VIC bus, the old CPU bus ("chip RAM") and the new CPU bus ("fast RAM"), the last two separated by the CPLD.

The faster clock would need to be derived with some form of PLL, with a timing that ensures, that no memory access of the Super CPU straddles across the hand-over between the half-cycles of VIC and CPU.

[eslapion]

I had a short PM exchange with Francois, and we were able to clear up the matter.

Thank you very much.

Assuming you've detected an access to the upper half of BLK0 or upper half of BLK4, what electronic chips or logic circuits do you use to deal with this properly?

While not many programs use the bottom 1K RAM to hold video data, the VIC is able to access that, too.

But in that case, slowing down zero-page and stack-accesses would be rather counterproductive, so we could rather declare the lower 1K as fast RAM.

Specifically because of the stack access and the zero page. I think its best to declare $0000-$0FFF as fast ram. Since we have a minimum of 32k of fast ram, this also provides us with a free 3k ram expansion in fast ram.

Programs which use the first 1k for video data should still run fine but with garbled characters on the screen.

It depends whether the new CPU allows to stretch a memory access cycle. I'd set a CPLD on the CPU side of the address bus, data bus, and clock lines. It fakes a non-destructive read cycle to the mainboard while the CPU accesses fast memory. When slow memory or I/O is accessed, it needs to hold the CPU:

1. while VIC takes its half cycle, or
2. when the CPU does the access not right at the beginning of its own 'original' half cycle.

granting access as soon as VIC releases the bus, and stretching the cycle until VIC wants to have the bus again. Acknowledging point 2. ensures, that the slow RAM and I/O are able commit register changes without problems. Also, when their registers are read out, the data on the bus is able to settle. As mentioned above, there should be a local read-only copy of BASIC and KERNAL ROM, so it can be accessed fast. Maybe it is sensible, to cache the character ROM, too.

That way, the mainboard logic never 'sees' signals with less than 500 ns cycle time. Effectively, you have 3 busses now: the VIC bus, the old CPU bus ("chip RAM") and the new CPU bus ("fast RAM"), the last two separated by the CPLD.

The faster clock would need to be derived with some form of PLL, with a timing that ensures, that no memory access of the Super CPU straddles across the hand-over between the half-cycles of VIC and CPU.

This clearly reflects what I had in mind.

Maybe we don't need a PLL. The 656X derives the 1.02MHz clock for the main architecture from a 14.31818MHz crystal connected via a few logic gates to pins 38 and 39. We could clock the W65C02S directly from that signal which is syncroneous relative to the main architecture.

Also, the new CPU bus comprises not only 32k of fast static ram but also 32k of rom containing a copy of the char, Basic and a modded kernal ROM. Can we call it the fast bus?

Can we also agree that we will only use a W65C02S and not a 65816?

If I followup on your idea, we should have a mechanisn which detects accesses to BLK0 (upper half) and BLK4 (upper half). When such a condition is detected, the W65C02S's RDY line becomes held low and all RAM/ROM on the fast bus are /CS inhibited (except for reads and writes to $1000-$1FFF - see added edit). The mechanism then waits for the next rising edge of the S02 line.

At that point, we may have an S02 high but not enough of this half cycle may be left to make a good access. When the next S02 rising edge is detected, the address, data and RW lines from the new CPU are applied to the old CPU bus and it stays that way for the next 450ns. RDY is still low at that point.

Once the 450ns have passed, the RDY line goes high. If the CPU was making a read then it latches on the returned value and the CPLD uses the same address to perform dummy reads on the following cycles of old CPU bus until a new access is required. If the CPU was performing a write then the CPLD keeps applying the same values on the old CPU bus for one more cycle and releases the fast CPU's RDY line.

Also since the new CPU supports DMA which the original did not, perhaps it is possible to offer direct to SD Card storage.

Added edit:
From what I can see on the VIC's schematics, the 656X leaves the bus accessible to the CPU when pin 35 (Po1) is low and this line is inverted to become S02.

If a program for the unexpanded VIC is run then since we slow down the new CPU everytime "chip ram" is accessed then the level of acceleration becomes negligible. We could alleviate this problem by declaring that fast ram contains a copy of chip ram and slowing the cpu on writes to $1000-$1FFF but not on reads as the fast ram contains the same data.

Also, most basic programs designed for the unexpanded VIC will also operate with 3k expansion which is now full fast ram.

[eslapion]

@Mike:
Did I understand you correctly?

Did my last post go in the same direction as you see?

[Mike]

Hi,

Did I understand you correctly? Did my last post go in the same direction as you see?

In the broad picture, yes.

The 6502 is removed, and replaced by a small logic which provides A14, A15 and Phi1, Phi2 from the clock input. The new CPU sits on an external cartridge. However, the extra signals do not necessarily need to be provided on the cartridge port, IMO they could just use a signal cable.

I think it is important, that the new CPU is able to have its memory access stretched. It will put the required memory address on the bus, and the CPLD needs enough time to decide, whether the access can be satisfied by fast memory or it has to stall the CPU during the memory access for at least a full non-VIC cycle on the mainboard.

I have to think about what the clock generator circuit might do with the extra load.

Michael