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.

Reply
 
Thread Tools
Old 29th Oct 2020, 10:14 pm   #701
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Quote:
I call that tuning.... blame your test team for not isolating the fault.
I blame no one but myself.

Observation: in the non-optimised version, NENIN is changed four times per frame. In the optimised version it is changed 516 times per frame.

Maybe the corruption phenomenon is always there but so rare that in the non-optimised version we don't notice it.
Karen O is offline   Reply With Quote
Old 29th Oct 2020, 10:16 pm   #702
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,387
Default Re: Mk14 vdu

Karen, thanks for the latest try to get things running smoothly. As Tim has already test driven it and found that it didn't seem to make a difference, I haven't tried it myself.

One thing I did do was this:

-OrtonView with the latest mainstream firmware, enabled, displaying 0Fxx and 0Bxx

-CPU kept out of harm's way by executing a tight loop in I/O RAM (0880) so that the only thing accessing the 0Fxx and 0Bxx RAM areas (and therefore activating the chip enables for those areas) should be OrtonView

Attached images are both captured at 1V/Div with 0V lined up on the first thin horizontal graticule line.

#1: Sample portion of CE1 of the 0Bxx RAMs

#2: Sample portion of CE1 of the 0Fxx RAMs

The CE1 of the 0Bxx range has only two logic levels, enabled and not.

The CE1 of the 0Fxx range has three distinct levels. I don't like that at all.

I'm wondering if we need to try putting 'real' tristate buffers between the address output pins on the PIC and the SC/MP address bus, or less drastically, try pulling at least the high bits A8-A11 either high or low.

If we insert buffers, that implies the need for an enable signal for those buffers and unfortunately we don't have any pins left over for that.
Attached Thumbnails
Click image for larger version

Name:	OrVw_CE1_0Bxx.jpg
Views:	22
Size:	82.1 KB
ID:	219186   Click image for larger version

Name:	OrVw_CE1_OFxx.jpg
Views:	24
Size:	80.6 KB
ID:	219187  
SiriusHardware is online now   Reply With Quote
Old 29th Oct 2020, 10:24 pm   #703
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

I notice that in the circuit diagram I supplied in #352 I omitted the power rail decoupling capacitor. This is 100nF between GND and +5V.

If you haven't included this capacitor, I would try it because it can cure a whole range of strange behaviour.
Karen O is offline   Reply With Quote
Old 29th Oct 2020, 10:28 pm   #704
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,387
Default Re: Mk14 vdu

On the PIC circuit you mean? On mine, the 'PicDuino' shown a while back now, there are already supply decoupling capacitors mounted very close to the supply pins.
SiriusHardware is online now   Reply With Quote
Old 30th Oct 2020, 12:16 am   #705
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 737
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
On the PIC circuit you mean? On mine, the 'PicDuino' shown a while back now, there are already supply decoupling capacitors mounted very close to the supply pins.
Mine of course is a very literal build and has none - I will add one to see if it helps - to play fair the scope does not show a very noisy rail.

Karen's point about the rarity of an event may be relevant and it could be a risk that exists in the MK14 that nobody ever noticed - if you mess with NENIN but the SOC VDU is so laid back it never shows it up. I have never had an issue with #352 no matter how much I play but, all optimized ones experience corruption ergo it is related to events where you give the SC/MP back the buses before everything has settled down or you are still changing/clamping it.

Those small 1.4v values seem common even without the OrtonView and indeed are present on the SCRUMPI - they were the ones that were not quite high enough on SCMP II to allow a 1 to be written without a pullup... it may just be a feature of the SC/MP tri-state architecture

For fun a gratuitous picture of NENIN against the video frame because I wanted to see if I understood how to use the new toy that Sirius said was worth buying yet then then said he wished he had more than two channels Taken on the #692 firmware of course.

Click image for larger version

Name:	IMG_4158.jpg
Views:	30
Size:	98.9 KB
ID:	219191Click image for larger version

Name:	IMG_4161.jpg
Views:	28
Size:	86.7 KB
ID:	219192
Timbucus is offline   Reply With Quote
Old 30th Oct 2020, 1:07 am   #706
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,387
Default Re: Mk14 vdu

Strictly speaking those are video LINEs you have lined up against NENIN there.

My alarm over the images in #702 has to do with the fact that those are _CE signals which should ideally only ever really be in one state or another - not like bus lines which may be driven low, driven high or tristate, so you can expect to see some odd levels on buses.

A nice feature of those scopes is the way you can freeze the image at any time and then alter the Time / division, Volts / division and horizontal position controls to zoom in on and look at a particular point in a captured waveform in more detail.

I might try writing a bit of test code (for the PIC) which runs through all valid RAM base addresses to see what happens on all of the relevant _CE pins (NENIN will need to be asserted each time I output a base address on A8-A11 so that the SC/MP does not try to use the buses at the same time).
SiriusHardware is online now   Reply With Quote
Old 30th Oct 2020, 9:50 am   #707
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

My code allows for an approx. 3 usec margin when asserting/removing NENIN during the active display area. I suspect that is not enough. Trouble is, the cycle scavenging only gives back 32 usec to the SC/MP (approximately the active display time per scan line). If the switchover margins are made much wider, then there will be precious little to be scavenged.

In the absence of cycle scavenging, there are TWO NENIN asserts and de-asserts. These correspond to a period early in each 625 frame during which the display buffers are being pre-charged; and the actual active display lines (some 16.384 millisec) during which the bulk of the display data is fetched. I could widen these margins considerably for these two cases, though it just doesn't seem necessary.

There's a strong argument for NOT awarding the SC/MP small slithers of time (such as is done with cycle scavenging). The SC/MP might find each awarded slither insufficient to complete a read or write cycle. In that event, the SC/MP is effectively stalled, doomed to keep retrying a memory cycle over and over (potentially 256 times per frame).

It's a ****** minefield, that's what it is!

Last edited by Karen O; 30th Oct 2020 at 9:51 am. Reason: unclear
Karen O is offline   Reply With Quote
Old 30th Oct 2020, 10:18 am   #708
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,387
Default Re: Mk14 vdu

I see where you are coming from but the improvement in MK14 running speed is so dramatic in recent firmware versions that contrary to that pessimistic view, the SC/MP seems to be getting a LOT more done when these firmware versions are in use.

I think Slothie was joking a little bit when he said it was 'too fast', I think he just meant there was wiggle room if you wanted to lose a little bit of speed, because as things stand your firmware slows the MK14 down slightly LESS than the SOC VDU does, about 4% slowdown as against about 8% for the SOC VDU measured by the same 'benchmark'.
SiriusHardware is online now   Reply With Quote
Old 30th Oct 2020, 10:42 am   #709
Slothie
Heptode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 666
Default Re: Mk14 vdu

Indeed I was trying to convey my opinion that if you have to rob a little speed for stability there is plenty of room to do so.
Slothie is offline   Reply With Quote
Old 30th Oct 2020, 3:32 pm   #710
Mark1960
Pentode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 202
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
The CE1 of the 0Fxx range has three distinct levels. I don't like that at all.
Is this chip enable direct from the address bus? The A0 in previous posts shows similar levels. As the RAM chips have two chip enables this might not be a problem if the other chip enable is high at those times but its also never good to have indeterminate signal levels. Maybe adding pullups to the most significant address lines would help.
Mark1960 is online now   Reply With Quote
Old 30th Oct 2020, 3:42 pm   #711
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 737
Default Re: Mk14 vdu

Well not sure if this moves us forward or not but, it is interesting. Scoping the two _CE1 to reproduce Sirius' results I thought I would check my JMP as well and luckily for Slothie it has similar level issues on the B00 RAM _CE1 so it is a feature of the MK14 Anyway this photo has B00 on top as I was just holding the probes on:

Click image for larger version

Name:	IMG_4169.jpg
Views:	12
Size:	85.9 KB
ID:	219233

I notice that all the funny levels correspond with where the other _CE is in transition... it seems more than a fluke as I looked quite a bit.

So in the meantime I rigged some wires onto the chips so I can clip on (I really must buy some proper chip clips...) and now B00 is on the bottom zoomed in.

Click image for larger version

Name:	IMG_4179.jpg
Views:	10
Size:	78.3 KB
ID:	219234

To me that looks like they are both low at the same time effectively so I thought Hmm maybe the problem is a pullup / down is needed - I settled on a 4.7K pullup and to me it looks cleaner and the MK14 works fine with and without the Orton View...

Click image for larger version

Name:	IMG_4178.jpg
Views:	11
Size:	79.1 KB
ID:	219235

All the video stuff works fine but. MINEFLD still crashes - in a slightly different way now so it is having an impact. As the CHARSET is the most predictable I put a switch on my NENIN pullup so I can go between 4.7K and 10K as my 10K gives the character written to both memories - sure enough it appears again exactly 8 bytes further up in memory than without the _CE1 pullup on B00 - here is a picture where I disconnect it while the code is running... so both F00 and B00 get the benefit - EDIT: just to clarify it moves up 8 bytes in each area - the same char is written to both as you can see

Click image for larger version

Name:	IMG_4180.jpg
Views:	18
Size:	58.4 KB
ID:	219236

No idea what it all means but, interesting and others may spot something useful.

Last edited by Timbucus; 30th Oct 2020 at 3:51 pm.
Timbucus is offline   Reply With Quote
Old 30th Oct 2020, 3:44 pm   #712
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 737
Default Re: Mk14 vdu

Quote:
Originally Posted by Mark1960 View Post
Quote:
Originally Posted by SiriusHardware View Post
The CE1 of the 0Fxx range has three distinct levels. I don't like that at all.
Is this chip enable direct from the address bus? The A0 in previous posts shows similar levels. As the RAM chips have two chip enables this might not be a problem if the other chip enable is high at those times but its also never good to have indeterminate signal levels. Maybe adding pullups to the most significant address lines would help.
Great minds obviously...
Timbucus is offline   Reply With Quote
Old 30th Oct 2020, 4:19 pm   #713
Slothie
Heptode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 666
Default Re: Mk14 vdu

Quote:
Originally Posted by Timbucus View Post
Quote:
Originally Posted by Mark1960 View Post
Quote:
Originally Posted by SiriusHardware View Post
The CE1 of the 0Fxx range has three distinct levels. I don't like that at all.
Is this chip enable direct from the address bus? The A0 in previous posts shows similar levels. As the RAM chips have two chip enables this might not be a problem if the other chip enable is high at those times but its also never good to have indeterminate signal levels. Maybe adding pullups to the most significant address lines would help.
Great minds obviously...
The CE1 for the Bxx memory comes straight from A10, for Fxx its via a 74LS04 inverter. If the bus is tristate that would mean the input to the inverter is floating so its not impossible to imagine wierd logic levels on its output, although I thought that was more an issue for CMOS inverters.
Slothie is offline   Reply With Quote
Old 30th Oct 2020, 4:29 pm   #714
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 737
Default Re: Mk14 vdu

Indeed it is effectively A10 I have the pullup on. I had to up it to 10K as the Mk14 in SCIOS was doing weird things ending up jumping into very high memory addresses when stepping with MEM.

I also notice that on the new FW chip the LISTER program which runs in F00 memory and displays in B00 is crashing when you use Go to get to the next page once or twice - with the pullup it displays corrupt characters and always dies on the first Go. Either way it dies - I put the old chip back in and it works fine except with the pullup on A10/_CE1 where it does eventually die.

Last edited by Timbucus; 30th Oct 2020 at 4:36 pm.
Timbucus is offline   Reply With Quote
Old 30th Oct 2020, 4:45 pm   #715
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,387
Default Re: Mk14 vdu

For clarity, I think from now on we all need to always state exactly which firmware is in use for any given tests - I assume by 'old' you mean pre-optimised and by 'new' you mean some recent version of the optimised firmware. Using your convention of naming it after the number of the post it first appeared in is probably the best way.

Will have another look at this a bit later.
SiriusHardware is online now   Reply With Quote
Old 30th Oct 2020, 5:02 pm   #716
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 737
Default Re: Mk14 vdu

Yes apologies I am referring to New as in the #692 version and the Old as in the nearly working #523/#621 it would have been better to say previous as I consider #352 as the stable one on which LISTER works flawlessly.
Timbucus is offline   Reply With Quote
Old 30th Oct 2020, 7:19 pm   #717
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,387
Default Re: Mk14 vdu

Agree that FW352 is the final pre-optimised version, works flawlessly but IMO slows the system down far too much. We'll always have that one to fall back on and to work forwards from.

FW523 is the first optimised version where Karen had spotted and fixed that Port-A read/write issue, so that is what I consider to be the mainstream optimised version with other subsequent versions as 'forks' or experimental versions. This is the first version where the screen started to be rendered properly in both Character and Graphics mode, at least on the non-A variant PIC, and also where the MK14 started to work normally again in terms of running speed / display scanning speed. This is an improvement well worth trying to keep, I think.

Some of the later versions were where various things were tried in order to fix the 'graphics mode shudder' which afflicted only 'A' versions of the IC. We are all now agreed that we just fix that by using the non-A variant of the chip, so I think we should regress back to FW523 which was devoid of those mods.

Other later mods were aimed at fixing the current 'occasionally writes go to the wrong memory page' problem which we still have, but as they unfortunately didn't solve the problem, I would say we should again go back to FW523 which doesn't have those redundant mods in it so we are working from the cleanest 'optimised and almost working' version we have.
SiriusHardware is online now   Reply With Quote
Old 31st Oct 2020, 1:14 pm   #718
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,387
Default Re: Mk14 vdu

Assuming FW523 + Charset running, where charset is writing to the 0Bxx block but characters occasionally get written to the same location in the 0fxx block:-

It might be useful to observe whether:-

-The unwanted write occurs INSTEAD of the 'wanted write' - every once in a while the system writes a 'wrong' byte to one of the wrong pages instead of writing the right byte to the right page.

-The unwanted write occurs AS WELL AS the 'wanted' write - the right character gets written to the right location AND at the same time the wrong character gets written to the wrong place.

The way to determine this is to carefully watch the sequence of rolling characters being written to the screen area at 0Bxx and try to notice whether that sequence ever skips a character, and if, whenever it does, a stray character gets written to the same location in the 0Fxx area.

Unfortunately this will take a lot of patience to catch in the act. It could even be worth adding a bit of code which checks that what was supposed to be written to 0Bxx actually was, and if not, stops the run.
SiriusHardware is online now   Reply With Quote
Old 31st Oct 2020, 4:01 pm   #719
Buzby123
Pentode
 
Buzby123's Avatar
 
Join Date: Oct 2011
Location: Culcheth, Cheshire, UK.
Posts: 186
Default Re: Mk14 vdu

Sorry to butt in.

I've been following closely, but as I've still not got Micky working I can't offer a third hand eye on the project.

However, it did occur to me that between the two of you, is it possible you could somehow give Karen remote access to your hardware ?.

Karen has worked wonders under very difficult conditions, and if you could make things easier I'm sure she would be grateful.

( Karen helped me ten years ago, but she doesn't know it !. )
Buzby123 is offline   Reply With Quote
Old 31st Oct 2020, 5:16 pm   #720
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,387
Default Re: Mk14 vdu

Quote:
Originally Posted by Buzby123 View Post
is it possible you could somehow give Karen remote access to your hardware ?.
Assuming you're serious, I am all ears. How do we put an MK14 on the internet?

I certainly do wish Karen had the same hardware in front of her as we do, as I'm convinced that if she did, she would instinctively know what the problem is.

We are incredibly grateful for what Karen has managed to do so far in, as you say, the most pressing circumstances imaginable. The remaining problem is one which, in microprocessor terms, only occurs once in a geological age, so accumulating exact information about the cause and effect is proving difficult.
SiriusHardware is online now   Reply With Quote
Reply

Thread Tools



All times are GMT. The time now is 9:25 am.


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 - 2021, vBulletin Solutions, Inc.
Copyright ©2002 - 2020, Paul Stenning.