MK14 memory

[Phil__G]

I wonder if anyone has used these SCM5101E static ram chips in a MK14?
These have been in a bag labelled "MK14 ram" for so long I cant remember where they came from... the datasheet looks very MM2111...
Cheers
Phil

[Mark1960]

Until you look at the pinout, or even just count the number of pins.

I have a few of these in my spares box, and might even have had some connected to my original mk14, when I had ribbon cable connected. The 5101 is pin compatible with 2101 and has separate data inputs and outputs so a little easier to use with the intel 4040 and 4289. Also one of the first cmos srams that can be used with battery backup so I think were in production for a few years after the 2101.

[SiriusHardware]

Phil, I have PMed you about a reasonably priced option for RAMs.

[Phil__G]

Thanks G I'll follow up that tip
Meanwhile I found a single TC5501
...and a pair of 2114's (ground a couple of address lines?)

[SiriusHardware]

As I'm sure you know, you need to fit the RAMs in pairs so a minimum of two but ideally four are required. I did suggest to Slothie that if there was ever a further revision of this PCB maybe he could re-jig it to work with much more obtainable 'lookalike' 2114 RAMs, even if only 256 locations of each chip were actually used, because the 2111 and equivalents are so expensive and hard to find now. I think there is something significantly different about the control pins on a 2114 - a different number of enables, or R/W handled differently, something like that, which would need a bit of a redesign to accommodate them.

You can also look out for AMD AM9111s, they are also drop in equivalents for 2111, but even they are difficult to come by now. Also very rarely seen Siemens SAB2111, which I can't even find a reference to on Google now.

[Phil__G]

Taking up G's tip I've ordered a batch, so I will have a few spares if anyone else is looking for MK14 ram. Meanwhile, somewhere here I'm sure theres a box of 40-year-old TTL but its managed to evade capture so far...

[SiriusHardware]

One cautionary note, the RAM Phil is referring to is ONLY usable in an issue VI replica MK14 PCB, which specifically allows for an alternative to 2111 types. They can't be used in any other replica PCB.

[Phil__G]

Trying to understand the VDU principle, does this look right?

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

...and the TOPPAGE output would be connected to the PS1 input to use 0200-03FF as contiguous VDU memory?
Ta
Phil

[SiriusHardware]

Looks right to me, and yes that's what TOPPAGE is primarily used for although you can ALSO connect it to other VDU inputs at the same time, for example to the Graph/Chars input to get a screen which is half characters and half graphics.

You can also take TOPPAGE to the SWAP PAGES input, and in fact to put 0200-03FF on the top half of the screen and 0400-05FF on the bottom half of the screen, I think you have to.

[Phil__G]

In graphics mode I understand its 64 x 64 pixels so 64 lines of 8 bytes per line?,
and that within each horizontal 'cell' bit 7 of each byte (ie the ms bit) is towards the left of the screen, bit zero to the right?

200-207 line 1
208-20F line 2
210-217 line 3
218-21F line 4
...
3E0-3E7 line 61
3E8-3EF line 62
3F0-3F7 line 63
3F8-3FF line 64

with each line:
 byte0   byte1   byte2   byte3   byte4   byte5   byte6   byte7 
7654321076543210765432107654321076543210765432107654321076543210

and in text mode its 16 bytes per line (bits coming from the char gen) and 32 lines?

200-20F line 1
210-21F line 2
220-22F line 3
230-23F line 4
240-24F line 5
250-25F line 6
...
3D0-3DF line 30
3E0-3EF line 31
3F0-3FF line 32

... in both cases assuming the TOPPAGE output is connected to the PS1 input?

Ta !
Phil

[SiriusHardware]

Yes, that's all correct. In practice, the gap between one character line and the next in character mode is uncomfortably small, so for actual text output it is sometimes more agreeable to leave a blank line between each line of text and treat it as a 16 character wide by 16 line display.

The attached mock image (#1) of a 'graphically enhanced' Moon Landing game illustrates this point, as the lines of text in the lower half of the screen are separated by blank text lines. You can imagine how cramped it would look if the text was on adjacent lines.

The 'game' doesn't actually exist, I just loaded the half-screen-high 'porthole' image into one 256-byte block and the prepared text into another 256-byte block and connected TOP PAGE to one of the 'PS' input lines and to Graph / Char to switch the VDU from graphics mode to character mode half way down the screen just to prove that that feature did work, as explained earlier.

Image #2 is an early test of the VDU in character mode rendering from offboard RAM at 0200-03FF. Here, I had typed the MK14SCI character codes for '0200' and '0300' into the first few bytes of those address blocks just to prove that those address blocks were being rendered to their expected places on the screen, but you can see how close together the character lines are.

[SiriusHardware]

Quoting myself in post #9:

in fact to put 0200-03FF on the top half of the screen and 0400-05FF on the bottom half of the screen, I think you have to.

Got into a bit of a muddle there, the correct values ought to have been 0200-02FF and 0300-03FF, but you've already worked that out anyway.

[Phil__G]

Thanks G, I think I have a better idea of how it works now

[ortek_service]

Originally Posted by Phil__G

I wonder if anyone has used these SCM5101E static ram chips in a MK14?
These have been in a bag labelled "MK14 ram" for so long I cant remember where they came from... the datasheet looks very MM2111...
Cheers
Phil

They might have come from an NS Introkit - As that used a pair of these.
And so might be able to get these to work in a quite-similar architecture / circuitry MK14 - Although unfortunately the 5101 / 2101 are in a wider / more pins / different pinout package than the 2111 (which itself is a little unusual, in having the ground pin shifted up by one pin from the bottom left).
I should have a couple of spare 2101's to maybe try, as someone swapped me four 2101's for 2off 5101's (that they wanted for Arcade machines battery-backed RAM) which were originally in my Introkit, as that didn't really need the very low-power ones.

I did think about making some adaptors to use 2114's, as much easier to get hold of (Plus I've already got quite a few of) in place of the 2111's that weren't that common even back in the late 70's.

[ortek_service]

Originally Posted by SiriusHardware

Phil, I have PMed you about a reasonably priced option for RAMs.

Originally Posted by Phil__G

Taking up G's tip I've ordered a batch, so I will have a few spares if anyone else is looking for MK14 ram. Meanwhile, somewhere here I'm sure theres a box of 40-year-old TTL but its managed to evade capture so far...

Originally Posted by SiriusHardware

One cautionary note, the RAM Phil is referring to is ONLY usable in an issue VI replica MK14 PCB, which specifically allows for an alternative to 2111 types. They can't be used in any other replica PCB.

Can someone remind me of this possible alternative's part number ?
(I think it may have been mentioned in a previous thread / seem to recall that it didn't work with the VDU?).
And I wonder how practical it would be to mod other replica's to accept these, that this issue VI replica has been designed to be able to use?
- I might be interested in buying some, if they can be made to work with other replicas, without too much adapting.

I have previously discovered that JPG Electronics in Chesterfield? are selling MHS HM1-6561B-8 SRAM's at £9.69 (1off), £9.21 (2off), £9.01 (3off), £8.72 (4+) - But they're not listed on their own website, only on an online (buy it now auction) marketplace shop (as mistabargain)
And I thought these may well be an alternative to the 2111, but haven't thoroughly checked the datasheets / tried any of these yet.

[Phil__G]

Originally Posted by ortek_service

... if they can be made to work with other replicas, without too much adapting.

The incompatibility isnt in the replica MK14 Owen, its the way the VDU variant accesses its 'video' ram.
A genuine SoC VDU grabs the bus with NENIN, drops NRDS then scans through 256 addresses whilst NRDS is low. (twice)

Realview, Ortonview and Coolsnaz2's YAMK VDU card all do separate reads, ie one NRDS pulse per address location.

The key thing is that MM2111 will tolerate the SoC process, latched memory will not

[ I'm still catching up on MK14 stuff, I only learned about this yesterday mainly thanks to Sirius and many hours of reading!!! ]
Cheers
Phil

[SiriusHardware]

There is an extra logic IC on the issue VI to enable the choice between the original 2111 type RAM and the 6561 alternatives while at the same time retaining the active-low reset input on the keypad edge connector.

You can probably find the current diagram for the issue VI somewhere in Slothie's epic 'MK14 schematic revisions' thread which follows the development of that replica.

An issue VI fitted with 6561 type RAM can still work with an original SOC VDU or close replica of same IF the issue VI has offboard conventional memory such as a 6116 SRAM mapped into the 0200-07FF area and the VDU is set up to use that as screen memory. It makes more sense anyway for the screen memory to be 512 continuous bytes of memory.

[ortek_service]

Thanks for the info.
So it seems the 6561's I'd found still available, aren't quite a drop-in replacement on most replica's / the original, and do need some extra logic.

But if an off-board 6116 etc. is required (only when using 6561's, rather than 2111's?) to work with the (SoC etc) VDU, then I'm wondering if it's actually worth the expense of fitting 6561's ?
And maybe just use an external 6116 etc. (If that is large enough to provide all the normally required RAM, both for MK14 and VDU, in the right places in the memory-map), if normally always using the MK14 with the VDU. and not really needing it to run by itself.

[SiriusHardware]

The issue VI, alone of all the MK14 replicas available to date, has the system address, data and control signals available on the rear edge connector and so you are right, you could, in true Sinclair tradition, make a 'RAM pack' consisting of an address decoder and an SRAM large enough to span the whole required address range, something like a 6264, which will activate whenever an address within the address range of the standard, optional or offboard RAM (0200-07FF, 0B00-0BFF, 0F00-0FFF) is accessed and just not fit any onboard RAM at all. If you don't have the optional 8154 I/O RAM device you could also arrange for the 6264 to activate in the range 0800-08FF, there being no hardware registers to avoid in the lower half of that space if the 8154 is not fitted.

Taking it a step further, you could also put an EPROM on the offboard memory expansion and and arrange for the address decoder to activate that when the address falls in the range 0000-01FF, and now you've eliminated the need for those awkward, expensive bipolar PROMs as well.

Obviously Chris Oddy's MK14E will be the logical development of this idea since it will use slightly later wide bodied EPROM and RAM in place of the 'exotic' devices required by current replicas and they will be on the main PCB, not dangling off it on an expander PCB.

[Phil__G]

I'm half-sure I've seen such an external ram/rom PCB offered online, but it was before I got into this little avenue...