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

[MartinB]

Attached is an update to the eeprom configuration and programming utilities which takes EEP16 and EEP32 from version 4.1 up to version 4.2. EELOAD is unchanged and remains at version 4.1.

- Both EEPxx utilities have a bug-fix incorporated to correct an issue which was causing a corruption of the target eeprom device first byte (installed address $8000) when the LOCK and UNLOCK switches are used. This has now been fixed.

- EEP32 also has a further fix incorporated to correct an issue whereby the SUM switch would always display the checksum for the two consecutive sideways bank ID's numbered from the first ID specified regardless of the actual specified ID of the second bank. For example, *EEP32 SUM 48 would actually calculate and display the checksums for banks 4 and 5 rather than the specified banks 4 and 8. This has now been fixed.

In both cases, many thanks to Stardot member KenLowe for discovering and reporting the bugs

The attached zip contains DFS ssd and ADFS adf images where both include the three utilities and some test images. The programs are all ADFS compatible as long as PAGE on the host machine does not exceed $1D00.

===============================================================
A basic usage reminder of the eeprom configuration and programming utils for anyone unfamiliar....

*EELOAD <(filename) (@)> <id>

e.g. *EELOAD TESTAA 1

[ Specifying '@' instead of a filename causes the target eeprom to be programmed from main ram at $3000-$6FFF ]

*EEP16 <(LOCK)(UNLOCK)(ERASE)(SUM)(OFF)> <id>

e.g. *EEP16 ERASE 2

*EEP32 <(LOCK)(UNLOCK)(ERASE)(SUM)(OFF)> <idL><idH>

e.g. *EEP32 UNLOCK 01


The EEP16 util applies to a 16k AT28C256 configuration (single-eeprom, single sideways bank ID) where eeprom A14 and A12 are shorted (see thread for details) and the EEP32 util applies to a 32k AT28C256 configuration (single-eeprom, dual sideways bank ID's). EELOAD is used with both configurations.

Notes :

1. EELOAD can also be used to load disc or memory-based rom images and data into almost any standard sideways ram implementation.

2. The EEPxx SUM and OFF command switches are not exclusively eeprom-specific and can also be used with any sideways rom or ram bank.

3. The EEPxx LOCK, UNLOCK and ERASE command switches should not be used with standard sideways ram as they will cause corruptions. This is because for such functions, EEPROM devices employ JEDEC 'magic address' sequences of writes that configure the chip without actually writing any data whereas SWR would simply have these 'magic' locations corrupted.

4. All three utilities load and execute in main user memory at $1D00 and so any resident programs or data should be saved before using the utilities because the former will be overwritten.

5. Typing any of the three command names followed by <Return> with no switches or parameters will show the version number of the given utility.

===============================================================

V4+ EEPROM Utilities 290518.zip

(3.61 KiB) Downloaded 8 times

[Stewie66]

knock out some more notes...

OK, here goes:

- cut track connecting centre and top holes on L1 - top of board(assuming default configuration of Sprow board)

- cut track connecting centre and bottom holes on L2 - bottom of board

- connect centre of switch to centre hole of L1 (note: all connections are to PTH's on board)
- connect top of switch (write protect on) to 5V rail
- connect bottom of switch (write protect off) to top hole of L1
- connect centre hole of L2 to A22 (0V)
- lift pin 1 of EEPROM and connect to bottom hole of L2

HTH,

Mike

Hi, I'm interested in tying this as I have a also have a couple of spare sparrow cartridges, however I can no longer see the pictures in this post, is it possible to get them reposted

Cheers
Stewie

[MartinB]

All my posted pics on this thread are still present and correct so I don't know if the missing ones are a consequence of the recent site upgrade or because Mike (mjf2708) hosted them remotely and the images are no longer available on his remote site. Perhaps a forum admin could advise or you could send a PM to Mike....?

[1024MAK]

@Stewie
In his posts, Mike (mjf2708) linked to images stored at an external photo/image site. So you best contact him direct.

Mark

[Elminster]

Hmmm. I asked how to do it but never got around to trying. Pity as I have the spare cartridge slot, and the eeprom. Just forgot. Shame or I could just photo what I did.

[MartinB]

I don't have one of Sprow's cartridges but I did post details of how I modified a standard Elk cart to take an AT28C256 eeprom such that it works fine with these utilities.

Have a looky here.......

...also, on page 10 of this thread, I posted details of how to modify a Master cartridge and I even modified the eeprom programming method within EELOAD to suit the vagaries of the Master.

Have a looky here.......

[Elminster]

This might help from Sprow's site.

The layout to show where L1-L3 are

http://www.sprow.co.uk/bbc/hardware/car ... tlinks.gif

[Elminster]

So I think these need to be cut where the pink bit is

[Elminster]

And if I read the instructions right that would give something like (if someone can double check)

[Stewie66]

And if I read the instructions right that would give something like (if someone can double check)

Yep, have just followed them and now have the EEPROM up and running from the cartridge slot

Thanks for everybody’s help

Cheers
Stewie

[Elminster]

Great. Thanks for testing, now I can follow my own interpretation of the instructions, with out destroying my own cards