• Please review our updated Terms and Rules here

Reasons why expansion interface might cause RAM errors in keyboard unit?

K

kengr

Member
Joined
Sep 11, 2017
Messages
43
I have two Model I Expansion Interface boards. Both boards use the last expansion interface board design, and both are populated with 32K RAM. There are no other modifications/additions (e.g., no doubler, no data separator, no RS232, etc.).

I'll refer to the two expansion interface boards as A and B.

When board A is in the system (with 16K keyboard unit, two known good power supplies, one floppy drive), everything works well...TRSDOS 2.3 boots every time, TEST1A passes every time, I can enter DOS BASIC every time, the correct amount of RAM is reported, and everything works as expected.

When I replace board A with board B (same cables and power supplies), I can boot to TRSDOS 2.3, but TEST1A reports lots and lots of RAM errors in the keyboard and eventually ends with a scrambled screen. This happens 100% of the time. Also, if I boot to TRSDOS 2.3 and then attempt to enter DISK BASIC, the system either freezes or reboots itself.

When I go back to expansion interface board A, all is well again.

I have cleaned the contacts on expansion interface board B and carefully reseated the RAMs in it, but board B always fails as described above. The capacitors on board B look fine visually.

Any ideas what might cause this behavior when using expansion interface board B, and what I could try to troubleshoot what's causing the issue?

Is it possible that bad RAM installed on the expansion interface board B could cause TEST1A to report bad RAM in the keyboard unit? Or is this more likely a signal issue between the keyboard and expansion interface?

(I am primarily a software person, so circuit board troubleshooting is not my forte.)

NOTE: I am not using a buffered interface cable. It's just a straight-through cable, and I'm using the same cable to connect to each of the expansion interface boards.
 
Last edited:
The first thing to try is to pull the second bank of memory from board B and try the test. Then swap the memory from the second bank into the first bank on board B and test again. That might help track it down. If they both fail then try the memory from board A in B and vice versa.
 
Or you can try BABYROOT a Memory test program. It will find the bad address(s) and then you test the
bad address(s) with bitchck to find which bit is bad.

Let the software work for you..

PM me your email address.

Larry
 
What does the Model I memory test tell you? If you press reset while holding down [Break] do you get the memory size? question? If so, and you then hit [Enter] followed by ?MEM [Enter] do you get the same result from both EI boards?
 
Thanks for your replies.

I tried the two different sets of 16K from board B in the first bank of board B, and got the same bad behavior with each set. I also tried the 32K (16K at a time) known good RAM from board A in board B, and still got the same bad behavior. The only good behavior I got from board B was with no RAM at all installed in it. So, it's like board B doesn't like any RAM at all, whether it's unknown (the two 16K sets that came with board B) or known good (the two 16K sets that came with board A). The one thing I didn't do was put the board B RAMs into board A. I'm a little nervous about doing that, because I don't want to rock the boat on board A...I really want it to keep working. But I'll give that a try anyway, and see what happens.

Note that, if I boot the system using board B when it has zero RAM, TEST1A runs perfectly (against the 16K in the keyboard), and I can get into DOS BASIC (although there's very little available RAM left to do anything).

As for trying babyroot, I currently don't have a way of getting utilities onto the system, as the PC HD floppy drives I have don't write the lower density TRSDOS images properly.

With any memory installed in expansion interface board B, the TEST1A memory test always passes the ROM test, and then reports a large number of RAM problems in the keyboard RAM, followed by pages and pages of scrolling blocks of zeros.

Using expansion interface board B, if I press reset while holding down Break, I do get the memory size question. Then PRINT MEM reports just under 16K (the keyboard RAM size) no matter how much memory is installed in the expansion interface board B (0K, 16K, or 32K). So, Level II (with no TRSDOS involved) only sees the memory in the keyboard, and doesn't see any memory installed in expansion interface board B. On the good expansion interface board A, PRINT MEM always shows the expected 48K.

So, having any RAM (even known good ram from the other board) in board B is unrecognized by Level II (no TRSDOS), and causes TRSDOS TEST1A to throw fits about the memory in the keyboard.
 
Last edited:
What happens when you put memory in board B, and start up diskless and enter 32000 for memory size? Does your 16k ram in the keyboard then work okay? I’m wondering whether the EI is really causing any problems in the keyboard ram, or if the errors you’re seeing reported for that ram are actually being caused by the fact that the diagnostic program is running in higher ram.
 
Using board B, with any amount of RAM installed (16K or 32K), and booting diskless into Level II causes a relatively long delay before the memory size question appears (definitely a much longer delay than the same scenario with board A). After that delay, when I answer 32000 to memory size, as you suggested, I get into Level II and PRINT MEM yields 14796, which is lower than the normal 15xxx I get when not specifying any memory size. Not quite sure why I'm seeing a lower than normal value here, but other than that, this is consistent with what happens when I don't specify any memory size...it only ever sees the memory in the keyboard, no matter how much RAM is installed in expansion interface board B.

The fact that attempting to go from TRSDOS into DOS BASIC always causes hangs or reboots the system, even though TRSDOS and DOS BASIC (according to the memory map diagrams) loads inside the keyboard's 16K, seems to indicate to me that there is a problem even if the expansion interface board B memory is not being used. On the other hand, perhaps DOS BASIC does something temporarily in higher memory while it's starting up, which might be causing the hangs/reboots.
 
kengr said:
The fact that attempting to go from TRSDOS into DOS BASIC always causes hangs or reboots the system, even though TRSDOS and DOS BASIC (according to the memory map diagrams) loads inside the keyboard's 16K, seems to indicate to me that there is a problem even if the expansion interface board B memory is not being used. On the other hand, perhaps DOS BASIC does something temporarily in higher memory while it's starting up, which might be causing the hangs/reboots.
Click to expand...

It's likely that when you start BASIC, memory above 8000h is being accessed. See page 7-5 of the manual, about TOPMEM.

After booting, use DEBUG to see what value is at 4049h. If it's higher than 7FFFh (stored little-endian as FFh 7Fh), then use DEBUG to change it to 7FFFh, and then try starting BASIC. Also try running TEST1 (or TEST1A) after you've set TOPMEM.
 
Do you know the history of the B EI? I know some people have modified their keyboards to contain more memory. If they do that, I'd guess that memory addressing in the EI would have to be changed so that it could be used for the floppy controller. I'll dig through some of my documents to see if this is a possibility.
 
Holmes Engineering sold an internal memory option for the TRS-80 Model I. This is text from archive.org, with a couple corrections from the pdf file

"MODIFYING THE 'NEW STYLE" EXPANSION INTERFACE. If Z29 and
Z31 are 74LS244's, you have a "new style" EI. Since you should
already have it opened up, (1) make sure Z29 and Z31 are
74LS244's. IF THEY ARE NOT, contact HOLHES ENGINEERING before
proceeding. If they are, find Z28, a 74LS00 I.C. (2) Find the
trace running between pins 8 and 9 of Z28. (3) Cut the trace
running between pins 8 and 9 of Z28, just past the point where
it 'feeds through" the hole in the circuit board. (4) connect
a 1k-10k resistor (value not critical) from the feed-through
hole in the circuit board to the heavy trace connected to pin
16 (or 14?) of Z28. You have now connected pin 19 of Z29 and Z31 to +5
volts, which "tri-states" (floats) the RAM output buffers and
prevents them from interfering with the operation of the
INTERNAL HEHORY. To restore your EI to original configuration,
simply repair the cut trace. "

https://archive.org/stream/Internal...ernal_Memory_1981_Holmes_Engineering_djvu.txt
 
I left this alone for awhile, due to other priorities. When I returned to troubleshoot it again, Expansion Interface B started working just fine with the full 32K installed. I successfully booted without floppy to see the full 48K in the system, I successfully booted to TRSDOS 2.3 and ran TEST1A multiple times, and it passed every time. I tried using the system for awhile, copying files between floppies, entering and running BASIC programs, running existing programs, etc. and could not get the thing to fail. I ran a program overnight, to see if it would fail in some way, but it was still chugging away the next morning.

I didn't change anything, clean anything, reseat anything, etc. between the time it consistently failed and the time it started working. Same power supply, same room temperature, same everything. I have no explanation for this. I've seen software rot and hardware rot, but this looks like a case of reverse rot...leave it alone for a few weeks and it heals itself. While I'm happy that it's working now, I'd really like to understand someday what was causing all the trouble.

To answer some questions posed earlier in this thread, I don't know the exact history of this EI board, but was told that it was new old stock from Radio Shack parts center. Physically examining the board, there are no signs of cut traces, jumpers, replaced chips, etc. The board is the redesigned version, which uses a plain old ribbon connector. It arrived to me without any RAM, I ordered the RAM from a reputable source, and carefully installed it myself.

Anyway, it's working just fine now. A bit of a mystery. Thanks to all for your suggestions and ideas.
 
You must log in or register to reply here.
Back
Top