UK Vintage Radio Repair and Restoration Discussion Forum

UK Vintage Radio Repair and Restoration Discussion Forum (https://www.vintage-radio.net/forum/index.php)
-   Vintage Computers (https://www.vintage-radio.net/forum/forumdisplay.php?f=16)
-   -   MK14 schematic revisions (https://www.vintage-radio.net/forum/showthread.php?t=145663)

SiriusHardware 2nd Apr 2019 12:23 am

Re: MK14 schematic revisions
 
OK, let us know how you get on. (As a new forum member your posts are currently subject to new user moderation / delay. After a few more posts that will wear off and you will be able to post in real time).

The connectors I currently have on my MK14 (rear edge and keypad connector) were bought around 2012 from RS, and are both exactly the right length, single sided with no keyway - it's almost as though they originally stocked them with the MK14 in mind and still had some stock left all that time later.

I'm not sure if they still do them now though, and even if they do, they were tremendously expensive 6-7 years ago, never mind now.

Edit: On a quick look, they still do the 32-way version - note that although it looks double sided in the illustration the upper and lower contacts are paired so there are only 32 pins sticking out of the rear of the connnector. Not so useful for those of you who have late issue MK14s which do have double sided rear edge connectors. Here they are - the keys in the outer ends (position 0 and 33) are removable.

https://uk.rs-online.com/web/p/edge-connectors/0466551

... but look at the price! They might even still do the 16 way one as well, I did not look that far.

Timbucus 2nd Apr 2019 7:59 pm

Re: MK14 schematic revisions
 
Nice looking connectors, but, not so nice on the price. I again was lucky as I had a 80 way that I cut down to make the one in the photograph. That leaves enough for another one as well - aren't junk boxes great - my Dad was a real hoarder as well so I have the benefit of over 60 years of useful electrical bits - I think I may dispose of the Capacitors though as they were cheap bags in the late 70's... Some of the bigger ones look too cool so maybe I will keep them for decorations.

Also I finally have the MK14 board fully populated and the CPU etc arrived with REAL DM chips - no idea if they are blank so I think a PM to Mr SirusHardware is in order to a) take a look and b) program them if so. If not I wonder what is on there?

SiriusHardware 2nd Apr 2019 9:17 pm

Re: MK14 schematic revisions
 
Yes, I got your PM, you have one by way of return. Let's hope those devices are both genuine and blank.

Timbucus 2nd Apr 2019 10:08 pm

Re: MK14 schematic revisions
 
Indeed let's hope they are genuine and blank, they are marked (and from what seems to be a professional source) DM74S571N so will be winging their way to you. Thank you very much!

SiriusHardware 9th Apr 2019 6:59 pm

Re: MK14 schematic revisions
 
(Keeping the more general MK14 related questions in this thread).

Timbucus: regarding your suspected faulty INS8154, RAM/IO IC, how did you come to that conclusion?

The RAM/IO has three 'images' in memory at 0800 onwards, 0C00 onwards and 0E00 onwards. For the purposes of this, let's stick with the one at 0800 onwards.

The 128-byte RAM portion of the device is mapped into the upper half of the 256-byte block occupied by the RAM/IO, therefore at 0880-08FF. You should find that data entered anywhere within that address range will 'stick'.

If you tried it out by editing addresses low down in the RAM/IO block and expecting them to read back the same, 0800 - 0824 are the control / data registers etc of the I/O portion of the device, so writing to those locations and then looking at them would give unexpected results.

Addresses 0x0825-0x087F do not (officially) have any hardware associated with them, so anything written to that range would be lost.

SiriusHardware 9th Apr 2019 8:12 pm

Re: MK14 schematic revisions
 
A quick test for the I/O section of the INS8154 IC just using the monitor - assuming the new / improved monitor is in use.

First,

Code:

Abort
0 8 2 3
Term
F F
Mem

You won't see the data digits change, but doing this writes FF to the port 'B' data direction register to define all of the port B pins as outputs.

Then,

Code:

Abort
0 8 2 1
Term
5 5
Mem

This time, you will see the data digits change. This writes the pattern 01010101 to the port pins 0-7 of port B. You should be able to verify this with a meter, scope or logic probe.

Finally,
Code:

Abort
0 8 2 1
Term
A A
Mem

Should write the pattern 10101010 to bits 0-7 of port B.

I chose port B for this because the port pins 0 through to 4 appear in a sensible order on the edge connector. The port A pins are all over the place.

Timbucus 9th Apr 2019 9:44 pm

Re: MK14 schematic revisions
 
Well I just got in from dinner and was going to slob - saw your messages and went DUH as I had tried lots of addresses in 0800 for 128 bytes- didn’t notice the 0880 thanks - works fine and I can toggle the io port B lines fine with your script according to a meter - appreciate the help can’t believe I was so dull... and I didn’t even need to turn on my PC as I had printed out lots of useful diagrams and sheets for the MK14 so had the pinout.

SiriusHardware 9th Apr 2019 9:47 pm

Re: MK14 schematic revisions
 
One less problem. ;)

Timbucus 9th Apr 2019 10:05 pm

Re: MK14 schematic revisions
 
Indeed thanks again for the pointers - I also added my last two RAM chips and they seem to work so I have a full 640 bytes, almost as much as my first kit built machine the ZX81... I can try segtris now yay!

Timbucus 11th Apr 2019 2:16 pm

Re: MK14 schematic revisions
 
I have discovered why I thought the 128 byte IO RAM is at 0800 - it seems the memory map (which I have been using) on the online emulator is wrong...

http://www.dougrice.plus.com/dev/seg_mk14.htm

I cannot get the virtual machine to respond well enough to test if it actually implements it wrong - something with the browse speed on my PC I expect.

Looking at Page 52 of the V2 manual it is of course broken down as you pointed out.

SiriusHardware 11th Apr 2019 3:02 pm

Re: MK14 schematic revisions
 
The online emulator is unusable, slow and unresponsive on its default settings - you have to ramp the cycles per second value up to the maximum and I find I have to change the display type as well to get it to run at a reasonable speed - and also it only seems to respond on the keypad meant for tablet users as well, for me - sorry I can't be more specific but it has been a while since I used it.

Timbucus 14th Apr 2019 1:17 pm

Re: MK14 schematic revisions
 
1 Attachment(s)
Again keeping more general MK14 stuff in this thread - following SH's suggestion of looking through Practical Electronics I started with the original review (which is reproduced in text on the net) in the May 1979 issue. Off Topic I was shocked when the cover featured the IC insertion tool I had used to help build my replica - surprised I still had it and the elastic was still working! I only lamented it was too small for the 18pin PROMS and RAM!

https://www.americanradiohistory.com...9-05-S-OCR.pdf

I had read the text but, with the photo's I notice that the VDU board he mentions is not the SoC one but, the one built and described in PE itself over three issues from Oct 78 to Dec 78. - just change the number in the url to 11 and 12 to get to the other two parts...

https://www.americanradiohistory.com...cs-1978-10.pdf

This solves the problem of slowing the MK14 and and using its memory with its own onboard 1K. The review also describes the changes needed on Rev I-IV boards to remove the PROM shadow - which is where they map the Video RAM.

I have the parts on the way to build the SoC one but, that looks like an interesting project to reproduce the PCB - not sure if any of the chips are still available...

again as an aside I still have some 7400 chips with the free stickers from the Oct 1978 cover on them...

Attachment 181342

SiriusHardware 14th Apr 2019 6:08 pm

Re: MK14 schematic revisions
 
Yes, the PE VDU was a much more sensible beast than SOC's own effort. I've never seen one.

For the SOC VDU, be aware that one of the ICs on that - the character generator IC - is quite a specialised IC and may be hard to find now. It was actually an option which did not automatically come with the VDU kit, you had to pay extra for it. It still sort of works without it, but only in dot-matrix (graphics / pixel) mode. If you want to use it in its text / character output mode you'll need the character generator IC.

If Slothie manages to track the VDU connections to the rear edge -and- removes the images from 0200-07FF (a big ask) then there is the possibility to place a 'ram pack' in between the MK14 and the original SOC VDU, or just by itself to give the machine a respectable extra 1.5K of RAM.

Unfortunately the butchery required to my issue II board to get rid of the images in that range would not only be too great now, it was too much for me to consider then and I never did it.

Even when hooking the VDU into the MK14 in the manner intended there were a few required changed such as track cuts and a change to a 4Mhz crystal, so it was quite a destructive process. Mine still bears the scars, even though I have modified it back to near original state, except for the keypad of course.

..I remember those stick-on IC diagrams, a good idea I thought but of course you always ran out of the common ones pretty quickly.

SiriusHardware 15th Apr 2019 12:42 am

Re: MK14 schematic revisions
 
... Just caught up with your latest MK14 article finds.

That one with the image of the super-early-version MK14 is great, I don't think I have ever seen that one before. I have never actually heard of, or seen, an actual issue I MK14. All the ones I've ever seen are issue II or later.

Yes, an acknowledged weakness of the cassette audio signalling format is that it starts sending significant information immediately - this was addressed in later Sinclair machines by sending a long preamble of steady tone to let the recorder AGC settle before starting to send significant data.

I've never heard of the interesting HF injection method to pre-adjust the AGC action before but another forum member here (Gert?) had the brilliant idea of inverting the data before sending it to the cassette interface so that the signalling is done, not by silence broken by 4ms or 16ms bursts of tone, but by interrupting the otherwise continuous audio tone for either 4ms or 16ms. That would provide a lead-in tone for the recorder to adjust its gain on before any significant information begins to be sent.

I was actually wondering if we could (or should) collect all the links to known sources for MK14 software and hardware projects into a thread of its own, which might also incorporate some discussion about actually programming the machine - there's a lot of interest in recreating the hardware but people rarely write anything new to run on them (I am as guilty as anyone else).

I've been contemplating the idea of setting up a small model railway circuit and trying to do some basic PWM speed control and automatically starting from / stopping at a station - I have some (N gauge) sectional track and a few models to put on it, but no electrically controlled points, so it would have to be quite basic. I think this is the sort of experimental Arduino-like hobby control application the MK14 was originally aimed at.

Another, less physically complex and more self contained project might be to connect an alphanumeric LCD display to one or both of the 8154's I/O ports and recreate the 'Message' program with the message scrolling on the LCD display with no crippling literary limitations imposed by there being no Letters 'K', 'M','P','Q', 'V', 'W', 'X', 'Y', and 'Z'.

Timbucus 15th Apr 2019 8:25 pm

Re: MK14 schematic revisions
 
As regards the SoC VDU - Martin has a substitute part a DM86S64CAB which he has managed to get - not sure how much stock he has but, its a useful source with the PCB.

I think the idea of collecting articles and links in a thread is great - this one is sort of doing it. I have been pulling together a set of personal notes on topics which may help form an FAQ. A wiki would be ideal somewhere perhaps...

That's funny I describe the MK14 to people as the Arduino of 1978 so a model train controller seems ideal...

I am also guilty of not doing any coding (yet) - as a Z80 programmer I am having a bit of a shock reading what is available on the SC/MP II first!

The Alphanumeric LCD display ties in very well with my first intended project which is to port my adaptation (which is 256 Z80 bytes) of an i2c and RTC driver from the Next! That is what I am working up to... now I have actual hardware and a cross assembler.

Other magazines of the time may have something of interest if not directly MK14 then SC/MP (E.g. Elektor who had the designs for a machine based on one if I remember correctly). One I quite fancy having a go at is 2 dimensional version of Conway's game of life described in Issue 12 of the 1978 Byte:

https://archive.org/details/byte-mag...78-12/page/n69

The magazines suck up research time ( I have to stop )...

I have also just been naughty and bought a copy of Issue 2 of Personal Computer World (May 1978) as they are not archived online anywhere. It has a review of the MK14 in it (I noticed as the listing included the contents page) which I will obviously scan - interestingly it is written by Nick Toop. I think it may be the same person who in PE of April 1979 provides an MK14 diagnostic program written in NIBL BASIC - he is described as working for SoC then and is credited as the designer of the VDU board... He has a further article in the Dec 1979 PE issue with an Output Flag multiplexer and falling man animation for the VDU.

The bit that really interested me in the above is the mention of NIBL at SoC I wonder if they had somehow put the ROMS (2 off 2316A for 46.90 from Greenbank Electronics) into the MK14 memory map or were using a more powerful SC/MP system. That started me thinking that if the top four address bits were latched and some mods to the onboard address decoding were done it could appear as another 4K Page... only problem would be the SCIOS reliance on the RAM at FFF appearing to wrap below 000. A future project...

SiriusHardware 15th Apr 2019 10:58 pm

Re: MK14 schematic revisions
 
I love Z80, when I was playing about with my Maplin Z80 system a while ago I was struck by how luxurious the instruction set seemed. I remember a lot of the opcodes even to this day. Of course, this marks me out as coming from the Sinclair tribe - I still have my original ZX81 and 48K Spectrum, along with a couple of other Sinclair machines which were not originally owned by me.

The main things I wish the SC/MP had are CALL and RET instructions and a proper stack pointer to support those.

Having a cross assembler for SC/MP is the final link in the chain - once you have that and combine it with some way of getting your assembled code into the MK14, the MK14 is almost as much fun to play with as an Arduino, PIC or AVR, although of course all of the latter have extra goodies like built-in UART, I2C, SPI, Timers, analogue inputs, PWM outputs...

Slothie 24th Apr 2019 9:29 am

Re: MK14 schematic revisions
 
1 Attachment(s)
I've been looking at my latest PCB design and to correctly decode the ROM to allow extra memory in the lower 2k is going to require an extra logic IC and the requisite rework to squeeze it in somewhere and still make it look authentic. Still, perhaps that will give me something to think about! I've attached the schematic up here and perhaps you could tell me if the connections on the bottom row (P4) look good to connect the VDU. Note that due to the orientation of the connector, the power (+5) is on the right under the top power connections, and the address lines will be on the right hand side (IE nearest the vertical resistors).

PS I'm back in action after my operation though it will be a month or so before I discover how successful its been - so till then I'm a one-eyed sloth!!

SiriusHardware 24th Apr 2019 8:59 pm

Re: MK14 schematic revisions
 
Best wishes, obviously, for a good outcome from your eye surgery.

I just had a look through, looking at your diagram and my VDU and the list of connections - I think you've done a nice job with the connections in the right order and running in the right direction. I notice you've included the write signal, which, although not needed by the VDU, would be needed by any external memory or any other useful sort of peripheral IC, such as a UART or ADC or DAC connected this way.

You might conceivably need more than just one 0V and one +5V connection because individual edge contact connections tend not to be very good load bearers - probably why SOC placed the +8V and 0V input connections on groups of several edge connections each on the upper side.

Timbucus 24th Apr 2019 10:14 pm

Re: MK14 schematic revisions
 
4 Attachment(s)
Looking at my board from Martin it follows the schematic

Attachment 181803

so D0 to D7 are actually on pins A18-A25. NRDS is on A28 and NENIN is on A31 with VCC on A32 under FL1

The spares are A26, A27 and A29/A30

Here is a closeup:

Attachment 181804

and a photo of the bottom of martin's unpopulated clone - the only pin that connects on the top of the PCB is the Reverse Pages pin B15 that emerges on the Via in the bottom left up to the OR gate out on IC1. So all the traces can be seen and the bottom right is IC16 and the Data lines can clearly be seen clustering towards it. I also attach a photo of how I intend to connect them and still leave the option of a memory shim board - or even a backplane if I can get enough connectors...

Attachment 181805 Attachment 181806

SH so is your VDU board different? Martin has a photo on his site with both an original and his clone side by side so maybe there are different revisions?

SiriusHardware 24th Apr 2019 11:05 pm

Re: MK14 schematic revisions
 
No, mine is a revision 2, photo-identical to that one in your photos with all the tracks near the edge connector arranged the same way. My documentation / wiring up information also matches the circuit diagram you've posted.

Slothie's mission was only to try to lay out the connections for the VDU in the same order and in the same direction so that each required connection faced its counterpart across the gap when the two boards were laid next to each other, making it easy to wire up an appropriate lead with a 32-way edge connector at one end and a DIN connector at the other without having to criss-cross any wires.

That Martin has already tracked the required lines to the underside edge connector is complete news to me, as I have never seen one of his PCBs. It makes me wonder if SOC finally did get around to doing this on the issue V.

One thing that is missing from Slothie's diagram, I have just noticed, is the clock-out signal from the MK14 which needs to go into pin b27 of the VDU, which despite being called X-OUT is an input on the VDU. The original wiring instructions tell you to take that clock signal directly from the SC/MP (pin 38).

Timbucus 25th Apr 2019 12:11 am

Re: MK14 schematic revisions
 
1 Attachment(s)
SH sorry perhaps I misled you Martin's issue 5 board edge is in the second photo and it only has the pads ready to patch too. It is the VDU board you can see all the tracks on.

It just seemed to me that it would be ideal to have them match 1:1 so that instead of an edge connector you could solder on a DIN4162 at the top of a patched Issue 5 or a Slothie v2... in fact rather than doing all the messy patching on Martin's board maybe I will wait for a Slothie v2 for myself if he does change the D0-D7 location as it is a right shift of a group that should be possible - the other couple of lines might give him a headache though - especially if we can find a way to get the Issue 5 memory decoding and the different RAM chip stuff he has included...

This example of an issue 5 has done just that by the way so it is authentic:

https://twitter.com/mk14man/status/892508941170733056

Slothie hope the eye op goes well - understand if you do not make the the above change(s) on your board. It just occurs to me that we effectively have a useful standard connector for VDU and maybe an external RAM/ROM board between the MK14 and the VDU that can be used with anything people like. Indeed you could actually solder a right angled edge connector on the VDU - I cant find where I found this one but, that was done on there so I assume they could just plug it directly onto the MK14!

Attachment 181810

The VDU Manual says that the PADS are present on Issue 4 and Issue 5 but, you still needed to do your own patching - we still don't know when the memory decoding improvement happened though unless someone has a reference but, it was on the Issue 5 so again if you can put that on it would be authentic - maybe using the original gates and then just a new gate for your memory patch and reset solution... or not they will be functionally equivalent.

SiriusHardware 25th Apr 2019 1:12 am

Re: MK14 schematic revisions
 
1 Attachment(s)
According to my MK14 edge connector diagram from the manual the 32 pins of that connector (top side) are numbered 1 (nearest the regulator end) to 32 (nearest the vertical resistors). Place the VDU card in its logical location next to the edge connector and the first thing you see is that the numbering on the VDU pins runs the other way. Awkward.

The other problem is that there are more lines connected to the 'b'; row than that single track you see going to b17 on the top side. Other 'b' row pins are reached by Vias coming from the track side of the PCB.

If we line them up anyway, the connections on the MK14 top side and VDU top side ('b' row) line up as per the attached diagram.

This is not as bad as it could be, with most of the VDU 'b' row control lines ending up connected to 8154 I/O pins which can then be used to drive or read them, as applicable.

The problems are the VDU 'Reverse page' input (b15) which finds itself connected to the MK14 interrupt input, and the VDU clock input (b27) which gets shorted to 0V.

SiriusHardware 25th Apr 2019 1:15 am

Re: MK14 schematic revisions
 
Cross posted with you Tim: I agree that it would have been sensible to do it the way you thought it was actually done, very sensible. If even Martin's PCB does not have the buses tracked, then you may as well do it that way, bearing in mind the minor anomalies which will happen when you connect the 'b' row one-for-one to the MK14 top side connections, as stated in the previous post.

SiriusHardware 25th Apr 2019 9:33 pm

Re: MK14 schematic revisions
 
2 Attachment(s)
That was a bit more difficult than it needed to be - my archived copy of the source code for the VDU 'Demo' wasn't the final version - I have no idea where that got to - so I had to debug the next most recent version all over again.

Ordinarily, I would connect the MK14 VDU or my ZX81s to a nice little mid-late seventies B/W portable TV that I keep for the purpose, but that is mothballed just now so I dug out my Philips CM8524 Composite / RGB video monitor and fed that with composite video taken from the input of the VDU's UHF modulator.

Attached image #1, the VDU fitted with RS sourced SN74LS365s in place of its original 80L95s and displaying an appropriately informative text.

The VDU is of course monochrome, but the Philips (colour) monitor has a 'Green' switch which puts it into a mode where monochrome is displayed as restful green on black instead of white on black. The image is absolutely rock steady - the Philips has always been a great monitor for me - I bought it to use with my Atari ST in the mid eighties and it is still regularly used with that same Atari. I had to replace the power switch once, but that's all.

The SN74LS365s were two from the same batch which all worked in place of the 80L95 on the MK14 - looks like they work OK as IC9 / IC10 in the VDU as well.

Doing this reminded me again just how primitive the VDU is - only 16 characters maximum across, I had to leave a blank line between each line of text because they are insufficiently spaced out otherwise, there are only 64 characters in the character set (no lower case, and only a limited subset of 'other' characters available).

Image #2 (displayed in conventional white) is more or less centre justified within the active screen area. It gives a better idea of where the left and right boundaries are and clearly shows that even with the correct 4MHz clock the active screen area is noticeably off-centre towards the left.

Slothie 25th Apr 2019 10:58 pm

Re: MK14 schematic revisions
 
Pictures I have seen of what I believe to be Rev V boards appear to have just pads on the bottom, and no actual connections to them.
While I have no problem with putting XOUT on the connector, I am reluctant to put it in the middle of all those 0v connections on the top, I'd rather put it on one of the "spare" connections on the bottom.
Again, I can't see any real problems in shifting the D0-D7 connections etc to their correct place, but that will still leave you with problems with clashes on the top connector as Sirius has pointed out, requiring mods to your VDU card to resolve.

If I take out support for 65X61 memory devices I might free up enough gates to be able to fully decode the PROM enable - but at the moment these memory chips are reasonably easy to find for reasonable(ish) amounts on ebay/aliexpress wheras the 2111 or AM9111 are only popping up occasionally, usually for s.

Decisions decisions! I hate decisions!!!

Timbucus 26th Apr 2019 10:38 pm

Re: MK14 schematic revisions
 
2 Attachment(s)
Slothie -yes you are correct the one I linked to above and another I found online have patch wires, close up here of both for convenience:

Attachment 181912

One seems to roughly follow the VGA layout the other looks like it is almost the same patch pattern but, totally reversed! the one that seems to be following the VDU for direct connect also has some resistors patching something. Would be nice to work out what is going on there.

https://www.eevblog.com/forum/projec...4-restoration/

I should have credited this link as the source of the VDU board I posted with the edge connector on it. I have just noticed looking at it again I think it carries out the trick I am planning. As you say XOUT should be on the bottom - I suggest on the pin below no A27 as that is unused so would be easy to bend back the pin on the connector and then just bridge the pads...

Attachment 181911

I can just do a similar thing with B15 the Reverse Pages (input) pin - bend the pin up and patch it over to B8 which will mean it appears on the IO Chip A3 line... it even has a neat via I can pick it from or the hole itself...

We just need to work out what the default effect is on all those ports at reset... Maybe one or two need inversion to ensure display is on or off etc...

The only public software I know of for the VDU is the falling man animation in Dec 1979 PE - that does not seem to write to the I/O chip so doing this is unlikely to break major software...

https://www.americanradiohistory.com...9-12-S-OCR.pdf

SH- you may like the submitted subroutine handler in there as well if you haven't seen it - clever bit of code for larger programs... The offset calculator is also better than the one in SCIOS as it patches the whole program.

The other circuit I want to try and may interest others is in the 1980 August Issue of Practical Electronics which is a circuit by Anthony D. Love of Swansea that uses a 74LS32 to allow Bit 6 of the character code to invert individual characters to Black on white! Page 48

https://www.americanradiohistory.com...0-08-S-OCR.pdf

As regards the Memory - there are some notes posted somewhere (by SH I think) on the gates they used on the Issue V to remove the multiple PROM images so it is possible with only what is on the board.

The would mean that the additional chip you add would be for the alternate memory option - this should also mean only that change has a routing difference to the real MK15 Issue V. UTsource have AM2111 at 5.95 each at the moment - they do not show stock levels but seemed happy when I put four in my basket - delivery is slow or steep though...

SH - thanks for doing all that testing... - at least you have a sketch (it was an arduino you used?) now you can share for people to test a VDU board :)

I have received my two MM80C95N as well which I will try in the VDU when I build it and get it working. One of them certainly works on the keypad IC11 i/f which we are discussing in the other thread. I didn't think as a CMOS part it would have enough fan out but, maybe the other chips are not being driven as it is a bus... so they need the EN or CS asserted for that. I will study a bit more the VDU schematic how they are used there, as this is at the limits of my electronics knowledge...

SiriusHardware 27th Apr 2019 9:22 am

Re: MK14 schematic revisions
 
Again, some nice information mining there. We're going to have to make you the official MK14 historian / repository. I remember running the 'Falling man' animation on my VDU / MK14. That comment by Paul Robson (-The- Paul Robson?) is quite new, I only just noticed it myself.

The VDU 'demo driver' PCB is a Microchip '44 pin demo PCB' of the type which was included with PicKit3 programmers - the chip on it is a PIC18F452, chosen because it has a 'PLL' clock mode which allows it to effectively run at 40Mhz with a 10Mhz clock crystal. I rigged that up a few years ago now after seeing the VDU PCB sitting unloved in a drawer for decades and finally feeling sorry for it.

In theory you can test the VDU just by programming an eprom with some test text or a test bitmap image and connecting the address, data and RD lines to the appropriate connections on the VDU. (You will need to generate a 4MHz clock for it as well).

Tie all unused eprom pins - higher address pins, OE, etc to 0V and other pins to whatever state is necessary to get the chip into read mode.

On the VDU, tie all of its control lines into the obvious required states and you should get a nice static image of whatever you have programmed the eprom with.

Character mode is the easiest to try this with since the relationship of screen ram locations to screen character locations is exactly as you would expect, screen ram location zero is the first (upper left) character on the screen, screen ram location 511 is the lower right character on the screen.

In graphics / bitmap mode the relationship between screen ram locations and pixel locations is not quite as simple as you would expect, I'll go into that in more detail some other time. There's a reason why the 'Falling Man' animation scrolls downwards rather than across... I'll also post the VDU's reduced ASCII character code set as well, as I don't know if it is documented anywhere.

Timbucus 27th Apr 2019 2:35 pm

Re: MK14 schematic revisions
 
I did say I was a bit obsessive about information on a topic... I am trying to record all this in one place but, it is getting so big and interconnected I think maybe it will be enough for a book!

I only have a PIC16 kit I picked up recently - never done anything with them so it was a curio. I will probably have a go at KarenO's machine one day as a suitable project to find out about them. I have a few blank EEPROM's so that sounds like a good way to try it - thanks.

I will look forward to your insights on the Graphics modes.

If you really want to blow your mind read the Manual update letter - it is full of interesting snippets...

http://www.computinghistory.org.uk/d...Update-Letter/

> An updated PROM was available that supported a teletype terminal - that makes the EX42/44 project more interesting in relation to this - I wonder if any of the boards still in existence have that instead...

> They were planning a 2K Memory expansion card (so our intention is in keeping) and it confirms that 1,2 and 4 boards can be modified (wonder what happened to III). And that Issue 5 are already done.

>A 16 way A to D card.

>Advanced calculator interface - to use the calculator as a maths co-pro!

Really interesting:

>BASIC Language board - this seems to support my theory that the published NIBL BASIC program in PE April 1979 was perhaps done on a prototype MK14 BASIC expansion... definitely worth doing now...

They say this needs the VDU card (which they hoped to release in January - (1979 I assume) and the also announced 40 Key Keyboard which would came with another SCIOS update... - other items due March (again I would assume 1979)

I also notice that https://twitter.com/mk14man has started posting again intending to get his AVR based one finished. His latest tweet also posts the link to the Powerpoint he gave at the ParlaBytes Spanish Retro event in 2015 which I had discovered recently. There is also a video of the talk online as well (in English):

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

and here is the link to the Powerpoint as it is hard to see in the Video...

http://www.auic.es/contenido/documentos/charla-Mk14.ppt

Timbucus 30th Apr 2019 10:08 pm

Re: MK14 schematic revisions
 
Quote:

Originally Posted by Timbucus (Post 1140113)
The only public software I know of for the VDU is the falling man animation in Dec 1979 PE

Actually I was wrong there - looking back through my notes I had also found that PE August 1981 has some nice programs for the SoC VDU board. They say they get a lot
submitted for the device which it also informs us is sadly no longer available from SoC;

A Clear Screen routine, A Logic Display of the IO ports and a Horse Race - it also includes the design for an RTC not specifically for the MK14 but, generally...

https://www.americanradiohistory.com...cs-1981-08.pdf

SiriusHardware 30th Apr 2019 11:53 pm

Re: MK14 schematic revisions
 
I missed those, although a CLS routine is not a difficult thing to do - just fill the screen area with either 0x00 in graphics mode or 0x20 (Space) in text mode.

I have been meaning for years to do something more than just the static text display with that VDU demo jig - I changed the demo code a couple of days ago to put the VDU into graphics mode for probably the first time since it was attached to the MK14 at least 40 years ago. There appears to be a small problem with my timing in graphics mode as there is some interference / flickering on two of the vertical pixel lines. I'll have a look at it again if I get time.

Getting a PIC to react to a change in address and supply the data meant to be coming from that address at the same sort of speed as an SRAM was surprisingly hard, as I remember.

One problem is that the VDU takes the RD line low for the whole of the time it takes to read one horizontal line's worth of text or graphics RAM, so there's no falling RD edge each time the VDU wants some new data. It just keeps RD low, changes the address it's sending out to the host RAM, waits a short time for the new data from the RAM to settle and reads the next data in, repeating that until it has read the data for the whole line. Then, RD goes back high.

When RD falls low at the beginning of the line I do the first address read and data output. The rest of the read address / output data cycles on the line are timed by watching for changes of state on the VDU's A0 line.

The (theoretical) advantage of using a PIC to do this is that, in the period outside the time when the VDU is demanding to be fed data, the PIC could spend a bit of time manipulating / animating the screen ram contents, whereas if you use an EPROM to store a test image it will just be that fixed image - although you could store a different text page or bitmap image every 512 bytes in a very big EPROM and run a binary count-up on the remaining address pins, either slowly for a 'slideshow' or quickly to do a flicker-book 'animation'. (My animation skills are definitely not up to that).

SiriusHardware 1st May 2019 10:32 pm

Re: MK14 schematic revisions
 
I've been mucking about with the VDU again tonight, and here are a couple of snippets arising from that.

Earlier, I said that the relationship of screen RAM locations to text character positions was the way you'd logically expect, but I also said I didn't think that applied to bitmap / graphics mode. I don't know why I thought that, because the allocation of memory locations to pixels does follow the most obvious scheme you could imagine.

The first byte of screen RAM is represented by the first eight pixels at the upper left of the screen, with the LSB state indicated by the rightmost pixel of eight and the MSB state indicated by the leftmost pixel of eight.

The second byte of screen RAM is represented by the next eight pixels to the right, the third byte of screen RAM by the next eight pixels to the right of those and so on, so that the first eight bytes of screen RAM are mirrored by the uppermost 64 pixels. The next eight bytes are represented by the second line of 64 pixels, the eight bytes after that are represented by the third line of pixels and so on. All just as you would hope / expect.

The second snippet of information is the VDU character set, which is as follows: (Each character, followed by its MK14 VDU hex code).

Code:

@ 00  A 01  B 02  C 03  D 04  E 05  F 06  G 07  H 08  I 09  J 0A  K 0B  L 0C  M 0D  N 0E  O 0F
P 10  Q 11  R 12  S 13  T 14  U 15  V 16  W 17  X 18  Y 19  Z 1A  [ 1B  \ 1C  ] 1D  ^ 1E  _ 1F
  20  ! 21  " 22  # 23  $ 24  % 25  & 26  ' 27  ( 28  ) 29  * 2A  + 2B  , 2C  - 2D  . 2E  / 2F
0 30  1 31  2 32  3 33  4 34  5 35  6 36  7 37  8 38  9 39  : 3A  ; 3B  < 3C  = 3D  > 3E  ? 3F

Please note these characters and codes are correct for the character generator IC originally supplied with the MK14. I don't know if this is true for the alternative character generators which are being supplied with Martin L's VDU clones.

I didn't forget the character whose code is 0x20 - that would be 'space' which is why you don't see anything there in the table. At first glance this is awkwardly different to the standard ASCII character set, but in fact some portions are the same and other values are easily derived from the original ASCII values.

Assuming you have some genuine ASCII text which you want to display on the MK14, then:

Send characters with codes in the range 0x20 to 0X3F to the VDU unchanged, as they are the same as in standard ASCII. This range includes the numerals 0 to 9.

For characters with codes in the range 0x40 to 0x5F, - mainly upper case letters, but also including the '@' character whose code is 0x40 - subtract 0x40 from the ASCII code to convert it to the VDU code.

For characters with codes in the range 0x61 to 0x7A - lower case letters - subtract 0x60 from the ASCII code to convert it to the VDU code

If the original ASCII character does not fall within any of these ranges I convert it to 0x3F, which is the code for a question mark '?'.

Slothie 14th Jun 2019 1:23 pm

Re: MK14 schematic revisions
 
4 Attachment(s)
Well, since my eye is improving I thought I'd get back to sorting out the new PCB layout. I've managed to wire up all the connections on the edge connector to better match the VDU card (XOUT is on the bottom rather than the top, as discussed previously). I'm now trying to squeeze in an extra gate to fully decode the prom as this is going to make it possible to add extra RAM for VDU users and for some ideas I have. Here's a few screendumps of my progress so far.....

If there are any glaring omissions please feel free to point them out!

SiriusHardware 14th Jun 2019 4:22 pm

Re: MK14 schematic revisions
 
One very minor non-fatal error so far - on the circuit diagram, on the lower edge of the display, the terminal marked 'e' is probably meant to be marked 'col 3'.

Slothie 14th Jun 2019 6:08 pm

Re: MK14 schematic revisions
 
Well spotted! I did actually notice this sometime before Christmas and then instantly forgot all about it.... I guess I need to edit the footprint sometime.

SiriusHardware 14th Jun 2019 6:28 pm

Re: MK14 schematic revisions
 
I see you did get the reset line out to the keypad edge connector.

Regarding the 'P4' connector row which I assume is the new lower side of the top / rear edge connector, at which physical end of the connector will pin 1 be? The end nearest the regulator? Or the end nearest the four vertical resistors? I'm guessing you have numbered them in the same order as the corresponding VDU row pins rather than in the same order as the MK14 top side pins?

With respect to the (obviously unfinished) PCB layout, I don't see many mounting positions for supply decoupling capacitors. While this is authentic with respect to the original MK14 which has very few supply decoupling capacitors and somehow gets away with it, it would probably be better practice to provide a mounting position for a (ceramic) decoupling capacitor for pretty much every IC, if possible.

Slothie 14th Jun 2019 8:14 pm

Re: MK14 schematic revisions
 
Due to technical issues (OK, mistakes!) the bottom connector P4 is numbered the other way round - so the address lines are on the right (near the vertical resistors) and the VCC/XOUT/NRDS/NWDS signals are to the left, underl the power/ground connections. I'm not sure if the VCC is going to be all that useful given that the regulator glows in the dark as it is, but it might be useful for something.

As for decoupling capacitors - I have been thinking seriously about this and I am glad that you also think it would be a good idea to make room for at least a few more where they can be fitted. The design as originally given works but I think that it can't do any harm to place holes for them even if I don't choose to populate (all) I'm not convinced my layout of the power rails is particularly optimal and I'm using a modern switching power wall wart which typically generate a lot of high frequency noise of its own. With the additional chip and a few other changes I have made its not like its going to be mistaken for an original unit anyway! Looking at the power and signals on an oscilloscope reveals a lot of noise, which might explain the occasional reset problems I had noted.

SiriusHardware 14th Jun 2019 8:59 pm

Re: MK14 schematic revisions
 
I prefer to think of this as an 'ultimate' MK14, with all the refinements that the issue VI would have had, had there ever been one.

You've obviously gone away from the possibility of using PLDs or GALs or PROMs as custom address decoders, a decision which I can safely applaud since I'm not the one who actually has to get all the necessary standard logic onto a PCB.

Ultimately, that decision will make it easier for anyone else to rock up and populate one of your replicas, with only the PROMs then still being really difficult and expensive to obtain - hopefully the 6xxx RAM alternatives are still available at a reasonable price.

Timbucus 14th Jun 2019 9:53 pm

Re: MK14 schematic revisions
 
I am rushing away for the weekend but, this looks great - I will check it out in detail when I get back to a machine on Monday night. Just a note that utsource currently list stock of over 147000 AM9111 RAM chips and a similar number of the PROM's so I do not think the world is going to run out very soon and the Tesla PROM's seem pretty plentiful on auction sites still.

SiriusHardware 14th Jun 2019 10:23 pm

Re: MK14 schematic revisions
 
Ah, well, the Tesla PROMs are Slothie's other problem. :)

I could send you what info I have about those - over and above what was discussed earlier in the forum, and maybe the two of you can forge ahead on that problem either together or independently.

With regard to Utsource, I know you (Tim) had a good experience with them recently but someone else sent me a pair of PROMs obtained from there which, although they were genuine DM74S571s, turned out to be already programmed. Granted they were suspiciously cheap, and if you paid more you'd be more likely to get genuine unprogrammed blanks even from the same source.

Everything is still available - if you can afford it.

Slothie 14th Jun 2019 11:30 pm

Re: MK14 schematic revisions
 
Quote:

Originally Posted by SiriusHardware (Post 1152693)
You've obviously gone away from the possibility of using PLDs or GALs or PROMs as custom address decoders, a decision which I can safely applaud since I'm not the one who actually has to get all the necessary standard logic onto a PCB.

Yes I haven't gone in that direction partly because I want the result to look like it could have been from the 70's but mostly because I've used CPLDs in the past and the software you need to make the programming files is a pain to use (Quartus I'm looking at you!) GALS are getting rarer to find too even if you can find the software for them.

As for PROMs I've blown up a few MOSFETs on breadboards trying to get the programming wave-forms right but then all this excitement with my eyes started and I've yet to get back to it!

Slothie 22nd Jun 2019 8:50 pm

Re: MK14 schematic revisions
 
1 Attachment(s)
Well I've squeezed in some decoupling capacitors which was the last thing on my list, so I'm going to give it another few days and then check everything over again and I think its time to send off to have the boards made...

SiriusHardware 23rd Jun 2019 12:54 am

Re: MK14 schematic revisions
 
Maybe give Timbucus a chance to look it over before committing to hardware, he seems to have the same gift for effortless understanding of traditional logic circuits which you have.

Slothie 23rd Jun 2019 1:03 am

Re: MK14 schematic revisions
 
Quote:

Originally Posted by SiriusHardware (Post 1154705)
Maybe give Timbucus a chance to look it over before committing to hardware, he seems to have the same gift for effortless understanding of traditional logic circuits which you have.

Lol a lot of that "effortless understanding" is the python parallel logic simulator I wrote :)
But I accept your compliment and it'll be towards the end of next week before I send off anything so Timbucus should get a chance to comment!

SiriusHardware 23rd Jun 2019 8:49 am

Re: MK14 schematic revisions
 
I take it we can assume that the actual circuit diagram remains unchanged from the one you attached in #182, you've just added physical places on the layout where a few supply decoupling capacitors can go?

With regard to the python-language logic simulator, that sounds like a nice handy tool. I seem to remember there being something a bit like that available for the Spectrum in one of the official Sinclair branded software cassettes - don't remember what it was called now. Maybe just 'Logic'.?

Slothie 23rd Jun 2019 9:27 am

Re: MK14 schematic revisions
 
1 Attachment(s)
Yes, aside from the decoupling capacitors everything is as it was.
The logic simulator is very basic and just produces truth tables - I've attached it zipped with an example input file if you want to play with it!

SiriusHardware 23rd Jun 2019 10:55 pm

Re: MK14 schematic revisions
 
I've just arrived back from the Hebrides so, although I've grabbed the package in the previous post I have not seen it yet. I'll have a look at it tomorrow (Monday) evening. Thanks for putting it up.

SiriusHardware 24th Jun 2019 1:21 am

Re: MK14 schematic revisions
 
Aha! The Spectrum software was called Make-A-Chip. I'm pretty sure I still have a boxed original tape copy somewhere. Limited to gates with two inputs and twelve gates in total, which is a shame.

https://www.petervis.com/Sinclair/Ma...ke-a-Chip.html

Sorry, going off on one there. Back to the MK14.

Timbucus 25th Jun 2019 9:08 pm

Re: MK14 schematic revisions
 
1 Attachment(s)
Quote:

Originally Posted by SiriusHardware (Post 1154705)
Maybe give Timbucus a chance to look it over before committing to hardware, he seems to have the same gift for effortless understanding of traditional logic circuits which you have.

Ha ha not sure where you get that impression! Slothie deserves it for the excellent work on the PCB which looks really good, although I have not had time to go through it with a tooth-comb but, I think his goal of a believable V5.5 has been achieved - I will stick my hand up to try one when they are available as it will make using my VDU easier!

He also deserves praise of course for his simulator... "Make a Chip" is considered the booby prize in any collection of spectrum software as everybody seems to have a copy (except me strangely).

https://youtu.be/JMLvJHdCmPo?t=256

Staying off main topic for a while on that one we used to publish software (from a friend of mine Peter Armitage) for the BBC BITD!

Attachment 185680

Also I thought you would be interested that Geoff Phillips uploaded his surviving "Complement and Add" user group magazines to archive.org - I have not read them all yet but, he also added a nice preface.

https://archive.org/search.php?query...lement+and+add

SiriusHardware 25th Jun 2019 10:04 pm

Re: MK14 schematic revisions
 
Another mega information find!

It was remarkably kind of Mr Philips to put all that up. If you have a contact address or email for him please offer him our sincere thanks.

It beggars belief that the chain-letter format worked as well as it sometimes did (and sometimes didn't). All pre-internet and pre dial-up BBS of course, never mind the fact that for most of the club members the MK14 was the only sort of 'computer' they had.

Imagine the stuff which could be contributed to that newsletter now, if it was still going. Just the material contained within several threads (some now closed) on this forum - plus numerous off site sources pointed to by links in the same - would be enough to fill 100 such newsletters.

I have (ahem) 'reserved' one of Slothie's issue 5.1 / 5.5 PCBs as well, Tim, the notion of owning an MK14 with all the bus signals neatly available at the rear edge would be too interesting to resist.

Slothie 25th Jun 2019 10:11 pm

Re: MK14 schematic revisions
 
Since a queue is forming I'd better check that its going to work carefully!


All times are GMT +1. The time now is 8:36 pm.

Powered by vBulletin®
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
Copyright ©2002 - 2020, Paul Stenning.