• Please review our updated Terms and Rules here

XTIDE tech support thread

mk553 said:
Hey guys,

[snip]
Now, it's got me kind interested in building one of my own. It's not something I've done before, as I'm a software programmer and not a hardware guy, but it makes me wonder if this would be something good to learn from? The one time I tried to do some some soldering, I got solder all over the place, and it never worked. :) Can I still get one of those kits anyway??

Anyway, thanks again, and great job!!

Mike
Click to expand...

Hi Mike, if you are interested in how computer hardware works and building your own equipment you might want to consider the N8VEM home brew computing project. You build your own computer from scratch and learn a lot about computer hardware and electronics.

You could learn similar things from building your own XTIDE board however it is a more narrowly focused peripheral board and doesn't include important items such as RAM, CPU, bus, etc. Still XTIDE is a great board and works fine but I personally would not choose it as a project to learn about computer hardware since it was not really designed for that.

Good luck! Thanks and have a nice day!

Andrew Lynch
 
Will the BIOS boot menu allow selecting to boot from a drive attached as SLAVE ?

One thing I've noticed , after booting from my WD31000 1 GB, the first time
I issue a DIR command, the files in the directory are listed, then it takes about
15 seconds to return to the command prompt.

Issuing DIR the second+ time , files are listed and it returns to the command
prompt immediately.

BTW, who is Tomi Tilli in the BIOS copyright ?
 
Since aitotat here on the forums is the author of the current BIOS, I am assuming that would be his real name...

The lengthy DIR time on old machine is due to how the FAT filesystem works. FAT is an extremely inefficient filesystem, and the system has no easy way to calculate free space. http://en.wikipedia.org/wiki/FAT_filesystem#Fragmentation
The performance could be improved with a disk cache, but usually the machines that could most use a cache, are the machines least able to afford the necessary ram for the cache.

I have a 2GB partition on an old full height seagate SCSI drive, and I get the same thing. The first directory listing will take ages, and the 2nd will be much quicker since it already calculated the free space. If you try a dir /b, it will finish post haste, but you will only get filenames, with no sizes or attributes.

These old machines just weren't designed with 2gb+ partitions in mind I guess :p
__
Trevor
 
I am unable to update my chips to RC2 from RC1, the utility keeps reporting the EEPROM keeps timing out, i can force the issue by manually using the flasher, or telling it to add a wait-state while writing, but if i do that, it stops just short of detecting the hard drive, or the XT reports that the ROM is bad. This has been tried on all the chips, one got bricked, the others wont take new code. only 1 of them took the new code and works ok, it was flashed using the defaults, same as the others. What could be causing this. I have even tried the recovery method earlier in this thread, no luck there either

*update*

I was able to manually update 1 of the bad chips using the /A parameter of the flash program, but it keeps saying verify failed, 2 columns are shown the left has different values than the right ones. I'm guessing these chips are simply refusing to take the code, no matter what jumper settings i feed it.

**update** it reports unexpected byte where another should be and fails, with the write enable jumper, ON of OFF it's ignoring the jumper. I am beginning to wonder if i have found a bug in the card

***update*** i have copied this post from the universal thread to this one, maybe on both more peeps will read it. and i'm adding more.

I am using the command line flash, which is the one reporting the unexpected bytes. IDECFG is reporting the timing out while polling issue. Neither will flash the chips properly, and i do not have access to a EEPROM programmer. :(
 
Flash.com cannot be used with XTIDE Universal BIOS (flash.com corrupts it since it writes settings meant for hargle's bios) so only use idecfg.com.

Here are some general things to try for everyone having problems with flashing:
Enable Software Data Protection for Atmel EEPROMs and disable it for SEEQ EEPROMs and others that do not support SDP.
Make sure that Page Size is set to 1 byte.
For polling errors, try to set Write Cycle Delay to 10ms but i'm sure that it won't help since polling should always work.
For later PCs, make sure that shadow RAM or any write cache is disabled during flashing.
 
aitotat, i've tried ALL of those things, idecfg fails using ANY settings, i've checked the solder, it all checks out. what i need is a way to completely erase the chips and start over with the flash, but i'm pretty sure i've got several borked chips :(
 
Hello, this one is gonna be kinda serious. Out of the 6 Amtel chips. Only 1 took the flash properly and works. 1 was rendered unwritable. the 3 spares REFUSE to be written to, they WERE good, but flashing with the idecfg program, i get data verification failed, then the chips return a faulty rom code on start-up. I do not have the facilities to completely erase them and start over from scratch. so i have 1 working XT-IDE card, the assembeled kit and the second fully assembeled card BOTH with no working rom. I have followed ALL the instructions, the recovery procedure, to no avail. As i've said, i have no facilities to manually reprogram the chips. all the solder joints on all 3 cards are good. Thusly i seem to have recieved 5 faulty Amtel chips. I couldn't even turn off the software write protect on the chips. The act of simply changing that setting, without attempting to add the file in, is what returned the data verification error, subsequent flashes, the 5 chips return EEPROM timed out. What's the deal?
 
Hi! I would remove all the chips on your board except those absolutely needed for the EEPROM access. Those would be SW1, RR2, U9, and U10.

Power off your PC, remove the XT-IDE. Remove all parts and inspect your board for any solder bridges and/or cold solder joints especially on the VCC and ground pins. Remelt all solder joints and wick away any excess solder.

Ensure RR2 is installed with correct orientation. Disconnect anything on the IDE connector. Install JP1 and JP2. Try flashing the EEPROM again with the SW1 configured to the correct ROM address.

If the system won't boot with EEPROM enabled, try removing JP1 and carefully reinstalling after the system powers up and is finished booting.

Actually, a useful thing to try would be to remove the board entirely and boot the system. Use MSDOS Debug to inspect the memory region where you are placing the XT-IDE board and ensure there is nothing presently there. What you are describing sounds a lot like bus contention and you may have conflicting devices in the region.

Let's try a few things and if that doesn't work, you (only you, send PM) can send me your board for further inspection, debug, and test.

IMO, I would consider using a 27C64 EPROM since they are nearly indestructible once in circuit and are impossible (AFAIK) to change their values short of reprogramming or erasure.

I hope this helps. Thanks and have a nice day!

Andrew Lynch
 
k2x4b524[ said:
Hello, this one is gonna be kinda serious. Out of the 6 Amtel chips. Only 1 took the flash properly and works....
Click to expand...

Reposted from my PM to k2x4b524[:


Don't sweat it...yet.

The odds that there is a small timing bug in the idecfg program that flashes the parts is significantly higher than you receiving 5 bad parts. Atmel parts are top quality, I'll eat my hat if they are actually bad. My guess is that the utility is right on the very hairy edge of timing on your machine and the stuff isn't getting to the part fast enough, or too fast. Machine speed and a number of other factors can weigh in here.

aitoit, who wrote the program, didn't have any atmel parts when he wrote the program. He's got them now. There are a LOT of things that can go wrong in the software, and with all the different machines to run it on, there will be some issues.

Give him some time to poke around, try and reproduce the issue and we'll see what's up. I too have written a flash program (per based his on mine) that I can try out. I've got a PC, XT and tandy machines I can test it out on.

You just need to be a little patient; this is still pretty new.
 
Speaking of timing, I just realized my Vicki runs at a higher clock frequency (7.16 MHz ?) than usual. The one card that I got to the boot menu but didn't detect any hard disks, would it make sense to slow down the computer to ordinary 4.77 MHz frequency? There is a motherboard jumper for that.
 
k2x4b524[ said:
I couldn't even turn off the software write protect on the chips. The act of simply changing that setting, without attempting to add the file in, is what returned the data verification error, subsequent flashes, the 5 chips return EEPROM timed out. What's the deal?
Click to expand...

idecfg.com does not disable Software Data Protection once it has been enabled. SDP must be kept enabled for Atmel EEPROMs since new XTIDE cards have them with SDP already enabled. I'll support disabling enabled SDP in the next version.

What are the specs for you system (processor, clock rate, DOS version etc.)? Have you tried flashing on some other computer?

How are the XTIDE jumpers and switches configured? Are they at the default positions?
 
carlsson said:
Speaking of timing, I just realized my Vicki runs at a higher clock frequency (7.16 MHz ?) than usual. The one card that I got to the boot menu but didn't detect any hard disks, would it make sense to slow down the computer to ordinary 4.77 MHz frequency? There is a motherboard jumper for that.
Click to expand...

nope. disk detection and operation should not require any speed changes. I first developed my BIOS on a 486-100 machine and it was perfectly compatible back to the 8088.
Flash EEPROMs however, are extremely timing sensitive because there has to be some way for the eeprom to know when to lock in the data you've written to it.
 
aitotat said:
idecfg.com does not disable Software Data Protection once it has been enabled. SDP must be kept enabled for Atmel EEPROMs since new XTIDE cards have them with SDP already enabled. I'll support disabling enabled SDP in the next version.

What are the specs for you system (processor, clock rate, DOS version etc.)? Have you tried flashing on some other computer?

How are the XTIDE jumpers and switches configured? Are they at the default positions?
Click to expand...


Yes the settings are the defaults, I am using your plain jane stock IBM 5160, Persyst CGA board, and IBM floppy controller, there is going to be my AST board once this gets worked out though. And there is an option in the IDECFG to turn off SDP. Dos versions vary from 3.x to 6.x i'm considering whipping out my dos 2.x disks. Also i forgot to mention, the 1 card that DID take the flash, did so WHILE my AST board was installed, would the lack of it be causing anything?

*Update* I installed my MACH-10 board thinking about the timing, still didn't work, thinking that the chips were completely borked, i stuck in my first xt-ide card figuring what the hell, and all the chips are flashed and functional, meaning the second card is borked, unfortunately i don't have the equipment to unsolder everything and redo it, i can only do one at a time solder joints, quite tedious. partially why the kit is taking me so long.... Any suggestions on how to get the joints right?

I also want to apologize to hargle for being suck a penis to him about the chips... once again last ditch effort narrows the problem to the hardware *the card*
 
Last edited:
k2x4b524[ said:
And there is an option in the IDECFG to turn off SDP.
Click to expand...
It doesn't disable SDP. It just tries to write without enabling SDP. Flashing will fail if SDP has been enabled previously.

Dos versions vary from 3.x to 6.x
Click to expand...
I always boot from DOS 6.22 boot disk when flashing. If that doesn't help then DOS isn't the problem.

Also i forgot to mention, the 1 card that DID take the flash, did so WHILE my AST board was installed, would the lack of it be causing anything?
Click to expand...
Possibly. Does it have any BIOS of its own? Does the AST have extra RAM? If so, how much do you have RAM with and without the AST?

By the way, do you happen to remember was the boot menu selection timeout counter working before all this flashing.
 
k2x4b524[, i'd like you to try this build of idecfg.com.

Try to flash with default settings:
Page Size (1 byte)
Write Cycle Delay (0 ms)
Software Data Protection (Y)

If it does not work, set Write Cycle Delay to 10ms and try again. It won't help but i'd like you to measure how long it takes before you get error message. No need to measure time with polling mode (Write Cycle Delay set to 0).
 
k2x4b524[ said:
[snip]
once again last ditch effort narrows the problem to the hardware *the card*
Click to expand...

Hi! Given the quantity of working units out already and the history of the testing, I am fairly sure the issues you are seeing trace either to a software related problem or a local issue with your board and/or system. The problems are you seeing are significant and we would be absolutely flooded with posts were these issues design related and thus more widespread IMO. That being said, there is *always* the possibility of a design flaw.

I think the key is to be patient while the well meaning people on this project work on the problem. Eventually the real issue will come out but until then it is important to be kind and gentle with the people trying to help or you'll drive away the people most likely to help you solve your problem. Please remember this is an amateur/home brew/all volunteer effort so you are depending on the kindness of strangers not a giant corporate monolith with endless resources.

When you assemble a board from a kit or PCB you really don't have any realistic expectation of on going support. Please keep that in mind and don't drive away the project contributors like Hargle, et al. It harms the whole community.

Thanks and have a nice day!

Andrew Lynch
 
aitotat said:
It doesn't disable SDP. It just tries to write without enabling SDP. Flashing will fail if SDP has been enabled previously.
Click to expand...
I'm guessing this is the problem.

Here's how it I think things happened:
My work's eeprom burner was able to enable SDP. I flashed *nearly all* of the eeproms using it.
However, before I went in and burned them all, I tested at least 1 of the parts on the XTIDE itself, to test the RC1 BIOS on my machine to verifiy it worked before I spent the time burning the bulk of them. k2x4b524[ received extra atmel parts from me, and I'm guessing at least one of them came from the "not burned with the eeprom burner" stockpile that I had. That is likely the one eeprom that is working for him.

So, this proves that SDP is working. He's unable to flash those parts.
Hopefully the new idecfg can undo SDP! ;) I have every confidence that it will.

---

This brings up an oversight in my testing of new cards though. I am not re-flashing the cards I've created to test that portion of the hardware. Once we get the process nailed down completely, if there is anyone out there who got a pre-built card from me who is unable to flash their card, PM me and we will work out a repair in case it's a construction issue.
 
Hi! I can program EEPROMs and/or EPROMs if needed. Let me know if that's what you want to do. I am standing by to help if needed.

Frankly, I still recommend moving to 27C64 EPROMs or even 27C64 OTP PROMs since this is a non-issue is with an external programmer.

I also know people don't like that solution but you might consider it for a longer term fix once the on board BIOS stabliizes.

My guess is most people will just plug in the board and use what ever BIOS is present and never change it. That's my $0.02

Thanks and have a nice day!

Andrew Lynch
 
hargle said:
Hopefully the new idecfg can undo SDP!
Click to expand...

I'll support SDP Disable command when it is time to release first stable version.

I didn't think disabling SDP was necessary since SDP can be temporarily overridden by preceding page to be written with SDP Enable command.

This is how the flashing works at the moment:
When Software Data Protection is set to Y, SDP Enable command is written before every data page. This will enable SDP or override it temporarily if it has been already enabled. This makes possible to flash EEPROMs with SDP enabled or disabled. If EEPROM does not support SDP it writes the command as data and so data verification fails.

When Software Data Protection is set to N, no command is written. This makes possible to flash EEPROMs that does not support SDP.
 
We'll figure it out. You and I both have atmel parts (you likely have some that were SDP'ed by my eeprom burner and some that are not) and we all have the same XTIDE hardware. I have true blue PC and XT machines like k2x4b524[ is using, with stock CPU speeds. We both have flash utilities to play with and the datasheets available and the technical skill to figure out the quirks. As soon as I'm finished assembling the last of the boards to ship out (hopefully sunday) I can start investigating this if you haven't beaten me to it already.
 
You must log in or register to reply here.
Back
Top