As someone who designed hard drive controllers when this tech was new, you are right - FM, MFM and RLL are all RLL. However, the quality of the oxide needs to be a whole lot better for "RLL" to work well. Formatting needs to write new address marks (which begin sector marks and data). Sector marks are a bunch of data which tells you which sector will come next (ie contains the track number and sector number). However - the address marks and sector data may be interleaved - sector label 1 is followed by data for the last sector, then sector label two, then sector data one! This is because the formatter processor may not be fast enough to figure out which label it just read in the inter-sector gap! I warn you - address marks are a possible problem: Mostly people used the IBM address mark. Unfortunately the IBM documents were wrong! The data bits were defined in chronological order, but the clock bits in reverse chronological order. I designed a controller with the clock bits in the correct order (as an option). Using the bits in the correct order means that the address mark contains a single flux transition in between two gaps exceeding the max legal distance in legit data. This means it is a unique pattern on the drive surface. The industry standard version is illegal as data, but is not necessarily unique. Using my address mark, most drives had enormously fewer bad sectors and read errors - but were not compatible with formatters made by IBM, Western Digital etc. I used programmable logic (which was new at the time) to map data into RLL code . In addition to formatters for mainframes, I also did the first hard drive interface for the Apple ][, and one for the BBC micro. Both used the 6502 CPU - like Woz did for the floppy controller!
Wow! Fantastic to hear! For what it's worth, I've tested every single drive in my collection (over 500+ drives at this point) as RLL and I've had very few drives fail RLL that didn't already have issues during nominal MFM operation.
I always though RLL was a kind of extension to MFM. a 20MB MFM drive would be 30MB with RLL, IIRC. What I can't recall are the specific debug commands used for the low level formatting.
Sure, hundreds of us neckbeards were shouting SYS C: at the telly (or even FORMAT /S), but, and this is important, hundreds more didn't have the first clue so it's excellent that you're showing this to the inexperienced :D
That's part of why I love watching people work on very different old tech. Man's got an incredible handle on the minicomputers like the Centurion, but DOS isn't really in his wheelhouse, where I can breeze through DOS but I'm *absolutely* lost on the big(gish) iron.
I was taught this stuff back in school; but, having not touched it in over 20 years, the actual command was foggy. More reason to check back at this stuff periodically, I guess.
Before MS-DOS 4, the sys command required the disk to be freshly-formatted. Starting with MS-DOS 4, the sys command was able to handle files already being on the disk.
I think the root cause is in a boot sector loader. In 3.3 it was just loading system from reserved sectors. Later it started to look for system in directory entries
@@big0bad0brad They are reserved once used. So it's more them being fixed ones, and if they already are in use for other things, sys cannot free (and reserve) them.
@@alexloktionoff6833 The DR-DOS bootloader could read the system files from the directory entries, which was very convenient. However, MS-DOS was never able to do this.
This was the "normal way" format (A/C/D): /s in former times. But, why low level, when the linuxdevice print all OK? It is the first formatting of a hard drive. This hard drive was lowlevel formatted. As a rule, this was only done when the HDU said goodbye. Or the controller had a different logic, such as Ompti, Adaptec, DTC. It was better with the spinrite tool. The good old DOS. 2.11😀😉 and Speedstore to use BigDisk > 32mb
The thing with the SYS command, the IO and MSDOS system files is hardcoded to be the very first two files on the drive. The reason for this is because the libraries for handling the filesystem is inside those, so the DOS boot code can't go searching through the filetable the same way you can after DOS is loaded.
It's really a laziness of the bootloader. The FreeDOS bootloader includes enough of a FAT12/16/32 filesystem driver within the 512 bytes to find and load its kernel.sys, stepping through the FAT entries to find the next sectors. I've also written one that not only includes enough filesystem driver but also floppy controller driver to load my BIOS on a system that does not have a BIOS in ROM, with the BIOS file at any physical disk position. Including a startup text and error message display, again without any help from the BIOS. MS was just lazy. There's plenty of room for that code.
This got fixed. I've been seeing DOS 4.0 quoted as the beginning of the ability to SYS any disk as long as it was big enough to move the existing files out of the way, but I skipped it. I know for certain that DOS 5 did it.
Totally understandable limitation, but it would have been nice if they used a more informative error message when there are already files on the drive.
FYI, an ST238R is simply an ST225 that passed a few more QC checks. Quite a few hobbyists with ST225s plugged in an RLL board and got the 32MB capacity with no issues.
You've low-level formatted the ST4097 with the drive parameters of the ST238R, so you'll only have 30MB usable. On these older controllers you have to select the drive parameters with jumpers. They depend on the Controller's BIOS ROM version though. There are lists online of which ROM version supports which drives. It's quite possible that your ROM won't support the correct parameters, so you'd either have to modify it and change the parameter table, or get the WD SuperBios which can be configured to any drive parameters. The ST4097 is a 80MB MFM drive, so with 2,7 RLL it should give you roughly 120MB!
Those older Western Digital controllers have jumpers to set the drive type. Since you originally had a ST-238R in there, it's treating the ST-4097 as a ST-238R which means it formatted it with 615 cylinders, 4 heads, and 27 sectors. The drive types are defined in the ROM on the controller itself and it probably doesn't support the ST-4097 at all. There is a utility called SpeedStor that has a command line switch to display the drive types supported by the controller. Later WD controllers offered a free format option where you could enter in the correct drive parameters for the drive. The drive interleave is how the sectors are laid down onto the drive during the low-level format. A 4 to 1 interleave will skip every four sectors. The reason for this, is the 8-bit controller is not fast enough to process an interleave ratio lower then 4 to 1. I you were to tell the controller to use an interleave ratio of 3 or lower, you would end up with extremely slow drive performance as the controller would fail to read the next sector in line and have to wait for it come back around to try again. This would result in a 27 to 1 interleave ratio meaning one sector read for each platter revolution. If you were to toss in a 16 bit RLL controller like a ST-21R, you would be able to run a 1 to 1 interleave and should see 7 mb/s drive through put. There is even more tweaks that can be done during a low-level format such as head an cylinder skewing. Which affects how the sectors are positioned on the adjacent platters so when the head switches or moves it doesn't have to wait for an entire platter revolution. Without skewing, a fast drive like the ST-4097 will be faster with a 2 to 1 interleave vs a 1 to 1 interleave. You may also want to check out the ESDI interface which extends on the ST-412 (MFM / RLL) interface. ESDI is not compatible with the older ST-412 interface drives.
ESDI drives differ by having the data separator and PLL electronics in the drive instead of on the backplane controller. ESDI is quite different from ST-506/412 in a number of ways. ESDI supports higher level commands to the drive than ST-506/412 too.
Good explanation of interleave. However in my experience many better controllers I worked with would work down to 2:1 on a XT. Tim Patterson (yes that one) made a “Falcon” controller that was able to use some kind of burst mode on the bus to be able to handle a 1:1 interleave. I’d have one in my old deskpro, but it was MFM only and I wanted RLL for the greater storage.
I had three ESDI drives donated to me with a lot of bad sectors. They were still larger than any other drives I happened to have at the time, both logically (150 and 300MB drives) and physically - these were the full height of 3.2 inches. My drives also took about a minute to come up to a stable speed. Yes, they were on their last legs, however they still made a Linux system viable for me.
@@brickviking667 I had a lot better luck with ESDI drives. I was a bit unnerving to see a label with a big bad sector map, but it was rare to ever experience gown defects. It seemed all or nothing - either the drive worked, or it was a brick.
I remember when I was a kid working with these drives. I had a 20mb MFM drive, a 40mb RLL drive, and later a full-height 80mb RLL drive that I salvaged. It weighed a ton (figuratively). One of the heads had broken off the actuator and was bouncing between two platters, so I messed with jumpers and ended up with 65mb usable -- as three separate partitions. The drive lasted another 6 or 7 years before finally failing catastrophically. When I disassembled the device (after the complete failure), I discovered that the reason my trick worked was because the head that broke was the next-to-last. So when I reset the jumper to reduce the heads by two, it was ignoring the last two, which was where the fault was.
I was a PC tech and owner when the RLL controllers came out. While everything official said you needed a rated drive (at least to be supported), common knowledge was that most decent MFM drives could be re-formatted using an RLL controller for a ‘free’ 50% increase in storage space. I bought an Adaptec RLL card, and successfully used it with a ST-225, and a Miniscribe (also a hh drive) and had twin 30meg drives. Later replaced with a giant Maxtor full height that formatted out around 200MB, unheard of for a 8086 box. BTW, aside from the Falcon controller made by Tim Patterson, the fastest a 8 bit MFM or RLL controller could manage was a 2:1 interleave. 1:1 overran the bus unless you knew the magic Tim did. I still have that Maxtor and the controller along with the Compaq deskpro, not powered up in years. I need to image it, so getting that magic board to support RLL would be really exciting to me.
Ok.. the moment he mentioned Procomm Plus, a wave of nostalgia hit me like an ocean breeze.. All the BBS i've spent time on came back to me.. lol That is just awesome!
There is a video of Adrian black making an image of his MFM hard drive in the rare Unix workstation. I’d love to see the emulator feeding the signal back to an mfm cotroller.
When my NYC government agency bought a lot of Priam brand hard drives they sent me to Priam training in NYC around 1986 where we learned about RLL (2,7) encoding. I hadn’t thought about that for almost 40 years and your video brought it all back to me. I remember listening to Howard Stern on the radio on the way to the hotel in Queens where they held the class. You explained the concept well.
Oh, memory lane !!! Thanks for the video. One thing about the MFM vs RLL thing that you missed (not because you were wrong) is that those differences came along because of software, not hardware. People started noticing that there were better ways of encoding things, hence the LZW algorithm that gave us ZIP and DCT (Discreet Cosine Transform) that gave us JPEG. That is where this magical way of encoding stuff came from, if you encode it like that, you are able to compress more stuff together, both being able to store more as well as being able to read/write faster. Once again, Thanks for the video.
Correct, Seagate drives format depends on controller (especially early controllers). I had IBM PC XT clone at work and controller and HDD was treated always as bonded pair in terms of swapping between machines. MFM controllers have some own specific sector prefixes and coding quirks (interleaving sectors).
The way RLL works is quite different from LZW or Huffman tables or any of that, although these ideas were used for "disk doubling" software. 2,7-RLL actually writes twice as many bits as MFM, but by strictly limiting how many consecutive 0s or consecutive 1s are allowed, it can pack those bits in three times as tight and still work with them reliably. These are mapped through a simple lookup table to convert to/from data bytes, resulting in a net 50% increase in both storage and speed, all invisible to the OS. All DOS/BIOS know is that the disk has 26 sectors per track instead of 17.
Interleave indicated how many sectors should be placed *between* sectors in a given sequence. Why does that matter? Because if you were reading sequential sectors, the processor would take some amount of time to transfer data to the PC. This means if you ordered them [1,2,3,4,5,6,7,8], by time you transferred the data after reading sector 1, the head may be physically over sector 4, or 6; and you'd have to wait for the drive to spin back around the start of sector 2. If you get the offset right (say it was optimally 3 or 4 sectors), then an interleave of4 [at least] would put 4 sectors between each sequential one to get the best response time. That would give you an order like this: [1,3,5,7,2,4,6,8]. This way by time the system is ready to read the next sector, sector 2 is the next one to hit (or the one after, worst case). If it hit a conflict when building the map, it would just push to the next free sector block, and continue that pattern until the sector list was full. Worst case, some end sectors have slightly worse performance, but it' still way better than an interleave of 1 (which is how most early drives were formatted). There was a tool called "spinrite" that would copy out, then low-level at about 20 tracks in with different interleaves to find the best one. It would err toward the larger number, and then re-low-level format the whole drive with that offset. (Later versions would change interleave several times over a larger drive, since the value could change based on track velocity and density.) This would cause at least that first area of the drive to be perfectly interleaved. Since that's where the boot, system, and often the MFT lived, it made the boot sequence, and the entire performance of the filesystem significantly faster when properly tuned. Mind you: some drives did not support this low-level rewriting. Many RLL drives would forbid it, since the read timing was so critical that it couldn't be relied on for that track data to be written out in the field. The equipment needed to do the timing properly was far more expensive, and was only found in the factories that made the drives. By that point though, manufacturers were optimizing interleave anyway before production, and drives started having buffers to optimize the transfer to the system. Some early RLL drives mistakenly left the low-level write code in though, and triggering it would just nuke the entire drive. Guess where your ST241 lands in that! If you guessed "nukeable with spinrite", you'd be correct. I know that one from painful personal experience.
Brings back a lot of memories. My first PC was one very much like the EDS, with twin 40mb RLL drives. It ran DOS 3 and it was basically plunked down in front of me to figure out. Eventually had Procomm Plus on it as well. That software was insanely powerful. At one point, I had it running as a BS host for other people to dial into, before eventually just running a real BBS of my own. Procomm Plus was my killer app during that whole era. Still have the floppy somewhere. Seeing it on your channel is like seeing an old friend again. Also surreal seeing AJ on here. That guy gets around!
Procomm Plus had a pretty cool scripting capability which could automate all sorts of things. You could have it read menus and then take action on what was listed in the menus. It was cool for it day.
You have experienced, "Low level format" using the ROM on the controller that is at at memory location C800:5. Then the "partition" using fdisk. Then the "high level format" using the format command.
who needs drivers when the hardware itself comes with a BIOS ROM. this idea of the operating system having drivers was a mistake, we should go back to having ROM BIOS
@@monad_tcp a real mode BIOS. This would not work in protected mode as is. But no standard hardware API leads to a million drivers and no compatibility with linux or even other generations of Windows so I kinda agree with some of it.
@@monad_tcp The code that firmware developers put in ROM is utter garbage with atrocious performance. Good code has never been put in ROM, only trash. BIOS developers have delusions of illusory superiority. You would be right if this planet weren't jam packed with utterly incompetent people. BIOS code is when some jackass thinks it is fine to just spin in a loop until I/Os completes. Some jackass that reads one block at a time, using individual PIO instructions that are 8000 cycles each, with a comment that says // FIXME: Use DMA, lol.
@@monad_tcp What's old is new! Some modern PCIe devices contain a UEFI driver in a standard format on a flash ROM chip. This enables the device to do certain things in the UEFI before an OS loads. For instance a graphics card can detect a display and show text and graphics at native resolution, and a network adapter can obtain an IP and connect to a server if you want to network boot an OS. These drivers can be used by simple OSes too, but most will want to load their own drivers for the device in a format that meshes better with the OS's structure, to support more advanced functions like 3D acceleration of vendor-specific features like CUDA.
It warms my heart to know that there are still ST-238Rs alive out there in the wild. Not extinct yet! Dave, remember the only reason anyone ran the 238 vs. a 225 was the 50% more capacity (30MB vs. 20MB) at an incrementally higher price. Not sure why EDS would spec a 238R in the machine, I guess they needed the 30MB capacity? Otherwise, the 225s were as common as cigarette butts back in the day.
Instead of using format c: and sys c: you can also use format /s c: and transfer the system files as part of the format. Also, ensure that the partition you want to boot is active. From what I recall fdisk from dos 3.3 will take care of that, but it is something to always check.
and if you know the drive is good, add /q for a quick format. The non-quick version just checks for bad sectors before writing the file system. Not sure if that is already in this old version of MS DOS, but for sure in later systems.
@@drstefankrank I'm not entirely sure which version introduced /q but it wasn't available yet in 3.3. From memory it was 5.0, but.. I try to forget DOS 4.0, so it might have been that one as well.
@@c128stuff Like 4th Edition D&D vs. 5e, there were some good ideas in DOS 4 but for the most part they got carried over into version 5 so there's no reason to stick with 4 and its warts.
@@mal2ksc I was a tester for DOS 4, and DOS 4 fdisk actually has a little bit of code from me (fix for selecting an other disk than the primary one). It certainly had some good ideas, but it was rather problematic due to memory use. I probably spent hundreds, if not thousands of hours on helping IBM 'large accounts' (ie, large corporate customers) dealing with exactly that issue. (when DOS 4.01 got released, I worked for IBM) DOS 5 was a huge improvement, containing all the improvements from DOS 4, but without the issues.
I did a similar thing in the early 90s. I got two MFM hard drives (one full height and one half height) basically for free, as there were considered old, loud, large and slow by then. I learned about RLL and that using that would make the storage capacity some 50% more and reading the drives would be faster. I was happy to have the extra storage, and my tower case has enough slots for the huge disks. But man, were those drives noisy...
Nice shirt! We spoke briefly as VCF SW. I actually have one of the world's largest documented collections of vintage mechanical hard disk drives, I'm still counting spoils fron VCF, but I think I am around 600 units right now. FWIW, MFM and RLL drives are not often called this way by collectors, they are ST-506/ST-412 and ST-412HP, or 5MT and 7.5MT, respectively. The only difference is the expected encoding, which for most drives was entirely determined by the method used to test the drive in the factory. If it passed with few enough defects as RLL, its an RLL drive. The ST-238R is one of these drives. It is an ST-225 that you were at one time guaranteed for compatibility with RLL. You can run it as "MFM," or if you have an ARLL card like a Perstor PS200, you could run it at 10 megabits, or if you hitch it to an arduino, you can write one bit per track in a custom format. The drive does not know or care about the format at all. I have tested every drive in my collection as RLL - Every video demo I have done is with a DTC 7287 cached RLL controller. I have yet to find a drive that works with MFM but does not work as RLL. Even the ST-412 itself, and a myriad of crappy clones, even Soviet drives can handle it without much worry. I have personally tried one of those dingy little emulators - I borrowed one from Forgotten Machines, actually, and I was not able to read any drives formatted with my DTC 7287 on it.
It's not always a matter of "works", it can be a matter of data retention. It's not good if the sectors can't be read a few weeks after being written, which could happen if you were pushing the spinning rust to its limits. This is where the bad reputation came from, but somewhere between the ST-225 and the ST-251, it pretty much stopped mattering at all. All the drives were becoming format-agnostic.
@@mal2kscWell, my Soviet-built IZOT CM5508 has no trouble retaining RLL data after 6 months now. Any drive worth anything will have no trouble with this at all - Repeatability is important with any encoding method. Data storage is not about precision so much as Repeatability.
I'm so glad you've done the research, testing and collecting that you've done. And it was also GREAT to meet you at VCFSW! I hope to meet up again and do some hard drive exchanging...
Haha! Love the title of this video :D - There it was, you addressed the title fairly early into the video with a neat explanation. It has surfaced a long buried memory, I'm now trying to think whether I came across these encoding schemes as a student or afterward, lol. At any rate, it's really good to get these "vintage" techniques back in the light of day - thank you, Usagi (and today, AJ)! I'm curious to see what headway you've made with DEC's insanely brilliant PDP-11 power supply schema 😜
I know a lot about the ST-225 / ST-238 , rotation speed stability was the difference as RLL needed better control . The ST-238 is a ST-225 that passed testing . The ST-238 is sutable with modifications for video image file of one digitized with ( PWM on disk ) NTSC frame per track a quiet revolution at that era : )
The sequence is as follows: 1) Low level format: debug g c800:5 to run the BIOS provided on the extension card The sector interleave is the sector count between consecutive sectors on the same track. This value depends on a whole bunch of factors, the most important one being the speed of the CPU. Because of the sector skipping the transfer rate decreases The value of 4 means read one sector skip 3 and read the 4th one etc... For an XT class machine it is probably the right value. 2) Use Fdisk to create 1 Primary dos partition (the only one Dos can boot from) 1 extended partition that will itself contain as many partition as necessary 3) Dos format letter: /u (/u = unconditional do NOT retain previous data structures) The /u switch is only applicable for recent revisions of Dos (5 and up ?) 4) Transfer the system with the 'sys drive:' command From a: with a bootable disk in it run sys c: 5) Copy the rest of the files with copy (or xcopy if available) Putting all dos files under c:\dos is considered good practice Only the 3 system files (see bellow) and boot configuration files (config.sys, autoexec.bat) should be at the root of C: PS: the system files: IBMBIOS.SYS IBMDOS.SYS COMMAND.COM are supposed to be at predefined file allocations positions otherwise the boot process will stall. The sys command does not support "making room" for these files by moving files elsewhere. This is why the sys command has to be applied first, before other file can use up that space. PS2: you might want to give ms-dos 5.x a try to break the 32Mb per partition barrier if the ram size allows.
Since it's not an original IBM-PC, it is probably "IO.SYS" and "MSDOS.SYS" instead. IO.SYS needs to be the first entry in the FAT, starting in the first available sector for data, and contiguous with MSDOS.SYS, which needs to be the second entry in the FAT.
Interleave can be later optimized without a reformat using Spinrite. So yeah, start with a conservative value like 4:1. If it turns out later that your hardware operates well at 3:1, that's basically just an overnight "set it and forget it" changeover. A lot of later RLL controllers, even the 8-bit ISA ones, worked well at 1:1 interleave. So did some of the later MFM controllers. Again, this is something that Spinrite can address if you chose wrong.
The correct way to install DOS would be using SELECT, not using format/sys/copy. You'd create the partition with FDISK, then reboot and run: SELECT A: C:\DOS 001 US It formats the partition, makes it bootable, copies all DOS files into the given path (C:\DOS) and configures it for country code 001 and US keyboard.
Finally someone explains the concept behind mfm vs rll. I used mfm drives with rll controllers for such a long time with my Amiga 1000 and (Commodore) PCs until IDE showed up. Why? As kids we recycled broken drives by swapping parts around and used what we got. We basically never had problems with repurposed ST225, ST251 and the full size ones which model number I just forgot, which just worked fine with rll Controllers.
A couple things. 1) You should copy all the dos files to a dos directory and the procom plus files into a procomm directory. There is a limit to the number of files you can have in the root directory. I forget exactly what it is, but it isn't that much and it's probably less for dos 3. It will generate false disk full errors if that number is met. Second, you should probably create a config sys file and an autoexec bat file with a decent files= statement and load ansi sys (both in config sys) and a path statement in the autoexec bat and a prompt=$p$G for a normal looking c prompt.
The max number of directory entries for FAT12 and FAT16 seems to depend on the total size of the disk. For smaller removable disks it's typically only 100-200 entries. I think hard disks were still limited to 512 entries though. FAT32 got around this by storing the root directory _after_ the FAT along with the rest of the data on the disk and could grow dynamically after the disk was formatted (compare to FAT12 and FAT16 which stored the root directory before the FAT and so was fixed in size when formatting).
Yes, I was squirming at the copying of *everything* to root, but then again it is a limited-purpose computer at the moment (the HDD effectively being a much faster floppy). But a simple autoexec.bat that directly loads Procomm could be useful (for the current usage). I expect the original HDD would have had a startup/utilities menu at boot.
@@SenileOtaku Yes. Often it was a simply type statement with a bunch of lines saying press 1 plus enter to start procomm plus Press 2 plus enter to start bla blah blah With a 1 and 2 and 3.... bat files that end by cls, cd back to root and then a type statement displaying the menu again. Very simple, very effective. A lot of the early XT machines didn't include 640k. So having a menu loaded into memory wasn't really ideal.
I think the limit for files in the root is 512. In any case, putting things in their own directories makes it easier to find things! I think you get a message like Directory Full if you try to exceed this, as opposed to Disk Full if the disk is actually full.
Love that you explained the difference between MFM and RLL ! Love this video, again. I remember going through BYTE Magazine saying "NO/YES" to the HD controllers because I needed an MFM/RLL for the HDD that I wanted to install.
As a couple of other commenters have already said, if you want to get more than the 30MB out of the HDD you will need to low level it again after changing the jumpers on the controller card. The exact parameters for the 4097 are unlikely to be supported, but you can pick any larger geometry which has less than or equal to 9 heads and less than or equal to 1024 cylinders. Look up the model on the controller card on bitsavers or TH99 or similar and find a manual. The supported types should be enumerated in the documentation.
Yes, the 1024 limitation was something related to the maximum number of cylinders addressable at the time. Tools like DiskManager were able to reconfigure the disk geometry and later go beyond 1024.
Back in the early 90s, I remember connecting an MFM hard drive to an 8-bit ISA Seagate RLL controller and I would get an additional ~30% storage after low-level reformatting the drive. The downside was that I noticed the drive would run hotter. Someone once explained to me it had to do with how it would run the actuator which was out of spec. So yes, I would agree from experience that MFM Is RLL and RLL is RLL.
Two thumbs way up for Dave's emulator. When the hard drive on my Kaypro 10 died, I bought one of these. It was close to plug-and-play to install and the old Kaypro restore disks had no problems with it at all!!
Blast from the past - thank you. I remember in the mid-80's buying a HUGE 72MB Micropolis drive and then RLL'ing it to 144MB. An yes, my piers thought I was insane for wanting that much storage. I won't admit what I paid for that (used!) 72MB 8" drive But I was successful and became "the man of the hour" Thank you for the infoTainment. The check is in the mai! Cheers from So.Ca.USA 3rd House On the Left.
17:56 I had an ST4096 back in the day. Looking it up, I see that the difference is that your ST4097 is RLL, as opposed to the original ST4096 which was MFM. Due to this, the higher number of sectors per track gives us the higher transfer rate and capacity.
I agree they are amazing. I imaged a DEC Rainbow disk just in case it fails. The DEC Decmate II disk (same type) is already bad and can't be read. I need to get a few more of these to image the drive in my Pro-350.
Man! so many memories came back with this video 1) After removing the screws, the bump that you had to make to the case with the palm. 2) Putting the case back on: You have to make pressure with your hand's palms leaving your fingers free to make an inverse pressure to fit it again. ....Yes, the secuence to format would be: FDISK to read the disk, examine it, chose your partition configuration and after that create partitions. Then Format C:/s /c, being C: for the first hard drive (Select 1? in FDISK) /s to make it bootable (so you can skip Sys C: later) and /c to check for bad sectors.
MFM, RLL, Voice Coil termos que ficaram para sempre na memória da gente xD FDISK... Debug + G=100 + Entrar lista de Bad Sectors + etc :D fiz muito isso nos computadores, naqueles anos. A gente instalava muitos HD, apesar do preço ser alto. Duas coisas atrapalhavam as controladoras: Mau contato (Mesmo sendo novas) e aterramento. Sim! As fezes, só de colocar um parafuso, mesmo que fechando o gabinete, fazia a controladora ou a placa-mãe ficarem loucas! Vendo a situação, lembrei de um tempo em que alguns conjuntos (controladora+Winchester) ocorria um problema: Após formatar e transferir o sistema e dar boot, dizia que não havia O.S. para dar boot. Daí, tinha que executar o Sys c: novamente. Com o tempo, descobri o que era (não lembro mais). Bem, grato pelo vídeo!
You can run MFM drives on an RLL controller and, back in the day, be very happy getting 50% more space, but there's a cost. As the drives heat up, you can end up getting more and more read errors since the disks aren't really rated for that kind of density. The drive may last a couple years running like this, then the errors start. I ran into this with a couple of ST-225's. Both drives started with read errors about 2 years into their lives. It got to the point where they were so hot, I couldn't touch the drives after 30 minutes. I really had to copy the data off of them, but to keep the drives running cool enough for long enough, I had to run the drives under a towel and a gallon bag of ice water. Worked like a charm!
Back in the day, I do recall taking an MFM drive that was about 20MB and worked fine with it's MFM controller in DOS. I replace the MFM controller with an RLL controller to the same HDD then low level formatted it, but I'm not sure what software I used for that it wasn't using debug and jumping to a memory location. It was either a specific software from the drive maker, OR is was a format utility in CMOS BIOS that wrote zeros all over the drive. After that I mounted the drive with FDISK. Then formatted it in DOS (3.3 or 5 maybe?) and it gained 10-11 more MB! I then ran Norton Utilities to set it's interleave (1:1) so it would run a little bit faster. Interleave, from what I understand, was the number of times the disk would spin before it performed a read/write. The higher the interleave the slower the drive performed. Norton Utilities had a program what would test interleaves for your drive and find the lowest interleave that didn't screw data integrity. If it managed 1:1 (1 rotation : 1 r/w) then you have a very good drive.
31:30 you could have added a /s after the format command to essentially do both steps at once. Been ages since I used that early of a version of DOS, but I know that worked at least with version 5 and later. Should still work on 3.3 though I believe.
Interleave basically translates to "how many revolutions of the disk are required to read all sectors on a track". Smaller values make reads/writes faster until the controller's ability to read consecutive sectors is exceeded. At that point performance falls off a cliff because an additional rotation of the disk is required between reading/writing each sector. For old 8 bit MFM controllers on XTs, interleave of 3 was typical, but sometimes you could get away with 2, increasing performance by 33%. RLL usually has a higher interleave value because the sectors pass under the heads more quickly (26 per revolution rather than 17).
To format the harddrive and transfer system in one step you can use A>FORMAT C: /S but also to make your system disk look a little nicer you could place the dos files in a subdirectory by itself. A>MD C:\DOS and then copy the diskettes from A -> C:\DOS A>COPY 'star'.'star' C:\DOS (RUclips won't show the 'star' character) to enable the system to find the dos files at the correct subdir you need to add following line to the AUTOEXEC.BAT file PATH=C:\DOS Maybe other ppl suggested this too, so I'm sorry if this would be a double entry. Very nice machine :)
Oh man, this reminds me of my qbx days except you are getting hard drives to work. I never fixed a single one, I just got them from the trash working and used them til I found a better system in the trash. I kept trading up and up entire dos systems out of the trash in the 90's until I got up to a 286 processor. I've seen many of those old drives in terrible states of condition making lovely progressive failure noises. I don't miss the 80'88's trying to run QBX with dos 6 on 600k of ram either. HOWEVER I do love magnetic recording and data fundamentals (TAPE) so your video here is functional therapy for me. Thank you, and I enjoy coming along for the ride!
I did the ST-225 / ST-238 modification back in the mid-80's as well! I do remember the early version of spinrite, to determine the optimal sector interleave (1 = 1,2,3,4; 2 = 1,3,5,...; etc) before reformatting it. it's been so long so i'm not surprised how many people haven't actually experienced the joy of going from 20mb to 30mb on your hard drive!
How are you planning to do file transfer? Write an XMODEM program for the Centurion, and then use Procomm+'s file transfer support (which surely includes XMODEM)? I don't understand why different disk block sizes matter if you are backing up at the file level... Flashback to using KERMIT to transfer files from our VAX/VMS mainframe to my Atari ST in 1987ish...
I was wondering the same thing. The serial transfer would act as an abstraction layer, leaving the program on either end to handle any data storage through the OS. Might need something to make a note of any extra attributes the Centurion's filesystem adds to files or translate them to a DOS equivalent, maybe?
Oh man that took me back 30+ years to playing around with my Amstrad PC1512 and then PC1640 machines. Formatting hard drives, swapping floppies back n forth, trying out copy commands, learning about Autexec.Bat, Config.Sys, XCopy, editing files, trying and failing, then trying and succeeding etc etc. What amazing days they were 🥰
This reminded me of the Perstor 180 and 200 series disk disk controller boards from the late 80s (I think). They used a more aggressive RLL coding, which would allow pretty much a capacity doubling relative to their MFM capacity, rather than the extra 50% from the regular 2,7 coding that was normally used. Of course, they also required even better timing stability in the recovered read data signal in order to operate, but by the late 80s more drives were capable of that level of performance.
Sys doesn't need it to be freshly formatted. It needs a very specific place in the drive to be empty to place the system files in that specific location. If that specific space isn't free then you get that error regardless of how much free space the rest of the drive has.
You need to copy all the DOS files into a directory usually called "DOS", because the number on entries i.e. files in the root directory is limited. The error message is a bit useless since it will only say something "not enough space left..." when it actually should say "not enough file table entries left..."
It's either that, or old versions of sys weren't able to move stuff around to make space for IO.SYS (of which at least the beginning needs to be in the first sector, IIRC)
@@seritools Ahh yes, that was the reason, I remember now. Similar for Windows: KRNL386.SYS can be anywhere on the drive but must not be moved. It was loaded using a sector table written to the boot sector compiled during installation. If the checksum didn't match then you got "Cannot find or load KRNL386.SYS".
The limit is 512 items in the root directory, which includes hidden files and subdirectory’s. I know this thanks to having to recover a customer’s system after they saved everything to the root…
Funny how I haven't done a lowlevel format of an RLLor MFM drive since the late 80s, but I still remembere debug g=c800:5. Crazy what the brain stashes away. I am loving your channel. It's got so much fantastic content. /spins propellar hat.
I have formatted a 10 meg I believe was a seagate mfm drive from mfm to rll on a ibm xt 4.77 . It was to gain more space from that drive it would be 14 megs or something after converting to RLL
Of course you need to SYS the disk as countless others already told you. But another thing that got me on edge... you do know that DOS since version 2 can do subdirectories and that you can place a "SET PATH=C:\DOS" into the AUTOEXEC.BAT? Maybe a CONFIG.SYS with a few lines, like "DEVICE=C:\DOS\HIMEM.SYS" to liven up the place and all should be fine. ☺
Cool video, i'm actual working on an "WANG Professional Computer" (It is an MS-DOS machine witch is not IBM compatible and use ist own card interface no ISA connectors), with some problems with the comunication with the hard drive. It's an MFM Drive, spins up normally and runs through it's self test and the drives service manual says, when the powerlight stays on (What it does) and doesn't blink, the drive is in ready state. After 1 minute of computer selftesting it says "booting from winchester disk..... failed. After that i couldn't test anymore because the damn RIFAS goes up in smoke. But befor i powered it on, i dumped all the ROMs (safety first).
As a computer nerd in the 1980's, I did find that you could format a Seagate MFM drive with an RRL controller to get about double the drive size. However, often after a few months the MFM drive will crash and now all you have is a new door stop.
When you run the initial format command, there is a /s option which transfers the systems files. Similarly, there is a dos SYS command for transferring the systems files after formatting is complete. I don't think it will boot from C: if you just copy *.*. That's fine for copying the dos files there are 3 files hat have to be placed on specific sectors and that why you have to use the sys command or use format with the /s option.
Wow. References to sector interleaving. Haven't seen that sort of thing in a very long time. BTW, IIRC, you can type "format c: /s" to format the drive and make it bootable in one step instead of running sys after running format.
I had a MFM drive as well as RLL drives way back in the 80's and I don't remember exactly what I was doing with them (maybe copying one to another or swapping them out) but the drive (I don't remember which one) just started to make all kind of noise like the write head was just bouncing back and forth off it's stops. I then realized that it needed to be mounted in the chassis because it used it for ground. Just FYI if you have the same kind of problem.
Usually format C: /Q /Y only write an empty File Allocation Table and does not ask for confirmation. This is time saving not to cycle through writing all the cylinders.
@bubullenoiraude you lived in a dangerous fast way! At company level I cannot afford any errors to show up unexpectedly so format without checking for bad sectors was a big NO, No for me and my work.
MFM and RLL drives, now that's a while ago! I can't remember the details, but I remember when RLL drives came about. Or was it the controllers that started supporting RLL? Frankly I can't really remember. I do know that the same drive could be formatted using MFM or RLL and using RLL it gained something like ten or twenty percent capacity. at the time this was a big thing. Other things you had to test was performance related. The formatted sectors on a track on the disk was not necessarily ordered 1, 2, 3 and so on in series. Usually you inserted interleave sectors, so the order could be 1, 8, 15, 2, 9, 16 and so on. This was done as the computer, card slot or the disc controller couldn't read the sectors if they were just stepped up by one every time. Then the disc had to spin an entire revolution for the controller to read the next sector. But with the right interleave it was ready for the next sector when the interleave sectors had passed under the read head. With an interleave of 0 a complete track could be read at one revolution but it was very uncommon you saw a computer able to handle that. An interleave of one meant that it would take two revolutions to read the entire track. Each time you added a interleave sector the necessary revolutions rose by one, so you wanted to use a interleave that was just big enough that they computer could handle it. Another thing was the data listing defect sectors on the disk. This was used to map these so they wouldn't be used when accessing the drive. Most of the time they came on a separate paper with the drive, but often they were also written on the label of the drive. Some times they were rather long and other times there were just a few listed. This data was entered when doing the low level format of the drive, this was also when you set the interleave so that it was used for the format when installing the OS. What is interesting is that so much of this has become antiquated knowledge. It must be at least 20 years since I low level formatted a HDD, perhaps 30 years.
Idk why but the "technical difficulties" with the piano brake down killed me I wasn't expecting something that random upbeat and fast paced in the middle of all the interesting long winded info
Thinking way, way back, and with some uncertainty: a handy keyboard thing is the upand down arrow keys. From the command prompt, type UP-arrow and it displays the previous command line. DOS keep a few lines available. Browse through them with UP and DOWN arrows. When you get one you want to repeat, press enter. If you want to edit it, use RIGHT and LEFT arrow keys.
As someone who designed hard drive controllers when this tech was new, you are right - FM, MFM and RLL are all RLL. However, the quality of the oxide needs to be a whole lot better for "RLL" to work well. Formatting needs to write new address marks (which begin sector marks and data). Sector marks are a bunch of data which tells you which sector will come next (ie contains the track number and sector number). However - the address marks and sector data may be interleaved - sector label 1 is followed by data for the last sector, then sector label two, then sector data one! This is because the formatter processor may not be fast enough to figure out which label it just read in the inter-sector gap!
I warn you - address marks are a possible problem: Mostly people used the IBM address mark. Unfortunately the IBM documents were wrong! The data bits were defined in chronological order, but the clock bits in reverse chronological order. I designed a controller with the clock bits in the correct order (as an option). Using the bits in the correct order means that the address mark contains a single flux transition in between two gaps exceeding the max legal distance in legit data. This means it is a unique pattern on the drive surface. The industry standard version is illegal as data, but is not necessarily unique. Using my address mark, most drives had enormously fewer bad sectors and read errors - but were not compatible with formatters made by IBM, Western Digital etc. I used programmable logic (which was new at the time) to map data into RLL code .
In addition to formatters for mainframes, I also did the first hard drive interface for the Apple ][, and one for the BBC micro. Both used the 6502 CPU - like Woz did for the floppy controller!
Very interesting, I always thought that there must be a trick to write rll adress marks. Do you have a video or link for the details of encoding?
Very interesting!
Wow! Fantastic to hear!
For what it's worth, I've tested every single drive in my collection (over 500+ drives at this point) as RLL and I've had very few drives fail RLL that didn't already have issues during nominal MFM operation.
decoding that raw flux image will be an interesting problem
I always though RLL was a kind of extension to MFM. a 20MB MFM drive would be 30MB with RLL, IIRC. What I can't recall are the specific debug commands used for the low level formatting.
Sure, hundreds of us neckbeards were shouting SYS C: at the telly (or even FORMAT /S), but, and this is important, hundreds more didn't have the first clue so it's excellent that you're showing this to the inexperienced :D
I thought I remembered a shortcut to use the /s parameter for formatting to make it bootable
That's part of why I love watching people work on very different old tech. Man's got an incredible handle on the minicomputers like the Centurion, but DOS isn't really in his wheelhouse, where I can breeze through DOS but I'm *absolutely* lost on the big(gish) iron.
I was taught this stuff back in school; but, having not touched it in over 20 years, the actual command was foggy. More reason to check back at this stuff periodically, I guess.
Format c: /s would have done it
trimmed my neckbeard earlier today, but I was still shouting "/S!"
Before MS-DOS 4, the sys command required the disk to be freshly-formatted. Starting with MS-DOS 4, the sys command was able to handle files already being on the disk.
I think the root cause is in a boot sector loader. In 3.3 it was just loading system from reserved sectors. Later it started to look for system in directory entries
What you would typically do was use the /s parameter for the FORMAT command, which would do the equivalent of SYS immediately after the format.
@@alexloktionoff6833 If they were reserved sectors, then there would be no problem loading the boot code in later.
@@big0bad0brad They are reserved once used. So it's more them being fixed ones, and if they already are in use for other things, sys cannot free (and reserve) them.
@@alexloktionoff6833 The DR-DOS bootloader could read the system files from the directory entries, which was very convenient. However, MS-DOS was never able to do this.
Yes, I was yelling "You have to sys the drive." Or, you can format and sys the drive with the format C: /s command.
Great video.
This was the "normal way" format (A/C/D): /s in former times.
But, why low level, when the linuxdevice print all OK? It is the first formatting of a hard drive. This hard drive was lowlevel formatted. As a rule, this was only done when the HDU said goodbye. Or the controller had a different logic, such as Ompti, Adaptec, DTC. It was better with the spinrite tool.
The good old DOS. 2.11😀😉 and Speedstore to use BigDisk > 32mb
Yes, that was the way we did the bootable drive format, in one step.
Same 😂
I was actually expecting him to sys the drive and still not boot because of missing BOOT flag on the volume in MBR
Wasn't until (U)EFI boot that you could just boot from a system with the right files on the disk and no boot sector meddling heh.
Yay!
30:47 indeed we were screaming "sys c:". I'm so glad that at LAST I had some relevant knowledge for this channel 🤣
Or "format c: /s"
format c: /s
Was it a later dos version that included "format /s c:"?
I chuckled and just wait to him discover just copying the files don't work hahahaha
I also thought NOOOOOOO you're missing the sys command 🙂
The thing with the SYS command, the IO and MSDOS system files is hardcoded to be the very first two files on the drive. The reason for this is because the libraries for handling the filesystem is inside those, so the DOS boot code can't go searching through the filetable the same way you can after DOS is loaded.
It's really a laziness of the bootloader. The FreeDOS bootloader includes enough of a FAT12/16/32 filesystem driver within the 512 bytes to find and load its kernel.sys, stepping through the FAT entries to find the next sectors.
I've also written one that not only includes enough filesystem driver but also floppy controller driver to load my BIOS on a system that does not have a BIOS in ROM, with the BIOS file at any physical disk position. Including a startup text and error message display, again without any help from the BIOS.
MS was just lazy. There's plenty of room for that code.
This got fixed. I've been seeing DOS 4.0 quoted as the beginning of the ability to SYS any disk as long as it was big enough to move the existing files out of the way, but I skipped it. I know for certain that DOS 5 did it.
@@mal2ksc I was going to make the same remark re: DOS 5. I had DOS 4, but never had reason to explore the sys issue there.
Never did "trust" it lol... format with the /s was failsafe.
Totally understandable limitation, but it would have been nice if they used a more informative error message when there are already files on the drive.
FYI, an ST238R is simply an ST225 that passed a few more QC checks. Quite a few hobbyists with ST225s plugged in an RLL board and got the 32MB capacity with no issues.
Everyone else living in a rural property in Texas has a "ranch," whereas Dave has a "compound"
Tell that to the Davidians
I'd wager there are a few other compounds, as well as bunkers, installations, strongholds, and camps.
We have enough computing power to land people on the moon (almost at least)! I think that qualifies us as a compound :D
@@UsagiElectric So, a calculator, basically? :P
@@johnpmchappellpixel 7a
You've low-level formatted the ST4097 with the drive parameters of the ST238R, so you'll only have 30MB usable. On these older controllers you have to select the drive parameters with jumpers. They depend on the Controller's BIOS ROM version though. There are lists online of which ROM version supports which drives. It's quite possible that your ROM won't support the correct parameters, so you'd either have to modify it and change the parameter table, or get the WD SuperBios which can be configured to any drive parameters.
The ST4097 is a 80MB MFM drive, so with 2,7 RLL it should give you roughly 120MB!
Those older Western Digital controllers have jumpers to set the drive type. Since you originally had a ST-238R in there, it's treating the ST-4097 as a ST-238R which means it formatted it with 615 cylinders, 4 heads, and 27 sectors. The drive types are defined in the ROM on the controller itself and it probably doesn't support the ST-4097 at all. There is a utility called SpeedStor that has a command line switch to display the drive types supported by the controller. Later WD controllers offered a free format option where you could enter in the correct drive parameters for the drive. The drive interleave is how the sectors are laid down onto the drive during the low-level format. A 4 to 1 interleave will skip every four sectors. The reason for this, is the 8-bit controller is not fast enough to process an interleave ratio lower then 4 to 1. I you were to tell the controller to use an interleave ratio of 3 or lower, you would end up with extremely slow drive performance as the controller would fail to read the next sector in line and have to wait for it come back around to try again. This would result in a 27 to 1 interleave ratio meaning one sector read for each platter revolution. If you were to toss in a 16 bit RLL controller like a ST-21R, you would be able to run a 1 to 1 interleave and should see 7 mb/s drive through put. There is even more tweaks that can be done during a low-level format such as head an cylinder skewing. Which affects how the sectors are positioned on the adjacent platters so when the head switches or moves it doesn't have to wait for an entire platter revolution. Without skewing, a fast drive like the ST-4097 will be faster with a 2 to 1 interleave vs a 1 to 1 interleave. You may also want to check out the ESDI interface which extends on the ST-412 (MFM / RLL) interface. ESDI is not compatible with the older ST-412 interface drives.
ESDI drives differ by having the data separator and PLL electronics in the drive instead of on the backplane controller. ESDI is quite different from ST-506/412 in a number of ways. ESDI supports higher level commands to the drive than ST-506/412 too.
Good explanation of interleave.
However in my experience many better controllers I worked with would work down to 2:1 on a XT. Tim Patterson (yes that one) made a “Falcon” controller that was able to use some kind of burst mode on the bus to be able to handle a 1:1 interleave. I’d have one in my old deskpro, but it was MFM only and I wanted RLL for the greater storage.
I had three ESDI drives donated to me with a lot of bad sectors. They were still larger than any other drives I happened to have at the time, both logically (150 and 300MB drives) and physically - these were the full height of 3.2 inches. My drives also took about a minute to come up to a stable speed. Yes, they were on their last legs, however they still made a Linux system viable for me.
@@brickviking667 I had a lot better luck with ESDI drives. I was a bit unnerving to see a label with a big bad sector map, but it was rare to ever experience gown defects. It seemed all or nothing - either the drive worked, or it was a brick.
I remember when I was a kid working with these drives. I had a 20mb MFM drive, a 40mb RLL drive, and later a full-height 80mb RLL drive that I salvaged. It weighed a ton (figuratively). One of the heads had broken off the actuator and was bouncing between two platters, so I messed with jumpers and ended up with 65mb usable -- as three separate partitions. The drive lasted another 6 or 7 years before finally failing catastrophically. When I disassembled the device (after the complete failure), I discovered that the reason my trick worked was because the head that broke was the next-to-last. So when I reset the jumper to reduce the heads by two, it was ignoring the last two, which was where the fault was.
I was a PC tech and owner when the RLL controllers came out. While everything official said you needed a rated drive (at least to be supported), common knowledge was that most decent MFM drives could be re-formatted using an RLL controller for a ‘free’ 50% increase in storage space.
I bought an Adaptec RLL card, and successfully used it with a ST-225, and a Miniscribe (also a hh drive) and had twin 30meg drives. Later replaced with a giant Maxtor full height that formatted out around 200MB, unheard of for a 8086 box.
BTW, aside from the Falcon controller made by Tim Patterson, the fastest a 8 bit MFM or RLL controller could manage was a 2:1 interleave. 1:1 overran the bus unless you knew the magic Tim did.
I still have that Maxtor and the controller along with the Compaq deskpro, not powered up in years. I need to image it, so getting that magic board to support RLL would be really exciting to me.
Ok.. the moment he mentioned Procomm Plus, a wave of nostalgia hit me like an ocean breeze.. All the BBS i've spent time on came back to me.. lol That is just awesome!
Yes, I also used Procomm quite a bit back in those wonderful BBS days. Also ran my own BBS for many years. I wish I had kept a backup of it.
But did you pay for it?
Likewise
@@JanBruunAndersen Did anyone? wasn't it shareware....
@@paulstubbs7678 - it was. Which meant that after a trial period you were supposed to pay for it.
Always find hard drive stuff very fastening.
Plus I want to thank you and your discord team for helping out Adrian's digital basement.
👍
There is a video of Adrian black making an image of his MFM hard drive in the rare Unix workstation. I’d love to see the emulator feeding the signal back to an mfm cotroller.
When my NYC government agency bought a lot of Priam brand hard drives they sent me to Priam training in NYC around 1986 where we learned about RLL (2,7) encoding. I hadn’t thought about that for almost 40 years and your video brought it all back to me. I remember listening to Howard Stern on the radio on the way to the hotel in Queens where they held the class. You explained the concept well.
Brings back memories of my first PC in 1988, running Debug to low level format a 5MB Rodime HDD I bought second hand.
I remember those Rodime drives. Davong Systems drives too.
Wow there's a brand name I forgot about. Remember doing the same thing. Was always a white knuckle experience.
Oh, memory lane !!! Thanks for the video. One thing about the MFM vs RLL thing that you missed (not because you were wrong) is that those differences came along because of software, not hardware. People started noticing that there were better ways of encoding things, hence the LZW algorithm that gave us ZIP and DCT (Discreet Cosine Transform) that gave us JPEG. That is where this magical way of encoding stuff came from, if you encode it like that, you are able to compress more stuff together, both being able to store more as well as being able to read/write faster. Once again, Thanks for the video.
Correct, Seagate drives format depends on controller (especially early controllers). I had IBM PC XT clone at work and controller and HDD was treated always as bonded pair in terms of swapping between machines. MFM controllers have some own specific sector prefixes and coding quirks (interleaving sectors).
The way RLL works is quite different from LZW or Huffman tables or any of that, although these ideas were used for "disk doubling" software. 2,7-RLL actually writes twice as many bits as MFM, but by strictly limiting how many consecutive 0s or consecutive 1s are allowed, it can pack those bits in three times as tight and still work with them reliably. These are mapped through a simple lookup table to convert to/from data bytes, resulting in a net 50% increase in both storage and speed, all invisible to the OS. All DOS/BIOS know is that the disk has 26 sectors per track instead of 17.
@@mal2kscIf there's a lookup table involved, would that be a really early form of a static dictionary?
Interleave indicated how many sectors should be placed *between* sectors in a given sequence. Why does that matter? Because if you were reading sequential sectors, the processor would take some amount of time to transfer data to the PC. This means if you ordered them [1,2,3,4,5,6,7,8], by time you transferred the data after reading sector 1, the head may be physically over sector 4, or 6; and you'd have to wait for the drive to spin back around the start of sector 2. If you get the offset right (say it was optimally 3 or 4 sectors), then an interleave of4 [at least] would put 4 sectors between each sequential one to get the best response time. That would give you an order like this: [1,3,5,7,2,4,6,8]. This way by time the system is ready to read the next sector, sector 2 is the next one to hit (or the one after, worst case). If it hit a conflict when building the map, it would just push to the next free sector block, and continue that pattern until the sector list was full. Worst case, some end sectors have slightly worse performance, but it' still way better than an interleave of 1 (which is how most early drives were formatted).
There was a tool called "spinrite" that would copy out, then low-level at about 20 tracks in with different interleaves to find the best one. It would err toward the larger number, and then re-low-level format the whole drive with that offset. (Later versions would change interleave several times over a larger drive, since the value could change based on track velocity and density.) This would cause at least that first area of the drive to be perfectly interleaved. Since that's where the boot, system, and often the MFT lived, it made the boot sequence, and the entire performance of the filesystem significantly faster when properly tuned.
Mind you: some drives did not support this low-level rewriting. Many RLL drives would forbid it, since the read timing was so critical that it couldn't be relied on for that track data to be written out in the field. The equipment needed to do the timing properly was far more expensive, and was only found in the factories that made the drives. By that point though, manufacturers were optimizing interleave anyway before production, and drives started having buffers to optimize the transfer to the system. Some early RLL drives mistakenly left the low-level write code in though, and triggering it would just nuke the entire drive. Guess where your ST241 lands in that! If you guessed "nukeable with spinrite", you'd be correct. I know that one from painful personal experience.
Brings back a lot of memories. My first PC was one very much like the EDS, with twin 40mb RLL drives. It ran DOS 3 and it was basically plunked down in front of me to figure out. Eventually had Procomm Plus on it as well. That software was insanely powerful. At one point, I had it running as a BS host for other people to dial into, before eventually just running a real BBS of my own. Procomm Plus was my killer app during that whole era. Still have the floppy somewhere. Seeing it on your channel is like seeing an old friend again. Also surreal seeing AJ on here. That guy gets around!
Procomm Plus had a pretty cool scripting capability which could automate all sorts of things. You could have it read menus and then take action on what was listed in the menus. It was cool for it day.
I like the part where they make sure that the SD card is mounted and then writing the raw image to the onboard storage. 😂
I saw that as well and waited for the part where they pull the SD Card and wonder why it is empty upon inspection on a PC, but it never happened.
@@drstefankrank And then you hope very perfusely that the root partition isn't a ramdisk.
@@Stoney3K I also didn't pay too much attention on how big the root is and expected a disk full error, but it seems it has plenty of space.
@@drstefankrank I expected the disk full error any moment.
Well, when dealing with critical, non-replacable data, it's probably better to save to internal storage and then copy to the SD.
36:02 You're welcome, it and it WAS an absolutely blast!
Love the excitement you both display when something works. I've been in the same position decades back and your chuckling brought back those days.
You have experienced, "Low level format" using the ROM on the controller that is at at memory location C800:5. Then the "partition" using fdisk. Then the "high level format" using the format command.
who needs drivers when the hardware itself comes with a BIOS ROM.
this idea of the operating system having drivers was a mistake, we should go back to having ROM BIOS
@@monad_tcp Those ROM BIOS are why the x86 memory address space has been a hot mess for 40+ years. I'd rather not.
@@monad_tcp a real mode BIOS. This would not work in protected mode as is. But no standard hardware API leads to a million drivers and no compatibility with linux or even other generations of Windows so I kinda agree with some of it.
@@monad_tcp The code that firmware developers put in ROM is utter garbage with atrocious performance. Good code has never been put in ROM, only trash. BIOS developers have delusions of illusory superiority. You would be right if this planet weren't jam packed with utterly incompetent people. BIOS code is when some jackass thinks it is fine to just spin in a loop until I/Os completes. Some jackass that reads one block at a time, using individual PIO instructions that are 8000 cycles each, with a comment that says // FIXME: Use DMA, lol.
@@monad_tcp What's old is new! Some modern PCIe devices contain a UEFI driver in a standard format on a flash ROM chip. This enables the device to do certain things in the UEFI before an OS loads. For instance a graphics card can detect a display and show text and graphics at native resolution, and a network adapter can obtain an IP and connect to a server if you want to network boot an OS. These drivers can be used by simple OSes too, but most will want to load their own drivers for the device in a format that meshes better with the OS's structure, to support more advanced functions like 3D acceleration of vendor-specific features like CUDA.
It warms my heart to know that there are still ST-238Rs alive out there in the wild. Not extinct yet!
Dave, remember the only reason anyone ran the 238 vs. a 225 was the 50% more capacity (30MB vs. 20MB) at an incrementally higher price. Not sure why EDS would spec a 238R in the machine, I guess they needed the 30MB capacity? Otherwise, the 225s were as common as cigarette butts back in the day.
Instead of using format c: and sys c: you can also use format /s c: and transfer the system files as part of the format.
Also, ensure that the partition you want to boot is active. From what I recall fdisk from dos 3.3 will take care of that, but it is something to always check.
and if you know the drive is good, add /q for a quick format. The non-quick version just checks for bad sectors before writing the file system. Not sure if that is already in this old version of MS DOS, but for sure in later systems.
I came here to say this, but I wasn't sure if /s was available in 3.3. It's been a very long time! lol
@@drstefankrank I'm not entirely sure which version introduced /q but it wasn't available yet in 3.3. From memory it was 5.0, but.. I try to forget DOS 4.0, so it might have been that one as well.
@@c128stuff Like 4th Edition D&D vs. 5e, there were some good ideas in DOS 4 but for the most part they got carried over into version 5 so there's no reason to stick with 4 and its warts.
@@mal2ksc I was a tester for DOS 4, and DOS 4 fdisk actually has a little bit of code from me (fix for selecting an other disk than the primary one).
It certainly had some good ideas, but it was rather problematic due to memory use.
I probably spent hundreds, if not thousands of hours on helping IBM 'large accounts' (ie, large corporate customers) dealing with exactly that issue.
(when DOS 4.01 got released, I worked for IBM)
DOS 5 was a huge improvement, containing all the improvements from DOS 4, but without the issues.
I did a similar thing in the early 90s. I got two MFM hard drives (one full height and one half height) basically for free, as there were considered old, loud, large and slow by then. I learned about RLL and that using that would make the storage capacity some 50% more and reading the drives would be faster. I was happy to have the extra storage, and my tower case has enough slots for the huge disks. But man, were those drives noisy...
Nice shirt! We spoke briefly as VCF SW. I actually have one of the world's largest documented collections of vintage mechanical hard disk drives, I'm still counting spoils fron VCF, but I think I am around 600 units right now.
FWIW, MFM and RLL drives are not often called this way by collectors, they are ST-506/ST-412 and ST-412HP, or 5MT and 7.5MT, respectively. The only difference is the expected encoding, which for most drives was entirely determined by the method used to test the drive in the factory. If it passed with few enough defects as RLL, its an RLL drive.
The ST-238R is one of these drives. It is an ST-225 that you were at one time guaranteed for compatibility with RLL. You can run it as "MFM," or if you have an ARLL card like a Perstor PS200, you could run it at 10 megabits, or if you hitch it to an arduino, you can write one bit per track in a custom format. The drive does not know or care about the format at all.
I have tested every drive in my collection as RLL - Every video demo I have done is with a DTC 7287 cached RLL controller. I have yet to find a drive that works with MFM but does not work as RLL. Even the ST-412 itself, and a myriad of crappy clones, even Soviet drives can handle it without much worry.
I have personally tried one of those dingy little emulators - I borrowed one from Forgotten Machines, actually, and I was not able to read any drives formatted with my DTC 7287 on it.
LOL at the one-bit-per-track example.
It's not always a matter of "works", it can be a matter of data retention. It's not good if the sectors can't be read a few weeks after being written, which could happen if you were pushing the spinning rust to its limits. This is where the bad reputation came from, but somewhere between the ST-225 and the ST-251, it pretty much stopped mattering at all. All the drives were becoming format-agnostic.
@@mal2kscWell, my Soviet-built IZOT CM5508 has no trouble retaining RLL data after 6 months now. Any drive worth anything will have no trouble with this at all - Repeatability is important with any encoding method. Data storage is not about precision so much as Repeatability.
@@ericwazhungIt's possible, and I've personally done something like it with an Arduino - But I was using FSK, it's a lot easier to breadboard.
I'm so glad you've done the research, testing and collecting that you've done. And it was also GREAT to meet you at VCFSW! I hope to meet up again and do some hard drive exchanging...
Dumping everything in the root directory makes my hair stand on end XD
The contents of the DOS disks go in C:/DOS, then you put it in your path string
Haha! Love the title of this video :D - There it was, you addressed the title fairly early into the video with a neat explanation. It has surfaced a long buried memory, I'm now trying to think whether I came across these encoding schemes as a student or afterward, lol.
At any rate, it's really good to get these "vintage" techniques back in the light of day - thank you, Usagi (and today, AJ)!
I'm curious to see what headway you've made with DEC's insanely brilliant PDP-11 power supply schema 😜
All Hail Ross Perot! (that noise is the sound of our souls being sucked out by the floppy)
I know a lot about the ST-225 / ST-238 , rotation speed stability was the difference as RLL needed better control . The ST-238 is a ST-225 that passed testing .
The ST-238 is sutable with modifications for video image file of one digitized with ( PWM on disk ) NTSC frame per track a quiet revolution at that era : )
Congrats! Your EDS now boots from the C drive, just like a modern PC!
The sequence is as follows:
1) Low level format:
debug g c800:5 to run the BIOS provided on the extension card
The sector interleave is the sector count between consecutive sectors on the same track.
This value depends on a whole bunch of factors, the most important one being the speed of the CPU.
Because of the sector skipping the transfer rate decreases
The value of 4 means read one sector skip 3 and read the 4th one etc... For an XT class machine it is probably the right value.
2) Use Fdisk to create 1 Primary dos partition (the only one Dos can boot from)
1 extended partition that will itself contain as many partition as necessary
3) Dos format letter: /u (/u = unconditional do NOT retain previous data structures)
The /u switch is only applicable for recent revisions of Dos (5 and up ?)
4) Transfer the system with the 'sys drive:' command
From a: with a bootable disk in it run sys c:
5) Copy the rest of the files with copy (or xcopy if available)
Putting all dos files under c:\dos is considered good practice
Only the 3 system files (see bellow) and boot configuration files (config.sys, autoexec.bat) should be at the root of C:
PS: the system files:
IBMBIOS.SYS
IBMDOS.SYS
COMMAND.COM
are supposed to be at predefined file allocations positions otherwise the boot process will stall.
The sys command does not support "making room" for these files by moving files elsewhere.
This is why the sys command has to be applied first, before other file can use up that space.
PS2: you might want to give ms-dos 5.x a try to break the 32Mb per partition barrier if the ram size allows.
Since it's not an original IBM-PC, it is probably "IO.SYS" and "MSDOS.SYS" instead. IO.SYS needs to be the first entry in the FAT, starting in the first available sector for data, and contiguous with MSDOS.SYS, which needs to be the second entry in the FAT.
You can omit the SYS command if you do format /s
That works too.
Interleave can be later optimized without a reformat using Spinrite. So yeah, start with a conservative value like 4:1. If it turns out later that your hardware operates well at 3:1, that's basically just an overnight "set it and forget it" changeover.
A lot of later RLL controllers, even the 8-bit ISA ones, worked well at 1:1 interleave. So did some of the later MFM controllers. Again, this is something that Spinrite can address if you chose wrong.
The correct way to install DOS would be using SELECT, not using format/sys/copy.
You'd create the partition with FDISK, then reboot and run:
SELECT A: C:\DOS 001 US
It formats the partition, makes it bootable, copies all DOS files into the given path (C:\DOS) and configures it for country code 001 and US keyboard.
@@kpanic23 Is that similar to Setup or Install in newer DOS versions?
As an old EDS'er I smile when I see that logo.
Finally someone explains the concept behind mfm vs rll.
I used mfm drives with rll controllers for such a long time with my Amiga 1000 and (Commodore) PCs until IDE showed up.
Why? As kids we recycled broken drives by swapping parts around and used what we got. We basically never had problems with repurposed ST225, ST251 and the full size ones which model number I just forgot, which just worked fine with rll Controllers.
You have a great knack for simplifying and explaining all of the tech jargon. Extremely fun entertaining and educational channel.
A couple things. 1) You should copy all the dos files to a dos directory and the procom plus files into a procomm directory. There is a limit to the number of files you can have in the root directory. I forget exactly what it is, but it isn't that much and it's probably less for dos 3. It will generate false disk full errors if that number is met.
Second, you should probably create a config sys file and an autoexec bat file with a decent files= statement and load ansi sys (both in config sys) and a path statement in the autoexec bat and a prompt=$p$G for a normal looking c prompt.
Yeah i was thinking that, he got spoiled by the Centurion 🙂 IIRC it just says no free space when there is or that abort retry ignore prompt.
The max number of directory entries for FAT12 and FAT16 seems to depend on the total size of the disk. For smaller removable disks it's typically only 100-200 entries. I think hard disks were still limited to 512 entries though. FAT32 got around this by storing the root directory _after_ the FAT along with the rest of the data on the disk and could grow dynamically after the disk was formatted (compare to FAT12 and FAT16 which stored the root directory before the FAT and so was fixed in size when formatting).
Yes, I was squirming at the copying of *everything* to root, but then again it is a limited-purpose computer at the moment (the HDD effectively being a much faster floppy). But a simple autoexec.bat that directly loads Procomm could be useful (for the current usage).
I expect the original HDD would have had a startup/utilities menu at boot.
@@SenileOtaku Yes. Often it was a simply type statement with a bunch of lines saying
press 1 plus enter to start procomm plus
Press 2 plus enter to start bla blah blah
With a 1 and 2 and 3.... bat files that end by cls, cd back to root and then a type statement displaying the menu again. Very simple, very effective.
A lot of the early XT machines didn't include 640k. So having a menu loaded into memory wasn't really ideal.
I think the limit for files in the root is 512. In any case, putting things in their own directories makes it easier to find things! I think you get a message like Directory Full if you try to exceed this, as opposed to Disk Full if the disk is actually full.
Love that you explained the difference between MFM and RLL ! Love this video, again. I remember going through BYTE Magazine saying "NO/YES" to the HD controllers because I needed an MFM/RLL for the HDD that I wanted to install.
As a couple of other commenters have already said, if you want to get more than the 30MB out of the HDD you will need to low level it again after changing the jumpers on the controller card. The exact parameters for the 4097 are unlikely to be supported, but you can pick any larger geometry which has less than or equal to 9 heads and less than or equal to 1024 cylinders. Look up the model on the controller card on bitsavers or TH99 or similar and find a manual. The supported types should be enumerated in the documentation.
Yes, the 1024 limitation was something related to the maximum number of cylinders addressable at the time. Tools like DiskManager were able to reconfigure the disk geometry and later go beyond 1024.
Boy this brings back memories.
I even remembered the low level format entry point
Back in the early 90s, I remember connecting an MFM hard drive to an 8-bit ISA Seagate RLL controller and I would get an additional ~30% storage after low-level reformatting the drive.
The downside was that I noticed the drive would run hotter. Someone once explained to me it had to do with how it would run the actuator which was out of spec.
So yes, I would agree from experience that MFM Is RLL and RLL is RLL.
I like this AJ guy! good sense of humour. I love how the software reports runtime with nanosecond resolution :)
Love the B-W Corsiar-2 photo print on the wall. Great show... thank you.
Two thumbs way up for Dave's emulator. When the hard drive on my Kaypro 10 died, I bought one of these. It was close to plug-and-play to install and the old Kaypro restore disks had no problems with it at all!!
I'd give more than 2 thumbs up if I had more thumbs. I imaged my DEC Rainbow disk just in case as it's an ST-251 I believe.
Procomm Plus was an amazing terminal modem software package for DOS! I used it ALL the time back in the day!
Blast from the past - thank you. I remember in the mid-80's buying a HUGE 72MB Micropolis drive and then RLL'ing it to 144MB. An yes, my piers thought I was insane for wanting that much storage. I won't admit what I paid for that (used!) 72MB 8" drive But I was successful and became "the man of the hour" Thank you for the infoTainment. The check is in the mai! Cheers from So.Ca.USA 3rd House On the Left.
This is awesome! Thanks for the heads up about AJ!
17:56 I had an ST4096 back in the day.
Looking it up, I see that the difference is that your ST4097 is RLL, as opposed to the original ST4096 which was MFM. Due to this, the higher number of sectors per track gives us the higher transfer rate and capacity.
David’s MFM emulator’s are awesome!!! I have maybe 8 of them!!! Truly amazing MFM solution!!!
I agree they are amazing. I imaged a DEC Rainbow disk just in case it fails. The DEC Decmate II disk (same type) is already bad and can't be read. I need to get a few more of these to image the drive in my Pro-350.
Man! so many memories came back with this video 1) After removing the screws, the bump that you had to make to the case with the palm. 2) Putting the case back on: You have to make pressure with your hand's palms leaving your fingers free to make an inverse pressure to fit it again. ....Yes, the secuence to format would be: FDISK to read the disk, examine it, chose your partition configuration and after that create partitions. Then Format C:/s /c, being C: for the first hard drive (Select 1? in FDISK) /s to make it bootable (so you can skip Sys C: later) and /c to check for bad sectors.
I just love this channel
MFM, RLL, Voice Coil termos que ficaram para sempre na memória da gente xD
FDISK... Debug + G=100 + Entrar lista de Bad Sectors + etc :D fiz muito isso nos computadores, naqueles anos. A gente instalava muitos HD, apesar do preço ser alto.
Duas coisas atrapalhavam as controladoras: Mau contato (Mesmo sendo novas) e aterramento. Sim! As fezes, só de colocar um parafuso, mesmo que fechando o gabinete, fazia a controladora ou a placa-mãe ficarem loucas!
Vendo a situação, lembrei de um tempo em que alguns conjuntos (controladora+Winchester) ocorria um problema: Após formatar e transferir o sistema e dar boot, dizia que não havia O.S. para dar boot. Daí, tinha que executar o Sys c: novamente. Com o tempo, descobri o que era (não lembro mais).
Bem, grato pelo vídeo!
You can run MFM drives on an RLL controller and, back in the day, be very happy getting 50% more space, but there's a cost. As the drives heat up, you can end up getting more and more read errors since the disks aren't really rated for that kind of density. The drive may last a couple years running like this, then the errors start. I ran into this with a couple of ST-225's. Both drives started with read errors about 2 years into their lives. It got to the point where they were so hot, I couldn't touch the drives after 30 minutes.
I really had to copy the data off of them, but to keep the drives running cool enough for long enough, I had to run the drives under a towel and a gallon bag of ice water. Worked like a charm!
Back in the day, I do recall taking an MFM drive that was about 20MB and worked fine with it's MFM controller in DOS. I replace the MFM controller with an RLL controller to the same HDD then low level formatted it, but I'm not sure what software I used for that it wasn't using debug and jumping to a memory location. It was either a specific software from the drive maker, OR is was a format utility in CMOS BIOS that wrote zeros all over the drive. After that I mounted the drive with FDISK. Then formatted it in DOS (3.3 or 5 maybe?) and it gained 10-11 more MB! I then ran Norton Utilities to set it's interleave (1:1) so it would run a little bit faster.
Interleave, from what I understand, was the number of times the disk would spin before it performed a read/write. The higher the interleave the slower the drive performed. Norton Utilities had a program what would test interleaves for your drive and find the lowest interleave that didn't screw data integrity. If it managed 1:1 (1 rotation : 1 r/w) then you have a very good drive.
Wow! Looks interesting to see BBB as head of some repair tool.
31:30 you could have added a /s after the format command to essentially do both steps at once. Been ages since I used that early of a version of DOS, but I know that worked at least with version 5 and later. Should still work on 3.3 though I believe.
Interleave basically translates to "how many revolutions of the disk are required to read all sectors on a track". Smaller values make reads/writes faster until the controller's ability to read consecutive sectors is exceeded. At that point performance falls off a cliff because an additional rotation of the disk is required between reading/writing each sector. For old 8 bit MFM controllers on XTs, interleave of 3 was typical, but sometimes you could get away with 2, increasing performance by 33%. RLL usually has a higher interleave value because the sectors pass under the heads more quickly (26 per revolution rather than 17).
To format the harddrive and transfer system in one step you can use
A>FORMAT C: /S
but also to make your system disk look a little nicer you could place the dos files in a subdirectory by itself.
A>MD C:\DOS
and then copy the diskettes from A -> C:\DOS
A>COPY 'star'.'star' C:\DOS (RUclips won't show the 'star' character)
to enable the system to find the dos files at the correct subdir you need to add following line to the AUTOEXEC.BAT file
PATH=C:\DOS
Maybe other ppl suggested this too, so I'm sorry if this would be a double entry.
Very nice machine :)
Instead 'star'.'star' you can just type 'dot' eg .
Haha, I liked y'all's aplause reaction to this starting to work!
Post credits sequence?!! Oh no, have I been missing these every time? 😁
This was my first time trying the post credits sequence, glad someone saw it!
Oh man, this reminds me of my qbx days except you are getting hard drives to work. I never fixed a single one, I just got them from the trash working and used them til I found a better system in the trash. I kept trading up and up entire dos systems out of the trash in the 90's until I got up to a 286 processor. I've seen many of those old drives in terrible states of condition making lovely progressive failure noises. I don't miss the 80'88's trying to run QBX with dos 6 on 600k of ram either.
HOWEVER I do love magnetic recording and data fundamentals (TAPE) so your video here is functional therapy for me. Thank you, and I enjoy coming along for the ride!
I did the ST-225 / ST-238 modification back in the mid-80's as well! I do remember the early version of spinrite, to determine the optimal sector interleave (1 = 1,2,3,4; 2 = 1,3,5,...; etc) before reformatting it. it's been so long so i'm not surprised how many people haven't actually experienced the joy of going from 20mb to 30mb on your hard drive!
Love to see it work. Can't wait till you decode the transitions file!!
Loved getting a chance to see these in operation in person
This could easily have been an 80's video showing off the speed of the newly introduced harddrives! 😄
I love it! Nicely done David!
Only you get so excited over something so dull.
And yet, I watched the whole thing on the edge of my seat.
In my old 286 system I had a Seagate ST238R HDD controller. I ran several different MFM drives as RLL with absolutely zero problems.
Congratulations! This entire system is coming together nicely!
Very impressive and compelling episode!
How are you planning to do file transfer? Write an XMODEM program for the Centurion, and then use Procomm+'s file transfer support (which surely includes XMODEM)? I don't understand why different disk block sizes matter if you are backing up at the file level... Flashback to using KERMIT to transfer files from our VAX/VMS mainframe to my Atari ST in 1987ish...
I was wondering the same thing. The serial transfer would act as an abstraction layer, leaving the program on either end to handle any data storage through the OS. Might need something to make a note of any extra attributes the Centurion's filesystem adds to files or translate them to a DOS equivalent, maybe?
PCPlus does support XModem. ZModem and YModem as well.
at 28:07 how many other people were shouting at the screen format C: /s to install the system.
Oh man that took me back 30+ years to playing around with my Amstrad PC1512 and then PC1640 machines. Formatting hard drives, swapping floppies back n forth, trying out copy commands, learning about Autexec.Bat, Config.Sys, XCopy, editing files, trying and failing, then trying and succeeding etc etc. What amazing days they were 🥰
I was 6yo when I played with those things, I can't believe that was 30y ago , time flies.
He called it a compound himself, so we can call it a compound too XD Great video
Awww that's a cute baby bunny. I want more of that. Time for the channel to make a hard pivot lol
This reminded me of the Perstor 180 and 200 series disk disk controller boards from the late 80s (I think). They used a more aggressive RLL coding, which would allow pretty much a capacity doubling relative to their MFM capacity, rather than the extra 50% from the regular 2,7 coding that was normally used. Of course, they also required even better timing stability in the recovered read data signal in order to operate, but by the late 80s more drives were capable of that level of performance.
Awesome video as usual! The baby rabbit at the end was adorable!
Apologies I'm super sick watching this right now I might fall asleep but I promise to rewind in the morning
After a rough night, can confirm I have now rewound and finished the video 😁
This was very cool and the rabbit feeding at the end was the jerry on top for me.
Sys doesn't need it to be freshly formatted. It needs a very specific place in the drive to be empty to place the system files in that specific location. If that specific space isn't free then you get that error regardless of how much free space the rest of the drive has.
Lol, I just knew AJ from Knight Rider Historians. I had no idea he was into vintage computing.
LOL SAME!!! funny how worlds collide. Though I guess AJ is the one who is reverse engineering/rebuilding a lot of the vintage electronics in the Cars.
@@Nebula1701 Yes, it's true! Not just the cars, but reverse engineering a vintage computer was the key for us finding the Semi!
You need to copy all the DOS files into a directory usually called "DOS", because the number on entries i.e. files in the root directory is limited. The error message is a bit useless since it will only say something "not enough space left..." when it actually should say "not enough file table entries left..."
It's either that, or old versions of sys weren't able to move stuff around to make space for IO.SYS (of which at least the beginning needs to be in the first sector, IIRC)
@@seritools Ahh yes, that was the reason, I remember now. Similar for Windows: KRNL386.SYS can be anywhere on the drive but must not be moved. It was loaded using a sector table written to the boot sector compiled during installation. If the checksum didn't match then you got "Cannot find or load KRNL386.SYS".
The limit is 512 items in the root directory, which includes hidden files and subdirectory’s. I know this thanks to having to recover a customer’s system after they saved everything to the root…
Funny how I haven't done a lowlevel format of an RLLor MFM drive since the late 80s, but I still remembere debug g=c800:5. Crazy what the brain stashes away.
I am loving your channel. It's got so much fantastic content. /spins propellar hat.
I have formatted a 10 meg I believe was a seagate mfm drive from mfm to rll on a ibm xt 4.77 . It was to gain more space from that drive it would be 14 megs or something after converting to RLL
I had no idea Basic was invented in New Hampshire! As a native, I recognized the historical markers. So cool!
Just love this detective work!
Of course you need to SYS the disk as countless others already told you. But another thing that got me on edge... you do know that DOS since version 2 can do subdirectories and that you can place a "SET PATH=C:\DOS" into the AUTOEXEC.BAT? Maybe a CONFIG.SYS with a few lines, like "DEVICE=C:\DOS\HIMEM.SYS" to liven up the place and all should be fine. ☺
Brings back memories
a:\format c: /sys
is a shortcut to put system files onto new boot drive in a single line when formatting
Just /s is all you need but yes, pretty much. 🙂
Cool video, i'm actual working on an "WANG Professional Computer" (It is an MS-DOS machine witch is not IBM compatible and use ist own card interface no ISA connectors), with some problems with the comunication with the hard drive. It's an MFM Drive, spins up normally and runs through it's self test and the drives service manual says, when the powerlight stays on (What it does) and doesn't blink, the drive is in ready state. After 1 minute of computer selftesting it says "booting from winchester disk..... failed. After that i couldn't test anymore because the damn RIFAS goes up in smoke. But befor i powered it on, i dumped all the ROMs (safety first).
As a computer nerd in the 1980's, I did find that you could format a Seagate MFM drive with an RRL controller to get about double the drive size. However, often after a few months the MFM drive will crash and now all you have is a new door stop.
When you run the initial format command, there is a /s option which transfers the systems files. Similarly, there is a dos SYS command for transferring the systems files after formatting is complete. I don't think it will boot from C: if you just copy *.*. That's fine for copying the dos files there are 3 files hat have to be placed on specific sectors and that why you have to use the sys command or use format with the /s option.
ST238R, my first HDD!
Wow. References to sector interleaving. Haven't seen that sort of thing in a very long time. BTW, IIRC, you can type "format c: /s" to format the drive and make it bootable in one step instead of running sys after running format.
Whilst in FDISK you can check that the partition is also made active (usually option 5), then format c: /s /q (/q quick format if available)
I love watching shows from the old days, And they speak about computers. This makes this clear to me.
I had a MFM drive as well as RLL drives way back in the 80's and I don't remember exactly what I was doing with them (maybe copying one to another or swapping them out) but the drive (I don't remember which one) just started to make all kind of noise like the write head was just bouncing back and forth off it's stops. I then realized that it needed to be mounted in the chassis because it used it for ground. Just FYI if you have the same kind of problem.
Usually format C: /Q /Y only write an empty File Allocation Table and does not ask for confirmation. This is time saving not to cycle through writing all the cylinders.
@bubullenoiraude you lived in a dangerous fast way! At company level I cannot afford any errors to show up unexpectedly so format without checking for bad sectors was a big NO, No for me and my work.
MFM and RLL drives, now that's a while ago!
I can't remember the details, but I remember when RLL drives came about. Or was it the controllers that started supporting RLL? Frankly I can't really remember. I do know that the same drive could be formatted using MFM or RLL and using RLL it gained something like ten or twenty percent capacity. at the time this was a big thing.
Other things you had to test was performance related. The formatted sectors on a track on the disk was not necessarily ordered 1, 2, 3 and so on in series. Usually you inserted interleave sectors, so the order could be 1, 8, 15, 2, 9, 16 and so on. This was done as the computer, card slot or the disc controller couldn't read the sectors if they were just stepped up by one every time. Then the disc had to spin an entire revolution for the controller to read the next sector. But with the right interleave it was ready for the next sector when the interleave sectors had passed under the read head. With an interleave of 0 a complete track could be read at one revolution but it was very uncommon you saw a computer able to handle that. An interleave of one meant that it would take two revolutions to read the entire track. Each time you added a interleave sector the necessary revolutions rose by one, so you wanted to use a interleave that was just big enough that they computer could handle it.
Another thing was the data listing defect sectors on the disk. This was used to map these so they wouldn't be used when accessing the drive. Most of the time they came on a separate paper with the drive, but often they were also written on the label of the drive. Some times they were rather long and other times there were just a few listed. This data was entered when doing the low level format of the drive, this was also when you set the interleave so that it was used for the format when installing the OS.
What is interesting is that so much of this has become antiquated knowledge. It must be at least 20 years since I low level formatted a HDD, perhaps 30 years.
Idk why but the "technical difficulties" with the piano brake down killed me I wasn't expecting something that random upbeat and fast paced in the middle of all the interesting long winded info
I'm not saying I don't like the long winded explanations just that that's what I'm here for. I'm not the best at talking for sure 😂
Data recovery specialists! Nice work :)
HI KERI,.lol,. how r u ? this is really interesting,. its like the toddler years of computers,.lol
That's an incredible tool!
Thinking way, way back, and with some uncertainty: a handy keyboard thing is the upand down arrow keys. From the command prompt, type UP-arrow and it displays the previous command line. DOS keep a few lines available. Browse through them with UP and DOWN arrows. When you get one you want to repeat, press enter. If you want to edit it, use RIGHT and LEFT arrow keys.
This should work for the Linux OS on the BeagleBone, but does not work for DOS. In DOS you can use the F3 key to bring up the previous command.