EMS parity errors and wrong memory size about isa_ems_4mb

[A-Small-Mice]

I got one IBM 5150 this time, and I conducted a test again.

In the previous results, the ROM test using the IBM ROM BASIC always failed, but as I checked now, I think it was a BASIC problem. I put some CGA games in ROM instead of BASIC and it works very well.

[A-Small-Mice]

Finally done!

I wish @primis the best of luck, too.

[hkzlab]

@A-Small-Mice BTW, I think the bracket I used was mouser no.534-9202 / Keystone 9202
Just in case you want a metal one.

[hkzlab]

Of course I cannot tell You what You did wrong, but I can point out a few things.

First of all, keep in mind the following: as I say on my github bio, I don't offer support, this is not my job.
Second: there is always the chance you got a defective PCB printed out.
Third: I have built 4 of these boards, they're working fine in my 5160 and in 3 ATs. No issues there, but I never tested them on the NuXT.
Fourth: Not using sockets for the logic ICs was a VERY bad idea. This is going to be a pain for you to debug, if it turns out to be a defective IC.

Now, some pointers.

• The logic for the led is VERY simple. The base address is decoded by U7 (a '688), and when it matches with the one you choose via jumper, it brings down a /RAM-SELECT signal that will turn the led on. If the led is not blinking, you have either a bad '688, you are accessing the wrong address, you put the led in reverse or you put too high resistance on R3 (but I see a 560ohm there, should be fine). When the EMS utility runs by testing memory, it should blink a lot. First of all, fix this
• Parity errors and different pages at each boot, probably tied to the previous point, but could also be bad ram or bad logic chips. Don't worry about this until you fix that led.

From what I see, you set the board to E000h as base address and 260-263h I/O address. Are you positive there is no conflict with any other board or with the UMB memory enabled in the NuXT? The NuXT can have UMB memory at that address that needs disabling.

Have you tried other addresses? Have you tried other I/O ports.
Also, try to move the RAM chips around, exchanging them, and trying with only half of them.

[A-Small-Mice]

Thank you for your detailed advice. I'll give it a try and tell you the result.

[hkzlab]

Also, I have the 2Mb version of this board running with the micro8088 by Sergey. Identical circuit but less RAM, and the micro is a close relative of the NuXT, so I'm more convinced that the issue is either a conflict or a bad IC on the card.

[hkzlab]

Once You have debugged the led issue and get that thing to blink, and have doublechecked that there is no base address and/or IO port conflicts, and that You have verified that the issue happens also if you swap around the RAM chips and You try to run the board with 2M instead of 4, next thing I would try is swapping the U12 ('ACT245) with an 'LS245 (and a socket), as the CMOS family is a bit more sensitive to noise. Maybe it's not triggering properly with the signals you have on your bus.

[A-Small-Mice]

Thank you again for your kind and detailed advice..

I re-made the EMS card with DIP sockets installed.
I also realized that the LED didn't blink because I put it in reverse. There's no problem right now.

Finally, I tested the logic ICs with my TL866II programmer. There's no problem with all of them.

The sad fact is that I still get memory parity errors. So I thought there might be a problem with AS6C4008, but when I tested all the 40 chips I had, the result was the same. In addition to NuXT, I also tested the EMS card with an XT clone named DTK, but the result was the same.

And it seems to be no base address and IO port conflict error.

I have only a few options left to try.

1. Replace electrolytic capacitors with new ones
2. Replace HD74ACT245P with LS245 you mentioned
3. Replace SN74HC04N with 74HCT04

[hkzlab]

EDIT: Added a few tips/advice

Don't put too much trust in tests made with the TL866. If they say an IC is bad it's generally true, but not the reverse. I had chips failing in-circuit when the TL was saying they were fine.

I would start by

• leaving only 2 ram chips
• Doublecheck that the resistor network on the data bus is fine (RN3, 10k bussed, check that it is not actually an array of separated resistors, just in case...)
• then swapping around the ICs, starting with the ones you mentioned ('245 and '04)
• if that does not help, go with the '573s (exchange their places in the sockets before replacing them)
• then go with the '138 (it's the chip toggling the /CS for the ram chips)
• then go with the '32 and replace it with an LS (it's directly tied to the ISA bus, an LS is less sensitive to noise), keep in mind that when you do this, the '04 will have to be an LS or an HCT, an HC won't work right with an LS feeding into it.

What happened when you installed only 2 or 4 memory chips? Identical errors?

• Could you please take a screenshot of the results of the memory test from CheckIt?
• Also, a screenshot of the memory map output of CheckIt could help (without card inserted and EMS driver NOT loaded)

This is a photo of checkit running on one of my ATs with this board in (2Mb only installed).

[hkzlab]

This is my memory map, with board inside and EMS driver loaded.
In your case, with board out and no EMS driver, the space should appear as unused/empty.

I'm starting to get a little worried about the fact that you mentioned a "parity"error though, because this board has no parity hardware...

[A-Small-Mice]

I have no '245 and '04 right now, I just ordered these chips, so I'll have to wait until this Thursday to get replacements and test them out.

Even when 2 or 4 RAM chips are installed, the problem* still occurs.
(*memory size error and memory parity error)

Once I tried swapping the positions of the '573's, it didn't solve the problem.

The picture above is my computer's memory map wtih no EMS card, no EMS driver.

The picture above is my computer's memory map wtih the EMS card and the EMS driver.

The pictures above are the result of memory test with 2 RAM chips.
I don't know what the repeating number 7 means. 😂

[hkzlab]

Thanks, so indeed it seems that the address is free!
I've added a few tips for You in the previous comment. Could you also please check the resistor network above the '245? it's bussed right? not a network of separated resistors. Just in case some data lines are shorted together...

Edit: added more advice you can run thorough one check at a time.

[A-Small-Mice]

Auh... My multimeter's battery is dead.

Instead, I checked the resistor network's spec.
It is A09103JP.

1/8 Watt, Bussed, ±5%

[A-Small-Mice]

I orderd 74LS32, 74LS04, 74HCT04, and 74LS245. I hope the chip exchange will solve the problem!

[hkzlab]

Also order a multimeter battery :-)
If those are not going to cut it, also check for the '138 and '139. And I think we'll have exhausted all the replacements.

If that is also not fixing it, I'm starting to worry about a defect in the PCB print (e.g. a short), because even in case of a computer incompatibility, the same issue on two different machines is rather suspect.

[primis]

I can replicate this weirdness with pages as well, With three RAM chips (That's all I have at the moment) I'm only seeing 1328K of EMS. Checkit is reporting a ton of Bit errors at basically every address line on the EMS addresses

[hkzlab]

@primis what is the machine you're trying it on? an XT clone, AT clone? Did you build it with all-CMOS too?
I just disassembled the board I have on another AT to check it, this one with the full 4Mb, to see if I replaced any IC with a different logic family and then forgot, but no. They match what I have on the BoM in the readme.

I wonder what is happening here. The schematic is the same as the lo-tech EMS board, except with all the ram /CS connected to support the additional ICs

[primis]

I'm using it on the XI-8088 clone board (www.malinov.com/Home/sergeys-projects/xi-8088) running at standard 4.77MHz with an NEC V20 and 1 wait state. All CMOS chips on my board as well.

[hkzlab]

I have a xi8088 around, but it's hidden in some box after my last move. The micro8088 should be reachable though. I'll try to dig it up and re-test with an all-cmos board.

[hkzlab]

hmm, I might have something here.
I took out the Micro8088 (V20 9.5Mhz), which was the base for the NuXT, so it has some similarities, the expansion card I put on there was all-LS chips, so I took it out and put in the all-CMOS one I use in my 286.

First checkin test, all good.
Second checkin test, errors.
Rebooted.
Checkin test, errors again.

So I took the card out, and replaced all the ICs that are connected to the bus with LS ones:

• both the '688 (You can ignore the one near the ROM socket)
• the '139
• the '245
• the '32
• the '04, even though it's not on the bus, mine was an 'HC04 that is not good to feed with an LS.

Tested once, good.
Rebooted and tested once, still good.
Ran 3 tests in a row, good again.
Tested again once, because why not. Good.

So I'd invite You to try by replacing those ICs and see if it makes a difference.

Now, there is one thing of importance to note: In the past I noticed that both the Xi8088 and the Micro8088 (but never ran serious tests on my NuXT 1.0) could get unstable when ran at high-speed and with many ISA cards installed. This was also with OEM cards, so I added a passive terminator to the backplane. It's soldered in, I cannot remove it to see if it changes the results. I don't have it on my AT clones though.

[hkzlab]

An article regarding the stability issues and termination in case any of you intend to test: https://www.smbaker.com/diagnosing-xi-8088-stability-issues
A few notes: I would stay away from terminating IRQ lines, and I wouldn't use 2.7V as a middle ground for termination. It's too high and gets read as a logic high. I stay between 0.8 and 2V.

[A-Small-Mice]

Nice test!

It must be a good solution for this ploblem.
I will change all the chips mentioned here with LS ones.

[hkzlab]

@A-Small-Mice fingers crossed, but even if it does not fix the issue, I'm interested to see if it reduces the number of errors.
After you swapped out the ICs, if the issue persist, try removing other cards on the bus and see if something changes. I'm convinced this is a noise issue given what I saw with the Micro.

[primis]

I'll order a set of LS chips to try to replicate your success, if that doesn't work then it's probably a case of me needing to implement that bus termination as well

[A-Small-Mice]

Here's the status quo.

RAM Size	74LS245	74LS04	74LS32	Result of Memory Test
1 MiB	X	X	X	Failed
1 MiB	O	X	X	Passed
1 MiB	O	O	X	Passed
1 MiB	O	O	O	Passed
4 MiB	O	X	X	Faild
4 MiB	O	O	X	Passed sometimes
4 MiB	O	O	O	Passed sometimes

• X means the ICs of the original BoM (74ACT245, 74HC04, and 74HCT32)
• O means LS chips was used.
• Checkit was used for the memory tests.

I need to prepare LS139 and LS688 for more testing.

[hkzlab]

@A-Small-Mice Let's see what You get by replacing those too.
If possible, also try to remove extra boards in the machine, and insert one card at a time if You notice the stability improves. You can also try to change the slot this card is using.

Given that results improve by replacing the CMOS chips with TTL, I'm more and more convinced that the issue is bus noise, as TTL chips are less influenced by it.

On the Micro8088 I initially built, I used 'ACT245 as bus transceivers but had to replace them because they were giving me issues with RS232 expansion cards: I wasn't able to send data above 9600bps.

[A-Small-Mice]

I also found out that the bus noise has a negative effect on the EMS card's ROM.

I installed IBM ROM BASIC on a ROM storage and tested it.

Data Corruption

[hkzlab]

The ROM circuit uses the third '688 and the ROM chip itself. It could be made more robust by using a transceiver for the data bus, like a '245, but there wasn't enough space.

I actually designed a new version of that board that removed the ROM entirely to make it smaller, as I felt it wasn't much use in the end.

[A-Small-Mice]

It's useful to some extent.
That's another strong motive for me to make this card.

[A-Small-Mice]

This is the last one.

System	RAM Size	74LS245	74LS04	74LS32	74LS688 & 74LS139	EMS Test	ROM Test
NuXT	1 MiB	X	X	X	X	Failed	Failed
NuXT	1 MiB	O	X	X	X	PASSED	Failed
NuXT	1 MiB	O	O	X	X	PASSED	Failed
NuXT	1 MiB	O	O	O	X	PASSED	Failed
NuXT	4 MiB	O	X	X	X	Failed	Failed
NuXT	4 MiB	O	O	X	X	Failed	Failed
NuXT	4 MiB	O	O	O	X	Failed	Failed
DTK Turbo XT	4 MiB	O	O	O	X	Failed	N/A
NuXT	4 MiB	O	O	O	O	PASSED	Failed
DTK Turbo XT	4 MiB	O	O	O	O	PASSED	PASSED

• X means the ICs of the original BoM (74ACT245, 74HC04, 74HCT32, 74HCT688, and 74HCT139)
• O means LS chips were used.
• Checkit was used for the EMS memory tests.
• The failures in the ROM tests mean screen glitch.

The complete replacement with the LS chips solved all problems in my memory tests. When using NuXT I still have a issue with the ROM test, but this is trivial.

[hkzlab]

Glad to see your results improve so much :)
Hah, I really should have added a '245 to buffer those data lines from the ROM. If replacing the '688 that acts as the ROM decoder does not help, it might be worth trying a different ROM chip, there isn't much else to do except adding a terminator.

I'll add a warning with your findings to the README, better warn other builders. Leaving this ticket open in case @primis wants to chime in their results.

[A-Small-Mice]

Just a question.

Can it be better to replace the other remaining chips('573 and '138) with LS ones?

[hkzlab]

@A-Small-Mice don't think it would bring improvements if the board is already working fine. Those are not in direct communication with the ISA bus.

[hkzlab]

Very glad to hear that! Enjoy your board.
Which games did you put in ROM, btw?

[A-Small-Mice]

A person named Predator99 has created a tool to put CGA games into ROM. Check out the following link.
https://www.vogons.org/viewtopic.php?f=46&t=67364&p=761478&hilit=ibm%20rom%20basic#p761478

I put Digger in a ROM. It works very well with my 4MB EMS card.