An Enhanced MK14 (MK14E)

[ChrisOddy]

The MK14 is still a very popular project, especially on this forum, but development is held back by its limitations, particularly with memory so with that in mind I have designed an Enhanced version which I have called MK14E.
I've tried to retain the essence of the original whilst making it easier to build and providing a flexible platform for future developments.

I have partly built a prototype (and it works) and thought it would be useful to post what I have done so far to see if there are any suggestions for additions/mods that could be usefully made ?

For instance I already intend to add a link so that coolsnaz2's 'cassette interface' can be connected.

So here it is: https://theoddys.com/acorn/replica_b...14e/mk14e.html

Chris

[SiriusHardware]

Brilliant Chris, this was always the logical next step, a 'respectful' but more practical replica using more easily obtainable / programmable EPROM, conventional RAM and plenty of it, and with all the most desirable enhancements, such as the buses properly routed to the rear edge (so far only previously featured on Slothie's issue VI).

I think you may rightfully be entitled to call this PCB the issue VII.

I see you have arranged for some variation in the 'balance' between the amount of EPROM and the amount of RAM in the 0000-07FF range.

I would suggest also making at least two different 512 byte segments of the EPROM link - selectable so that either SCIOS 2 (with cassette routines) or SCIOS 3 (with fast loader routines) can be placed at 0000-01FF by moving a link while still leaving 0200-07FF as RAM.

[Phil__G]

Excellent Chris
Maybe an INS8255 which is readily available, instead of the 8154?
Wouldnt be software compatible but how much software was written for the 8154? and at least you'd be able to control stuff. The 128 bytes of 8154 ram could be gated from the 6116. Just a thought.

[Mark1960]

You could use 74HCT series instead of 74LS.

74HCT193 doesn’t need NADS inverted. If you ground the up/down inputs this also gives you high and low page selects on the carry outputs. If you keep up input grounded then the down input can be used as an additional enable.

Maybe check what happens with vdu if pages are decoded. Take care not to make sudden changes to the address lines when nenin is raised.

74HCT573 could replace both 74LS157s and the two 7408s, which are also getting rare. You might need to add series resistors to limit display current.

6116s could have battery backup to save losing programs on power off. Links could allow battery backed ram to replace the eprom for mods to the monitor.

Would the serial interface need inverters to work with NIBL ?

[SiriusHardware]

Chris, I see on the notes for your replica VDU that you have changed the 74L86 to a 74LS86 - this has been discussed before because the L86 is so 'exotic' but it was noted that it has a much longer propagation delay than the LS86 and may have been chosen for that precise characteristic, its 'slow' speed, to introduce a needed delay without which the VDU may not run properly.

I suppose the way to find out is for someone with an original or close replica SOC VDU to try fitting an LS86 with pins suitably rearranged into the L86 socket.

I did also notice that there is an MK14E VDU in the pipeline as well, one which doesn't require the character generator IC.

[SiriusHardware]

On the subject of battery backup, there are 6116 pinout compatible SRAMS with built in battery backup, it may be simpler to choose to use one or two of those now that the chosen RAMs have a 6116 form factor.

[SiriusHardware]

I think the use of a non-8154 on the PCB is a step too far away from the original - there is existing software which uses the 8154 for VDU control, the 'Function Generator' program in the manual uses the 8154 to drive a D-A converter, I personally use it to drive a 2 line by 20 char LCD display although of course I could rewrite that to use any other connected I/O chip.

If you really want to play with other peripheral ICs such as 8255s and maybe a 6402 UART and a counter/timer or real time clock it might be better to have those on a 'Multi-I/O' PCB which can be slotted into the backplane. I'm sure Chris O would be only too happy to oblige with a PCB for something like that if there is enough interest, and if he ever has time.

[coolsnaz2]

Fantastic Chris,

Currently to build a MK14 replica costs approximately £350, it would be great if the cost can be reduced by half.

Here are a few of my personal suggestions.

I don’t think the memory at the original locations should be battery backed up, should be the same as the original.

I think the main PCB should have a slot for the 8154, and the 8154 replacement should be on the expansion board.

All programs in the original MK14 Training Manual should run with no modifications.

Expansion board should allow for USB Keyboard or USB Numeric Keypad.

Are the 7 segment displays upside down in the photo?

[ChrisOddy]

Thanks for all the replies, just what I wanted plenty of good suggestions !

I really want to keep as much of the original design as possible and of course maintain 100% software compatibility. So the 8154 has to stay but how about an expansion board a bit like the Acorn VIB with 6522, 8255 and a UART ?

I like the idea of being able to switch between SCIOS versions so will definitely look at that.

78L/LS86, I missed that the slower part might be there for a reason, something to look at when I have the VDU built.

I'll also have a look at the 74HCT573 though its then moving away from original ?

Battery backup is link-able so you don't have to use it ?

How would a USB keyboard interface ?

Not sure how much it would cost to build, unfortunately a big junk would currently go on the 8060 (£42 from Littlediode !).

and Ian you weren't supposed to spot that the displays are upside down ! annoyingly the only mistake on the board.

keep them coming

Chris

[Realtime]

Very exciting!

I think there needs to be a MK14 Rev VI memory map mode that still has the various mirrors of 8154 and KEYBD etc, but also makes space for the expansion RAM in 0x200 - 0x7FF. The reason being that some of the original programs don't always use 0x0800 for the 8154 base address and/or don't always use 0xD00 for the KBD/Display interface. Instead they use a mirror - perhaps just because they could or perhaps because it allows them to use relative addressing from one of the base areas in RAM (0xF00 / 0xB00). Whilst it's a bit of a niche situation the MK14E should make provision for it (IMHO). [In fact I think the MICOM Assembler is an example of putting the 8154 at a different address].

And..... why not fit 32K E(2)PROM and 32K RAM on the base card and do away with the expansion card memory? Just seems it would then leave the backplane and expansion card free for more exciting options. I assume there is a GAL or CPLD being used for the memory decoding?

I would like to see a separate graphics LCD interface (I2C, SPI or maybe even parallel) to allow one to be connected instead of a VDU module with a separate display. Would make for a very compact solution and also allows for a fairly simple colour display to be generated, especially as there's so much EPROM available - all sorts of graphics routines could be included at some point including the LCD driver. Perhaps that's one for the expansion card.

Looking forward to seeing how this develops

[SiriusHardware]

A further suggestion, pin out for a 27(C)32(A) rather than 2716, why? -

1) - 2716 is getting a bit rare now to the extent that fakes are sometimes offered

2) - Too many people have low end USB powered programmers which simply can not supply the 25V VPP usually required by a 2716, but the same programmers can sometimes manage a 24-pin EPROM with 21V VPP (2732A?) and usually work OK with rarer 24 pin EPROMs with 12.5V VPP (27C32?)

* Most will be aware that you can use a 2732 'as' a 2716 by programming the data into the upper half of the chip because when placed in a socket intended for a 2716, the high address pin of the 2732 is held permanently high. However, it might be less confusing just to lay the PCB out for the 2732, then the device (whether standard, A or C version) can be programmed with the code starting at address 0000 as per normal expectations.

[SiriusHardware]

Quick Note: I didn't see Realtime's ambitious suggestion for EPROM and RAM when I suggested the relatively minor upgrade to a 2732 - same size but more obtainable and more programmable.

When it comes to things like this we need to beware of feature creep, we could end up with something which is almost entirely unlike an MK14.

While the removal of the various 'images' of the 8154 and keyboard hardware etc is something that SOC could and should have done back in the day I agree with Realtime that there needs to be a mode in which those images are present for compatibility with legacy software.

SOC did finally remove the ROM images occupying 0200-07FF on the issue V MK14 and published mods for how to do it on earlier issues, so the removal of those images and the provision of RAM or a mix of RAM and ROM in that space is 'canonical' and if you have a VDU, quite frankly, essential.

I like the way the existing mainboard proposal is still recognisably an MK14 at heart, but with almost limitless opportunity for expansion provided by the future backplane and add-ons.

Another thing I'd like to see further down the line is a prototyping board which can plug into the backplane.

[ChrisOddy]

thanks all, I am in the process of consolidating all the comments and looking at the feasibility of implementing them.

I agree with the comments from SiriusHardware on feature creep (we call it mission creep at work) a popular past time for engineers !, we shouldn't loose sight of the main objective which is to make an enhanced MK14 and not an all singing all dancing SC/MP computer.

There's potential for the board to have an awful lot of links making it confusing to use and a pig for me to test !

Chris

[Phil__G]

Question for Realtime, DavidMS and Coolsnaz, do you think an RP2040 emulation of the 8154 is feasible?

[SiriusHardware]

You haven't said how you are implementing the rather complex address decoding, perhaps with a GAL as was suggested earlier?

If the address decoder will be a programmed device you could always offer different variants of the address decoder, one which includes the historically correct 'images' of the 8154 and keyboard / display hardware and one which removes them - or - if it will be a programmable device then maybe it will be possible to include both behaviours by taking a single pin on the address decoder either high or low, so just one link for that purpose.

I think the most positive thing about this proposed revision is the way it does away with the 4-bit PROMs and 4-bit RAMs which are really expensive and hard to get now, they must pose the single greatest part of the expense for any prospective builder. The move to common-or-garden EPROMs or EEPROMs and bog standard 8-bit wide RAM will greatly reduce the overall cost of getting one of these up and running.

Yes, they significantly alter the appearance of the machine away from its original look - I did once suggest that a future revision of the issue VI might use 4 x 2114 which were visually similar 2111s but still quite easy to get, even if the extra capacity was wasted.

That wouldn't solve the PROM bottleneck and I think now is really the right time to advance the design a couple of years into its future, to what SOC might have done with it had they not diverted their resources onto the ZX80 instead.

[ChrisOddy]

All the logic is implemented in discrete TTL in line with the original.

[SiriusHardware]

Oh, very hardcore (I approve though, as using a GAL would just mean replacing one hard to obtain and programme device with another).

[DavidMS]

Originally Posted by ChrisOddy

All the logic is implemented in discrete TTL in line with the original.

Excellent, GALs have their place but it does put the design at risk of early obsolescence as suppliers seem to drop older GALs quite fast from production

[ChrisOddy]

I've been through all the comments and come up with some relatively simple changes that tick off most of the significant issues. I've created an Issues Log to keep track (attached).
By adding the option of using a 2732 that also provides a way of selecting one of two OS images for free by pulling A11 high or low.
By adding three additional links to the address decoding the original V5 phantom images can be put back, at the expense of RAM of course.
I've also added a line to the backplane 'I/O' which when pulled low disables the onboard I/O and memory so that off board circuitry can be inserted into the upper half of the Page 0 memory map.
See attached 2nd draft schematic.

[Mark1960]

You might consider changing the pullups to 20k, it looks like you can have as many as three pullups on A10 depending on link settings. 3.3 k pullup in addition to ls ttl inputs might be a bit much for the 8060 to drive. The pull ups are for static conditions with links removed so 20k should be enough.

For the ram shadows I think you need to disconnect address lines from the ram chips, otherwise the shadows are addressing different areas of ram.

Is there some way to simplify the address logic? Seems to be using a lot of gates.