MK14 memory

[SiriusHardware]

You may be thinking of the one offered for the Czech replica MK14s - it plugged into the CPU socket as a daughterboard and included RAM and program memory.

It was necessary in that case to adopt the daughterboard approach because the very authentic Czech replicas of the original issue V are so authentic that even they don't have the system buses and control signals routed to the rear edge connector.

I've not aware of anyone having made a similar add on specifically to plug into the rear edge connector of the issue VI, but happy to be corrected on that.

[Qbertni]

If you search that well known auction site for "Science Of Cambridge MK14 RAM and Tape I/F PCB and 3 ICs" you'll find a board that gives the full 1.5k of ram on a rev VI MK14. I have a suspicion that the seller is someone who frequents this forum. (it's not me)

[Phil__G]

Here's Martins board, including the GAL equations:
https://www.8bity.cz/2018/science-of-cambridge-mk14-1536b-ram-expansion/

[SiriusHardware]

you'll find a board that gives the full 1.5k of ram on a rev VI MK14

I know the one (and I know who) you mean but again that uses a daughterboard format, in which the CPU is removed, the daughterboard is plugged in in place of the CPU and then the CPU is plugged into the daughterboard.

I meant that I haven't yet seen one which just plugs into the rear connector on the issue VI in the fine tradition of the Sinclair RAM packs for an instant extra 1.5K of RAM. It is understandable that the commercially sold versions offered so far would adopt the daughterboard format because then their use is not limited only to issue VI PCBs, they can also be used directly in original issue V PCBs and the Czech replicas (and the 'Oddy') which are close clones of the issue V.

For original issue II, II, IV and their clones (such as JMP) which have 'images' of the PROMs present in the 0200-07FF memory area it would be necessary to modify the MK14 board to remove those PROM images from that memory range first before fitting the daughterboard.

[Qbertni]

Originally Posted by Phil__G

PS4  PS3  PS2  PS1     Address range
A11  A10  A9   A8
 0    0    0    0      000-0FF  SCIOS monitor prom 512 bytes      
 0    0    0    1      100-1FF  SCIOS monitor prom /
 0    0    1    0      200-2FF  standardised VDU ram top half of screen
 0    0    1    1      300-3FF  standardised VDU ram lower half of screen
 0    1    0    0      400-4FF
 0    1    0    1      500-5FF
 0    1    1    0      600-6FF
 0    1    1    1      700-7FF
 1    0    0    0      800-8FF  8154 I/O Ports -->87F, 880-8FF 128 bytes RAM
 1    0    0    1      900-9FF
 1    0    1    0      A00-AFF
 1    0    1    1      B00-BFF  Optional 256 bytes ram
 1    1    0    0      C00-CFF
 1    1    0    1      D00-DFF
 1    1    1    0      E00-EFF
 1    1    1    1      F00-FFF  Standard 256 bytes ram

Looking at the schematic as A9 and A10 aren't connected to the INS8154 doesn't it also appear at A00-AFF, C00-CFF and E00-EFF

[SiriusHardware]

Yes, there are multiple images of the 8154 as well, and some original owners of the MK14, notably 'circuitryboy' who pops up here occasionally, went so far as to modify their machines to remove those as well. Some of them are potentially quite useful, for example with a pointer set to 0F00 (start of standard RAM) or 0B00 (start of optional RAM) you could use a minus offset to reach into the I/O RAM image at Exxx or Axxx

[Phil__G]

The problem with removing images is that often the image has been used in preference to the documented 'real' address so to 'free up' the image could cause problems - 'Message' & 'Duck Shoot' etc in the SoC manual use the display image at D00 (D for display makes more sense to me) whereas I've seen the 'real' address documented as 900h

[SiriusHardware]

That's an interesting observation, I've only ever thought of 0D00 being the official keypad / display address because it is so often referred to as such in the manual. It just goes to show that the removal of some of the images could have unintended consequences, but the removal of the PROM images seems to be a reasonably benign act.

[ortek_service]

With so many options for images and locations of the RAM and IO (as well as the PROM's) - I think deciding upon the best way for doing this has mainly what ChrisOddy has been considering in order to finalise his MK14E design - I wonder if it might be more versatile to do the address decoding C64-style with a PLA?
- Or actually use a v.fast Parallel re-programmable memory IC such as the Winbond W27C512-45Z DIL28 (that people have used to replace that PLA which runs rather warm), which despite the '27' number normally being used for UV(/OTP)-EPROMl's, is actually a 45ns Electrically-Eraeable PROM, that uses a fast 100ms bulk-erase rather than byte-erase of standard EEPROM's or Block-erase of FLASH devices.
https://media.digikey.com/pdf/Data%20Sheets/Winbond%20PDFs/W27C512.pdf

Maybe not as retro as various jumper-links / 74 TTL logic IC's, but certainly the most versatile / re-configurable solution.
And can often obtain these from around £1 for a pair of working 'pulls'.

Although you'd need to write a small config program to build the look-up hex-dump to program into this. And they need 12V/14V to Program/Erase, so not too-well suited to In-System reprogramming (But having a PC-style 'BIOS setup' with a small uC etc, maybe over-complicating the MK14 a bit!)

[Mark1960]

You could use an sst39sf0x0, only 5v needed to program.

The 8060 is so slow you could probably even just use 450 ns eproms.

If you use a 1k x 8 dual port ram you might be able to let the mk14 change its own address decoding on the fly. The only problem would be initialisation.

[SiriusHardware]

If you wanted to stay in the same period you could use a third BPROM as a custom address decoder - PROMs are much faster than contemporary EPROMs, but apart from the expense and difficulty of obtaining and programming them (as per the OS PROMs) one extra PROM alone would add around 100mA to the power requirements.

[Buzby123]

I much more favour the Old Skool method of pins and jumpers to enable/disable parts of a circuit. I even prefer jumpers more than DIP switches, as the settings don't depend on the particular switch chosen by the designer.

Programmed devices are more suitable for a commercial product where settings are fixed before shipping. On a hobby product you should be able to see the settings just by looking at the board, without needing to connect any kind of progamming thing.

[SiriusHardware]

If you use a parallel ROM device (EPROM or whatever) as a custom decoder it will usually have more capacity than needed for the job and at least some of the high address lines would have to be tied in a fixed state, ie, low.

If the state of the upper address lines was made jumper selectable the memory device could be programmed with 2, 4, or 8 different address decoder setups, the memory device used would only need to be programmed once and the user could pick whichever of the programmed setups suits them.

I think this is pretty much the approach planned for the MK14E, which will allow the user to select from a preprogrammed set of memory configurations.

[ortek_service]

Yes, kind of like CB / 10m conversion EPROM's, where the upper address lines are used to select which block of 40 channels are mapped to PLL from the channel switch.
So you could maybe use links / DIP-switches / a Hex encoded 0..F 4bit PCB-mount rotary switch to choose from a set of common configurations (Hopefully < 16 should cover ones to work with all known programs).

Whilst just having links alone (that is seems Acorn System and Nascom cards often hadm to select base addresses etc) may make it difficult to also set where / how many any base-address images should also exist.


Using a Bipolar PROM would be rather retro, it would be rather inflexible having to reprogram / swap it for another, so probably wouldn't really offer much advantage over fixed TTL logic. Plus they wouldn't be large enough to have a complete look-up table for all of the address lines range.
And it seems that the ability to change the configuration easily, may be needed for compatibility with all existing programs without re-writing them.

[SiriusHardware]

Using a Bipolar PROM would be rather retro, it would be rather inflexible having to reprogram / swap it for another, so probably wouldn't really offer much advantage over fixed TTL logic. Plus they wouldn't be large enough to have a complete look-up table for all of the address lines range.

Bear in mind that the address decoder actually only needs to 'see' the state of the A8-A12 lines if you are looking for a minimum address block size of 256 bytes, so that's only 5 of the address bits (A8-A12) going to A0-A4 on the memory device being used as an address decoder. 5 address lines is a mere 32 locations within the PROM so even a 512-byte PROM like the 74S571 could hold a number of decoder configurations selectable by the states of the PROM's upper address lines. However with only 4 data outputs it might run out of 'Chip Select' output lines too soon, so better to pick one which is byte-wide rather than nibble-wide.

If you were looking to make your address decoder resolve individual addresses rather than memory block of size 'x' then yes, you would need a device with the same number of address pins as there are address lines on the system bus, but it would be unusual to want to do that. If you did, it would let you reserve very narrow address blocks of 1,2,4 addresses only for individual peripheral ICs which might be nice.

[Mark1960]

82S23 was often used as an address decoder, 32x8 bits seems quite well suited. They still have the problem of being one time programmable and needing a prom programmer.

75ls156 would let you decode 256 byte blocks for the top 2k and wire or the outputs with links to match the original mk14 decoding. 74ls159 would cover the full 4k but not very easy to find them now. 74ls154 could be used with diodes or gates to combine the outputs.

[Phil__G]

...or the old faithful GAL16V8, reprogrammable as many times as you like in your cheap TL866II...

[SiriusHardware]

I have at least two programmers which can programme GAL16V8 and a reasonable stash of the devices, but I have no idea how to generate the code to put into them. Is there something in the public domain which can generate the JEDEC files from some kind of source code?

[ortek_service]

I was aware of PALASM - a DOS Program for the original PAL.
And the (more-universal, manufacturer-independent ? - but expensive in its day) programming language: ABEL (Advanced Boolean Expression Language) .

However, it seems the GAL16V8 might (now) be a Lattice device, who are known for having free tools / Low-cost interfaces for their (CPLD/FPGA etc at least) IC's

And there's some recommendations on this similar discussion, here:
https://www.eevblog.com/forum/microcontrollers/gal-design-software/
https://www.eevblog.com/forum/microcontrollers/looking-for-palgal-dev-tools/
- Mainly (AMD / MMI) PALASM & (Atmel) WinCUPL

Plus maybe some useful info, here: https://www.ythiee.com/
- especially link to: https://www.ythiee.com/2023/01/08/lattice-ispgal-isplsi/
Which covers Lattice pDS (pLSI/ispLSI Development System) Software, for their more-recent ISP-GAL's
And also a long-list of the many (original, now old) PLD Compilers: https://www.ythiee.com/2021/06/06/pld-compilers/


Although, if you only run Linux, then might need to run under WINE etc emulation.
But maybe Lattice / others have native Linux versions of the design software (Many do these days, but maybe not so much back when PAL & GAL were widely-used)

[ortek_service]

It looks like the GAL16V8 was discontinued (by lattice at least) > 10yrs ago, with suggested replacements on this list: https://www.latticesemi.com/en/Support/MatureAndDiscontinuedDevices

But Datasheets are still there, which include suggestions for compilers for the various Simple/Complex/Registered/Auto-Mode sub-types: https://www.latticesemi.com/-/media/LatticeSemi/Documents/DataSheets/GAL/GAL16V8DataSheet.ashx?la=en