attached a bios.bio for xiflash and the whole 128kb bios for burning directly to the rom itself with a burner.

Has anyone had any luck with the lockups?

I've tried everything: using commercial adapters for everything but the SBC and Backplane, exchanging the processor and all peripherals, triple-checking every solder joint, etc. The only thing I have still not done is exchanging all 74xx logic with new ones.

I've checked with CheckIT 3 and there are random memory errors once in a while, in any random position. I don't know what else to do with my Xi8088 🙁

I'll ask Sergey about it again. He says he has no problems with his, though. I haven't unpacked mine again, have been working on some other projects right now, so haven't had time to do any troubleshooting...

I have left Ultima III running at the intro screen for three days straight with no lockups, though, and left Champions of Krynn running for hours and hours with no problems, but as soon as I look at enabling UMB it all goes to hell.

keenerb wrote:

I'll ask Sergey about it again. He says he has no problems with his, though. I haven't unpacked mine again, have been working on some other projects right now, so haven't had time to do any troubleshooting...

I see. I've just unpacked mine after a few years because of the replacement ICs I've bought, but unfortunately the behavior is the same. I've given up bothering he because we couldn't get anywhere, then I've eventually found that you guys are having similar problems.

keenerb wrote:

I have left Ultima III running at the intro screen for three days straight with no lockups, though, and left Champions of Krynn running for hours and hours with no problems, but as soon as I look at enabling UMB it all goes to hell.

Is that with Sergey's backplane or another? With 512kb or 640kb RAM?

I also can get a little more stability without UMBs, but eventually it freezes (or displays a random memory error when checking - even at low addresses).

I'm getting it set up again now to do some more burn-in testing, I have three different backplanes right now.

I have noticed the occasional random memory error. If it's this widespread I assume it's a defect in the underlying design, or quite possibly a BIOS bug.

Running five memory checks with checkit 3.0

When running on mine, Checkit 3.0 ocasionally performs a full pass without errors, but in rare ocasions there are errors in at least half the blocks. Very, very random.

If this is a defect in the underlying design, I will probably grab a commercial 8086/286/386 SBC and use my self-made backplane, opl2, fdc, uart and vga with it, leaving the xi8088 parts for spare/breadboard. This is really unfortunate since I've build all the x86-related designs from Sergey and they all work very well in other computers.

Im wondering if its not more a bus contention issue or something. Ive run different backplanes and such. I dont have a terminated isa slot backplane to see if that makes a difference.

I have a strange memory that using faster crystals caused it to hang more than slower ones, but even in non-turbo 1mhz it still locked up. I've restricted RAM memory to <= 512kb but had same problems. I've done it with every card removed but the vga card and the xt cf card.

I dont really have the patience to hook it up to my big beastly logic analyzer (136 channel HP/Agilent/Keysight mofo).

But I suspect there is some kind of bus issue or cross talk or something.. or modern chip timings might be too fast.

I even thought about getting the SRAM in SOJ package and wiring it to dip, the SOJ 512kb sram is 10ns, the DIP sram is 55ns.. probably wishful thinking...

my bus controller is an 802c88 from UM, I think I'm going to hunt down an intersil one. all my other chips are intersil/harris.

I use a bus controller from Intersil, but no joy with it either.

Do you know if it was common to have the ISA bus terminated?

I ran memory tests on mine all night with no errors using checkit.

I'll fire up ultima III and see if it locks up.

How can you tell if your backplane is terminated or not?

sometimes there will be resistor networks on like the last slot. its not really a thing with isa (it was more a SBUS/S100 bus thing). There are resistor networks on the xi8088 board, maybe they are bus termination I need to look at schematic again. isa doesnt really need termination, I think isa spec has it as optional.

for termination example (not the best image)
http://pictures1.kyozou.com/pictures/_28/27269/27268921.jpg

you can see a whole host of resistor network (the yellow chips) on the last slot.

Ultima IV has been running for a while now, since my last post. No obvious issues.

Just started getting some graphical corruption, although game is still running.

what has everyone got the 'waitstaites' toggleswitch on the pcb set to?

I've tried all four combinations without success. Changing the slot positions also had no effect. I can't seem to do anything that affects the error rate

I've noticed that, in my case, only the high bits show errors in Checkit 3

i.e.:

In the 16-bit number
FEDCBA9876543210

I've only seem errors in the higher bits:

FEDCBA98........

I'm pretty far out of my depth here so this might all sound stupid, but a memory test failure means the data read isn't the data that was supposedly written previously. Aren't there really only a few things that should be able to cause this?

Considering how often I see lockups with UMB enabled vs. pretty stable with SW2.1-2.6 disabled, I'm really suspicious of the RAM.

The memory itself could be faulty, but these are brand-new SRAM chips, multiple batches/users, all having same symptoms? Not very likely unless the board isn't maintaining +5v consistently. I see C12 and C13 caps that should keep that from being a problem, right, they should maintain power to the SRAM chips, unless they are not the correct spec for what the chips need.

Does check-it return any detailed info on memory errors, like the bit pattern it expected vs. the bit pattern it received?

Could there be a timing issue where the reads simply fail because the bus is actually tied up with DMA or something? Could we disable DMA on this board somehow just to see if anything changes?

Maybe there's some weird edge case where the memory reads are actually pulling data from some other peripheral or from the ROM address space. Maybe something activates both memory chips simultaneously and we actually read data from U11 instead of U12 for the higher 8 bits. Could we write a custom memory tester that fills U11 and U12 with specific bit patterns and then validates WHERE (or from which chip) it received the data from? If we filled U11 with 0000000 for higher bits, and U12 with 1111111 for higher bits, and only test values that modify the lower 8 bits as we increment through the ram, I wonder if we'd suddenly see a value U11 with 11111111 in it's higher bits, or see 00000000 at the corresponding location in U12.

Theoretically, if it were an issue with both RAM chips being activated at the same time somehow, that might explain why simply enabling the 384k UMB space would lead to much higher rates of lockups, which is something I've personally observed. If this scenario were accurate, there'd be a potential overlap of just 128kb by default with no UMB enabled, which would be where memory on U12 between 512 and 640k overlaps memory on U11. Enabling UMB could open that window of potential overlap significantly.

Also, I have several memory cards that can provide lower memory up to 640k, but none seem to work with the xi8088; I guess it's not possible to use any other memory than the on-board ram.

mine will often lock up during boot. most of the time it will get though to dos and die in 1-5 minutes after booting. while it works, everything is working fine, and I have seen memory corruption on doing long dir listing (I have my own dir replacement.) even dos dir sometimes bugs out with strange characters. for the longest time I thought it was my vga card.

Add me to the list of folks who are unfortunately experiencing weird issues. It seems like this thing worked perfectly when I first built it, and when I produced my youtube video. A couple months later it has started acting up. The problem started with the occasional random lockup during long-term operation. This week it started to throw POST 54 errors on boot, and I tracked that down in the BIOS as a memory test failure of the lower SRAM. I replaced what I believe to be the lower SRAM chip (U11). The POST 54 errors went away. However, I'm not convinced, as experience as shown me that sometimes just pulling a board and fidgeting with it can appear to solve a problem. So I started runing Checkit 3.0.

Checkit found a memory error (despite the replaced SRAM chip), so I pulled the board again, cleaned the hell out of it with alcohol and distilled water. I then went over it under the microscope and examined my soldering work. I retouched a couple of spots that appeared good but were less than perfect. Ran checkit again, and it seemed to run for a few hours and then lockup.

My build uses a Nec V20 with a 24 Mhz oscillator. The problem happens both in Turbo and non-Turbo mode. As I write this message, it was running checkit, and it just started beeping and freaking out. I'm running DOS 3.31. This thing is a Sergey design throughout, including the backplane, VGA, floppy, and adlib boards.

Weird. I'm not sure where to go next, other than to try a chip-by-chip replacement with spares to see if some IC is misbehaving.