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 8th Oct 2020, 4:00 pm   #321
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Yes, amazing to see that familiar font being generated by something which is NOT a 40+ year old SOC VDU or a hardware replica of the same.
SiriusHardware is online now  
Old 8th Oct 2020, 7:50 pm   #322
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Indeed very impressive progress - let's hope the EPROM gets their pronto and I burned it correctly
Timbucus is offline  
Old 8th Oct 2020, 8:04 pm   #323
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

...and that I compiled it correctly. Gulp.
SiriusHardware is online now  
Old 8th Oct 2020, 9:19 pm   #324
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Good point, Slothie

I think I have an answer. I use two 16 character buffers in alternation (BUFA and BUFB).

My problem is seeing how one half (top half) can pre-charge BUFA ready for the start of the bottom half. But why share? How's about I use BUFA, BUFB for the top half, and BUFC, BUFD for the bottom half? That way I can pre-charge the lower half's data (i.e. BUFC) during the blanking period above the display.

It means code duplication (key routines are hard-coded to using a particular source, such is the cost of indirection).

I think this will work! It all seems rather obvious with the benefit of retro-ocular vision.
Karen O is offline  
Old 9th Oct 2020, 7:37 pm   #325
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Tim's EPROM arrived today and works great. Still progressing with the firmware...
Karen O is offline  
Old 9th Oct 2020, 8:13 pm   #326
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
Tim's EPROM arrived today and works great. Still progressing with the firmware...
Excellent news - it means mine will likely work when I try your firmware.
Timbucus is offline  
Old 9th Oct 2020, 9:21 pm   #327
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

I have rat's nested my DIN connector up to the PIC PCB according to the current version of the wiring scheme, invoked when the project reverted to using the 16F877.

I've swapped over port B / Port D, at the moment though I still have Page Select 4 going to RE3 (MCLR on 877) as I'm not quite sure what the new routing for the PS4 signal is. Apart from that I think it is ready to drop a programmed PIC into but I need to buzz it all out first.

One thing I will mention, the original wiring in the list in Karen's post #187 shows a number of lines pulled high with 10K resistors but not NRDS - I think this line will also need a pullup resistor somewhere since the RA4 output being used for NRDS out from the PIC-VDU is open-collector. The original VDU instructions say to add a pullup resistor to NRDS so I already have one on my MK14-to-VDU 'bridge' board.
SiriusHardware is online now  
Old 10th Oct 2020, 9:30 am   #328
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

SH, you are right (as always) on the need for a pull-up resistor on NRDS. In particular, I'm operating the VDU in host-less mode which means I can't rely on the Mk14's NRDS pull-up. So yes, a pull-up is required on pin 6 of the PIC. NENIN (pin 7) is always an output.

As for PS4: This was previously routed to pin 1 (RE3 on the '887). A pull-up is used on this signal. The revision for the '877 is quite simple. disconnect PS4 from pin 1 but leave the pull-up in place. This is our new /MCLR as per the '877.

Wire PS4 to a new pull-up. Now, we're going to feed this into RC6 (pin 25) as this pin is an input MOST OF THE TIME. Unfortunately, when the serial port is enabled for video pixel generation, this pin becomes an output with a 2/4 MHz square wave on it (actually, the serial port synchronous data clock).

To prevent PS4 being bombarded by clock signals, insert a series 10k between the pulled-up PS4 and pin 25.
Karen O is offline  
Old 10th Oct 2020, 9:39 am   #329
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Karen, thanks for that info. On my particular PCB that PIC pin was always dedicated as _MCLR because I originally built it for guess what, the 16F877 - so there is already the standard PIC reset circuit with the schottky diode, capacitor, resistor, etc on that pin.

I'll rearrange the PS4 arrangement accordingly. I'm unavoidably sidetracked for the rest of the day but will meter everything out tonight to try to have it 'firmware ready' by the end of the weekend.
SiriusHardware is online now  
Old 10th Oct 2020, 10:27 am   #330
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

No hurry, SH.

I've more or less completed the character mode aspects of the VDU but there's a way to go on the graphics aspect.

I'm hoping the graphics mode will be a breeze by comparison, since the dot clock is slower.
Karen O is offline  
Old 10th Oct 2020, 10:52 am   #331
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
No hurry, SH.

I've more or less completed the character mode aspects of the VDU but there's a way to go on the graphics aspect.

I'm hoping the graphics mode will be a breeze by comparison, since the dot clock is slower.
Sounds like you'll have this wrapped up in a moment! Next step - combine the VDU and PIC14 code to make a one chip MK14 + VDU chip !!
Slothie is offline  
Old 10th Oct 2020, 2:31 pm   #332
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Quote:
combine the VDU and PIC14 code to make a one chip MK14
I can confidently say that won't be happening any time soon

Attached is screenshot of Tim's EPROM text. The page top/swap system is implemented. It can also have distinct upper and lower inverse video state.

Graphics next. I do hope the lower pixel clock will ease things here
Attached Thumbnails
Click image for larger version

Name:	Photo0019.jpg
Views:	100
Size:	27.1 KB
ID:	217536  
Karen O is offline  
Old 10th Oct 2020, 4:28 pm   #333
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
NENIN (pin 7) is always an output..
Technically NENIN should be driven high by any requesting device and floating when not needed, but since on original MK14s it's tied low and there aren't any other MK14 peripherals that would use it that I know of then I suppose its not a problem. Either way, judicious insertion of a diode or resistor could fix that. On my Issue VI r1.3 boards the NENIN connection on the edge connector is pulled low with a 4k7 resistor.
Slothie is offline  
Old 10th Oct 2020, 7:41 pm   #334
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: Mk14 vdu

Quote:
Originally Posted by Slothie View Post
Quote:
Originally Posted by Karen O View Post
NENIN (pin 7) is always an output..
Technically NENIN should be driven high by any requesting device and floating when not needed, but since on original MK14s it's tied low and there aren't any other MK14 peripherals that would use it that I know of then I suppose its not a problem. Either way, judicious insertion of a diode or resistor could fix that. On my Issue VI r1.3 boards the NENIN connection on the edge connector is pulled low with a 4k7 resistor.
I don’t think NENIN should be allowed to float, I think it is a standard nmos input.

If connected to NBUSRQ then it should not be driven high as this might damage the NBUSRQ driver.

So I think it might be best if NENIN has pullup to Vcc, with link to 0v if the vdu is not fitted and a schottky diode from NENIN output of the PIC. This means the INS8060 would not run if the PIC is not connected but would avoid damage.
Mark1960 is offline  
Old 10th Oct 2020, 7:48 pm   #335
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by Mark1960 View Post
Quote:
Originally Posted by Slothie View Post
Quote:
Originally Posted by Karen O View Post
NENIN (pin 7) is always an output..
Technically NENIN should be driven high by any requesting device and floating when not needed, but since on original MK14s it's tied low and there aren't any other MK14 peripherals that would use it that I know of then I suppose its not a problem. Either way, judicious insertion of a diode or resistor could fix that. On my Issue VI r1.3 boards the NENIN connection on the edge connector is pulled low with a 4k7 resistor.
I don’t think NENIN should be allowed to float, I think it is a standard nmos input.

If connected to NBUSRQ then it should not be driven high as this might damage the NBUSRQ driver.

So I think it might be best if NENIN has pullup to Vcc, with link to 0v if the vdu is not fitted and a schottky diode from NENIN output of the PIC. This means the INS8060 would not run if the PIC is not connected but would avoid damage.
I was really talking in the context of the MK14, where NENIN is either tied to 0v or in the issue VI pulled low via a resistor. When modifying a issue V or lower you'd need to cut the track and fit a pull-down resistor to bring the NENIN signal to the edge connector.
Slothie is offline  
Old 10th Oct 2020, 7:55 pm   #336
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
Attached is screenshot of Tim's EPROM text.
Fantastic progress!

I'm glad that text turned out as intended, because I never had the opportunity to view it on my setup. It would have been a bit depressing if you were the first person ever to see it and it said 'Hradware and Frimwrae yb Kraen Ortno'.
SiriusHardware is online now  
Old 10th Oct 2020, 9:50 pm   #337
Phil__G
Octode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,078
Default Re: Mk14 vdu

Not Kraen Ortno the popular CIP progmarmer?

Interesting that its ascii-40h if its above (what, 40h?)

Last edited by Phil__G; 10th Oct 2020 at 9:57 pm.
Phil__G is offline  
Old 10th Oct 2020, 10:04 pm   #338
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by Phil__G View Post
Not Kraen Ortno the popular CIP progmarmer?

Interesting that its ascii-40h if its above (what, 40h?)
It certainly would have made more sense to make it ascii-20h for all characters, but the 70's were Wild West days and sensible wasn't always the obvious choice!
Slothie is offline  
Old 10th Oct 2020, 10:24 pm   #339
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

There is a (sort of) correlation between ASCII and the MK14 VDU's character set, such that it is not too difficult to 'transform' ASCII to text which can be displayed on the VDU.

Basically, you take the ASCII code and:

-if the ASCII code is > 0x7a (unsupported character), convert it to 0x3f (=?)

-if the ASCII code is 0x60 (also unsupported), convert it to 0x3f (=?)

-if the ASCII code is >=0x61 and <=0x7a, subtract 0x60 to convert to MK14 equivalent code

-If the ASCII code is >= 0x40 and <= 0x5f, subtract 0x40 to convert to MK14 equivalent code

-If the ASCII code does not fall within any of the above ranges, leave it unmodified as the MK14 code is the same as in standard ASCII.

As the MK14 VDU only has upper case characters, the above conversion 'formula' converts all alphabetic ASCII characters to upper case.

Quote:
Originally Posted by Phil__G
Not Kraen Ortno the popular CIP progmarmer?
The very same.

To be honest I deliberately did not view the test-text on my VDU because I wanted Karen to be the first person ever to read it - and that would only be possible if she managed to get the project working...

...which, of course, she has.
SiriusHardware is online now  
Old 10th Oct 2020, 11:55 pm   #340
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
There is a (sort of) correlation between ASCII and the MK14 VDU's character set, such that it is not too difficult to 'transform' ASCII to text which can be displayed on the VDU.

Basically, you take the ASCII code and:

-if the ASCII code is > 0x7a (unsupported character), convert it to 0x3f (=?)

-if the ASCII code is 0x60 (also unsupported), convert it to 0x3f (=?)

-if the ASCII code is >=0x61 and <=0x7a, subtract 0x60 to convert to MK14 equivalent code

-If the ASCII code is >= 0x40 and <= 0x5f, subtract 0x40 to convert to MK14 equivalent code

-If the ASCII code does not fall within any of the above ranges, leave it unmodified as the MK14 code is the same as in standard ASCII.

As the MK14 VDU only has upper case characters, the above conversion 'formula' converts all alphabetic ASCII characters to upper case.
Or if you didn't mind lower case getting mangled a bit you could subtract 0x20, AND with 0x3F then XOR with 0x20:
Code:
  |  0|  1|  2|  3|  4|  5|  6|  7
---+---+---+---+---+---+---+---+---
  0| @ | P |   | 0 | @ | P |   | 0 
---+---+---+---+---+---+---+---+---
  1| A | Q | ! | 1 | A | Q | ! | 1 
---+---+---+---+---+---+---+---+---
  2| B | R | " | 2 | B | R | " | 2 
---+---+---+---+---+---+---+---+---
  3| C | S | # | 3 | C | S | # | 3 
---+---+---+---+---+---+---+---+---
  4| D | T | $ | 4 | D | T | $ | 4 
---+---+---+---+---+---+---+---+---
  5| E | U | % | 5 | E | U | % | 5 
---+---+---+---+---+---+---+---+---
  6| F | V | & | 6 | F | V | & | 6 
---+---+---+---+---+---+---+---+---
  7| G | W | ' | 7 | G | W | ' | 7 
---+---+---+---+---+---+---+---+---
  8| H | X | ( | 8 | H | X | ( | 8 
---+---+---+---+---+---+---+---+---
  9| I | Y | ) | 9 | I | Y | ) | 9 
---+---+---+---+---+---+---+---+---
  a| J | Z | * | : | J | Z | * | : 
---+---+---+---+---+---+---+---+---
  b| K | [ | + | ; | K | [ | + | ; 
---+---+---+---+---+---+---+---+---
  c| L | \ | , | < | L | \ | , | < 
---+---+---+---+---+---+---+---+---
  d| M | ] | - | = | M | ] | - | = 
---+---+---+---+---+---+---+---+---
  e| N | ^ | . | > | N | ^ | . | > 
---+---+---+---+---+---+---+---+---
  f| O | _ | / | ? | O | _ | / | ? 
---+---+---+---+---+---+---+---+---

if __name__ == "__main__":
    SOC_FONT="""@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ !"#$%&'()*+,-./0123456789:;<=>?"""
    print ("   ",end='')
    for col in range(8):
        print("|%3x"%col,end='')
    print("\n---"+"+---"*8)
    for row in range(16):
        print("%3x"%row,end='')
        for col in range(8):
            ascii_chr = col*16 + row
            char = SOC_FONT[ ((ascii_chr - 0x20) & 0x3F) ^ 0x20 ]
            print("| %1s "%char,end='')
        print("\n---"+"+---"*8)
Slothie is offline  
Closed Thread

Thread Tools



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