Still haven't tried out that custom Tandy identifier bios, haven't gotten to the point where I can use it to test anything.

Considering how much tinkering I've been doing with the BIOS and how much I anticipate doing in the future, does anyone have suggestions for either replacing the DIP32 socket with a ZIF socket, or somehow extending the socket with a ribbon cable so I can replace bios without unmounting the motherboard?

Assuming such a ribbon cable extender exists, would there be timing issues or anything like that when using 4" or so of ribbon cable to make replacing bios more convenient?

32pin zif, http://www.futurlec.com/Sockets/ZIFS32pr.shtml

dont know if it will fit space wise where the socket is, but making an pcb adapter or something should be easy.

might be easier to just ribbon cable a socket up.

Yeah ZIF socket won't work, not enough space i think. Possibly if I reoriented the capacitor and the littelfuse to the back of the board and flattened them against the board.

I'm hoping to avoid manually creating a ribbon cable, I know I'll short +5v and ruin it all, but being able to swap the BIOS without uninstalling the board would be nice.

*edit*

Aha. So these connectors DO exist!

http://www.moates.net/emuc3206-emulation-cabl … nch-pi-168.html

Any idea what the DIP-32 connector at the end of the ribbon cable is called?

Ive always just called them dip ribbon connectors.

I have some. ebay has them, never found them on mouser that didnt cost more than gold.

these are the diy version.

This place has some but not in 32's.

http://www.jdr.com/SearchResults.asp?Search=idc+dip+ribbon

You could get dip 32/40 etc at some point, my Z80 ICE and fluke pods have bigass dip ribbon connectors. Might be a bit rare thesedays.

homebrewing something like this might be better;

xi8088 update:

I've been troubleshooting these UMB/himem.sys/USE!UMBS lockups.

It's also been happening without using the drivers and a combination of cards including my FDC.

It appears there's a problem with my self-assembled ATX backplane from Sergey. THe same cards installed into a four-slot AT-style backplane in the same order booting the same CF drive appear to have no issues at all.

I'm troubleshooting this issue right now, hopefully I'll have some more info available. I've tried two different ATX power supplies.

I get random lockups. sometimes its quick after bootup, couple of minutes. sometimes its long time after bootup, but pretty much it happens all the time. I thought it was my vga card (since I have some issues with it). I had nothing but that in the machine and I was getting it.

I did seem to (anecdotally?) see less when I stopped using the USE!UMBS. I dont know if its a ram thing or not, or my jumper settinsg or waite states. I'm not 100% sure how to debug / diagnose it. I even changed backplanes!

OK that makes two of us on the UMBs. I've actually stopped using himem.sys and now I"m troubleshooting why it locks up on that backplane with my floppy disk controller.

Basically when using himem.sys or use!umbs it just freezes at random, or applications exit with weird error codes. The most interesting was when I wrote a simple loop named loop.bat:

:start
xdir
goto start

It will execute a number of repetitions and then exit with "Unable to find file lbop.bat" or "No label named !start", which is telling me there's some sort of bit read/write error. I've already replaced my RAM.

I mean, this is a hobby board with hand-written BIOS, some things like this are bound to be problematic. It'll run a looping SSI game demo all day right now on my AT backplane with XT-IDE CF, VGA card, and Sergey FDC.

Once that AT backplane shows up we'll see what happens. If it continues to run well I"ll tinker with using my 2MB EMS card's page frame as UMB, or my lo-tech 1MB ram card to backfill memory.

I'm almost certainly going to have to revert to my Tandy 1000 as my primary retro machine while I sort this out though. 🙁

Yeah. Sounds like what I am seeing. I was REALLY sure using USE!UMB (I didnt use himem.sys) was causing it WAY WAY more than not to lockup that I stopped using it ages ago. Worse, while it happens every time, the amount of time it takes to lockup on me is random. I also see odd program behaviour, like exit an app, run it again, input wont work, or just wierd stuff. I need to work out if turbo makes it happen faster or not.. I do wonder if its something on the bus. Ive had it loaded with isa cards, no cards (except my vga). I havnt booted it up in a bit (troubleshooting this was depressing), but I think I was running dos6.22 or 3.3

BloodyCactus wrote:

Yeah. Sounds like what I am seeing. I was REALLY sure using USE!UMB (I didnt use himem.sys) was causing it WAY WAY more than not to lockup that I stopped using it ages ago. Worse, while it happens every time, the amount of time it takes to lockup on me is random. I also see odd program behaviour, like exit an app, run it again, input wont work, or just wierd stuff. I need to work out if turbo makes it happen faster or not.. I do wonder if its something on the bus. Ive had it loaded with isa cards, no cards (except my vga). I havnt booted it up in a bit (troubleshooting this was depressing), but I think I was running dos6.22 or 3.3

I'm running DR-DOS 7. I haven't noticed a difference with turbo vs. non-turbo. I've had a game looping now for over six hours with no freeze.

I actually feel like it's a RAM refresh timer failure of some sort, and memory contents are being corrupted. Perhaps it's only on the second ( > 512kb) chip, and we're only seeing it when accessing that higher ram. You tinker with the bios a lot, can you set the dram refresh timer to a shorter time period and see what happens? Isn't that the PIT timer 2 or something?

ram refresh timer would be odd, since its sram, no refresh required. I might look through the bios, look over the interrupts entry/exit points make sure a register is not being corrupted or something dodgy with stack is going on

I had wondered about that.

It's definitely a memory corruption though, there's no explanation for why it would change loop.bat to lbop.bat mid-execution. Memory has been replaced though.

Maybe I screwed up and used one of the original chips again, I"ll tinker with it some more.

I also see it more with memory intensive stuff, aka doing an ftp from my server with mtcp.

BloodyCactus wrote:

I also see it more with memory intensive stuff, aka doing an ftp from my server with mtcp.

Yeah I think we're on to something. It's nice to know this is possibly an architectural flaw rather than something I screwed up on my system!

Sergey responded to my query. He hasn't seen anything himself but did say that "The chip select logic for UMB (and actually 512 KiB - 640 KiB too) has a bit more delay than for lower 512 KiB of SRAM".

spent most of today poking around with things and having no luck stabalising things...

BloodyCactus wrote:

spent most of today poking around with things and having no luck stabalising things...

Looking back at this issue.

Do you think it'd be possible to modify the bios to report only 512kb of ram and avoid the second memory bank completely to test?

At least then it shouldn't lock up during normal operation.

should be able to do easily, yes. I might try that on the weekend.

Cool, let me know if you get a chance. Sergey definitely said that the timings for the upper 512kb are a little different than the timings for the lower 512kb, so I suspect that's going to ultimately be the issue.

I've noticed that when I use the 64kb window of my lotech 2mb EMS board for UMBs I see much less freezing, so I could probably live with 512kb low + a 64kb UMB block on this machine, at least short-term. I wonder if 1MB ram card could fill in the rest?

I fixed the bios to max 512kb, and all my dos6.22 loaded with bare bones nothing configs, no umb no nothing.

still getting lockups. it was as if I made no changes.

Upload it for me if you can. It's possible you have a bad chip as well, remember the problems I had until I tracked down that bad part...