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)

Slothie 21st Oct 2018 5:32 pm

Re: MK14 schematic revisions
 
2 Attachment(s)
Great news! I finally tracked down all the wiring errors on the pcb. I've typed in the program SiriusH gave me and got "Slothie" on the display as a reward, so all would appear to be working as expected. The only odd thing is that on reset 8 out of ten times you get random digits on the display in the gaps between '0000' and '00' - but pressing Abort clears this and all seems to operate as normal. If I ever find my scope and probes maybe I should look into the reset timings.
I tried to get a photo of the output of SiriusH's program but its a bit hard to see - maybe I need better lighting. However if you squint a bit you can see it. The random looking wire at the back is grounding the "SENSE-A" pin so that programs will run...
The other photo shows the modification wires on the bottom.... lets just say I think I will get a new PCB made, if only because the wires are going to be a pain snagging and breaking etc. I also need to put some diodes or a resistor in the power lead because the regulator runs HOT (hot enough to make you not want to touch it - I measured it as 60 deg C and stil slowly climbing.) When I redo the pcb I might make room for a bigger heatsink or fab one from aluminium,
Well, thanks to everyone who offered help & encouragement, as I am now in posession of a working MK14! All I need to do now is to write a few programs for it...!

Slothie

SiriusHardware 21st Oct 2018 8:50 pm

Re: MK14 schematic revisions
 
Good work Slothie, I knew it wouldn't take you long to snag it. I originally made that program (a modified version of one I already had) when it seemed you were days away from getting it up and running, but then things started to get complicated. By that time my own MK14 was back in storage so I tested the code on Doug Rice's online emulator.

The reset behaviour you describe is not normal, normally they reset cleanly every time but that is a minor niggle in the grand scheme of things.

SOC were either optimistic or knew full well that the user would have to fit a heatsink and omitted it to reduce their costs, either way you are correct, the regulator runs unacceptably hot without a heatsink. If you are running on a variable regulated supply you can help it out a bit by lowering the input voltage to the lowest at which the regulator continues to produce a reliable 5V output, which in practice will be between 7.5V - 8.0V.

If you are running on an unregulated supply marked '9V', try measuring the input voltage to the regulator, it might be a lot higher than 9V in reality.

Slothie 21st Oct 2018 9:22 pm

Re: MK14 schematic revisions
 
Quote:

The reset behaviour you describe is not normal, normally they reset cleanly every time but that is a minor niggle in the grand scheme of things.

SOC were either optimistic or knew full well that the user would have to fit a heatsink and omitted it to reduce their costs, either way you are correct, the regulator runs unacceptably hot without a heatsink. If you are running on a variable regulated supply you can help it out a bit by lowering the input voltage to the lowest at which the regulator continues to produce a reliable 5V output, which in practice will be between 7.5V - 8.0V.

If you are running on an unregulated supply marked '9V', try measuring the input voltage to the regulator, it might be a lot higher than 9V in reality.
The power supply I'm using is a modern switching "wall wart" which is rated at 2A outputs 9.1v off load and a tiny bit less (~9.08v) when plugged into the MK14. Thats why I thought using a couple of diodes would drop the input to ~7.8v and dissipate some of the power before it gets to the regulator. The original manual suggested a resistor but I think diodes are a better option - in 1978 that would have been expensive but not so much today!
The regulator has a heatsink but its tiny, so I'll see if I can find one with longer fins. Unfortunately I made the regulator a bit snug against the socket for the INS8154 RAM/IO which I will address when I do rev 2 of the board!

Until then I'm celebrating with a can of :beer: and a takeaway and spending a little time (re)learning how to program the SC/MP. I've learnt so much from making this despite the frustrations and once I've corrected the PCB I'll make the design files available for other people to play with .... and possibly have a go at the problem of programming Tesla 74S571 PROMs!

Slothie 25th Oct 2018 10:06 pm

Re: MK14 schematic revisions
 
1 Attachment(s)
Well I've fitted a bigger heatsink (here) and the temperature of the regulator case stabilises at about 65 deg C compared to 70 deg C for the previous heatsink. When the display is off the temperature drops - running the clock program from the manual the temperature stabilises at about 62 deg C. I'm a lot happier with this as the previous heatsink never seemed to stabilise, and I was worried it would creep too high. 65 degrees is pretty hot, but not unusual for this type of regulator. This larger heatsink means the INS8154 RAM/IO chip probably won't squeeze into its socket, but I'll shift things around when I update the PCB to make room for an even larger heatsink that will cope with the added current load of the RAM/IO and the optional memory.

I think the reset problem I'm seeing is something to do with the switching power supply I'm using, because if you leave the capacitor to discharge or short it before plugging in the MK14 resets properly every time.

I've been having fun playing around with the MK14, trying to get my head around to the relative addressing scheme it uses and the minimalist instruction set, and I'm so happy to have a working system at last!!

SiriusHardware 25th Oct 2018 11:21 pm

Re: MK14 schematic revisions
 
Best of luck finding the 8154 RAM/IO (maybe you already have one)- it definitely makes a big difference to the 'play value' of the MK14. I think Forum member GrahamN (who has one of the JM replicas) managed to find some somewhere, though at a price.

One of the things which always gets me about the SC/MP is ... no SUB (subtract) instruction, or at least not one which is immediately recognisable as such. ("CAD", Complement and Add, is the equivalent). Also, no conventional CALL / RETURN instructions and no dedicated Stack Pointer of the type found on virtually all other microprocessors from that time - you can call subroutines, but it involves swapping the contents of one of the pointers with the PC - a bit messy.

Slothie 26th Oct 2018 12:13 am

Re: MK14 schematic revisions
 
I have 2 which I got from a seller in China for 15, although I've not tested them they look pretty genuine (vertical stripe, NS logo and same font as my SC/MP) and the seller has lots of positive feedback and virtually no negativ They are the only ones I've seen for less than ~35 a piece for more "reputable" suppliers so if they prove to be fake then I guess thats a lesson learned!

As for programming, yes its definitely arcane but to be fair to NS it was designed before a lot of the "conventions" we take for granted. It's not surprising that a lot of systems using it were done by cross-assembling the code on a minicomputer which could make use of exotic macro features and high level constructs! I've got a TASM table for the 8060 so I can assemble through a DOS box on my laptop, but I've yet to find anything that runs nativly on Linux (not that I've looked very hard).

SiriusHardware 26th Oct 2018 12:31 am

Re: MK14 schematic revisions
 
I use a free, open-source cross assembler - "SB-Assembler 3" written in Python by San Bergmans whose electronics hobby website is

https://www.sbprojects.net

It can be downloaded from there. A beta version of it was shown being used in this rather shonky Youtube video of mine posted several yours ago now. It didn't include a 'Cross' for the 8060/SC/MP at that time so I had to write that bit myself, and I only did the absolute minimum required to make it work.

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

SB-Assembler 3 has since made it to the final release version which includes an 8060 / SC/MP 'cross' file properly written to the same standard as the rest by San himself. As it's written in Python it will run on any platform for which Python is available, including, as seen above, on a Raspberry Pi.

GrahamN 26th Oct 2018 10:28 am

Re: MK14 schematic revisions
 
That's an impressive video!

I still haven't had time to do more than a couple of quick tests on my replica so far, but I do like the idea of downloading directly from the Raspberry pi rather than the tedious typing in!

Is the interface an open-source project? Or did you design it yourself?

SiriusHardware 26th Oct 2018 2:40 pm

Re: MK14 schematic revisions
 
I did that one myself, around 2012. It's not very repeatable / replicable as there is a complex maze of 20 * optocouplers built on the lower of the two veroboards. The idea of using optocouplers was so that the interface was completely isolated and could be disconnected from the MK14 while it was running, so I could load it up with something and then leave it running a demo in its clean stand-alone configuration.

There are theoretically alternative / easier ways of doing the hex downloader / keypad interface which I'll be happy to discuss in due course.

JohnBHanson 26th Oct 2018 9:43 pm

Re: MK14 schematic revisions
 
Use the tape in input (or actually the serial input). Then all that is required is one pin of digital output and a program to download.

Key in to load tape and then off you go. I wrote one in Z80 assembler once.

Slothie 26th Oct 2018 11:18 pm

Re: MK14 schematic revisions
 
was thinking of doing something like this using an arduino (since I seem to have a box full of them I've managed to collect). Send the intel hex file down the serial connection and convert to the serial waveform the mk14 expects... not as dramatic as Sirius's solution on the display, but probably quicker to implement!

SiriusHardware 27th Oct 2018 12:04 am

Re: MK14 schematic revisions
 
There are reasons not to use the tape interface or the SIO pin.

The tape interface needs the system to have the 'new' version of the OS, as only that version has the tape routines embedded in it. But even then, the problems with that approach include:-

-Speed. Only four characters a second.

-Code size limitation of 256 bytes in any one load (a limitation imposed by the tape interface firmware).

-The tape interface routines require you to know (and manually input) the load address for the program prior to loading it because the data file does not contain this information.

Serial input through SIO pin - only practical if you are prepared to modify the Monitor PROMs and replace the tape service routines with serial download routines. Physically ties up the SIO pin and may need to ring fence some RAM as a receive buffer.

Advantages of using an interface which injects the code into the machine by literally typing it in through the keypad edge connector:-

-Much faster than the cassette interface.

-Requires absolutely no modification to the MK14 hardware or firmware, which is especially important if the machine is an original MK14.

-Uses no system resources or hardware assets which are not already used by the Monitor. (Doesn't tie up any Sense, SIO, Flag or RAM I/O pins).

-If the interface is designed to receive Intel Hex then downloaded code can be directed to multiple locations within the memory as defined by .ORG statements in the source code - the code is automatically 'typed' into the correct addresses.

-No size limit on the amount of code which can be injected into the machine in one go in this way, apart from the size of the available memory of course.

Slothie, yes, I would use an Arduino for the receiving / control now if only to make it much easier to implement a USB, rather than RS232 serial link to the sending source. I hadn't actually heard of / come across the Arduino concept at the time.

Sticking with the Raspberry Pi, a simplified version could use a bit of bespoke software running on the Pi which would notice whenever the working hex file had been modified by the assembler, and if so, send the relevant control signals for the opto matrix directly to the GPIO pins of the Raspberry Pi. I made the original interface to be as generic / versatile as possible so that anything which could send an Intel Hex file out over a serial port - PC, Raspberry Pi, Psion Organiser - could be used to load up the MK14.

GrahamN 27th Oct 2018 9:56 am

Re: MK14 schematic revisions
 
I like the idea of 'typing' in the code automatically - apart from the reasons stated above it just seems so flexible, and can easily be modified to suit other computers of that era relatively simply (I'm thinking KIM1, Acorn System 1, etc.).

Anyway, I'm not too hot on circuit design, but I think I'm going to have a go. I did think about Arduino relay boards for real simplicity, but looking up the price of optocouplers on eBay, I find I can get 50 for less than 2 delivered! So - I've placed an order and I'll spend the few weeks until they arrive sketching out some designs.

I quite like the idea of serial rather than USB as again it seems appropriate when using vintage technology - but in any case it's very easy to convert between the two and I'm pretty sure I have some circuits around for driving multiple relays from serial inputs which should be straightforward to modify.

Slothie 27th Oct 2018 10:49 am

Re: MK14 schematic revisions
 
I've got a tube full of opto isolators (somewhere!) so I'll probably have a go someday if they turn up in the never-ending story of tidying my flat up and organising my electronics "collection" (read: Hoard). I mentioned the serial idea mainly because it seemed like something that could be achieved in an hour or two without too much soldering, and 4 bytes a second is still 10 times faster than I can accurately type!!

As for the Arduino, I suppose if I wanted to keep it retro I do have a literally dozens of 6502/6809/z80 microprocesors and support chips, a load of EPROMS and static RAM chips so I could make something retro custom for the job! That said, given the time its taken to make the MK14 I'd be looking at a long project :D

No, I like Sirius' idea better from both a technical and aesthetic point of view, and using a RPi seems like a good plan because then I can have the whole development environment and the uploader hardware in one place and just SSH into it from whatever computer I'm working at! Three 74LS138 3-to-8 decoders, a scattering of resistors and the Pi and the jobs done!

SiriusHardware 27th Oct 2018 10:10 pm

Re: MK14 schematic revisions
 
Quote:

Originally Posted by GrahamN (Post 1086552)
...can easily be modified to suit other computers of that era relatively simply (I'm thinking KIM1, Acorn System 1, etc.).

Yes, I've already done this. ;D Not with the computers you mention but with numerous other items of equipment which have relatively complex programming but are only programmable through their keypads, things like low end burglar alarm panels and so on. It's an especially useful thing to be able to do when you have a large quantity of items all of which are only keypad programmable and all of which need the same set of initial parameters programmed into them, normally a tedious, slow and error prone manual job. When doing this with other equipment I use an Arduino driving a general purpose 4 * 4 opto matrix and the information to be programmed is just held in look up tables in the Arduino source code.

The very first incarnation of a scheme I used like this did actually use relays because I had lots of those and no optocouplers. Apart from the noise and the slower speed (relays need time to physically get from off to on, and from on back to off again) there is also the problem that their contacts bounce just like the contacts in switches do.

Using optos (which turn on and and off a lot faster and don't bounce) you can ramp the speed up until character entry speed is as fast as the target system can manage to accept it - usually the speed limiting factor is the target system's built in key debounce delay. The entry speed in that MK14 video is about 5 percent less than the absolute maximum character input rate the MK14 can reliably accept without starting to miss incoming characters.

For other systems you also have to factor in how long it will be after any given input before the system has performed the requested action and is ready to accept another input character.

Last time I was discussing this (in a now closed MK14 thread) TonyDuell pointed out that I could have used only twelve optocouplers, with four connected to the rows and eight connected to the column/cathode drive lines. To 'press' any given key you'd turn on one of the row optos and one of the column optos, and those two optos in series, one above the other, would connect the desired row and column together. I think on any standard Arduino or Pi you could probably find 12 digital outputs to drive those 12 optocouplers, so there wouldn't be any need for any additional encoding hardware between the micro and the opto LEDs.

On my original interface I don't use 20 digital outputs each driving one opto LED, instead the opto LEDS are connected in a matrix in a similar fashion to 'Charlieplexing', such that specific parallel binary values output to the rows and columns of the opto LED matrix turn on only one chosen LED and turn all the others off. It works well but it is another reason why my original design would be very complicated for anyone else to build.

However, consider also a further, simpler development of Tony's idea, which is to use 2 * 4051 ICs wired back to back. These ICs are essentially digitally controllable 8-way rotary switches with a digitally controlled SPST 'enable' switch in series, so,

-Connect the switch 'common' terminals of the two ICs together

-Connect the 'enable' pins of the two ICs together.

-Connect the eight switched terminals of the first IC to the eight keypad column lines.

-Connect the first four switched terminals of the second IC to the four keypad row lines

-Connect three column select control lines from the uP to the 'select' pins of the first IC

-Connect three row select control lines from the uP to the 'select' pins of the second IC

-Connect one more line from the uP to the commoned 'enable' lines of the two ICs.

Now, to press a key-

-The uP outputs row and column select addresses to the two ICs.

-The uP momentarily enables both ICs. This has the effect of joining one row to one column momentarily.

This should work because the 4051s have the property of allowing signals to flow through their 'switch contacts' in either direction.

There's one drawback with this idea of using 2 * 4051 ICs - the resulting interface is not as well isolated as one using an opto matrix and would be potentially unsafe to disconnect from a running MK14. But if you don't mind leaving the interface connected then this is probably a much easier way to do it than by using optos.

Incidentally this (the idea of using two back to back 4051s as a micro-controllable matrix keypad 'presser') is not my original idea, it came out of a discussion over on the Arduino forums quite some time ago.

SiriusHardware 29th Oct 2018 10:11 pm

Re: MK14 schematic revisions
 
4 Attachment(s)
To further illustrate the above:

Image #1: Circuit diagram of external keypad and its connections to the MK14 edge connector. This also shows which 'fingers' of the edge connector need to be joined together for any desired keypress. I should say that this diagram relates to the keypad edge connector of an original MK14, modern replicas may or may not have the keypad edge connections in the same order.

Image #2: Optocoupler output circuit which replicates the above, to enable an external device to 'type' programs into the MK14. This is the scheme used by my interface, but it requires one optocoupler per keypad switch position. Tested, works, but complicated to build.

Image #3: Simplified scheme proposed by TonyDuell using 12 optocouplers. In this method the controlling micro turns on one column opto and one row opto simultaneously to 'press' a given key. Not tested, but I can't see why it would not work. You could drive the 12 opto LEDs either with 12 individual outputs from a Pi or Arduino - this is simple to visualise and to wire up and programme for, or, to save some micro I/O lines for other purposes the 12 opto LEDS could be arranged in a matrix and driven by 3 + 4 output lines.

Image #4: Same idea implemented using a pair of back to back 4051 ICs. Also untested. Each IC has an 'on' contact resistance of 120R so with 2 ICs in series the 'on' contact resistance therefore rises to 240R. However, the original MK14 key contacts were made from conductive rubber sheet which also had a fairly high 'on' resistance, so the combined series resistance of two 4051s should still be low enough to work. The controlling micro outputs a 3-bit column select value to the first 4051 and a 3-bit row select value to the second 4051, then takes the enable pins low momentarily to 'press' the selected key. This method only uses 7 bits of the controlling micro's I/O port so it is doable even with the most basic model of Pi or Arduino. Although the Pi outputs 3V logic levels, experience with Pis driving other 5V logic has shown that the 3V logic-1 output level from a Pi pin is high enough to be seen as a logic 1 input by a 5V logic device.

Slothie 27th Nov 2018 4:57 pm

Re: MK14 schematic revisions
 
An interesting (hopefully!) postscript to this story regards SC/MP chips from China. I've seen them on eBay for ~6 which was suspiciously cheap. In april I ordered 5 chips for 26 because I thought it was worth the risk - I already had a SC/MP I'd bought from someone in Spain a year earlier which was quite old (aka "period") but I wanted a backup and thought that it was worth the risk of them being fake. time rolled on and eventually they arrived and I was slightly dissapointed that they didn't look right, they just has a curly N logo and "INS8060N" printed on them, with some kind of date code or serial number on the underside that didn't make sense. The one from spain had the white bar and the "ISP-8A/600" marking for a SC/MP 2 that I expected to see.

When I finished assembling the MK14 and it didn't work I initially thought it was a faulty SC/MP so I ordered another 2 from a different chinese seller who pictured chips with the "correct" markings, which I thought was a better bet. While I waited for the chips to arrived I actually determined I had a fault on the PCB which when corrected made the computer burst into life!

A week or two later I tried one of my batch of 5 Chinese SC/MP chips and it didn't work, so I chucked them all in a parts box and forgot them. Some time later the 2 new Chinese SC/MP chips arrived and I was dismayed to see they were not marked like my Spanish chip but like the other 5 Chinese chips.... not expecting much I put one of them in my MK14 and ..... it worked! Slightly bemused, I tried all the chips and all but one (the one I originally tested) worked too!

So now I have 6 processor chips that appear to work, plus the Spanish one thats in the MK14. They could, of course, be marginal chips that perhaps fail when pushed, although at the MK14's 4.33Mhz clock they're already "overclocked", or perhaps have faulty instructions that the MK14 PROM doesn't use - I haven;t tried it extensively, I just stepped them through the monitor ROM and tried modifying ram - but looking at them carefully some of them have obvious solder on the leads so they could be pulled from equipment and perfectly good. I wouldn't trust them to pilot a jet but they look like they'll be OK for hobbyist activities.

I can't say all the Chinese SC/MP chips are good, but I can say that it might be worth a punt, especially since "reputable" sources like part factors have them for 25 - 30 each, which is a little steep for most hobbyists.

SiriusHardware 28th Nov 2018 7:13 pm

Re: MK14 schematic revisions
 
Keep one as a spare and sell the others individually as 'Tested Pulls'? Should rake back a little of the money you had to lay out for things like RAM, PROMs etc.

Are you now planning to make a V2 version of your MK14 PCB, or is it enough now to have one of your original PCBs modified and working?

Slothie 28th Nov 2018 10:26 pm

Re: MK14 schematic revisions
 
I'm going to make a v2 with all the corrections because I want to release the files in case anyone else wants to play with them, and because I keep snagging the mod wires and breaking them! Because I got the display wiring backwards there's rather a lot of wires under the board.

SiriusHardware 28th Nov 2018 10:39 pm

Re: MK14 schematic revisions
 
If I can venture a suggestion: While making your other changes, convert the highest finger on the keypad edge connector into a reset input. The top two fingers are originally 0V.

It always surprised me that SOC didn't do that - if you remote mounted the keypad (as many did, when they put the machine in an enclosure) then you always needed an offboard reset switch as well. The original design didn't allow for one to be connected via the keypad edge connector, which was a bit of an oversight.

..Though I'm not sure if you incorporated the issue V changes, in which case your reset capacitor and switch may go up to +5V instead of down to 0V?

Slothie 29th Nov 2018 7:12 pm

Re: MK14 schematic revisions
 
Hmm thats possible, I've included most of the changes aside from the extended PROM decoding (so it appears multiple copies in the lower 2k) because I needed a gate to allow the use of 6561 ram chips which required a chip select during write cycles. However there is a spare AND gate which might be used to replace the inverter on the reset circuit and allow a standard pull-down reset circuit that could be brought out to the keyboard connector, since +5 isn't on the connector.

Slothie 29th Nov 2018 7:19 pm

Re: MK14 schematic revisions
 
1 Attachment(s)
Here's the current schematic.

SiriusHardware 29th Nov 2018 8:38 pm

Re: MK14 schematic revisions
 
Nice diagram!

Actually, the simplest way out would be to make the last finger +5V instead of 0V, and the second last finger Reset. There are arguably good reasons not to have unlimited +5V on that edge connector though, as the edge connector is not keyed / position limited and one slip / senior moment could see hard +5V ending up where it should not be.

I don't think there are any pre-existing or historic peripherals which ever used those two 0V connections, because the external keypad doesn't need 0V.

Slothie 11th Dec 2018 10:03 pm

Re: MK14 schematic revisions
 
I think that I will include reset on the keyboard connector, and make it a pull-down to ground because for the reasons you outline I don't want to add Vcc to the connector even if there was room, and because that's what is the convention is for reset lines both then and now.

I'm also going to add a 2.1mm barrel jack connector for the power, as I've already had problems with wires soldered to the edge connector and having moved the RAM/IO to clear the regulator there is plenty of room for it. Not very "original" but I think the utility of it overrides that objection.

Once I've mulled over other possible improvements I'm not far from ordering rev 2 of my board! Any other ideas are of course welcome. I'm then going to turn my attention to programming Tesla PROMs since I seem to have accumulated a number of them and their seems to be interest in the possibility.

SiriusHardware 11th Dec 2018 11:21 pm

Re: MK14 schematic revisions
 
Yes please, I would be just as interested in a Tesla programmer since those PROMs are considerably cheaper than any of the pin-compatible ones I can currently program.

Re: The MK14, beware feature creep :)

Before you know it you will be replacing those hard to get 2111 RAM ICs with a 6116, the PROMs with a common 8-bit wide EPROM, the RAM I/O device with an 8155 or 8255 (Neither has RAM, but the 6116 would make up for that). Basically, you'd end up with an MK15... a bit like mk14man's fine effort a few years ago...

http://mymk14.co.uk/

..but using only conventional components.

Slothie 12th Dec 2018 12:25 am

Re: MK14 schematic revisions
 
Quote:

Before you know it you will be replacing those hard to get 2111 RAM ICs with a 6116, the PROMs with a common 8-bit wide EPROM, the RAM I/O device with an 8155 or 8255 (Neither has RAM, but the 6116 would make up for that). Basically, you'd end up with an MK15... a bit like mk14man's fine effort a few years ago...
Yes, that is a thing to beware!

When setting out on this project the aim was:
* use the same chips or at least pin compatible
* same layout, look and feel
* include usability modifications like keyboard etc since the original design would be hard to reproduce and pretty useless in practice.

The mods so far are the sort of thing an enthusiast at the time would have made, and although adding a power connector is kind of stretching that a bit I think it wouldn't stick out like a sore thumb and makes using the computer a lot easier, and if I'd had an MK14 back in the day I'd probably have epoxied a power connector to the PCB and wired it in after having the wires break off for the 13th time.....

If I was going to build an "MK15" using more recent, obtainable chips I'd build a SC/MP computer with a NIBL ROM, >4k RAM and maybe built in keyboard and VDU a la ZX80......

Just for the hell of it!

PS: I do have a load of 6116's someone gave me that have been sitting arounf unused.....!

SiriusHardware 12th Dec 2018 1:22 am

Re: MK14 schematic revisions
 
I would actually be quite interested in an 'MK14.5' PCB which used a slightly later 8-bit wide RAM and EPROM.

Mapping the 6116 into the three areas occupied by the standard RAM, extended RAM and RAM /I/O but keeping it away from any other part of the range could present a challenge - could use a 74S571 PROM as an address decoder of course, but it would be better to shy away from devices which hardly anyone can program now. MK14man's project, although brilliantly executed, was problematic for the same reason, not many people have facilities for programming FPGAs and other programmable logic.

My original MK14 is almost too precious to run now, I keep thinking that the next power-on inrush will be the one which finally finishes off a vital component, so it would be good to have a second, expendable machine for playing with, but quite honestly the difficulty and expense which you and others have incurred while trying to acquire parts, get PROMs programmed and so on would really put me off building a precise replica.

Oh by the way, if you are feeling particularly enthusiastic, how about tracking the address, data and control buses to the fingers on the underside of the top edge connector? SOC never did bother to do that, but it would have been a very sensible thing to do especially after the introduction of the VDU, which required all those connections.

Slothie 15th Dec 2018 12:32 am

Re: MK14 schematic revisions
 
Quote:

Oh by the way, if you are feeling particularly enthusiastic, how about tracking the address, data and control buses to the fingers on the underside of the top edge connector? SOC never did bother to do that, but it would have been a very sensible thing to do especially after the introduction of the VDU, which required all those connections.
Hmm.. That probably wouldn't be to hard since quite a lot of those lines go up to the RAM/IO anyway. Do you know if there is a "definitive" mapping (i.e. order of pins) or was it just left to user whim?

I just checked my circuit with 6561 RAM chips by changing JP1 on the schematic I posted earlier and it works fine. One slight difference is all the memory locations reset to FF rather than random values on initial power up which is interesting but unimportant. The "add on" ram chips U6 & U7 work too. I wasn't able to test the RAM/IO because due to the heatsink the chip doesn't go into the socket :-[ - on the new PCB I've moved the RAM/IO chip to give more room for the heatsink. It only involved removing and relaying about 50 tracks!

SiriusHardware 15th Dec 2018 3:11 am

Re: MK14 schematic revisions
 
If you are serious about it I would look at the connections for the VDU and try to have the various signals arrive at the edge connector in the order in which the VDU needs them. Probably the greatest difficulty presented by the VDU was the fact that there wasn't any provision to connect it to the main board. Later issue boards had contact fingers on the underside of the top edge connector but they still weren't tracked to anywhere.

Slothie 15th Dec 2018 7:27 pm

Re: MK14 schematic revisions
 
I've found the pinouts for the VDU in the VDU manual I downloaded from the internet but my question is, when viewed from the top (component) side, is pin 1 (0v or ground) on the left hand or right hand side? I've looked at google for images of the PCB but all I seem to find are replicas that seem to have 64 way DIN connectors which I doubt would have been an extravagance that SOC would have had any truck with! If you know of any photo's of the original board or perhaps a component layout diagram with the connectors marked then that would be nice.

Ian

SiriusHardware 16th Dec 2018 1:45 am

Re: MK14 schematic revisions
 
As far as I remember the MK14 board layout diagram from the manual was actual size and showed the true locations and spacing of the keys. Online versions of the original manual rarely include that page because it, like the circuit diagram, was intended to be removed and in most cases was, but I still have mine, I should maybe scan and upload it here.

SiriusHardware 16th Dec 2018 1:50 am

Re: MK14 schematic revisions
 
Away from base but I have an actual VDU that I can examine when I get home. The VDU was laid out for a card rack style connector and in fact mine has one fitted although SOC did not supply one.

SiriusHardware 17th Dec 2018 2:05 am

Re: MK14 schematic revisions
 
4 Attachment(s)
Image #1: Rough sketch of MK14 VDU connector pin numbering seen from top (component) side. I made some quick measurements to verify that the 'a' row is definitely the row closest to the PCB edge and the 'b' row is the row further away from the edge.

Image #2: Top side showing '1' at right hand side and '32' at left hand side

Image #3 Underside of connector area

Image #4 The reason mine has a DIN connector fitted. In 2013, after the VDU card had languished in a drawer for at least 30 years, I took pity on it and connected it to a PIC micro evaluation board programmed to emulate a 512 byte block of RAM which was preloaded with a static message for the VDU to display. The aim was basically just to see / show the VDU card working without having to connect it back up to the MK14.

Slothie 17th Dec 2018 11:40 pm

Re: MK14 schematic revisions
 
Well thats fortunate because it looks like most of the signals come off the RAM/IO in the correct order. And there's not much on the bottom of the PCB in that area so its looking very possible.
Thanks for the photos, looks like I'll have something to do while the family's wathing Die Hard etc this Christmas!

Happy Christmas to all on the Forum and a Vintage new year! :thumbsup:

SiriusHardware 18th Dec 2018 12:06 am

Re: MK14 schematic revisions
 
Good luck and... um... maybe you can take out those 1.5K of unwanted PROM images as well? (I may be pushing my luck, but that, along with the availability of the data bus, control lines and most of the address bus on the top connector would create the possibility of making an offboard 'RAM Pack' (in true Sinclair tradition) to go either inline between the VDU and MK14 main board, or just by itself for an instant increase in RAM).

All the best.

Slothie 18th Dec 2018 1:17 am

Re: MK14 schematic revisions
 
I spent a lot of time thinking about that because memory size is one of the biggest limitations of the MK14, especially if you go to the trouble of adding the VDU, and to do it I'd have to either remove support for 6561 memories or add another 74 series chip (which I suppose wouldn't be too bad if I could squeeze it in unobtrusively).

Since the 2111/ AM9111 memory availability is patchy I'd rather not drop 6251 support as it gives more options. The 2111 compatible memories are one of the hardest part to get if you don't want to pay 30+ each from a broker.

Unfortunately there aren't really any other memory alternatives, other than the MK14.5 approach of using something like a 6116 and logic to recreate the memory map... :-/

SiriusHardware 18th Dec 2018 11:30 am

Re: MK14 schematic revisions
 
Might it be possible to have an option to use 2114s in place of 2111s, even if you 'waste' most of each chip, as they seem cheaper and more widely available? They look almost identical, so they would preserve the original appearance while making it much easier to source memory.

Of course if you could fully utilise and map the extra memory available in 4 * 2114, so much the better.

Slothie 20th Dec 2018 1:57 am

Re: MK14 schematic revisions
 
While the 2114 is almost pin compatible with the 2111. the ground and write enable pins have been swapped and the 2 extra chip enables have been lost, so I'd have to add in some extra gates and it would be hard to add jumpers to cater for it due to the ground pin moving, so its one or the other rather than an option.

As for fully mapping the extra memory, it's a big change but I get your point! It means ripping out all the address decode logic and replacing it, I've worked out whats required with my logic simulator but it'll need reworking to simplify and use 74 gates you can actually get (I'm thinking a 74ls138 and some AND gates), but you end up with 1.5k RAM with "holes" in for the display and ram/io at $D00-$DFF and $800-$8FF respectively. I think I would do this as a "Rev 3" board a little later, since I do have 3 sets of 4 2111 compatible chips at the moment.

If I'm putting the address and data on the edge connector of course you could just leave out the 2111's and put in memory of your choice with logic that maps to the right places on an external card!

Anyway I'm not fully decided yet, I think I shall think about it over Christmas!

SiriusHardware 20th Dec 2018 3:30 am

Re: MK14 schematic revisions
 
Quote:

Originally Posted by Slothie (Post 1103122)
While the 2114 is almost pin compatible with the 2111. the ground and write enable pins have been swapped and the 2 extra chip enables have been lost, so I'd have to add in some extra gates and it would be hard to add jumpers to cater for it due to the ground pin moving, so its one or the other rather than an option.

I remember that the 2114 was different in terms of chip select lines and so on, but I am suggesting - maybe not on your initial V1.1 revision, but on V2.0, that you rearrange it so that it -only- uses 2114s since all of the 256-byte 4-bit types are becoming economically unobtainable.

Assuming you are still going to use BPROMs to hold the monitor code then you might consider using a third BPROM as a custom address decoder to generate with one IC the awkward chip enable intervals which would otherwise have to be generated with a 74138 plus more logic. (You may have your Tesla programmer up and running by that time).

Quote:

If I'm putting the address and data on the edge connector of course you could just leave out the 2111's and put in memory of your choice with logic that maps to the right places on an external card!
Yes, Martin Lukasek has done that, except that he removes the original RAMs and plugs an overhead daughterboard into the SC/MP socket. It may depend on the PROM images at 0200 - 07FF already being absent (his replica is of the issue V PCB. I still have not established whether the issue V did or did not have this mod incorporated).

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

Slothie 20th Dec 2018 4:02 am

Re: MK14 schematic revisions
 
Quote:

Originally Posted by SiriusHardware (Post 1103132)
I remember that the 2114 was different in terms of chip select lines and so on, but I am suggesting - maybe not on your initial V1.1 revision, but on V2.0, that you rearrange it so that it -only- uses 2114s since all of the 256-byte 4-bit types are becoming economically unobtainable.

Thats pretty much what I was thinking... I would end up with 2 versions, one "authentic" and one thats possible to put together from more available components. If was doing that then I'd think about adding a footprint for a 2716 EPROM since its not given that the TESLA proms are going to be around forever...

Quote:

Assuming you are still going to use BPROMs to hold the monitor code then you might consider using a third BPROM as a custom address decoder to generate with one IC the awkward chip enable intervals which would otherwise have to be generated with a 74138 plus more logic. (You may have your Tesla programmer up and running by that time).
My concern other than availability would be that the BPROMs may not be fast enough when its access time is added to that of the RAM and Monitor ROM, but that would be something that would be easy enough to try out, and would make fully expanding the MK14 to 512b prom + 3k RAM possible, and would make many more complex VDU projects feasible (Like MK14 space invaders ??!!)

Anyway, since I now seem to have a decent collection of SC/MPs I don't see why I shouldn't build a number of variants! I'd like to see a small computer with NIBL on it and a very simple display. I do have some 9 digit 14 segment alphanumeric displays somewhere... :idea:

SiriusHardware 20th Dec 2018 10:13 am

Re: MK14 schematic revisions
 
Quote:

My concern other than availability would be that the BPROMs may not be fast enough when its access time is added to that of the RAM and Monitor ROM, but that would be something that would be easy enough to try out, and would make fully expanding the MK14 to 512b prom + 3k RAM possible, and would make many more complex VDU projects feasable (Like MK14 space invaders ??!!)
Don't get too ambitious, the dot resolution of the VDU in graphics mode is not terribly high. 'Pong' might be a more realistic aim. ;)

BPROMs were used on the Nascoms, or at least one of them, as custom address decoders. They are actually surprisingly fast in terms of access speed - for that reason they were often used in things like video test pattern generators where the access speed of contemporary EPROMs might have been too slow.

However, as with all things that age they are becoming more expensive and difficult to get. GALs would be another option but only a small percentage of people have programmers capable of programming them. The parts would really need to be as ubiquitous as possible. A 'modern' fast EPROM might work just as well as an address decoder but it would come in a wide bodied footprint.

Slothie 20th Dec 2018 1:00 pm

Re: MK14 schematic revisions
 
Quote:

However, as with all things that age they are becoming more expensive and difficult to get. GALs would be another option but only a small percentage of people have programmers capable of programming them. The parts would really need to be as ubiquitous as possible. A 'modern' fast EPROM might work just as well as an address decoder but it would come in a wide bodied footprint.
GALs might be an option; my cheap 50 TL866CS/Minipro programmer will do Lattice GAL16V* and GAL20V* and Minipro works great on Linux under Wine with a modified DLL. Although obsolete too they seem to be far more available than BPROMS. Although I've never used GALs I have used CPLDs which are much the same. I'd have to find some logic compiler to generate the bitmap that the Minipro expects but I'm sure there's something out there for free. (Sadly the TL866 doesn't do BPROMS :-/ )

That said, if someones kitted themselves out with a programmer for Tesla PROMS for the monitor then programming an address decode PROM wont be an issue! eBay seems to be flooded with Tesla 74S571s at the moment, so perhaps I should get my act together and start looking at programming them!

SiriusHardware 20th Dec 2018 1:02 pm

Re: MK14 schematic revisions
 
.... nudge. ;)

Slothie 25th Jan 2019 1:34 pm

Re: MK14 schematic revisions
 
1 Attachment(s)
Hmm things are getting a bit tight....

SiriusHardware 25th Jan 2019 6:48 pm

Re: MK14 schematic revisions
 
Project impossible? (Within the established footprint, at least). Maybe that's why S.O.C. never did it despite it being the obviously right thing to do.

Slothie 26th Jan 2019 6:22 am

Re: MK14 schematic revisions
 
Probably not impossible if i'm prepared to rip up and re-lay some tracks. It would have been far more difficult for SOC without modern CAD tools, the board photos I've seen show they were most likely done with tape and transfers on acetate sheets by hand, so yes that's probably why SOC didn't. I haven't quite given up yet :)

SiriusHardware 28th Jan 2019 8:10 pm

Re: MK14 schematic revisions
 
I've just been looking around for maybe one or two pairs of spare DM74S571 PROMs to give me the option of occasionally using the MK14 for a dedicated purpose every once in a while - the price of Tesla PROMs has gone up to about 2+ 3 each and the seller I bought two 'real' (National Semiconductor) DM74S571 PROMs from for 6 each last May is now selling them for 16 each.

Elsewhere I found someone offering programmed pairs of PROMs for well in excess of 30 which I thought was ridiculous until I saw the price the DM devices are going for now (The devices being offered in that particular case are actually DM, not MH).

In the past, it was the price of original machines and the lack of availability of PCBs which held people back from building / owning MK14s. Before long it is going to become impossible for anyone to afford the parts to populate one. I can see a situation where eventually genuine MK14s in poor condition are being robbed for their parts to populate replicas or just to sell separately.

Timbucus 31st Mar 2019 2:49 pm

Re: MK14 schematic revisions
 
1 Attachment(s)
I can certainly vouch that the cost and difficulty of sourcing parts for a replica is rising, glad I am doing it now.

Just like to say thanks to all of you for the amazing amount of discussion on here around this little device. I am in the process, with the various signposted resources in the threads, of building at least one (as often I order two of something when the postage is the significant bit) based on a JM (Issue 0) board I bought, little did I realise how much time and money completing it would cost... and how much a mistake on the first key order would add, when the needed ones are no longer produced and therefore even more expensive - they are Multimec 3FTL6 or H9 as that is not documented elsewhere - they are hidden until the red keycap and the reproduction keypad housing.

I have not yet heard back from Martin on getting some pre-programmed PROMS but, I have included 2 on my order along with the 8060 and 8154 - if they turn out to be original (and blank...) DM then I would obviously need to find someone who can program them for me. Even better a pair of the Tesla ones which I have, although I read in other threads are proving difficult to find / create a programmer for...

I attach a photograph of the board so far - there appear to be no shorts between any data or address lines etc and 5v/Gnd is correct on the sockets but, I can do little more until my CPU, RAM and programmed PROM's arrive. The connector at the top was a way to connect power and to build the Single step circuit / have dupont access to the I/O connections. I also have the parts on order to make the clever keyboard / PI programmer from SiriusHardware as I am sure I will get tired of the hex data entry...

The display is a modern one which I gave into as I did not have the heart to rip apart the Text880 I bought, as it still actually works...

SiriusHardware 1st Apr 2019 12:00 am

Re: MK14 schematic revisions
 
Welcome Timbucus, nice to have another potential MK14 user on the forum. As you may have read elsewhere, if your PROMs turn out to be blank National Semiconductor (DM prefix) parts then I can program them for you - all I ask is a stamped, addressed jiffy bag to send them back in. PM me if / when you get to that point.

There are at least two forum members who are intending to make stand-alone, possibly Arduino based programmers to handle the Tesla versions but those projects have not, as far as I know, come to fruition yet. Unfortunately, real life tends to get in the way.

For my project to build Karen O's PIC14 hardware MK14 emulator, I bought a Texet 880 which was honestly advertised as having one broken key (and therefore very cheap), so I didn't feel too bad about removing the display from it - but I did it in a non destructive way and kept the rest, so it could be restored at some point.

As to sourcing other parts, it's possible that some forum members who have already trodden this path may already have bought more parts than their replica needed, either because they were sold as a lot or to make the postage a more reasonable fraction of the cost. If you can let us know of any outstanding parts you still need, maybe someone may have some surplus to requirements which they would like to move on to offset the cost of their own replica.

Timbucus 1st Apr 2019 7:32 pm

Re: MK14 schematic revisions
 
Thank you very much for the warm welcome and the offer to blow the PROM's! Fingers crossed.

My 2111 chips arrived today - when I looked I had only one in my electronics collection (hoard from attic), which was not MM. Also didn't have most of the other 74 series either despite a fair range...

I did however have some offcuts of connectors including a single sided 15way that if I miss Pin 1 (as 2 is also 0v) will work for the Keyboard programmer... by luck Pin six was the Keyway which I don't need connected...

I will reach out if any further bits are needed.


All times are GMT +1. The time now is 9:03 pm.

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