Software Problems? Hardware Solutions!

VCF Southwest is barreling down on us real fast, and some of my junk works, haha. The CDC hawk drive is almost there, only it’s giving us even more grief now and the data terminal takes a dirt nap everytime we throw data at it. Let’s see if we can coax some of this stuff back into life enough for the event!
If you want to know more about the Centurion, the wiki is full of just about everything we know:
github.com/Nakazoto/Centurion...
Come hang out with us at VCF Southwest:
www.vcfsw.org/
If you want to support the channel please hop over to Patreon:
/ usagielectric
Also, we now have some epic shirts for sale!
my-store-11554688.creator-spr...
Come join us on Discord!
Discord: / discord
Intro Music adapted from: Artist:
The Runaway Five Title:
The Shinra Shuffle ocremix.org/remix/OCR01847
Thanks for watching!
Chapters
0:00 A funny story!
1:41 Alright, what’s broken now?
6:39 Swapping heads like it’s Frankenstein’s monster
9:25 Taking it for a test drive
12:10 Shady business practices striking 40 years later
15:33 Finally getting to the data terminal
16:59 Comparing the Regent 100 and Regent 200
19:38 It couldn’t have been easy, could it have?
22:17 Shifting gears and digging into the MUX card
24:45 Building and testing the daughter board
29:01 Hacky hardware solutions!
31:26 Koma!

[@n2nby]

17 year ADDS employee here again. The regent 200 terminal had all kinds of problems in its life. It was supposedly a souped up 100 with more software features. The stock 8085 processor was not up to the task, too much to do too little time to do it. You were dead on the circuit boards were the same. Just a rom upgrade made it a 200. The difference in keyboard cable was first release to newer. Even 100’s got the idc cable later. First release used the micro to scan the key matrix, double flat cable. Found to be a big problem task wise. 200 even more so. Scan task was removed from software, to hardware chips. Flickering maybe from over loaded input buffer on the 200. The 8275 video controller would be paused to process the input buffer. Hence video flicker. If the centurion computer has flow control. Software or hardware enable it. I preferred rts/cts flow control, had to be enabled on the terminal (forget??). The flow will be jerky but no video flick. Good trick to cut in half baud clock to get 4800. Good luck

[@UsagiElectric]

Whoa, awesome to hear that you used to work at ADDS! I think y'all made some of the most stunning and striking looking data terminals out there. Although, it is good to hear that I'm not so far off point with the Regent 200 in thinking that it's not a hardware fault, but rather a design fault. The Centurion flow control is unfortunately not properly fleshed out (it looks like they were thinking to implement it and then never quite followed through). I think in that case, our best solution might be to just let this one live at 4800 until we can figure out how to get RTS/CTS working properly on the terminal!

[@ultrametric9317]

I wanna say I worked on an ADDS terminal that could do APL characters. I may just be imagining that :) I wish this Centurion would do something really cool like be a FORTH or APL system, even with remote nodes. You can definitely multi-task FORTH on this class of machine.

[@Lucien86]

@@UsagiElectric I might be wrong here but that behaviour with the higher speeds on the terminal might be a subtle hardware fault. On machines like terminals the hardware and software are not very separate and it can be difficult to discriminate problems between the two... Especially with things like timing issues.. Even very slight differences between chips can mean that something works with one chip but not another. - The real problem is that nothing is actually broken it just doesn't work.. It could be something as simple as a slightly bad or off value capacitor.

[@n2nby]

@@Lucien86 Nope! The regent 200 was just that bad. You can google it. The 200 was the subject of a bad lawsuit from a vendor client. ADDS lost it, no surprise there. The original 8085 clock was 1.5 MHZ. It was design copy of the Intel 8275 video controller. It was interrupt driven. Just like the first IBM PC. Anything to change in video had to be done in the horizontal retrace time. Or you got serious flickering. Because of timing issues with the 8275 controller. The 100/200 line was never upgrade-able to faster 8085's. @UsagiElectric Get a viewpoint terminal. Very reliable, just paint the black PVC40 plastic blue. Centurion I believe never bought any viewpoints. If you find one, the only thing that goes wrong is the keyboard cord. But that's just a telephone handset cord. RJ4's on each end. Cheap and easy to replace.

[@WelshProgrammer]

Sounds like a similar problem to what the Sinclair ZX80/81 had, flickering video because the CPU had to stop video processing to deal with other stuff.

[@WesMakesStuff]

Working in EDU sales, I’ve got a feeling that the dealer may have removed the format command so that students couldn’t wipe out the drive. With the cost to repair one of these units back in the day, and being at a high school, I’d say there was a high probability it was removed to keep the nuckle heads from wiping the OS every other week.

[@horusfalcon]

That kinda _does make sense._

[@louiskeser9255]

Good point. Used to work at a school and the MacOS images we used also had some utility applications removed for similar reasons.

[@UsagiElectric]

Hmm, I didn't think about that! Talking with Ken Romaine, he said it wasn't uncommon for dealers to remove the format command to force the customers to buy packs from them instead of getting them from cheaper sources, but I like the school theory as well!

[@Alcarods]

This would make total sense. I remember in the early 90s our school windows-based computers had a second partition to the hard drives that were read-only. Don't ask me how I know

[@borisbosnjak4812]

Sounds like the same rationale our first year chemistry lab teaching assistant employed in not telling us where the Manual of Explosives was kept in the chemistry library... :P

[@chuegen]

Interesting story... in your last video, you mentioned Mr. Hall at Butler Tech. It perked my ears, only because... Mr. Hall is my brother-in-law. I texted him and sent him the link, and he told me the story. Who would have thought -- small world!

[@chevylization]

"HELLORLD" never gets old 😂

[@UpLateGeek]

I always assumed that once a head is blown, that's the end of the story. But if you can work out how to re-wind a blown coil, that could be a huge step forward for dead hawk drives! Obviously it's not going to help for heads that have damaged ceramic substrate from a head crash, but I'm sure there are drives out there that could be rescued if they just need a coil re-wound.

[@SeanBZA]

Those heads are large enough that they were originally hand wound in the factory, so should be doable. Usagi needs to get himself a decent metallurgical microscope, or a Mantis, to get the deep depth of field and large working distance to do this. Yes winding with 60SWG wire is going to be difficult, but doable.

[@Gamah1991]

This reminded me of a hilarious copypasta about defense contractors... This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said "Of course it leaks". He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to "support" the leaks. Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention.

[@BoredInNW6]

22:31 This is a coincidence: I've just spent a couple of days reverse engineering an old paper tape reader which uses a 6402 UART. Your solution is elegant, even though you called it "dumb", but I'm wondering about a more flexible route. Looking at the mux board, the UARTs are already in sockets, so you could bring the port 0 UART out to a daughter board without any changes to the mux board. Then you would just need to intercept the RRC or TRC clock (either one, since they're tied together) and send it via a flip-flop, used as a clock divider. Then the host would think it had configured port 0 for 9600 baud, but the UART would actually clock it at 4800. And you'd retain the ability to change the baud rate without fiddling with DIP switches. There's always more than one way to do it!

[@michaelrowley8679]

I'm an Electrical Engineer that worked on old computer systems including removable drives like you show here. We had alignment disks that we would load in the drive and align the heads using an oscilloscope. After alignment, regular disk packs could then be used.

[@robertsmith2956]

ahh, 8.5" floppies. those were the days...... An ardiono optical tape reader is on my bucket list to recover a few programs on very fragile paper tape.

[@lorensims4846]

So nice that you were able to modify the data rate without having to actually change the OS or ROM software, or make any permanent mods to either unit. The minicomputer now looks and works as good as new!

[@UsagiElectric]

It was really important that I didn't make any permanent modifications to the original boards (aside from adding a socket). It was a nice little solution that I'm quite happy with!

[@mudi2000a]

@@UsagiElectric is it still usable? even at 9600 scrolling is not exactly fast on those terminals ...

[@paulcohen1555]

When I worked on these and other CDC drives, I never encountered bad heads unless they crashed. Another thing I remember that we had torque screwdriver to fix the screw at the proper torque and not break them in the carriage!

[@UsagiElectric]

Interestingly, of the four heads with bad coils I've come across so far, three of them are lower heads. Perhaps after decades in storage, moisture accumulates on the lower head more than the upper and corrodes the extremely thin wire? It's a small sample size to say anything for certain, but it's definitely an interesting observation! I think the first time I cinched the head screws down, I was a little worried about stripping them, so I didn't get them tight enough. After replacing the rubber pads and cinching the heads down a bit tighter this time, it's been through about 10 to 15 power cycles so far without any issues! I really should look into getting a torque screwdriver though, I'm super worried about stripping out the carriage.

[@jonathanreves]

​@@UsagiElectric Wheeler makes a good torque screwdriver that I have had great success with.

[@paulcohen1555]

@@UsagiElectric A Torque screwdriver is quite expensive, at least a good calibrated one. BTW, Most crashes occurred on the top of the platter.

[@mudi2000a]

@@UsagiElectric Moisture issue on the heads is possible, there are some series of Commodore 1541 drives which also suffer from head failure due to moisture.

[@srenhaandbk7904]

🎵Hard drive, you've got all stars, get your name on, hey, heyyy 🎵

[@TastyBusiness]

Nicely done. Sometimes old computer repair just goes like that. Have fun at VCFSW!

[@munyxxi]

I love this channel, your enthusiasm is contagious!

[@JeffBreyer]

I love how you implemented your solution. I am slowly learning about these old systems thanks to you.

[@andresgazso881]

Loved that you used a vintage Casio Mini 8 to calculate the baud rate! To be consistent, I am sure you will use a slider rule to make any calculations for the Bendix machine 😂

[@3v068]

I know absolutely next to nothing about early computers and finding your channel randomly recommended to me has made my month! Keep working on these! It's very interesting to see as a mere 26 year old.

[@terrylyn]

I'm 41 and still these were before my time as well, however I see some resemblance to early IBM MS-DOS PCs.

[@pglick123]

I'm only @6:00 and your idea of moving heads between drive assemblies sounds like insanity! Good luck, I have to keep watching until the end...

[@MontegaB]

That bodge board is perfect! So cool that you got to do a period-correct modification to the machine. Great work.

[@anthonyblacker8471]

I miss Radio Shack. The last thing I bough from them was a cordless home phone for my ex's grandfather in Fort Myers Florida. That was probably 2011. I went to the back of the store where all the components used to be in the big long gray drawers and it was all cleaned out, no real parts to speak of. A few bags of resistors hanging on a card, but man.. when I was a kid in the 80s Radio Shack was 15 minutes from my house growing up and I spent a LOT of time there!!

[@MarkusHobelsberger]

It's great to see how far you have come with the Centurion. I remember when misaligned heads in the Hawk drive seemed like an insurmountable hurdle and today you are casually swapping and re-aligning heads in that drive if needed.

[@user-nd8zh3ir7v]

intro was hilarious! great vid as always

[@MRichK]

You know this is bringing up memories. I am pretty sure I remember setting some ADM type terminals to 4800 in the mid 1980's on a Rexon, a Basic 4 type small multiuser computer as well. That was done based on "lore" but it worked I think that machine had 6 users on a huge 64K memory and a removable plateer hard drive as well.

[@wtmayhew]

I spent way too much time back in the 1970s and 1980s dealing with bit rate, flow control and parity settings on terminals and printers. I had the best luck with HP terminals because they had ring buffers and could pass flow control immediately to the host before the buffer overran. The HP 2445A terminal was awesome, it could display and write to its tape drive simultaneously at 9600 bps without ever doing flow control thanks to using fast bit slice processors. Of course, the downside was the price, which could have bought a decent used car. The other cool thing is that HP has used &… control language since the 1970s, and the language is consistent across many types of peripherals. If you write code to display a graph on a terminal, the same code could generate the same graph on a pen plotter or laser printer. My least favorite terminal was the DEC VT-100, especially in smooth scroll mode. The VT-100 actually stored each line on the screen as a variable length line in memory. HP did the same, but HP did it better. Storing the screen that way conserves memory and allows a terminal to do local editing on the terminal, which is nice for a terminal on a Bell 103 modem running at 300 bps. The host at the remote end would not have to repaint the screen, provided it correctly tracked the inserts and deletes occurring at the terminal. The problem with storing the screen as a linked list of lines is that memory fragmentation is inevitable. The terminal has to stop from time to time to garbage collect and consolidate memory. The VT-100 had an 8085 (?) running at a couple MHz, so those garbage collection pauses could be 500 mS or maybe even longer. The CPU was busy and would miss flow control during those pauses. The result is that a genuine VT-100 on a slow serial line was apt to get screen corruption no matter how you set the serial port. The best bet was to run at 2400 bps with smooth scrolling disabled. AT&T SysV UNIX could pretty much operate correctly with a VT-100 thanks to the terminfo database accounting for the vagaries of VT-100 timing. vi actually worked correctly most of the time even on slow serial lines.

[@The_Ballo]

@@wtmayhew Do you mean the HP 2645A?

[@wtmayhew]

Yes 2645A, that was a typographical error, apologies.

[@The_Ballo]

@@wtmayhew You must have typed the comment on a VT-100

[@wtmayhew]

@@The_Ballo Yes, that was accurate based on my personal experience. I had more problems with VT-100 terminals and PDPs running RT-11 with DRV-11 or whatever the combo RS-232/current loop card was (it been 40+ years) and Vax VMS and DEC mux boards than I did with SysV UNIX on Vax with the same DEC mux board. I believe it was Mark Horton and a few others at Bell Labs in Columbus, Ohio who rewrote vi to use the terminfo database instead of /etc/termcap to obtain terminal characteristics. Terminfo apparently has a much more complete characterization of terminal behavior including timing required for various operations. As previously noted, the sweet spot for the real DEC early model VT-100 is 2400 bps. Slower or faster than that increased the likelihood of screen corruption in a visual editor. The problem was that the firmware did not generate or respond to flow control while it was garbage collecting. I was more UNIX than DEC O/S oriented and didn’t have that much screen time in DEC O/Ses. My recollection was that the default editor from DEC was TECO (MIT, 1962) and later KED written in TPU and EVE which supported visual full screen. UNIX started out with the ed and then later vi.

[@hellraizer322]

Very awesome work Usagi!

[@danpedersen55]

Its such a good looking Terminal... Nice video 👍

[@wtmayhew]

That’s a cool solution to setting the console bit rate. It is good that there seem to be no timing loops in the operating system which assume the UART is operating at a particular bit rate on the console.

[@rlbf1967]

Awesome solution! Shocked by format command😱

[@donhuebert9151]

That was a fun one. I love TTL and building a little plug in card to solve a baud rate problem is a great fix! Well done.

[@darren6202]

I'm in awe of your electronics skills - I wish i had them!

[@KeritechElectronics]

Your Radio Shack desoldering iron bears a close resemblance to the Weller T0051304099. Congrats on getting the machine going before VCFSW! Setbacks and solutions, just like in the real life space program. Failure is not an option.

[@UsagiElectric]

It's very similar indeed! I think that was a popular option before electronic ones became all the rage. And failure was always an option, I was quite nervous if we'd get it done in time, haha.

[@slightlyevolved]

I can't speak for that specific one, but Weller was the OEM for quite a number of pieces of RadioShack soldering equipment.

[@KeritechElectronics]

@@slightlyevolved interesting, though this solder sucker is clearly meant to work with different type irons. That one was for a Weller TCP-S iron, you just removed the enclosure pipe and tip, then screwed it on.

[@edgeeffect]

@@slightlyevolved Yeah, it was always a favourite game of mine when buying from Radio Shack (or Tandy, here in the UK)... to try and work out who the manufacturer was and what it's original branding was. :)

[@williamsquires3070]

Hi Mr. Usagi. Have you tried O-rings as bump-stops? Maybe even some soft pencil erasers salvaged from #4 pencils. 😊

[@Wizardofgosz]

Sorbothane rubber or perhaps some sort of thick gel pad material might work well also.

[@SeanTurnerDeeper6]

I miss Radio Shack. 😢

[@mysock351C]

Ikr? I have that same desoldering iron and it’s amazing. Their solder and braid kicked ass as well. Really miss them.

[@jerther_]

I also have that desoldering iron and I recently replaced it. It was ok-ish but I can't say I miss the time it takes to warm up enough to be efficient. Anyway, it served me well for over three decades, can't say that often these days ;)

[@mysock351C]

@@jerther_ They may have dumbed it down at some point for safety. Mine takes about two to three minutes to heat, but once it does it gets HOT to the point that all the chrome was gone within a few uses, and it has lots of thermal mass so the solder melts instantly so with some technique even ICs will fall out under gravity once the solder is gone. On the flip-side I do have to be careful not to lift pads with it, so they may have toned it down a bit.

[@mysock351C]

@@jerther_ Actually I checked since I have a few and they did revise it and make it kinda wimpy later on. The earlier 50W one I have is quite spicy.

[@jerther_]

@@mysock351C ah, there you go. Mine is around 25W. I admit, at 50W it must be a beast 🔥

[@mysock351C]

Quick tip with the desoldering iron is that you can suck the solder out and break the pin free at the same time. I have that same RadioShack desoldering iron and as the solder melts I apply gentle pressure to the pin to center it before I release the bulb. This gives enough room to break the meniscus once the solder is gone, and the IC usually lifts right out by hand.

[@SeanBZA]

Probably the terminal flashing at 9600 and higher is simply the processor is unable to keep up, and the screen updates are done during CRT flyback, and there are simply not enough CPU cycles in that period to move all the data, so there is data moving during screen draw time. They probably solved that by using the retrace time to draw a line up at a time, instead of the vertical blanking, and the new hardware has an extra interrupt that allows this to be done. Boards might look identical, but definitely they have some trace changes done on them to get that right.

[@Moriarty147]

this is almost certainly the case. side note: if the CPU is standard & socketed I wonder if replacing it w/one that can run at a faster clockspeed would be doable.

[@Eletronicafg]

@@Moriarty147 Well, you would have to check if the RAM, ROM and peripherals can run at a higher speed also. If the firmware has any delay loop / timer that relies on the CPU clock then it would not work.

[@SeanBZA]

@@Eletronicafg They might have done that, but likely they also did a redesign on the board to remove bottlenecks, and that the layout is the same is because they reused the original Rublith layout, pulling up the crepe tapes where needed, and laying new ones. Remember no real CAD unless you had $200k to blow renting something for a month, and most designers simply drew at 2:1 size on Rubylith film, and then photographically reduced it to make the photoresist masters for production.

[@espfusion]

If a single scroll operation is CPU bottlenecked it shouldn't make a difference what the baud rate is as any one character can cause a scroll. My best guess is that the old version scrolls one line at a time on a character by character basis so it can only handle so many line feeds per vblank. While the fix looks ahead and scrolls multiple lines at once if necessary. But it's also possible the new version has a more sophisticated zero-copy scroll method, which could explain why it appears to not work on the older hardware. Either way it's weird that scrolling seems to cause the text to be blanked first. Maybe it's not a simple RAM buffer and there's some kind of hardware assist for clearing and/or scrolling because otherwise this seems bad both from a performance and visual impact standpoint.

[@mysock351C]

I LOVE those RadioShack solder suckers! Have two of them and they are absolute wonders for desoldering pretty much anything.

[@SeekingTheLoveThatGodMeans7648]

Frustrating yes, though it's obviously better to have the necessary tangle with the frustration BEFORE you get it to the conference. Wishing you and it a molto bon voyage there and back.

[@TheHylianBatman]

Great work! You should be proud!

[@frankowalker4662]

Great solution to the flicker.

[@cpunut]

I've been self employed in embedded HW/SW design for 40 years and we think so alike, I know what you're going to do next before you do it 🙂 I don't know if you or anyone remembers PMMI S-100 modems in the Altair age, well I was a big part of that company (understatement). If you ever get in the Dulles Airport area, we should meet, I have a feeling it would be fun and you would enjoy seeing my setup here. Love the animals, sorry you had to go through that tough time with them!

[@leegleason]

Looks like the screen blinks whenever it would be trying to stop the incoming data stream, when it needs to pause at higher speed to draw the screen. Does your terminal cabling include pins 4 and 5 (RTS and CTS)? They might be needed for flow control. The ADDS 200 manual recommends they be used for higher speeds.

[@8bitwiz_]

The interesting thing is, at [16:40] you can see it flickering even when there is no scrolling. If flow control wires weren't connected, and no data is lost, was flow control even happning? Also, this is a really primitive UART, with the control and status on individual pins, rather than having bus-readable registers like a 6850 etc. It certainly doesn't have the ability to buffer more than the most recent byte received, while it shifts in the next one. The only good way to avoid losing data at 9600 baud with 8-bit CPUs of that era (the code is clearly 8080 code) is to receive it in an interrupt that writes to a FIFO in RAM. Maybe there's a bug in the interrupt handler when it has to go really fast. If there is some kind of simple "blank everything" output for the display, maybe that somehow gets tickled by accident?

[@leegleason]

@@8bitwiz_ Well, that's as may be. But, the ADDS 200 manual says to connect RTS and CTS when operating at higher speeds. I can't think of a reason to do that if not for flow control. And too many interrupts for handling characters incoming can interfere with other things that have to get done. Take the DEC VT100, for example. Smooth scrolling required flow control at higher speeds, jump scrolling (which was faster) did not. II. Distances greater than 50 feet, speeds more than 2400 baud PIN SIGNAL PAIR 2 BA-EIAOUT Pair 1 AA-GND 3 BB-EIAIN Pair 1 GND 4 CA-RQSND Pair 7 GND 5 CB-CLSND* Pair 7 GND 8 CF-CARDET Pair or 11 SCA single 12 SCF* Pair or 20 CD-DATTRY single 6 DSR Data Set Ready

[@glonch]

Well done!

[@jamesross3939]

Wow! Very interesting!

[@vincerosso4161]

Hi David, I watch all your videos avidly, and in spite of the fact that I am an electronic product design engineer with over 40 years experience, I am in awe of what you accomplish. I particularly like this hardware fix you devised to alter the baud rate from 9600 to 4800, however you went about this in a very roundabout way, given you did not want to alter the mux board you could have accomplished this with one wire link and lifting a pin on the U_K1. Since I can't see the whole schematic I have to make an assumption as to which pin has the 9600 baud signal, all you really had to do is remove the 9600 baud from U_K1 and substitute the 4800 baud signal. If the 9600 baud signal is on pin 12 of U_K1 all that you needed to do was cut pin 12 near the PCB, bend the IC leg up so it is free of the board and link from pin 13 to pin 12, this means when the selector U_1K is in the 9600 baud position the signal is actually 4800 baud, to reverse the mod, remove the link between the U_K1 pins and link from the lifted pin back to the PCB pad that it was originally connected. No risky de-soldering and only only a pin lift. Keep the videos going, I enjoy them so much.

[@peterstrezev8159]

Looking at the schematic, you could have pulled out U_L1 instead, and replaced it with a socket. This way, your breakout adapter would have to only contain the DIP switch and 3 pull-up resistors

[@MarcelHuguenin]

That was a great hack there to get the default 4800 baud. Enjoy VCF South-West David!

[@gbclab]

Simply...wow!😮

[@CoreyDukes]

I thought the correct tool to pull chips from a board was a hammer.... 🙂

[@UsagiElectric]

Only when they're already socketed :P

[@mrcampbell7674]

Fun fact: "ram chip" doesn't refer to installation method

[@rtechlab6254]

Thought. If the centurion supports flow control you could use a micro like an STM32 with multiple UARTs to do the speed change on the fly and signal the centurion to stop of the FIFO fills. Should be simple and potentially useful elsewhere

[@PCBWay]

That's IMPRESSIVE!

[@brucebuckeye]

Brilliant! 🐰

[@joebonkosky5880]

Check with JRF magnetics for the hawk drive head. They may have a replacement part or they may be able to rewind the coils.

[@williamsquires3070]

Yeah, I’ve got that same Radio Shack desoldering iron. Do you have a source for these, Mr Usagi? BTW: I use the “4 second rule” when desoldering power-plane pins on an IC (or transistor). Squeeze the bulb, apply the iron, jiggle it about to free the pins, and wait 4 seconds for the solder on the component side to melt, then I let go of the bulb. Particularly tough dogs get a new application of fresh solder. 😀 I don’t even remember how long I’ve had that desoldering iron, but a couple of decades is my guess. And the squeezy-bulb gives your hand a workout!

[@SeanBZA]

You can buy them still, they are cloned by a good number of companies now, though I do suspect they all come from the same Chinese factory with a brand name stuck on.

[@8bitwiz_]

I see some on Amazon for $35, but it's currently listed as "Only 2 left in stock". Whether that means there will be more to restock is a good question, but I certainly hope so. What is really important is being able to get replacement tips, because they do slowly wear down with use. (or quickly, if you don't tin the tip first!) I tried some tips that I found on Amazon a couple of years ago, and they seemed to work as well as the originals from Radio Shack. Keep in mind that it is important for the tip be flat to keep the suction working, but I can usually file a tip down a few times before it is worn out. When working on important stuff, you should really switch to a fresh tip.

[@8bitwiz_]

Nice job on the little board. It doesn't even look like a rat's nest on the other side! (I made one for ADM-3A lowercase that does look like a rats nest of all white Kynar wires.) As for the firmware issue, is there somewhere that you have these ROM dumps that people could take a look at them? (Bonus if you can get dumps from people with other versions of the terminals.) I do love disassembling code, though I haven't had as much time for it lately as I'd like, and a subtle problem like this is harder to figure out without knowing the nature of what it is actually doing wrong.

[@UsagiElectric]

It's been a long time since I soldered anything on perf board, I should have just CNC'd out a proper PCB, I forgot how difficult it was to make compact PCBs like that! Still, I think it worked out alright. For the firmware, we'll probably dig into them in more detail after VCFSW. This was mostly a stopgap to get us through the event. With only a few weeks to go (and one of those weeks being consumed by a work trip out of country), I didn't have time to dig into it deeper.

[@wdolgae]

If you do a lot of thru hole rework, look for air-vac engineering. I have a desoldering iron from them, it uses and air compressor to create a venturi effect to remove the solder.

[@DavidLightman]

I love software problems fixed with hardware mods xD it is the most reliable and simple way, i was about to suggest to program a pic with 2 serials and convert speeds, but that would be 100 times more complicated, your solution is simple and elegant! fantastic! i loved it. please do a video of the format of the fixed disk wouldnt be possible to use the format utility from the other centurion? i know it's a different processor but use it as a guide it would be a lot easier than start from scratch IMHO.

[@johnvanwinkle4351]

Great job on the hack! I like the look of it and it works…..😀

[@kuukeli]

thank you

[@russtuff]

That solution is hardcore

[@vilhjalmrwt]

Great video and a cool hack

[@hamesparde9888]

Man that's a cool calculator. I don't know if one was ever made, but a 70s style programmable graphing calculator with a VFD would be super cool.

[@kelli217]

I think Tech Tangents has a video where he’s got an HP big programmable calc sending output over the HPIB to a graphics terminal of some sort that responds to HPPCL.

[@hamesparde9888]

@@kelli217 that's pretty cool, but I was thinking of those 70 pocket calculators you can program with basic or something.

[@horusfalcon]

Man... you definitely had to think out of the box on this one. Some USB to RS-232 adapters do not support RTS/CTS, so your test setup might not be including the lines needed for it, or may just not be responding to those signals if they are present. I see the CTS LED on the breakout is lit, but not the RTS... does it change state during operation?

[@UsagiElectric]

Hmm, you know, I didn't think about the converter not having one of the lines internally. I'll have to give that one a test! But the fact that the Regent 100 can support the higher speed while the Regent 200 can't is still mighty suspect to me. Also, the Centurion MUX card doesn't properly support RTS/CTS, so we'd have to find a way around that limitation anyways.

[@Sven_Dongle]

@@UsagiElectric I used a lot of finicky UARTs for old gear. The cheap converters are trash. The one that never failed me was the Keyspan. If you want full control and to remove all doubt, cobble your own with the MAX232 chip. Its a complete package, just solder 4 capacitors. It gives you complete control over CTS, RTS DTD etc.

[@highpath4776]

@@UsagiElectric Better to have a dodgy display than an incorrect input or store / calculation in ones computer !

[@ChristopherHailey]

I think a baud converter would really do the trick, they are about $75 but then again the hack is free. A converter can step down the rate and has buffer and flow control support. They can also convert RTS/CTS to XON/XOFF.

[@8bitwiz_]

@@Sven_Dongle Keyspan (now owned by Tripp Lite) has been and still is the best brand of USB-to-RS232 adaptors. I remember that around 2010 or so, they still had drivers for an old one I had which was a dual Macintosh miniDIN-8 adaptor from the '90s. Most companies would have EOLed and wiped from their web site something that old without even trying to support it.

[@OtherWorldExplorers]

You should print up all your instructions and settings on archival paper. And then put it in a Ziploc bag. And then put that bag tape to the inside of the plastic of the monitor. So that way anybody who has to work on it has your information.

[@bradleyphillips5254]

Hi David, love your channel, please tell me what model your desoldering iron is, thanks

[@UsagiElectric]

Just search Amazon for radio shack desoldering iron and it should pop up!

[@FasaFeu]

Let there be hawk for mankind

[@akostadinov]

My father used some hard drive platters like these as aerial analog tv antennas at the time...

[@robot797]

good job dude

[@jeromethiel4323]

I always find hand designed PCB's to be just interesting. No machine routed that, human beings had to sit down and design how those signals propagated around the PCB. That, and most of those old boards were double sided, at best. No multiple layer PCB's back then! Well, there might have been, i don't really know, my personal experience is double sided was as complex as they got.

[@Maxxarcade]

When swapping the ROMS around, it looks like one was an EPROM where the others are different types of mask ROMs, which tend to have slightly different pinouts. Perhaps the board needs to be jumpered for whichever type of ROMs are used? At least that's what I'm used to when fixing arcade boards. Maybe you could dump the known good software and program it back onto a couple standard EPROMS, then configure the board to use those.

[@AnotherFreakingDude]

*_HEADS_* : loaded *_MY HEAD_* : unloaded

[@PedroOliveira-lz3mk]

You may connect the hawk drive to another system and format it there... Just an idea... BTW, I love this channel.

[@JoeGoesXtreme]

How do you know that the coils are bad?. Have you considered if it could be the transistors that switch them on and off are bad instead?

[@jonorgames6596]

31:28 best part :)

[@UsagiElectric]

Without question!

[@ViegasSilva]

@@UsagiElectric did he went to the supermarket and bought himself a love doll? 🤡

[@TechneMoira]

Clever hack :) I wonder if there's either a spurious screen refresh signal or maybe an extraneous CS signal at the UART at 9600 baud ? Either way, the solution may be "hacked", it's certainly a nice display of resourcefulness :)

[@MauroTamm]

Time to figure out if new heads can be manufactured. It doesn't look too complex or specialised.

[@danek_hren]

1:21 "it's broken again!" :D

[@elbiggus]

Given the track alignment is pretty much drive specific would pre-formatted platters actually work?

[@UsagiElectric]

The track alignment for the fixed platter is drive specific, but for the removable platter, you'd normally use a CE alignment pack to make sure all CDC Hawk drives were aligned to the same specification. So, pre-formatted removable platters totally could have been a thing the dealer did.

[@Sven_Dongle]

You've got an allstar disk!

[@andrewdunbar828]

Time to disassemble!

[@n2nby]

Stupid story about the PCB boards for the ADDS Regent series. All board chips had a name legend identifying the chip used. The son-alert which sounded local bell (aka teletype like) had an ID legend it said "Beep Beep" but it could not be read because the sounder cover obscured it. Someone in sales got peeved when a customer inquired about it. Engineering services got a little reaming out for it. Sales people are just too stiff, loosen up dude and dudets.

[@bborkzilla]

The IBM System/23 didn't have a format command - you had to buy pre-formatted floppies (8" btw) from IBM (the company I worked for bought them from Quill). 1980's version of the "no cyan" printer fault of today.

[@andromedaturnbull3512]

I believe there may have been a reason for that other than vendor lock in; some of the earlier IBM MFM floppy drives had a few important factory-written sectors on the disks that were somehow critical to how the drive hardware functioned but I can't remember why/how. The drive hardware at the time might have been too basic to selectively avoid totalling them during a format error, and so it was just less work at the time to get the user to buy the disks pre-formatted.

[@kelvinclements]

Drive format - I might have missed something, but can't you connect a long cable from the big centurion to the duff hawk drive and use that to do the format? I known you have a different os on both machines, but sure the format process would be the same for the drive.

[@pengiswe]

If locking the address on the multiplexer, wouldn't it have worked just removing the chip and add a jumper wire from correct input to the output instead of the board?

[@VandalIO]

At higher baud rate the signal wasn’t very pretty … maybe that’s causing it to flicker ?, I would suggest probe the clock pulse of the other one and see how it looks ?

[@georgestephens2593]

Hi David. Swiss army knife guy here. About the screen flickering... I'm wondering if the software bug can again be fixed with a hardware hack. I'm thinking that you should try to review the video frame by frame while the terminal is scrolling at 9600 baud, then count the number of lines that scrolls between the 'flickers' (which looks like the whole screen blanks). This could be a clue to the problem. Perhaps the video memory and the data being fed to the video memory have some sort of a clock conflict at 9600 baud, preventing the display output to the screen after a certain number of line feeds. It may be an easy fix with a bit of TTL logic. Just a thought.

[@user-sk7ru3du9k]

Maybe in the head only switching diodes dead, not a coils itself. You can simply check it with electrical tester

[@SeanBZA]

More likely the wire failed, it has a lower time constant than the diode, and the diodes are on the head amplifier on the main board. These wires are thinner than a human hair in the head.

[@eli3963]

Those parts are so tiny and fragile, it's no wonder we had to start sealing HDDs.

[@Professorke]

Have you tried changing the clock on that monitor, by plugging in another crystal?

[@jwhite5008]

I think you can temporarily connect the hawk drive to system6 centurion, and format if from there the OS is different but physical drive format should be the same

[@eDoc2020]

Nice mod but you didn't need to make your daughterboard. After socketing the clock rate multiplexer chip you should be able to use a jumper wire between the 78kHz input pin and the output pin.

[@humidbeing]

You can order square and round stock polyurethane rubber in all different durometer ratings from McMaster.

[@Qyngali]

Maybe the newer ROM needs all 3 ROMs to work properly since it's possibly bigger? So try installing a socket in the empty ROM slot and try with all 3. Worth a shot.

[@KameraShy]

The format program may have been removed as a security measure, to prevent curious or inept users from destroying the system. In the IBM mainframe world, it is important to keep certain utility programs away from general users and programmers. Only system programmers and operations should have access to them. In this case, I wonder if the program might have been renamed and still be present, just hidden under a different name.

[@jeromethiel4323]

Very curious as to why you wanted the OS on the removable platter instead of the fixed platter. To me, it would make more sense to have the OS on the fixed platter, so it's always there and available, and used the removable platter as a data drive. Would love to know the reasoning behind that decision.

[@wmrieker]

Question at this point: If you use 9600 baud but write a program that throttles the output to 300 chars per second, does it still flicker?

[@douro20]

Didn't know Gore made ribbon cables. I know they make all different types of RF cables.

[@jakobfindlay4136]

Really fighting making a bad joke about the bad head xD

[@evanbarnes9984]

Bad head is better than no head! Especially considering how rare these are.

[@Alexis_du_60]

It's sure gonna cause a few headaches, and uh... ...I'll see myself out for this terrible pun.

[@michaelterrell]

Are both terminals running the same CPU clock speed and processor versions? It appears there were three versions in 3, 5 and 6 MHz.

[@kevincozens6837]

Is the missing format command on the CPU5 based Centurion? I thought UE had a full copy of the OS for CPU5. Is the logic board of the ADDS Regent 200 a CPU based board? If it is, what CPU does it use? If it is a known CPU the ROMs could be disassembled.

[@kenromaine2387]

We did not know the JCL [ .FORMAT ] was missing till we needed to format the Hawk.

[@ChrisSmith-tc4df]

In the upper corner to the right of the keyboard connector, you can spot a P8255A and more importantly, a P8085A next to it. Notice that the crystal traces take a detour around the 8255 to get over to the 8085. The 8085 has an identical instruction set to the original 8080 save for two additional instructions.

[@kevincozens6837]

@@ChrisSmith-tc4df It wouldn't be hard to disassemble the ROMs containing 8085 code. A little bit of time with a multi-meter would allow working out the memory map for the peripherals in the terminal to aid in commenting the disassembled ROMs.

[@Wizardofgosz]

Flickering screens? Reminds me of my early MSDOS days.

[@ChristopherHailey]

Yikes, CGA.

[@dennisolsson3119]

The breakout box you showed didn't cross over RTS/CTS etc... But you might have done that off camera

[@RadioTeal]

Just wondering if it is possible to find a "good" set of roms for your ADDS 200? If you can find good rom chips for it, perhaps you could copy them? I think the restoration folks would be interested so I would reach out to the museums and folks that are fellow enthusiasts. I realistically know this may not be possible, but you never know unless you ask. Love your vids.

[@root42]

17:53 hmm. The unpopulated socket has an Intel 8251A UART on the other board. Maybe that IS part of the problem? Having a proper USRT would probably help in the communication...

[@n2nby]

That second 8251A was for the aux port. Not required for normal ops. Sold as an option for serial printers. Except for software flow control it was output only.