• Please review our updated Terms and Rules here

A tip for those designing new hardware for vintage machines...

JonnyGators said:
Problem squarely exists with the xtide card. Not sure where to go next with this, as I didn't build it.
Click to expand...

Did you ever link what exact card you bought? (Or posted a detailed picture of it?) Conceptually there is very little to the XT-CF design, but depending on how the builder chooses to implement it and what shortcuts they might take the exact parts used can vary, a lot. So if you’re asking for help trying to repair the one you have or more accurate guesses on what failed people would need that info.
 
DougM said:
Well, the first thing [the robot vacuum] did was aim for the stairs, drive right off the edge and land in pieces at the bottom.
Click to expand...
I don't even want to think about the conditions in that factory if the first thing any escapee from it does is commit suicide by throwing itself off a cliff. :)

modem7 said:
I have seen only experienced failure of the 28C64 EEPROM. Sometimes corrupt contents, fixed by rewriting the 28C64. In those cases, maybe it would not have happened if I had the ROM write-enable jumper removed.
Click to expand...

If you want EEPROM (at least, +5V programmable EEPROM) to act as ROM you must remove that jumper. Otherwise, if the write line is connected, there's nothing stopping a buggy or crashing program that's randomly writing memory from just happening to come across the correct sequence and timing to rewrite a bit of your EEPROM.
 
cjs said:
If you want EEPROM (at least, +5V programmable EEPROM) to act as ROM you must remove that jumper. Otherwise, if the write line is connected, there's nothing stopping a buggy or crashing program that's randomly writing memory from just happening to come across the correct sequence and timing to rewrite a bit of your EEPROM.
Click to expand...

Maybe that's a good argument for a flash chip like the SST39SF010. They use a "pound on the magic window" method of initiating write cycles that makes it a *lot* harder for something to hurt them accidentally.
 
JonnyGators said:
Looking at the card, it says Blue Lava Systems XT-CF Bootable 8-bit CF Interface
Click to expand...

Is it this one, or some previous model? Like maybe the one in this thread?

To me it looks like neither one of these cards has a data bus buffer for the card. The theoretical reason why this is a bad idea is it breaks something that would otherwise allow the card to properly detect if there isn't a CF card plugged in. (It also slightly increased the bus load, but probably not enough to matter.) But other than that, well... there's not a lot to go wrong here. If it's the "sandwich" model that uses a separate CF adapter plugged into the ISA host board you could try pulling it apart and reseating it, or even buying another CF-in-a-card-slot dingus (these devices used a part that was widely available on eBay/Amazon/the usual) to plug into it to see if the problem is something like failed soldering on the CF adapter.
 
cjs said:
If you want EEPROM (at least, +5V programmable EEPROM) to act as ROM you must remove that jumper. Otherwise, if the write line is connected, there's nothing stopping a buggy or crashing program that's randomly writing memory from just happening to come across the correct sequence and timing to rewrite a bit of your EEPROM.
Click to expand...

Dont forget to disable eeprom writing if you have a machine that shadows the ROMs. I have a 486 that reflashes its xt-ide if I forgot to hop in the bios and disable shadowing while dinking around with stuff.
 
Eudimorphodon said:
Is it this one, or some previous model? Like maybe the one in this thread?

To me it looks like neither one of these cards has a data bus buffer for the card. The theoretical reason why this is a bad idea is it breaks something that would otherwise allow the card to properly detect if there isn't a CF card plugged in. (It also slightly increased the bus load, but probably not enough to matter.) But other than that, well... there's not a lot to go wrong here. If it's the "sandwich" model that uses a separate CF adapter plugged into the ISA host board you could try pulling it apart and reseating it, or even buying another CF-in-a-card-slot dingus (these devices used a part that was widely available on eBay/Amazon/the usual) to plug into it to see if the problem is something like failed soldering on the CF adapter.
Click to expand...

It's like the one in the 2nd link to the thread.

I've tried pulling it apart and re-seating it. No luck.

1714092889038.jpeg
 
westveld said:
This is a quality option:
https://texelec.com/product/isa-ide-to-sd-adapter/

If you really want to stick to CF:
https://texelec.com/product/lo-tech-xt-cf-lite-rev-2/

That said, these kinds of devices are low volume, niche items.

Even the normal high-volume consumer products that have $$$$$ worth of product testing still have failures.

And not all 30+ year old machines survived either.

Some of that era didn't last 2 years ... I recall some Packard Bell machines didn't fare so well
Click to expand...
Thanks for the suggestion, ordered one.

But might be nice to get this one working again at some point to have a spare.
 
Eudimorphodon said:
Maybe that's a good argument for a flash chip like the SST39SF010. They use a "pound on the magic window" method of initiating write cycles that makes it a *lot* harder for something to hurt them accidentally.
Click to expand...
That's kind of nice if you want it writable, and just want a bit of extra protection against accidental writes that you didn't command. But for "programmable ROM," give me a hardware jumper that disables any possibility of writing any day. Who knows when some program might accidentally jump to the "write EEPROM" routine in my system monitor.
 
cjs said:
Who knows when some program might accidentally jump to the "write EEPROM" routine in my system monitor.
Click to expand...

But unless your option ROM has the flash routine embedded in it you’re basically 100% safe in a PC. ;) (To program the SST flash chips you specifically have to write two different specific addresses twice in a row *with no other reads nor writes in the sequence*, which implies heavily that your write routine has to be running from a different memory… etc. This is pretty unlikely to happen by accident.)

On my expansion board there isn’t a specific write disable, but there is an indirect one; it’s a 128K flash chip but I only expose either 16 or 32K of it, switch selectable. The higher “write unlock” address is (relative) 5555h, IE, around the 22k mark. If I really want to lock it I just need to set the smaller window. (Which is how it’s set in my 1000EX, to leave more space for UMBs. I leave it unlocked in the 1000HX because thanks to dark magic I have it set up from F0000-F7FFF, up and out of the way entirely. And it’s never been accidentally overwritten.
 
I use a EEPROM for my KIM-1 6530 replacement. It does have a write enable pin but I've no felt the need to use the hardware protection. Not only does it seem to have a robust sequence to actually program but for reasons related to the small space that I allotted to it, both the address and data paths do not match the original intention for them. Without doing a lot of circuit tracking and looking at the original part specification, any random data write to an address that would otherwise be intended as ROM is quite unlikely to accidentally overwrite the ROM data.
As for the generic thought of using newer stuff for keeping old computers running, I have no objection to doing so. I have several computers that need to use a parallel keyboard. I have a limited number of these ( one of my favorite ones has internal key failures ). I do have several AT keyboards with old AT computers that because of battery leakage, I have no desire to keep running. I've used a cheep "Blue Pills" to create an AT to parallel converter. I consider that fair usage.
Dwight
 
Eudimorphodon said:
But unless your option ROM has the flash routine embedded in it you’re basically 100% safe in a PC. ;)
Click to expand...
Now this is what I like to hear, someone who follows the route of my own software-developing heart.

I'm always talking to hardware folks who are continuously moaning about what might go wrong, rather than just concentrating on happy things like what might go right. They're always doing this "verification" stuff, and worst of all, when I run something and it works, they don't accept that it's obviously ready to ship! I can even run it ten times, and it works nine of them, and they're still saying it doesn't really work.

I just ship it anyway. If something goes wrong, the user can always reboot, and in my experience everything works fine after a reboot.
 
JonnyGators said:
Any ideas how to troubleshoot/fix the non-working one I have?
Click to expand...
Get your 'scope out and write some code for DEBUG. The board is very simple and the code for the BIOS is openly available.

If you lack the skills and equipment, try looking for cold solder/intermittent joints. They're not uncommon on this type of board--and why I stick with ltin-lead solder for my stuff.
 
DougM said:
Funny story there, I recently was trying to find a robot vac that would work on shag carpet (TLDR: there isn't one)
Click to expand...
You still have shag carpeting? All that thing is gonna find in the shag is lego bricks, light brite pegs and remnants of a better time.


On a side note i grew up with shag carpeting..... Now i hate all carpeting and think hardwood floor is king.
 
Apparently he was supposed to have DIY kits available at the VCF East workshop but logistical problems got in the way and the few kits he did bring quickly sold out.

I've still yet to buy an XT-IDE from any vendor, for the record. :/
 
You must log in or register to reply here.
Back
Top