Thanks. Did not know about this tool.
- 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
XTIDE Universal BIOS
- Thread starter aitotat
- Start date
The better policy will minimize burned roms that won't work. Thus yeah, this is terrible.
Last edited:
I took a look at some datasheets, and figured out that on some 27C128, the pin 27C256 uses as A14 is used as PGM (inverted). Thus if driven low, it'd enable programming. Therefore, most NICs that don't use A14 likely drive it high or pull it up.
Therefore, A14 will be permanently high on most NICs that don't support 32KB boot rom.
Thus, my 10KB 386l rom with correct checksum and padded with zeros wouldn't work because the exposed upper 16KB are just zero.
That would definitely have worked. Mine didn't work because wrong checksum.
And I went and burned my remaining 32KB rom as blank 16KB pad + checksummed 10KB + blank 6KB pad.
... and verify failed. My remaining rom was bad :huh:.
So testing will have to wait until I get UV eraser or more eproms (27C64 and 27C128 on their way).
Sigh.
Of interest, to test an option rom on qemu:
To checksum an option rom, this cute tool from from qemu: https://github.com/qemu/qemu/blob/master/scripts/signrom.py
And interesting quote from etherboot documentation.
I hope this is of use to someone.
I'll be back once I receive the goods and am able to do further testing.
Therefore, A14 will be permanently high on most NICs that don't support 32KB boot rom.
Thus, my 10KB 386l rom with correct checksum and padded with zeros wouldn't work because the exposed upper 16KB are just zero.
That would definitely have worked. Mine didn't work because wrong checksum.
And I went and burned my remaining 32KB rom as blank 16KB pad + checksummed 10KB + blank 6KB pad.
... and verify failed. My remaining rom was bad :huh:.
So testing will have to wait until I get UV eraser or more eproms (27C64 and 27C128 on their way).
Sigh.
Of interest, to test an option rom on qemu:
Code:
qemu-system-i386 -net none -option-rom ide_386l_padded.binTo checksum an option rom, this cute tool from from qemu: https://github.com/qemu/qemu/blob/master/scripts/signrom.py
And interesting quote from etherboot documentation.
I hope this is of use to someone.
I'll be back once I receive the goods and am able to do further testing.
Eudimorphodon
Veteran Member
I don’t understand what the “policy” issue here is. It is in the docs that the downloaded binaries need to be run through XTIDECFG before they are usable and that pads the image to the next 2k boundary and makes the checksum add up. That the downloads are not padded to a 2k boundary is a good tip-off that they’re not usable.
Also if you need to pad a configured ROM to a larger size for your burner to accept it (some software doesn’t care and will just burn an image smaller than the ROM into the start of it) there’s no need to update any checksum, as the docs say the header has a byte saying how many 512 byte code pages there are that count in the calculation. If you pad on a 2k boundary then it simply doesn’t matter what you stick in there as long as it’s not going to get confused for another extension. (I also assume that if you read a padded file back into XTIDECFG it would either complain about it being the wrong size or just discard the non-code pages.)
The expectation for rom images is for them to be ready to burn. A good policy is to have the safest defaults.
Knowledge about padding, checksums and such would be optional most of the time, so would be reading the documentation, if rom images were distributed in a burnable format, which (again) would be the safest and most correct way to distribute them.
Eudimorphodon
Veteran Member
The XTIDE project supports so many different hardware configurations I suspect you’d have quite a bit of difficulty getting people to agree on what the most useful default is. (I would go so far as to say that may be an impossible ask for the eight bit builds) It’s not unreasonable to expect consumers of such a technically oriented thing to put a few minutes into RTFM-ing.
maxtherabbit
Veteran Member
I've debated this with Krille before, but my stance is it is FAR easier for a user to see the XTIDE sign-on text and get the drift that it's looking at the wrong I/O port or whatever than to get absolutely nothing at all and be left wondering wtf.
My opinion: the ROM releases should be ready to load and execute, the default drive access configuration is irrelevant.
Imagine you are the user with no foreknowledge - if you see that the ROM is loading successfully but not finding drives, your troubleshooting instincts would then bring you toward the ROM's documentation. If you see that it is not loading at all, you would begin to suspect something else in your system or tool chain. EXACTLY as what occurred here. No one in their right mind would assume "oh this released option ROM image must not be checksummed"
My opinion: the ROM releases should be ready to load and execute, the default drive access configuration is irrelevant.
Imagine you are the user with no foreknowledge - if you see that the ROM is loading successfully but not finding drives, your troubleshooting instincts would then bring you toward the ROM's documentation. If you see that it is not loading at all, you would begin to suspect something else in your system or tool chain. EXACTLY as what occurred here. No one in their right mind would assume "oh this released option ROM image must not be checksummed"
Eudimorphodon
Veteran Member
… But if someone is insisting on not reading the manual and burns one of these unconfigured images to a UV-erasable or OTP EPROM they still just wrecked their day. Maybe I’m a big meany but I have my doubts that someone who isn’t even going to scan the manual for something that is pretty obviously more complicated than a pirated game ROM has the best instincts troubleshooting or otherwise. The warning that the BIOS images for download are useless until configured is the first paragraph of the first page of the website. The devs could put a “Readme.1st” file in the download dir proper for people that direct link there and skip the front page, but that’s about the only way I can see to put any more bubble wrap around it.
Maybe the unconfigured images should be padded and checksummed, but out of the box all they do is say “UNCONFIGURED: run XTIDECFG to continue!”.
(Edit: I just checked the modification history for the front page and the stern warning about running XTIDECFG appeared six months ago. I would definitely have more sympathy prior to that. FWIW, I do actually think a readme with the downloads could be useful additional CYA.)
Maybe the unconfigured images should be padded and checksummed, but out of the box all they do is say “UNCONFIGURED: run XTIDECFG to continue!”.
(Edit: I just checked the modification history for the front page and the stern warning about running XTIDECFG appeared six months ago. I would definitely have more sympathy prior to that. FWIW, I do actually think a readme with the downloads could be useful additional CYA.)
Last edited:
maxtherabbit
Veteran Member
You say "insisting" on not reading the docs implying people are being belligerent, when in reality the most common MO throughout the history of technology has been "try first, read later."
The disconnect here is that the symptom is not commensurate with the actual problem - a ROM being configured improperly for the hardware does not prevent it from loading and executing, it defies the knowledge of experience.
It would be trivial for the releases to include a checksum byte, I don't feel like I'm asking for a large accommodation.
The disconnect here is that the symptom is not commensurate with the actual problem - a ROM being configured improperly for the hardware does not prevent it from loading and executing, it defies the knowledge of experience.
It would be trivial for the releases to include a checksum byte, I don't feel like I'm asking for a large accommodation.
maxtherabbit
Veteran Member
that warning appeared at my behest, prior there was NO indication at all, anwhere
Eudimorphodon
Veteran Member
Thank you for that, then. I actually went back and checked the changelog on the Wiki front page after posting because bad memories of some significant issues with the documentation that existed a couple years ago when I built my first XT-CF suddenly came flooding back. (There was this period where it was actually really confusing to find the Download page at all if you came in via the front door.) So... yeah, the docs have certainly had their gaps in the past. At least it's there now.
That said:
I know it's been everyone's gosh-given right as an American to just dump the newest hyper-sophisticated miracle of modern science out of a box, plug it in, and have it "just go" since the 1950's, and based on such it would be a reasonable expectation for someone, say, buying a complete XTIDE card to assume the BIOS chip on it was set up to at least accommodate the default jumper settings so it's "plug and play". But the BIOS itself isn't a "consumer" item, it's "system integration"-level code that typically *will* require customization for whatever hardware it's intended to go with, and making the wrong choices can in a significant number of edge cases create crash-severity conditions. Having an unconfigured image do "nothing" is the safer option compared to having it try to do wrong thing.
(If the code had more capability to at runtime autodetect hardware this would be less of a problem, but as it is it requires re-flashing the ROM if you change port hardware addresses, let alone what hardware scheme you're using.)
If someone wanted to take on the job of curating pre-configured ROMs for various common configurations maybe that wouldn't be the worst idea ever. I haven't used the AT build, only the XT ones, and on the XT side of the fence 16-bit "full" XTIDE and 8-bit XT-CF-lite hardware seem to be about roughly equally common and there are significant type variants of both. Therefore the chances that a "generic" binary will be correct one seem pretty low. Maybe there is a "generic" AT config that covers 95% of use cases with no further config?
maxtherabbit
Veteran Member
This is really the crux of my disagreement, I cannot concieve of a situation where running an improperly configured XUB would actually hurt anything
Eudimorphodon
Veteran Member
To pick a random example from the XT side of the fence: If you enable "Full Operating Mode" then pretty bad things will happen if you use that BIOS in a Tandy 1000 (you will crash and burn hard if you use a Tandy graphics mode), but if you don't enable it you'll break ROM BASIC in an IBM machine. Which should be the default?
Back in the early days it was a no brainer, The 6 monthly and prior official releases on the old google code site were configured and checksummed, The XT binaries were configured for the XTIDE R1 controller and the AT binaries were configured for the 16-bit controllers because there was no other's until the XTIDE R2 > / JR IDE and Lo-Tech ISA CF / Lite controllers appeared, The BETA 3 was the last of the configured and checksummed binaries to be released in March 2013 which was R517, The Google code XUB site was shut down in 2016, By then the XUB revision had reached r588.
Eventually the XUB found a new home and is now at r618, It supports more controllers and more systems, I have no idea what's involved server side in setting up to provide basic configured and checksummed XT binaries configured for the XTIDE r1 controller and AT binaries configured for the 16-bit controller,
Personally i don't see the point in checksumming NON_CONFIGURED_BINARIES but maybe a basic configuration would make some folk happy or not.
Eventually the XUB found a new home and is now at r618, It supports more controllers and more systems, I have no idea what's involved server side in setting up to provide basic configured and checksummed XT binaries configured for the XTIDE r1 controller and AT binaries configured for the 16-bit controller,
Personally i don't see the point in checksumming NON_CONFIGURED_BINARIES but maybe a basic configuration would make some folk happy or not.
maxtherabbit
Veteran Member
To answer the specific question as posed, I'd break the ROM BASIC, because who cares lol.
But my meaning in bolding hurt was to imply real damage, such as data loss, not simply making something not work.
Overall I like the idea of making the releases conform to the most likely use cases by default, as malc laid out. 16-bit IDE for the At build and so on
But my meaning in bolding hurt was to imply real damage, such as data loss, not simply making something not work.
Overall I like the idea of making the releases conform to the most likely use cases by default, as malc laid out. 16-bit IDE for the At build and so on
Eudimorphodon
Veteran Member
Hey, I actually like the idea of embedding a code stub in there that says "Thank you for downloading, now read the manual" if an image isn't configured if a dev wants to toss it together. 
My expectation is for people to read at least some of the documentation. I guess we should both adjust our expectations. If you think that reading the documentation is optional then by all means, don't read the documentation.
Actually, I just tried and it does neither. It will preserve the file size on disk. It should also flash the whole file to ROM but I can't test that.