Nice video, I love the deep dives into obscure ISA video cards, especially when you go to the level of writing your own code, very cool! Hope you get your old MFM drive to work, cheers!
I know spinrite was really good at finding, marking, and bypassing damaged sectors. I had a quantum fireball that it was able to save with either it was a bad sector 0 , or damaged where the MBR resides. But that was an IDE drive, not MFM. IIRC the program is hand written in assembly, so it super efficient and will run in only conventional memory. But not sure how minimum it's reqs are. Might be worth looking it up.
Good to see some of our comments making it to your video. Thanks for sharing your experiences! By the way, are you using an RLL controller on an MFM drive? ST-225 is tested to store bits in MFM format and can hold 21MB of data. The formatted capacity indicated by Speedstor states 32MB, which would indicate that you're cramming way more sectors on the drive than it's capable of holding. You need to get the ST-225R which is rated for RLL controllers, or switch your RLL hard drive controller for an MFM controller. An RLL controller will be unreliable at best on an MFM drive. Keep up the good work!
I used a ST-225 w/ RLL for 5 years. The RLL version of the ST-225 is the ST-238. Same geometry, more sectors per track. I also used it on a CMI-6424. The guy who sold me the RLL controller, also said, it was a 640 Cyl drive, not a 614. Got an extra 5/7Mb out of it for a scratch disk. The drives ( MFM 2 RLL ) worked daily with Xenix for more than 4 years, until Xenix died, and I backed everything up and used it as all DOS/Windows 1. MFM was 17 Sectors per track and RLL was 31. They relabel the ST-225Rs IF they format clean with an RLL Controller. I did that, for 4 days. They also label them ST-238 and ST-238R. Unreliable at best is a rumor. I had 30~35 drives - no problem. Finally switched to ESDI, which was another host of problems.
@@joeturner7959 Hi, thanks for your input! I have never had success with RLL on a non-RLL drive. I've had it work for a while, but after a few weeks of use had read errors on several MFM drives. So now I pair RLL controllers only with RLL rated drives.
I suspect the circuit board on the bottom of the drive has a cracked trace or failed solder joint causing your issues. I've seen this happen before. An easy way to test is to pull the drive and press on the board while it's running to see if things act differently. I've also had the data cables go bad on me before as well which made it looked like a given drive was completely bad.
Definitely worth checking. The drive used to stop working, and only after I moved it about did it start. This could be consistent with what you are suggesting.
I guess the ST225 is when they switched from stepper motors to voice coils? IDK I can't find a consistent answer quickly on Google. I know steppers can seize up and I've seen Adrian Black rescue some of those with a little lubrication and working them out but the voice coil ones might be different. I wonder if the head got knocked out of alignment? Stiction caused it to scratch the surface? IDK... Might be time to run your air filters on max and pop the lid out of curiosity.
I'd run Spinrite, by GRC. Really cool MFM drive utility, you can even change the interleave value without low level formatting and partitioning and so on.
@@PCRetroTech Spinrite seems to lowlevel access most MFM-controllers and is trying to "repair" sectors by flipping bits with different patterns. Sometimes, this helps!
If you use a special program called xfdisk, it will allow you great control over your partition tables. Also spinrite, gibson research, can test interleave your drive, Mine went from 6:1 to 3:1 for my 10 Mhz Machine. There was an old school fix for drives with bad partition tables, Open it up and bend the heads. I did this on a 80Mb drive, and it lasted years. The ST-225 is a workhorse. I ran mine with a RLL controller for years, but ALWAYS PARKED THE HEADS. ALWAYS.
@@PCRetroTech The position of track 0 is defined purely by a mechanical limiter, like a screw or something. The stepper motor uses it as a reference for track 0 and returns there on any read error (and you hear a click). Ajusting the limiter won't be any hard, you'll find out when you open the hdd. LLF required after that, of course. A few tracks at the end of disk may be lost (or not).
Your Harddrive is a MFM one, but in speedstor it shows 26 sectors instead of the regular 17 sectors for the ST225. It seems you have an RLL controller instead of an MFM one. Formating MFM drives with RLL gives more space (26 vs 17 sectors) but is unreliable on MFM-only drives like the ST225. (in your example arround 30MB instead of regular 20MB). The ST225 is known for absolutely didn't like to be formatted as rll. Try it with a real mfm contoller, i think it will work fine. :)
Oh, well spotted. That could totally be the issue. Thanks. I actually remember wondering about that at some point, but then didn't bother to check it out.
I noticed this too, seems someone else beat me to it - the controller is obviously RLL, but the drive is MFM; this CAN work but it will be "kind of unreliable, sometimes" when it works. Sounds exactly like your issue. Because your drive is a nice MFM one, it's working well enough that the low-level format took, but there are too many sectors per track for the data to be consistently read accurately. You probably don't need to use an MFM controller, maybe just format it again using 17 sectors per track.
@@shawnmulligan3471 I wondered if that might be possible, but according to the docs for Speedstor it isn't necessarily able to change the settings for the drive. But I'll fiddle with it and see what happens. Obviously there will be a follow up video.
@@PCRetroTech If your controller card supports dynamic / virtual drives, you can set up any geometry you want on the drive. Sometimes you need to set jumpers on the controller to enable this feature. Many Western Digital controllers allow it. Then you use the low level format tool built into the controller - usually, run debug.com, the g=c8000:5 to start the utility. (Might be c800, not c8000 - forget off-hand; use the base io address for you controller card). After low level format, partition using fdisk, and format using DOS format command as usual.
@@shawnmulligan3471 I'll try the format tool built into the controller, though that is what I did originally. I'm not sure why I would have used anything other than the settings for that specific drive though. By the way, I think it is C800:5, though there can be some variations depending on controller.
21:44: I wonder if formatting with the /U parameter might help. That should skip attempts to save (and maybe then read back and verify?) the unformat information. MS-DOS 5+ defaulted to saving unformat info, and I personally don't recall the new unformat command having ever helped me -- I do recall the saving of unformat info causing problems quite a few times. More trouble than it was worth IMHO.
I was going to recommend that as well. The error occurred when it was trying to save the unformat data, not when it was actually formatting the drive. Adding /U will force it to unconditionally format the drive without trying to save the unformat data first.
@@vwestlife Truth be told, every time I forgot to put /U, those unformat info shenanigans felt like I was being punished for someone else's mistake. Undelete was legitimately useful, but I kind of hated unformat back in the day.
16:00: The interleave thing reminded me of The Story of Mel (which is googleable, for the uninitiated). [A very broadly similar optimisation is mentioned in the story, but it concerns drum memory, not hard drives.]
I recall having issues with the mfm drives and some old IDEs as well, were the first or second tracks were faulty and you couldn't boot from them. Of course you could use them to store things, but no boot. I think it should be possible to have the partitions wherever you fancy, but I'm not sure if fdisk is actually able to do so. Maybe using a third party app would make sense
Yes I recall PCs - even into the Pentium era - that wouldn't boot or even recognize HDDs when some of the partition table data (or other track 0 data) was corrupt and no low level tool would work anymore. Attaching it to an Amigo or MSX with IDE or SCSI interface let me access and fix it easily ...
The boot sector is all that matters, although with some boot loaders, that’s boot sectorS. The first partition can start anywhere you’d like. DOS’s fdisk is indeed too dumb for this work though. Anyone ever hear tale why one and only one primary partition, and the rest have to be logical? DOS is capable of reading drives with more sensible layouts, it just can’t create them.
I have a theory on the speed improvement. The Persyst seems to contain some sort of ASIC or PLD, doesn't it? So as the amazing Grace Hopper once told everyone who would listen, size matters, which is why she used to hand out her foot-long "nanoseconds" (see Wikipedia). Basically, Grace said that to be fast, you needed to go small. The reverse of that is that if you integrated a whole bunch of discrete components into a single chip which you maybe managed to manufacture more cheaply due to technology marching on, well, you'd have gotten a nice natural speed improvement for free. Or at least that's my theory. Feel free to pick holes in it.
@@PCRetroTech Hm, good point -- or should I say hole, picked ~. :) But I will ask: When (video) memory access speeds are being measured, what's really being measured, and would that process still be affected by vendors going from discrete components to ICs? The way I understand it, with main RAM, an address is put out on address lines, and then the RAM chips put those contents on the bus in response. But now I'm talking regular RAM, not VRAM, and I'm not quite sure if there's essentially the same thing again happening on a smaller scale on the actual graphics card, or if there's maybe not even a real difference between RAM and VRAM in that respect, since VRAM is also represented in the system's address space. This is once again pushing the limits of my knowledge, but I just thought maybe it's not a waste of time to ask the above. (Side Q: I guess DMA just allows something other than the CPU to put the address on the bus and read the contents, etc.?)
@@ropersonline They used off the shelf components for the RAM, and clearly here they used very fast (and presumably expensive) RAM chips. I don't know anything about the ASIC, so I can't make any further guesses.
Doesn’t a normal CGA card work with no extra wait states? The snow is caused by giving the CPU priority to access the RAM. So I’m puzzled how on earth the new card can have faster memory on the standard ISA bus. If a normal CGA has wait states, then of course a speed-up would be to design a card with no wait states. Snow can be eliminated by using wait states to hold up the CPU while the video controller accesses memory. No snow implies wait states. Might be interesting to bench test the speed of different CGA cards, unless you have already done this in another video.
@@migry : You can have faster memory than the ISA bus by sticking some buffers between your card and the ISA bus. Throw in a bit of extra circuitry on your controller chip to control the buffers, and you can have an arbitrarily faster memory speed.
I think the problem is at the head 0 cyl 0; there (afaik) is stored the partition table information and mbr. Maybe try (as other said) another MFM controller card or tweak it to show the real capacity of the drive. Also you can use Ontrack Disk manager (winworldpc) to initialize the HDD (there is a specific version for old MFM Seagate drives) or Norton disk doctor to try to recover the bad sectors.
@@PCRetroTech Also for calculating the optimum interleave for your HDD-system combo can use The Troubleshooter; you can find it on Hiren`s Boot CD ver 6 to 8. It can help to see if the interleave is varying with the temperature. (Simply extract the archive from the CD and decompress it on a floppy). This program is the best tool to identify what is on your system and also provide tests for everything.
nice video. The v20 incompatibility issue reminds me of the problem i had with using an XT-IDE CF card with Amstrad PC 1640. Apparently, the XT-IDE has two different Roms for both 8088/8086 vs v20 and v30. When i swapped in a v30 to the 1640 the xtide card stopped working (could never get it to work, even flashing the correct version of the rom for the v30) Had to go back to the 8086. "Select the appropriate ROM image: IDE_XT.BIN for Intel 8088 and 8086 CPUs IDE_XTP.BIN for NEC V20, V30, and Intel 80286 CPUs"
It's amazing that there are programs out there that hit these incompatibilities. I believe the shifting and division instructions may be implemented a little differently, but we'll look into this in a later episode.
Track 0 head 0 is essentially the only part of the drive you don't want to be bad because that's where the MBR lives, and it looks like you have extraordinary bad luck here based on the speedstor defect list.
@@PCRetroTech you could try clearing the bad track list in speedstor and then repeatedly low level formatting that track to see what happens. A different interleave might also help, albeit with a speed penalty.
@@JimLeonard Worth a try, but I've noticed cylinder 0, head 0 often goes before other parts of the drive, probably because it is used very often. Drives that I've pulled apart over the years show why. There's usually a scrape there.
I have three ST-225s. One of which worked just perfectly fine the second to last time I had it running (and yes I parked the heads - at least I'm pretty sure). Last time I turned it on, it wouldn't work, testing it showed two heads are completely dead. Haven't looked into it yet. Another of these ST-225s is factory new, but whoever bought it in 1988 unpacked it, hooked it up, turned it on and put it back into storage without parking the heads and now the first 2 or 3 megabytes are full of bad sectors...
That's a real shame. It seems like you've had some really bad luck with those. Unfortunately if the heads got stuck to the platter, then it is all over for the drive. Another thing that can happen is the very fine wires connected to the heads can snap off. I hope it isn't that, but it sounds like something equally catastrophic has happened if two of the heads are completely dead. Of course it is also worth checking for dry solder joints and to see if there are any blown components, if you have some electronics knowledge. Shame about the factory new one. That sounds pretty bad.
@@PCRetroTech Heads snapping off - I would have heard that, especially as they would hit the remains of the actuator arms 2700 times per second... the drive sounds perfectly normal. My guess is bad op-amp or as you said dry joint. Haven't looked at it, it's in the far corner of my tiny museum room where I would need to remove a ton of other stuff just to get to the machine. (there's a pretty recent video of that room on my channel - the more interesting stuff though is my homebrew games) I had heads snapping off happening on an ST157A though... I noticed the motor didn't turn (that was AFTER I replaced a few shorted tantalums). Trying to turn it manually yielded resistance. So I opened it up and tried my best to unstick the head. Unfortunately, the glue connecting the head to the actuator arm had also gone bad and the head pretty easily snapped off. And on top of that, another head two platters down (unreachable) had also welded to the platter and snapped off. Even worse, the owner wanted the files off that drive... but the machine had two identical drives, the other one was about a year older and worked fine and it contained all the files he was talking about.
@@senilyDeluxe Yes, I think you would have heard heads if they snapped off when you had the drive. It seems like your museum is a little like my apartment, so full of stuff that it is difficult to move about. We need to come up with better ways of storing this stuff! I will check out your channel.
The video card seems to be quite a find should be useful, great graphics. The poor hard drive. I have had hard drives with minor faults and tried to fix them with various software. They nearly always ended up with the same downward spiral of increasing faults. If you can find a way to bypass the problem it should be quite interesting.
I think that it won't be a reliable drive, that's for sure. I think I can get it working with the comments here, but whether it stays working remains to be seen. This is usually a very reliable model of drive.
It's probably late enough that it is, but I actually don't know for sure. My guess is home 386 owners would have been after something much later than this. I think even my 286 back in the day had a SuperVGA card.
Yes, I will do that. I decided not to do it right now as I've done that fairly recently, and I didn't want to throw confounding variables in at this stage.
Maybe I missed this but are you using an RLL controller? As speedstor was indicating 32MB? If so, can you try formatting it using MFM (20MB) as that is normally what the ST225 is formatted for? Just a guess.
Did you manage to find out what exactly the incompatibility was between the 8088 and the V20? I know the V20 does not support certain undocumented instructions. Perhaps you used any of those (AAM/AAD, SALC etc?)
I haven't narrowed it down yet, but you can bet it will be the subject of a future video. I'm not actually sure yet whether I just used an undocumented opcode which the V20 is known to not support. I will check and let everyone know in a future video.
I had a 130MB Maxtor drive that would fully lock the 486 system if a certain part got accessed.. This happened after I installed Stacker, no idea how that can damage a drive, but anyway.. I found the error was towards to end of the drive. So I was able to create a shorter partition, and just ignored the last 10 or 15% of space... It worked fine after that.
@@PCRetroTech I think I had to reduce cylinder count in bios.. because even low level formatting locked the machine up when it touched that special spot.
I think it is just because there is no picture. Even when I was much younger, CRT whine was not a big deal. It is what we used for TV and computers back in the day and I don't recall there being any issues with the sound. Of course it could also be that the monitor is making an unusual noise because it is old, but this one is in very good condition, so I doubt it.
@@migry A lot of PC sound systems don't reproduce 15kHz faithfully, so who knows what is actually happening. The microphone wasn't pointed at the screen and it is pretty omnidirectional, so it is slightly surprising something is audible.
On a mic, in a video, through lossy compression that throws away ultrasonics, and through someone else’s media player. Most of us here lived with that whine six inches away from our face every day. You’ll live for 20 min.
Put oil in the stepper motors, both of them, directly in the motor in the "peg" at the center etc Those tend to start to "lock up" or misfiring due to getting stuck so oiling them will fix them. WD40 is not recommended. It will work bit a bit then kill the motors so yeah. Even cooking oil will do, but not wd40, that's murder
![เจ็บที่ยังฮัก - ม่อน วรวิทย์ [ Official Mv ] จอนนี่มิวสิค](http://i.ytimg.com/vi/KALIGSRSjFs/mqdefault.jpg)
Nice video, I love the deep dives into obscure ISA video cards, especially when you go to the level of writing your own code, very cool! Hope you get your old MFM drive to work, cheers!
Glad you enjoyed it!
I know spinrite was really good at finding, marking, and bypassing damaged sectors. I had a quantum fireball that it was able to save with either it was a bad sector 0 , or damaged where the MBR resides. But that was an IDE drive, not MFM. IIRC the program is hand written in assembly, so it super efficient and will run in only conventional memory. But not sure how minimum it's reqs are. Might be worth looking it up.
Good to see some of our comments making it to your video. Thanks for sharing your experiences! By the way, are you using an RLL controller on an MFM drive? ST-225 is tested to store bits in MFM format and can hold 21MB of data. The formatted capacity indicated by Speedstor states 32MB, which would indicate that you're cramming way more sectors on the drive than it's capable of holding. You need to get the ST-225R which is rated for RLL controllers, or switch your RLL hard drive controller for an MFM controller. An RLL controller will be unreliable at best on an MFM drive. Keep up the good work!
Someone else noticed this, and it could indeed be the issue. Thanks.
I used a ST-225 w/ RLL for 5 years. The RLL version of the ST-225 is the ST-238. Same geometry, more sectors per track.
I also used it on a CMI-6424. The guy who sold me the RLL controller, also said, it was a 640 Cyl drive, not a 614. Got an extra 5/7Mb out of it for a scratch disk.
The drives ( MFM 2 RLL ) worked daily with Xenix for more than 4 years, until Xenix died, and I backed everything up and used it as all DOS/Windows 1. MFM was 17 Sectors per track and RLL was 31. They relabel the ST-225Rs IF they format clean with an RLL Controller. I did that, for 4 days. They also label them ST-238 and ST-238R.
Unreliable at best is a rumor. I had 30~35 drives - no problem. Finally switched to ESDI, which was another host of problems.
@@joeturner7959 Hi, thanks for your input! I have never had success with RLL on a non-RLL drive. I've had it work for a while, but after a few weeks of use had read errors on several MFM drives. So now I pair RLL controllers only with RLL rated drives.
Thank you for your videos, always a pleasure, a very good explanation everytime.
Best regards from Germany.
Thanks!
I suspect the circuit board on the bottom of the drive has a cracked trace or failed solder joint causing your issues. I've seen this happen before. An easy way to test is to pull the drive and press on the board while it's running to see if things act differently. I've also had the data cables go bad on me before as well which made it looked like a given drive was completely bad.
Definitely worth checking. The drive used to stop working, and only after I moved it about did it start. This could be consistent with what you are suggesting.
7:13: I think the original EGA had at least 64KB VRAM, not just 32K (as a minimum).
Yes, apparently I let an error slip through here, thanks for pointing it out.
I wouldn't ordinarily associate the exceptional reliability of a hard disk as being something of notoriety.
I guess the ST225 is when they switched from stepper motors to voice coils? IDK I can't find a consistent answer quickly on Google. I know steppers can seize up and I've seen Adrian Black rescue some of those with a little lubrication and working them out but the voice coil ones might be different. I wonder if the head got knocked out of alignment? Stiction caused it to scratch the surface? IDK... Might be time to run your air filters on max and pop the lid out of curiosity.
For the time being I swapped the drive out. I'm reluctant to open them for now.
I'd run Spinrite, by GRC. Really cool MFM drive utility, you can even change the interleave value without low level formatting and partitioning and so on.
You can do that with SpeedStor too and it was free.
@@PCRetroTech Spinrite seems to lowlevel access most MFM-controllers and is trying to "repair" sectors by flipping bits with different patterns. Sometimes, this helps!
It also was able to work with my RLL controller on a MFM drive. I never had an issue with the hardware.
I’ve got one that needs a new home.
If you use a special program called xfdisk, it will allow you great control over your partition tables. Also spinrite, gibson research, can test interleave your drive, Mine went from 6:1 to 3:1 for my 10 Mhz Machine.
There was an old school fix for drives with bad partition tables, Open it up and bend the heads. I did this on a 80Mb drive, and it lasted years.
The ST-225 is a workhorse. I ran mine with a RLL controller for years, but ALWAYS PARKED THE HEADS. ALWAYS.
I've never heard of that head bending method. I'm honestly amazed that this works.
@@PCRetroTech
Its not from my era, its from the 1950s Burroughs drives, but it worked on a dead ST-4096.
@@PCRetroTech The position of track 0 is defined purely by a mechanical limiter, like a screw or something. The stepper motor uses it as a reference for track 0 and returns there on any read error (and you hear a click). Ajusting the limiter won't be any hard, you'll find out when you open the hdd. LLF required after that, of course. A few tracks at the end of disk may be lost (or not).
@@1236-t7i Interesting. It sounds like a lot of track 0 issues could be worked around this way.
Your Harddrive is a MFM one, but in speedstor it shows 26 sectors instead of the regular 17 sectors for the ST225. It seems you have an RLL controller instead of an MFM one. Formating MFM drives with RLL gives more space (26 vs 17 sectors) but is unreliable on MFM-only drives like the ST225. (in your example arround 30MB instead of regular 20MB). The ST225 is known for absolutely didn't like to be formatted as rll. Try it with a real mfm contoller, i think it will work fine. :)
Oh, well spotted. That could totally be the issue. Thanks. I actually remember wondering about that at some point, but then didn't bother to check it out.
I noticed this too, seems someone else beat me to it - the controller is obviously RLL, but the drive is MFM; this CAN work but it will be "kind of unreliable, sometimes" when it works. Sounds exactly like your issue. Because your drive is a nice MFM one, it's working well enough that the low-level format took, but there are too many sectors per track for the data to be consistently read accurately. You probably don't need to use an MFM controller, maybe just format it again using 17 sectors per track.
@@shawnmulligan3471 I wondered if that might be possible, but according to the docs for Speedstor it isn't necessarily able to change the settings for the drive. But I'll fiddle with it and see what happens. Obviously there will be a follow up video.
@@PCRetroTech If your controller card supports dynamic / virtual drives, you can set up any geometry you want on the drive. Sometimes you need to set jumpers on the controller to enable this feature. Many Western Digital controllers allow it. Then you use the low level format tool built into the controller - usually, run debug.com, the g=c8000:5 to start the utility. (Might be c800, not c8000 - forget off-hand; use the base io address for you controller card). After low level format, partition using fdisk, and format using DOS format command as usual.
@@shawnmulligan3471 I'll try the format tool built into the controller, though that is what I did originally. I'm not sure why I would have used anything other than the settings for that specific drive though. By the way, I think it is C800:5, though there can be some variations depending on controller.
21:44: I wonder if formatting with the /U parameter might help. That should skip attempts to save (and maybe then read back and verify?) the unformat information. MS-DOS 5+ defaulted to saving unformat info, and I personally don't recall the new unformat command having ever helped me -- I do recall the saving of unformat info causing problems quite a few times. More trouble than it was worth IMHO.
I was going to recommend that as well. The error occurred when it was trying to save the unformat data, not when it was actually formatting the drive. Adding /U will force it to unconditionally format the drive without trying to save the unformat data first.
@@vwestlife Thanks, that is probably correct. I've made further progress which I'll show in the next video.
@@vwestlife Truth be told, every time I forgot to put /U, those unformat info shenanigans felt like I was being punished for someone else's mistake. Undelete was legitimately useful, but I kind of hated unformat back in the day.
12:07 very nice rainbow effect! What is this magic VGA card hehe? 😊
the ram is dual ported, that's why it doesn't have cga snow and is twice as fast
16:00: The interleave thing reminded me of The Story of Mel (which is googleable, for the uninitiated).
[A very broadly similar optimisation is mentioned in the story, but it concerns drum memory, not hard drives.]
Drum memory is just a hard disk, with 1 head per track. Very very fast. No seek times, only rotational latency.
I recall having issues with the mfm drives and some old IDEs as well, were the first or second tracks were faulty and you couldn't boot from them. Of course you could use them to store things, but no boot. I think it should be possible to have the partitions wherever you fancy, but I'm not sure if fdisk is actually able to do so. Maybe using a third party app would make sense
Yes I recall PCs - even into the Pentium era - that wouldn't boot or even recognize HDDs when some of the partition table data (or other track 0 data) was corrupt and no low level tool would work anymore. Attaching it to an Amigo or MSX with IDE or SCSI interface let me access and fix it easily ...
I've seen these issues before. It's an interesting idea that it might be fixable on a different machine.
The boot sector is all that matters, although with some boot loaders, that’s boot sectorS. The first partition can start anywhere you’d like. DOS’s fdisk is indeed too dumb for this work though.
Anyone ever hear tale why one and only one primary partition, and the rest have to be logical? DOS is capable of reading drives with more sensible layouts, it just can’t create them.
I have a theory on the speed improvement. The Persyst seems to contain some sort of ASIC or PLD, doesn't it? So as the amazing Grace Hopper once told everyone who would listen, size matters, which is why she used to hand out her foot-long "nanoseconds" (see Wikipedia). Basically, Grace said that to be fast, you needed to go small. The reverse of that is that if you integrated a whole bunch of discrete components into a single chip which you maybe managed to manufacture more cheaply due to technology marching on, well, you'd have gotten a nice natural speed improvement for free. Or at least that's my theory. Feel free to pick holes in it.
Sure, but it is the memory which is fast.
@@PCRetroTech Hm, good point -- or should I say hole, picked ~. :)
But I will ask: When (video) memory access speeds are being measured, what's really being measured, and would that process still be affected by vendors going from discrete components to ICs?
The way I understand it, with main RAM, an address is put out on address lines, and then the RAM chips put those contents on the bus in response. But now I'm talking regular RAM, not VRAM, and I'm not quite sure if there's essentially the same thing again happening on a smaller scale on the actual graphics card, or if there's maybe not even a real difference between RAM and VRAM in that respect, since VRAM is also represented in the system's address space. This is once again pushing the limits of my knowledge, but I just thought maybe it's not a waste of time to ask the above.
(Side Q: I guess DMA just allows something other than the CPU to put the address on the bus and read the contents, etc.?)
@@ropersonline They used off the shelf components for the RAM, and clearly here they used very fast (and presumably expensive) RAM chips. I don't know anything about the ASIC, so I can't make any further guesses.
Doesn’t a normal CGA card work with no extra wait states? The snow is caused by giving the CPU priority to access the RAM. So I’m puzzled how on earth the new card can have faster memory on the standard ISA bus. If a normal CGA has wait states, then of course a speed-up would be to design a card with no wait states. Snow can be eliminated by using wait states to hold up the CPU while the video controller accesses memory. No snow implies wait states. Might be interesting to bench test the speed of different CGA cards, unless you have already done this in another video.
@@migry : You can have faster memory than the ISA bus by sticking some buffers between your card and the ISA bus. Throw in a bit of extra circuitry on your controller chip to control the buffers, and you can have an arbitrarily faster memory speed.
I think the problem is at the head 0 cyl 0; there (afaik) is stored the partition table information and mbr. Maybe try (as other said) another MFM controller card or tweak it to show the real capacity of the drive. Also you can use Ontrack Disk manager (winworldpc) to initialize the HDD (there is a specific version for old MFM Seagate drives) or Norton disk doctor to try to recover the bad sectors.
All worthwhile suggestions, thanks!
@@PCRetroTech Also for calculating the optimum interleave for your HDD-system combo can use The Troubleshooter; you can find it on Hiren`s Boot CD ver 6 to 8. It can help to see if the interleave is varying with the temperature. (Simply extract the archive from the CD and decompress it on a floppy). This program is the best tool to identify what is on your system and also provide tests for everything.
@@sebastian19745 Thanks, I'll look into that.
nice video.
The v20 incompatibility issue reminds me of the problem i had with using an XT-IDE CF card with Amstrad PC 1640.
Apparently, the XT-IDE has two different Roms for both 8088/8086 vs v20 and v30.
When i swapped in a v30 to the 1640 the xtide card stopped working (could never get it to work, even flashing the correct version of the rom for the v30) Had to go back to the 8086.
"Select the appropriate ROM image:
IDE_XT.BIN for Intel 8088 and 8086 CPUs
IDE_XTP.BIN for NEC V20, V30, and Intel 80286 CPUs"
It's amazing that there are programs out there that hit these incompatibilities. I believe the shifting and division instructions may be implemented a little differently, but we'll look into this in a later episode.
@@jkeelsnc Sure. I plan to take a look at those, and the AAM instruction, which I believe also behaves differently.
Track 0 head 0 is essentially the only part of the drive you don't want to be bad because that's where the MBR lives, and it looks like you have extraordinary bad luck here based on the speedstor defect list.
Yes indeed.
@@PCRetroTech you could try clearing the bad track list in speedstor and then repeatedly low level formatting that track to see what happens. A different interleave might also help, albeit with a speed penalty.
@@JimLeonard Worth a try, but I've noticed cylinder 0, head 0 often goes before other parts of the drive, probably because it is used very often. Drives that I've pulled apart over the years show why. There's usually a scrape there.
I have three ST-225s. One of which worked just perfectly fine the second to last time I had it running (and yes I parked the heads - at least I'm pretty sure). Last time I turned it on, it wouldn't work, testing it showed two heads are completely dead. Haven't looked into it yet.
Another of these ST-225s is factory new, but whoever bought it in 1988 unpacked it, hooked it up, turned it on and put it back into storage without parking the heads and now the first 2 or 3 megabytes are full of bad sectors...
That's a real shame. It seems like you've had some really bad luck with those. Unfortunately if the heads got stuck to the platter, then it is all over for the drive. Another thing that can happen is the very fine wires connected to the heads can snap off. I hope it isn't that, but it sounds like something equally catastrophic has happened if two of the heads are completely dead. Of course it is also worth checking for dry solder joints and to see if there are any blown components, if you have some electronics knowledge.
Shame about the factory new one. That sounds pretty bad.
@@PCRetroTech Heads snapping off - I would have heard that, especially as they would hit the remains of the actuator arms 2700 times per second... the drive sounds perfectly normal. My guess is bad op-amp or as you said dry joint. Haven't looked at it, it's in the far corner of my tiny museum room where I would need to remove a ton of other stuff just to get to the machine. (there's a pretty recent video of that room on my channel - the more interesting stuff though is my homebrew games)
I had heads snapping off happening on an ST157A though... I noticed the motor didn't turn (that was AFTER I replaced a few shorted tantalums). Trying to turn it manually yielded resistance. So I opened it up and tried my best to unstick the head. Unfortunately, the glue connecting the head to the actuator arm had also gone bad and the head pretty easily snapped off. And on top of that, another head two platters down (unreachable) had also welded to the platter and snapped off. Even worse, the owner wanted the files off that drive... but the machine had two identical drives, the other one was about a year older and worked fine and it contained all the files he was talking about.
@@senilyDeluxe Yes, I think you would have heard heads if they snapped off when you had the drive.
It seems like your museum is a little like my apartment, so full of stuff that it is difficult to move about. We need to come up with better ways of storing this stuff! I will check out your channel.
The video card seems to be quite a find should be useful, great graphics. The poor hard drive. I have had hard drives with minor faults and tried to fix them with various software. They nearly always ended up with the same downward spiral of increasing faults. If you can find a way to bypass the problem it should be quite interesting.
I think that it won't be a reliable drive, that's for sure. I think I can get it working with the comments here, but whether it stays working remains to be seen. This is usually a very reliable model of drive.
@@PCRetroTech Whatever happens, of will be interesting 😊
awesome video! definitely an interesting card!
Yes, I think it will prove to be very interesting if we can find out more about it.
is it compatible with i386 pc (intel 386dx and other)?
It's probably late enough that it is, but I actually don't know for sure. My guess is home 386 owners would have been after something much later than this. I think even my 286 back in the day had a SuperVGA card.
That noise in the hdd seems to come from the heads stepper motor, try to lubricate it, you can acces it from the bottom.
Yes, I will do that. I decided not to do it right now as I've done that fairly recently, and I didn't want to throw confounding variables in at this stage.
Maybe I missed this but are you using an RLL controller? As speedstor was indicating 32MB? If so, can you try formatting it using MFM (20MB) as that is normally what the ST225 is formatted for? Just a guess.
Yes, I think that could be one of the issues here. There are others, but I will try this in a followup video.
Did you manage to find out what exactly the incompatibility was between the 8088 and the V20? I know the V20 does not support certain undocumented instructions. Perhaps you used any of those (AAM/AAD, SALC etc?)
Not yet, but I may have used SALC. By the way, congrats on the production!
@PCRetroTech If this card is so compatible, what is if you through Area5150 on it :)
It's worth a try actually. Some of the glitches of the original IBM card actually show up on this card. I might try it later today.
so the same nec incompatibility is the reason for the games that had problems? did you narrow it what it is, memory copy ?
I haven't narrowed it down yet, but you can bet it will be the subject of a future video. I'm not actually sure yet whether I just used an undocumented opcode which the V20 is known to not support. I will check and let everyone know in a future video.
So the card seems to have traveled from Germany to Australia? 😉
Not yet. I'm still in Germany, but quite by coincidence, I am planning a trip back to Australia this year.
I had a 130MB Maxtor drive that would fully lock the 486 system if a certain part got accessed.. This happened after I installed Stacker, no idea how that can damage a drive, but anyway..
I found the error was towards to end of the drive. So I was able to create a shorter partition, and just ignored the last 10 or 15% of space... It worked fine after that.
That's a weird problem indeed. I don't have any idea what would cause that. Nice that you managed to partition it out though.
@@PCRetroTech I think I had to reduce cylinder count in bios.. because even low level formatting locked the machine up when it touched that special spot.
@@1st_ProCactus Wow.
Nice, but can it run GTA V at 60 fps? hehe
Jokes aside, a very interesting video.
the voice i thought was hugh jeffreys voice
1:40 - uhh, the crt whine noise!
Please filter it out next time, my ears would be really really thankful. :)
I think it is just because there is no picture. Even when I was much younger, CRT whine was not a big deal. It is what we used for TV and computers back in the day and I don't recall there being any issues with the sound.
Of course it could also be that the monitor is making an unusual noise because it is old, but this one is in very good condition, so I doubt it.
I’m amazed that it is even audible. I wonder what bandwidth the audio has? Isn’t CRT whine at horizontal sync rate = 15kHz?
@@migry A lot of PC sound systems don't reproduce 15kHz faithfully, so who knows what is actually happening. The microphone wasn't pointed at the screen and it is pretty omnidirectional, so it is slightly surprising something is audible.
On a mic, in a video, through lossy compression that throws away ultrasonics, and through someone else’s media player.
Most of us here lived with that whine six inches away from our face every day. You’ll live for 20 min.
Put oil in the stepper motors, both of them, directly in the motor in the "peg" at the center etc Those tend to start to "lock up" or misfiring due to getting stuck so oiling them will fix them. WD40 is not recommended. It will work bit a bit then kill the motors so yeah. Even cooking oil will do, but not wd40, that's murder
Thanks. Fortunately I do not have any WD40, so no damage done.