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 17th Aug 2020, 7:04 pm   #161
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by Slothie View Post
I've been looking at this, the pinouts of the 74L86 and 74LS86 are different, true, but the bigger issue is that the 74L86 has a propagation delay 4 times higher than the LS variant (60ns rather than 14ns) and Im trying to see if the (lack of) delay will cause problems - fortunately the gates are mostly connected to the higher order outputs of the counter where the frequencies are lower and therefore delays likely to cause fewer problems. However two gates are wired as buffers (with one input grounded) so they must have wanted the delay for something..
Interesting maybe I can make up one on a little vero and swap it out - empirical testing...
Timbucus is offline  
Old 17th Aug 2020, 7:11 pm   #162
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Incidentally, let's not forget that there is the possibility of a one-chip VDU from Karen at some point. I have great faith in Karen.
SiriusHardware is online now  
Old 17th Aug 2020, 7:45 pm   #163
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Oh yes I'm still looking forward to that; Its going to be really a good add-on.
I made a checkerboard pattern generator with a PIC 16F384 (I think) a few years back, cycle counting and generating the correct interlaced scan sync pulses; it was quite a challenge but to actually output character based video,,,,
I only got the character generator because I might want to build it into one of several I designs I have seen that use the NatSem character generators. I have (in storage ) several different CRTC chips and I'd like to try out them and other options (like the teletext chips mentioned elsewhere). Its something that has interested me for some time, not sure why!
I would have taken Buzby up on his offer if I thought I'd be able to get round to doing anything with them in the near(ish) future, but until I know what my housing situation is going to be then it would be wrong to take them off him.
Slothie is offline  
Old 17th Aug 2020, 7:54 pm   #164
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Quote:
Originally Posted by Slothie View Post
I made a checkerboard pattern generator with a PIC 16F384 (I think) a few years back, cycle counting and generating the correct interlaced scan sync pulses; it was quite a challenge but to actually output character based video
I think Karen's 'trick' with video output is usually, perhaps not always, to use the onboard UART to generate the pixel bitstream.
SiriusHardware is online now  
Old 30th Aug 2020, 7:29 pm   #165
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

SH is absolutely right! PIC's generally have two types of serial port: an SPI port and a conventional UART-type serial port. I usually use the latter in synchronous mode because it is capable of back-to-back transfers i.e. no gaps. I have used the SPI port for generating video on occasions, but you have to tolerate gaps and wide spacing of characters.

The bigger challenge is use of table look-up or program flash reads to do font generation. The whole process can be done in 8 cycles, which is enough to avoid gaps.

The characters on the Mk14 VDU are quite widely spaced, however graphics mode needs back-to-back transfers to ensure a continuous row of pixels.
Karen O is offline  
Old 30th Aug 2020, 8:33 pm   #166
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Hi Karen,

I suppose the autonomous nature of the UART is what makes this possible, you give it something to do and it just gets on and does it, for the duration of 8 character pixels or 8 graphics pixels. In the meantime, the CPU can forage around for the data for the next 8 pixels to load into the UART.

Did you notice what we discovered (in the 'MK14 revisions' thread) about the alternative IM6... RAMs which can be fitted in Ian's repro MK14 PCB? - although they work fine in the standalone machine they don't work with the original VDU because of the rather hokey way in which the original VDU keeps NRDS low while it reads a whole line's worth of data. The address latches on the IM6.. RAMs are edge triggered rather than level triggered so the RAM needs there to be a proper NRDS active-low pulse for each individual byte read from it.

This is therefore one improvement your project could make over the original, generate a proper momentary low _NRDS pulse on each byte read from the MK14 RAM so that it will work with an MK14 fitted with either the original 2111/9111 type or the alternative IM6.... type.
SiriusHardware is online now  
Old 30th Aug 2020, 9:09 pm   #167
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Thanks for mentioning this, SH. I can't see a problem - I can flap NRDS up and down to avoid this issue.
Karen O is offline  
Old 31st Aug 2020, 9:32 am   #168
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

I remember that you were intending to pre-read all the data for one line in a 'burst' in the time period between the sync pulse and the point where the VDU starts rendering the pixel data to screen, or at least that was my understanding. (During the 'black' period between the left edge of the screen and the beginning of the 'active' area on which the VDU 'draws').

I wasn't sure if the additional overhead involved in changing the NRDS state twice for each read from RAM would consume too much of that time.
SiriusHardware is online now  
Old 31st Aug 2020, 9:54 am   #169
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

It has occurred to me that if anyone did have an MK14 issue VI with IM61X65 RAMs and an original or replica SOC VDU, one other way around this is to add more offboard RAM such as a 6116 + address decoder into the memory hole at 0200-07FF, and point the VDU at that.

The VDU would then be rendering from the 6116 which does not have the edge triggered operation that the onboard IM65X61 does, so that would work OK.

If you want to use the VDU for any practical purpose, it really needs to have its own dedicated run of 512 bytes of memory anyway.
SiriusHardware is online now  
Old 31st Aug 2020, 9:56 am   #170
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
SH is absolutely right! PIC's generally have two types of serial port: an SPI port and a conventional UART-type serial port. I usually use the latter in synchronous mode because it is capable of back-to-back transfers i.e. no gaps. I have used the SPI port for generating video on occasions, but you have to tolerate gaps and wide spacing of characters.

The bigger challenge is use of table look-up or program flash reads to do font generation. The whole process can be done in 8 cycles, which is enough to avoid gaps.

The characters on the Mk14 VDU are quite widely spaced, however graphics mode needs back-to-back transfers to ensure a continuous row of pixels.
The 'traditional' way with an AVR is to use SPI and indeed you get an "extra" white bar between characters (or a dark bar if you invert the SPI output) which isnt always desirable, so its interesting to hear the UART can be used in a synchrounous mode.
Slothie is offline  
Old 31st Aug 2020, 10:42 am   #171
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

I read an article not long ago but I cannot find it again where someone had repurposed the video output of I think a BBC to generate fast enough continuous streams of data to directly write floppy tracks to recreate random sector errors used in floppy protection systems BITD. Another good example of abusing Serial shift registers in other devices for alternative purposes...
Timbucus is offline  
Old 31st Aug 2020, 12:55 pm   #172
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

The COSMAC Elf - a computer of similar size and capability to the Mk14 - developed a tradition around its VDU: CHIP8.

As far as I know this had no parallel with the Mk14. Any ideas why? I'm guessing that there was just too little program space in the Mk14...?

Maybe it's time to implement something similar to CHIP8 for the Mk14?
Karen O is offline  
Old 31st Aug 2020, 2:49 pm   #173
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

In the "SoC Further Applications Programs" booklet from David Johnson-Davies for the MK14 there are two things along these lines - the MINIL program interpreter (which he has continued to expand and do things with http://www.technoblogy.com/show?283C) and also a way to use the unused 20 2F instruction codes with a bit of addon hardware.

I was lucky enough to get a PDF copy of the book direct from him when I was looking at similar minimal languages like the ICL CESIL etc. although it is not available online anywhere. I must get around to finish typing in the program and running it on the MK14.
Timbucus is offline  
Old 31st Aug 2020, 5:49 pm   #174
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Another thing I plan to look into is whether a PIC can implement the IO portion of a RAMIO chip. That would result in a comprehensive modern emulation of a fully expanded Mk14.
Karen O is offline  
Old 1st Sep 2020, 12:56 am   #175
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

I remember noticing that some of those 40-pin PICs have an optional special mode on one 8-bit port (Port D?) which can simplify making the PIC look / act like an on-bus peripheral IC.

When that special mode of Port D is enabled, the PORT E pins become _RD, _WD and _CE signals, where the latter signals are 'special functions' of the Port E pins. I can't remember if there is also provision for an A0 or 'register select' or 'Command / Data' pin on Port E as well.

I've never tried to use that Port D / Port E 'peripheral mode' myself.
SiriusHardware is online now  
Old 1st Sep 2020, 10:43 am   #176
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Parallel slave port?

Yes that might be useful.

I tried to use that in simultaneous bidirectional mode once and encountered funnies (losing data). I don't think reads and writes are fully independent.
Karen O is offline  
Old 2nd Sep 2020, 9:02 pm   #177
coolsnaz2
Tetrode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 86
Default Re: Mk14 vdu

I have an Mk14 issue V with VDU card issue 2, both are still working. Attach photos show how I connected the Mk14 to the VDU card.
I had to use an old VCR machine to tune into UHF signal from the VDU card.
Attached Thumbnails
Click image for larger version

Name:	20200829_131704.jpg
Views:	96
Size:	84.7 KB
ID:	214821   Click image for larger version

Name:	20200829_131803.jpg
Views:	98
Size:	75.0 KB
ID:	214822   Click image for larger version

Name:	20200829_140500.jpg
Views:	99
Size:	75.2 KB
ID:	214823   Click image for larger version

Name:	20200829_140511.jpg
Views:	98
Size:	72.4 KB
ID:	214824   Click image for larger version

Name:	20200901_220118.jpg
Views:	98
Size:	99.2 KB
ID:	214825  

coolsnaz2 is offline  
Old 3rd Sep 2020, 1:12 pm   #178
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Thanks for posting the pictures of the VDU and modified MK14, pictures of these old devices are rare and its always nice to see new ones; eack MK14 is special in its own way because of the modifications put in by its owner.
Slothie is offline  
Old 3rd Sep 2020, 4:42 pm   #179
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Ah, issue V, lucky man. The final and most desirable original MK14 version.

Only issue IV and issue V had the contacts on the underside of the rear edge connector, which you have taken the ribbon cables to. Nice to see it all working, neat trick using the VCR as a UHF-to-composite converter.
SiriusHardware is online now  
Old 3rd Sep 2020, 5:44 pm   #180
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Forgot to mention - I have had some success with just tapping the video off from the input to the modulator and taking it straight to the composite input on my Philips CVBS / RGB video monitor.

Your mileage may vary, depending on how well your TV / display takes to the VDU's rather crude video output. Flatscreens appear generally less tolerant of imperfectly formed video signals than CRTs are.
SiriusHardware is online now  
Closed Thread

Thread Tools



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