Mk14 vdu
 

I know several people around here either have or may, at some point, be building a replica SOC VDU, as used with the MK14.

It took some finding, but here is what may currently be the only Youtube clip of an MK14 driving an MK14 VDU, unless of course anyone knows differently. (The MK14 is visible on the far right hand side of the video image).

https://www.youtube.com/watch?v=q8YG0hjRbZo

Re: Mk14 vdu
 

Thanks for that link, SH.

A few comments:

I had always assumed the Mk14 VDU display was 16 lines of 32 characters but it looks like it's 32 lines of 16 characters.

Is it a camera artefact or are odd lines and even lines displayed in separate fields?

Am I right in thinking this VDU uses DMA?

Re: Mk14 vdu
 

I suppose you could call it DMA - it uses the SC/MP's ability to go hands-off on the bus to take over the memory, scans 512 bytes of the 640 bytes total memory and renders the contents as either characters or pixels. The character mode layout is 16 across by 32 down, the character lines are really too close together for comfort with a very small vertical interval between the lines.

As to the rendering mode, I can't honestly say as I have never looked into it in that kind of detail. I'll attach the manual, which includes the circuit diagram, below.

There were various problems with it:

-When the VDU was active it stopped the SC/MP whenever the scanning dot was within the 'drawable' area of the screen - in other words, instead of halting the SC/MP for just long enough to read each byte of screen data, it would keep the CPU in the halt state whenever the 'dot' was within the drawable area, which slowed the system down a lot.

-It ate up most of the available RAM, leaving only 128 bytes in which to write an actual program.

-The MK14 standard 4.43Mhz crystal had to be changed to 4.00Mhz for the VDU, so software timing-critical programs such as 'Music Box' and 'Digital Clock' didn't run quite as well as before.

-No version of the MK14 ever had proper connections provided for connection of the VDU - issue IV and V had extra 'finger' connections on the track side of the rear edge connector but they still weren't actually wired to the buses, you had to do that yourself.

For all of the above reasons mine didn't stay connected to the MK14 for long, but around 2013 I found it languishing unloved in a drawer and took pity on it, connected it to a PIC programmed to emulate 512 bytes of RAM and powered it up, essentially just so that I could show it / see it working. (see attached image). The lines of text on that demo image are written to every other character line to leave a reasonable space between lines.

You may recognise the PIC PCB as a '44 pin demo' PCB, as supplied with some versions of the PicKit2 / PicKit3 programmers. The PIC is an 18F452. The 'metal can' oscillator is providing the 4.00Mhz clock which would normally be borrowed from the MK14.

Practical Electronics magazine were enthusiastic supporters of the MK14 and produced a superior VDU project for it - unfortunately I never saw one or came across anyone who had one.

Re: Mk14 vdu
 

Thanks, SH, I will have a look at that circuit.

I think it was inevitable that the SC/MP would be locked out for most of the while. I expect the worst case latency for bus acquisition corresponds to the longest instruction (ILD/DLD at 22 microsec). That's a third of a scan line, so the hardware didn't dare relinquish during rendering.

Re: Mk14 vdu
 

Actually, I hadn't thought that through, I'd always just assumed that the uP just went instantly off-bus with any ongoing action held in a static state. It never occurred to me that it might finish whatever it was doing before relinquishing the bus.

The VDU holds _RD low from the left edge of the 'drawable' area to the right edge of the 'drawable' area, which presents a problem for the PIC pretending to be RAM.

The very first "Read address from VDU / get data from that address in PIC RAM / Present data to VDU data bus" cycle is done on detection of the falling edge of _RD, but then the VDU just holds _RD low for the rest of the line, outputs the next address, reads, outputs the next address, reads, and so on until the end of the line where it releases _RD high.

With _RD staying low for the whole of the rest of the line, the PIC instead watches for changes of state of the VDU A0 line in order to know when to do the next read address / get data / offer data cycle.

Re: Mk14 vdu
 

Well, TBH I'm not sure what SC/MP behaviour is. I'm probably making assumptions - a multi-processor system needs semaphores, and you can't have those if instructions can be interrupted. But that's a guess. When I've gathered enough resolve I'll study the SC/MP data sheet to determine exactly how bus appropriation works!

Re: Mk14 vdu
 

I'm certain you're right, otherwise if the uP was halted in mid-action it would probably have to rewind to the start of the action. It would be much more logical for the uP to notice the request for the buses, finish what it is doing, release the buses and then signal that they are available.

Re: Mk14 vdu
 

Nice find on the Video Sirius - I wonder what the code does as it is not either of the SCIOS image (V1 or V2) copies that would be at 0200 - it does seem to be a primitive disassembler code listing tool running - and I am sure I have seen one of those in a magazine somewhere but, can't find it again.

Karen O - There is a good description on the multiprocessor function in the May 1979 Elektor in the article before NIBL-E:

http://https://www.americanradiohist...or-1979-05.pdf

Sheet 38 of the PDF - Page 5-34

I have all the parts now to make a VDU but, I really need to build an issue V board as my JMP Issue 1 will be harder to use with it because of the memory decoding and lack of solder pads on the lower side. The V5.5 board design from Slothie is promising in that regard with the actual routing for all the pins.

Re: Mk14 vdu
 

I have a feeling both the VDU and the MK14 in this case are Czech (Martin L) replicas so the ROM images will be absent. Perhaps it's being used with one of ML's RAM expansion / PROM to EEPROM converter daughterboards, as in here:-

http://www.8bity.cz/2018/science-of-...ram-expansion/

The page is in Czech but any browser will offer to translate it, or there are various flags to click on at the top of the right hand column. I know this has been mentioned before in related threads, it is included here again for anyone who comes looking for info relating specifically to the MK14 VDU.

One of these expansions would be an essential companion for the VDU, I'm sure that will have been his main motive for producing that add on - but of course it can only work with an issue V - real or replica, or with earlier issue machines which have been modified to remove the PROM images from 0200-07FF.

Re: Mk14 vdu
 

Just checked back on the video I linked to in post #1: The originator (Milan) has stated that he has now made a game running on the VDU, which he hopes to post a video of soon.

Maybe a few more positive comments on the original video clip will give him a bit of incentive?

Re: Mk14 vdu
 

And here it is! Roughly analagous to the 'Squash' game in the old AY-3-8500 based video games, or Breakout without the Bricks...

https://www.youtube.com/watch?v=2hLAX2UUdpk

Re: Mk14 vdu
 

Looking good - using the whole screen as well - I wonder if it is extra RAM or just the expansion 128 bytes - impressive if so. Anyway gave it a tweet to see if we can get some thumbs up!

Re: Mk14 vdu
 

As you may remember from his first video his MK14 - which he says is a replica, probably one of Martin L's Czech issue V replicas - appeared to have RAM at 0200, therefore probably 1.5K of additional RAM at 0200-07FF as well as the usual 640 byte RAM of a fully expanded MK14.

I guess he'll be using one of Martin L's extra-memory daughterboards, as mentioned in post #9.

Re: Mk14 vdu
 

Indeed you are correct it is hard to remember al the threads now!

Re: Mk14 vdu
 

Hi folks!
If anyone is interested in trying my new rel 5.5 PCB which was specifically designed to connect to the VDU board by the edge connector they are at https://bitbucket.org/IanKRolfe/mk14/src/master/ and https://bitbucket.org/IanKRolfe/kica...ib/src/master/ which are bitbucket git repositories for tje boatd and the libraries i have created for components not in the default libraries. They are for an older version of Kicad so if you have a more recent one you may need to fiddle with the library settings and/or ignore warnings about them.

I cant really help at this time because i am still languishing in hospital (although things are going well) and have no access to my laptop or the boards i had made. I did manage to retrieve the zipfile i uploaded to JLCPCB but my phone doesnt seem to like the attach file dialog here so i have put it as a download on the bitbucket mk14 repository. If you have any luck with it please tell me!

Re: Mk14 vdu
 

Hello Ian (Slothie), very nice to hear from you and thanks for thinking about us in your current situation. Glad to hear the sand is still flowing in the right direction.

I'll gladly take a look at the contents of the archive but I have never used Kicad or gone on to order PCBs made with it, so it may be a steep learning curve. No doubt Tim will be along presently, maybe the two of us can huddle together and sort out an order for some PCBs between us - you must have been reasonably confident that the design was good when you ordered your own PCBs.

I think we'll continue any further discussion about this in what was, after all, your thread concerning this very project, the 'MK14 Schematic Revisions' thread.

You were right to point out that your MK14 PCB design is unique in the way that it has all the signals required by the VDU routed to the rear edge connector.

Re: Mk14 vdu
 

Indeed good to hear you are going the right way - as you know I had a long stint in hospital as well so appreciate you taking the time to do this and understand your frustration with lack of access to your hobby! As Sirius says we will continue the thread on the PCB with progress so you enjoy it vicariously. As my main interest was to get my VDU board working this will be a great chance to push forward on that without hacking my JS one to bits!

Re: Mk14 vdu
 

Dont forget the XOUT signal got moved from 1 side of the board to the other so you will need to make a mod to the VDU card.

Re: Mk14 vdu
 

Thanks will do! I had forgotten

Re: Mk14 vdu
 

DM8678 emulator from 1978 National Semiconductor book that might be useful for people having yrpuble getting the character generator chip. The proms could be replaced by any EPROM 1024x8 or larger.

Re: Mk14 vdu
 

Certainly useful to have that information, although I find it hard to imagine anyone putting all of those components onto a daughter board which then plugs into the CG IC socket. Regarding the use of an EPROM to substitute for the original PROM, this is one of the rare cases where that might not work because of the high access speeds involved. Even by modern standards, Bipolar PROMs are still very fast compared to EPROMs.

Karen could probably replicate the whole SOC VDU with a single PIC chip if asked nicely. Direct video output from PICs is something of a speciality for her.

I've often wondered whether, when you're starting with no VDU, it might be better to recreate the PE (Practical Electronics) VDU for the MK14. I never studied it in detail because I already had the official SOC item but by all accounts the PE one was better thought out. I think, though I'm not sure, that it had its own onboard RAM.

Tim posted link after link to MK14 related items in magazines in old British electronics magazines hosted on the americanradiohistory website, I'm sure one of those will be pointing straight at the PE VDU article(s).

Re: Mk14 vdu
 

Yes, I knew Tim wouldn't have let me down.

PE October, November and December of 1978. The RAM module, constructed by stacking 2112 RAM ICs between rectangles of veroboard, would have to go and be replaced with a one-chip SRAM. It also uses a specialised CRTC IC, but not a common one like the 6845, so that could be a technological dead end.

Re: Mk14 vdu
 

Of not an original VDU I was going to try Grant Searles AVR based design which has it's own memory and is only a couple of chips. It can be building with 4 or 8 bit parallel interfaces and its also pretty high spec with different character sizes and graphics. It also has a PS/2 keyboard and serial interface optionally.
http://searle.x10host.com/MonitorKeyboard/index.html

I would have tried the PE design as it's more "period" but the CRTC chip seems to be unobtainable. Its possible theirs an equivalent device on a different number but I wasn't able to find one. The other option would be to.make a 6845 design adapted to the MK14 since I have several!

Re: Mk14 vdu
 

If you are really game for a challenge we could recreate the Display Circuit from the SCRUMPI 3 - two challenges met with one task... :) Just saying like. I paid for access to the Journal article where he describes how it works but, they did not supply the circuit diagram he mentions - I need to chase that up.

For those who remember the Pong video I had a reply from him and he confirmed he was using a RAM expansion - this thread has some nice pictures of the backplane he made to have an external RAM board and the VDU...

https://translate.google.co.uk/trans...78640%23p78640

Scroll up a bit to see the other photo as the link is direct to one of them half way through the thread.

Re: Mk14 vdu
 

Actually that would be a great idea, kill 2 birds with one stone, and the SCRUMPI 3 VDU would be age-appropriate on an MK14. I hope you can get the schematic because info on the SCRUMPI 3 is very scarce.

Re: Mk14 vdu
 

Well, to bring things up to date: Thanks to Slothie the world now has an MK14 replica PCB with all of the lines needed for the VDU already tracked to the rear edge connector, the first time this has ever been done.

Moving on, Tim had to muck about with the components on his replica VDU's composite output, but I didn't quite follow exactly what he did, so Tim, can you attach a sketch of what the composite output on your VDU now looks like - and is there still an issue with inverted (black text on white background) not looking right?

Re: Mk14 vdu
 

hello
for video output there are more schemat for zx80 or zx81 see
http://www.user.dccnet.com/wrigter/i...zxinverter.htm
Do you have the definitive version of the slothie pcb?

Re: Mk14 vdu
 

To make his TV / display work with the composite output from his 'Martin' replica VDU, Tim had to change some components around, so I was asking if he will post the changes he had to make, even if it is just a sketch with a pencil.

Tim and I have just built up two of Slothie's latest version of his PCB, see recent posts on this page of this thread:-

https://www.vintage-radio.net/forum/...145663&page=23

It appears to work very well.

Re: Mk14 vdu
 

Well as requested - the short story is here are the mods I did to get a nice clean composite on my Phillips CRT. Basically the manual BOM has to have R9 and R7 changed and the omitted R6 needs to be installed - C10 is still omitted.

Attachment 207417Attachment 207415

Note that I was unable to tune the modulator - I have since swapped it for another and still cannot on either my Phillips or my period Sony - the latter does give a poor picture.

Attachment 207414

It is possible I need to revert the component values to allow the use of the modulator - I was unable to find its DataSheet UM1233 but, maybe it needs the near 5v p2p that the system was putting out that was blanking my usual desktop CRT. Martin has said that his LCD works with the original values on composite - it does not seem to mind the higher voltages.

The composite image on my Phillips is great though!

For completeness of mods done: I have bent up b27 (as that would short the clock to a GND on the b side so a wire patch underneath (tiny one, one pad down from the resistor) takes it to XOUT on the 'a' side where it comes from the MK14.

The resistor is for the pullup for NWDS which is mentioned in the VDU Manual as needing to be done on the MK14 - note that changes to NENIN have already been done on the Slothie V6 board - you would need to do those on a real one or the JMP/Martin clones along with the pullup. I did it on the clone VDU as it is removed when I unplug it.

Attachment 207416Attachment 207418

Finally the two white wires (and the associated bent up pins, move b13 the VDU ON/OFF from connecting to PA0 on the INS8154 I/O chip to FLAG1 (on pin b1) as recommended in the manual - I prefer this as you can turn it on and off (which you need to do to use cassette or a KeyProgrammer) still without an IO chip (I have used patch wires in its socket to pull the relevant pins up and down) - and it is canon from the manual - I may well hook my Graphics/Chars (b14) over to Flag2 for a similar reason.

The other wire is the Reverse Pages pin which I move from INTR (an input to the IO chip) onto PA3 which can be an output.

My next step will be to make a neat 8154 plug in module with some switches for the other lines and try my actual 8154 to change things within a program.

Re: Mk14 vdu
 

I should have mentioned that inverting the signal to black on white creates a useless image - I assume it has the same problem as the early ZX81 that there is no Back Porch on the signal to set the White level. I may investigate adapting one of the (555 based) ZX81 fixes.

http://zx.zigg.net/misc-projects/ZX8...nditioning.pdf

Re: Mk14 vdu
 

Thanks for the info - I believe it is a fact that the composite output circuit ideally needs to be distinctly different depending on whether you are driving a UM1233 modulator (as per original) or composite video directly, for one thing a composite video input on a TV or display typically has a rather low termination resistance of 75R.

If you followed any of John Erland's adventures in his ZX81 thread you may have noticed that his replacement 'ULA IC' even had selectable output modes, depending on whether it was going to output to a modulator or output direct composite video.

Both of those conditioning circuits look as though they could be built inside the empty shell of a UM1233 modulator, with the 'UHF out' connector then becoming composite-out.

Re: Mk14 vdu
 

Well I had to know so I did a temp patch back to the VDU manual values... (yes its messy):

Attachment 207432

anyway now I still get a composite image on the Phillips (as the Modulator is also in circuit I assume it drops the levels a bit) although it did blank on me once or twice. Inverse is still junk.

UHF is awful though

Attachment 207433

But, the Sony can now get a stable picture in both Graphics and Text - although you have to twiddle the horiz. hold every time you turn the MK14 on or off.

Attachment 207439Attachment 207440

So for those who were observant on the rubbish picture above no surprises here:

https://www.youtube.com/watch?v=vtL2yKEOh74

Re: Mk14 vdu
 

Brilliant!

Re: Mk14 vdu
 

Wow, the old 'Falling Man' demo... I have not seen that running since about 1979. That's also the first time I have actually seen the uploader being used anywhere else so that was interesting for me too.

If you suspect a possible problem with the modulator (where did it come from?) forum user 'electroanorak' mentioned in another recent thread that he has a few NOS ones.

Re: Mk14 vdu
 

I do not think the modulator is (or was) faulty (I had already swapped it) it is simply the lack of Back Porch that makes Black on white unusable (and of course the perfect values for a NO modulator fitted board that stopped it working probably). So the original was probably OK but, I switched it for one on a Spectrum Issue 2 I know is good, that has had a wire Composite bypass (which I reversed) so does not need a working one if the original indeed proves faulty.

Anyway tonight I miniaturised my INS8154 eliminator allowing a switch for Graphics/Text and for Invert video anyway to experiment - I have one spare switch I can use to vary something else (the green one)...

Attachment 207590

For those who wish to repeat the demo from the video here is the FallingMan as far as I have got - I am intending to replace the jumbled man bits above the horizontal line with a picture or the text Falling Man - 1979 if I can work out the bit pattern....

(just delete the .TXT and restore the last three chars for the file extension)

Attachment 207591

Attachment 207592

Re: Mk14 vdu
 

Thanks, I was hoping you'd have that handy. It will be a few more days before I get mine connected, but it will be good to have something to fire into it straight away when I'm ready. When I last ran that about... 41 years ago, I had just typed it all in by hand.

You seem to be having fun with that. I still plan to use the actual 8154 to control the VDU initially, just because it's already there.

Re: Mk14 vdu
 

Great - when you have worked out the initial settings to get it to display something I can steal them and put mine in! I just wanted to get rid of the breadboard as it was awkward and a ten minute job turned into a major event...

Re: Mk14 vdu
 

Just a word of caution - try testing the voltages after the VDU is hooked up on the expansion bus on PA0-PA7 BEFORE you plug in the 8154 - I was getting readings around 6v and could not control text/graphics mode using PA6 by writing bits to it after setting it to an output port. Maybe we have to sink too much using the IO/chip alone if they are normally high - some study needed of the circuit I think.

It might be worth on your little conversion device having a set of links that can be made or broken for each PA0 connection - I need to look into what is happening - hoping I have not done any damage to my only 8154! The eliminator will be back in for the moment.

I have also found a flaw in our 1:1 mapping - hooking the "top page" line b17 to PB0 as an input is great to sense in software (in theory) when you are there but, you also need to link it over to b11 on PA1 so that the VDU board auto swaps the memory page to display both pages - that cannot be done fast enough in software.

I started down this road typing the Charset demo from the manual which 'only' needs the I/O chip to execute from so though what the hell and plugged it in and started using your trick of just writing to the 0800 areas after setting 0822 to 1...

I did this as Sirius asked if the char set was the same. Anyway more updates later in the week.

Actually I am getting high readings >7v on SIN and SENSE_A and other lines when my VDU is hooked up with no INS8154 - I wonder if something is coming back in that should not... I will have to take a serious look at the connections - especially if it is coming through the SC/MP!

Re: Mk14 vdu
 

I would view 7V anywhere east of the regulators with a great deal of alarm! I was actually already thinking of replacing one of the many decoupling capacitors with a 5.6V zener so that in the event of regulator failure (short from input to output) the zener would at least limit the voltage and more likely fail s/c, which would be bad news for the zener but would hopefully save everything else.

What's the actual supply voltage to the chip supply pins on the VDU? It's possible, I suppose, that somehow the unregulated input has found its way to the +5V - out terminal on the edge connector. Always remember, this was a previously untested PCB so you have to consider things you wouldn't normally consider.

I was aware of the likely problem with 'top page' usually needing to be connected to one of the address select lines in order for the VDU to display two different 256-byte blocks.

Re: Mk14 vdu
 

On a different note, I've been reading the articles in PE on their VDU project and it looks interesting. It uses a Thompson SFF96364 CRTC which when I looked at it last year seemed unobtainable, but now I see Littlediode advertising on eBay. It's an odd design but has some interesting features, including a RF modulator with inductors and transformer printed on the PCB layout. It has its own 1k of RAM that you could map to 400-7FF and a few control lines that could be connected to the 8154. The RAM is 8 2102 memory chips soldered between two pieces of veroboard to form a memory module that is connected by wires to points on the PCB. This memory chip is unusual in that it has separate inputs and outputs - modifying the circuit to use more easily obtainable ICs might be an interesting project.
Just need to get my stuff back so I can start clearing my backlog of projects!

Re: Mk14 vdu
 

Do you mean the memory ICs are dual-port? I have here an IDT7132 IC which is a 2K dual-port RAM IC, (48 pin DIP!). That was my original ambition, to put that between the MK14 and the VDU so that the VDU could scan and display the RAM contents without stopping the MK14 system, which would therefore continue to run at normal speed.

https://www.idt.com/eu/en/document/dst/713242-datasheet

Re: Mk14 vdu
 

No, the 2102 only had 1 set of address and control lines, but separate data in and data out. I recall that 8 bit S-100 cards had separate data in and data out paths, so there must have been some good reason for it. Without looking into it too hard, I imagine the changes required to the circuit to use, say 2114 RAM would be to use a bidirectional buffer instead of the two unidirectional buffers.

Although I do like the idea of using dual port RAM on the SOC VDU, it would allow running the MK14 at "full" speed rather than 4mHz.

Re: Mk14 vdu
 

Should you want to build this and use 2102s I have, I think, 16 of them I bought many years ago for a project which never got built.

Keith

Re: Mk14 vdu
 

If you do come across them then PM me with a price. Don't feel you need to hurry as it'll be a while before I'm reunited with my soldering iron!

Re: Mk14 vdu
 

Will do.

Keith

Re: Mk14 vdu
 

A number of the high-speed (45ns or less access time) 1-bit wide bipolar RAMs had separate Data In and Data Out pins. I've just been working on a device that uses a couple of the Hitachi HM6147, for example (4K*1 bit).

As an aside, I once built a colour (TTL RGB output) video display board using 3 standard ICs, and which needs 2 TTL signals from the processor (bidirectional, open collector driven). While it wouldn't be compatible with the SoC VDU board, it could certainly be hung off an MK14, you might even be able to use the flag and sense pins on the processor. The ICs were :

74LS04 (6MHz clock oscillator and a bit of buffering)
6264 (RAM, actually all you need is 1K*8, but the 6264 is common enough)
SAA5243 (yes, the teletext IC. You can read/write the video memory over the I2C bus you see...)

Re: Mk14 vdu
 

A nice idea, I bet those TT ICs were made in such large quantities that there will still be a good few around today.

It might be easier to bit-bang I2C with the 8154 ports because I2C uses the same line for data in and out, therefore you ideally need a single pin which can be both input and output.

You can simulate the open-collector nature of an I2C driver by writing a '0' to the 8154 data output latch and then control the line by changing the direction of the port pin - in output mode it will drive the SDA line low, and in input mode it will release the SDA line, which is always pulled up by a resistor, high.

Re: Mk14 vdu
 

That's certainly interesting. I think I have a teletext chip somewhere, part of a lot of random ICs I got from eBay years ago. Could probably be knocked up on protoboard fairly quickly.

Re: Mk14 vdu
 

You need one of the later Philips 'Computer Controlled Teletext' ICs in the SAA5240 series. Those let you read/write the memory over the I2C bus. Doing it with the older SAA50x0 series chips is a lot of work!


Yes, it's easier to simulate the I2C bus using the 8154, but that chip is getting hard to find. You can get away with a couple of diodes (to turn totem pole outputs into open collector ones) and pull up resistors. From what I remember you don't need to sense the SCL signal (just drive it) in a simple application like this so you could use a couple of the SC/MP flag outputs to drive the lines (via the diodes) and monitor SDA using the Sense B input or something like that.

At one time Philips produced a user manual for the SAA5243 which included a lot of useful information not in the data sheet. I have no idea where you'd get it now.

Re: Mk14 vdu
 

Just looked around, the SAA5240 is available quite cheaply in some quarters, one supplier in Ireland has them at around £2.00 although I happen to know from experience that supplier has quite a high minimum-order threshold. Still, they are available.