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 25th Oct 2020, 11:32 pm   #601
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Well this is probably a good news report and should be repeatable for Sirius.

I played 12 levels of Minefield on the SOC VDU with no problems until I got bored and triggered my explosion; If you hold F down to continuous fire (or pulse it a lot) then when it gets the end of the screen it crashes through memory - it was a bug to do with the slight recoil on fire that I left in as it is a good anti-cheat...

I was only half joking on the Pot but thanks for the warnings. I tried soldering another 4.7K in parallel and that seemed to have little effect - I could still cause FALLMAN (occasionally) and MINEFIELD (always by the end of Level 1) to crash. CHARSET ran fine. Still saw the odd reverse C

Just replaced the effective 2.3K with a 10K - my original fault on CHARSET is back in the same spot and FALLMAN/MINEFIELD crash a lot quicker.

However, my clock may say half ten but, my body says it is bed time and I have work again in the morning...

EDIT: For clarity this is the pullup on NWDS.
Timbucus is offline  
Old 25th Oct 2020, 11:35 pm   #602
Phil__G
Octode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,080
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
... in other words a byte value of b0001111 or 0x0F is somehow eventually getting written to that display cell.
just a thought, hope you dont mind me chipping in, shouldnt the 'Ↄ' be a 'O' which are the same except for bits 4 & 5 being low? maybe its not 0x0F being written, but bits 4&5 being pulled low? just thinking, these are nibble-wide RAM chips, and bits 0-3 are correct... ? ? ?
Phil__G is offline  
Old 26th Oct 2020, 12:03 am   #603
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
Indeed, maybe have a 470R in series with the pot just to be on the safe side.

For information, the reverse 'C' character is formed by segment a (=1) + segment b (=2) +segment c (=4 ) + segment d (=8) , in other words a byte value of b0001111 or 0x0F is somehow eventually getting written to that display cell.
D7-D4 of course share the IC11 input from the keyboard strobe buffer pulled up - I see you point out they that they are 0 but, they will behave differently when the keyboard is scanned. Anyway Sirius may remember some shenanigans with mine - I have currently been running with an 80C95 not 80L95 so I put in the 74LS365 from my JMP (I do not own an 80L95) but, as we both had the same symptom it seemed unneeded I tried anyway. I noticed that the reverse C now appears subjectively more often? Also the system is unusable as my PI cannot type data even with the VDU off or disconnected. I will experiment more with that tomorrow as I have not used these scripts on the JMP - I have an older version for it with different constants.

Putting the C back in restored operation - with the same repeatable char on CHARSET with the 10K NWDS pullup (the old 4.7K must have been close to that with the crack).

While I was panicking that I had broken something I was uploading SEGTRIS so I tried that with the VDU on and OFF - its 7 digit display corrupts sometimes when playing with the VDU on consistent with a corrupt memory write.
Timbucus is offline  
Old 26th Oct 2020, 12:05 am   #604
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by Phil__G View Post
Quote:
Originally Posted by SiriusHardware View Post
... in other words a byte value of b0001111 or 0x0F is somehow eventually getting written to that display cell.
just a thought, hope you dont mind me chipping in, shouldnt the 'Ↄ' be a 'O' which are the same except for bits 4 & 5 being low? maybe its not 0x0F being written, but bits 4&5 being pulled low? just thinking, these are nibble-wide RAM chips, and bits 0-3 are correct... ? ? ?
It should actually be a blank space not anything at all but, good observation.
Timbucus is offline  
Old 26th Oct 2020, 12:12 am   #605
Phil__G
Octode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,080
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
It should actually be a blank space not anything at all
Ah yes of course, sorry
Phil__G is offline  
Old 26th Oct 2020, 12:15 am   #606
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by Phil__G View Post
Quote:
Originally Posted by SiriusHardware View Post
It should actually be a blank space not anything at all
Ah yes of course, sorry
No problem appreciate the contribution keep em coming - it is a useful observation. I should have mentioned though that the SEGTRIS corruption of the display was also a 'Ↄ' (nice trick Phil_G) in the first two or three 7 segments on the left.
Timbucus is offline  
Old 26th Oct 2020, 1:00 am   #607
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
Indeed, maybe have a 470R in series with the pot just to be on the safe side.

For information, the reverse 'C' character is formed by segment a (=1) + segment b (=2) +segment c (=4 ) + segment d (=8) , in other words a byte value of b0001111 or 0x0F is somehow eventually getting written to that display cell.
It is also interesting that d0-d3 are the only data bits pulled high by resistors on the MK14...
Slothie is offline  
Old 26th Oct 2020, 1:10 am   #608
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
Mark1960 has a point in post #583.

Were the VDU to assert NENIN part way through a write cycle to screen memory, then that write cycle may be corrupted, resulting in temporary corrupted data in memory. Corrupted data may then show up in the screen display.

When the SC/MP is allowed to resume, the SC/MP will repeat the cycle, complete successfully and restore correct data to memory.
If the address is not held at the end of an interrupted write cycle it might be corrupting some other address, then when the same bus cycle is repeated later it would not be the corrupted address that is written.

The SCMP outputs will be tristated by NENIN high, so rise time on NWDS might be slow, while the address lines may be driven to a different address by the PIC quite quickly.

For me this is just guesswork as I don’t have anything set up to try this.
Mark1960 is offline  
Old 26th Oct 2020, 9:41 am   #609
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

I've been working on a new version of the code which doesn't alter serial port baud rate for graphics i.e. both text and graphics use 4 M pixel/sec. It is hoped that this will eliminate juddering (unless someone's witnessed juddering on text?!!)

Trouble is, this new code has grown in size, and key routines may not fit into the PIC 2k code page they reside in. I won't be able to test this until I get back on my old XP laptop ('development' is limited to text editing on this crummy little laptop I have in hospital for the moment)

I live in hope!
Karen O is offline  
Old 26th Oct 2020, 9:54 am   #610
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Appreciate the determination to make it compatible with A parts.

I am hoping Sirius will be able to reproduce the charset memory corruption as we might stand a chance of tracing what is likely the final bug. I had thought to try some gates that block the PIC assertion of NENIN while NWDS is still asserted but then I would need buffers as well and it becomes complex - if as the above implies it retries the write then that would
Not work - the buffers would make it just like the SCRUMPI one - which I will do one day...

Anyway if while editing the ASM you spot an opportunity to put a guard time - and flag where with a comment for NENIN to allow the write to finish - perhaps a bit like on the older FW which did not have this issue we could experiment empirically locally for you. Marks theory seems very possible to me

I am also not clear if the added reads flapping NRDS that are over and above the SOC design to accommodate the other chips was put in? If so that could perhaps be an area to highlight in the code for temp removal as it is a difference in the spec

I know I’m a man I hate asking for directions but, it seems needed in the complex neighbourhood
Timbucus is offline  
Old 26th Oct 2020, 9:55 am   #611
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Quote:
I live in hope!
So do we.

I gather you are using an old XP laptop there, will one of the older archived versions of MPLAB or MPASMWIN not run on that? (Maybe the laptop doesn't have an internet connection).

There has never to my knowledge been a problem with judder in character mode, and there has only been a problem with judder in graphics mode

-From the first optimised version of firmware onwards
-Only with 'A' suffix PIC devices.
SiriusHardware is online now  
Old 26th Oct 2020, 11:23 am   #612
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Ah...

So you haven't experienced judder using the PIC16F877-20/P ?

Well, that sounds like a solution to me!

I suspect the judder problem is revealing of chip internal implementation details. In its proper context (serial communications) it usually doesn't matter if there is uncertainty about exactly when each transmission will begin. I sometimes have to remind myself that I have no right to be indignant about such details, when I am using a peripheral for a purpose never intended.

I have hacked together a version of the code which uses a fixed pixel clock 4Mpix/sec.

It is very unlikely that it will work: there may be typos, etc. and even if the MPLAB tools deem it valid code, I may have overrun a 2k page limit. I'll post it here anyway, just on the very remote chance that it works...
Attached Files
File Type: zip mk14vdu.zip (6.1 KB, 47 views)
Karen O is offline  
Old 26th Oct 2020, 11:29 am   #613
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Quote:
I am also not clear if the added reads flapping NRDS that are over and above the SOC design to accommodate the other chips was put in? If so that could perhaps be an area to highlight in the code for temp removal as it is a difference in the spec
Yes, that feature is in and no, it won't be easy to take out!
Karen O is offline  
Old 26th Oct 2020, 12:42 pm   #614
Phil__G
Octode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,080
Default Re: Mk14 vdu

Just a further thought, sorry I'm chipping in again... in the main video loop there are a lot of adjacent BSF/BCF/BTFSS on port C, could it be the old pic read-modify-write problem?
(at 20mhz the 'read' is only 50ns after the 'write' ie ¼ cycle)

Last edited by Phil__G; 26th Oct 2020 at 12:53 pm.
Phil__G is offline  
Old 26th Oct 2020, 1:21 pm   #615
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Quote:
So you haven't experienced judder using the PIC16F877-20/P ?
Well, that sounds like a solution to me!
We have been careful to point out that the 'A' suffix device is the only device which does this. We did also say that as the leader of your project it was up to you to declare, if you wanted to, that the project has to use a plain 877, not 'A'.

I won't be able to try the new offering until this evening.
SiriusHardware is online now  
Old 26th Oct 2020, 1:30 pm   #616
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Hi Phil G

You're thinking of read-modify-write hazards for port C? There are two outputs that might be vulnerable: the TOP output and the video sync output. The former is actually only valid for brief periods during frame blanking. The video sync... well... if trouble were occurring here we might see tears and discontinuities in the picture but none of the symptoms we've experienced so far.

BTW, the PIC processor clock is one quarter of the crystal frequency (so the instruction cycle is 250nsec for this application).

It would do no harm for me to sweep the code for BSF/BCF instructions in anticipation of such problems though...
Karen O is offline  
Old 26th Oct 2020, 1:37 pm   #617
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Quote:
We have been careful to point out that the 'A' suffix device is the only device which does this. We did also say that as the leader of your project it was up to you to declare, if you wanted to, that the project has to use a plain 877, not 'A'.
I have no strong feelings on this, SH. If I have mistaken efforts to get things working on the 'A' version as efforts to make the code work at all (which I have, at least for a while) well that's my own fault for not paying enough attention to posts!

I find it interesting that the juddering seems synchronised to the video frame rate. Any theories as to why this might be...?
Karen O is offline  
Old 26th Oct 2020, 1:49 pm   #618
Phil__G
Octode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,080
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
BTW, the PIC processor clock is one quarter of the crystal frequency (so the instruction cycle is 250nsec for this application).
At 20mhz the instruction cycle is 200ns, but each instruction cycle is four 50ns clock pulses. I need to check the sheet but I think adjacent read-modify-writes use the last clock of the four for the previous write and the first clock of the next four-clock instruction for the next read, hence only one 50ns clock between write & read, which with minimal capacitance can lead to the read-modify-write problem
I usually use a shadow. But this is from memory, I dont have the sheets with me

Last edited by Phil__G; 26th Oct 2020 at 2:02 pm.
Phil__G is offline  
Old 26th Oct 2020, 1:50 pm   #619
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
I find it interesting that the juddering seems synchronised to the video frame rate. Any theories as to why this might be...?
You're actually asking?? The intricate workings of the code are way over my head. I may understand it better some day if I work through it line by line, but in the short term there is unfortunately no substitute for being the person who wrote the code.

I still need to carry out the test process I mentioned a few posts ago to be absolutely sure that the offset is per whole frame (only within the active area of the screen) or per line as you originally expected it would be. I'll add that to my 'to do' list and report back, since the root cause for one case or the other will be quite different. Of course if the code you posted today fixes it, that question will be redundant.
SiriusHardware is online now  
Old 26th Oct 2020, 1:56 pm   #620
Phil__G
Octode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,080
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
BTW, the PIC processor clock is one quarter of the crystal frequency (so the instruction cycle is 250nsec for this application).
At 20mhz the instruction cycle is 200ns, but each instruction cycle is four 50ns clock pulses. I need to check the sheet but I think adjacent read-modify-writes use the last clock of the four for the previous write and the first clock of the next four-clock instruction for the next read, hence only one 50ns clock between write & read, which with minimal capacitance can lead to the read-modify-write problem
I usually use a shadow. But this is from memory, I dont have the sheets with me
Phil__G is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 5:11 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.