usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Modding and Technical Issues

Moderator: Moderators

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

usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by MCes »

Hi,
I'm thinking about improving a cartridge RAM expansion with a switch that inhibit the WRITE signal because it could be useful for run the SW that check the kind of memory on they are (RAM/ROM) and stop if it isn't ROM.

Inhibit the write on all RAM blocks of the cartridge is simple.
More complex could be inhibit writing only on BLK 5, but is it useful?

Please tell me your experience with this kind of problem.
Thanks
"Two things are infinite, the universe and human stupidity, and I am not yet completely sure about the universe." (Albert Einstein)
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by eslapion »

More complex could be inhibit writing only on BLK 5, but is it useful?
Its not more complex at all unless your expansion is a single chip 32k.

I did that accidentally back in the 1980s. I put a switch that pulled high only the R/W line of the specific 8k x8 SRAM chip connected to BLK5.

Many 16k carts no longer worked properly including Krazy Antiks.
Be normal.
User avatar
MCes
Vic 20 Afficionado
Posts: 457
Joined: Fri Jul 24, 2015 1:19 am
Location: Italy

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by MCes »

my expansion has inside only 1 chip of 32K RAM.....
I'm interested in knowing if there are applications that need some expansion RAM (BLK1,2,3) with "BLK 5(or else) Write-inhibited".

Otherwise I could simply inhibit the write signal (via switch) of the entire RAM chip (ALL ram memory into the expansion: BLK1,2,3,5).
So: is useful restrict the inhibition only at BLK5?
"Two things are infinite, the universe and human stupidity, and I am not yet completely sure about the universe." (Albert Einstein)
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by eslapion »

MCes wrote:I'm interested in knowing if there are applications that need some expansion RAM (BLK1,2,3) with "BLK 5(or else) Write-inhibited".
AFAIK, there isn't any. Even SuperExpander which resides in BLK5 but can take advantage of RAM expansion in BLK1,2,3 will not cause problems if you leave all RAM write enabled.
Be normal.
User avatar
MCes
Vic 20 Afficionado
Posts: 457
Joined: Fri Jul 24, 2015 1:19 am
Location: Italy

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by MCes »

Thanks Eslapion!
"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: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by Mike »

MCes wrote:I'm interested in knowing if there are applications that need some expansion RAM (BLK1,2,3) with "BLK 5(or else) Write-inhibited".
eslapion wrote:AFAIK, there isn't any. Even SuperExpander which resides in BLK5 but can take advantage of RAM expansion in BLK1,2,3 will not cause problems if you leave all RAM write enabled.
Exceptions confirm the rule.

RTC V-Link does writes to its own address range, which destroys the code, when it's loaded to non-write-protected RAM in BLK5, as a means of copy-protection. It's a BASIC extension similar to BASIC V4, with extra routines to drive the user port either as IEEE-488 or as parallel printer port. A prototype came as refurbished +3K RAM expansion with an extra EPROM carrying the extension.

Of course that extension would be more than happy to use extra RAM in BLKs 1..3, but RAM in BLK5 would need to be write-protected.

Further down that thread, I provided the binary together with re-engineered source code, so anyone inclined can try out to find the dangerous writes and build a version that doesn't need the write protection. :P
User avatar
MCes
Vic 20 Afficionado
Posts: 457
Joined: Fri Jul 24, 2015 1:19 am
Location: Italy

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by MCes »

from solution to problem......
If I interrupt the Write line:
for the RAM chip each "write cycles" become a "read cycle"....
so CPU and RAM put (different) data on DATA BUS simultaneously,
isn't it a BUS conflict?
"Two things are infinite, the universe and human stupidity, and I am not yet completely sure about the universe." (Albert Einstein)
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by eslapion »

I think you read too much of Jens Schönfeld's posts...
Be normal.
User avatar
MCes
Vic 20 Afficionado
Posts: 457
Joined: Fri Jul 24, 2015 1:19 am
Location: Italy

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by MCes »

what's happening on DATA BUS when CPU try to write on RAM with RAM's R/W line forced High ?
CPU is putting data on it, the selected RAM is putting other data on it......
It's a problem! (isn't it?)
"Two things are infinite, the universe and human stupidity, and I am not yet completely sure about the universe." (Albert Einstein)
yogi
Vic 20 Drifter
Posts: 36
Joined: Wed Apr 08, 2015 9:49 am

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by yogi »

what's happening on DATA BUS when CPU try to write on RAM with RAM's R/W line forced High ?
CPU is putting data on it, the selected RAM is putting other data on it......
It's a problem! (isn't it?)
It depends on how you are using /OE, /WE and /CS.

If you are using these input separately then you wouldn't have a problem. I.E the /BLK5 driving the /CS; VR/W going to (or not) to /WE, and /(VR/W) to /OE. During a write cycle the inverted R/W would be driving /OE hi and IF /WE is blocked it would be Hi. In this state even though /CS is Lo neither /OE or /WE would be Lo and the SRAM will not come out of tri-state.

Sometimes /CS and /OE are tied together , and this works fine with RAM most the time. The combination of /CS and /WE active LOW takes precedence over the state of /OE. So having all three inputs Lo is a Write cycle. But, blocking the /WE line during this cycle would look like a Read cycle and you would have buss contention.
Yogi
EDIT:
here is a simple design for example:
Example SRAM CTRL.zip
(11.4 KiB) Downloaded 46 times
The Write Protection is a jumper block; Closed=WP, OPEN=R/W. But you could just as easy use a logic input of some sort. In which case you could drop the Pull up R and GND, driving the NAND input directly.

Had to put the PDF in a ZIP for the board :)
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by eslapion »

AFAIK, the self modifying carts do cause bus contentions. They last about 500ns.

It seems to me this is not long enough to cause damage.
Be normal.
User avatar
Richardc64
Vic 20 Drifter
Posts: 33
Joined: Mon Feb 01, 2010 3:55 pm

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by Richardc64 »

The possibility of buss contention still exists in the simple design, Yogi.

VR/W goes low -- if it's going to go low -- near the end of SO2. (PH2) /CS will go low at the start of SO2, and so will the SRAM /OE, putting data on the buss at the same time as the 6502. The duration of this contention will be even shorter than the 500nS eslapion mentioned, but to eliminate it completely, a better approach would be use another NAND to invert CR/W, which will go low long before VR/W does -- during SO1, in fact -- and use that to disable /OE.
wp_nand.gif
wp_nand.gif (18.34 KiB) Viewed 1064 times
Another method to achieve Write Protect and at the same time prevent buss contention would be to just not let /CS go low when you don't want /WRite to happen.
wp_nand2.gif
wp_nand2.gif (4.54 KiB) Viewed 1064 times
This is all well and good, but we might be getting worked up over nothing. Consider the VIC-20 architecture as it is: There is no logic to prevent buss contention in BLK0, the built in memory. Neither is there any logic present to prevent WRiting to the system ROMs, which don't have /OE pins that might be used to prevent buss contention. If a POKE or loop of POKEs were to go astray, due to a programming error or whatever, that would be a serious case of colliding data.

Has such an event ever occurred and caused any damage? I don't know.
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler
User avatar
MCes
Vic 20 Afficionado
Posts: 457
Joined: Fri Jul 24, 2015 1:19 am
Location: Italy

Re: usefulness of partial inhibition (and not all) of the writing on the RAM expansion

Post by MCes »

in VIC 20 there are address that write (and READ!!!!!) simultaneously in (from) VIA 1, VIA 2, VIC (see CS1 line on VIAs....) .
The READing in this address will put on data bus 3 different devices......
To prevent this in C64 there is the PLA....
"Two things are infinite, the universe and human stupidity, and I am not yet completely sure about the universe." (Albert Einstein)
Post Reply