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

[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

[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.

[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?

[eslapion]

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.

[MCes]

Thanks Eslapion!

[Mike]

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.

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.

[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?

[eslapion]

I think you read too much of Jens Schönfeld's posts...

[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?)

[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 59 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

[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.

[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 (18.34 KiB) Viewed 1394 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 (4.54 KiB) Viewed 1394 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.

[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....