This thread was for the Electron - which turned out to be easy e.g. just removing the battery and replacing the SRAM with the 28C256 Flash/EEPROM worked. The ABR for the Master seems to be causing me problems

First I tried exactly what I did for the Electron - Master wouldn't even start-up. Hmmmm! Time to look closly at what I was doing inside the PLD (GAL16V8 25ns/15ns < tried both). I couldn't see anything obvious - so:

Just picked up this issue again, as it was starting to bug me. I'd had some suggestions form Steve Picton (thanks Steve) - I'll list what I've done since restarting the investigation.

I'd been reading MartinB's thread EEPROM - the Holy Grail of Sideways Rom? - although I haven't one of Spro's boards I have my ARA II board. They're a little tricker to modify as pin one is connected to +5V - However, I modified a bare PCB so it was easy. The result was I have a working ARA II board with a 28C256 plugged into it.

Next . . . To take some reference 'scope shots, ARA II, of the three control signals: nCS, nOE and R/nW
Top trace down = T2, nCS, Noe and R/nW (for all 'scope traces)

The only differences I now have, from the modified ARA II, is nCS passes through the DS1210 and all three signals pass through the PLD.

Bridged out the DS1210 - no change! Anyone have any things to try or check?

Note: If I load a valid image into the 28C256 I can read it, save it and use it OK! If I replace the 28C256 with RAM I can read and write to it OK!! So It's just a write issue to the 28C256 . . . I've checked with the data sheet and all write parameters seem to be met!!!

I’m on hols Dave as you know but quickly, I didn’t ever get my eeprom stuff working in a Master internal socket but everything was fine in a cartridge. That’s probably no help whatsoever but just thought I’d mention it...

.

Last edited by MartinB on Sat Aug 11, 2018 2:43 pm, edited 1 time in total.

I’m on hols Dave as you know but quickly, I didn’t ever get my eeprom stuff working in a Master internal socket but everything was fine in a cartridge. That’s probably no help whatsoever but just thought I’d mention it...

Thanks, Martin . . . I think Steve must have, as I'm sure one or more of his boards uses EEPROM.

I'm going to try T2 with the other signals. The data sheet show a nCE controlled write sequence - so that's next on the list.

To be honest, I didn't ever do much intelligent investigation into the Master internal eeprom fit - when it wasn't playing ball, I pretty much just retreated to the cartridge solution, not least because there isn't actually that much rom real-estate inside a Master and after all, cartridges are there to be used for just this sort of thing.

Anyway, I was originally just reading-across from the Beeb as shown in blue below but I was getting write issues ('Device is ROM' etc...) and so I later withdrew the blue master details and published the cartridge solution that you linked to.

Instigated the nCS controlled write sequence which seems to have fixed the problem.
As in the first post: Top trace down = T2, nCS, Noe and R/nW

Second trace from the top, nCS gated with T2 for a nCS controlled write.

Close up of the write sequence.

Close up of read sequence.

Testing on the Master, with MartinB's utilities, has gone well. The only thing you have to remember is to use the ABR utility UNLOCK before using any of Martin's utilities and LOCK afterwards. Having the software controlled LOCK and UNLOCK means you don't need a physical write-protect switch - bonus

Does this chip return inverse/toggling bytes for a short while after an attempted write even if locked like the Greenliant chips do? That's a problem I had with the chips I used & DFS 2.26 IIRC - tried writing to itself and then next opcode read was incorrect causing a crash.

Does this chip return inverse/toggling bytes for a short while after an attempted write even if locked like the Greenliant chips do? That's a problem I had with the chips I used & DFS 2.26 IIRC - tried writing to itself and then next opcode read was incorrect causing a crash.

Yes it does . . . hence the beauty of the ABR with it's 'lock' as it powers-up in the locked state you don't have any problems.

I've been using your EEPROM utilities a lot, over the last few days, during the testing of the ABR with a 28C256 fitted, not all the features but enough.

The following are not criticisms but observations: If I follow your instructions to the letter - the most important one being Ctrl/Brk after each command (I'm sure I've seen that somewhere?) then there are no problems. I noted that if I didn't Crtl/Brk e.g. just carried on using the same or another of the utilities, then any follow-on command usually didn't work correctly.

I don't think 'new' versions are needed as what I'm suggesting wouldn't affect the normal operation e.g. for none ABR 28C256s. I've always wondered about the on-chip locking feature - when used within the Acorn environment - OK it stops the contents from being corrupted but any write protect switch will do the same. Importantly it doesn't stop programs falling over if a write is accidentally issued while relying on reading the contents e.g. the read lock-out.

So, for any utility that 'modifies' the contents: Unlock ABR : Load image into ROM : Read ROM type and insert into ROM table : lock ABR. Of course you'll need to know which machine you're in as the ROM Table and latch are in different places for the Master And electron (more egg sucking lessons later ).

I’m currently looking at something strange when using a RAM based ABR and an EEPROM based ABE in a Master at the same time. I’m not sure I have the full details, as yet (the dinner gong shout interrupted me!). Two things I'm investigating (1) Programmed a RAM based ABR in an Electron - both positions with the same ABR108 utilities. Fitted it into a Master and a ROMS only showed one. This could be down to the OS just reporting one, however, I’m going to check with ADT to see if the other image is actually there. (2) Even more strange, with the 2 x ABR in position. Both ABRs were empty. I then unlocked them both with UNLOCK #. Then using Martin’s EEP32 UNLOCK 23 util made sure the other lock wasn’t active. Then EELOAD ABR108 0 (the EEPROM ABR was in the back slot) followed by ROMS - it’s then I noticed that the ABR108 was showing up in slot 0 and slot 2 - even after a Ctrl/Brk - Hmmm! Need to look at that tomorrow.

On the softlock, as soon as I discovered this quaint eeprom feature, it sounded really cool so I just dived straight in and added the tools but this was before I encountered the now notorious ‘write-offline’ quirk that was tending to hang Acorn kit. So, even though I later mandated a hardware write-protect switch to combat the latter, I left the LOCK and UNLOCK features in the utilities because lots of users were still telling me that it worked fine! Personally though, I do recommend the use of a hardware write-protect switch....

On the <Ctrl><Break> thingy, that’s mostly a broad generalisation about modifying any sideways rom configuration simply because many such roms have complex initialisation needs and the OS is easily confused. It could of course also be a bit of lazy programming on my part but things such as *EELOAD do inevitably tend to use main memory as a buffer and that can often then lead to ‘Bad program’ messages and the like.

Anyway, I do think that the utilities could probably benefit from another overhaul in light of your experiences, suggestions and comments and it would be good to embrace Chis’s modules in a one-for-all package. I guess as ever though, finding the bandwidth will be the governor....

On your last ‘issue’, I shall await further info because I haven’t a clue what you’re on about....

.

Last edited by MartinB on Mon Aug 13, 2018 8:49 pm, edited 1 time in total.