Tricking the 6502 addressing to access 54KBytes of SRAM

Modding and Technical Issues

Moderator: Moderators

User avatar
MCes
Vic 20 Afficionado
Posts: 457
Joined: Fri Jul 24, 2015 1:19 am
Location: Italy

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by MCes »

Now how are you going to deselect the KERNAL ROM?
forcing LOW (from the cartridge) one of decoded cartridge enable that are the input of NAND UD9, the output of NAND go to 1 driving UF8 LS245 to insulate the CPU (and cartridge) data bus
"Two things are infinite, the universe and human stupidity, and I am not yet completely sure about the universe." (Albert Einstein)
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by Mike »

Address and data bus pins of BASIC and KERNAL ROM are directly connected to the 6502 and cartridge port.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by eslapion »

Kakemoms wrote:Wrong. This is a method to get 54K RAM addressable into an UMODIFIED Vic-20. Through the expansion port.
I understood that.

I suppose it's possible to do it on an unmodded VIC through the cart port if you also have a small board on the CPU socket.

Would that be "unmodified enough for your purposes?
MCes wrote:
Mike wrote:Now how are you going to deselect the KERNAL ROM?
forcing LOW (from the cartridge) one of decoded cartridge enable that are the input of NAND UD9, the output of NAND go to 1 driving UF8 LS245 to insulate the CPU (and cartridge) data bus
My idea is a bit more sophisticated.

RAMBOards for the 1541 used to generate a fake address to prevent the extra SRAM on the added board to generate a bus conflict with mirrored ROMs, VIAs or SRAM on the main board. I would do something similar.

If a CPLD can intercept the higher address lines of the CPU, it can either forward those lines as is to the VIC-20's board or when BLK6, 7 are mapped to RAM, forward the actual address lines to a SRAM chip but the VIC-20's board gets a dummy read/write to IO3 where there is actually nothing to cause conflict.

You can do this "fake address trick" for any area mapped to SRAM instead of what it normally is.
Be normal.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by Kakemoms »

MCes wrote:
Now how are you going to deselect the KERNAL ROM?
forcing LOW (from the cartridge) one of decoded cartridge enable that are the input of NAND UD9, the output of NAND go to 1 driving UF8 LS245 to insulate the CPU (and cartridge) data bus
That was the original idea, but as Mike points out, the Kernal resides on the wrong side of the buffer, so there is no point in disconnecting the buffer there. The Character ROM though resides on the other side so will be isolated and can be used (at least 3K of it). The problem then becomes to not respond during BASIC ROM access since you won't see the difference in signals (BLK4 and BLK6 access will look the same). A way might be to force the 245 buffers to shut and read the databus (if there is nothing on the databus, its the BLK4 that is trying to respond..).

As for not generating a bus conflict with the Kernal ROM... its complicated. The CS signal is the same as BLK7 which is unavailable on the expansion port. What is available on the expansion port is the A13 which is used for generating the BLK7. Basically you have to generate a bus conflict, but only on pin A13. If it will work I have no idea, but I may get crazy enough to test it... after the holidays.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by eslapion »

@Kakemoms
You don't seem to have much interest for my solution which does exactly what you were looking for in the first place without the need to apply conflicting outputs to the VIC's built-in LS decoder chips.
Be normal.
User avatar
MCes
Vic 20 Afficionado
Posts: 457
Joined: Fri Jul 24, 2015 1:19 am
Location: Italy

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by MCes »

I think that we have to stop and re-consider the problem from the starting point.

If I understood well Kakemoms want plan an external HW for unmodified VIC20.

Kakemoms is thinking about expanding ram more than the naturally decoded blocks but this specific method can't work
(ROM kernal/basic not deselectable if addressed)

If Kakemoms is thinking about a project that will start on "power on" then the SW has to be write into a ROM in BLK5 (autostart features) so: in (RAM1,2,3) BLK1,2,3 we can put: optionally another 8k program ROM (if needed), a whole RAM covered by a chip of 32Ksram and in a block a window of 8k where choose 1 of 16 pages of 8K from a chip 128Ksram (or 4pages from 32k chip, or.... ecc...).
Register for page could be done:
1) from user port (not recommended: only for start/test development)
2) from I/O2,3 (PIO 6522, or some chips for R/W register, or PLD, ecc..)


This is my thinking.
"Two things are infinite, the universe and human stupidity, and I am not yet completely sure about the universe." (Albert Einstein)
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by Kakemoms »

eslapion wrote:@Kakemoms
You don't seem to have much interest for my solution which does exactly what you were looking for in the first place without the need to apply conflicting outputs to the VIC's built-in LS decoder chips.
Sorry, but I didn't really understand the method you described. Maybe you could elaborate a little.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by eslapion »

Kakemoms wrote:
eslapion wrote:@Kakemoms
You don't seem to have much interest for my solution which does exactly what you were looking for in the first place without the need to apply conflicting outputs to the VIC's built-in LS decoder chips.
Sorry, but I didn't really understand the method you described. Maybe you could elaborate a little.
You want to be able to toggle specific areas of the memory map of the VIC-20 between added SRAM and whatever they normally are but only for the 6502, not for the 6560/61.

Inspired by the 1541 and RAMBOard:
The method I suggest is almost identical as used by RAMBOards in the 1541. Its is very difficult to add RAM to a 1541 because the way the address decoding is done on the mainboard causes the ROM, VIAs and RAM to have many mirrors all over the 64k addressable range. The solution on the RAMBOard is to have a 74LS257 generate a fake address for the mainboard when the 6502 addresses the extra added RAM. This fake address is generated by intercepting the higher address lines of the 6502.

In the 1541's RAMBOard, the 74LS257 will let these address lines pass intact when the 6502 addresses the real ROMs, in BLK 6, and 7 and the real SRAM and VIAs in BLK0. Usually the added RAM is in BLK3 so when the 6502 addresses BLK3, the 74LS257 replaces the 6502's top address lines with specific values that fools the 1541's mainboard into believing the 6502 is actually addressing a small region of 4k where there is nothing so no conflict occurs.

Doing the same for more areas in the VIC-20:
If we were to apply the same trick to something a bit more sophisticated than a 74LS257, we could intercept all calls from the 6502 to 8 addressing areas: 3k RAM expansion area, BLK1, 2, 3, lower half of 4, 5, 6 and 7. We do it by using a simple small CPLD such as a XC9536XL (used on PLAnkton) or even a more sophisitcated one like a XC9572XL and screening the 6 top address lines of the 6502.

Making the idea a reality:
Using a simple 8 bit register you can "POKE" at IO3 (dec. 39936) which individual address areas is mapped to the normal VIC-20 or to the added SRAM.

When the 6502 tries to address a region of RAM which hasn't been mapped to extra SRAM, the top 6 address lines of the 6502 will be passed unmodified to the VIC-20's mainboard. If the addressed region has been mapped to the added SRAM then one of two 32k x 8 SRAM chips receive the 6502's real address lines but the VIC-20's mainboard top 6 address lines receive a specific value which fools it into thinking the 6502 is trying to read/write IO3 (or IO2) which is completely empty.

The 32k x 8 SRAM always receive the 6502's real address lines (with one of the two using an inverted A15 as secondary !CS) but the !OE only gets activated if the 6502 is addressing a memory region mapped to extra SRAM.

Doing it through the cartridge port is a bit difficult but not unfeasible if you add a small board under the 6502. IMHO, the best way is by adding a small board under the 6502 with 3 only components on it: 2 SRAM chips of 32k x 8 and one CPLD - all surface mount and very compact.

The power load for something like that is going to be minimal, about 30mA in all. Most importantly, you can map in and out a total of 60k of RAM, even more than originally asked for and strictly no risk of damaging the VIC-20's 74LS chips.
Be normal.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by Kakemoms »

Interesting eslapion! Even if it defeats the original purpose of only using external expansion ports, it is a good alternative. I even found a download page to the universal peram with Eagle files. These guys even built their own from that, so it should be quite straight forward.

As for my plan A, I want to do some research on tricking the Vic-20 using non-conformant signals. There is the A13 and BLK signals than can enable some manipulation, even if one keep within spec of the 74LS. Only problem is the components that differ. My oldest Vic-20 has a MB74LS138 in which only shortform datasheets have been found. Most common seems to be F74LS138PC or M74LS138P. Some F are marked as Fairchild, some are not. Its the reality of component shortage. Edit: Actually I found a commond spec here.

To continue the original discussion of tricking signals, forcing a 1.5Volt onto A13 results in the interesting case were neither A13=0 or A13=1, so it would disable both BLK6 and BLK7 signals towards the Basic ROM and Kernal ROM. Since only A0-A12 are needed for setting an address range within the 8KByte ROM areas, no confusion should occur on these signals (hopefully).

Well, enough talk. I will test how a SN74LS138 reacts to this (e.g. current draw and heating). If it doesn't destroy it I will try to get hold of some old M/MB74LS138 and 74LS138PC and see that I don't fry any of those either.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by eslapion »

Kakemoms wrote:Interesting eslapion! Even if it defeats the original purpose of only using external expansion ports, it is a good alternative. I even found a download page to the universal peram with Eagle files. These guys even built their own from that, so it should be quite straight forward.
You could say it's a more sophisticated twist on the PETRAM. My idea is a board that's less than half that size and uses a modern CPLD instead of a GAL.

It has the virtue of providing exactly what you're asking for AND not requiring any mods to the VIC. However, intercepting the top six address lines of the CPU can only be done on the 6502's socket.

You could have the 6502, CPLD and both SRAM chips on a cartridge and only a small board connected to the CPU socket which would provide the few connections you can't get in the cart port.
As for my plan A, I want to do some research on tricking the Vic-20 using non-conformant signals. There is the A13 and BLK signals than can enable some manipulation, even if one keep within spec of the 74LS. Only problem is the components that differ. My oldest Vic-20 has a MB74LS138 in which only shortform datasheets have been found. Most common seems to be F74LS138PC or M74LS138P. Some F are marked as Fairchild, some are not. Its the reality of component shortage. Edit: Actually I found a commond spec here.
You can go on Digikey's web site to get TI's datasheet for the SN74LS138. I noticed they also have the datasheet for the (discontinued) Fairchild version, the DM74LS138.

All 74LS series chips have a low impedance when pulling down so I suspect defeating a pull down with an external source could damage the chip in the mid/long term.
Well, enough talk. I will test how a SN74LS138 reacts to this (e.g. current draw and heating). If it doesn't destroy it I will try to get hold of some old M/MB74LS138 and 74LS138PC and see that I don't fry any of those either.
I strongly suspect damage will be progressive.

Then again, if you bust it, this is not exactly an expensive chip to fix.

ADDED EDIT: I just realized if you use the type of board I suggested above along with a 32k RAM expansion which covers BLK 1,2,3,5 then you have a VIC-20 with an extra 92k of added RAM.

Perhaps there is an advantage of having it internal instead of the cartridge port.
Be normal.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by Kakemoms »

eslapion wrote:You could say it's a more sophisticated twist on the PETRAM. My idea is a board that's less than half that size and uses a modern CPLD instead of a GAL.

It has the virtue of providing exactly what you're asking for AND not requiring any mods to the VIC. However, intercepting the top six address lines of the CPU can only be done on the 6502's socket.

You could have the 6502, CPLD and both SRAM chips on a cartridge and only a small board connected to the CPU socket which would provide the few connections you can't get in the cart port.
I agree to that. The A15&A14 are not available on the expansion port, but I may have a less intrusive way of deducing their state:

The BLK7 signal can be deduced as explained in previous post. Thus A15=1, A14=1 and A13=1 in that case.

There is a way to deduce the BLK6 as well:
If all BLK1/2/3/5/7,RAM1/2/3,IO2/3,CLK2 are HIGH AND G input for the 74LS245 buffer (for the databus) is HIGH, BLK6 can only be LOW.

Now to find out whether the 74LS245 is isolating the databus from the internal SRAM, you only need to pull on the line and it will follow. This has to be done during CLK2=HIGH and before the Basic ROM responds to the address request. Fortunately the Basic ROM is slow (450ns response), so its not going to push anything onto the databus until CLK2=LOW. One can therefore hope that its output is tristate for some time after its CS line goes low (this needs to be tested).

The best way to pull a databus line (for example D0) would be to connect it to around 2.5Volt through a resistor and use a dual comparator to see if it went to the same voltage, or stayed around 0V or 5V. TI's LM319N should do the job with a propagation delay of 80ns (which is fast enough).

So with BLK6 signal deduced we only have to worry about BLK4..

I also want to point out that writing to a ROM area should be fine for an external SRAM. E.g. the CPU won't know its writing to a ROM and will output on both data and address bus. The strange thing is that there is nothing in the Vic-20 schematics that prevents the ROM from responding in such a case. So it looks like writing to a ROM is going to cause databus contention. Anyone seen this before?
eslapion wrote: ADDED EDIT: I just realized if you use the type of board I suggested above along with a 32k RAM expansion which covers BLK 1,2,3,5 then you have a VIC-20 with an extra 92k of added RAM.

Perhaps there is an advantage of having it internal instead of the cartridge port.
With paging my favourite is Alliance Memory 4Mbit SRAM. Its not so large and would fit well on a small CPU board. Less inductance and noise are added advantages of having it inside. That might become problematic if you run long wires from the cpu socket onto an external card. And having the expansion port free is also a nice advantage.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by eslapion »

Kakemoms wrote:I agree to that. The A15&A14 are not available on the expansion port, but I may have a less intrusive way of deducing their state
You must not only deduce them, you must also prevent their real values from being sent to the VIC-20's mainboard and replaced with values which cause a dummy access to IO2 or IO3 to prevent a conflict with the real ROMs if you mapped the accessed area to SRAM.

That's what the 1541 RAMBOard does.

In fact this is not just true for A15-A14. If you have a game cartridge plugged in and it uses BLK5 but you mapped BLK5 to extra SRAM, you know when BLK5 is accessed but you still have to prevent the game cartridge from responding. If you intercepted and replaced A15 to A10 to cause a dummy access then there never will be any conflict.
I also want to point out that writing to a ROM area should be fine for an external SRAM. E.g. the CPU won't know its writing to a ROM and will output on both data and address bus. The strange thing is that there is nothing in the Vic-20 schematics that prevents the ROM from responding in such a case. So it looks like writing to a ROM is going to cause databus contention. Anyone seen this before?
A lot of VIC-20 game cartridges try to self modify as a form of copy protection. Of course, the resulting conflict lasts only one or two CPU cycles and no damage occurs.

I did notice however that a few Atarisoft game cartridges tend to self destruct because of that. Probably they used poor quality ROMs. Then again it's better to have the ROMs destroy themselves instead of the CPU.
Be normal.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by Kakemoms »

eslapion wrote: You must not only deduce them, you must also prevent their real values from being sent to the VIC-20's mainboard and replaced with values which cause a dummy access to IO2 or IO3 to prevent a conflict with the real ROMs if you mapped the accessed area to SRAM.

That's what the 1541 RAMBOard does.
Of course. That is were I plan to use A13 and pull it down. In fact, by putting a 333Ohm resistor on the A13 I managed to pull its pulses down to to 2V. That is only a 9mA current draw. With the CLK2 sync its only 50% of that (in effective) and for real-world situations you can keep that pull even shorter (the ROM can respond, but if it responds too late, it won't affect the SRAM - CPU read response. Now, 2V is not 0V, but its at the point that the 74LS138 should stop responding (e.g. the CS line of the ROM won't go active). So with the ROM response out of the way, you can put in a SRAM response instead.
eslapion wrote:In fact this is not just true for A15-A14. If you have a game cartridge plugged in and it uses BLK5 but you mapped BLK5 to extra SRAM, you know when BLK5 is accessed but you still have to prevent the game cartridge from responding. If you intercepted and replaced A15 to A10 to cause a dummy access then there never will be any conflict.
Well, if the SRAM expansion is plugged into the expansion port, there is no need to worry about a cartridge there.
eslapion wrote: A lot of VIC-20 game cartridges try to self modify as a form of copy protection. Of course, the resulting conflict lasts only one or two CPU cycles and no damage occurs.

I did notice however that a few Atarisoft game cartridges tend to self destruct because of that. Probably they used poor quality ROMs. Then again it's better to have the ROMs destroy themselves instead of the CPU.
Self destruct from two cycles of bus conflict? That sounds really strange. Atari bought all of their ROM chips from MOS, so they should be the same as those inside the Vic-20. And I doubt Commodore engineers would have made a product that could self destruct (e.g. the Vic-20). Do you have more data on this?
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by eslapion »

Kakemoms wrote:Of course. That is were I plan to use A13 and pull it down.
Well that's something I know I would never do. The correct method is by using a multiplexer.
In fact, by putting a 333Ohm resistor on the A13 I managed to pull its pulses down to to 2V. That is only a 9mA current draw. With the CLK2 sync its only 50% of that (in effective) and for real-world situations you can keep that pull even shorter (the ROM can respond, but if it responds too late, it won't affect the SRAM - CPU read response. Now, 2V is not 0V, but its at the point that the 74LS138 should stop responding (e.g. the CS line of the ROM won't go active). So with the ROM response out of the way, you can put in a SRAM response instead.
Once more, there is absolutely no need to take this sort of risk with the logic chips of your VIC-20 if you have the top address lines of the CPU pass through a multiplexer instead.
Well, if the SRAM expansion is plugged into the expansion port, there is no need to worry about a cartridge there.
There are such things as cart port extenders. Also, if the device you make uses the cart port, it would far more useful and practical if it had a passthrough.
eslapion wrote: A lot of VIC-20 game cartridges try to self modify as a form of copy protection. Of course, the resulting conflict lasts only one or two CPU cycles and no damage occurs.

I did notice however that a few Atarisoft game cartridges tend to self destruct because of that. Probably they used poor quality ROMs. Then again it's better to have the ROMs destroy themselves instead of the CPU.
Self destruct from two cycles of bus conflict? That sounds really strange. Atari bought all of their ROM chips from MOS, so they should be the same as those inside the Vic-20. And I doubt Commodore engineers would have made a product that could self destruct (e.g. the Vic-20). Do you have more data on this?
If over a period of a few months you restart the VIC-20 in excess of a hundred times (which I did when I was 13-14 y.o.) then it's not so strange at all. At every reset, the cart tries to self modify.

My own Donkey Kong cart did that about 7 months after I bought it. Dozens of my friends had similar problems.

Damage is cumulative.
Be normal.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: Tricking the 6502 addressing to access 54KBytes of SRAM

Post by Kakemoms »

I understand you have personal objections, but without testing we would never know what is possible. There is certainly a lack of data on how much current one can draw from the 6502 lines, but short pulses seems to be ok. For WDC 65C02 I have seen 50mA mentioned and 100mA for the Rockwell 6502 (also see further down).

Whether the cartridges failed from poor ROM processing or copy protection we will never know, but since not every cartridge failed, it is more probable that the silicon processing quality was less than optimal. I would say they probably skipped on QA since accelerated lifetime testing should have picked that up.

I have done some more testing in order to decide how to best pull A13 down without drawing too much current from it.
To do this I wrote a short program:

Code: Select all

*=5000
                sei
loop2
                ldx     #255
loop1
                lda     $4000,X
                sta     $1000,x
                lda     $E000,X
                sta     $1000,x
                lda     #7
                sta     $9400,x
                dex
                bne     loop1
                jmp     loop2
This gave the following screen output (this data from $E000-$E0FF, e.g. the kernal ROM):
IMG_4603.JPG
A picoscope showed a 450ns spike on the A13 line (the 3+Volts are due to some wire capacitance of the setup):
A13_short_pulse.png
Preliminary test showed that a 47Ohm resistor would draw the A13 down (<0.8Volt) so that the screen showed the first data in the Basic ROM instead ($C000-$C0FF), but that is quite some current draw (85mA) and too much for my taste.

Two delay ICs (74LS31N) that gave me around 250-300ns delay were used:
Delays.png
These were used to make a delayed signal that was then put through a NAND with the original A13. The NAND output was fed back into the A13 through a 10 Ohm resistor. To limit the current, a 1KOhm resistor was used to feed the VCC of the NAND IC (74LS00). E.g. max average current draw is 5mA at that setting.

After the modification, the following signal could be observed on the A13:
A13_pulse.png
The output on the screen was then non-stable as no ROM was responding and the 74LS138 in the Vic-20 was not generating a CS signal for neither Basic ROM or Kernal ROM (sorry about the poor picture, but the same characters were on the top part of the screen):
IMG_4606.JPG
So. This hack seems to work. Its not very safe, so I will have to do long-time testing and such to be sure that nothing gets damaged. Basically its the 6502 that has to deliver all the current, so if damage occurs it will be on the A13 output line.

Edit: I remembered that NMOS is using a pullup resistor (load) on its output to push output high. In the event that the output is low, the NMOS transistors will pull that load as can be seen here: https://en.wikipedia.org/wiki/NMOS_logic. What we are doing here is basically pulling the same load externally. Still, testing will be the only way to make certain this is safe.
Post Reply