dongfeng
Veteran Member
That would also be very useful if the card was mounted on a hard-card frame!
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
8-Bit IDE Controller
- Thread starter Agent Orange
- Start date
That would also be very useful if the card was mounted on a hard-card frame!
per
Veteran Member
A minor update has been done to the utilities package. It's really minor, and it fixes the following:
- some text that were not displayed in SETCARD when it should have been displayed, is now displayed.
- the flasher doesn't set default I/O port-base anymore if the /B:#00 parameter is not present, as the default one is already stored in the source-file.
- Some miss-information in the readme has been corrected, as we haven't really made the 100 cards yet.
hargle
Veteran Member
Brackets, brackets brackets!
I found a place, durcell technologies, who can do (and have done) ISA slot brackets, and just got a quote for under $2 each, but only if I order 250 of them. I'd previously asked if they had any old stock from the 80s lying around in a back corner, but they've got nothing.
What in the heck am I going to do with that many brackets?
Pros:
The price is pretty good. (a full dollar cheaper than mouser.com)
We could easily fill all of our upcoming 100 order and also fit one onto all the prototypes.
If we do additional ISA cards in the future for other projects, we'll have brackets for all of them.
We can actually get them. I've not found any other place with them in stock.
Cons:
$500 upfront cost for some cheap metal.
Only need 1/2 of that at most.
Storage until other projects take them off my hands.
Thoughts?
I found a place, durcell technologies, who can do (and have done) ISA slot brackets, and just got a quote for under $2 each, but only if I order 250 of them. I'd previously asked if they had any old stock from the 80s lying around in a back corner, but they've got nothing.
What in the heck am I going to do with that many brackets?
Pros:
The price is pretty good. (a full dollar cheaper than mouser.com)
We could easily fill all of our upcoming 100 order and also fit one onto all the prototypes.
If we do additional ISA cards in the future for other projects, we'll have brackets for all of them.
We can actually get them. I've not found any other place with them in stock.
Cons:
$500 upfront cost for some cheap metal.
Only need 1/2 of that at most.
Storage until other projects take them off my hands.
Thoughts?
Chuck(G)
25k Member
If I can chime in here, I'd recommend against it.
While you might get another ISA card design that requires a blank bracket, I think it's more likely that you have one that takes a connector through the bracket.
You might consider looking for some (or having some made up) that have a DC-37 cutout in them. One can always use a filler plate to cover it.
While you might get another ISA card design that requires a blank bracket, I think it's more likely that you have one that takes a connector through the bracket.
You might consider looking for some (or having some made up) that have a DC-37 cutout in them. One can always use a filler plate to cover it.
IBMMuseum
Veteran Member
- Joined
- Aug 28, 2006
- Messages
- 1,488
The trouble with a connector (at least the standard DB-style) hole going through bracket is that the manufacturer typically then won't have PCB mounts on it. That is, the bracket is retained to the adapter by the design of the connector. I wonder if there is a bracket with a rectangular hole for something like a 40-pin right-angle berg.
But I do like your concept of a DB-37 if my concerns above are addressed; It allows one to slip a 40-pin IDC cable in to connect it to the card (without device power, of course)...
From Jameco, including price breaks with quantity: http://www.jameco.com/webapp/wcs/st...toreId=10001&catalogId=10001&productId=101742
FWIW, I have seen an external IDE CD-ROM drive in a case with a 37-pin cable (it wasn't very long) connection, driven by its specific ISA adapter...
In fact I probably still have it around here somewhere...
Last edited:
Chuck(G)
25k Member
I've got several ISA brackets with DC37 cutouts and mounting "ears", so I know they exist(ed). A few ISA prototype boards (e.g. JDR) came with them. You could use a DC37 or not as your needs dictated.
IBMMuseum
Veteran Member
- Joined
- Aug 28, 2006
- Messages
- 1,488
I've got several as well (and also had at least two of the JDR prototype cards at one point), but they are vastly outnumbered by the brackets with just a DB-37 cutout, no mounting ears, hence me saying "typically". Typically I've also not seen too many DB-37 blockouts (compared to DB-9 and DB-25 sized) to cover the hole on the bracket. Of course, there typically isn't airflow issues on 8-bit systems (compared to later designs) to cover the hole, other than for esthetics (and keeping out some of the larger insect and rodent household wildlife).
digger
Experienced Member
There is a well-known problem regarding "bus-endianness" on AT&T 6300 / Olivetti M24 machines, related to the fact that those machines had a proprietary 16-bit extension to the 8-bit industry standard ISA bus. This extension predated the IBM 16-bit AT ISA bus, and as Murphy's Law would have it, the designers decided on the opposite byte order to what IBM would be standardizing on later.
As a result, there are some incompatibilities on such systems when equipped with an EGA card and certain applications that write 16bit data to the EGA ports directly (as opposed to through BIOS calls).
My question is: could this XT-IDE card run into similar problems with 16-bit I/O when installed in such a system? Or am I just being completely silly, not knowing what I'm talking about?
hargle
Veteran Member
I don't think it would. I say that because at the PC end, it's all 8 bit, and only from the card to the drive (and back again) it's 16 bit. So once it hits ISA-land, it shouldn't matter.
Of course, I've been wrong so many times now that I won't say for certain.
Either way, even if it is backwards, we'd just change the code slightly and rebuild it to reverse the byte order. Easy!
hargle
Veteran Member
Announcement:
User aitotat is going to be taking over all BIOS work on this project. This frees me up to concentrate on trying to get CD-ROM support proven out before we go into production, just in case any hardware changes are required. Writing a CD-ROM driver is a couple months worth of work, and trying to juggle all these things at the same time is draining my time.
aitotat's BIOS will still be open source, and will be a continuation of the existing XTIDE BIOS. All features from the existing XTIDE code (boot menu, eINT13) will be ported over to the new code base, and new features will be added.
thanks, good luck, and I'm still here for debugging work and testing, so it's not like I'm retiring completely. You can't get rid of me that easily.
User aitotat is going to be taking over all BIOS work on this project. This frees me up to concentrate on trying to get CD-ROM support proven out before we go into production, just in case any hardware changes are required. Writing a CD-ROM driver is a couple months worth of work, and trying to juggle all these things at the same time is draining my time.
aitotat's BIOS will still be open source, and will be a continuation of the existing XTIDE BIOS. All features from the existing XTIDE code (boot menu, eINT13) will be ported over to the new code base, and new features will be added.
thanks, good luck, and I'm still here for debugging work and testing, so it's not like I'm retiring completely. You can't get rid of me that easily.
per
Veteran Member
Do you know if setcard.com is compatible with aitotat's version? or do I have to change setcard.com to make it compatible?
hargle
Veteran Member
I see no reason why it can't be made compatible. It's a simple and totally easy to maintain, so we should keep it in place if possible.
--------------
In totally other news:
Just got a quote for $1.76 per bracket.
The place claimed they didn't have all of them in stock, but seems to be willing to order them, with just a couple weeks lead time. Sounds good to me. These are new old stock. I think I'm going to go for that.
hargle
Veteran Member
brackets brackets brackets!
I found a place willing to sell 70 of their new old stock for a whopping $0.28 each! they are the same keystone brackets that I picked up from mouser for $3.00 each. Muhahahah. I had to go through the electronics surplus supplier "send me a quote" process, but if this works out, we will likely have enough brackets for the whole production run, assuming that not everyone will need a bracket.
they are on their way to me right now, hopefully there isn't a typo in the description and I end up with a bunch of PCI covers or just blanks...
At a price that low, I should be able to also source some screws for them at my local hardware store and still come out ahead.
yay.
I found a place willing to sell 70 of their new old stock for a whopping $0.28 each! they are the same keystone brackets that I picked up from mouser for $3.00 each. Muhahahah. I had to go through the electronics surplus supplier "send me a quote" process, but if this works out, we will likely have enough brackets for the whole production run, assuming that not everyone will need a bracket.
they are on their way to me right now, hopefully there isn't a typo in the description and I end up with a bunch of PCI covers or just blanks...
At a price that low, I should be able to also source some screws for them at my local hardware store and still come out ahead.
yay.
I'm almost ready to release first beta of XTIDE Universal BIOS. setcard.com is completely incompatible since i have completely different ROM variables. Would it be better for setcard.com to modify ROM image instead of write settings directly to EEPROM? That way only one EEPROM writing procedure would be required when upgrading to new BIOS version.
I'm going to add new features to the BIOS in the future and that means new ROM variables as well. Best thing would be that setcard.com would use some script file that would contain configuration questions, all selectable options, ROM locations and such. That way setcard.com wouldn't have to be updated when i need to modify ROM variables.
Anyway, here is what i use at the moment. ROM variables start at offset 0.
Code:
; Controller specific variables (16 bytes)
struc IDEVARS
.wPort resw 1 ; IDE Base Port for Command Block (usual) Registers
.wPortCtr resw 1 ; IDE Base Port for Control Block Registers
.bBusW resb 1 ; Bus width (0=8-bit, 1=16-bit, 2=32-bit)
.bIRQ resb 1 ; Interrupt Request Number, 0=disabled
resw 5
endstruc
; ROM Variables.
struc ROMVARS
.wRomSign resw 1 ; ROM Signature (AA55h)
.bRomSize resb 1 ; ROM size in 512 byte blocks
.rgbJump resb 5 ; First instruction to ROM init (jmp)
; Offset 8 (8h) starts here
.strDate resb 8 ; BIOS build date string (mm/dd/yy)
; Offset 16 (10h) starts here
.strXTIDE resb 8 ; Signature string for XTIDE flash program
.strInfo resb 40 ; Reserved for additional strings
; Offset 64 (40h) starts here
.wFlags resw 1 ; Word for ROM flags, currently unused
.bIdeCnt resb 1 ; Number of supported IDE controllers
resb 1
resw 14
; Offset 96 (60h) starts here
.ideVars0 resb IDEVARS_size ; 8 words
.ideVars1 resb IDEVARS_size
.ideVars2 resb IDEVARS_size
.ideVars3 resb IDEVARS_size ; Must start within first 256 bytes of ROM!
endstrucI have currently reserved space for 4 controllers but this can be easily changed later.
One thing about flash.com. Is the "PCXT IDE" signature check really necessary? I think that it should be removed.
per
Veteran Member
The reason that's there is because almost all of the utilities takes use of it, when searching for already installed cards. One example is the automatic base-address search in the flasher. It is a lot easier for the user to just select a valid base address than trying to decode the switch settings and manually find the base address.
all of the programs expects the signature at offset 0x10 (hex), and then the following variables following:
- 0x10 = Signature ('PCXT IDE')
- 0x18 = I/O port (word)
- 0x1A = IRQ level (byte, not really used, but just in cause)
- 0x1B = DMA channel (byte, I don't even know if the hardware supports this at this point, but you'll never know, maybe in the future)
- 0x1C = Delay before booting (byte, in 1/18.2ths of a second. The boot menu can be entered durning this delay)
- 0x1D = First boot device ID (byte, 0x00 for drive A, 0x01 for drive B, 0x80 for drive C, etc)
- 0x1E = Second boot device ID (byte, same format as above)
- 0x1F = Action if normal boot failed (byte, 0x00 for boot-menu, everything else loads C-BASIC)
- 0x20 to 0x3F = Reserved for future variables (rigth now, they're not used at all and if variables are going to be put here, I should be notified so I could add support for them in the utilities)
If you move the according variables in your BIOS to the offsets above, then the utilities will be compatible as they are rigth now.
I can't use the same offsets simply because i don't have the same variables. My BIOS supports multiple controllers and doesn't have boot menu (yet). Every controller needs to be configured for different port and IRQ.
I can release first beta without any configuration program since port 300h is probably used by everybody. Maybe i should do my own configuration program later.
per
Veteran Member
Anyways, I suggest the variables are put at offset 0x20-0x3F. Those offsets aren't used by my utilities, as they were reserved for "future variables" of Hargle's BIOS. As Hargle has stopped the development of his BIOS, it's safe for you to put the variables there.
The benefits in doing this, is that they are being preserved when updating the EEPROM. That is, they don't get reset to default if automatic base-address scanning is being used when reflashing.
I/O port and IRQ can be stored in the offsets 0x18 and 0x1A. This way, you will still have different settings for the different cards, as long as you set them up individually after, or more preferable, when flashing them.
To what degree do your BIOS use IRQ transfers?
Does flash.com modify BIOS image on the fly or do you mean setcard.com? By the way, does flash.com generate checksum byte automatically?
IRQs are implemented and working but they are not used optimally at the moment. OS hooks (INT 15h, AH=90h and AH=91h) are supported but they are not used at the moment since they are supposed to exist only on AT+ machines. After that the IDE Status Register is simply polled in a software timeout loop. I could also poll the BDA variable that ISR sets but it is simpler to poll the status register directly.
Best way to implement waiting (when OS hook doesn't do that) would be to put the processor to sleep with HLT instruction. That would require timeout loops to use system timer. I didn't want to do that since there are programs that simply doesn't hook system timer interrupt properly.
per
Veteran Member
The only modifications the Flash.com does is to optinally set the I/O address into the ROM image (at offset 0x18), and to calculate and set the checksum byte (at offset 0x1FFF).
The flasher modifies all the variables of Hargle's BIOS, but it only updates the first 64 bytes and the checksum byte, hence it is a lot faster than reflashing the entire EEPROM.
For the delay, we didn't hook the system timer. We used BIOS function 1Ah, and just took note on how many "ticks" that passed before continuing booting. The variable controlling the delay is just the number of ticks to wait. No need to hook any interrupts to get that working. However, the delay is kind of pointless if there is no boot menu (as the delay has been working as a chance for the user to enter the boot menu manually).