8th Oct 2020, 4:00 pm | #321 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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.
|
8th Oct 2020, 7:50 pm | #322 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Indeed very impressive progress - let's hope the EPROM gets their pronto and I burned it correctly
|
8th Oct 2020, 8:04 pm | #323 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Mk14 vdu
...and that I compiled it correctly. Gulp.
|
8th Oct 2020, 9:19 pm | #324 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
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. |
9th Oct 2020, 7:37 pm | #325 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Tim's EPROM arrived today and works great. Still progressing with the firmware...
|
9th Oct 2020, 8:13 pm | #326 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
|
9th Oct 2020, 9:21 pm | #327 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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. |
10th Oct 2020, 9:30 am | #328 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
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. |
10th Oct 2020, 9:39 am | #329 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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. |
10th Oct 2020, 10:27 am | #330 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
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. |
10th Oct 2020, 10:52 am | #331 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
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 !!
|
10th Oct 2020, 2:31 pm | #332 | |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Quote:
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 |
|
10th Oct 2020, 4:28 pm | #333 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
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.
|
10th Oct 2020, 7:41 pm | #334 | |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
|
Re: Mk14 vdu
Quote:
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. |
|
10th Oct 2020, 7:48 pm | #335 | ||
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Quote:
|
||
10th Oct 2020, 7:55 pm | #336 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Mk14 vdu
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'. |
10th Oct 2020, 9:50 pm | #337 |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,078
|
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. |
10th Oct 2020, 10:04 pm | #338 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
|
10th Oct 2020, 10:24 pm | #339 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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:
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. |
|
10th Oct 2020, 11:55 pm | #340 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Quote:
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) |
|