Re: Ortonview PCB
 

Switch set to:

00001100

...and TOP linked to P3...

Gives you:

Screen RAM = 0F00 / 0BFF
VDU on
Display mode = Characters
Pages swapped = No
Normal (Not inverse) video

P1-P4 switches OFF means P1-P4 inputs = high = base address 0F00, but connecting TOP to P3 overrides the P3 pullup resistor and toggles the address between 0Fxx (upper half) and 0Bxx (lower half)

Re: Ortonview PCB
 

Thanks - I had worked out the second one but, could not work out why the first config did not work. In a lucky decision I had not soldered the switches in with ON towards the PIC. When I turned it around (as I had put it in a socket :) I was unable to get the machine to stay in Text mode - anyway long story short was that one of the switches would not go on. Swapped to another one and now I can render graphics to either config flawlessly. Charset runs fine in main RAM at full pelt.

In real terms I cannot find anything that does not work yet... So the other RAM chips may not be needed and indeed I would have been surprised if this had not worked as it is the same one as was in the RAM expansion I built and used with my protoboard OrtonView.

Re: Ortonview PCB
 

Assume you are still running in MK1 (unbuffered) mode? In that mode I don't have any problems either, provided I have capacitors on A8-A11. (And provided I don't fit any of my Hitachi 6116-3 chips, which cause problems for some reason).

It's the buffered mode, which we hoped would remove the need for the capacitors, which seems to be causing problems.

Re: Ortonview PCB
 

Its been a long time since I've got something working, then broken it because I want it to work a different way :D :D

Re: Ortonview PCB
 

Indeed yes unbuffered but, using the 6116P-4 which according to your table is even slower than yours...

I will of course play with the buffers later to confirm all your findings and the strange case of the A (maybe the A11-A8 220pF caps fixed that as well?) we never tried it after firmware 357... shop duties call first so I will report in later.

Re: Ortonview PCB
 

I've been writing some test programs to "exercise" the memory. This:
will fill a 256 byte page with values 00 to FF. Sometimes it runs through to completion and drops back into the monitor, sometimes it seems to stop early, on occasions it starts filling the bottom half of the screen.... This looks like memory in the program area (0F20->) getting corrupted. So my "rock solid" configuration isn't as rock solid as it appears. Loading images into the 0200-03FF area using the uploader seems to work still, but then the monitor PROM can't get corrupted so the chances are its the same problem that you were seeing with your prototypes, i.e. random bits of the MK14s memory getting corrupted.

I've zipped and included the asm and hex in case its useful.

Re: Ortonview PCB
 

Cool - I will try that now. I have put the buffer chips in and it all seems to work the same as with them strapped out, running static images into the video at 0x200 and also running CHARSET with video in standard memory etc. Even played a few rounds of MINEFIELD!

Re: Ortonview PCB
 

How many times do I need to run this? I have done it 10 times - always succeeds and this is with the Buffers in place.

Re: Ortonview PCB
 

I would say it runs OK for a dozen or so goes then stops prematurely or starts writing elsewhere. Fails are fairly rare, and your hardware combo may be "luckier" than mine!

I've hooked up my Ortonview to my cheapo logic analyser and trying to see if I can trap any problems. I'm seeing write cycles after NENIN goes high, but they all seem to terminate within 1uS of NENIN going high, and we're building in a bigger margin as far as I can see. The only problem with the Sigrok software is that combination triggers with this hardware don't seem to be possible, so I'm having to scroll through megabytes of data!

Re: Ortonview PCB
 

Groan, this is awful. Three substantially different results with essentially similar hardware.

Tim: Buffers in, but... capacitors in, or capacitors out? What chip family are your 365s?

Are we all agreed that the classic mode - unbuffered and with capacitors on A8-A11 - is working 100%?

I have been out for most of the day so that is where my testing is going to be for now, in classic (unbuffered) mode. We need to show that there is at least one configuration in which this can be expected to work for all builders / users.

Re: Ortonview PCB
 

Not LP-4? If not, maybe that's what's making the difference.

Re: Ortonview PCB
 

Just double checked - correct just 6116P-4 - I have been playing most of the day - not had an issue yet - note that I still have the caps as well as the buffers as I had soldered them in as I did not have turned pin strips but, I may take them out and see.

Re: Ortonview PCB
 

And to confim they are LS365 brand new from Farnell - so in my case both modes seem rock stable.

I can confirm that the jumping in Graphics mode appears when you upgrade an 'A' chip to FW692 from FW352 still so that is consistent.

Re: Ortonview PCB
 

As I said I should have the chips that Slothie recommended by Tuesday so I can swap that out and see of it gets bad.

Re: Ortonview PCB
 

I was wondering if the buffers should have pullups on the inputs if 74hct365 is used instead of the 74ls365. 74ls365 is probably going to be ok without pullups as 74ls ttl inputs tend to float high. I’m not sure if 74hct floats high or low, but always see recommendation to not leave then floating.

Re: Ortonview PCB
 

The inputs on the buffers are constantly connected to the PIC address-driving pins which are in input mode, in which they probably exert a weak pullup on the buffer inputs, most of the time. The buffers will translate that to a strong high on all outputs if they are enabled while the PIC pins are still inputs.

Re: Ortonview PCB
 

Right, so obviously I am thinking that your flawless operation in buffered mode is actually due to the presence of the capacitors, curing the same problem that they cure in unbuffered mode.

Re: Ortonview PCB
 

Which of course means that they are not really needed. But, at least if you can get the same effect then we can build a stable Ortonview on this card with our capacitor fix.

Re: Ortonview PCB
 

Meaning the buffers, or the capacitors?

I think from the time Mark first suggested the capacitors and wow, they worked, we have been able to say that we have a satisfactorily working version of OrtonView, but it is a fairly unpleasant bodge - you should never have to fix a digital problem by intentionally rounding off the corners on some of the main signal lines.

The buffers are just a (so far, manifestly unsuccessful) attempt at fixing the problem the 'proper' way.

Re: Ortonview PCB
 

The Buffers I meant - I am more pragmatic - it is a Sinclair - the place that stuck variously a Diode, a Transistor an upside down chip and others to 'fix' things... then sent them out the door.

But, I understand the technical challenge to eliminate this dirty workaround.

Re: Ortonview PCB
 

As I've pointed out, Karen herself was pragmatic enough to use capacitors to solve unanticipated problems, most notably the ones she placed across the base resistors on the LED / column drive transistors in PIC14, after it turned out that they were not switching fast enough. There's every chance that she would have said 'yep, just go with that', but it is equally possible that she too would have wanted to understand the underlying cause.

I am just curious - as I know Slothie is - to understand why it is necessary to slow down the rate of the change of state of A8-A11 in order to 'fix' the problem, or rather to understand what problem it is which has to be 'fixed' in this way.

The good news is that anyone who just wants a working MK14 VDU can build OrtonView, unbuffered, capacitored and no questions asked, and it should 'just work'. Never mind why it does.

Re: Ortonview PCB
 

Well I was just looking at the buses with the logic analyser and was seeing some strange things, on investigation found I had broken the A10 track from the load cap to the buffer, I have now joined the pins with a short wire, and things look much more sensible.

I am seeing NWDS being asserted after NENIN goes high, but NENIN always goes back to '1' within 1uS, and there is no sign of the top 4 address lines being driven until 37uS after NENIN goes high.

As yet, I can't see any other suspicious activity.

However, I mapped the VDU to display Fxx on the top and Bxx on the bottom, loaded the testmem program and ran it. It is quite obvious that random points on the screen (i.e. memory locations) are getting changed from time to time and sooner or later the program gets corrupted and a block of memory gets overwritten, so there must be a rare occurance that I am not able to capture with my logic analyser due to its trigger limitations.

Re: Ortonview PCB
 

Not sure if this is conclusive yet that the buffers are not the reason the original mk14 vdu does not show the memory corruption but it does seem to be pointing in that direction.

I think the remaining possibility is that the original mk14 vdu is synchronized to the mk14 clock, maybe the bad timing of NWDS to address only occurs when NENIN is raised at a certain time in the write cycle.

If the PIC osc in is driven by an external 16MHz clock then I think the PIC osc out would be 4MHZ, but using that to clock the mk14 would mean hacking the mk14 which I’m sure we don’t want to do.

We might try registering the NENIN from the PIC to the XOUT of the mk14 using a 74ls74 or 74hct74. The 250 ns delay this might introduce shouldn’t be a problem.

Re: Ortonview PCB
 

I can't quite visualise how that would work (pure digital logic is not my strong point - maybe you can expand on it a bit?)

Another possibility is to somehow multiply the MK14 CLK-OUT signal by four and use the resulting 16MHz signal to clock the PIC instead of using a crystal.

Re: Ortonview PCB
 

If NENIN from the PIC is connected to the D input of one half of a 74ls74, then XOUT from the MK14 connected to the clock input of the 74ls74, and the Q output of the 74ls74 then provides the NENIN signal to the MK14. That way the NENIN to the 8060 always changes at the same time relative to the rising edge of the 8060 clock.

I’m not sure if the original MK14 vdu changes NENIN relative to the rising edge or the falling edge of the clock. I’ll take another look at the schematic for the MK14 vdu and see if I can figure that out.

Re: Ortonview PCB
 

In the MK14 vdu, MK14 XOUT is buffered but not inverted the provides clock input to a 74ls74 configured as divide by two, so I think NENIN should be timed relative to the rising edge of XOUT.

Then there is a delay between the rising edge of XOUT and NENIN, propagation time of IC4 74ls74, IC3 74ls93, IC6 4040, two gates of IC7 74ls04 or 74l04, one gate of IC2 74ls20, RC 4.7k and 82 or 100pF, IC5 74ls4011, and Q4 BC239.

I don’t want to try and calculate that delay, maybe Tim could measure from rising edge of XOUT clock to rising edge of NENIN on an original or replica MK14?

Probably better to use a monostable to generate a delay of that order of magnitude, I’ll take a look through some datasheets.

Re: Ortonview PCB
 

I understand a little better now, but what about a case like Slothie's where the OrtonView and MK14 are not only unsynchronised but running at very different speeds (OrtonView nominally 4MHz, derived from 16MHz, but the MK14 is running at a significantly different frequency (4.43MHz)?

If the problems are related to the phase relationship between the two clocks you would think they would be much more exaggerated when the two clocks are quite different. (I can appreciate that even two '4MHz' clocks running independently will not be exactly the same frequency and will shift in and out of phase all the time.)

Re: Ortonview PCB
 

I don’t think it would matter that the clocks are different, just that NENIN is raised at a particular time relative to the clock of the 8060. If the corrupted write cycles are caused by NENIN timing.

I took a look through some datasheets for monostables, the fairchild AN-366 is a good reference.
http://www.scarpaz.com/Documents/AN-366.pdf

One of the problems to watch out for is that most of them will trigger on release of the clear input, though the 74ls423 is meant to fix that. We might be able to synch the NENIN to a time relative to the 8060 clock using a single 74ls423.

74ls74 is more common, so maybe rather than sourcing a specific part we should stick to the 74ls74 as I described earlier, followed by an RC delay, and use the second half of the 74ls74 as a buffer following the RC.

Re: Ortonview PCB
 

Well. I've just spent quite a while with OrtonView in 'classic' mode.

-Buffers bypassed.
-4 x 150pF, then 4 x 220pF from A8-A11
-Graphics mode, pointing at 0200-03FF

Sorry to have to say that even in this mode the content of the extra-extra memory (the 6116) is not as stable as I would like.

I've slowed down the uploader so that it loads code reliably even when the VDU is enabled and I have tested that by loading alternate programs into the 'normal' MK14 RAM - loads code first time every time there. But if I repeatedly load one or other of our test images into 0200->, what I tend to see is the image building up line by line on the screen but I also often see a pixel or two well away from the area which is being loaded into, changing, maybe once per upload.

More often than not these are the same two or three bytes which keep getting boinked during uploading, and this is interesting, if I swap my other spare EL6116LP-10 RAM in, then a different two or three bytes tend, consistently, to be the unstable ones, the ones which are getting changed when code is being written to some other address in the chip.

By now you'll be thinking I must have a bucketload of slightly duff RAM. I know I'm starting to think that way.

If I put any of the Hitachi 6116LP-3 ICs in the system still goes bananas but I am willing to bet that if I put them in my Maplin Z80 CPU board they will all work. I do also have a chip test built into my device programmer, which includes a test for 6116s, so I will give them a run through.

I'm going to have to have a hunt around for a third brand / type of RAM, ideally non-LP, to see what that does.

The strange thing is that the EL6116LP-10 on my original 'bridge' board never suffered from this problem - unfortunately I can't try that original IC in this setup because it is soldered pins-flat onto the underside of the bridge board.

Re: Ortonview PCB
 

Looking at my bridge board again, it has 4K7 pullups on both NRDS and NWDS so I may as well try reducing the NRDS pullup (currently 10K on the new board) to 4K7, and also there is no pullup on the CE pin of the 6116, it is pulled up or down solely by the action of the output of the address decoder on my original PCB.

The address decoder on the original bridge board also happens to be a 74LS rather than 74HCT as presently fitted on the Slothie-OrtonView.

While I can't imagine any of these things making a huge difference, I suppose they are there to be eliminated from enquiries.

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.