Mk14 vdu - Page 15 - UK Vintage Radio Repair and Restoration Discussion Forum

Slothie · 5th Oct 2020, 10:02 pm

It may be a long time before I get a SOC style VDU together but I can see myself putting together a Karen-style VDU card (Orten-view? TeleOrton? KOVDU?) since the hardware so far seems to be minimal. This project did make me wonder if one of the faster PIC chips could be employed to make an INS8154 substitute....

SiriusHardware · 5th Oct 2020, 10:09 pm

Post #174, this thread!

Slothie · 5th Oct 2020, 10:16 pm

Quote:

Originally Posted by SiriusHardware

Post #174, this thread!

Yes but given the instruction time with a 64MHz clock is 62nS I thought it mght be possible to simulate the RAM as well... Use a surface mount PIC and make a plug-in replacement DIP module. All depends on optimising the code to use interrrupts and as few instructions possible.

SiriusHardware · 5th Oct 2020, 10:29 pm

I actually expected that Karen meant emulation of the entire chip including the RAM, but I'm sure she won't mind if you take the job in hand.

For my original PIC-based demo PCB for the SOC VDU I used a PIC18F452 running at 10MHz quadrupled (so 40MHz) to emulate the RAM of an MK14 host system - it ran fast enough for the VDU to be able to read from it OK.

Slothie · 5th Oct 2020, 11:00 pm

Quote:

Originally Posted by SiriusHardware

I actually expected that Karen meant emulation of the entire chip including the RAM, but I'm sure she won't mind if you take the job in hand.

For my original PIC-based demo PCB for the SOC VDU I used a PIC18F452 running at 10MHz quadrupled (so 40MHz) to emulate the RAM of an MK14 host system - it ran fast enough for the VDU to be able to read from it OK.

I really cant wait to get my stuff back and build my issue VI. Then they'll be all this fun to be had. Till then I can hone my SC/MP programming skills on my PIC14 which by the end of the week should have a display....

Karen O · 6th Oct 2020, 9:27 am

I did consider trying to get a PIC to implement the I/O aspects of a RAMIO IC. There is a 'parallel slave port' facility of the larger PICs, which enable the PIC to be written to by a master. Trouble is, it's a single byte port with no address capture so the PIC wouldn't be able to determine which 'register' had been written to.

That's not to say we couldn't make something useful: single byte instructions would enable, say, 64 GPIOs to be set, cleared or toggled. It just wouldn't be an historical solution.

Karen O · 6th Oct 2020, 10:59 am

I've hit something of a show stopper. None of my PIC tools support the PIC16F887. I'm going to press ahead nonetheless.

Someone on this thread pointed to the data sheet for the character ROM IC used in the Mk14 VDU. I'd be grateful for a reminder.

Also, is there a finalised text/graphics binary that I can use for test purposes?

SiriusHardware · 6th Oct 2020, 11:13 am

I posted a binary of a VDU data testfile with details of its contents in #245, Phil__G was then kind enough to convert it to Intel Hex format which you can cut and paste from his post #253.

Karen O · 6th Oct 2020, 11:25 am

I can see only one way out of this predicament.

I will revert to using the PIC16F877 but I need to make two hardware changes: I must swap ports B and D so that the data bus uses the TTL compatible B port.

Really, the '887 only gives me one extra bit of I/O - the /MCLR pin is also port RE3 on the '887. On the '876 it is a straightforward master clear pin.

RE3 is used to sense PS4, so an input. Cunning plan: I use the serial port for video generation, but is only enabled on those scan lines that display text or graphics. During the frame blanking, when the PS4 state needs to be examined, the serial port is switched off. I can arrange that the clock output pin (RC6) is an input at this time and use this to sense PS4. I will couple through a resistor so that, when the serial port is enabled, the 2/4MHz coming out of RC6 doesn't try to drive PS4.

Does that sound like a plan?

SiriusHardware · 6th Oct 2020, 11:50 am

If it will make things go more smoothly I can 'loan' you my spare Pickit2, which does support the 16F887. You'd still need to make a little ICSP programming adaptor or include an ICSP header on your project.

As ever, you seem to have come up with a resourceful alternative, so if you prefer to go with the 877/A just let us know the specific detail of the wiring changes as and when you know it.

Doesn't this mean you'll have to rip up half of the wiring you've already done on your prototype? Let me know if you'd prefer to go the programmer route.

SiriusHardware · 6th Oct 2020, 11:53 am

For the character generator datasheet, a link to a databook containing it (and its position within that databook) is in post #127.

SiriusHardware · 6th Oct 2020, 12:26 pm

If you are looking to extract the character set into digital form, why not crowdsource it to us? Just let us know what order you need the character bytes in:

e.g,..

All bytes of character 0, then
All bytes of character 1, then
All bytes of character 2... etc,

or...

All the first bytes of characters 00-3F, then
All the second bytes of characters 00-3F, then
All the third bytes of characters 00-3F... etc.

You get the idea.

Slothie · 6th Oct 2020, 2:03 pm

Quote:

Originally Posted by SiriusHardware

Doesn't this mean you'll have to rip up half of the wiring you've already done on your prototype? Let me know if you'd prefer to go the programmer route.

I think the pinouts for the 2 chips are the same, just on the 887 MCLR can be used as an input on RE3

Karen O · 6th Oct 2020, 2:40 pm

I've swapped ports B and D so now port B is the data bus and port D is the lower address bus.

There's another issue I've noticed in going back to the '877 - RA4, which drives NRDS, is open collector. But the timing is very slow so I'll not worry about it. The original hardware drived NRDS in an open collector like manner, didn't it?

Slothie · 6th Oct 2020, 2:56 pm

Quote:

Originally Posted by Karen O

I've swapped ports B and D so now port B is the data bus and port D is the lower address bus.

There's another issue I've noticed in going back to the '877 - RA4, which drives NRDS, is open collector. But the timing is very slow so I'll not worry about it. The original hardware drived NRDS in an open collector like manner, didn't it?

Yes, but I recall Tim saying he had to provide a pull-up since the MK14 leaves it floating. 10k should do it.

SiriusHardware · 6th Oct 2020, 3:22 pm

The pullup on NRDS is an odd thing actually because if you look at the NRDS output on the VDU, it -is- pulled up on the VDU PCB. So why is an extra pullup needed elsewhere?

No idea.

You can call it good luck that RA4 happens to be open-collector since that's exactly what it needed to be, otherwise you were going to have to emulate an open collector output somehow.

Karen O · 6th Oct 2020, 3:54 pm

My original plan was to drive NRDS using bipolar drive (i.e. using a PIC GPIO configured as an output). I would ensure that it is high impedance when not needing access to the buses.

But it really doesn't matter...

I suppose being open collector saves on the discipline needed to disable NRDS.

I'm now programming an EPROM with the images that people kindly prepared.

I'm doing hardware first, partly to test code, but mostly so that the 'clean' work of programming the PIC is all that's left to do. If I have to go back in the hospice, then they'll probably tolerate PIC programmers, but not soldering irons!!!

SiriusHardware · 6th Oct 2020, 5:08 pm

Quote:

Originally Posted by Slothie

I think the pinouts for the 2 chips are the same, just on the 887 MCLR can be used as an input on RE3

I meant that she was also going to have to move all the connections originally going to port D0-D7 to port B0-B7, and all the connections originally going to Port B0-B7 to Port D0-D7, but there you go, she's already done it!

Slothie · 6th Oct 2020, 6:04 pm

Quote:

Originally Posted by SiriusHardware

Quote:

Originally Posted by Slothie

I think the pinouts for the 2 chips are the same, just on the 887 MCLR can be used as an input on RE3

I meant that she was also going to have to move all the connections originally going to port D0-D7 to port B0-B7, and all the connections originally going to Port B0-B7 to Port D0-D7, but there you go, she's already done it!

Ah yes I missed the "I must swap ports B and D so that the data bus uses the TTL compatible B port." bit

Karen O · 6th Oct 2020, 10:10 pm

Well I've had a thoroughly fruitless day trying to burn the image binary into a 2732. Nothing seemed to be going right for me - either the Dataman S3 complaining of a low battery (when it's powered from an external power supply). Many of the EPROMs of that size simply aren't listed in the algorithm list. Not much has me tearing at my hair roots, but this seemingly simple task has done just that.

I'm losing time on the firmware while I faff about with this: could I impose on one of our SC/MP fans to undertake this task for me? The code appears to be 2kbytes long so a 2716 will suffice. If the programmed device could be posted to me, I would be most grateful. It will of course be returned, along with the completed VDU.

Hex provided in post #253.

5th Oct 2020, 10:02 pm	#281
Slothie Octode Join Date: Apr 2018 Location: Newbury, Berkshire, UK. Posts: 1,287	Re: Mk14 vdu It may be a long time before I get a SOC style VDU together but I can see myself putting together a Karen-style VDU card (Orten-view? TeleOrton? KOVDU?) since the hardware so far seems to be minimal. This project did make me wonder if one of the faster PIC chips could be employed to make an INS8154 substitute....

5th Oct 2020, 10:09 pm	#282
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Mk14 vdu Post #174, this thread!

5th Oct 2020, 10:29 pm	#284
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Mk14 vdu I actually expected that Karen meant emulation of the entire chip including the RAM, but I'm sure she won't mind if you take the job in hand. For my original PIC-based demo PCB for the SOC VDU I used a PIC18F452 running at 10MHz quadrupled (so 40MHz) to emulate the RAM of an MK14 host system - it ran fast enough for the VDU to be able to read from it OK. Last edited by SiriusHardware; 5th Oct 2020 at 10:43 pm.

6th Oct 2020, 9:27 am	#286
Karen O Rest in Peace Join Date: Jul 2011 Location: Bridgnorth, Shropshire, UK. Posts: 787	Re: Mk14 vdu I did consider trying to get a PIC to implement the I/O aspects of a RAMIO IC. There is a 'parallel slave port' facility of the larger PICs, which enable the PIC to be written to by a master. Trouble is, it's a single byte port with no address capture so the PIC wouldn't be able to determine which 'register' had been written to. That's not to say we couldn't make something useful: single byte instructions would enable, say, 64 GPIOs to be set, cleared or toggled. It just wouldn't be an historical solution.

6th Oct 2020, 10:59 am	#287
Karen O Rest in Peace Join Date: Jul 2011 Location: Bridgnorth, Shropshire, UK. Posts: 787	Re: Mk14 vdu I've hit something of a show stopper. None of my PIC tools support the PIC16F887. I'm going to press ahead nonetheless. Someone on this thread pointed to the data sheet for the character ROM IC used in the Mk14 VDU. I'd be grateful for a reminder. Also, is there a finalised text/graphics binary that I can use for test purposes?

6th Oct 2020, 11:13 am	#288
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Mk14 vdu I posted a binary of a VDU data testfile with details of its contents in #245, Phil__G was then kind enough to convert it to Intel Hex format which you can cut and paste from his post #253.

6th Oct 2020, 11:25 am	#289
Karen O Rest in Peace Join Date: Jul 2011 Location: Bridgnorth, Shropshire, UK. Posts: 787	Re: Mk14 vdu I can see only one way out of this predicament. I will revert to using the PIC16F877 but I need to make two hardware changes: I must swap ports B and D so that the data bus uses the TTL compatible B port. Really, the '887 only gives me one extra bit of I/O - the /MCLR pin is also port RE3 on the '887. On the '876 it is a straightforward master clear pin. RE3 is used to sense PS4, so an input. Cunning plan: I use the serial port for video generation, but is only enabled on those scan lines that display text or graphics. During the frame blanking, when the PS4 state needs to be examined, the serial port is switched off. I can arrange that the clock output pin (RC6) is an input at this time and use this to sense PS4. I will couple through a resistor so that, when the serial port is enabled, the 2/4MHz coming out of RC6 doesn't try to drive PS4. Does that sound like a plan?

6th Oct 2020, 11:50 am	#290
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Mk14 vdu If it will make things go more smoothly I can 'loan' you my spare Pickit2, which does support the 16F887. You'd still need to make a little ICSP programming adaptor or include an ICSP header on your project. As ever, you seem to have come up with a resourceful alternative, so if you prefer to go with the 877/A just let us know the specific detail of the wiring changes as and when you know it. Doesn't this mean you'll have to rip up half of the wiring you've already done on your prototype? Let me know if you'd prefer to go the programmer route.

6th Oct 2020, 11:53 am	#291
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Mk14 vdu For the character generator datasheet, a link to a databook containing it (and its position within that databook) is in post #127.

6th Oct 2020, 12:26 pm	#292
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Mk14 vdu If you are looking to extract the character set into digital form, why not crowdsource it to us? Just let us know what order you need the character bytes in: e.g,.. All bytes of character 0, then All bytes of character 1, then All bytes of character 2... etc, or... All the first bytes of characters 00-3F, then All the second bytes of characters 00-3F, then All the third bytes of characters 00-3F... etc. You get the idea.

6th Oct 2020, 2:40 pm	#294
Karen O Rest in Peace Join Date: Jul 2011 Location: Bridgnorth, Shropshire, UK. Posts: 787	Re: Mk14 vdu I've swapped ports B and D so now port B is the data bus and port D is the lower address bus. There's another issue I've noticed in going back to the '877 - RA4, which drives NRDS, is open collector. But the timing is very slow so I'll not worry about it. The original hardware drived NRDS in an open collector like manner, didn't it?

6th Oct 2020, 3:22 pm	#296
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Mk14 vdu The pullup on NRDS is an odd thing actually because if you look at the NRDS output on the VDU, it -is- pulled up on the VDU PCB. So why is an extra pullup needed elsewhere? No idea. You can call it good luck that RA4 happens to be open-collector since that's exactly what it needed to be, otherwise you were going to have to emulate an open collector output somehow.

6th Oct 2020, 3:54 pm	#297
Karen O Rest in Peace Join Date: Jul 2011 Location: Bridgnorth, Shropshire, UK. Posts: 787	Re: Mk14 vdu My original plan was to drive NRDS using bipolar drive (i.e. using a PIC GPIO configured as an output). I would ensure that it is high impedance when not needing access to the buses. But it really doesn't matter... I suppose being open collector saves on the discipline needed to disable NRDS. I'm now programming an EPROM with the images that people kindly prepared. I'm doing hardware first, partly to test code, but mostly so that the 'clean' work of programming the PIC is all that's left to do. If I have to go back in the hospice, then they'll probably tolerate PIC programmers, but not soldering irons!!!

6th Oct 2020, 10:10 pm	#300
Karen O Rest in Peace Join Date: Jul 2011 Location: Bridgnorth, Shropshire, UK. Posts: 787	Re: Mk14 vdu Well I've had a thoroughly fruitless day trying to burn the image binary into a 2732. Nothing seemed to be going right for me - either the Dataman S3 complaining of a low battery (when it's powered from an external power supply). Many of the EPROMs of that size simply aren't listed in the algorithm list. Not much has me tearing at my hair roots, but this seemingly simple task has done just that. I'm losing time on the firmware while I faff about with this: could I impose on one of our SC/MP fans to undertake this task for me? The code appears to be 2kbytes long so a 2716 will suffice. If the programmed device could be posted to me, I would be most grateful. It will of course be returned, along with the completed VDU. Hex provided in post #253.