• Please review our updated Terms and Rules here

Anyone Selling XT-IDE Cards?

I don't know where i got Filecard from, It's actually a "Plus Card" from Plus 5 engineering in the UK, The hard drive is a "Lapine", I can't quite make out the date of it but it's 28/4/8??. Seems to have Zilog / Omti controller chipset, Nothing on what i assume is the BIOS chip but i'll try and dump it later.

EDIT
I dumped the "Plus Card" bios and looking inside with a hex editor i can see " Copyright 1985, 1986 SMS "
 
Last edited:
This isnt right:

RP1, RP2 10K x 9 SIP resistors 266-10K-RC

That needs to be a 10K bussed type 10 leg sip resistor. You wrote 9 leg. Perhaps a 9 leg should also work i dont know.

I ordered them from Bourns with part nr 4610x-101-103 100pcs.

The part # is correct, 9x 10K resistors in a 10-pin SIP package. Mouser description is "Resistor Networks & Arrays 10PIN 10KOhms 2%"

10K x 9 means 9 resistors, and of course a tenth pin for the common. It does so happen that a 9-pin, 8 resistor network will also work in the rev 3 board, as well as an 8-pin, 7 resistor network, since the last two positions aren't used on either resistor pack.
 
.....I've got some MFM drives in the shed and later i will sort through them but i doubt if any of them are working now, I remember a couple of them worked 'ish' but they have been in there a long time.

I've gone through the MFM drives i could find and as i suspected none of them are working, Though i did find one that i didn't realize was in the shed and it works, It's an old 20Mb NEC 134-200450-002 from 1985 with a WD1002S-WX2 controller card, I had no problems booting from either the NEC (foreign drive) or CF using the HOTKEY bar or BOOT_MENU in XUB r591.
 
Personally, I'm not willing to ship assembled cards with the 2 series BIOS since they're still marked "beta" -- if the author is still calling it beta, that makes it not ready for general use, in my mind. Don't like it? Remove the beta designation :)

I'd like to remove the version info entirely because it's actually pointless. Just have the build date as it is now plus the Subversion revision number instead. This would require support on the server side though.

Secondly, there's no preconfigured image that fits in 8K with a boot menu. While I and presumably other hobbyists can certainly build our own with the provided source + makefile, I bet there are a lot of people who can't or don't want to try and build their own BIOS image to get it down to 8K. Perhaps make an 8K version with boot menu and no serial disk/floppy support officially available?

There's a reason for the missing boot menu. Some people didn't want it so it was made optional by dividing the functionality into two separate modules, MODULE_HOTKEYS and MODULE_BOOT_MENU. This change made it no longer fit in 8 KB and so here we are. Now people are complaining that it's gone which is hilarious considering that it's a non-issue when using a large build with a 32 KB ROM. AFAIK, the original XTIDE v1 is the only card that doesn't support ROMs larger than 8 KB, to people using that card I'd recommend using a custom build. Build it yourself or use a build provided by someone else, such as the one Alecv made and posted a link to earlier in this thread for example.

Yes, it could be argued that it should be yet another official build. The obvious problem with that is that we would quickly end up with a lot of builds even if we only provided the most commonly used combinations of modules/build options. And some people would be confused about what build they should use. And so the whining continues... The ultimate solution to this problem would be something like the ROM-O-Matic together with some good documentation. Which brings me to...

Third, it's actually kind of hard to figure out what you're supposed to be downloading and/or running w.r.t. the 2.0 XUB. A Google search brings up the Lo-Tech Wiki, then the "official" site (xtideuniversalbios.org) a bit lower down. Of course, the Lo-Tech Wiki still references the Google Code site. The downloads are non-obvious on xtideuniversalbios.org and the source browser seems like an early 2000's CGI for browsing SVN. Considering the Google Code site has handy "Export to GitHub" buttons all over the place, they may be trying to tell you something :) I'm a programmer and hardware engineer for my day-job and I find it difficult to navigate, so I'm betting other people do too.

...the official site (yes, it is the official site, there's no need to put that in quotes). It needs a proper front page, with links to the download section and the repository as well as links to the manuals (which are sorely in need of an update, btw). Any volunteers? I bet James would be grateful. I know I would be.

Again, I think two big, relatively painless steps in getting people using the 2.x XUB would be to (1) remove the "beta" label if the devs really feel it's ready and (2) start providing 8K builds that will "just work" with the boot menu and whatnot. The rev 3 boards and Lo-Tech boards both left the serial port off, so removing serial disk/floppy support, adding the boot menu, and building that as another binary output in the release process shouldn't cause too much headache/confusion for the users.

(1) As I wrote above, I basically agree with you on this. I just want to point out that I don't actually think it's ready. Yes, some parts like the standard IDE, the XT-IDE and XT-CF hardware support is ready, but the other controllers need testing. For example;

  • The ADP50L controller; Can be autodetected by XTIDECFG, actual BIOS support has not been confirmed however.
  • The JR-IDE/ISA controller; I don't know of a single person actually owning one of these.
  • The PDC controllers; Code recently added but not tested, probably not working.
  • The QDI Vision controllers; Used to work but recent changes might have broken the support for these.

(2) Providing builds that "just work"? Hell, why didn't *I* think of that?!? ;) Joking aside, if people can be arsed to run the configurator (XTIDECFG) that will go a long way in that direction. The controller autodetection works surprisingly well, so there is actually a fair chance that it will "just work". Regarding removal of the serial drive code; yes, the serial port hardware has been removed but the code supports use of any serial port in the system. If any part of the real floppy drive subsystem goes tits up, this is a great feature to have. And, as I wrote above, this point is actually moot with the XTIDE v3 card since you can use 32 KB ROMs.
 
I will add wiki updates and SEO to the list. We can changes the strings in the build process I'm sure, but aren't these somehow compressed and need some re-compression if they are changed before building?
 
Aren't strings compressed when building anyway, All builds contain "MODULE_STRINGS_COMPRESSED" ?, With my own custom builds i hacked the code to show the SVN revision number and had no problems building.
 
Cool, I will have a go. It should be easy enough to sed in some text replacement, perhaps we could change the appropriate source to <build-number> instead of the Beta 2.0.... text string so we have something consistent to change.
 
No, the version string is not compressed. This would need to be a post-commit hook script that changes these two lines in \XTIDE_Universal_BIOS\Inc\Version.inc;

This;
Code:
%define	ROM_VERSION_STRING		"v2.0.0",BETA,"3+ (",__DATE__,")",NULL

into this;
Code:
%define	ROM_VERSION_STRING		"rXXX"," (",__DATE__,")",NULL
where XXX is the revision number obviously. Further down is the C/C++ equivalent used when building serdrive.exe;

Code:
#define ROM_VERSION_STRING		"v2.0.0" BETA "3 (" __DATE__ ")"

which should be changed to;
Code:
#define ROM_VERSION_STRING		"rXXX (" __DATE__ ")"

It would end up looking something like this;
Code:
-=XTIDE Universal BIOS (XT)=- @ D000h
r592 (2016-07-18)
Released under GNU GPL v2

Anyone have any objections or suggestions for improvement?
 
Same as i did it, but with a couple of variations:

Code:
-=XTIDE Universal BIOS (XT)=- @ D000h
Rev 592 (2016-07-18)
Released under GNU GPL v2

Or

Code:
-=XTIDE Universal BIOS (XT)=- @ D000h
Build r592 (2016-07-18)
Released under GNU GPL v2

As long as the revision number is shown, it doesn't make a lot of difference really
 
Nice work! The bracket looks like it worked out well. There will be a Slot 8 Support daughterboard available soon, the KiCad and Gerber files will of course be made available, if you want to run your own.
 
I've had a strange issue with my new XT-IDE - It works fine on most HDD's, as well as my 1GB DOM... but there's one drive that it doesn't like!

My Maxtor 8051A (40MB AT-IDE) detects (and works properly) as 13MB! On other machines it detects fine (My 286 Clone for one)
Any idea why this would be the case? I was planning on using it in my Tandy 1000 as the power supply won't run a 5.25" HDD.

Not a huge issue as I can probably get another 40MB IDE to test fairly easily, I was just curious!

Bobby.
 
<snip> I was planning on using it in my Tandy 1000 as the power supply won't run a 5.25" HDD.

<snip>
Bobby.

My Tandy 1000A that I acquired from the original owner had (2) 360K floppies & an ST-251 stuffed inside it when I received it. It ran fine from the HD. I replaced the HD with a Lo-Tech XT-CF-lite, mainly because I didn't like the unsecured HD floating around inside the case.

Tom
 
I've had a strange issue with my new XT-IDE - It works fine on most HDD's, as well as my 1GB DOM... but there's one drive that it doesn't like!

There are timing issues in the MUX design which limit device compatibility.
 
There are timing issues in the MUX design which limit device compatibility.

Do you have a timing diagram or something for this? This keeps getting repeated, but I can't find the problem in the schematic.

Anyhow, a capacity mismatch doesn't sound like a timing issue. I would suspect you would get intermittent boots and randomish capacity "changes" if something in data mux timing was causing the XT-IDE to read the drive's capacity incorrectly.
 
Last edited:
What XUB rev are you running in your 1000? I used R566 originally. I had problems where I formatted the card & was able to boot, but I suddenly couldn't boot the next time I started the 1000A. After changing to R591 those problems seem to be gone. I need to get time and explore all the options available in XUB.

Tom
 
I'm using whatever configuration I was sent by glitch in this post :)

Maybe I'll try flashing another BIOS to it and check?

I'd rather not have the 30 second boot menu delay anyway, so i was looking to do just that.

Bobby.
 
Back
Top