IBM 5110 RAM timings

[apl-vade-mecum]

The prototype 3D shells printed by SLS (Selective Laser Sintering) just arrived.

They look very nice, the keying is perfect, they fit right onto the A1 board sockets on the inside of the cage as well as the IO cable sockets

But the plastic tang doesn't retain the DuPont contacts, they slide in fine but slide right back out too

So I went back to my junk box & found a different 0.1" square pin socket, TE AMPMODU IV/V:

https://www.te.com/usa-en/product-102548-5.datasheet.pdf

Note the little metal tank sticking out near the front - we just need a hole for the retention tang. Simple fix, ordered couple more.

Anyway, if your friend printed a sample, I'd be interested in how it came out - what sort of plastic & process?

 

[Pitou]

I just got them 10 minutes ago! Yes they fit perfectly and I was about to ask what kind of pins to put in there. I'll look at your datasheet.
Plastic used was PLA using a 3D printer (Ender 3 Pro)

However I'm not sure this could work for cards. Can you give me an example how I could solder to the ram card for example?
For power plug it's perfect.
Thanks!

 

[apl-vade-mecum]

Oh, it looks like you are using real original IBM shells & contacts? Maybe from a donor card & you carefully soldered on each contact?

Agree it isn't obvious how to use with a PCB. I have been thinking of a thinner version, where the crimp pins can hang out the back of the shell and be bent down to solder onto pads on the PCB. A tab on the edge of the PCB slides into a slot on the shell so it can't move sideways. The shell could be glued to the card. Then just push 24 sockets in from the back, bend each to touch PCB, solder, and done - the shell holds the sockets in place so easy soldering. A couple prototypes should show up by Monday or so. I tried to make them fit the TE AMPMODU IV pins.

 

[stepleton]

Agree it isn't obvious how to use with a PCB.

Would it be worth reconsidering then some elements of my approach? Integration with a PCB at a right angle is intrinsic to my design; you get it "for free". Mechanical and electrical connections are accomplished with solder. With 24 individual solder joints, it's a pretty sturdy assembly.

I propose a combination: my approach of T-joined soldered PCBs with a shell like yours (appropriately shortened in height). I think it could assemble quickly and easily, perhaps the fastest of any of the solutions we've considered so far. The only thing we would need to find is the actual metal wire-to-board contacts that go into your shell; if those don't exist, it won't work.

Here is the three-step assembly procedure:

Step 1: Mate the connector PCB to your main circuit board in the T-joint configuration shown in this picture. Solder it in place.

Step 2: Stuff a shell similar to what you've designed with appropriate wire-to-board metal contacts. Presumably there are pins or tabs that protrude from each contact out of the back of your shell that allow affixing the contact to the board.

Step 3: Push those pins or tabs (sticking out of your shell) into holes in the connector PCB that you mated in Step 1. Solder.

(Does this description make sense? It can be hard to know if it's easy to understand.)

 

[Pitou]

Oh, it looks like you are using real original IBM shells & contacts? Maybe from a donor card & you carefully soldered on each contact?

Yes exactly.

I have yet to find the cause of my issue. I'm a bit puzzled.
I made 4 videos to show the differences.

2 with the homemade pcb normal and display registers boot up and 2 with the original card

Gofile - Cloud Storage Made Simple

Secure, fast and free cloud storage solution. Upload and share files instantly.

gofile.io

 

[apl-vade-mecum]

Hi Stepleton,

Yes I see advantages of your design. I started down the road of crimp-to-wire female wire wrap post contacts as one goal was to make up a power supply interposer cable (to easily measure current for each voltage) but for sure crimp-to-wire isn't ideal for a board edge.

One issue with your PCB has is that the contacts stick out well past the PCB so maybe it doesn't align with the black plastic A1 surround.

Also the female 0.1" sockets I see used on things like Arduino boards are low quality, don't grab well at all.

Consider MillMax machined sockets, those are the really nice ones often seen as wire wrap DIP sockets. So I phoned up MillMax product support and described the problem and they suggested this as a possible solution:

0305 - Receptacle | Mill-Max Mfg. Corp.

www.mill-max.com

It is a machined female spring contact to be press fit or soldered into a PCB. The male A1 pins go right through.

So your PCB but with holes for machined female sockets will have excellent retention, and now the PCB would be flush with the front of the contacts so it will sit down right into the black plastic frame on the A1.

Now we have exactly positioned 24 female contacts with excellent retention. No need for a 3D shroud.

Thanks for posting! I think your small PCB concept is better than a shroud for PCB and just use shroud for cables.

 

[stepleton]

I'm glad if my approach has some useful elements! I am not 100% certain of how to use the sockets you've described --- is there a way you could show what you have in mind via a drawing?

Currently, when viewed from the side of the PCB with the connector facing down, my current connector uses something that looks like this (using some Unicode art --- I hope it's viewable):

    ‖           ‖
    ‖           ‖
    ‖           ‖
    ‖           ‖
 =≐=‖=≐=     =≐=‖=≐=
 | | | |      |   |
 |_| |_|      |   |
 
  socket       plug

My guess is that with the contacts you've found, the resulting connectors will look like this (note that only the socket changes; the plug is unchanged):

    ‖           ‖
    ‖           ‖
    ‖           ‖
  _ ‖ _         ‖
 | |‖| |     =≐=‖=≐=
 | |‖| |      |   |
 = =‖= =      |   |

  socket       plug

If the retention is firm, that could work, but on the IBM 5100 (and probably 5110/5120) on connectors Y1, Y2, Y3, Y4 and Z1, Z2, Z3, Z4 (see top and bottom of this diagram), there is a retaining bracket that expects to press against the top of the connector shell, as seen in this photo. In Unicode art, that looks a bit like this when used with my current connector:

    ‖
    ‖  ┏━━━ bracket
    ‖  ┃
    ‖  ┃
 =≐=‖=≐=
 | | | |
 |_| |_|

  socket

If the socket connector looks like what I've drawn in the second diagram, then the bracket will not have something to press against. Again, this could be just fine if the retention is still quite firm, but the bracket must not foul the sockets both for mechanical and electrical reasons (the bracket is metal).

For pluggable cards like the memory card under development, there is no retention bracket, so this approach is still well worth investigating regardless of this concern!

 

[apl-vade-mecum]

Hi Pitou,

Yes, saw your videos. From reading the manuals, I think that the display card can show from either address 0 or the video buffer address 0x200-0x5FF, and the processor (CPU) card. And page 3-39 says the video card increments the address by 2 for each scan line. The data read back over the IO bus goes to a ROM on the video card which turns the 16 bits into dots on the screen.

So if 3-39 is accurate, somehow the address lines change from being driven by the CPU (to fetch instructions & data) to being driven by the video card. Still thinking why that would affect the reads on the memory card.

This is an interesting puzzle!

 

[apl-vade-mecum]

I have two SRAM showing up tomorrow:

https://www.renesas.com/en/document/dst/71016-data-sheet

They are soldered onto DIP wirewrap adapters. They are 16 bits wide, so I only need two (use 9 bits on each) plus the LS04 & LS32.

To help figure out why the circuit is not doing video, I'll try to wire-wrap a board. When I worked through your circuit I didn't see any problems (if you did make any logical change to your KiCad schematic please let me know

IBM uses multiple CS lines to pass address to memory, rather than encoding them as address bits. This is curious.

Oh one more question - did your flying leads (before PCB) work ok? If so that would imply we don't have any major signal integrity issues.

The address & data bits go all over the place to many cards, it could be marginal output drive from the SRAM that works with receivers on CPU card but not receivers on video card?

 

[Pitou]

Hi
Oh. I'm so sorry for that but I have overlooked your comment in post #30.

I started with chips back around 1978 (learning from the TTL Cookbook) and wire wrap boards, always nice to see stuff working before paying for a board. If your flying leads proto passed power-on, the PCB really should work first time

I didn't know what you meant by "flying leads". English is not my native language

Oh one more question - did your flying leads (before PCB) work ok? If so that would imply we don't have any major signal integrity issues.

So actually, *no*. It didn't work with the flying leads setup and this is for this exact reason I did a PCB, thinking that signal integrity might not be good or optimal with all the messy wires. Wires length, interference and such.

To help figure out why the circuit is not doing video, I'll try to wire-wrap a board. When I worked through your circuit I didn't see any problems (if you did make any logical change to your KiCad schematic please let me know

Thanks very much for doing one yourself. That will help me a lot and this will be good for comparison. I didn't change anything in the KiCad design.

The address & data bits go all over the place to many cards, it could be marginal output drive from the SRAM that works with receivers on CPU card but not receivers on video card?

That can definitely be the reason for it to work for CPU and not video. Like you said maybe different receivers on the cards. I just wish my SRAM chips "push enough" signal to be "readable" by the display card.

I will design another PCB with 2 chips, same as you. Since physical space is limited on this card, that will reduce number of traces significantly and will help me define a proper ground plane which I skipped in the first design.

Again, thanks very much and good luck with your test.
Pitou!

 

[Pitou]

One quick question about unused pins. I never know really what to do and I hear many differents ways of managing them.

Please tell me what would you recommend.

- Address lines tied to GND?
- Gates input tied to GND?
- Gates output tied to GND or left unconnected?
- Unused data pins on SRAM chip tied to GND, unconnected or I even saw using a 10k resistor to VCC since they are bi-dir?
- Decoupling capacitor for all chips or only the SRAM?

 

[apl-vade-mecum]

I'm not an EE but I'd suggest for TTL:
- tie unused address line inputs to VCC with around 10k ohm resistors
- tie unused gate inputs as above
- tie unused tristate (both input & output) SRAM data lines as above
- leave unused outputs unconnected
- use a typically 0.1uF decoupling for each IC

Unfortunately I think we're guessing w/respect to need for a ground plane (to limit noise), need for stronger drivers etc.

A scope to watch signal rise/fall/levels at the video card lines with original RAM card vs new prototype RAM card might be informative.

 

[Pitou]

I put the scope on different pins of the display card with both cards and the signal is identical.
I'll go with the redesign route...

 

[apl-vade-mecum]

When you you had the scope out, did you happen to peek at the "unused" pins on the M2 RAM socket? I wonder if there is some special signal that's not on the block diagram going to only the first RAM slot and related to the video region.

It is probably futile for me to try this in wire wrap as it will be worse (longer wires) than your PCB. But the rest of the parts should arrive Monday and I don't have any better idea.

Have you considered the address bits? Usually the CPU card drives the address bits and that seems to work fine. Exactly how and exactly when does the video card put its address onto the bus? The text description sounds like the video card has a counter that starts from a base address of 0x0 or 0x200 and counts up. But is that address driven onto the bus directly from the video card, or does it go to the CPU card maybe over one of the big top-of-card jumpers during cycle steal?

What's the "redesign route"?

 

[Pitou]

When you you had the scope out, did you happen to peek at the "unused" pins on the M2 RAM socket? I wonder if there is some special signal that's not on the block diagram going to only the first RAM slot and related to the video region.

Yes,
J03 is tied to +5v
B03 is tied to +5v
B11 is tied to +8.5v
G11 is tied to +8.5v
G13 is tied to -5v

all through a capacitor.

No activity at all on those pins

Have you considered the address bits? Usually the CPU card drives the address bits and that seems to work fine. Exactly how and exactly when does the video card put its address onto the bus? The text description sounds like the video card has a counter that starts from a base address of 0x0 or 0x200 and counts up. But is that address driven onto the bus directly from the video card, or does it go to the CPU card maybe over one of the big top-of-card jumpers during cycle steal?

The display card doesn't talk to ram directly. It talks to the cpu that talks to the RAM. I checked on the diagrams and the A1 plane itself.
You can take a look at section 420 of the diagrams PDF.

What's the "redesign route"?

I mean to redo the PCB using 2 SRAM chips instead of 4, proper ground plane and apply correct rules to unused pins.

 

[Pitou]

Ok, I finished prototype #2 and it works but I still have the display issue. What's strange is that the garbled display is consistent with each card but at the same time different.
I made a mistake for the resistor footprint so I didn't put them everywhere.

Here is a small video.

Gofile - Cloud Storage Made Simple

Secure, fast and free cloud storage solution. Upload and share files instantly.

gofile.io

I have to admit I'm kind of stuck.

 

[apl-vade-mecum]

Hi Pitou,

So as you've done an entire 2nd board build I think we can rule out wiring errors and most electrical issues.

I'm trying to think of a way to separate the video writes/reads from other writes/reads. An access within the 1k video region could be regular memory or video card initiated, cycle steal signal should say which. So using the high order 6 bits should be able to detect access in that 1k window, and then stare at the rest of the control signals...

I think our modern SRAM chips are asynchronous meaning you put an address on the address lines, enable the output, and a few ns later the desired bits show up. There is also the concept of synchronous ram where things change only on specific control signal edges, maybe IBM did it that way and the signals only differ during cycle steal in some not obvious way.

I'll try hooking up a logic analyzer over the weekend and keep you posted.

Oh one other thing - it looks like you have figured out how to reuse 24 pin original IBM socket shells. How do you remove the brittle black plastic shell without breaking it? Also, do you re-solder the original contacts to a new board by hand?

 

[Pitou]

Hi apl-vade-mecum,

Yes, the shell is very fragile and most of the time it does break. I managed to remove 4 of them but with some damages. So there is no real trick. Yes I did solder manually all the 48 little pins by hand. When pushing the plastic shell it does stay in place and fits well in the IBM. However when I remove the card the plastic shells stay in the IBM. I have to remove them using pliers and re-install. Actually, I forgot to cut the PCB keeping the little notch on each end of each connector (4 notches total).

Thank you very much for trying to help me. I'm looking forward to your findings with the LA.
Pitou!

 

[apl-vade-mecum]

IBM 5110 logic capture, Salea Logic-16

ch signal location

0 Data-7-Even A1M2-D13
1 Data-6-Even A1M2-D12
2 Data-5-Even A1M2-J04
3 Data-4-Even A1M2-J05
4 ~Adr-E A1M2-B09
5 ~Adr-D A1M2-D10
6 ~Adr-C A1M2-D11
7 ~Adr-B A1M2-B13

8 ~StolenNext A1J2-B03 pg 3-39
9 ~StolenCycle A1J2-D06
10 CS A1M2-D09
11 DS A1M2-B10 sheet
12 WR-Even A1M2-J02
13 WR-Odd A1M2-J10
14 MCC3 A1G2-B08 or A1H2-G07 sheet 420 & pg 3-39
15 MCC4 A1G2-M06 or A1J2-J02 sheet 420 & pg 3-39

References:

SY31-0550-1 IBM 5110 Maintaince Information Manual June 1978 chapter 3
SY31-0552-3 large block diagrams 410, 415, 420

Here is a couple seconds, in APL, press 1 3 4 <CR>, all zoomed out, note burst of writes when APL runs:




And here is it zooomed in a little. See the pattern of Cycle Steal cycles? That's the video card generating NTSC video, the long pauses are when it retraces from bottom right back to upper left, the small pauses are as it retraces each line from right back to left. The blocms of cycles are reading memory to write out the 64 characters on a line.




And now zoomed in some more, you can see CS (Card Select) and DS (Data Strobe), we expect lots of DS without card select as that would be ROS reads. We do expect to see CS and DS associated with each ~CycleSteal which iis reading a word of video to give to the video card.




These all look as expected *except* I see an odd very narrow CS once in a while. I tried going to just 4 channels and capturing at 100MHz and it is still there, the odd thing is that it is narrow and when it happens, DS is not asserted. But for a legit access to the RAM card, don't we expect a DS to read, or a WR (even/odd/both)? CS with no DS or WR is confusing.

Here is the Salea Logic2 capture file, typing 1 2 3 <CR> all 16 channels at 16 MHz:

https://user.fm/files/v2-2e912723c3c7fe7631b267448864c88c/IBM-5110-APL.sal

If you download the Salea app it lets you use a capture file, you can pan and zoom and see a lot more detail, it is pretty fun to zoom in and out to see patterns and then the exact edges.

 

[apl-vade-mecum]

This is a big mystery. I was hoping that the logic analyzer would show some strange read behaviour associated with the cycle steal RAM reads. But looking at the four lines (~StolenCycle, ~StolenNext, MCC3 and MCC4 I haven't seen anything odd at all, they look like perfectly formed reads asserting the SRAM control lines same as regular memory reads. As we know your board works fine for normal reads & writes.

The last trace posted above shows video card reads, Cycle Steal is asserted along with CS and DS right at the time MCC3 and MCC4 are transitioning. So that all seems to match up with what the manual says it should be doing. I am not seeing anything strange that the SRAM chips wouldn't like.

Bus CS -> inverter -> ~CS SRAM
Bus DS -> inverter -> ~OE SRAM
Bus WR -> inverter -> ~WE SRAM

The SRAM data sheets have:

And even if CS is asserted but not DS or either WR the data lines should all be High-Z.

There is a long thread on video card repair here:

Video display card repair

But I didn't see any hints there. It does have lots of ideas regarding how to probe the video card.