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 4th Sep 2022, 10:02 pm   #21
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 vdu card

Yes, nicely done - one thing I notice is that the overall image is nicely centred, which I am afraid is not strictly canonical, as a real SOC VDU always has the image noticeably offset towards the left. As it is obviously more desirable for the image to be properly centred, we will forgive you.

One thing that would be interesting to have is an estimate of the degree of MK14 slowdown intoduced when the VDU is active - Karen's initial version of Ortonview slowed the MK14 down quite drastically because it was holding NENIN down for quite long periods of time. (She then made a version which asserted NENIN for shorter periods of time).

We had a test where we had a bit of code which produced 500Hz on Flag 1 on an MK14 running at full speed, then when the VDU was activated the output frequency being generated by that code would drop by x%, giving us a rough idea of the percentage of slowdown.
SiriusHardware is offline  
Old 9th Sep 2022, 11:56 am   #22
Realtime
Hexode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 318
Default Re: Yet another MK14 vdu card

Using SiriusHardware's code from the MK14_VDU thread, I've measured the slowdown of the processor when my VDU card is enabled. Pretty much the same as the original SoC VDU I get 450.8Hz when VDU is off and 422.2Hz when on. An 8.8% reduction in processing speed.

In the first photo the top trace shows the normal nENIN. In the lower trace I have changed the nENIN generation to strobe it for every memory access. So in theory giving the processor some time between memory accesses. Strangely it made no difference at all . Still 422Hz.

The original SoC VDU generates nENIN about 16us ahead of when it is really needed. Crude, but as with all things Sinclair built to a budget and it did the job. The second photo shows an improved nENIN generation that enables it 1us before the active video. Timing results for that are 450.8Hz when VDU is off and 435Hz when on. So now only a 3.7% reduction in speed.
Attached Thumbnails
Click image for larger version

Name:	nENIN1.jpg
Views:	52
Size:	90.5 KB
ID:	264474   Click image for larger version

Name:	nENIN2.JPG
Views:	45
Size:	155.8 KB
ID:	264475  
Realtime is offline  
Old 9th Sep 2022, 8:08 pm   #23
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Yet another MK14 vdu card

Also wondering if you have seen any unwanted writes to different areas of the display memory when the 8060 is kicked off the bus using NENIN. We saw this with the Ortonview but our conclusion was that this only occurred at specific timing of NENIN and lack of synchronisation between the 8060 and the PIC would allow it to sometimes find that timing. If your CPLD is synch to the 8060, you would probably either always have good timing or always bad timing. I wonder how much margin you might have to avoid the bad timing. This might be difficult to test.
Mark1960 is offline  
Old 11th Sep 2022, 4:06 pm   #24
Realtime
Hexode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 318
Default Re: Yet another MK14 vdu card

I haven't noticed anything going wrong with the video writes. Falling Man runs very smoothly with no glitches. I must say I'm not clear what the requirement for nENIN timing is other than if it doesn't crash the processor then it seems to be good. I've read everything I can find on the subject but no specifics on how best to apply it (is there something in the forum threads? - I haven't come across it yet). Is it really that NENOUT should also be used to indicate when the 8060 is ready to relinquish the bus?
Realtime is offline  
Old 11th Sep 2022, 4:13 pm   #25
Realtime
Hexode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 318
Default Re: Yet another MK14 vdu card

Proper back porch and blanking has been now been applied to the output video to allow black video on a white background to to be correctly displayed. Here's a video.

https://www.youtube.com/watch?v=4HZEFValWl4

(The iPad seems more susceptible to picking up the flyback on screen hence the noise).

The first 10 seconds or so also show individual inverse characters which are enabled by setting bit 7 of the character code.
Realtime is offline  
Old 11th Sep 2022, 4:31 pm   #26
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Yet another MK14 vdu card

If you want some more programs to try here is horse race from PE August 1981

HorseRace.zip
Timbucus is offline  
Old 11th Sep 2022, 4:32 pm   #27
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Yet another MK14 vdu card

and the Minefield game... from PE June 1980

MineField.zip
Timbucus is offline  
Old 11th Sep 2022, 4:33 pm   #28
Realtime
Hexode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 318
Default Re: Yet another MK14 vdu card

Great thanks. I shall get to it !
Realtime is offline  
Old 12th Sep 2022, 12:57 am   #29
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Yet another MK14 vdu card

Quote:
Originally Posted by Realtime View Post
I haven't noticed anything going wrong with the video writes. Falling Man runs very smoothly with no glitches. I must say I'm not clear what the requirement for nENIN timing is other than if it doesn't crash the processor then it seems to be good. I've read everything I can find on the subject but no specifics on how best to apply it (is there something in the forum threads? - I haven't come across it yet). Is it really that NENOUT should also be used to indicate when the 8060 is ready to relinquish the bus?
The issue we had with the PIC based Ortonview was seen when repeated writes to one area of the screen would also cause random changes to other locations. A tight loop with no delays incrementing one location seemed to be worst case.

The issue was not seen with original SoC vdu, we think due to the NENIN timing synchronized from the 8060 clock and that this was the reason for some of the delays added to the SoC circuit, for example the use of the 74L86.

There seems to be certain places in the 8060 bus timing where NENIN will change the address outputs of the 8060 before it deactivate NWDS. Capacitors on the high address lines gave some protection against the issue, but adding a ‘74 to delay NENIN slightly after NADS seemed to be a better solution.
Mark1960 is offline  
Old 12th Sep 2022, 1:05 am   #30
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Yet another MK14 vdu card

This is a link to the post in the thread where we were finding a fix.

https://vintage-radio.net/forum/show...&postcount=488
Mark1960 is offline  
Old 12th Sep 2022, 8:28 am   #31
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 vdu card

To be more specific, what we found was that when Ortonview (unmodified) was running, writes to address 0Bxx or 0Fxx would occasionally also cause unwanted writes to the same location in other 256-byte pages, and the theory, I think, was that this was happening on the relatively rare occasions when Ortonview took NENIN low when the SC/MP happened to be asserting NWDS at the time - and not every time, either.

If you had a program which was running in a tight loop and continually (intentionally) writing different characters to (say) location 0B4F, you would see that address xx4F in other 256-byte memory blocks would occasionally get corrupted, perhaps once every several seconds if the program was running in a tight loop with no delays.

The simplest way to observe this happening was to point Ortonview at a 512-byte consecutive area of memory like 0200-03FF while running a program which was continually writing to a particular offscreen memory location like 0F4F. Typically, we would see the screen locations at 024F and 034F being changed from time to time.

Mark devised two fixes for this Ortonview problem, a 'dirty' one involving capacitors on the high address bus lines, and then a more elegant one as per his link in the previous post.

Hopefully your project 'just works' and you don't need to worry about this but it would be worth running checks just in case because this occasional corruption of memory (by Ortonview) issue took a while to make itself known.
SiriusHardware is offline  
Old 12th Sep 2022, 10:29 am   #32
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 vdu card

I should have said: If you write test code to check this out, put your test code in the upper half of any available 256-byte RAM block (0880-08FF in the RAM / IO device is ideal) and choose a RAM location between xx00-xx7F to continually write to, so that the test code itself does not get damaged by occasional writes into the body of the test code.
SiriusHardware is offline  
Old 13th Sep 2022, 3:11 pm   #33
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Yet another MK14 vdu card

Quote:
Originally Posted by SiriusHardware View Post
Hopefully your project 'just works' and you don't need to worry about this but it would be worth running checks just in case because this occasional corruption of memory (by Ortonview) issue took a while to make itself known.
I've incorporated Marks 74LS74 latch modification to my Ortonview with the PIC16F887 version of the code and had a memory write test as you describe running for hours without sign of memory corruption. So if he does experience the corruption, maybe that will furnish clues how to fix it.

PS I'm currently looking at the remaining issues
1) Battery backup - mod seems to have worked just needs more testing
2) Removal of the buffers that proved unnecessary
3) Various footprint/layout issues
4) Possibly use the now spare gates to remove LHS white line? I'm not sure about the coding changes this would require even if I was able to free up an I/O pin.
Slothie is offline  
Old 13th Sep 2022, 3:22 pm   #34
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 vdu card

I wonder if it would just be simpler to use a small 8-pin PIC as a dedicated LH white line remover, but maybe if we are going to discuss development of Ortonview in detail it might be better to ask for your Ortonview PCB thread to be re-opened and continue any relevant discussion there, rather than dilute Realtime's very interesting thread. Certainly, I would like one of your revised Ortonview PCBs should they get to the point of availability.

It will be interesting to see if Realtime does detect any occasional memory corruption arising from the use of his VDU alternative. On Ortonview, the problem was only occurring on about one in every half million writes which made it rather hard to observe / catch in the act.
SiriusHardware is offline  
Old 13th Sep 2022, 5:38 pm   #35
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 vdu card

I've asked for the original Ortonview PCB thread to be re-opened so that we don't hijack Realtime's thread with Ortonview specific chat.
SiriusHardware is offline  
Old 13th Sep 2022, 5:55 pm   #36
Cobaltblue
Moderator
 
Cobaltblue's Avatar
 
Join Date: Dec 2010
Location: Exeter, Devon and Poole, Dorset UK.
Posts: 6,823
Default Re: Yet another MK14 vdu card

Thread re-opened as requested here.

https://www.vintage-radio.net/forum/....php?p=1454035

Cheers

MIke T
__________________
Invisible airwaves crackle with life or at least they used to
Mike T BVWS member.
www.cossor.co.uk
Cobaltblue is offline  
Old 14th Sep 2022, 6:49 pm   #37
Realtime
Hexode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 318
Default Re: Yet another MK14 vdu card

Thanks for the info on memory corruption testing. A bit distracted by work at the moment but I’ll give it a try at the weekend.
I’m also looking at generating syncs that fully conform to 625 line timing including equalising and broad pulses (properly interlaced) so it will work with modern digital TVs. It’s getting a bit tight on CPLD resources though.
Realtime is offline  
Old 17th Sep 2022, 1:17 am   #38
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 vdu card

Somthing I meant to ask about your VDU, one of the most useful signals on the original VDU was TOP PAGE which could be used in various ways-

Primarily, it was connected so as to toggle the state of one of the page select inputs so that the VDU rendered its output from two different 256-byte memory blocks, otherwise the same 256-byte block would be shown on the upper and lower halves of the screen.

It could also be applied to the inverse/normal input to make half of the screen inverse and half normal, or to the graphics / character mode input to show half of the screen as graphics and half as text.

Does your VDU generate a TOP PAGE output, can it be used in the ways described above as per the original VDU and Ortonview?
SiriusHardware is offline  
Old 18th Sep 2022, 4:26 pm   #39
Realtime
Hexode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 318
Default Re: Yet another MK14 vdu card

Quote:
Originally Posted by SiriusHardware View Post
Somthing I meant to ask about your VDU, one of the most useful signals on the original VDU was TOP PAGE which could be used in various ways

Does your VDU generate a TOP PAGE output, can it be used in the ways described above as per the original VDU and Ortonview?
Yes, it does generate TOPPAGE. It can be connected via the DIP switches to any or all of the following:
- to the INS8154 (Port A - 7) so MK14 can act on it
- to the Graphics / Character mode select line allowing half the screen to be graphics and half text
- to PS1 so that two adjacent memory blocks can be displayed.

This video I posted a few day's back shows the 2 memory banks and graphics / text switching. I haven't included the ability to control INVERT (ran out of DIP switches). I guess a wire link can be added if needed.
Realtime is offline  
Old 18th Sep 2022, 8:20 pm   #40
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 vdu card

TOP PAGE also eventually needs to be able to be connected to SWAP PAGES in case you want to swap over which halves of the screen are inverse/normal or which halves of the screen are graphics / characters.

Experience has taught us that where there is the possibility of TOP PAGE being connected to an 8154 port pin which might get into output mode somehow and fight with TOP PAGE, it is a good idea to have a modest resistor in series with the TOP PAGE output so that any voltage difference arising can fall across the resistor, reducing the likelihood of damage to the TOP PAGE output or to the corresponding 8154 port pin.

I think Tim(bucus) managed to take out the original 74L86 in his SOC VDU replica that way, hence his earlier interest in a substitute / clone of that IC.
SiriusHardware is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 6:23 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 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.