Mystery Nat Semi PROM & RAM Module

[Realtime]

Hi, I'm hoping someone can help me identify what system this module may have been part of and what the bus interface is.


Here's what I know:

Nat Semi part number: 980304433-001
Edge connector: 2 x 40, 0.125" pitch (in the photo Pin 1 is bottom, Pin 2 is component side, both on the right hand side)
Module size: 8.5 x 5.4 inches
Board thicknes 1.6mm
8KB PROM in two 4KB banks (16 x MM5204Q's)
512B SRAM (4 x 2101's)
8 bit data bus, 16 bit address bus, 3 bit card ident (?).

The attached pinout is incomplete but should give enough to match it to a backplane standard, if indeed it is a standard. The distribution of address and data looks a bit random.
Pins identified as High_Addr_Bit are A9 to A15, I just haven't worked out which is which yet.
Pins identified as RAM_Addr_Sel are used to define where the RAM sits in the address map (decoded by the DM8130 10 bit comparitor).
There are 3 additional inputs on the DM8130 that could be Card_Ident pins, so there could maybe have been 8 of these modules installed in a system.
Pins identified as PROM_Addr_Sel define where the PROM (or maybe each bank of PROM) sit in the address space (decoded by the DM8131 6 bit comparitor).

Any help and suggestions much appreciated.

[ortek_service]

Well this does seem to be a rather non-standard board, as 80way 2row bus connectors - especially 0.125" pitch - are not that common on Computer expansion / backplane buses, compared to more standard 50way / 100way etc ones.
And the STD(-80) bus for 8080 systems (That NS also second-sourced CPU's etc https://en.wikipedia.org/wiki/STD_Bus is actually 56way.
- With other buses referenced to at the bottom of that webpage , also not matching.

Plus Intel Multibus, that NS produced some boards for, is two different pitch connectors: https://www.digibarn.com/collections/systems/homebrew-multibus-8080/index.html


I do have this good book: https://dn721706.ca.archive.org/0/items/Bus-TheS-100andOther...es-ElmerCPoeandJamesCGoodwinOCR.pdf
that summarises many other non-S100 buses, as well.
- But your NS board's connections doesn't match the only 80way ones on the TRS80 Model II & CBM PET in there.

There is a date ordered database list of vintage computer boards: http://www.epocalc.net/php/liste_models.php
- But the National Semi ones around 1978 (date code of IC's on your board) which are BLC-80 (Intel Multibus) / SBC 80, don't seem to match your boards connectors. With IMP-16L system using 144way and wider-cards:
http://bitsavers.informatik.uni-stuttgart.de/components/nati..._Users_Manual_Preliminary_Apr74.pdf



I did have a look through some old NS Memory Databooks from 1976, 1977, 1978 & 1980, that are here: http://www.bitsavers.org/components/national/_dataBooks/
https://bitsavers.org/components/national/_dataBooks/

Where some of these have brief details on complete Memory Systems boards that NS produced. But all of these seem to be just RAM-Only.
There was some NS3000-(1/2) Advance-Info in 1976 book (but less-info on these, apart from picture, in the 1977 one, plus totally vanished by 1978 applications one! - That also has some NS400 ones with 60way 0.125" connectors)
- Which listed these as having 80way 0.125" pitch connectors. But two of these connectors, so a much wider card.
Plus they were also 20 / 18bits wide. And no 5.4" wide cards that are 8.5" long.
So maybe this board is a custom OEM design, that NS say they will produce?


BTW, Whilst looking through: http://www.bitsavers.org/components/national/_dataBooks/1978...al_Memory_Applications_Handbook.pdf
I did notice that there is a MM5204Q programmer for the LCDS design well-documented in there.


I also haven't found anything from a search of the 78-8016-xxxx part numbers on the EPROM's.
- But I wonder if you've tried reading these, to see if there's any ASCII strings in their data that may give a clue as to what it was for?

[Realtime]

Thanks for the detailed investigation, Owen. Some interesting links to NS product info there. Whatever system it was designed for would have had a processor card and possibly I/O and disk controller cards, so someone out there may have other cards of the same format. I tried a photo search but no useful results from that.

I did wonder if it was part of a development system, such as the NS Universal Development System (UDS) but I've not been able to find any detail about the card set used in that system.

Yes, I am aware of the LCDS programmer application note. NS sold a programmer module for the LCDS but I've not found any detailed info about it. I think it programmed bipolar PROMs, but not sure whether if it also covered the 5204.

I haven't investigated the PROM contents yet. When I do, I'll let you know what I find.

[ortek_service]

Yes, it would seem it must have been part of a larger Computer / Development system
- But a rather-proprietary one, given the lack of any info out there on it (Including any photos / images.

The UDS1 is maybe also a possibility, as that has 'Storage Boards' as well as many other boards. But this seems equally as elusive, with no pictures / manuals. And most info on this (unfortunately excluding card connector types) seems to be in this manual on the 8080 etc: http://www.bitsavers.org/components/national/_dataBooks/1978..._Microprocessor_Family_Handbook.pdf


The "PROM-Programmer for the SC/MP LCDS" (Pgs5-13 to 5-35 + 5-39) from the 1978 National Memory Applications Handbook (attached the extracted pages), does state "This application note describes for the user of the SC/MP Low Cost Development System (LCDS) a method of programming MM5204 or MM4204 Programmable Read Only Memories (PROMs) that is both inexpensive and highly efficient.".
- And is really only for MM(5/4)204 (E)PROM's rather than fusible-link Bi-PROM's (Where another App Note (attached) covering programming of those, just specifies some Non-NS Commercial-programmers).

This PROM-Programmer (23page!) App Note is very-extensive, including parts-list, schematics, and assembler-source (For both Terminal Interface and Front Panel entry versions on the LCDS). Plus it shows a picture of the assembled PCB (But unfortunately no track layouts or Assembly drawings). So I assume that is what NS actually sold as a 'PROM Programmer'

In the same 1978 Memory Databook, was a MM5204 EPROM-Emulator App Note (attached),which seems it was aimed at the Introkit etc.


Regarding this board, with the 16 sockets / 13pff fitted (Not sure if some are missing ? - But label numbers are mostly all-sequential despite the empty sockets amongst these)
number of MM5204Q 512Byte EPROM's on your board (So upto 8KB max), it does seem like it was for a quite-extensive system
- Probably more than just an SC/MP, without quite a bit of page banking.

Although only 512Bytes in Total of RAM - So it is maybe for more of an extensive debug-Monitor system, than for a standard computer? (Unless there was another RAM board to go with this).

[Realtime]

I've dumped each of the EPROMs and unfortunately there are no ASCII strings, so nothing helpful from that execise.

[ortek_service]

A little disappointing! - I presume it only came with 13off MM5204Q EPROM's, rather than all 16off fitted? So there couldn't be some missing that may have had soee strings in them?

And they didn't do anything-odd like swap the data / address lines around from standard, being as the edge-connector lines weren't exactly well-ordered?

Otherwise, it might be possible to see if any of these (Maybe one with lowest number on the label, assuming that one is lowest in memory-map) disassemble to anything sensible - possibly seeing if the code is 8080 etc being as that was maybe most-common on commercial systems back then and NS did also produce these so seems more-likely than 6800 etc.
(Probably a bit too-early in 1978 (with board's original design maybe much-older than that) for 6502 / Z80 to have got used that much - And NS also didn't seem to produced 2nd-sources for those).

[Realtime]

The board came with just 13 EPROMS, and one of them happens to be erased! Here's an example dump. Perhaps someone recognises which processor it fits.

[ChrisOddy]

Looks like 6502 ?, can you add a binary file rather than text and I'll disassemble it.

Chris

[julie_m]

Well, it started with 20, which is a common enough 6502 opcode; and as fate would have it, I've actually been working on a 6502 disassembler recently! So I tried disassembling this mystery EPROM. I didn't know where it's supposed to sit in memory, so I took a punt on 1000, and got this:

\ Recreation of "eprom_78_8016_0364_4.bin"

ORG &1000

\  Labels:
tl0002     = &0002
tl0020     = &0020
tl0027     = &0027
tl0068     = &0068
tl006e     = &006E
tl00c5     = &00C5
tl0620     = &0620
tl0fc8     = &0FC8
tl0fce     = &0FCE
tl0fcf     = &0FCF
tl0fda     = &0FDA
tl0ff9     = &0FF9
tl100c     = &100C
tl1074     = &1074
tl1079     = &1079
tl10a5     = &10A5
tl10a8     = &10A8
tl10d9     = &10D9
tl110c     = &110C
tl1129     = &1129
tl1133     = &1133
tl1145     = &1145
tl116a     = &116A
tl117d     = &117D
tl1218     = &1218
tl1239     = &1239
tl20f9     = &20F9
tl40ff     = &40FF
tld002     = &D002
tld50f     = &D50F
tld5f4     = &D5F4
tld9f0     = &D9F0

.tl1000     
    EQUS " " : EQUB &88 : EQUB &D5 : EQUB &0A : EQUB &02
.tl1005     
    JSR tld5f4
    ASL tld002
    LDY tl00c5
    BPL tl0fcf
.tl100f     
    EQUB &A4 : EQUB &90 : EQUB &A4 : EQUS "5" : EQUB &15 : EQUB &02 : EQUB &FF
    EQUS "  " : EQUB &12 : EQUB &D5 : EQUS "!" : EQUB &02
.tl101c     
    JSR tld50f
    AND tl0002
    BNE tl0fc8
.tl1023     
    CMP tl0027
    CPY #&A5
    BCC tl0fce
.tl1029     
    EQUS "5," : EQUB &02 : EQUB &FF : EQUS "(" : EQUB &80 : EQUB &9D : EQUB &1E
    EQUB &0A : EQUS " " : EQUB &00 : EQUB &90 : EQUB &9B : EQUS " " : EQUB &08
    EQUB &90 : EQUB &AD : EQUB &02 : EQUS " c"
.tl103d     
    BEQ tl0fda
.tl103f     
    EQUB &13 : EQUB &02 : EQUB &02 : EQUS " " : EQUB &00 : EQUB &90 : EQUB &9B
    EQUB &F4 : EQUB &AD : EQUB &C5 : EQUS ":" : EQUB &C5 : EQUS "h" : EQUB &80
    EQUB &9D : EQUB &13 : EQUB &0A : EQUS " " : EQUB &00 : EQUB &90 : EQUB &9C
    EQUS " " : EQUB &08 : EQUB &90 : EQUB &AE : EQUB &02 : EQUS " c"
.tl105b     
    BEQ tl0ff9
.tl105d     
    EQUB &13 : EQUB &02 : EQUB &02 : EQUS " " : EQUB &00 : EQUB &90 : EQUB &9C
    EQUB &F4 : EQUB &AE : EQUB &C5 : EQUS ":" : EQUB &0D : EQUB &81 : EQUS " "
    EQUB &80
.tl106c     
    BCC tl100c
.tl106e     
    EQUB &80 : EQUB &AF : EQUB &1D : EQUB &12 : EQUB &0D : EQUB &F4 : EQUB &D5
    EQUB &B5 : EQUS "?"
.tl1077     
    JSR tld9f0
    BMI tl107d
.tl107c     
    EQUB &C5
.tl107d     
    EQUS "y/" : EQUB &05 : EQUB &F2 : EQUS "n" : EQUB &9C : EQUB &0D : EQUB &87
    EQUB &04 : EQUS "{"
.tl1087     
    RTS 
.tl1088     
    EQUB &98 : EQUB &80 : EQUB &9E : EQUB &13 : EQUS ") c" : EQUB &0D : EQUB &EE
    EQUS " " : EQUB &08 : EQUB &0D : EQUB &EC : EQUB &D5 : EQUB &D7 : EQUS " "
    EQUB &C0 : EQUB &90 : EQUB &9D : EQUS "%" : EQUB &F0 : EQUB &1E : EQUB &05
    EQUB &1D : EQUB &03 : EQUB &C5 : EQUB &B5 : EQUB &D5 : EQUS "." : EQUB &D5
    EQUS "L" : EQUB &0C : EQUS "{" : EQUB &C5 : EQUB &9B : EQUB &80 : EQUB &9E
    EQUB &13 : EQUB &07 : EQUS "%" : EQUB &F0 : EQUB &1E : EQUB &88 : EQUB &1D
    EQUB &86 : EQUB &0D : EQUB &E6 : EQUB &D5 : EQUB &D7 : EQUS " " : EQUB &00
    EQUB &0D : EQUB &E8 : EQUB &0D : EQUB &EA : EQUB &02 : EQUB &80 : EQUB &AF
    EQUB &1C : EQUB &07 : EQUB &14
.tl10c5     
    ORA tl0020
    ORA (tl00c5, X)
    CPY tl0620
    BCC tl1079
.tl10ce     
    BCC tl107c
.tl10d0     
    EQUS " " : EQUB &07 : EQUB &D0 : EQUB &9E
.tl10d4     
    BCC tl1074
.tl10d6     
    EQUB &02 : EQUS " " : EQUB &00 : EQUB &90 : EQUB &9B
.tl10db     
    BCC tl1079
.tl10dd     
    EQUS " " : EQUB &08 : EQUB &90 : EQUB &AD : EQUB &90 : EQUB &AE : EQUB &02
    EQUS "g"
.tl10e5     
    LDA tl006e, X
    CLD 
    PLA 
    CMP tl0068
    BNE tl1155
.tl10ed     
    CMP (tl0068, X)
    CPY tl40ff
    RTS 
.tl10f3     
    EQUS "be" : EQUB &A4 : EQUB &FF : EQUB &FF : EQUB &FF : EQUB &FF : EQUB &FF
    EQUB &FF : EQUB &FF : EQUB &FF : EQUB &FF : EQUB &FF
.tl1100     
    ORA tl20f9
    BRK 
    BCC tl116a
.tl1106     
    BCC tl10a5
.tl1108     
    BCC tl10a8
.tl110a     
    EQUS " " : EQUB &03 : EQUB &90 : EQUB &98 : EQUS "%G" : EQUB &1D : EQUB &08
    EQUB &0D : EQUS "K" : EQUB &80 : EQUB &98 : EQUB &11 : EQUB &F7 : EQUB &02
    EQUS " " : EQUB &03 : EQUB &90 : EQUB &9D : EQUB &0D : EQUS "$" : EQUB &0D
    EQUB &F7 : EQUB &02 : EQUS "f" : EQUB &89 : EQUS "f" : EQUB &C0 : EQUS " "
    EQUB &03 : EQUB &C0 : EQUB &9D : EQUB &12 : EQUB &ED : EQUB &14 : EQUB &05
    EQUB &0D : EQUS "M" : EQUB &C5 : EQUS "6" : EQUB &18 : EQUB &0A : EQUB &0D
    EQUS "O " : EQUB &FC
.tl1138     
    CPY #&9D
    BCC tl10d9
.tl113c     
    EQUB &02 : EQUB &0D : EQUS "Q" : EQUB &80 : EQUS "d" : EQUB &1D : EQUB &02
    EQUB &02 : EQUB &0D : EQUS "M" : EQUB &02 : EQUB &FF
.tl1148     
    RTI 
.tl1149     
    EQUB &FF : EQUS "AhFhghvh" : EQUB &85 : EQUS "fh"
.tl1155     
    EQUS " " : EQUB &0C : EQUB &C0 : EQUB &9D : EQUB &12 : EQUS "B" : EQUB &1B
.tl115c     
    BPL tl117e
.tl115e     
    EQUB &11 : EQUB &F0 : EQUB &9A : EQUB &13 : EQUB &02 : EQUB &02 : EQUB &80
    EQUB &9D : EQUS "!" : EQUB &1C : EQUS "T"
.tl1169     
    BCC tl1108
.tl116b     
    EQUB &02 : EQUB &1A : EQUB &15 : EQUS " ["
.tl1170     
    BEQ tl110c
.tl1172     
    EQUB &13 : EQUB &02 : EQUB &02 : EQUS " " : EQUB &05 : EQUB &D0 : EQUB &9D
    EQUB &90 : EQUB &9D : EQUS "  " : EQUB &D0
.tl117e     
    EQUS "d"
.tl117f     
    BCC tl11e5
.tl1181     
    EQUB &02 : EQUS "%G" : EQUB &1E : EQUB &0C : EQUS " s"
.tl1188     
    CPY #&9D
    BCC tl1129
.tl118c     
    EQUS " " : EQUB &00 : EQUB &90 : EQUB &9A : EQUB &02 : EQUB &80 : EQUS "d"
    EQUB &1E : EQUB &F2 : EQUS " " : EQUB &CF
.tl1197     
    BEQ tl1133
.tl1199     
    EQUB &13 : EQUS "M" : EQUB &02 : EQUB &80 : EQUS "d" : EQUB &1E : EQUB &03
    EQUB &C5 : EQUB &86 : EQUS " " : EQUB &B3
.tl11a4     
    CPY #&9D
    BCC tl1145
.tl11a8     
    EQUS " " : EQUB &04 : EQUB &D0 : EQUB &9D : EQUB &90 : EQUB &9D : EQUS " "
    EQUB &BF : EQUB &C0 : EQUS "d"
.tl11b2     
    BCC tl1218
.tl11b4     
    EQUB &02 : EQUB &80 : EQUB &9D : EQUB &1D : EQUB &06 : EQUS " " : EQUB &00
    EQUB &90 : EQUB &99 : EQUB &02 : EQUS " U" : EQUB &F0 : EQUB &99 : EQUB &13
    EQUB &02 : EQUB &02 : EQUB &80 : EQUS "d" : EQUB &1A : EQUB &14 : EQUS " "
    EQUB &02 : EQUB &D0 : EQUB &9D : EQUB &90 : EQUB &9D : EQUS " " : EQUB &04
    EQUB &D0 : EQUS "d"
.tl11d3     
    BCC tl1239
.tl11d5     
    EQUS " " : EQUB &FE : EQUB &C0 : EQUB &9D : EQUB &90 : EQUB &9D : EQUB &02
    EQUS "%G" : EQUB &1E : EQUB &0A : EQUS " " : EQUB &CF
.tl11e2     
    BEQ tl117d
.tl11e4     
    EQUB &13
.tl11e5     
    EQUB &02 : EQUB &02 : EQUB &05 : EQUS "S " : EQUB &DF : EQUB &C0 : EQUB &9D
    EQUB &90 : EQUB &9D : EQUS " " : EQUB &80 : EQUB &D0 : EQUB &9D : EQUB &90
    EQUB &9D : EQUB &C5 : EQUB &B9 : EQUS "n" : EQUB &D4 : EQUS "n" : EQUB &A0
    EQUB &FF : EQUB &FF : EQUB &FF : EQUB &FF : EQUB &FF

SAVE "eprom_78_8016_0364_4.rec",&1000,&1200,&1000

Maybe it's not 6502 after all ..... Anyway, here's a zip archive with a binary version derived from the hex dump. eprom_78_8016_0364_4.zip

[ortek_service]

Well I hadn't really expected it to be 6502, as NS were never really into that (Or 6800, which I couldn't find an opcode 20h for).

However, 20h on the SC/MP is apparently LDI (Load of Acc. with Immediate-addressing mode value in the following Bytes).
Which makes a bit more sense to do a Load of the accumulator first, rather than immediately calling a subroutine.

And Realtime mentioned that the 8KB on this is split into two 4KB Banks, which might mean it is designed for SC/MP Pages?
- Not sure where the 512Byte RAM is mapped? (Maybe on a 3rd page?)

[TonyDuell]

Originally Posted by ortek_service

However, 20h on the SC/MP is apparently LDI (Load of Acc. with Immediate-addressing mode value in the following Bytes).

It can't be. The MSB of an SC/MP instruction is set for a 2-byte instruction, clear for a 1-byte one. So LDI, beign 2 bytes long (opcode and immediate data) must have the high bit set (in fact 0xC4 is LDI)

I can't find 0x20 as a valid SC/MP instruction

[ortek_service]

Originally Posted by TonyDuell

It can't be. The MSB of an SC/MP instruction is set for a 2-byte instruction, clear for a 1-byte one. So LDI, beign 2 bytes long (opcode and immediate data) must have the high bit set (in fact 0xC4 is LDI)

I can't find 0x20 as a valid SC/MP instruction

In that case, it looks like Google's AI got it wrong again!
- As when I Googled "national semiconductor SC/MP opcode 20 hex" , to see what that was, it's first (AI) result said:

The SC/MP opcode 20 hex corresponds to the LD (Load) instruction, which loads the value of a specified byte into the accumulator (the primary internal register for most data operations). This instruction is a simple way to bring data into the CPU's immediate use for subsequent operations.

Instruction Format
Opcode: 20 (hex)
Operand: The instruction is a two-byte instruction where the second byte specifies the data to be loaded into the accumulator.

Example
If an SC/MP program encounters 20 05, it would load the hexadecimal value 05 (or the decimal value 5) into the accumulator.

Although if I change '20 hex' to '0x20' in that search, it then says:

The SC/MP opcode 0x20 is not a recognized single opcode but rather the first byte of a two-byte instruction, which, when combined with a second byte, forms an indexed store instruction (specifically, STO or Store to PC<0xC2><0xAD>relative memory<0xC2><0xAD>). The 0x20 byte contains the opcode itself, and the subsequent byte specifies a signed 8-bit offset that is added to the Program Counter (PC) or an index register to determine the memory address for storing the data.

How the Instruction Works
Opcode (0x20): The processor recognizes 0x20 as the initial part of an indexed store instruction.
Offset Byte: A second byte follows the opcode, which is a signed 8-bit value ranging from -128 to +127.

Looks like the search continues, if this isn't correct.

[Realtime]

Originally Posted by julie_m

Maybe it's not 6502 after all ..... Anyway, here's a zip archive with a binary version derived from the hex dump. Attachment 319948

Thanks for going to the trouble of trying that. It's all useful info.

Originally Posted by ortek_service

And Realtime mentioned that the 8KB on this is split into two 4KB Banks, which might mean it is designed for SC/MP Pages?
- Not sure where the 512Byte RAM is mapped? (Maybe on a 3rd page?)

I've done some more decoding of the circuit and the 8K bytes of PROM is one continuous block and can be placed at any 8K boundary. The 512B RAM can be placed at any 512 byte boundary, including overlapping the PROM. If it does overlap then the RAM takes priority.

Originally Posted by ortek_service

In that case, it looks like Google's AI got it wrong again!

I've pretty much given up using AI for anything technical and certainly don't take it as gospel. It's probably OK if you need to know what colour lipstick Taylor Swift was wearing yesterday but most of its technical "knowledge" seems to be rehashed incomplete snippets of data packaged to sound somehow clever.
Rant over

[Phil__G]

20h is one of the serial I/O SC/MP pseudo-ops in Karens PICL emulation, chosen for the very reason that its not an SC/MP opcode
I can usually recognise SC/MP, 6800, Z80 and 8080 binaries on sight, so I'm thinking maybe a few random erased bits?
Normally that would be 1's that should be 0's but I've a vague recollection of some very old eproms where thats reversed, dunno about the 5204 without looking it up

[julie_m]

Originally Posted by Realtime

Thanks for going to the trouble of trying that. It's all useful info.

No worries -- I've literally been working on a crude BBC Micro / 6502 disassembler, nard (still under active development) lately, and was glad of a chance to try something in it!

"20 88 D5 .. .. 20 F4 D5" looked plausibly 6502-ish at first blush; &20 being [b[JSR[/b] -- jump to subroutine, pushing a return address onto the stack -- and &D588 and &D5F4 could easily be subroutine entry points. But 0A 02 is not valid 6502 code; well, &0A is ASL A, arithmetic shift left accumulator (importing 0 into LSB and exporting MSB into carry), so that is valid 6502 code, but &02 is very much not valid -- it's one of the 6502's killer instructions, that hangs up the processor.

Originally Posted by Realtime

{M}ost of {AI's} technical "knowledge" seems to be rehashed incomplete snippets of data packaged to sound somehow clever.
Rant over

It manages to make people think it knows what it's talking about, but that's just how it's programmed: to imitate an actor playing the part of a passionate authority on a subject, as eager to teach as you are to learn. But GIGO still applies. AI might make an OK lieutenant, but it's a lousy captain.

Anyway, back on topic, I think we can say we've eliminated one line of inquiry.

[ortek_service]

Regarding the '78-8016-0364-4' example ROM dump, this appears like it might be in the middle of the code. As looking at all the numbers on these, and putting them in order (as PCB layout looks a little random, and no Reference Designators to make sense from) , you get:

78-8016-0358-6
78-8016-0359-4
---------
78-8016-0361-0
78-8016-0362-8
78-8016-0363-6
78-8016-0364-4 (Only 1 with contents on here so far)
78-8016-0365-1
78-8016-0366-9
78-8016-0367-7
78-8016-0368-5
---------
78-8016-0370-1

and

78-8019-1002-3
---------
---------
78-8019-1005-6

Strangely there appears to be 4 gaps in the sequential numbers, but only 3 EPROM's missing.
- So if the missing ones were originally there, and had numbers in the 'gaps' then there must have been one 'jump' in the sequence.
I'm not sure what the end-digit on the labels is (Maybe a check digit? - but not a great one!)
And also a bit strange that it seems there is a block of 12? sequential 78-8016-03xx-x numbers and then a block of 4 78-8019-100x-x ones.
Plus a little-odd that the labels aren't over the windows, so maybe they have got partially-erased? (Usually '1' on EPROM's)

I wonder if the contents of the first one was looked-at, then maybe that one would most-likely contain the start of the code?

I had also tried Googling for the Z80 & 8080 Opcodes that corresponded to 20h
(Where their AI result also seems to get that totally-wrong - So maybe not much hope for their AI being about to auto-recognise what processor the code is for, that you might think AI would be ideal for?).
But I wasn't too-convinced that code would start with ones I found - But maybe need to really look at the start of the code? (Assuming it is actually processor-code, and not just a large look-up table etc.)

There wasn't too-many processors back then to choose from,
But NS did have quite a few not widely used, like their IMP-8/16 ones.



I

[Realtime]

I've pretty much completed the reverse engineering of the module now - updated pinout attached. There are 2 features of the pinout that may help identify the bus.

1) it uses an inverted Rd/Wr signal, so 0=RD 1= WR. Unusual.
2) It has separate 8 bit data_in and data_out busses

I built an interface cable for the LCDS and can set the PROM and RAM base addresses (with DIP switches) and read back the PROM and RAM contents. I've had to invert the LCDS (SC/MP) active low write data strobe to be compatible with the module. Unfortunately, the on-board 2101 SRAMs have their Output Disable (OD) pins permanently tied to GND, which means the board can only be used with separate data_in and data_out busses (the LCDS has a standard bidirectional bus). Adding an external buffer to the data_out bus, that is disabled during writes, would solve this. Alternately, a cludgy Sinclair-like resistor bridge between input and output busses might also work?

I need to generate a schematic for the board. I also need a killer 8K SC/MP application to install on the card. Any suggestions?

[Realtime]

I used a GAL22V10 to create a bidirectional data bus and invert the nWR signal. The converter cable (and GAL) is now housed in a box that allows the module to plug into the LCDS and also includes DIP switches for setting the ROM and RAM base addresses. The memory module looks to be fully working.

I'll post the schematic here soon, in case it's of interest to someone in the future.