I got a nice message from the person who made these original disk images I used to make this work, so I'll post it here. (And it appears that RUclips did eat the comment!!!) "I'm the guy who made the crappy KryoFlux image on archive.org -- awesome video, and I'm glad you were able to make it work! Back when I imaged the disk I was just starting out with KyroFlux and was only familiar with IBM-formatted stuff. I actually found those SSB disks at a swap meet after I had bought the KryoFlux. They were sitting in an old cigar box, and the vendor wanted $15 for them. I hadn't the faintest clue who Smoke Signal Broadcasting was but found DOS-68 and the company's name enigmatic. It turns out I was lucky that I purchased them that day, as all the other electronics-related stuff that the vendor had that day (loose PROMs, ancient LEDs, breadboards and a TRS-80 Model I monitor) were gone the next week. Sorry for the headache that my 360 RPM 80-track drive caused! At the time all I had was a TEAC 55GFR, which I did all my PC disk archiving on before I found the SSB disks. I was aware of the issue with reading 360 KB disks written from a 1.2 MB drive, but thought that flux imaging would benefit from the finer pitch of the read head of a 1.2 MB drive, in the case of bit rot and other bad sector errors. I never realized that crosstalk is a potential problem! Really I was concerned with the age of the disks (almost 40 years old when I found them) and the potential for sticky-shed syndrome to eventually ruin them, so I just wanted them backed up by any means possible. I was amazed that KyroFlux software detected no errors when interpreting the data as FM encoded, and putting the output disk image into a hex editor looked promising with all the DOS-68 filenames and message strings, but without a 6800 system or experience with emulating one I couldn't really put those images to the test. I'm glad it worked out perfect, even though it took some effort to correct my mistakes. I still have all the disks, including the FORTRAN compilers, and will plan to recreate the flux images with a 300RPM 360K drive eventually (right now they're in cold storage). --@fleaslikeus"
Great job! Any disk image is better than no disk image at all. :) All the data was there and it lead to a bootable disk, albeit with some work, and made a vintage OS boot that would otherwise have been lost to time.
(Sorry to reply here, YT buries comments atm.) - How about some SK*Dos, OS-9 and/or Unix System V, next? They all run on 6800 type processors, and some have versions specifically for the SWTP computer. (see bitsavers manuals on Star-k for SK*Dos) As for why SK*Dos, it was made later, and specifically was more compatible with what would become MS-Dos As for why Unix V, Unix is not mentioned on the channel often, but its usability was far greater than dos, Incredibly more at the time. Most modern code is still compatible. As for why OS-9, its a much later OS, that was also found on X86 hardware and some versions even offered a GUI called GEM. (You could use this even over serial with a little work!)
Brings back memories. I built my SWTPC 6800 from a kit. Soldered all the components in the motherboard and 4K ram board. I didn't have a floppy drive, I used a Teletype ASR 33 to load basic from a paper tape.
This operating system makes MS-DOS, CP/M and the Linux command line look like a miracle of user-friendliness and verbosity by comparison. What an amazing piece of history.
Done when memory was expensive, so every bit counted. No room to put fancy error messages, or even error detection code for odd cases, as you only had the 8k of ROM available to use, and likely were already trying to put an entire extra kitchen sink into it as well. Thus all the optimised code that reused routines as much as possible, or even some that did different things depending on where you entered the subroutine, as the CPU would always execute the first byte on entry as an opcode.
@@SeanBZA I played a little bit with some super optimization on a BIOS I wrote for the Sanyo MBC-55x series - it's 8088 based but no BIOS in ROM (normally it loaded the BIOS functions along with DOS and ROM just had a basic bootstrap loader). I found some interesting tricks like using a jump on parity to make a loop run exactly twice and save a few bytes, using a mov opcode to skip 2 bytes of data that served as alternate instructions for another entry point (saving one byte), shrinking init code down by making an initialization list of port addresses and data, and then a bit of trickery to make different sections more similar to each other so that the UPX compression could shrink it more (due to the memory layout, I actually had RAM to spare and wanted to use it to shrink the on-disk size). Optimizing for size at all costs is definitely an exercise in doing all the bad things you normally should never do when programming.
Wow! This swtpc 6800 series for me was a great trip down memory lane. As a student I was designing my own 6800/6809 based computer systems as well as peripheral and DRAM cards. At that time I was still working with 8" floppy drives. I also built a 128kByte paged EPROM card that contained my editor, assembler, linker and a hw debugger. I was actually building these EPROMs by using a cross assembler on a CDC Cyber mainframe, printing to paper tape, taking this to the university and reading the tape using a teletype into an eprom programmer. Well, life as a programmer was hard at those times ;-) Thanks a lot for bringing back all those memories! 😀
It's funny you said, "I'm more of a hardware guy, and this software stuff is a bit over my pay grade." I feel the same way watching you, except in reverse. I'm a software engineer trying to learn how to repair old PC hardware (to keep it running)... you're way beyond my pay grade!
Back in the bad old days everyone was a hardware AND and software guy! The two went hand in hand. Assembly/machine code is the manipulation of logic gates. Every programming language since then has been just an abstraction of that process.
@@AndyGraceMedia John von Neumann, at least early on, considered the emerging assembly languages a cop out and was really not a fan. Any abstraction comes at a cost to clarity of what's actually going on with the machine, and when you're trying to debug a library-sized computer... Yeah.
I'm in between. I understand enough of both aspects to follow and understand pretty much everything, but if I was in Adrian's shoes I could never get any of this going on my own.
@@GdotWdot I love that guys from that time were like “if you can’t keep track of your jump points you’re not a real programmer, assemblers are pointless”
I actually knew some people back in the day who had these SWTPC 6800 machines. Sure it looks clunky and simple today. But back then it was the best thing ever. Watching this series is a real trip down memory lane.
ive been watching this channel for a couple years. i know i have learned alot because i can always follow along logically with what is going on, even if i dont understand the 'why' of a ton of it, nor could i recreate it or explain it to someone else. but the crazy thing is that despite that, and despite the fact that i rarely watch videos 30-60 min long, i always watch these videos in their entirety, never get bored and enjoy every minute. keep doing what you do adrian, you have my support.
agreed - I probably understand far less than most here (I’m more familiarized with vintage channels like Mr. Carlson’s Lab, and I’ve been studying Ben Eater’s more basic videos recently after deciding to really learn 8/16/64-bit electronics) but I can still follow the flow of these videos. My aspiration is to become a hobbyist in my own living space one day! (but I suspect I’ll be starting simple with radios and VTVMs and such… it’ll be some time before I repair my first computer!)
ive also been watching for a few years now i started my pc fascination with my schools old acorn systems(uk) then primary school bought a win 95 machine with a cd rom for £1000 there was a whole school assembly too then in high school back to acorns then finally windows xp as we leave thanks Britain . left school built my own win xp machine ive been tweaking ever since anything pre 90s is pure pc archeology to me keep up the good work guys
I have to agree with the original poster. Adrian, please stop feeling like your videos are too long. They're not! If someone feels like a video is too long, they can always skip ahead.
The problems you worked through demonstrate just how far we've come in terms of sophistication on not only the hardware, but also the software in the systems we use. Troubleshooting these old systems is definitely an adventure!
I think the delay on the floppy disk controller card, either software or hardware, has to do with some older floppy disk drive, as the spindle motors on some of them were huge and heavy, so the controller is simply buying the floppy disk drives time to stabilize in term of speed of the spindle before it even bother to read the floppy disks, mostly to prevent the CRC checksum errors while reading the disk that's not in the alignment of both rotation speed and MFM subcarrier frequency. Modern floppy disk controller doesn't do that anymore as we were using the final 3 inches floppy disk drives whose motors were light so it spins up right away. So, protip; for those who love computing history and uses 5 inch floppy disk drives, especially those modified to accept the classic MFM datalink, I recommend to incur the three seconds hard drive boot delay in the BIOS, so you can give those classic drives time to stabilize before booting up the OS on it or do anything with it otherwise.
What I love about this is that even though the original backup was made with the wrong drive/wrong settings, it was still enough to turn it into a completely usable, bootable disk (with some extra steps). Just goes to show that when it comes to data preservation, doing something is always better than doing nothing. Even if you don't get it completely right it can still be useful to someone in the future!
I am a older gent that used to loved working on Computers before IC became too hard to work with. Watching this series has given me an idea to recreate this computer with newer parts... and by that I mean ATX power supply, use 50 pin cable style connectors for main bus and 30 pin for IO bus. I am starting with the base board (MP-B) and go from there. Plan is to design new circuit boards that use the new tech such as you using sram, it could all be on a very small board with a single ram and a few support curcuits. This was a great series and who knows... someday I maybe able to make the boards I design available to other people that are interesred in this sort of thing. Thanks Adrian
Computer archaeology in action! This was a fascinating series - really helps to see the complexity of simple procedures we took for granted in later machines.
Most users of computers these days have no clue what the 70's and 80's were like. Today Google, Siri, Alexa and the like can usually understand your spoken words and search or run commands for you. You don't have to memorize cryptic commands to get anything useful done.
At least *micro* computer archaeology. There had been computers around for several decades, before we got modern VLSI designs like this, that fits on a desktop.
Your dogged determination to fight through all that disk track .. etc stuff is amazing. And to have multiple faults (card chips need reseating, ribbon cable problems, disk sector issues, termination issues etc) and eventually end up with a DOS prompt was amazing. The tour through the various commands was wonderful. Made me appreciate how easy it became for people like me who started with msdos. Thumbs-up !
CPM and MSDOS/PCDOS were quite the advancements back in the day. Then came the GUIs, and now people rarely see command prompts, unless they are programmers or work on servers.
I have often said, "I miss the 8-bit days. Back then, there was absolutely no doubt that you were the superior being." Well, this is to those 8-bit machines what the 8-bit machines are to us. xD It's super cool to see such an ancient and even more rudimentary machine actually running. Huge kudos, Adrian, for your efforts and determination to get this beast chugging along again!
Being able to essentially restore a more stable copy of the original disc is great. It was cool to get the breakdown of how you slowly pieces bits of things together to get a workable solution.
I will never in my life do anything like this, even if I would fantasize about it. Thanks for letting me do it vicariously. It's so important to preserve these things.
2 года назад+3
Just a small note on bulk erasers. In the instructions for audio media, I recall that they said to turn on the unit when far away (both arms length) from the media before bringing it against the media to erase. Same thing before turning it off: take it away from the media before releasing the switch. The idea is to avoid creating magnetic pulses that would magnetize the media when operating the AC switch. Thanks!
In the IMD docs it discusses the potential need to format a disk on the target machine then copy the IMD imaged disk to the locally formatted disk when writing to an IMD written disk corrupts the disk. The issue you saw is consistent with my experiences with IMD as well. It may be related to the R/W Gap and/or the Format Gap settings in IMD.
It’s pretty interesting how it’s basically bootstrapping modulation tolerances, using asymmetric tolerances for reads and writes, until you finally get something nice and in spec
I love the mentions back and forth between Adrian and Clint (LGR)! They both got their own thing with a lot of mutual respect. Us nerds got to stick together!
Fifty years from now, someone will be trying to access an old laptop by using the FO to SATA version of Kryo and they will be adjusting clock times to match the solid state chips just as you adjusted the rpm controller of the disk drive. Fascinating video. Bravo on your hard work paying off. Little by little. Thank you for the upload.
You are a legend. These videos bring back memories of Amiga 500 I used to own, and bringing computers I've never seen. That intuitive problem solving is top notch, because old hardware is so dodgy, you never know if it's a bad connection somewhere or dirty disk drive. Back in the day, we used to "make" SD-disks to DD-disks by making a nothc to the diskette, as it fools the drive to think it's a double density, and it worked with better quality disks. Try that one sometimes. Greetings from a nerd from Finland!
Well done on the detective work. One thing that I learnt the hard way with my TRS80 Model 1 is to remove the disk (or at least open the drive door) before power up or down as the “splurt” of data down the cable can corrupt the disk. I’d be doing that here as well…
Turning the system power on or off would push a glitch through the drive heads, corrupting whatever was under the head, even without the drive spinning. I glitched a few disk sectors on my Model 1 from that back in the day. I quickly learned to keep the door open when not using the disk.
Amazing work. When I first saw this computer I didn't have the slightest clue how it even operated. After watching your videos, I still don't have the slightest clue but I'm glad you got it working! Seriously cool to see it functioning how it did back in the day.
I'm not too experienced with these old systems, but I DO remember that it was VERY easy to damage those discs from power spikes. Hence, it was always standard practice to put the disc in a few (3) seconds AFTER switching the computer on and to NEVER remove a disc while the drive light was still on. Also, it was a thing to wait 5 seconds after a forced shutdown to allow for any memory to be completely flushed before switching on again. That procedure does eliminate some spurious errors.
A genuinely amazing bit of real digital archeology, very impressed with the flopy disc salvage. As was pointed out, this was in the age when everything was hacked together, one step up from punched card or tape. Reminds me of my early days on a Research Machines 380Z!.
Awesome Adrian, well done on getting that going! And thanks for the tour of DOS - most interesting. It does seem to work at a lower level than more modern systems; I worked with CP/M in the 80's and that was a bit like that.
fantastic work, and a great addition of the preservation of this hardware and software, its great to see that MS-DOS wasn't the only game in town, an addition to other DOSes like TRS-DOS and CP/M.
MS-DOS' disk structure was actually fairly primitive compared to what was available on other much earlier systems. Good old TRS-80 MI/III used free space bitmaps, the concept of block allocation runs, different levels of file access by password, spanning directory entries for extra metadata storage, while MS-DOS had crude memory hungry FAT chains and that was about it. It wasn't just TRS-80 DOSes either, there's plenty of examples of more advanced structures. In many ways MS-DOS was actually a backward step.
This is a super-interesting example of how even early 1980s disc systems are essentially related to earlier devices. No-one was reinventing technology (even IBM), these were evolutions. I guess that is largely because Shugart mechanisms were the only game in town.
Amazing walk through of this system (all parts in the series). I know so little of those very early computers, and to see you progress from receiving it to a functioning 2 drive setup like that is really eye opening! All that sleuthing to get the drives working, imaging & booting - very impressive! Again, fantastic series. Thank you.
It's fascinating to see a time capsule like this getting preserved, and thanks to the other videos on the channel you can get a sense of where this machine fits in on the computing timeline. It's not something I'd most likely ever get to see outside of a vintage computer fair or museum, so thank you for get this old timer up and running in the highly educational way that you do. I used to sell antique Ford auto parts, and like a Model T, the SWTPC has a certain type of charm in its simplicity, but also something I would never ever want to own. :)
Back then, I purchased for a stagering $10K , my first TRS80-1200, 2 floppies, 10MB HD, built-in screen, with a Dot Matrix Printer. When booted-up, it showed DOS, ready to accept commands. This video brings me back in time. I make me feel so weird when I compare with today's technology. That's how I started with computers. Evolution is such a weird thing. Thanks for posting 🎉
A long time ago, I used DOS for a long time. From the early version to last. I started using it much later than others at the place I worked. we created menues and was able to use it at our office. When i first started working for a company who used DOS mostly. Well, us in the back of the business. I was able to catch on very fast. The guy who brought my computer to me, I quikly programmed a menu option that we used on our network. He was quite suprised I figured it out. Well, I did a lot of research. And from there, I started working in IT jobs only. I was living inTexas when I started my IT career. I have made lots of money in that field of work.
Having my own computer in 1975 was just an impossible dream. By 1981 we had CP/M with Assembler and BASIC on a Z80 at school... but I still had to dream of that Fortran compiler. That repair command takes me back to college.... replacing BASIC's error messages with our own "funny" versions.
I have to chuckle because I first heard about the stunt as a child. My mother was taking college classes and had a prof who/and/or students that had replaced the error codes in some of the university's terminals, where a piece of the exploded death star was on display circa '78.... My actual interest at the time is obvious, but I never forgot the "naughty" error codes bit.
These DOS-68 really show how far things had come by MS-DOS days, they also show quite well DOS evolutions (when you move up the version tree, _and_ start using stuff like FLEX). Thanks for putting in the time to get a good outcome.
Thanks for sharing, really nice research, I wonder how much time was spent on it to get it working. Great job. OSs from a preDOS time are barely known today, and its really nice to see how it works. And last but not least, its great to see a good technical explanation of how system works, not just a video when somebody takes an old machine and just start gaming.
Fascinating! Some excellent detective work there and entertainingly presented. I remember seeing adverts for these machines back in the day but have never seen one working.
Hey Adrian - Thanks for the trip down memory lane! So many memories form back in the day of trying to get this gear to work. But more importantly all the people who were there. We all spent a lot of hours helping each other. Lots of pizza, beer and good friends!
I had a disk drive I bought from SWTPC. It used 8" floppies and plugged into a smaller card at the rear of the computer. I think I paid $1200 for the drive and controller. I didn't know about DOS68, But I did have a Smoke Signals BASIC and Smoke Signals word processor (not GUI) I took my system to an attorney's office and demonstrated the word processor. I also had a Xerox daisy wheel printer that I used as a terminal. The clerical staff at the attorney's office weren't happy. They thought I was trying to replace them with a computer.
I was thinking about daisy wheels the other day; 3D print the "wheel" an RPi0 to control a hammer that smacks it against Some-Kind-Of-Ribbon. Pi Pico would do the job. Or robot finger, more RPi, moving across electric typewriter. Write a "driver" that converts ASCII to finger presses.
@@andrewkieran8942 yes I later made a deal with a computer store owner. He had a customer who needed it and I ended up with an original IBM PC about a month after they were introduced. I also wrote some software in the exchange.
@@stalinvladThere were devices that could be attached to typewriter keyboards, effectively adapting them for use as printers or teletypes. These were controlled by a computer and used electromechanical plungers to actuate the keys.
My friend's co-worker was totally CLUELESS when it came to computers. He asked him for a copy of a certain floppy. You guessed it, he Xeroxed the floppy itself and placed it in a (physical) folder! :)
I was about to ask if he even stuck the floppy on the side of a metal desk with (you guessed it) a magnet. Remember: closing all windows doesn't mean to literally close all the windows in your house. That, and your CD drive tray is not a cup holder. 🤣
I saw that computer advertised in so many issues of Popular Electronics that the SWTP logo seems to have been burned into my childhood brain. There was no way I could afford it of course.
Absolutely brilliant... you are getting amazing at working through the problems that confront you in retro computing. I have to watch this a few more times to understand exactly what you figured out along the way.
2 года назад+2
Awesome video! That machine deserves its own pillar of fame with floppy's and terminal to show of what it can do!
Adrian, you make an excellent point! Always format the disk you want to use on the drive you want to use it with, and then move that disk to the other drive to copy the file to it. Drive interchange will bite (and cut) you every time!! Thanks for going through all these steps for everyone! PS. I'd like to hear more of the heavy technical troubleshooting that you went through, with the oscilloscope, etc; I'm sure others would as well. maybe for your second channel... Just a thought!
I am also one of the people who dump all disks with an 80 track drive, as 80-track images. Simply because if the disk is marginal, you can get some additional flux info from the neighboring (half-)tracks which might help in repairing bad sectors. In the end, the more data you have, the better. All the problems you describe (picking 40 tracks from a set of 80, converting the RPM to proper 300RPM, etc.) are all things that KF's dtc.exe does with the flip of a single switch. So for me, the value in having more data dumped from the floppy trumps convenience when trying to write it back... Also, I think most of the confusion from DTC comes from the fact that the order of parameters is relevant. I get tripped by this too, all the time. So it might be that your switch to only read/write side 0 is not getting picked up. Try swapping the order around. It's the file name parameter that is relevant, so if you have that at the end, try to move it to the front, or vice versa (I can never remember which is correct)
What a fascinating video and I can appreciate just how much work you put into this to get it working. This is a really interesting machine and a good insight into how OS development went, when this basically starts into nothing more than a machine language monitor. Thank you for sharing your journey to get this fully working again. You must have an amazing collection of working vintage computers by now.
I was on the edge of my seat the whole time! What a journey! I'm glad that you ended up with a fully working system, and with that assembler included in the dos disk, the sky is really the limit now!
FYI, the reason for the cable twist is simply so IBM could ship all drives configured as drive 1 (second drive) and not need to stock a separate part number, or to deal with extra documentation and the chance of someone doing it wrong.
Ah, back in the days when not only was it possible to have absolute knowledge of how your computer worked, every single feature, every IC, port, memory address, etc, but it was also mandatory.
I love your transistor radio sitting there so you can listen to the RF noise the system emits. Back in the day there was one permanently sitting behind my TRS-80 Model I.
As for trouble reading/writing on a disk formatted on a different drive (but could read/write disks formatted by itself) this was extremely common back in the 1980's with Radio Shack Shugart drives ..We would tell the person to bring their computer with drives into local Tandy Computer Repair Center and have drives aligned ...which what i would do as a Repair Center manager... The process would be using a specially made floppy disk from Dyson there is a signal written at the very edge of the track 16 and 17 and another signal written on the edge of 17 and 18..We would set the drive on track 17 and with an O-Scope read the signals making sure both signals were equal... commonly called setting the head azimuth this would make sure the head was directly over track 17 (center of the disk) ..
I can barely hold on by the skin of my teeth to what you talk about, Adrian. Sincerest kudos for breaking most of this stuff down for those of us that lived during that era. Even though I took classes in three different assembly languages, COBOL, JCL, Pascal and C, etc., I haven't kept up with it. Hardware and electronics, and tube amp repair is something I dabble in, so much of what you do in your videos, blows my mind. Thanks for some crazy interesting topics. I only wish you could spend more time on the Apple ][ series, and breakdown the internals of the Apple ][+ and //e, memory maps, the & command, etc. Though there are a lot of Commodore users in the world, I kinda get tired of having SO MUCH done on your channel regarding Commodore. But, thanks for everything you do, regardless. Awesome brain!
I love this PC Archeology that you have been doing lately. Today's 64-bit era is very easy to the point where most people have an internet connected device, and take it for granted. Seeing these old 8-bit machines and what was necessary to make them function show how much we take computers and information technology for granted. Back then you really had to know your stuff to do even the most basic tasks. Great stuff, keep it coming.
Well done! Never read or otherwise learned about Smoke Signal Broadcasting before, despite being interested in computer history for many years. It's good to see this history preserved.
You do have what was referred to as flippy floppies. We used to keep hole punches for punching holes in paper around to make our own flippy floppies, You gently lift the cover away from the recording medium, punch a new hole 180 degrees from the original hole into the soft cover on both the front and back of the diskette. This gives you a new index hole on the opposing side, next on the opposite edge of the floppy you also cut a new write protect notch to mirror the original notch. Now both sides of the floppy can be written or read on a single side floppy drive by simply flipping the diskette over./ The data on the back side of the floppy is recorded backwards and the for can not be read on a double-sided drives second side. To read the back you must flip the diskette over even in a double sided drive. I never did figure out why some genius did not figure out how to read the data, and reverse the bits/bytes in software to make them readable.
The steprate in that 1771 floppy disc controller is hardwired but it can select 4 different rates. There is a "seek track" command that the OS sends to the controller, and 2 bits of that byte specify how fast it should step. I don't know DOS68, but likely the only way to send another steprate to the controller is to patch some byte in the DOS image. OSes developed a little later (e.g. NEWDOS/80 for the TRS-80) had disk parameter tables that you could change to adapt the steprate to your drive.
In another comment I read this, indicating that DOS68 also had such a feature to adapt the steprate: Note that as supplied, the system disk is shipped to boot⠂ with the slowest step rate and the longest dealy time after⠂ select. Your disk drives most likely can use a faster step⠂ rate; thus, please ensure you establish your boot disk as is⠂ appropriate for your system. Read about SYSTEM (STEP=n) and⠂ SYSTEM (DELAY=) in your user manual. Also use the proper⠂ BSTEP= parameter when you format your working system disk.⠂
Of all those machine you have show on the bench, I think this is the most interesting machine imho., because it is so much different than newer more standardized machine. Really interesting to learn about how this machine works.
6:40 I actually saw some 5.25" floppies which has cutouts for the index holes on both sides, so you can flip the disk in drives which use the index pulse. IIRC they were some German made disks.
Well done! I‘d transfer software via the terminal. You can cp the asm code to a file (pasting the asm in the terminal will save you typing it) and compile it on the 6800. I used to work with similar hardware in a „company“ that didn’t replace their computers as long as possible (due to it being „perfectly fine“ and „normal“ to use such outdated equipment to control and monitor a process). In the end there was a catastrophic fault and I got it updated. Reverse engineering the software was quite a bit of work, but it was required to validate the new system provided by the vendor had the same functionality and especially the calibration routines where unaltered. What a trip down memory lane.. Thanks!
Great job getting that box booting DOS68. AFAICR, this is the first time I've heard you mention the KyroFlux in a video I've seen. It is a very useful device to help bootstrap some vintage machines along with that other program that you mentioned. I have an old original CP/M 2.2 8" diskette (somewhere). I never had a system up and running to let me back up its contents.
I was a senior lab tech at University of North Texas computer lab in the 1980s. Computers with hard disc drives were scarce. A PhD student was finishing his dissertation on a dual floppy IBM PC. He tried to save and got the Error writing drive B Abort Retry Fail message. To his credit he came to me instead of turning the computer off. .Drive B had an error. So with the computer on I unplugged the A drive and swapped it with the B drive and selected retry. It saved his dissertation. All the connectors are low voltage so if you are careful with the connectors, it will reset the drive once it gets power. He graduated and the lab got pizza at night, my shift, for the remainder of the summer. I miss this level of computer technology. Faster great but very little is repairable by the average person with the newer technology
FYI, the Kryoflux is absolutely the device NOT to have. The AppleSauce disk imager is the tool of choice for those that have serious work to do and don't want to worry about being mistreated or threatened by the company that sells the device.
Great job on getting the ancient technology to work. You have patience! To those who just want to see the floppy drive working properly FF to 42:39. Thanks!
I remember in old times everything was so complicated and delicate, it was difficult to reproduce success stories and you had to try over and over till it worked again for a while.
So, I can tell you what happened with the disk: the issue is that the Kryoflux RAW files are flux-level files, which means they contain a fundamentally analogue recording of the intervals between each magnetic flux transition on the disk. As you discovered, these can't normally be written back. Each RAW file actually contains the data from about five to ten revolutions of the disk in one long stream, and it's not split up into sectors or records. If you're using flux-level hardware, then what you have to do is to decode this into the actual data --- a sector image --- and then encode it _back_ into flux data. This will contain one revolution of data, so it'll fit on a track. It also contains nicely aligned pulsetrains without all the analogue noise that you get when reading the disk. This is basically what you did by creating the IMD file (which is a sector image), and then writing it back with ImageDisk; in this case, of course, the FDC encodes the sector data into flux data in hardware. But if you use flux-level hardware then things are much more flexible. Reading and writing 40-track disks on 80-track drives totally works (on reads you skip tracks, or just read both tracks and deduplicate the sectors after decoding; on writing, you write even track and magnetically erase odd tracks); and drive RPM becomes largely irrelevant (you can write 300rpm formats with a 360rpm drive no problem --- just change the flux pulse timing!) The bad writes I have more trouble explaining, but I'm going to guess that something was wrong with the sector spacing so that writing one sector would erase part of the following one. Drives take time to turn the erase head on and off, during which time the disk continues to rotate, and there's typically a dead space between records on the disk to provide a safe space for this to happen. If the sectors were too close together, it'd totally be possible to accidentally erase part of the sector header of the next sector on write, even though they'd read fine.
Knowing absolutely EVERTHING there is to know about CP/M made me think I was the smartest guy in the room. I was wrong, and lay down my sword before you. You Sir, have bested me.
it's great you took the time for this early DOS walkthru on what was a bit of a long road to getting this thing to boot right. For while I am into retro stuff...the 6800 is a bit too old and bit to into the hardware side of things for me to dig into but I liked seeing the DOS and the differences between say it and DOS 3.3 or even CPM for example.
Great job Adrian! Learned a lot and enjoyed it. Fascinating. Thank you for making this video. I now see where Atari DOS inherited the 'binary load' ' binary save' and 'create mem.sav' features.
"It's probably not a problem...probably." Adrian, don't you know that's exactly what the scientists said just before the Resonance Cascade in Half Life 1? :D
Thank you for doing all of this research and work, made a really great video! Both interesting and educational. And such a great preservation of information for the future.
I got a nice message from the person who made these original disk images I used to make this work, so I'll post it here. (And it appears that RUclips did eat the comment!!!)
"I'm the guy who made the crappy KryoFlux image on archive.org -- awesome video, and I'm glad you were able to make it work! Back when I imaged the disk I was just starting out with KyroFlux and was only familiar with IBM-formatted stuff. I actually found those SSB disks at a swap meet after I had bought the KryoFlux. They were sitting in an old cigar box, and the vendor wanted $15 for them. I hadn't the faintest clue who Smoke Signal Broadcasting was but found DOS-68 and the company's name enigmatic. It turns out I was lucky that I purchased them that day, as all the other electronics-related stuff that the vendor had that day (loose PROMs, ancient LEDs, breadboards and a TRS-80 Model I monitor) were gone the next week.
Sorry for the headache that my 360 RPM 80-track drive caused! At the time all I had was a TEAC 55GFR, which I did all my PC disk archiving on before I found the SSB disks. I was aware of the issue with reading 360 KB disks written from a 1.2 MB drive, but thought that flux imaging would benefit from the finer pitch of the read head of a 1.2 MB drive, in the case of bit rot and other bad sector errors. I never realized that crosstalk is a potential problem! Really I was concerned with the age of the disks (almost 40 years old when I found them) and the potential for sticky-shed syndrome to eventually ruin them, so I just wanted them backed up by any means possible. I was amazed that KyroFlux software detected no errors when interpreting the data as FM encoded, and putting the output disk image into a hex editor looked promising with all the DOS-68 filenames and message strings, but without a 6800 system or experience with emulating one I couldn't really put those images to the test. I'm glad it worked out perfect, even though it took some effort to correct my mistakes.
I still have all the disks, including the FORTRAN compilers, and will plan to recreate the flux images with a 300RPM 360K drive eventually (right now they're in cold storage).
--@fleaslikeus"
Great job! Any disk image is better than no disk image at all. :) All the data was there and it lead to a bootable disk, albeit with some work, and made a vintage OS boot that would otherwise have been lost to time.
All of this is amazing. Even if the image wasn't done the right way, it still saved the disk in a way that actually saved the disk. Great work.
Try putty for Connecting for this type of computers
"And it appears that RUclips did eat the comment!!!"
(Sorry to reply here, YT buries comments atm.) - How about some SK*Dos, OS-9 and/or Unix System V, next?
They all run on 6800 type processors, and some have versions specifically for the SWTP computer. (see bitsavers manuals on Star-k for SK*Dos)
As for why SK*Dos, it was made later, and specifically was more compatible with what would become MS-Dos
As for why Unix V, Unix is not mentioned on the channel often, but its usability was far greater than dos, Incredibly more at the time. Most modern code is still compatible.
As for why OS-9, its a much later OS, that was also found on X86 hardware and some versions even offered a GUI called GEM. (You could use this even over serial with a little work!)
Brings back memories. I built my SWTPC 6800 from a kit. Soldered all the components in the motherboard and 4K ram board. I didn't have a floppy drive, I used a Teletype ASR 33 to load basic from a paper tape.
This operating system makes MS-DOS, CP/M and the Linux command line look like a miracle of user-friendliness and verbosity by comparison. What an amazing piece of history.
Done when memory was expensive, so every bit counted. No room to put fancy error messages, or even error detection code for odd cases, as you only had the 8k of ROM available to use, and likely were already trying to put an entire extra kitchen sink into it as well. Thus all the optimised code that reused routines as much as possible, or even some that did different things depending on where you entered the subroutine, as the CPU would always execute the first byte on entry as an opcode.
@@SeanBZA I played a little bit with some super optimization on a BIOS I wrote for the Sanyo MBC-55x series - it's 8088 based but no BIOS in ROM (normally it loaded the BIOS functions along with DOS and ROM just had a basic bootstrap loader). I found some interesting tricks like using a jump on parity to make a loop run exactly twice and save a few bytes, using a mov opcode to skip 2 bytes of data that served as alternate instructions for another entry point (saving one byte), shrinking init code down by making an initialization list of port addresses and data, and then a bit of trickery to make different sections more similar to each other so that the UPX compression could shrink it more (due to the memory layout, I actually had RAM to spare and wanted to use it to shrink the on-disk size).
Optimizing for size at all costs is definitely an exercise in doing all the bad things you normally should never do when programming.
Well, you have to start somewhere, if you fire up some PDP11 emulator with Unix V6 you will have a similar experience. :)
70s CP/M isn't going to be much better.
Wow! This swtpc 6800 series for me was a great trip down memory lane. As a student I was designing my own 6800/6809 based computer systems as well as peripheral and DRAM cards. At that time I was still working with 8" floppy drives. I also built a 128kByte paged EPROM card that contained my editor, assembler, linker and a hw debugger. I was actually building these EPROMs by using a cross assembler on a CDC Cyber mainframe, printing to paper tape, taking this to the university and reading the tape using a teletype into an eprom programmer. Well, life as a programmer was hard at those times ;-)
Thanks a lot for bringing back all those memories! 😀
6809 was the processor used in the Tandy Color Computer. 👍
It's funny you said, "I'm more of a hardware guy, and this software stuff is a bit over my pay grade." I feel the same way watching you, except in reverse. I'm a software engineer trying to learn how to repair old PC hardware (to keep it running)... you're way beyond my pay grade!
Back in the bad old days everyone was a hardware AND and software guy! The two went hand in hand. Assembly/machine code is the manipulation of logic gates. Every programming language since then has been just an abstraction of that process.
@@AndyGraceMedia John von Neumann, at least early on, considered the emerging assembly languages a cop out and was really not a fan. Any abstraction comes at a cost to clarity of what's actually going on with the machine, and when you're trying to debug a library-sized computer... Yeah.
I'm in between. I understand enough of both aspects to follow and understand pretty much everything, but if I was in Adrian's shoes I could never get any of this going on my own.
@@GdotWdot I love that guys from that time were like “if you can’t keep track of your jump points you’re not a real programmer, assemblers are pointless”
I actually knew some people back in the day who had these SWTPC 6800 machines. Sure it looks clunky and simple today. But back then it was the best thing ever. Watching this series is a real trip down memory lane.
ive been watching this channel for a couple years. i know i have learned alot because i can always follow along logically with what is going on, even if i dont understand the 'why' of a ton of it, nor could i recreate it or explain it to someone else. but the crazy thing is that despite that, and despite the fact that i rarely watch videos 30-60 min long, i always watch these videos in their entirety, never get bored and enjoy every minute. keep doing what you do adrian, you have my support.
support from satan is always welcome ;)
agreed - I probably understand far less than most here (I’m more familiarized with vintage channels like Mr. Carlson’s Lab, and I’ve been studying Ben Eater’s more basic videos recently after deciding to really learn 8/16/64-bit electronics) but I can still follow the flow of these videos. My aspiration is to become a hobbyist in my own living space one day! (but I suspect I’ll be starting simple with radios and VTVMs and such… it’ll be some time before I repair my first computer!)
ive also been watching for a few years now i started my pc fascination with my schools old acorn systems(uk) then primary school bought a win 95 machine with a cd rom for £1000 there was a whole school assembly too then in high school back to acorns then finally windows xp as we leave thanks Britain . left school built my own win xp machine ive been tweaking ever since anything pre 90s is pure pc archeology to me keep up the good work guys
Satan165.... Agreed 💯
I have to agree with the original poster. Adrian, please stop feeling like your videos are too long. They're not! If someone feels like a video is too long, they can always skip ahead.
The problems you worked through demonstrate just how far we've come in terms of sophistication on not only the hardware, but also the software in the systems we use. Troubleshooting these old systems is definitely an adventure!
I think the delay on the floppy disk controller card, either software or hardware, has to do with some older floppy disk drive, as the spindle motors on some of them were huge and heavy, so the controller is simply buying the floppy disk drives time to stabilize in term of speed of the spindle before it even bother to read the floppy disks, mostly to prevent the CRC checksum errors while reading the disk that's not in the alignment of both rotation speed and MFM subcarrier frequency. Modern floppy disk controller doesn't do that anymore as we were using the final 3 inches floppy disk drives whose motors were light so it spins up right away.
So, protip; for those who love computing history and uses 5 inch floppy disk drives, especially those modified to accept the classic MFM datalink, I recommend to incur the three seconds hard drive boot delay in the BIOS, so you can give those classic drives time to stabilize before booting up the OS on it or do anything with it otherwise.
What I love about this is that even though the original backup was made with the wrong drive/wrong settings, it was still enough to turn it into a completely usable, bootable disk (with some extra steps). Just goes to show that when it comes to data preservation, doing something is always better than doing nothing. Even if you don't get it completely right it can still be useful to someone in the future!
I am a older gent that used to loved working on Computers before IC became too hard to work with. Watching this series has given me an idea to recreate this computer with newer parts... and by that I mean ATX power supply, use 50 pin cable style connectors for main bus and 30 pin for IO bus. I am starting with the base board (MP-B) and go from there. Plan is to design new circuit boards that use the new tech such as you using sram, it could all be on a very small board with a single ram and a few support curcuits.
This was a great series and who knows... someday I maybe able to make the boards I design available to other people that are interesred in this sort of thing.
Thanks Adrian
Great work Adrian!! That computer is crying out for a FORTH operating system! See how much you can do in 48k of RAM! Complete control of the hardware!
Computer archaeology in action! This was a fascinating series - really helps to see the complexity of simple procedures we took for granted in later machines.
Most users of computers these days have no clue what the 70's and 80's were like. Today Google, Siri, Alexa and the like can usually understand your spoken words and search or run commands for you. You don't have to memorize cryptic commands to get anything useful done.
At least *micro* computer archaeology. There had been computers around for several decades, before we got modern VLSI designs like this, that fits on a desktop.
Your dogged determination to fight through all that disk track .. etc stuff is amazing. And to have multiple faults (card chips need reseating, ribbon cable problems, disk sector issues, termination issues etc) and eventually end up with a DOS prompt was amazing. The tour through the various commands was wonderful. Made me appreciate how easy it became for people like me who started with msdos. Thumbs-up !
CPM and MSDOS/PCDOS were quite the advancements back in the day. Then came the GUIs, and now people rarely see command prompts, unless they are programmers or work on servers.
I have often said, "I miss the 8-bit days. Back then, there was absolutely no doubt that you were the superior being." Well, this is to those 8-bit machines what the 8-bit machines are to us. xD
It's super cool to see such an ancient and even more rudimentary machine actually running. Huge kudos, Adrian, for your efforts and determination to get this beast chugging along again!
We still are the superior beings. And our younger colleagues know it.
Being able to essentially restore a more stable copy of the original disc is great. It was cool to get the breakdown of how you slowly pieces bits of things together to get a workable solution.
A less common form of bootstrapping :D
I will never in my life do anything like this, even if I would fantasize about it. Thanks for letting me do it vicariously. It's so important to preserve these things.
Just a small note on bulk erasers. In the instructions for audio media, I recall that they said to turn on the unit when far away (both arms length) from the media before bringing it against the media to erase. Same thing before turning it off: take it away from the media before releasing the switch. The idea is to avoid creating magnetic pulses that would magnetize the media when operating the AC switch. Thanks!
In the IMD docs it discusses the potential need to format a disk on the target machine then copy the IMD imaged disk to the locally formatted disk when writing to an IMD written disk corrupts the disk. The issue you saw is consistent with my experiences with IMD as well. It may be related to the R/W Gap and/or the Format Gap settings in IMD.
It’s pretty interesting how it’s basically bootstrapping modulation tolerances, using asymmetric tolerances for reads and writes, until you finally get something nice and in spec
I think the internet archive is a godsend for a lot of stuff. I like to support them as much as I can.
This series is an instant classic. Wow, all the old memories from the 70's and 80's. Thanks so much for these.
I love the mentions back and forth between Adrian and Clint (LGR)! They both got their own thing with a lot of mutual respect. Us nerds got to stick together!
Fifty years from now, someone will be trying to access an old laptop by using the FO to SATA version of Kryo and they will be adjusting clock times to match the solid state chips just as you adjusted the rpm controller of the disk drive.
Fascinating video. Bravo on your hard work paying off. Little by little. Thank you for the upload.
“Man these turn of the century semiconductors had such slow slew times… it’s hard to turn down modern hardware to even run this slowly”
You are a legend. These videos bring back memories of Amiga 500 I used to own, and bringing computers I've never seen. That intuitive problem solving is top notch, because old hardware is so dodgy, you never know if it's a bad connection somewhere or dirty disk drive.
Back in the day, we used to "make" SD-disks to DD-disks by making a nothc to the diskette, as it fools the drive to think it's a double density, and it worked with better quality disks. Try that one sometimes. Greetings from a nerd from Finland!
Well done on the detective work. One thing that I learnt the hard way with my TRS80 Model 1 is to remove the disk (or at least open the drive door) before power up or down as the “splurt” of data down the cable can corrupt the disk. I’d be doing that here as well…
Turning the system power on or off would push a glitch through the drive heads, corrupting whatever was under the head, even without the drive spinning. I glitched a few disk sectors on my Model 1 from that back in the day. I quickly learned to keep the door open when not using the disk.
Amazing work. When I first saw this computer I didn't have the slightest clue how it even operated. After watching your videos, I still don't have the slightest clue but I'm glad you got it working! Seriously cool to see it functioning how it did back in the day.
Wow! I'm an EE and worked on old computer for a hobby for years and I constantly learn so much here. Thanks!
"earlier in this video when I took a dump " - was seriously worried Adrian was about to do a major overshare 😂
I'm not too experienced with these old systems, but I DO remember that it was VERY easy to damage those discs from power spikes. Hence, it was always standard practice to put the disc in a few (3) seconds AFTER switching the computer on and to NEVER remove a disc while the drive light was still on. Also, it was a thing to wait 5 seconds after a forced shutdown to allow for any memory to be completely flushed before switching on again. That procedure does eliminate some spurious errors.
A genuinely amazing bit of real digital archeology, very impressed with the flopy disc salvage. As was pointed out, this was in the age when everything was hacked together, one step up from punched card or tape. Reminds me of my early days on a Research Machines 380Z!.
Very fitting for Adrian Black to take over the reins of this computer from Hank White! 😁
Awesome Adrian, well done on getting that going! And thanks for the tour of DOS - most interesting. It does seem to work at a lower level than more modern systems; I worked with CP/M in the 80's and that was a bit like that.
fantastic work, and a great addition of the preservation of this hardware and software, its great to see that MS-DOS wasn't the only game in town, an addition to other DOSes like TRS-DOS and CP/M.
MS-DOS' disk structure was actually fairly primitive compared to what was available on other much earlier systems. Good old TRS-80 MI/III used free space bitmaps, the concept of block allocation runs, different levels of file access by password, spanning directory entries for extra metadata storage, while MS-DOS had crude memory hungry FAT chains and that was about it. It wasn't just TRS-80 DOSes either, there's plenty of examples of more advanced structures. In many ways MS-DOS was actually a backward step.
This is a super-interesting example of how even early 1980s disc systems are essentially related to earlier devices. No-one was reinventing technology (even IBM), these were evolutions. I guess that is largely because Shugart mechanisms were the only game in town.
Amazing walk through of this system (all parts in the series). I know so little of those very early computers, and to see you progress from receiving it to a functioning 2 drive setup like that is really eye opening! All that sleuthing to get the drives working, imaging & booting - very impressive! Again, fantastic series. Thank you.
Are you related to the "King of Kong" Wiebe? Just spitballing here, didn't check the spelling.
@@jamesdye4603 Same spelling I believe, but slightly different pronunciation (last e is silent). But no, we're not related.
It's fascinating to see a time capsule like this getting preserved, and thanks to the other videos on the channel you can get a sense of where this machine fits in on the computing timeline. It's not something I'd most likely ever get to see outside of a vintage computer fair or museum, so thank you for get this old timer up and running in the highly educational way that you do. I used to sell antique Ford auto parts, and like a Model T, the SWTPC has a certain type of charm in its simplicity, but also something I would never ever want to own. :)
Back then, I purchased for a stagering $10K , my first TRS80-1200, 2 floppies, 10MB HD, built-in screen, with a Dot Matrix Printer. When booted-up, it showed DOS, ready to accept commands. This video brings me back in time. I make me feel so weird when I compare with today's technology. That's how I started with computers. Evolution is such a weird thing. Thanks for posting 🎉
What a great, winding road this forgotten old piece of metal took you on. Thanks for taking us with you!
A long time ago, I used DOS for a long time. From the early version to last. I started using it much later than others at the place I worked. we created menues and was able to use it at our office. When i first started working for a company who used DOS mostly. Well, us in the back of the business. I was able to catch on very fast. The guy who brought my computer to me, I quikly programmed a menu option that we used on our network. He was quite suprised I figured it out. Well, I did a lot of research. And from there, I started working in IT jobs only. I was living inTexas when I started my IT career. I have made lots of money in that field of work.
Hugely useful to a person trying to bring up a computer from that generation. Very well done. Your talents are appreciated.
Having my own computer in 1975 was just an impossible dream. By 1981 we had CP/M with Assembler and BASIC on a Z80 at school... but I still had to dream of that Fortran compiler. That repair command takes me back to college.... replacing BASIC's error messages with our own "funny" versions.
I have to chuckle because I first heard about the stunt as a child. My mother was taking college classes and had a prof who/and/or students that had replaced the error codes in some of the university's terminals, where a piece of the exploded death star was on display circa '78.... My actual interest at the time is obvious, but I never forgot the "naughty" error codes bit.
These DOS-68 really show how far things had come by MS-DOS days, they also show quite well DOS evolutions (when you move up the version tree, _and_ start using stuff like FLEX). Thanks for putting in the time to get a good outcome.
Thanks for sharing, really nice research, I wonder how much time was spent on it to get it working. Great job. OSs from a preDOS time are barely known today, and its really nice to see how it works. And last but not least, its great to see a good technical explanation of how system works, not just a video when somebody takes an old machine and just start gaming.
Fascinating! Some excellent detective work there and entertainingly presented. I remember seeing adverts for these machines back in the day but have never seen one working.
Hey Adrian - Thanks for the trip down memory lane! So many memories form back in the day of trying to get this gear to work. But more importantly all the people who were there. We all spent a lot of hours helping each other. Lots of pizza, beer and good friends!
I had a disk drive I bought from SWTPC. It used 8" floppies and plugged into a smaller card at the rear of the computer. I think I paid $1200 for the drive and controller. I didn't know about DOS68, But I did have a Smoke Signals BASIC and Smoke Signals word processor (not GUI) I took my system to an attorney's office and demonstrated the word processor. I also had a Xerox daisy wheel printer that I used as a terminal. The clerical staff at the attorney's office weren't happy. They thought I was trying to replace them with a computer.
I was thinking about daisy wheels the other day; 3D print the "wheel" an RPi0 to control a hammer that smacks it against Some-Kind-Of-Ribbon. Pi Pico would do the job. Or robot finger, more RPi, moving across electric typewriter. Write a "driver" that converts ASCII to finger presses.
> Xerox daisy wheel printer
The famous, Diablo 630, I bet!
@@andrewkieran8942 yes I later made a deal with a computer store owner. He had a customer who needed it and I ended up with an original IBM PC about a month after they were introduced. I also wrote some software in the exchange.
@@stalinvladThere were devices that could be attached to typewriter keyboards, effectively adapting them for use as printers or teletypes. These were controlled by a computer and used electromechanical plungers to actuate the keys.
My friend's co-worker was totally CLUELESS when it came to computers. He asked him for a copy of a certain floppy. You guessed it, he Xeroxed the floppy itself and placed it in a (physical) folder! :)
I was about to ask if he even stuck the floppy on the side of a metal desk with (you guessed it) a magnet. Remember: closing all windows doesn't mean to literally close all the windows in your house. That, and your CD drive tray is not a cup holder. 🤣
Scotty: (holds mouse like a microphone) Hello, computer?
-No response.
Proceeds to rewrite operating system...
I saw that computer advertised in so many issues of Popular Electronics that the SWTP logo seems to have been burned into my childhood brain. There was no way I could afford it of course.
Absolutely brilliant... you are getting amazing at working through the problems that confront you in retro computing. I have to watch this a few more times to understand exactly what you figured out along the way.
Awesome video! That machine deserves its own pillar of fame with floppy's and terminal to show of what it can do!
Adrian, you make an excellent point! Always format the disk you want to use on the drive you want to use it with, and then move that disk to the other drive to copy the file to it.
Drive interchange will bite (and cut) you every time!! Thanks for going through all these steps for everyone! PS. I'd like to hear more of the heavy technical troubleshooting that you went through, with the oscilloscope, etc; I'm sure others would as well. maybe for your second channel... Just a thought!
I am also one of the people who dump all disks with an 80 track drive, as 80-track images. Simply because if the disk is marginal, you can get some additional flux info from the neighboring (half-)tracks which might help in repairing bad sectors. In the end, the more data you have, the better. All the problems you describe (picking 40 tracks from a set of 80, converting the RPM to proper 300RPM, etc.) are all things that KF's dtc.exe does with the flip of a single switch. So for me, the value in having more data dumped from the floppy trumps convenience when trying to write it back...
Also, I think most of the confusion from DTC comes from the fact that the order of parameters is relevant. I get tripped by this too, all the time. So it might be that your switch to only read/write side 0 is not getting picked up. Try swapping the order around. It's the file name parameter that is relevant, so if you have that at the end, try to move it to the front, or vice versa (I can never remember which is correct)
What a fascinating video and I can appreciate just how much work you put into this to get it working. This is a really interesting machine and a good insight into how OS development went, when this basically starts into nothing more than a machine language monitor. Thank you for sharing your journey to get this fully working again. You must have an amazing collection of working vintage computers by now.
I was on the edge of my seat the whole time! What a journey! I'm glad that you ended up with a fully working system, and with that assembler included in the dos disk, the sky is really the limit now!
This has been a great series Adrian, thoroughly enjoying seeing this old machine come back to life bit by bit.
Nice work Adrian. I love the amount of technical detail you went into in this video to get those disk images working (and preserved).
FYI, the reason for the cable twist is simply so IBM could ship all drives configured as drive 1 (second drive) and not need to stock a separate part number, or to deal with extra documentation and the chance of someone doing it wrong.
Ah, back in the days when not only was it possible to have absolute knowledge of how your computer worked, every single feature, every IC, port, memory address, etc, but it was also mandatory.
Awesome interview you and Bil Herd did!
I love your transistor radio sitting there so you can listen to the RF noise the system emits. Back in the day there was one permanently sitting behind my TRS-80 Model I.
As for trouble reading/writing on a disk formatted on a different drive (but could read/write disks formatted by itself) this was extremely common back in the 1980's with Radio Shack Shugart drives ..We would tell the person to bring their computer with drives into local Tandy Computer Repair Center and have drives aligned ...which what i would do as a Repair Center manager...
The process would be using a specially made floppy disk from Dyson there is a signal written at the very edge of the track 16 and 17 and another signal written on the edge of 17 and 18..We would set the drive on track 17 and with an O-Scope read the signals making sure both signals were equal... commonly called setting the head azimuth this would make sure the head was directly over track 17 (center of the disk) ..
I can barely hold on by the skin of my teeth to what you talk about, Adrian. Sincerest kudos for breaking most of this stuff down for those of us that lived during that era. Even though I took classes in three different assembly languages, COBOL, JCL, Pascal and C, etc., I haven't kept up with it. Hardware and electronics, and tube amp repair is something I dabble in, so much of what you do in your videos, blows my mind. Thanks for some crazy interesting topics.
I only wish you could spend more time on the Apple ][ series, and breakdown the internals of the Apple ][+ and //e, memory maps, the & command, etc. Though there are a lot of Commodore users in the world, I kinda get tired of having SO MUCH done on your channel regarding Commodore.
But, thanks for everything you do, regardless. Awesome brain!
I love this PC Archeology that you have been doing lately. Today's 64-bit era is very easy to the point where most people have an internet connected device, and take it for granted. Seeing these old 8-bit machines and what was necessary to make them function show how much we take computers and information technology for granted. Back then you really had to know your stuff to do even the most basic tasks. Great stuff, keep it coming.
Well done! Never read or otherwise learned about Smoke Signal Broadcasting before, despite being interested in computer history for many years. It's good to see this history preserved.
This really is a spectacular overview. Well done getting all this working, and giving us an insight into 70s computing!
You do have what was referred to as flippy floppies. We used to keep hole punches for punching holes in paper around to make our own flippy floppies, You gently lift the cover away from the recording medium, punch a new hole 180 degrees from the original hole into the soft cover on both the front and back of the diskette. This gives you a new index hole on the opposing side, next on the opposite edge of the floppy you also cut a new write protect notch to mirror the original notch. Now both sides of the floppy can be written or read on a single side floppy drive by simply flipping the diskette over./ The data on the back side of the floppy is recorded backwards and the for can not be read on a double-sided drives second side. To read the back you must flip the diskette over even in a double sided drive. I never did figure out why some genius did not figure out how to read the data, and reverse the bits/bytes in software to make them readable.
6800 - The first processor I ever used, and programmed in binary level machine code.
When you can do that, you can do anything.
The steprate in that 1771 floppy disc controller is hardwired but it can select 4 different rates.
There is a "seek track" command that the OS sends to the controller, and 2 bits of that byte specify how fast it should step.
I don't know DOS68, but likely the only way to send another steprate to the controller is to patch some byte in the DOS image.
OSes developed a little later (e.g. NEWDOS/80 for the TRS-80) had disk parameter tables that you could change to adapt the steprate to your drive.
In another comment I read this, indicating that DOS68 also had such a feature to adapt the steprate:
Note that as supplied, the system disk is shipped to boot⠂
with the slowest step rate and the longest dealy time after⠂
select. Your disk drives most likely can use a faster step⠂
rate; thus, please ensure you establish your boot disk as is⠂
appropriate for your system. Read about SYSTEM (STEP=n) and⠂
SYSTEM (DELAY=) in your user manual. Also use the proper⠂
BSTEP= parameter when you format your working system disk.⠂
Excellent job Adrian! thank you for all your hard work on this project!
Incredibly detailed video. This definitely was a voyage! Adrian, thanks for bringing us along. Each video about this PC has been a treat!
Of all those machine you have show on the bench, I think this is the most interesting machine imho., because it is so much different than newer more standardized machine. Really interesting to learn about how this machine works.
6:40 I actually saw some 5.25" floppies which has cutouts for the index holes on both sides, so you can flip the disk in drives which use the index pulse. IIRC they were some German made disks.
That BFD was probably a BFD when it came out.
Well done!
I‘d transfer software via the terminal. You can cp the asm code to a file (pasting the asm in the terminal will save you typing it) and compile it on the 6800.
I used to work with similar hardware in a „company“ that didn’t replace their computers as long as possible (due to it being „perfectly fine“ and „normal“ to use such outdated equipment to control and monitor a process). In the end there was a catastrophic fault and I got it updated. Reverse engineering the software was quite a bit of work, but it was required to validate the new system provided by the vendor had the same functionality and especially the calibration routines where unaltered.
What a trip down memory lane.. Thanks!
Amazing work here, Adrian. Really learning a lot through your videos especially this series on the 6800.
Great job getting that box booting DOS68. AFAICR, this is the first time I've heard you mention the KyroFlux in a video I've seen. It is a very useful device to help bootstrap some vintage machines along with that other program that you mentioned. I have an old original CP/M 2.2 8" diskette (somewhere). I never had a system up and running to let me back up its contents.
Thank you for clarifying what BFD stood for. 😉
I was a senior lab tech at University of North Texas computer lab in the 1980s. Computers with hard disc drives were scarce. A PhD student was finishing his dissertation on a dual floppy IBM PC. He tried to save and got the Error writing drive B Abort Retry Fail message. To his credit he came to me instead of turning the computer off. .Drive B had an error. So with the computer on I unplugged the A drive and swapped it with the B drive and selected retry. It saved his dissertation. All the connectors are low voltage so if you are careful with the connectors, it will reset the drive once it gets power. He graduated and the lab got pizza at night, my shift, for the remainder of the summer. I miss this level of computer technology. Faster great but very little is repairable by the average person with the newer technology
What a journey! Really interesting troubleshooting, great job getting it going, many others would have given up!
FYI, the Kryoflux is absolutely the device NOT to have. The AppleSauce disk imager is the tool of choice for those that have serious work to do and don't want to worry about being mistreated or threatened by the company that sells the device.
I am happy that this SWTPC 6800 ended up in your hands. It is a nice piece of kit that needs to be preserved.
Great job on getting the ancient technology to work. You have patience! To those who just want to see the floppy drive working properly FF to 42:39. Thanks!
That was a real bit of amazing investigation.. Great work on finding and fixing all the problems that came along !!
Watching this computer and its DOS operate is like experiencing something from another dimension or world or timeline where this was in normal use.
This machine is so charming, I hope I can find one of my own sometime.
I remember in old times everything was so complicated and delicate, it was difficult to reproduce success stories and you had to try over and over till it worked again for a while.
So, I can tell you what happened with the disk: the issue is that the Kryoflux RAW files are flux-level files, which means they contain a fundamentally analogue recording of the intervals between each magnetic flux transition on the disk. As you discovered, these can't normally be written back. Each RAW file actually contains the data from about five to ten revolutions of the disk in one long stream, and it's not split up into sectors or records.
If you're using flux-level hardware, then what you have to do is to decode this into the actual data --- a sector image --- and then encode it _back_ into flux data. This will contain one revolution of data, so it'll fit on a track. It also contains nicely aligned pulsetrains without all the analogue noise that you get when reading the disk.
This is basically what you did by creating the IMD file (which is a sector image), and then writing it back with ImageDisk; in this case, of course, the FDC encodes the sector data into flux data in hardware. But if you use flux-level hardware then things are much more flexible. Reading and writing 40-track disks on 80-track drives totally works (on reads you skip tracks, or just read both tracks and deduplicate the sectors after decoding; on writing, you write even track and magnetically erase odd tracks); and drive RPM becomes largely irrelevant (you can write 300rpm formats with a 360rpm drive no problem --- just change the flux pulse timing!)
The bad writes I have more trouble explaining, but I'm going to guess that something was wrong with the sector spacing so that writing one sector would erase part of the following one. Drives take time to turn the erase head on and off, during which time the disk continues to rotate, and there's typically a dead space between records on the disk to provide a safe space for this to happen. If the sectors were too close together, it'd totally be possible to accidentally erase part of the sector header of the next sector on write, even though they'd read fine.
Knowing absolutely EVERTHING there is to know about CP/M made me think I was the smartest guy in the room.
I was wrong, and lay down my sword before you.
You Sir, have bested me.
I really liked this series on the SWTP computer. I would love to see a similar series on Cromemco and Digital Group computers. Keep up the good work!
it's great you took the time for this early DOS walkthru on what was a bit of a long road to getting this thing to boot right. For while I am into retro stuff...the 6800 is a bit too old and bit to into the hardware side of things for me to dig into but I liked seeing the DOS and the differences between say it and DOS 3.3 or even CPM for example.
Great job Adrian! Learned a lot and enjoyed it. Fascinating. Thank you for making this video. I now see where Atari DOS inherited the 'binary load' ' binary save' and 'create mem.sav' features.
Thank you for both sharing knowledge and highlighting importance of technology preservation, as well as contributing to it!
"It's probably not a problem...probably." Adrian, don't you know that's exactly what the scientists said just before the Resonance Cascade in Half Life 1? :D
Wow, this was some process! Well done for seeing it through to the end, Adrian!
That was brilliant Adrian. Many thanks, hours of endless fun!!
Insane how things have changed over the years
Thank you for doing all of this research and work, made a really great video! Both interesting and educational. And such a great preservation of information for the future.
Adrian. Super cool hos much capability this old machine has. Another one rescued from the graveyard!
Awesome video. I'm so glad to see you delve into these early systems. I find them very entertaining, much more than the more mainstream systems.
These videos have been so fun to watch. I didn't get into computers until right before XP but now I just love learning about them.
this is amazing windows xp and windows 95 too yep
Love Kryoflux but didn’t know about the issue with using HD vs DD drives, thanks!