EEPROM - the Holy Grail of Sideways Rom?

[MartinB]

....pin 22 (nOE) is wired to IC73 pin 25 (nRDS) and pin 27 (nWE) is wired to IC73 pin 24 (nWDS)

Hmmm..... If you read any of the installation instructions in the thread, you’ll see that I specified RnW and WnR and that in response to another user having issues with nRDS and nWDS, I tried using the latter and found that they don’t work reliably for E2, if at all! Can you try using RnW/WnR please and see what you get - I originally suggested IC14 Pin 1 and IC33 Pin 11 for a Model B but they are available at various places.




In the end, the Master config I specified was cartridge-based only so I voided the Master references in the above schematic.

[KenLowe]

Will do re RnW/WnR. Please also see my edit on the previous post about where the corruption is happening, and a possible theory.

Edit: I'm seeing exactly the same 'corruption' using RnW & WnR.

[MartinB]

I haven’t got the source with me at the mo (just a matter of a netbook rather than an iPad) but yes, I do perform a write test although I didn’t realise I was leaving a ‘corruption’ in place unless I got sidetracked by the need for a physical write-protect switch and never properly reviewed that process... . Because of the latter though, soft-locking became less useful and since you must use hardware write-protect, in the short term you can just not use the facility and I’ll have a look at the code to see what’s going on. I’ll check the summing process too if you think there’s a funny with the base id but with a myriad of users out there, I’m curious as to why nobody has spotted these issues. Perhaps no-one else particularly uses soft-lock or summing but I though I’d had good feedback from people who do.

[KenLowe]

Because of the latter though, soft-locking became less useful and since you must use hardware write-protect, in the short term you can just not use the facility

Indeed, that's exactly what I'm doing.

I’ll have a look at the code to see what’s going on. I’ll check the summing process too if you think there’s a funny with the base id

I'll also take a look through the code to see if I can see anything obvious.

I’m curious as to why nobody has spotted these issues.

I seem to have a habit of breaking things!

Perhaps no-one else particularly uses soft-lock or summing but I though I’d had good feedback from people who do.

The SUM function seems to work fine in conjunction with my IntegraB board. One key difference, however, is that in the IntegraB board, the EEPROM upper and lower banks are adjacent to each other (ie *EEP32 SUM 89 / AB /CD / EF), whereas on the Beeb where I've seen the issue the upper and lower banks are 4 slots apart (ie *EEP32 SUM AE)

Thanks for persevering with me.

[MartinB]

Ok Ken, had a quick look and I can straight away see that the corruption problem is basically because I do a device-type test for LOCK and UNLOCK to check that the user isn't wasting their time with an unsuitable device or configuration thereof but what I don't do is restore the $FF EOR'd first byte after the test, somewhat as you suspected. Simple schoolboy error really but easy enough to fix. I haven't looked at the summing code, that'll probably be a weekend job....

(The workaround pending a fix if folk still want to use LOCK and UNLOCK is to do as Ken found and carry out each lock or unlock command twice in succession because the characteristic of an $FF EOR is to restore the original byte every two operations. For the possible checksum error, only use *EEP16 SUM <id> for the time being where <id> is a single hex sideways rom slot number and this will always work fine for 16k and 32k configurations.)

Thanks for persevering with me.

No worries at all - if there are bugs then they need fixing even if you're apparently the only person who cares.....

[KenLowe]

The workaround pending a fix if folk still want to use LOCK and UNLOCK is to do as Ken found and carry out each lock or unlock command twice in succession because the characteristic of an $FF EOR is to restore the original byte every two operations.

That will only work for the UNLOCK. For LOCK, the first time you run the command, corruption of the EEPROM will occur and then it will be soft locked, thereby preventing a subsequent LOCK from fixing it.
For UNLOCK, you need to run the command twice. The first time UNLOCK will attempt to write to the EEPROM (fix the corruption), but will fail because it is soft locked. It will then go on to soft unlock the EEPROM. On the second occasion, the corruption will be fixed, because the EEPROM is now unlocked. Note however, that any subsequent UNLOCKs (eg 3rd, 4th etc attempts) don't appear to cause any further corruption.

For the possible checksum error, only use *EEP16 SUM <id> for the time being where <id> is a single hex sideways rom slot number and this will always work fine for 16k and 32k configurations.

Confirming that works fine.

[daveejhitchins]

but I though I’d had good feedback from people who do.

Hmmm! I think this maybe a "I'm shy" issue! I seem to be suffering a similar issue with the MGC . . . I know there are several Games/Utilities that don't work on the MGC, however, I've had no feedback from users - which really surprises me

Dave H

[MartinB]

Does that include any of my utils Dave? If so, any details to share...?

@Ken - thanks for the clarification, I'll get on and sort it as soon as I've got a handle on the 32k SUM issue too...

[1024MAK]

In my case, it's more of a "not discovered the limitations due to being too lazy and or too busy, or distracted by other shiny new items"...

So, with Martin's tools, I have never bothered with the softlock, as I use a physical write protect switch.
I have also never tried the checksum commands...

And I have never tried to change the content on my MGC...

Maybe I'm not alone in this...

Mark

[KenLowe]

...and I was only driven down the route of using SUM because of the issues I was having with the LOCK command, otherwise I wouldn't have been looking at the SUM command either.

Edit:

I'll get on and sort it as soon as I've got a handle on the 32k SUM issue too...

Having had a quick look through the SUM function code in EEP32, it looks like you're expecting the upper bank to be in the slot immediately above the lower bank slot. This is why it works fine with my IntegraB board, but fails on a system where the EEPROM occupies 2 non contiguous slots:

Code: Select all

                   \switch to second bank of eeprom
	LDA	#$C       \elk dummy rom select
	JSR	romsel
	INC	tgtrom
	LDA	tgtrom    \select target device
	STA	$F4
	JSR	romsel
	JSR	chk24     \calculate second rom sum

Looks like a fairly simple fix, using LDA twinrom instead of INC tgtrom / LDA tgtrom for selecting the second bank. I've just tested this by changing LDA tgtrom to LDA twinrom, and it works for me . You could also ditch the INC tgtrom, but you would also need to ditch the DEC tgtrom further on in the code.

Edit 2: I've also moved the nOE & nWE back to nRDS and nWDS respectively and it's still all working fine.

[MartinB]

Thanks for the heads-up Ken, I was confused there for a moment because I’d forgotten that I sent you the sources! Clearly, I was not fully in the room when I tested the EEP utils . Anyway, I’ll sort out some fixes and then think about the hard part which is producing the releasable bundles for DFS and ADFS (spit)

[Mekon]

Hi - just letting people know I've figured out the problem with my set-up. It was, as Hoglet suggested, simply a matter of dodgy chips. When I tried one from a batch I'd got from Dave Hitchins, it worked perfectly - unlike the suspiciously cheap ones I'd ordered from China.

I also did a little experimenting whilst trying to get my EEPROM into my master. I programmed the thing in a Model B, then transferred it to an internal ROM socket on the Master. In order to enable write-protect, I isolated pin 27 from the socket and connected it via a resistor to pin 28. It seems to work a treat, so even if they're not programmable internally in a Master, they can at least be used in the place of EPROMs.

[DutchAcorn]

...So, with Martin's tools, I have never bothered with the softlock, as I use a physical write protect switch. ...

Same with me. The physical write protect negates the use of the soft lock so I never used it.

[KenLowe]

I might actually try some 29C256 flash memory instead to see if it works any better.

For anyone that's interested, my batch of AT29C256 flash memory arrived today from China, and is also working perfectly in my IntegraB.

Unlike the AT28C256 which is pin compatible with 32K SRAM, the AT29C256 is essentially pin compatible with 32K ROM (apart from pin 1 which is configured nWE instead of Vpp). Reconfiguration of some jumpers on the IntegraB board was all that was required to get the correct signals to the correct pins on the AT29C256.

The fact that the AT29C256 is essentially pin compatible with 32K ROM might make it slightly easier to install on some other ROM expansion boards, where it may only be necessary to install one wire link - from flash pin 1 to nWDS (via WP switch).

Martins EELOAD tool works fine with this flash memory as well. Once the previously discussed corruption issue has been fixed, the EEP32 lock / unlock functions should also work. In the interim, I'm just using the WP switch instead of soft lock.

Left most IC is the AT29C256 flash (banks 8/9), followed by 3 x AT28C256 EEPROM (banks A/B, C/D & E/F), followed by 3 x TC55257 RAM (2 for SWR - banks 4/5 & 6/7, 1 for shadow). Banks 0, 1, 2 & 3 are assigned to the four ROM sockets on the main Beeb board.

[MartinB]

Yes, I originally looked at the 29C256 and although it is slightly more pin-assignment compatible in relation to ‘normal’ Beeb-familiar memory devices, in the end I favoured the 28C256 because (I think) at least at that time four years ago, it was harder to source non-dubious examples of the former and they were much more expensive.

Regarding the couple of fixes for the EEPnn utils, it’s just as ever a personal bandwidth issue - the fixes themselves are 10-minute jobbies but producing and testing two releasable disc images to cover DFS and ADFS (spit), takes a reasonable amount of resource so I shall get a round tuit as soon as I can. [ I’m never idle on the Beeb front btw but my grasshopper mentality sometimes means I end up juggling way too many awesome (at least at the initial idea point ) projects. ]

[KenLowe]

in the end I favoured the 28C256 because (I think) at least at that time four years ago, it was harder to source non-dubious examples of the former and they were much more expensive.

A lot of my electronic component purchases come from China (via ebay), but fortunately I've been very lucky and never really had any quality issues. From my quick browse through ebay, I agree that the 29C256 does seem to be more expensive and less available. I'm not trying to push one type in preference to the other, just noting that both do work reliably in the Beeb. It's nice to have a number of different options.

but producing and testing two releasable disc images to cover DFS and ADFS (spit), takes a reasonable amount of resource so I shall get a round to it as soon as I can.

Happy to help you with this, if you wish.

I’m never idle on the Beeb front btw but my grasshopper mentality sometimes means I end up juggling way too many awesome (at least at the initial idea point ) projects.

Yes. I know that feeling!

[KenLowe]

I've just installed a few of these 29C256 flash ICs into my BBC+, and they're working great

Very little modification was required to get them working.The only thing I needed to do was disconnect pin 1 from each flash, and reroute this to nW on the main board (equivalent to nWDS on the old Beeb). I'm currently picking up nW from IC84 (UPD7002), pin24. The nOE signal that is presented to the flash already includes the nR (nRDS on the old beeb) signal, so unlike the original beeb, no modification was required there. See here for a little bit further info:

http://mdfs.net/Archive/BBCMicro/2008/07/25/104154.htm

I obviously also had to move the ROM bank 16k/32k jumpers over the the East position to bring the A14 line into play.

I haven't actually installed hardwired WP switches on this system, but I've made a quick and dirty patch to EEP32 so I can software lock each flash, and that's working very well too. SWRAM version of Elite was very rudely trampling over the flash if I didn't do this. I've not seen any ROMs yet that fail to work with this soft lock setup - albeit I've not tried an awful lot.

One thing I have noticed on the BBC+, and never picked up before, is that ROM bank E seems to be unavailable due to the way the OS & Basic are combined into a single ROM