"Good" versus "Bad" Electron Plus 1s

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Thu Oct 09, 2014 5:44 am

MartinB wrote:John - what are you going to use (are using perhaps?) as your benchmark 'evil Plus 1' test?
I intend to remove the gating mod from the EUP board and then load sideways ram with images using the loader built into either the PRES or Slogger Plus 1 roms (these are what is fitted to my two Plus 1s).
I ask because whilst I have been slightly sidetracking your thread with Colin, the eeprom utils I'm about to re-release include a rom image loader which can be used to load 'normal' SWR, not just eeprom.:
I hadn't considered that the loading method might be significant - although if you remember back far enough, I originally encountered this problem using a hacked-together routine of my own design which I think should have worked but in reality induced really bad corruption. So perhaps the chance of finding an evil Plus 1 is:

(chance of bad ls/als configuration) x (chance that chip timings are worst case) x (chance you're not using the best method for loading) = a small number. This could explain why the problem is quite rare.

How does your new method work?

User avatar
MartinB
Posts: 5190
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by MartinB » Thu Oct 09, 2014 6:19 am

In terms of a SWR writing method at the lowest level, all loaders can ultimately only select the relevant rom via the hardware latch and use some variation of a 6502 store instruction to populate a single byte and in terms of corruption, it's very unlikely that there would be any significance to adopting a particular low-level write op-code.

However, because of the necessary nature of a fast programming algorithm for eeprom, my EELOAD utility (which will detect normal SWR and dynamically adapt the algorithm to suit) verifies each location at the point of writing and on completion, it executes a complete image verification against the source, reporting on any detected error. Finally, and this is new to the latest imminent release, it re-reads the eeprom (or ram) for a third time whilst calculating and displaying a 32-bit checksum for the image. Hence, it will be very easy to see if a failure occurs at some point during the load sequence or if the problem is always occurring at the subsequent <Break>. Additionally, the EEPxx utils can also be used at any time to re-calculate a checksum and so could be used to qualify and quantify subsequent_to_load corruptions, if any. (You can use HxD or similar on a PC to determine the correct Checksum-32 for a given rom image.)

Anyway, I think they'll be good to go later this evening so if you think the eeprom utils might help your diagnostic process, feel free to give them a whirl... 8)
eeprom utils.png

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Thu Oct 09, 2014 12:14 pm

Thanks, I will! :D

I'm currently studying the Plus 1 schematic and trying to figure out what the problem might be. I was hoping to just compare my two Plus 1s, but as they are both pretty much the same this won't work. Swapping chips is all very well, but (a) I would need to buy the alternative parts and (b) the ICs aren't socketed so it would be a lot of work on a trial and error basis.

So I'm trying to pinpoint a likely failure mode which I can check out on the scope first.

It occurs to me that maybe my "evil" Plus 1 could also be the reason why my the user port on my EUP board doesn't work properly? Haven't thought this through though.

User avatar
aerworuld
Posts: 1712
Joined: Tue Sep 25, 2012 8:40 pm
Location: Basingstoke, Hampshire
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by aerworuld » Thu Oct 09, 2014 8:04 pm

MartinB wrote:
What I could do though (would like to do actually) is post a development UPURS rom image with the revised UPCFS embodied and if you (or indeed anyone) have some spare time, you could give it a run to see if the compatibility has improved any? I'll get on it as soon as I've released the new eeprom utilties.....
I too would happy to try some uef's through a new UPCFS if it would help Martin?

I only have one Plus 1 now so I cant be of much help on the comparison front John, but just shout if there's any Elky stuff I can help with ;-)

Stuart :-)

User avatar
MartinB
Posts: 5190
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by MartinB » Thu Oct 09, 2014 10:49 pm

Ok John, I've posted the new utilities on the eeprom thread... :wink:

Stuart - yes, it would be very useful if you could try a bunch of games to get a feel for whether the compatibility has improved. I'll post a development version over the next couple of days, certainly before Col's retro-night on Tuesday :D

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Fri Oct 10, 2014 6:00 am

I have been studying Prime's redrawn plus one schematic carefully, and there are a couple of things that look wrong to me.

1. There is a signal ROMQA which appears at the cartridge slots and which is used as an input in the decoding part of the circuit, but it doesn't appear to come from anywhere. I thought this was the lsb of the rom select latch, but that pin is unconnected.

2. The circuit generates a signal nROMOE, which doesn't seem to be used anywhere.

These look like errors on the schematic to me, rather than actual design faults.

In terms of possible timing related design issues, I haven't spotted anything too suspicious yet, except that the design assumes that the Electron is outputting Phi2 whereas actually it outputs Phi0.

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Sat Oct 11, 2014 6:49 am

Just done a bit of testing:

- Removed EUP gating mod
- Elk with Plus 1, PRES rom, Plus 3, Prime's ROMRAM board set to E00 DFS.
- EUP in front slot

*EELOAD worked fine initially. Loaded all the test roms no problem, and EXMON.

But... when I try *EXMON the machine hangs. Tried this several times and once I managed to get "EXMON II" to display before it hanged, so it is failing at different points.

Then I decided to use *SAVEROM to save this corrupted image (as "EXMONC") and then use *EELOAD to reload it to see what its checksum was compared to the original file.

First I decided to do *EELOAD EXMON2 3 to find out what the original checksum was. This loaded OK, but this time it gave a verify error at &81E7. I found this was repeatable - the error now occurred at this location every time in slot 3. Loading EXROM2 into slot 2 was OK though.

Then loading EXMONC into slot 2 (which worked) I see that the checksums are different - the rom is indeed corrupt.

So then I tried to see if EXMON would run OK from slot 2. It doesn't.

Pressing break and trying slot 3 again, it seemed to load OK (no verify fault this time).

So - evil Plus 1 is definitely back! What I am unclear about is whether this is a read fault or a write fault. I would guess write, because the failures seem to be consistent after every rom write, not completely random.

User avatar
MartinB
Posts: 5190
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by MartinB » Sat Oct 11, 2014 7:40 am

John - I'll have a closer read later (a lot there :shock: :wink:) but just a point on ease of procedure...
You wrote:Then I decided to use *SAVEROM to save this corrupted image (as "EXMONC") and then use *EELOAD to reload it to see what its checksum was compared to the original file.
Don't forget you can now use *EEP16 SUM <id> at any time (not just with eeprom) to re-calculate the checksum of a rom or ram device at a given <id>. This stops you having to save and re-load an image with EELOAD in order to get a checksum and thus allows rapid corruption checking without unduly disturbing anything 8)

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Sat Oct 11, 2014 5:44 pm

I have more... but you're not gonna like it! :lol:

As a control, I tried loading EXMON into an ABR board, using EELOAD as before. This worked fine and EXMON ran properly. Admittedly, I didn't do any intensive testing, but it did at least work whereas it never worked from the EUP swr.

Then I went back to the EUP board and tried loading EXMON into that. About 75% of the time the loading and verifying process works OK, but 25% of the time it crashes - always at location 81E7. This location contains &85, but this isn't the first occurence of that number in the ROM so it isn't clear why it falls over (sometimes) at this point.

I investigated to see whether the bytes following 81E7 get corrupted as well. They do. Here are some example values (I didn't repeat this process to see if it always corrupts the same way, presumably it doesn't..?)

81E7 85 -> 4F
81E8 4A -> 47
81E9 A9 -> AB

No obvious pattern, but once the corruption begins it seems to continue for a bit at least.

I tried to use *EEP16 SUM a few times. Whilst I see an incorrect checksum (ie, not the same as the one reported on loading), it does at least remain constant.

On one occasion I successfully loaded EXMON, then did *EEP16 SUM on it and still got the right checksum. So then I typed *EXMON and it managed to get as far as the memory editor screen - but then it crashed. After pressing break, *EEP16 SUM reported an incorrect checksum, showing that corruption has occurred.

Final test for today - tried writing the image and then setting the "read only" jumper. This works fine, proving that spurious writes are the issue.

Looking at the schematic, I can see why you are so puzzled - there is almost nothing to go wrong is there? My thought is the RnW is supplied unadulterated by the Plus 1 so that must be OK. The ROMOE signal, however, is generated by the Plus 1 so what if that were going low at the wrong time and enabling the ram at the wrong times?

Looking at the Plus 1 circuit diagram, there seems to be an awful lot of gating with Phi0 going on, and there is also a delay circuit at one point. My interpretation is that timing only becomes an issue when changing the content of the ROMSEL latch. I wouldn't expect this to occur when using *EELOAD but perhaps it does, eg if there is an interrupt perhaps...?

Another thought - what does the ABR do that EUP doesn't do?

User avatar
MartinB
Posts: 5190
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by MartinB » Sat Oct 11, 2014 9:56 pm

John wrote:I have more... but you're not gonna like it!
Hey, no worries - whatever I do I can't repeat it with any of my collection so all investigations and discoveries are welcome 8)

I'm still slightly unclear John - you seem to be saying that you get the $81E7+ corruptions during loading but towards the end of your last post you said...
...tried writing the image and then setting the "read only" jumper. This works fine, proving that spurious writes are the issue.
...which implies you don't get the corruptions until you actually run Exmon (without WP true)? So can you just clarify - the corruptions occur during loading, on running Exmon or both?

(Looking at the Exmon code around $81E7, there's nothing going on which would explicitly cause self-corruption.)
Looking at the schematic, I can see why you are so puzzled - there is almost nothing to go wrong is there?
Well exactly, EUP only uses existing signals apart from the LS04 between Elk RnW and device nOE which is logical (sic) for all writeable devices and essential for eeproms :-k
EUP rom & ram.jpg
So essentially yes, I'm still puzzled and since I can't reproduce it, I'm a bit stuck :roll:

(Interrupts shouldn't be an issue btw but hey, who knows.... :wink: )
Another thought - what does the ABR do that EUP doesn't do?
I think it maybe uses a PAL chip so I'd have to look at the equations (which Dave posted on here if memory serves) unless Dave H can enlighten us directly?

User avatar
daveejhitchins
Posts: 4836
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by daveejhitchins » Sat Oct 11, 2014 10:47 pm

It's late, but here's the schematic and PLD equations . . . I drive nOE in the same manner - maybe a little more delay through the pld!! I'll catch-upon Monday (in Oslo again).

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Sat Oct 11, 2014 10:50 pm

I thought I might not have been entirely clear on the loading corruption issue, so I'll explain:

- Most of the time, loading works ok but Exmon seems to corrupt itself while running, so it doesn't get very far before crashing.
- If, having successfully loaded, I write protect before running, the image does not get corrupted and runs ok.
- Sometimes, loading itself fails. When this happens, it always fails at 81e7 (for Exmon, maybe its different for other roms?)

Does that help?

I will try loading a different rom to see what happens and where it corrupts. I will also study the ABR equations.

User avatar
daveejhitchins
Posts: 4836
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by daveejhitchins » Sun Oct 12, 2014 7:23 am

When you load Exmon into ABR are you using the ABR utility that 'locks' the RAM e.g. write protects it - Or, just a standard RAM load utility <- followed by a BRK?

Either way ABR WILL be write protected (it gets locked after a BRK!) E.g. Is this just a case of a ROM image that's protecting itself against running in RAM - Just a thought!

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
MartinB
Posts: 5190
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by MartinB » Sun Oct 12, 2014 8:24 am

I wondered about that Dave because I thought we've talked previously about ABR having 'automatic' write-protect of sorts. How does the ABR get write-enabled though?
John wrote:As a control, I tried loading EXMON into an ABR board, using EELOAD as before.
EELOAD simply pre-tests for ram, eeprom or rom and then proceeds if it can write, it doesn't know how to un-protect an ABR? How is loading an image via EELOAD therefore possible?

EDIT : That's probably just me being thick - I guess John will have used an ABR unlock utility or a suitable poke before using EELOAD...?

The ram self-protection aspect is easy to check athough I don't /think/ Exmon auto-corrupts, at least not intentionally but I can have a play with this tonight. Whatever though, if it was all summarised just by this....
John wrote:...Exmon seems to corrupt itself while running, so it doesn't get very far before crashing.
- If, having successfully loaded, I write protect before running, the image does not get corrupted and runs ok.
...then tbh, I would say simply that there's nothing to worry about.

However, the bizarre aspect is this...
John wrote:- Sometimes, loading itself fails. When this happens, it always fails at 81e7 (for Exmon, maybe its different for other roms?)
A loading failure that is repeatable at the same address...!? :shock: :-? :-s

Unless that were either a faulty disc-drive or ram chip, it would be a really challenging hardware problem, especially given the simplicity of this aspect of EUP. It'd almost have to be a super-subtle EMC-type problem where a particular combination of address lines being hi and lo cause interaction with each other or with other control and data lines. Very strange... :(

I need time to think.... :-k :wink:

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Sun Oct 12, 2014 10:39 am

Actually, I didn't use anything to unlock ABR. I just used *EELOAD, and it worked. I thought you only had to unlock it if you had explicitly locked it beforehand.

Looking at the ABR equations, I see that Dave uses OE directly, without altering it at all, but RnW is gated with Phi0 (actually on the schematic you have labelled this as "T2", ie Phi2, but really it is Phi0 - the Advanced User Guide is incorrect as AlanD and others have pointed out). In fact, on the schematic your equations say that RnW is gated TWICE with T2 but I assume this is either a typo, or if really true then it has no additional effect.

Anyway, it seems to me that whilst gating with Phi0 should not really be necessary, in reality it IS needed because the timing of the Plus 1's OE signal may be sometimes be a little bit wrong. I think it must be too early (due to the fact that it uses Phi0 rather than Phi2). This could suggest a reason why the use of ALS chips is a factor - because they are faster, they make the signal occur even earlier.

All the above is conjecture but it gives me a direction which I can investigate further.

User avatar
MartinB
Posts: 5190
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by MartinB » Sun Oct 12, 2014 2:17 pm

Fair conjecture John and indeed, all of that is why I (a) have a CR network on Phi0 to equate to a Phi2 for the 6522 element of EUP and why (b), I subsequently went on to gate said pseudo-Phi2 with RnW for the anti-corruption gating mod which seemed to sort out most people's issues.
Phi0 to Phi2.jpg

User avatar
daveejhitchins
Posts: 4836
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by daveejhitchins » Sun Oct 12, 2014 3:45 pm

Another thought (30min before I leave for the airport): Do you have a Plus 3 attached with Phill's ROM/RAM? If you don't have the latest code with this then ABR is continually unlocked . . . Which would explain why you can load OK but not the corruption!!

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Sun Oct 12, 2014 4:57 pm

Yes Dave, I do. That explains why I can write to the ABR! I actually thought of that myself earlier on, but thanks for confirming it!

I've been studying the Plus 1 schematic again, and I've found where nROMOE is used - its to select the internal expansion rom, so that's not an error. However I do think that ROMQA should be shown as coming from Q0 of the 74LS175.

When I updated the Elk Advanced User Guide I pinched some words from (I think) the Watford Electronics Master Reference Manual to better explain the Plus 1 cartridge slots. In relation to the OE signal my source said:
nOE - Output Enable
This is an active low signal during the Phi2 period of the system
clock. It is intended to switch on the output buffers of memory
devices in cartridges. It is not guaranteed to be high at other times.
The New Advanced User Guide says almost the same.

I think this is not true for the Electron (could be true for the Master though). Firstly, it's Phi0 not Phi2 on the Electron. But also, I think the output from the 74LS175 (ROMSEL) only changes when a different ROM is selected (on the rising edge of Phi0), and gives a constant output at other times. It isn't gated with Phi0 or anything else.

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by paulb » Sun Oct 12, 2014 5:37 pm

jms2 wrote:I think this is not true for the Electron (could be true for the Master though). Firstly, it's Phi0 not Phi2 on the Electron. But also, I think the output from the 74LS175 (ROMSEL) only changes when a different ROM is selected (on the rising edge of Phi0), and gives a constant output at other times. It isn't gated with Phi0 or anything else.
I was wondering about this recently: I didn't understand where Phi2 came from at all, and looking at another version of the EAUG, it is clearly marked as Phi0. There were also some other things that weren't very clear.

I don't remember where I got the other EAUG version from, but it has separate PDFs for each chapter and a reworked (and very clear) circuit diagram. Maybe someone will own up to doing that because it's very nice!

Edit: The other EAUG is found in this zip archive, found here.
Last edited by paulb on Sun Oct 12, 2014 7:38 pm, edited 1 time in total.

User avatar
1024MAK
Posts: 8554
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by 1024MAK » Sun Oct 12, 2014 5:45 pm

Links would be nice :wink:

It is possible that part of the reason for the problems is down to the SRAM chips being a lot faster, so any "glitch" at the wrong time may result in an inadvertent write to whatever address is on the address bus.

Mark

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Sun Oct 12, 2014 9:17 pm

1024MAK wrote:It is possible that part of the reason for the problems is down to the SRAM chips being a lot faster, so any "glitch" at the wrong time may result in an inadvertent write to whatever address is on the address bus.
I agree. However, the only potential source of glitches that I can see is when a new value is written into ROMSEL. This will happen quite a lot of course, but would it happen while writing a rom image using *EELOAD? I guess only MartinB can answer that.

User avatar
MartinB
Posts: 5190
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by MartinB » Sun Oct 12, 2014 9:27 pm

No - because EELOAD is all assembler and I don't need BASIC, I select the target ram/eeprom device immediately after the nominated image is read from disc into main ram and leave it selected until after device writing when the checksum is calculated and the program ends. Only then do I reselect whatever rom was active when EELOAD was called.

I've done some testing using an Elk, a Rombox+, an EUP with a 62256 32k SRAM and Exmon2 as a rom image. I had EUP in the front slot (rom id's 2 & 3) and a Peg disc interface in the rear which has the Peg DFS and Starmon fitted in it's 0 & 1 rom slots. The EUP does not have the additional gating mod fitted.

I loaded the Exmon image literally dozens and dozens of times into id's 2 & 3 but couldn't get a single failure. Additionally, after each load, I pressed <Ctrl><Break> followed by *E and a selection of Exmon commands but again, never any problems. I did not write-protect the 62256 at any time during any of the testing.

One curious behaviour of Exmon II in ram is that once running, it won't let you use itself to modify itself. Thus, if you load it into say slot 2 and execute a !2 followed by an E 8000, you cannot actually overwrite any locations and I think it does this consciously. Stranger though, if you then select !3, i.e. the second bank of 16k within the 62256 and try the same exercise, as soon as you try to overwrite a byte with Exmon, it hangs! But the really weird part is that if you then press <Break> and inspect slots 2 and 3, you will find that you have actually made the attempted change to the Exmon image in slot 2 and not to slot 3 where you were typing!?! Weird!

This must be some sort of quirk of operation with the Elk mode of Exmon II because if you do the same exercise with Starmon, everything behaves as expected. I have a suspicion that Exmon falls foul of the Elk's fussiness regarding paging the low-numbered roms in and out.... :-k

Anyway, other than that curiosity, I still can't reproduce any of the subject reported problems... :roll:

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Mon Oct 13, 2014 12:54 pm

Thanks for the update Martin, and for clarifying how *EELOAD works. I thought it probably worked that way, but I have remembered something that could be relevant - the Elk reads the keyboard via a rom slot (9 I think) and so presumably it pages rom 9 in and out regularly via an interrupt-driven routine that scans the keyboard. So the potential exists for the Plus 1 to cause glitches perhaps?

I appreciate that your Plus 1 (and for that matter, most of them) isn't affected by this problem and so I'm not surprised you can't reproduce it at all. What I need to do is identify something that is positively "wrong" happening and them I can work out how to modify "evil" Plus 1s to make them behave properly.

Today's testing has not gone well though! :(

First I tried various software experiments. Loading UPURS worked fine - I could not get it to corrupt on loading. It definitely corrupts afterwards though, because although *HELP displays "UPURS 1.0E", typing *HELP UPURS does not list the commands - this is the problem I noted originally.

Oddly, though, I did manage to get a situation where *EELOAD failed to work. After loading an image successfully, trying to load it again resulted in the error message "Bad syntax". Pressing Break resolved this issue, but I got from both EELOAD and EEP16 at times.

I then tried to see if loading would go amiss with EXMON2 again. It did, and it failed at &81E7 repeatedly. One time, though, it failed at &81E8!! I tried poking values into the file (at &81E6 and &81E7) before loading it to see if it would change this behaviour, but it didn't.

Then I tried hooking up the scope to see what was happening to the /CS line on the SRAM chip. I found that pressing break caused two low pulses of 500ns duration, synchronised (I think) with Phi0. I tried to select the rom permanently to see if the signal remained permanently low (as I expect it to) or whether it is gated (as the AUG suggests) - but I fell foul of two things. One was the fact that I forgot about the Elk's "double rom select" method, so my little bit of machine code didn't work.

Much more seriously though, in an attempt to find a suitable 0V location for the scope, I managed to kill the machine stone dead! :shock: I've never managed to do that before in all my experiments with the E2P board, so I was amazed that it happened. I'm hoping that it is just a fuse in the Plus 3 rectifier circuit that I have blown. Very annoyed with myself. :(

Even worse, I then fished out the other Electron and set up the scope leads much more carefully. But then this machine died as well! :( Almost certainly the same cause I would guess. This one doesn't have a Plus 3 though, so power was coming from the Elk itself.

I'm not going to try fixing them today because I am obviously cursed!

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Mon Oct 13, 2014 1:39 pm

Panic over - just tried both machines again and they are fine. :? Maybe shorting something out caused them some kind of temporary problem which resets after a few minutes..? Anyway, all is fine now and I've done a bit more testing with the scope.

If there is nothing in the RAM bank, /CS never goes low. Seems right! :D
If you load something, /CS goes low every 10ms typically. I think this is the OS polling the ROM.
If you issue a SEI command, the polling stops. =D>

I guess the above is all as expected.

When I try *EELOAD, there is a lot more activity on /CS but it is not low all the time (well, for the duration of the writing process anyway), which surprised me.

I tried writing a little machine code routine to disable interrupts, select rom 3, and then go into an infinite loop. I expected this to drive /CS low permanently. However, it doesn't - and I don't know why.

All the above doesn't answer my question of whether there are glitches which are inadvertently enabling the SRAM. Looks like they are going to be difficult to spot.

User avatar
1024MAK
Posts: 8554
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by 1024MAK » Mon Oct 13, 2014 2:23 pm

jms2 wrote:Panic over - just tried both machines again and they are fine. :? Maybe shorting something out caused them some kind of temporary problem which resets after a few minutes..?
I think there is some form of short circuit protection circuit included as part of the Elk's internal SMPSU. I have a defective FirstByte joystick interface. When plugged into an Elk, it kills it :cry:. Even after removing the faulty interface, the Elk will not power on :twisted: (which resulted in a Oh #¥€%! #-o).

Leave it 5 minutes unpowered, and then power up again, and it comes back to life as if nothing happened :D.
So I opened up the interface and tested various parts of the circuit. I found that there is a short between the +5v and 0V lines :(.
The time delay is almost certainly due to having to wait for a large electrolytic capacitor to discharge.

Mark

User avatar
MartinB
Posts: 5190
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by MartinB » Mon Oct 13, 2014 2:56 pm

John wrote:When I try *EELOAD, there is a lot more activity on /CS but it is not low all the time (well, for the duration of the writing process anyway), which surprised me.

I tried writing a little machine code routine to disable interrupts, select rom 3, and then go into an infinite loop. I expected this to drive /CS low permanently. However, it doesn't - and I don't know why.
Don't forget that whilst a given piece of code may be writing or reading to rom 3 which is mapped to $8000+, unless the code itself is located within the selected chip (i.e. within the rom 3 device address range), the program counter and hence op code and data fetches will be switching between different physical devices.

For example, EELOAD lives at $1100+ which means that the user ram and target rom device select lines will effectively alternate during a load as the code at $1100+ fetches the source image bytes from $2000+ and writes them to the target device at $8000+.

If you put your little piece of code within rom 3 ram and inhibit interrupts, you may see a steady select but even then, only if nCS is not gated with anything else such as Phi0 or 2. There are of course choices of how to control R/W chips using both nCS and nOE but on the Beeb for example, one is always clocked with 2MHzE (or in some cases 1MHzE) and nOE is used as the 'talk now' so you don't ever get pure levels.

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Mon Oct 13, 2014 4:35 pm

1024MAK wrote:Leave it 5 minutes unpowered, and then power up again, and it comes back to life as if nothing happened :D.
That's it exactly. :- :oops:
MartinB wrote:Don't forget that whilst a given piece of code may be writing or reading to rom 3 which is mapped to $8000+, unless the code itself is located within the selected chip (i.e. within the rom 3 device address range), the program counter and hence op code and data fetches will be switching between different physical devices.
Ah yes, I knew that, honest! :^o
Actually where I went wrong is that I had looked at the Plus 1 schematic and noted that its /OE output to the cartridge slots is not (apparently) gated with Phi0 and therefore I made the mental shortcut of thinking it was wholly dependent on the contents of ROMSEL and not on anything else. But in reality, it does depend on A14 and A15, so the situation is exactly as you've described.

I think what I will try to do next is monitor /WE and /CS on the sram chip, and detect when both of them go low (ie a write). If I'm not actually writing to the chip at the time, then this must be a glitch.

User avatar
1024MAK
Posts: 8554
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by 1024MAK » Mon Oct 20, 2014 4:39 pm

Electron Plus 1 Details
===================

Acorn Electron Plus 1 (Assembled in UK) Serial No.: 12-ALA11-100???? (part of sticker missing)
This is a "good-ish" unit. With gate mod it works fine with the EUP and a SRAM chip :-). See this thread for details...
IC1 = SN74LS30N by TI, date code 419C
IC2 = SN74ALS00AN by TI, date code 414B
IC3 = 74LS139N, date code 8214
IC4 = 74LS260N, date code 8337
IC5 = SN74ALS10N by TI, date code 410B
IC6 = SN74LS175N by TI, date code 8414B
IC7 = SN74ALS04AN by TI, date code 401A
IC8 = SN74LS27N by TI, date code 8319B
IC9 = SN74ALS20AN by TI, date code 414B
IC10 = SN74ALS00AN by TI, date code 414B
IC11 = Socketed, ADC0844CCN, date code 8416
IC12 = SN74LS195AN by TI, date code 8414C
IC13 = SN74LS32N by TI, date code 8406B
IC14 = Mask ROM by NEC, round yellow sticker says "E+1 O.S 1.0"
IC15 = 74LS125AN, date code 8412
IC16 = SN74LS273N by TI, date code 8410A

Q1: BC239
C3: 47uF, 10V axial electrolytic
C4: 10uF, 6.3V tant. bead
C5: 1uF, 35V tant. bead
C6: "n47" ceramic plate, I presume this is 470pF
R9: 220R

LINKS
LK1: made
LK2: made
LK3: open
LK4: open

PCB is 0219,100-S2 ISS 2

<END>

I have included chip manufacturer (where I recognise the logo / marking) and the date code (to give a clue about the date of manufacture).

I will post details of my other Plus 1's in due course :mrgreen:

Mark

User avatar
jms2
Posts: 2197
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by jms2 » Mon Oct 20, 2014 5:48 pm

Thanks Mark, there's everything that anyone could possibly want in there! :D

I have added your details to the table. Based purely on LS/ALS configuration, I would expect this Plus 1 to be "evil" - its the same as mine and the same as mga1103's.
Updated matrix 2.JPG
I'm intrigued to see what's inside your "super evil" version - I did have a quite nice simple theory as to what is going on, but the existence of a Plus 1 that doesn't even work with a gating mod kind of blows it out of the water. If I knew what chips were inside it, that might help - or just as likely raise a whole lot more questions!

User avatar
1024MAK
Posts: 8554
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: "Good" versus "Bad" Electron Plus 1s

Post by 1024MAK » Mon Oct 20, 2014 7:25 pm

jms2 wrote:I have added your details to the table. Based purely on LS/ALS configuration, I would expect this Plus 1 to be "evil" - its the same as mine and the same as mga1103's.
It's all relative, I call it good-ish because at least I can get this one to work... (even if it did need a mod to the EUP board).
jms2 wrote:I'm intrigued to see what's inside your "super evil" version - I did have a quite nice simple theory as to what is going on, but the existence of a Plus 1 that doesn't even work with a gating mod kind of blows it out of the water. If I knew what chips were inside it, that might help - or just as likely raise a whole lot more questions!
Well, as soon as I find it again! After it's bad behaviour it got banished into storage... :shock: It hopefully will be lurking behind a Beeb or in a box. Just need to go treasure hunting (well, daemon hunting maybe... :lol: ).

Next up will be the one that has not been properly tested yet.

I'm still thinking that somehow Mr Barr worked some RAMmagic to get hold of just a bunch of very good Plus 1's :? 8)

Mark

Post Reply