Ortonview PCB

[Mark1960]

Originally Posted by Timbucus

As an aside to the issues part of the Slothie PCB included a hardware Random number generator which we have not tried yet. It may interest you to know there is canon for that (with code snippets) for the MK14 in November 1981 Computing Today Microlink... Pg. 25...

http://www.flaxcottage.com/ComputingToday/8111.pdf

I did try to add just the two pages of the article as PDF but, it was too big...

I thought Slothie based his circuit on the twonky, ETI February 1979, page 79.
https://worldradiohistory.com/UK/Ele...1979-02-79.pdf

They leave a lot of details missing from the schematic, but it should be possible to fill in the missing info. They also list the code.

[Slothie]

Originally Posted by Mark1960

I thought Slothie based his circuit on the twonky, ETI February 1979, page 79.
https://worldradiohistory.com/UK/Ele...1979-02-79.pdf

They leave a lot of details missing from the schematic, but it should be possible to fill in the missing info. They also list the code.

Yes, I got the idea from there and the details from an article in Elektor I think, which used a similar circuit for a synth.

[SiriusHardware]

I've just done a 'lite' version of this test below,

(3) Disable or remove the VDU components so that the board is just a 1.5K 'RAM pack' and use Slothie's test program or some other means to verify the operation of all of the 6116 RAM ICs.

I removed the PIC and fitted every type of RAM I have available in the 6116 position and they all pass a 'slow test', which is to say,

-They don't mess up the operation of the system.

-The normal / extra and I/O memory of the MK14 can be edited and inspected.

-The extra-extra RAM provided by the 6116 can be edited and inspected even when one of the Hitachi HM6116LP-3 or MK6116N-15 types are fitted.

Apart from the fact that the PIC is removed, all other system configuration is as described in post #390.

[Slothie]

It is rather looking like the PIC being on the buses is the problem.... so maybe we need to look at getting the buffers to work. I'm still trying and failing to catch a "rogue" write.

[SiriusHardware]

I think for a better RAM test I need to do some testing of all RAM areas at full machine speed, with one of the 'worst' 6116s fitted.

Somewhere back in the thread I think you thought your 6116 RAM was working 100% but then discovered it was not entirely stable? Not sure which exact circumstances that was happening under.

I've just fitted SMD 10uFs to the PIC power pin pairs as per Mark's mod but have left the associated 0.1uF in the position provided as well. Will do a bit more testing tonight.

Is there any thought as to how fast the 6116s need to be specifically with respect to Ortonview? OrVw rips through the RAM at quite a rate in order to keep the video bit stream topped up.

[Slothie]

Originally Posted by SiriusHardware

Is there any thought as to how fast the 6116s need to be specifically with respect to Ortonview? OrVw rips through the RAM at quite a rate in order to keep the video bit stream topped up.

The ortonview accessed the memory slower (i.e. NRDS is low for longer) than the SC/MP but more frequently....

[SiriusHardware]

Those NRDS pulse on the RHS, obviously generated by OrtonView since NENIN is high during that period, are quite close together although it's hard to tell how close together (timewise) on that scale.

I'm assuming there is also a required minimum interval between the application of the address to the address bus and the onset of NRDS - ie, the address bus needs to have time to settle and then wiggle its way through the internal address logic to select the correct internal element of the RAM, before NRDS is taken low. Could we be taking NRDS low too soon for some (not all) of the RAMS being tested? What is the interval between OrVw writing the address (which it does in two steps, so it's the second write which is the relevant one) and OrVw taking NRDS low?

Bear in mind that application of the address to the address bus is done by changing the port from input mode to output mode in two stages - How long does that overall port direction change actually take to happen? And then afterwards, how long does it take to change back from output to input mode?

[Slothie]

Originally Posted by SiriusHardware

Those NRDS pulse on the RHS, obviously generated by OrtonView since NENIN is high during that period, are quite close together although it's hard to tell how close together (timewise) on that scale.

I'm assuming there is also a required minimum interval between the application of the address to the address bus and the onset of NRDS - ie, the address bus needs to have time to settle and then wiggle its way through the internal address logic to select the correct internal element of the RAM, before NRDS is taken low. Could we be taking NRDS low too soon for some (not all) of the RAMS being tested? What is the interval between OrVw writing the address (which it does in two steps, so it's the second write which is the relevant one) and OrVw taking NRDS low?

Bear in mind that application of the address to the address bus is done by changing the port from input mode to output mode in two stages - How long does that overall port direction change actually take to happen? And then afterwards, how long does it take to change back from output to input mode?

The MK14 NRDS pulses are 3.5-4.5 uS apart, with a duration of ~500ns or less.
The Ortonview NRDS pulses (at fastest) are 2.5uS apart with a duration of 1.5uS (hence the NRDS is high for 1uS between read cycles).

As for the address bus writes, the upper 4 bits are only set at the beginning of each half of the screen. the lower 8 bits are incremented in this macro:

; Read data from memory macro
RDMEM	MACRO
	BCF	PORTA,NRDS	; RDMEM = 7~
	DELAY	3
	MOVF	DBUS,W
	BSF	PORTA,NRDS
	INCF	ADRSSL
	ENDM

The address bus is incremented at the end of the
The code for each line looks like this:

	RDMEM
	ANDLW	B'00111111'
	IORWF	TINV,W
	MOVWF	BUFA+0
	RDMEM
	ANDLW	B'00111111'
	IORWF	TINV,W
	MOVWF	BUFA+1
	RDMEM
	ANDLW	B'00111111'
	IORWF	TINV,W
	MOVWF	BUFA+2

The RDMEM macro takes 7 cycles, then there are a further 3 instructions, so the address bus lower 8 bits get incremented every 10 cycles = 2.5uS as observed. The NRDS bit gets set low by the BCF instruction at 4 instructions after the increment which is ~1uS after the address bus is changed. There are at least 3 cycles (750nS) between NRDS being set low and the data being read from the address bus.

[SiriusHardware]

Oh... Dear.

I think I've just found out why my PCB-based OrVw is the worst performing of all those built so far, at least with respect to the operation of the 6116 memory expansion. While fitting a diode in place of the direct link between +5V and the 6116 supply pin, I realised I had the link fitted in the D1 position, not the D2 position - in other words, I had the link in the position of the diode which is meant to carry the alternative supply from the backup battery (not fitted).

This means, of course, that I have been trying to run the 6116s without any serious kind of +5V supply, except what they may have been getting through the clamp diodes on their various other pins, or through resistors R1 / R2 / R3, one of whose associated lines are high most of the time.

This being the case, it is pretty miraculous that any of the RAMs have been working at all, and no surprise that some tolerated the situation better than others. A simple check on the 6116 supply pins with a meter and scope would have given the game away two weeks ago. Not my finest hour.

I've now linked out the D2 position instead, so we'll see what happens when I give it another go tonight.

[Mark1960]

I actually read a suggestion to check for that kind of issue in a recent thread on 6502.org but thought that was too unlikely to pass it on. The thinking was that the parasitic diodes in the inputs and outputs charge the decoupling cap but then that is discharged when the inputs are low.
http://forum.6502.org/viewtopic.php?...tart=45#p85984

[Slothie]

Well its not like any of the rest of us have done something like that! (Speaking as the guy who fiddled with bad video for a fortnight before finding he had a transistor in backwards!).

I'm glad you've found the problem, I should have documented it better, rather than just posted a PCB to folks and leaving them to work it our!

[SiriusHardware]

I think this is why it took me so long to consider / notice the real problem, because at least some of the RAMs were working quite well and in fact all of them were working nicely in plain 'Memory expansion' mode - all without anything close to an acceptable +5V supply. It's hard to believe that any of them could have managed to work so well.

All I can say is, I'm glad Tim opted to leave the diode (D2) in because that was what finally drew my attention back to that area. If his had been linked out from the start, that wouldn't have been an issue which needed to be considered and I wouldn't gone there.

Just off to give it a shot now.

[SiriusHardware]

I should have documented it better

Don't kid yourself, the documentation, which included the circuit diagram, was fine and contained enough info for any half-wit (...almost any half-wit) to pick the right diode to bypass to put a direct supply on the 6116.

Back in a bit....

[SiriusHardware]

Straight in with the three worst RAMs, the Hitachi HM6116LP-3s, and all give a rock steady picture when OrtonView is rendering from 0200-03FF. I've left the third one in and I will run it for an hour or so to make sure no pixels get knocked about during that time.

I haven't (yet) regressed the decoupling capacitors to the original fitted values, I think that following Mark's observations I will keep the 10uF SMDs on the PIC pins but will otherwise take most of them back down to 0.1uF, and I will keep the additional two 0.1uF across the video output supply rails and the 6116 pins. Of course the 220pFs on A8-A11 are still there as well.

I'll be happy with this for a while, but then I may go back to trying to get the buffers working again now that I have a sensible supply arrangement for the 6116. Still determined to get rid of those capacitors eventually, if at all possible.

[Mark1960]

The documentation was almost not needed. The silkscreen of the component values made it much quicker to assemble, just needed to make sure I fitted 4k7 for NWDS. One thing that would be nicer would be to move the reference designators on the silk screen so we can still read then after the components are fitted. I don’t know how easy that is with kicad.

I’ve searched again for my spare scope probes and still not found them, so ordered a cheap set from Amazon to use on external trigger so I can look at both NWDS and an address line at the rising edge of NENIN. I’ll probably find them tomorrow when its too late to cancel the order. The search wasn’t a complete waste of time, I found my original MK14 manual and SC/MP technical manual, both a little worse around the edges for having been in a damp garage for a few years but still readable.

[SiriusHardware]

You would be surprised how much an original MK14 manual can be worth. The last one that caught my attention ended up going for more than 40 GBP. Just the manual.

Not that I imagine you would want to sell yours.

I have two, my original one which is covered in horrible teenage biro scrawl and another very clean one which I bought for less than a tenner, although that would have been about 10 years ago now. Both are V1, they describe the operation of the system with the original OS, not the revised OS.

[SiriusHardware]

So where is everybody else now? Tim has a more or less working vanilla Ortonview, as do I, finally.

Mine has now run for about an hour with no corruption to the image being rendered from 0200-03FF. Next up is to point OrtonView at 0Fxx / 0Bxx and run CHARSET to see if there is any remnant of the original corruption problem. If not, I may try gradually decreasing the A8-A11 capacitors to find a lower limit for the value of those capacitors on this PCB.

Slothie and Mark are obviously both trying to drill down to the actual cause of the corruption problem which the capacitors 'fix', although Mark is more likely to fix it with a hardware fix and Slothie is more focused on finding a firmware fix - is that a fair summary?

[audiokit]

Glad any of us makes an (afterwards obvious) mistake every now and then. Just think about it as making a journey, all the fun is the journey itself. Of course your goal is to get it working but you will find out that most of the fun has gone. I just try to follow the discussion, a bit difficult when you don't have your hands on the same PCB but still interesting. I am currently in the end process of making a complete Elektor SC/MP computer with 3 wirewound PCB's and a separate keyboard + display. Still enjoying the yourney meaning it doesn't work (yet)
Benny

[SiriusHardware]

I think Slothie is holding one OrtonView PCB in reserve in case his first prototype catches fire (more likely, in case it starts falling apart due to constant modification) - who knows, that spare PCB may become available.

If not, the project is simple enough in hardware terms to build on stripboard, especially if you build the original version (without 74LS365 buffers, but with some kludge capacitors on A8-A11). It should hang onto any SC/MP system quite easily, the design allows for any two 256-byte blocks of RAM in the address range 0x000 to 0xF00 to be mapped as the screen RAM.

[Mark1960]

Hi Benny

We’ll look forward to seeing your Elektor SC/MP computer whenever you feel ready to show it working or share some of the fun, finding out why it doesn’t.

Is it old style keyboard and display?

Mark