Started going back and watching your videos from when you first started repairing computers. It's amazing where you started from....... Now when you say "to the bench", I will always picture your old workbench with tools hanging on the pegboard !! Lol
Was up till 3 am last night trying to get a CF card working on my 5170. Found this video this morning surfing the web. Adrian to the rescue. Bios update did the trick. Love the channel!!
This is pretty interesting stuff. I just started following your channel and i'm pretty happy with what i see so far. I've got a stack of old 286, 386, 486 clones as well as some IBM machines as well. Trying to find the time to play around with them and i'm glad to see others with this interest as well!
I remember the days I used to hack the BIOS to move the video BIOS on the EPROM so I could get more contiguous memory for the network stack and adapters. The good old days may they never return
Last time I saw a working 286 was around 1997 in a local newspaper office. They used it to write articles then saved them on floppies for printing. It was very obsolete already but somehow worked flawlessly. They had 40MB Seagate HDDs and nothing else but DOS 3.3 some editor software like Chiwriter or Wordstar and Norton Commander which was pretty ubiquitous back then as a very handy file manager.
So exciting. I would never have guessed that. Haa, yeah was thinking TL866 TL866, and then there you had bought that one. I have it too, its great for its value. I use it for MCU programming as well. Great video.
Using a different BIOS was obviously the right thing to do. I have a strong suspicion about the bug in the original BIOS: Somehow the hard drive and the mainboard get out of sync, with the mainboard waiting for the hard drive to do something on the one hand, and the hard drive waiting for the mainboard to do another thing on the other hand. At some point in time, the mainboard gives up (the BIOS has a timeout built in) and returns the "not ready" error. This deadlock only appears on files above 1K, as you say. I suspect the real limit is already 513 bytes (i.e. more than one sector), but let's not argue about it. If you want to read more than one sector in a row, you can send a "read sectors" command to the hard drive, and specifiy the number of sectors to read. The IDE protocol for reading 2 sectors in a row is: HOST-a) set up the command parameters (select master or slave, set sector count (2 in this case), set start C/H/S value) HOST-b) issue the read sectors command (write 20h to port 1F7) HOST-c) wait for IRQ14 for the first sector HOST-d) read 256 16-bit values from port 1F0 HOST-e) wait for IRQ14 for the next sector HOST-f) read 256 16-bit values from port 1F0 A single-sector read works the same, but the process is done after step HOST-d. So it is very likely that there are no problems until step HOST-d. The only wait operation in this sequence is step HOST-e, so I strongly suggest that the BIOS hangs in step HOST-e. (I can't be sure, because there might be sub-steps like polling a "drive ready" or "drive wants to send/receive data" bit, which can also timeout). On the other hand, the on the side of the drive, the process it like this (it's the process used on a typical 1986 hard drive without any caching, read-ahead, double-buffered memory or anything like this): DRV-a) wait for a command to be issued (in this case, 20 = read sectors) DRV-b) obtain the command parameters from the parameter registers (aka the "IDE task file") DRV-c) seek to the requested track, if not already there DRV-d) wait for the sector ID of the requested sector to show up DRV-e) read sector data + ECC bits into a local buffer on the drive DRV-f) poll the ECC error detector status bit (most drives of that time do ECC calculation in dedicated hardware while transferring the data from the drive to the sector buffer, so the drive processor does not have to actually calculate anything if the hardware says "ECC OK"). DRV-g) set up the bus transfer logic to transfer the contents of the sector buffer to the host DRV-h) raise IRQ14 DRV-i) wait for the transfer logic to indicate that the transfer has been completed DRV-j) [basically go to DRV-d] wait for the sector ID of the following sector to show up DRV-k) repeat steps DRV-e,DRV-f,DRV-g for the next sector [letter "l" skipped due to similarity with 1 and roman numeral I] DRV-m) [repeating step DRV-h] raise IRQ14 again DRV-n) repeat step DRV-i: wait for the second sector to be transferred to the host DRV-o) go back to step DRV-a As single-sector reads work, I am confident that everything until step DRV-i works perfectly well with the AMI BIOS. Step DRV-i completes in lockstep with the step HOST-d. On a classic hard drive, steps DRV-j and DRV-k take a considerable amount of time, giving the host processor time to re-arm the IRQ14 wait process. At the time a classic drive reaches step DRV-m, the host computer is actually waiting in step HOST-e. On the other hand, modern drives read the subsequent sector into a buffer *while the host is transferring*, so step DRV-i is postponed, and the transfer to the host is parallelized to reading the next sector. In fact, the "wait for the host to be ready" can be postponed up to step DRV-m. The drive *must not* generate the second IRQ before the transfer is complete, but it may do so directly afterwards. So my theory about the issue is like this: On modern drives with read-ahead, or on drives that do not need to read to a sector buffer first (CF drives could transfer from the storage to the host directly) the IRQ14 for the second sector can be raised so quickly after the first sector transfer is completed, that bad code on the host might miss the second IRQ14. A typical AT BIOS implementation of IRQ14 is that IRQ14 does nothing except set a flag in the BIOS data area that IRQ14 occurred. Suppose the AMI BIOS works like this (letters as in HOST-x, numbers indicating substeps): AMI-c) poll the IRQ14 status bit AMI-d) read 256 words from the hard disk AMI-e1) clear the IRQ14 status bit AMI-e2) wait for the IRQ14 status bit to be set again and imagine the second IRQ14 to occurr between steps AMI-d and AMI-e1, in AMI-e1 the second IRQ14 will be discarded, and AMI-e2 is going to wait for a third IRQ14 which is not going to happen. Boom - there is your deadlock. One non-buggy ways to implement the process would be: BIOS-c1) poll the IRQ14 status bit BIOS-c2) block IRQ14 BIOS-d) read 256 words from the hard disk BIOS-e1) clear the IRQ14 status bit BIOS-e2) unblock IRQ14 BIOS-e3) wait for the IRQ14 status bit to be set again This would leave the second IRQ14 pending in the interrupt controller until the computer has already cleared the status bit. Another valid implementation is: BIOS-c1) poll the IRQ14 status bit BIOS-c2) clear the IRQ14 status bit BIOS-d) read 256 words from the hard disk BIOS-e4) wait for the IRQ14 status bit to be set again If you happen to still have that AMI BIOS, I would be interested to analyze whether my theory is right, and I was able to correctly identify the bug in the BIOS without seing any byte of BIOS code first. Can you confirm whether your BIOS matches the AMI BIOS with the same manufacturing date listed at www.minuszerodegrees.net/bios/bios.htm ?
Actually, *if* the BIOS matches the BIOS I linked, my theory is wrong. The BIOS I linked seems to implement the second algorithm I showed as "valid implementation".
I think I got it. I expect the same problems if you used the original AT BIOS dated 06/10/85, as shown on github.com/kaneton/appendix-bios . Both that BIOS and the AMI BIOS do not follow the fine print of the ATA standard (shown for example in ATA-2, published 10 years later on, see www.t13.org/Documents/UploadedDocuments/project/d0948r4c-ATA-2.pdf ). In the linked document, on page 76 (according to raw PDF page numbering), AKA page 63 (according to document internal page numbers) the steps of a PIO input command are shown. They are [... skipped until the step where an interrupt should be generated] SPEC-g) the drives reads the requested sector to an internal buffer, then sets the status register, clears the busy bit, and asserts an IRQ14 *SPEC-h) the host reads the status register* SPEC-i) if the drive wants to transfer data (it may reject data transfer in the error case), read 256 words SPEC-j) the drive already negated IRQ14 *in response to SPEC-h*, and the process repeats at step g if no error occurred. Both the original IBM BIOS and the AMI BIOS do not do SPEC-h. They *don't* test the status register before reading the data block, but the Quadtel BIOS *does* read the status register before transferring the data block. This means they might read a data block on error, even if the drive does not have any data available (e.g. in a sector-not-found condition). Reading data without data being available is benign, because reading the data port if no data is available does not crash the system, it just yields undefined data and transferring the block wastes some time. But that *also* means the the drive may not negate the IRQ14 line during the whole read process, because the drive must not negate IRQ14 until it is "acknowledged" by the host by reading the status register. (That's what the spec says. Reading the data register is not specified to be an "interrupt acknowledge"). The IBM and the AMI BIOS check the status register after the transfer instead. So the race condition I suspected in my first comment is likely to happen, but at a different point in the system than I expected. I still assume that a fast drive issues the *next* IRQ14 directly after the transfer, and the host did not do something in time. In this case, the "something" the host did not do in time is not (as I wrote in my first comment) clear its own "interrupt occurred" flag, but it is reading the status register. The drive requests the "next" IRQ before the previous IRQ was acknowledged to the drive. This could cause two kinds of situation which behave the same from a software point of view: a) because the previous interrupt was not acknowledged before the next interrupt should be signalled to the host, the IRQ14 line keeps asserted all the time. The ISA bus defines IRQs to be edge (originally I wrote "level" here, but this is blatantly wrong, and I never meant to write it) triggered, so keeping IRQ14 asserted the whole time does not trigger a new interrupts. b) because the next interrupt was signalled before the previous interrupt was acknowledged by the host, the host accidentally acknowledged the next interrupt. This causes IRQ14 to be negated, and again no new interrupt is generated. With your scope, you could easily differentiate between situation a and b by just checking the IRQ14 line when the system is locked up, but I don't consider the distinction interesting. What might be interesting on the other hand is the width of the IRQ14 pulses for read requests. The fastest you can get with "REP INSW" to receive data from the hard drive is 4 cycles per word transferred (that's the adverstisment number taken from the 80286 datasheet, but it is assuming 0WS memory and 0WS I/O, which is really atypical. Most AT boards insert at least 1 WS for the IDE data access), let's use a more realistic 9 cycles per word (1WS on memory and 4WS on I/O). That's around 2400 cycles for a sector (including some overhead). At 12MHz, 2400 cycles is 192µs. Check your video at ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-io66EelryLc.html, and you will find the last IRQ14 pulse to actually have a width of around 220µs. This matches the IRQ being asserted during the whole transfer, and negated as the BIOS checks the status after reading all the data from the drive. If that oscilloscope shot is from a situation where you got a timeout due to a longer read request, it confirms the theory that the second IRQ for the multi-sector read (not block-mode read, that's an entirely different thing and not supported by standard AT BIOSes) indeed got lost.
Great job ! As for erasing EPROMs: if you have bright sunny days, just peel off the sticker and place them in direct sunlight for a couple of hours. The sun‘s UV rays should do the Trick. Since you have an Eprommer, you can check if the EPROM is erased completely.
You can install a SCSI-Controller like the Adaptec 1542cf. This allows you to add harddisk with any capacity you can get and use external harddisk.cases with more than one drive including cd/dvd-drives.
Thank you thank you... I have a 286 portable computer and the hard drive is a gonner. I wanted to put a CF-IDE adapter but that didn't work, neither do my IDE drives. I have the AMI Bios (1987) installed. Exact same chips to!
Great videos. I have a bunch of motherboards. and SD cards. As soon as I have some time and energy, I will see if the 286 I have can handle a SD card. Hi from Astoria Oregon.
Thanks a lot man. I have been struggling with the commodore c286lt laptop and cf2ide adapter for two months. I tried three cards: 32MB CISCO, 256MB UNIGEN and 1GB PRETEC. Nothing works. They work in a newer laptop, but not in a commodore. I was able to fix the old CONNER CP2024 hdd faster and the Commodore c286 came to life. Thanks for the hint that the culprit is the BIOS - old Phoenix V. 3.10.00-11 / 1985-1990 / - I think so.
Reminds me when I upgraded my IBM 5170 when I was in my teens. A friend of my mother gave me a huge box of parts and a bunch of old Seagate hard drives. They were all RLL drives. My WD RLL drive that was in the computer had a bunch of bad sectors so I tossed in two 20MB drives but the BIOS didn't like it and kept booting into BASIC. Since there was no internet at the time as we know it and had no idea how to access the BIOS other then with a typical clone was the DEL key I tossed in a BIOS from a busted off brand 286 motherboard and I was good to go. I even tossed in a memory expantion board giving me a whopping 2MB of RAM, some Packard Bell combo sound/modem card. I did other things to it but I finally scored a 386 DX 40MHz board and 16MB of ram and two Maxtor 500MB IDE drives, by then it was totally a different system. Not to mention Windows 95 looked odd with EGA graphics.I think by time I was 19 I had it running Linux. If I knew how much these old parts go for I would of kept them or sold them on ebay lol.
Ok, I'm impressed enough now to comment! You really pushed the boat out to solve this one. I have a similar fascination with old computers, been looking at the same EPROM burner on ebay for a while. I have a Compaq Portable III with the same 504MB drive limit. Some of your other vids have directed me to the VIDE software to solve that issue. In this video I learned all 286 boards are identical and you can actually flash any 286 BIOS to them. I had no idea! Thank you for the time and effort you put into these videos. Very clear, concise and well edited. Do you have any interest in older machines? I just got my NEC APC up and running. Next job is to create some 8" floppies from software images and get the printer working. I also have an Intertec Superbrain and !MS 8000 S100 unit. I have subscribed! By the way, pls keep it music/effects free - its much cleaner and less distracting. Well done!
I think at this stage of IBM PC compatible computers there was very few (or none) extra, nonstandard components included on motherboards. Like you said, the chipset was trying to be 100% compatible with IBM's original. Which is why your new BIOS code worked OK. As soon as MB manufacturers started integrating things like disk controllers, sound cards and even joystick ports, all BIOS's became unique to each model.
Can you imagine that technology in the 90s that would be awesome, I remver that 286s were sold without hard disks because they were so expensive and we were managing everything with floppy disks
I have so good memories with my 286 - 16 Mhz plus math coprocessor! Along with my Amiga 500 it was a beast compared to. Apart the multimedia/games compartment it had faster cpu and moved 3d-vectorial graphics much better.
Ha I look like you, talk like you and share a love of 286s like you. Very nice vidjayo. Never would have tried to use any other bios than oem. Good way to think outside the box
Almost all 286 machines are all the same and just based off the IBM 5170. Later with the 386 things started to differentiate from one chipset to another.
Need to try and revive a 286 machine I have. It is the only machine capable of programming the old Motorola Saber two way radio. It is slow enough to talk to the radios comm port. Anything faster will literally turn that radio into a conversation piece ( no pun intended ).
I do love your shows. One small correction though... Not all 286 motherboards are clones of each other. There were brands like Tandy (I know, you already know this too) and their motherboards were never clones. From day one they engineneered theirs from top down to be specifically not clones.
Hello i am new to your channel and i must say that i really enjoy your videos!! i love all the old hardware, and i am in the process of looking for a older system to run win 95/98. i would like to set up some older games from my younger years, and all of your videos have been great fun to watch!! Thank You Great Work!!
weird thing is i have zero experience w working on computers yet from the first video on this you posted it reminded me of a bios issue (specifically a bios wiping virus that i also watched on youtube) so weird!
be aware with old IDE drives, you must "PARK".EXE the heads manually because old drives don't parks the heads automatically when the power switch off. And that is how old drives get broken, by new ppl trying to enjoy old hardware.
That's true of old drives with stepper motor actuators. With a couple of exceptions(that probably broke a couple of months after purchase because they were cheap and nasty), any IDE drive you like has an auto-parking voice coil actuator.
oh also, there's some program that will tell you the correct cylinders and heads, if you have a bios that lets you change hard drive options that fixes it as well.
I'm sure I'm not the first to make this offer, but here goes... I repair computers and have a gaggle of legacy stuff that I have been hanging onto that I would like to get rid of. If you're interested, I'll take some inventory and you can have it for the cost of shipping. Lemme me know.
I used to have a bunch of legacy stuff (8088 class machines and pherephirals). I ditched them years ago. Kicking myself in the arse since I got into retro computers, and I could use some of those parts right about now.
5:24 EPROM eraser... Is just a black light and you shine it on the chip for a few hours. Used to be my hobby erasing eproms at a 2 man pc store back in 1991 in wheaton maryland. One day I just wanted to hang out and they did not mind and they taught me stuff for free lol
same happened to me the problem is not with the cf adapters but with the cf card because some card cannot boot even if they work in normal condition i test several cards and at last the Toshiba 1 GB cf card worked well and the computer booted as a normal HDD
So, any information on where you purchased the EEPROM flasher, the EEPROMs, or the new version of BIOS? Since this was an obvious success, after all of your efforts, it would be helpful to know your sources, so we can yield the same results.
What about 286 chipsets that offer special memory management features like EMS or ROM shadowing? Don't they need different BIOS to control their extra features? And what about memory timing? In some BIOS wait states are even selectable. And why VGA speed differs dramatically with the same video card in various 286 mobos? Okay, ISA clock may be different but doesn't that need some tending from the BIOS too? And even different ISA clock can't explain some 3-fold difference.
I have a cheap 286 coming next week that I paid $20 for. I don't know if it works, but at least the previous owner said that power source turns on. I might be troubleshooting similar things in near future myself :)
I paid $25 for shipping, so $45 total. From pictures is looks like it has an I/O card and an EGA card inside. I have a VGA card that I can replace it with. It looks all original 286 from 80s
That original BIOS was probably implementing the classic int13h interface. Making only 504mb actually work, and failing when trying to access beyond that physical geometry. Like in a spreadsheet, your still on the first row, but the info you want is in collumn abc, but the bios can only function up to column zz, even though it shows theres more. Enhancing the bios (updated) gets by that early CHS implementation limit (until 8GB anyway, then you need LBA). Its not the size directly, its the way CHS was implemented early on, resulting in problems with storage bigger than 504mb until BIOS's int13 interface were enhanced. Good on ya finding a BIOS to work on that board! Just don't go putting a 16GB card on that 286's bios, god help ya if you do! However.... a 3rd party EIDE BIOS would probably work for that. Or a Promise controller with a BIOS of its own.
@@mcping I'm almost certain that would work. I'm sure I did that very thing for a picture frame project with an IBM thin-client back in the day. Certainly worth the try if you find a vintage one of that size on ebay or thrift store, etc.
Have you considered trying to install a more modern OS on it? Perhaps ELKS? I've been trying to get ELKS running on a 286 toshiba laptop, but no luck so far.
Great video! I have an almost identical motherboard, a DATAMINI 286, with same SUN TAC chipset, almost same layout (apparently the only difference is in the ISA bus section)... but the BIOS is on 2 x 27128 EPROM instead of 2 x 27256 EPROM... Strange... I suppose I can't use the 5170 bios... am I right?
Adrian, what is the cpu speed of your 286? I’m going to do this bios update on my 12mhz Phoenix ver 3 bios with faraday chipset. Hope the 12mhz won’t be a problem for the 8mhz BIOS. Thoughts on compatibility? Having same probs you had.
I had no idea this was possible! I wonder if anyone is selling chips with the latest 286 BIOS on them. Or would it even work with some kind of XTIDE Universal BIOS?
When programming a chip, you can only set the bits in one direction (usually it's high already and you program what you want to go low). In order to undo that programming you have to expose the windowed EPROM to UV so that it can forget it's programming (the bits go back to high, if they weren't already). Modern Flash EPROMs can do this in hardware, and the programmer can usually take care of that automatically.
No, these are Eprom, not EEPROM, the former is erased with UV light, the second by electron emittion, and therefore can be done programmatically. The term 'Flashing' comes from the use of xenon lamps used in camera flashes in order to wipe the memory. Foil tape is used in order to prevent accidental wiping when taking pictures of your motherboard :) The only way to remove the electrons from memory so it can be written again with Eprom was via UV light. In theory, you could bit flip zeros to ones, but you could not flip a one back to a zero.
I knew someone was going to crawl out to make a unneeded discussion about EPROM vs EEPROM. In the video he discusses both (even if just briefly) as well as in my reply (if you'd actually hit the read more button, instead of just lashing out about it).
I'd assume the reason both need to be erased is the same though. Which is the question I was asking. I was concerned about why and not how in this case.
Hello, I got one of these SD to IDE and tried to install XP on a SD and it took 2 days to install and once it did it was taking for ever to initiate windows so I gave up. My machine is a k8mm-v mobo.
:( any ideas? I really wanted to use it and see if it could be better. Now I'm trying with a Sata to IDE, seems to work better, still trying to install Windows XP.
Ive been having nothing but problems using SD/CF to IDE 44 pin adapters on my old Commodore C286-LT. I wonder if its a BIOS issue as well. It writes fine to the cards but refuse to boot or otherwise read files. Another thing to explore 😅
@@adriansdigitalbasement I have to watch those then because I am sure it is the same problem i have. I can make and read very small txt files. I programmed a new EPROM with the newest released Commodore BIOS and that will not work either. The weird thing is that some people here on youtube got it to work with that BIOS but I suppose my CF to IDE adapter is different. Thanks for your reply. It is much appreciated. 🙂
You "BURN" EPROMs not "FLASH". bit location is EPROMS are like little fuses and what happens when you program them is you BURN or don't BURN the fuses. The UV light used to Erase them wipes or clears a layer leaving new fuses to burn/not burn. Not quite the same in Flash chips or EEPROMS