• Please review our updated Terms and Rules here

Anyone Selling XT-IDE Cards?

glitch said:
They look great, typical high quality PCB Cart work.
Click to expand...

Very nice :) Wasn't it PCB Cart that fab'd the original R1 cards ?, I don't currently need any otherwise i would have put my name down, My R1 cards are still going strong.
 
Thanks for the support, everyone! Yes, PCB Cart did the original run, and many of the production run s100computer.com boards. There should be plenty left after the preorders are fulfilled, I ordered about 40% more than was preordered. I plan on keeping a stock of these boards, and possibly kits, so that they're available to the community as a regular purchase item.

Chuck, I didn't look into having the boards populated in China, but I would guess that it would be more economical to design a SMD version if I were going that route. I can't imagine, with the limited number of "I want finished product" preorders I got, that it would be cost effective to have the boards assembled overseas.
 
glitch said:
...I didn't look into having the boards populated in China, but I would guess that it would be more economical to design a SMD version if I were going that route. I can't imagine, with the limited number of "I want finished product" preorders I got, that it would be cost effective to have the boards assembled overseas.
Click to expand...

You're correct, it wouldn't be (cost-effective). As with the PWB manufacturing, the cost of SMT assembly would be about the same for 5 boards as it would be for 500. It's even less cost-effective to have it done in the US (where SMT-manufacturing has almost now completely disappeared). You have costs for screen/jet-printers, assembly-line time, and inspection (possibly even test) that just can't be done cheaply, especially for small-batch runs (this comes from 20+ years in SMT-manufacturing experience).
 
Trixter said:
-- it's already brilliant.
Click to expand...

I agree, An excellent job, Better than the old google code site, Good idea on the 'Pre-built binaries download center', Handy for those who don't want to build from source and yet have access to the latest revision, And the source is available as it used to be.
 
There are still two uncovered issues with xtideuniversalbios:

1) It hangs on the drive benchmark in the Norton Utilities (NU SYSINFO menu-driven version).
http://www.vcfed.org/forum/showthread.php?19591-XTIDE-tech-support-thread&p=364313#post364313
It seems SYSINFO plays dirty tricks with interrupt timer trying to be "multitask" and BIOS hangs.

2) Bad coexistance with 8-bit MFM controllers and their BIOSes while FULL_MODE and boot menu are disabled.
Most of 8-kb "lite" controllers use short BIOS version and affected. Simptoms: can't boot nor MFM
nor xtideuniversalbios-driven drive, "C" and "D" letters does not work. Both controllers are working
"solo". No resource overlapped.
 
Thanks for the comments. The binaries thing does indeed need a link, but anyway it's driven from a post-commit hook so as soon as new code is pushed in, the binaries will be right there.

Thanks for the issue reports. Something not yet working is self service registration that will allow you to create an issue ticket. But please bear in mind all of this is incredibly time consuming so please be patient :)
 
alecv said:
1) It hangs on the drive benchmark in the Norton Utilities (NU SYSINFO menu-driven version).
http://www.vcfed.org/forum/showthread.php?19591-XTIDE-tech-support-thread&p=364313#post364313
It seems SYSINFO plays dirty tricks with interrupt timer trying to be "multitask" and BIOS hangs.
Click to expand...

According to http://www.vcfed.org/forum/showthread.php?19591-XTIDE-tech-support-thread&p=368707#post368707 it is a bug in SYSINFO: "The BIOS actually returns from the call to INT 13h AH=10h (AH10h_HandlerForCheckDriveReady as you noted) with a Timeout error (AH=80h) but SI ignores that and keeps calling the same function in its own timeout loop which keeps spinning for 65535 times.".

That sounds like the problem is with SYSINFO, not the XUB.
 
I suppose SYSINFO triggers internal error in the XUB. I seems a stack corruption or race condition or reenterancy failary. I did a trace, it hangs on the Drive Ready waiting. SYSINFO does a very quick poll a BIOS to determine transfer speed. On some fast or caching controllers SYSINFO can't determine speed and writes message about "advanced controller".
 
alecv said:
I suppose SYSINFO triggers internal error in the XUB.
Click to expand...

I don't think the XUB is at fault here. I think you're ignoring the part where sysinfo "keeps calling the same function in its own timeout loop which keeps spinning for 65535 times". That's a terrible design choice. A proper busywait loop would set a time quantum of (for example) 5 seconds, and stop retrying after that time period had elapsed. The designers of SYSINFO assumed all int 13h,10h calls return almost immediately, but that was never their assumption to make. IBM's own PS2 and PC BIOS Interface Technical Reference makes no mention of how long that status call should or shouldn't take.

I don't consider the SYSINFO hang to be a result of the XUB, but rather poor coding. The XUB Int 13h,10h call returns successfully after a few seconds.
 
Agreed, code style is ugly. However NU SYSINFO was extensively used in 90'th and there were no reports "hangs on transfer speed test" for many many systems. As shown in trace, this code
Code: 
call    IdeIO_InputStatusRegisterToAL
test    al, FLG_STATUS_BSY                    ; Controller busy?
jnz        SHORT .UpdateTimeout                ;  If so, jump to timeout update
always return result "controller is in BUSY state". It's very interesting which call sequence renders controller to this state even for uber-fast Compact Flash?

There was some reports the early 1.1.x XUB does not hangs. SVN bisect may help us to find critical change.

It's interesting also to build test-bench with identical hardware i.e. 286 with 16-bit ISA (to exclude 8-to-16 mux effects) and debug native BIOS and XUB.
 
glitch,

After posting all the teaser pictures inquiring minds want to know... how are the kits coming along? :D

-J
 
Just got back from a week-long work trip, it looks like all of the remaining kit parts have come in. I'm not digging into it tonight (9 hours of driving! woot!) but payment request emails should be going out this weekend or Monday/Tuesday next week.
 
Hello Glitch,
Please, remember ( from my old P.M. ) that althrough I have not preordered, I am interested in a full assembled unit OR "board + part kit" depending on price.
Please P.M. me if one "full kit" is left and if it is conveniant for you to send it with the first batch.
 
OK! So I finally had time to sit down and finish out the formulas in my big spreadsheet 'o parts, and I've got totals for everything as follows:

Bare Board $8
Parts Kit (KIT ONLY, NO BOARD) $20
Assembled unit $85

Shipping in the US as follows:

Bare Board (up to 3) $5
Parts Kit (up to 3) $7 (USPS Flat Rate Box)
Assembled Unit (up to 2) $7 (USPS Flat Rate Box)

Greater quantities and international shipping will be quoted per-order.

Please note! The parts kit does not include full sockets for everything, only the EEPROM. It's been my experience that sockets for all ICs, unless you're using high quality (read: expensive) sockets for every location, add more trouble than they're worth. All ICs have been sourced from reputable sources with supply chain documentation, so there should be a very low probability of dead ICs out of the package.

The EEPROM socket is a high quality machine pin socket with gold inserts. If people *really* want a socket kit -- again, it's been my experience that full socketing is more trouble than it's worth -- I can probably come up with an add-on socket kit.

If you preordered bare boards only (I think that was only one person) then order request emails have been sent out. I'm finishing up the script+template to email out the requests for parts kit orders.
 
Last edited:
You must log in or register to reply here.
Back
Top