Re: Ortonview PCB
 

My original Bridge board does not seem to have any pullups - I thought they were on the MK14?

I also have an LS chip on the Bridge board and an HCT on the PCB like you. But, I can load multiple pictures into 200 hex with no apparent issues with a slow version of the up loader running with the VDU on.

Re: Ortonview PCB
 

And that's with your non-LP RAM? Did you get the Slothie specified ones yet?

The SOC VDU has an onboard 4K7 pullup fitted on NRDS but the fitting instructions also say to add a 4K7 pullup to NWDS - they meant on the MK14, but since I had my homebrew bridge board sitting between the issue VI and my original SOC VDU I added the NWDS pullup to the bridge rather than either of the other boards.

At the moment Slothie-OrtonView includes a 10K, rather than 4K7 pullup on NWDS (although I have now reduced that to 4K7), and a 10K on NRDS rather than the 4K7 which the SOC VDU always had on board. Did you not have pullups on your original build of OrtonView?

Re: Ortonview PCB
 

Just out of interest I swapped in a M5M5117P-15 that arrived - I get solid vertical stripes now rather than random data on power on but, it loads the pictures in fine - I will keep testing other things but, so far seem to perform well.

Re: Ortonview PCB
 

I reduced mine to 4K7 as well but, the pullup on my original build is switchable between 10k and 4k7

Re: Ortonview PCB
 

I'm going to try reducing the NRDS resistor to 4K7 (as per original VDU) and removing the pullup resistor on CE as that was not there on my original bridge board / memory upgrade. These things are unlikely to make a difference, but are quicker and cheaper to try than ordering assorted 6116s in the hope that one brand / type may behave itself.

I think Slothie may have added the pullup on CE to hold the chip deselected unless intentionally selected, as part of his battery-backed RAM idea.

Re: Ortonview PCB
 

Well as the ones I have as per Slothie seem to behave - maybe I could send you one of them - I will try another now!

Re: Ortonview PCB
 

Do you still have the diode in the supply to the 6116? Spec for hitachi 6116 shows 4.5 v minimum supply so the diode might be dropping the supply voltage. Maybe try shorting the diode if the battery is not fitted.

Re: Ortonview PCB
 

Ah should I have mentioned I had to use BAT43 diodes not 1N5711?

Re: Ortonview PCB
 

I do not have the battery fitted but, the BAT43 is in my supply still.

Re: Ortonview PCB
 

If you're asking me, no, I have direct supply to the 6116.

Re: Ortonview PCB
 

I used BAT43's as well, since I had some and 1N5711s are a bit OTT anyway.

I've been pouring through some logic analyser captures and not found anything too wierd yet, but the access times to RAM from the PIC are far slower than the SC/MP, so if the memory works with the SC/MP then its not RAM speed.

I don't think the pullup on the NRDS/NWDS is the problem either, but reducing the value shouldn't harm things as long as you don't go too far.

I've been trying to think of ways to automate my search for "wierdness" in the timing, current thinking is to make longer captures while hitting the memory hard then writing programs to search through the data looking for marginal timings, or writes when NENIN has been high for longer than about a microsecond, or other things. There is a Python module to access the "session" files from the sigrok software, but the documentation is pants so if I decide to squeeze down that particular rabbit hole it will take some experimentation.

The other option is to see if there is any way to cobble together some kind of hardware "trigger" for more complex conditions for the logic analyser using components I have or can easily get.

I also want to go back to the "vanilla" situation (using load caps) and write some software now I seem to have recovered some of my assembler skills (!) to stress-test the memory to make sure the problem really does go away, and not just become less noticable.

I think I know how to fix the battery backup, but its not a priority at the moment, and if you even remotely suspect it, remove the diodes and bridge over the VCC one.

Re: Ortonview PCB
 

I suppose its not inconceivable that the M5M5117 is subtly different from the 6116 is some regard, but it can't be much given that the RAM is essentially the same as the circuit Sirius was using on his bridge board unless he made any changes I am not aware of.

The CS was pulled high so that when the Ortonview was powered off it would remain high (connected to the battery). It appears that when not powered however the output of U1C is pulled low (probably through the substrate diodes in U1s output driver because Vcc and ground are essentially the same potential) so the RAM chip stamps all over the data bus crashing the MK14.

Re: Ortonview PCB
 

For me, even the 'Vanilla' mode is not working reliably at the moment (ref: occasional corruption of certain 6116 bytes when any given 6116 byte is being intentionally written to). Plus the fact that it just goes completely nuts when I put my should-be-acceptable Hitachi 6116s in, so I'll have to start by testing those independently.

As said, I have a few things I can try. I'll report back when I have had the opportunity to do that.

Re: Ortonview PCB
 

The address decoder on my original bridge board is an LS27 (3-input gates instead of 2-input gates, a hangover from when your original circuit also involved the RD and WR signals). When it was simplified down to just decoding the address, I just used 2 inputs of each gate to form the same circuit.

That's another thing I can try, LS02 instead of HCT02 - all of which ignores the fact that everything is pretty much working for Tim. Are you happy that yours also works fine in Vanilla mode? If so then I have to conclude for now that every 6116 I have available is duff to a greater or lesser extent.

Re: Ortonview PCB
 

It seemed to be working OK but as I mentioned above I want to stress test it in a more methodical manner.

I did see a video today by Adrian's Digital Basement where he had an IBM PC board that didn't work with a 74HCT device but did with an 74LS device in it, so perhaps there are some differences, but considering that the SC/MP bus is so slow in comparison I'm not convinced that is significant, but then I'm no expert in digital design :)

Re: Ortonview PCB
 

This could be a completely wrong memory but I saw a comparison between LS and HCT which states that among other things, the input logic level threshold is different - given that the inputs on this device are reading the very address lines we have to put capacitors on, any different in the logic level detection window could be worth considering.

...except that Tim's is working fine with an HCT.

I'm just going to have to pause until I have (a) tested my existing RAMs and (b) tried alternative RAMs.

Re: Ortonview PCB
 

No actual progress, but I have tried a few things, all in classic / vanilla mode - buffers bypassed and 220pF caps on A8-A11.

1) 6 x ElCAP EL6116LP-10, 2 x Hitachi 6116LP-3 and 2 x ST branded MK6116N-15 all tested in my device programmer's 'Chip Test' feature and all pass. This is a crude go / no go test, I can't vary the read / write speed of the test so it very likely runs at a speed which suits the slowest probable devices (450nS, possibly).

(2) Tried both of the ST devices and both of the Hitachi devices in OrtonView again. System falls over with any of these devices fitted. Note these are the slowest of the bunch, both 150nS (yes, even the Hitachi -3 suffix devices).

(3) Tried all 6 available ELCAP EL6116LP-10s - all 100nS. The system runs with these fitted but writing to any location in the range 0200-03FF occasionally writes to another byte in that range as well, sometimes somewhere ahead of, sometimes somewhere behind, the byte which is intended to be written to.

With the ELCAP devices the bytes which get corrupted are specific to each chip, and there is a worst one, where there are about 6 bytes scattered around the screen which tend to get corrupted, and a best one, which very nearly works without getting corrupted at all. In that one only one location tends to get corrupted.

I have also tried the final 'Fast' firmware (#692) and the first properly working version of the 'Fast' firmware (# 523) - neither version makes any difference to this problem. The PIC is the same physical device which worked OK in the OrtonView lash up and until tonight was still running whatever code originally worked.

Tried removing the CE pullup and reducing the NRDS pullup to 4K7, as per my previously working lashup version of OrtonView. No difference there either.

Still have not tried LS02 as address decoder - have not found one yet.

Re: Ortonview PCB
 

Even my chip museum failed me - although I did find another 5 EL6116LP-10s - so I've now ordered a couple of 74LS02s.

Re: Ortonview PCB
 

I’m hoping the pcbs show up in the mail this week so I can join in the fun. Daily visits to the mailbox across the street to check, but not at the point of watching out the window for the postman yet. I still miss the UK post service to a letterbox on the front door.

My 6116s are Hitachi LP-2 or LP-3, so I‘ll see if I have similar problems.

The 74HCT02 should be similar input levels to the 74LS02, but the main difference is input bias current, LS will float to high logic level if left floating, but HCT could float low and might damage the input transistors if left floating. 74HC02 would be a problem as the high level threshold is higher than TTL and might need pull up resistors if driven from LS TTL (or nmos loaded by ls ttl inputs).

I’m a little surprised that its not 74LS02 causing a problem as the High address lines on the MK14 are already driving a few 74LS inputs.

Re: Ortonview PCB
 

Well, sod's law, five minutes after I clicked 'buy' I noticed my Maplin Z80CPU (all chips in sockets) had an LS02 in so I 'borrowed' it and... no difference.

I might get to the point where I just send my built board to either Slothie or Tim to test drive, although... I think I am the only one with a 32+32 edge connector soldered onto mine, so that might be a non starter.