Accessing the Video RAM through the expansion port

[Kakemoms]

I have been studying the Vic-20 schematics for some time and I think I may have a way of writing to the character memory through the expansion port. It is untested, so there may be ways that prevents this from working, but it theory it may be possible:

The 74LS245N are bus transceivers that effectively isolates the internal 6502 (address/databus) + expansion port from accessing the internal RAM while the VIC 6560/1 is reading from it. The address bus direction is ALWAYS from the 6502 towards the VIC/RAM side, while the databus is bidirectional. The address bus isolation is controlled by a clock output on the VIC, but the databus is not. This is were it becomes interesting because the direction and isolation of the databus (74LS245N) is controlled by two signals that are found on the expansion port. The 74LS245N output enable (OE, also called G) will get HIGH and isolate the databus if one of the RAM1/2/3 or BLK2/3/4 or 5 signals are low, e.g. if the internal 6502 is accessing any expansion port memory. It also gets HIGH if CLK2 is low, so it would stop there if we could not affect this.

The CLK2 comes from the 6502 but goes through a set of logical gates of which the last one is a NOT gate. It is possible to force CLK2 high without affecting anything prior to that gate. The internal memory is accessed at 2MHz (multiplexed) so it should be ok.

Now, to get data through the 74LS245, the direction will also need to be set correctly so we need to force R/W to high while CLK2 is low. This will push data through onto the video-side of the bus AND set the RAM to write enable. This might be the worst part because the 6502 R/W will be low and we will force it high. If we compare with the VIC chip's R/W output, the 6502 is effectively forcing that HIGH as well when the 6502 is writing to the RAM, so it looks like that is ok, but then the 6560 is probably tristate?

So how to get the data into the correct address location? Well, the VIC chip is quite nice as it always reads the same locations while it is working. Thus, by timing it correctly one can address all the screen and character memory locations. Not easy, but possible, at least in theory.

[Mike]

The data bus buffer UF8 is completely blocked while VIC has the turn and accesses its side of the bus. As you've noticed, SΦ2 goes into UD9 (the 13-input NAND) which controls the active-low enable signal of UF8. And that goes high either if the CPU accesses anything on its side (see the long list of BLK1..3, BLK5, BLK6..7 (BASIC and KERNAL), RAM1..3, I/O 2..3) ... or SΦ2=0 and thus VIC is active. Forcing VR/W=0 from the outside is then only going to 'shot' everything in the internal RAM an unsuspecting VIC just was going to read. (I think you got the levels of the %R/W signals wrong. It literally reads "read, not write", i.e. %R/W = 1 is read access, %R/W = 0 is write access.)

With NMOS or TTL logic, the low-level takes precedence - if you try to enforce SΦ2=1 from the outside with a stronger output, you'll kill UC2 within short time, and disturb quite some chips (UC5/UC6 and both VIAs) anyhow.

...

A much less brutal, and actually working method of updating the Video RAM with data from the expansion port was introduced by tokra and me with the CPU emulated DMA put to use in our new graphic modes.

[Kakemoms]

Oh sorry about that. I meant to force RW low.

Yea, as clk2 goes low the VIC is active, but that also means the CPU is inactive on the databus. The VIC only reads, so when the RAM sees WE enable, there is no data coming out from that part. Thus the VIC ends up reading data from the expansion port (and the RAM will store it).

I think forcing clk2 high should be ok, but it requires some probing. It will put UF8 high while the VIC is active.

[mrr19121970]

Are you planning a turbo chameleon for the vic20 ?

[Mike]

I think forcing clk2 high should be ok, [...]

No, it isn't. At least it's only UC2 you're going to fry.

Are you planning a turbo chameleon for the vic20 ?

That, or people are still in the hope to replicate part *) of the functionality of my VFLI mod without the necessity to make changes on the mainboard.


*) the expanded colour RAM would still be missing

[Kakemoms]

No, it isn't. At least it's only UC2 you're going to fry.

Well, there is a ferrite bead before the UC2, so maybe I could try a higher frequency asymmetric high/low which the bead would block..

That, or people are still in the hope to replicate part *) of the functionality of my VFLI mod without the necessity to make changes on the mainboard.

*) the expanded colour RAM would still be missing

No color, so it won't be. Well, actually I have already been able to make random character colors by mis-wiring my expansion... But it was probably more like confusing the databus during reset (resulting in random colormap values). Very strange anyway as the rest worked fine (Basic, characters ++).

[Mike]

Well, there is a ferrite bead before the UC2, so maybe I could try a higher frequency asymmetric high/low which the bead would block..

Whatever you think. Just take a 74LS04 from a glass jar and measure how much current a low level output can sink before its voltage passes the threshold of 2.4 V (i.e. minimum of high level from an output). It is just a single Schottky transistor in the output stage then, which has to take all that power.

Well, actually I have already been able to make random character colors by mis-wiring my expansion...

Of course. Making all four channels of UD1 (4066) pass the signals between BD0..3 and VD8..11 by forcing SΦ2=1 isn't going to help either.

[Kakemoms]

Well, no forcing of clk2 was involved. Simply pushing data onto the databus at wrong times. The 74LS245N seems to let some things through, maybe its a little slow to respond..