UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Closed Thread
 
Thread Tools
Old 9th Nov 2020, 11:48 pm   #861
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

I wonder if the likelihood of this happening is influenced by the address at which the code doing the write resides? You may see different symptoms or behaviour of you load the code at 0884, 0887, 088F instead of 0880.

By putting the 8154 / flag setup code back in, you shifted the main code loop further up in the 088x block. I've put mine to bed for the night but you could try ORGing the main code loop to different start locations within the 08xx block and see if that causes any variations in symptoms.

Last edited by SiriusHardware; 10th Nov 2020 at 12:05 am.
SiriusHardware is online now  
Old 9th Nov 2020, 11:59 pm   #862
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

I will try fiddling tomorrow - I certainly found that varying the code impacted on where or if the corruption appeared when I first wrote CHARSET
Timbucus is offline  
Old 10th Nov 2020, 1:52 am   #863
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
One non-canonical way to go around this would be to map something like a 74LS573 (8 bit latch) onto the final address in the memory hole (07FF) replacing one byte of RAM, and use the outputs of that to control the VDU functions. Literally as cheap as chips, unlike the antique LSI ICs.
You could also decode the address for writing to the 8154 to select the write to a ‘573 or ‘273 (which has a reset input but not tristate). This could then be software compatible with someone using an 8154. 74hct series might be better to avoid additional bus loading, not very retro but neither is the PIC.

Did you both (Tim and Sirius), mount the 47 pf capacitors in the same location?
Mark1960 is online now  
Old 10th Nov 2020, 9:58 am   #864
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

It's a good idea to put the latch into the upper range of the I/O port block as the 8154 only really uses a handful of addresses in that range but then the address decoding for the 8154 would have to be intercepted on the MK14 itself, requiring mods to the MK14. That's why I suggested knocking out one byte of the extra-extra RAM (0200-07FF) instead, so that it could be incorporated into the address decoding for that section which is off-board.

Capacitor placement: Yes, sort of, but since Tim's build and mine are physically different it's impossible for us to place them in exactly the 'same' place but I put mine on the threshold of the PIC PCB as he did, ie, the point where A8-A10 exit the PIC PCB.
SiriusHardware is online now  
Old 10th Nov 2020, 3:44 pm   #865
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: Mk14 vdu

I was thinking the address decoding would be duplicated off board rather than share the 8154 address decoding.

If you wanted to simulate the bitwise output of the 8154 then the 74hct259 might be useful.

I couldn’t think of an easy way to combine bitwise and bytewise output.
Mark1960 is online now  
Old 10th Nov 2020, 4:09 pm   #866
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Quote:
Originally Posted by Mark1960 View Post
I was thinking the address decoding would be duplicated off board rather than share the 8154
Well, let's say you decide to map the extra hardware at 0840, above the range of the registers in the I/O portion of the 8154 but below the block occupied by the 8154 RAM (0880-08FF)

Even though there are no registers in the 8154 residing at that address, the _CE for the 8154 probably selects that IC anywhere within the 0800-087F block so it may clash with anything else you try to map into there. There may even be images of the 8154 I/O registers filling up the 0800-087F block.

That's why I think you would have to either intercept and further decode the 8154 chip select on the MK14 board, or, move the 8154 offboard and do the address decoding for it and the extra hardware there.
SiriusHardware is online now  
Old 10th Nov 2020, 5:26 pm   #867
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: Mk14 vdu

I was thinking the ‘573 would be given the same address as the bytewise output port of the 8154. Any write to the 8154 output port would also be written to the ‘573, but instead of connecting to the output port of the 8154 the vdu would connect to the output from the ‘573.

The 8154 would not be required if only the output port to the vdu was used.
Mark1960 is online now  
Old 10th Nov 2020, 5:40 pm   #868
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Well, unless you wanted to use the 8154 for its original intended purpose of controlling or reading input from something else, not the VDU

We originally decided to try to use the 8154 to control VDU functions because when connected together one for one nearly all of the VDU control pins happened to land on 8154 port pins, but to be honest I feel that's a bit of a waste of the 8154, the only decent I/O capability the machine really has.

Other possibility is to use an I2C parallel port IC (PCF8574?) to control the VDU control inputs and bit-bang I2C using Flag / Sense outputs. You'd still need to route TOP PAGE to one of several different destinations by some other means though.
SiriusHardware is online now  
Old 10th Nov 2020, 7:31 pm   #869
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

I repeated last night's experiments with 100pF capacitors. As with the 47pF capcitors fitted I never get the reverse-C appearing third from right, and unlike then, with the 100pFs fitted I don't see any flashes of interference in the empty digits 3rd and 4th from right no matter how many addresses I step through. So far so good.

On to Charset, writing to 03xx and watching 0Fxx and 0Bxx on the OrtonView screen. Previously, I was seeing the bytes at 0F1B and 0B1B both changing to 'O' within a minute or so of starting the program.

I still get 0B1B changing within that time scale but 0F1B no longer does, so tomorrow I'll try going higher again with the capacitors. The value will depend largely upon what I can find at work, but I'm thinking perhaps 180pF.

I've also ordered a flat-pack 44-pin 16F877-20, which I'm going to put on one of my spare Microchip '44-pin-demo' PCBs for my permanent build of the OrtonView. One reason to do that is that those boards already have the supply rails, reset circuit, crystal circuit, ICSP header provided on them, another is that they are quite compact. My current 'build' of OrtonView is quite unruly, much more so than Tim's, with quite a few long, flying wires between the PIC PCB and the 64-way DIN connector. I'll be able to make the wires a lot shorter if I use one of those PCBs.
SiriusHardware is online now  
Old 10th Nov 2020, 8:36 pm   #870
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

I found some 56pFs so I've paralleled those up with the 100pF capacitors already on the PCB. As before, no reverse-C at any time either when idle or when stepping through memory.

Ran Charset again writing to 0300 and watching 0Fxx and 0Bxx and so far - about half an hour now - I have not seen any character change in the 0Fxx or 0Bxx area. If it keeps going for another half an hour I will fit 180pFs at work and then thoroughly test it tomorrow night.
SiriusHardware is online now  
Old 10th Nov 2020, 8:39 pm   #871
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
I still get 0B1B changing within that time scale but 0F1B no longer does, so tomorrow I'll try going higher again with the capacitors. The value will depend largely upon what I can find at work, but I'm thinking perhaps 180pF.
Maybe try adding 100 pf to A11 first.

A11 floating high would correspond with writing to 0B1B instead of 031B.

Tim might not have needed a cap on A11 if his charset was writing to 0B1B.
Mark1960 is online now  
Old 10th Nov 2020, 8:51 pm   #872
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

As a matter of fact I do have four 100pF capacitors fitted, not three, and now four 56pF capacitors in parallel with them. (A8-A11). 4 x 100pF was better again than before but wasn't quite perfect, still occasional corruption of the 0Bxx block when writing to 03xx.

At the moment with 100+56pF on each of the four lines it appears absolutely solid, but I have no way of knowing whether that is only just enough capacitance to make it work reliably, so tomorrow I'm going to up it to 180pF each line to see if it:-

-Keeps working.
-Stops working.

Between us, Tim and I need to arrive at a minimum and maximum value for these capacitors which will hopefully guarantee operation of this circuit for anyone else who builds one.
SiriusHardware is online now  
Old 10th Nov 2020, 8:58 pm   #873
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

As of last night I left the expansion RAM version running until I went to bed and the underline had changed to an O so tonight now I will try a 100pF on A11 only (leaving the others unchanged at 47pF). I will then progress to some additional ones on A8-A10.
Timbucus is offline  
Old 10th Nov 2020, 9:02 pm   #874
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Again with the 100+56pFs on A8-A11 I've just succeeded in getting through about 6 levels of MINEFIELD without issues, or at least none that were not caused by my bad driving. Looking quite promising. Let me try 180pFs tomorrow and if that works maybe you would be so good as to try that value (or parallel capacitors to that value) as well.
SiriusHardware is online now  
Old 10th Nov 2020, 9:10 pm   #875
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

So what aspect of the timing is changing that these additional capacitors make?
Slothie is offline  
Old 10th Nov 2020, 9:16 pm   #876
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

They must be delaying the leading and falling edges of A8-A11. I'll have a look on a scope when I am sure that I have the final values. I would still prefer to fix this in firmware eventually because the optimum capacitor values may vary, depending on what there is on the high address lines. Systems which don't have extra memory may need a different set of values, we want a 'one fits all' solution really.
SiriusHardware is online now  
Old 10th Nov 2020, 9:58 pm   #877
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: Mk14 vdu

Quote:
Originally Posted by Slothie View Post
So what aspect of the timing is changing that these additional capacitors make?
They should be delaying the rise of A8 to A11 when NENIN is raised to kick the SCMP off the bus. They need to be held at the logic level that was being driven by the SCMP longer than the time it takes for NWDS to be pulled high.

Timing of NWDS rise would be dependent on the release time of the SCMP and the pull up resistor, but I don’t think that could be reduced much below 4.7k without loading the SCMP output too much.

It seems likely that the Orton View PIC drive of A8 to A11 is pulling these address lines high a bit faster than the MK14 vdu drivers.

Maybe scoping A11 and NWDS with charset writing to 03xx could show the difference between Orton View and MK14 vdu.

A better understanding of the PIC output drive might still make a software fix possible, which would be the nicest solution.

Another possibility could be to buffer the PIC address drive with a couple of 74ls365s, with enable gated by NENIN high and NRDS low, but this is not in keeping with the simplicity of Karen’s design.
Mark1960 is online now  
Old 10th Nov 2020, 10:03 pm   #878
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Well that is 1 hour running Sirius' version of Charset with 100pf on A11 (on the RAM board) and 3x47pF as was on OrtonView A8-A10. No sign of corruption. I might drop it back to 47pF - maybe the RAM expansion means I need it on A11 as well.

I will then then repeat with 147pF on each line to bracket as Sirius suggests - or even higher. Might not be for a day or so as busy couple of days coming up.
Timbucus is offline  
Old 10th Nov 2020, 10:08 pm   #879
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

The address drive from the SOC VDU is 'gated' by proper tristate buffers, whereas the PIC I/O pins most likely swim high when configured as inputs.

It seems as though the capacitors delay the rise of the address lines for just long enough for SC/MP NRDS to end, in the specific cases where NENIN rises smack in the middle of an SC/MP NWDS pulse.
SiriusHardware is online now  
Old 10th Nov 2020, 10:08 pm   #880
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Well instant corruption at B1B with a 47pF in A11 - changing a few times as well
Timbucus is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 3:50 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.