I've long repeated a quote I saw in my early days of accessing the internet: "Beware of programmers who carry screwdrivers." I've since amended it to include "or sledgehammers." Impatience and sheer size means I tend to grab the biggest tools available by default.
I worked for Intel in chipset validation during the initial rollout of PCIE, at least for desktop and mobile chipsets. We had a multi-day class then to go over the details of the differences between standard PCI and the new PCIE and how to go about designing tests to help isolate various features for testing. The first two rounds of that testing were PTSD inducing at best, with four consecutive 100+ hour workweeks on one of them, mostly because the chipset internal design changed so dramatically from the last PCI/AGP chipset to the first PCIE ones and nobody's device drivers worked even in isolation, much less together. I really don't miss those days much :)
@@squirrel1620 I was at least part of filing in excess of 400 issues against the Intel graphics driver over the course of about three years, then moved to CPU validation. When they decided to integrate the graphics into the CPU in the Core i series, that was just about the final straw for when I couldn't take it anymore and had to return home to Indiana.
@@VivekYadav-ds8oz I can't say. I had some good bosses there, but living in California turned out to be too much for me, so I left in 2006 or so. When I started my newest job here in Indiana much more recently, one of the projects I could have been assigned to would involve travel to both coasts for shipboard installations. I replied to my boss about that saying that I was reasonably sure that the next time my body crossed the border into California, fully half its atoms would spontaneously convert to antimatter and annihilate the other half and that at my current body weight, that would be an approximately 2.2 gigaton explosion :)
Great content Dave, as an old time IBM mainframe assembler programmer, I find it interesting how I/O grew to be similar to mainframe I/O, with several data transfer functions offloaded to more discrete hardware. Perhaps I am oversimplifying, but with mainframe disk drives had to be attached to an HDA (disk actuator/controller) which basically is like the bus services in the pc world. When we needed the fastest I/O possible, we could bypass the generic get and put type routines, we could construct a CCW (channel command word) with the raw data to move and the instruction to the controller on what to do. It was pretty heady stuff back then as we found a way to drive IBM's 3800 laser printers at a flat out speed, whereas the routines that IBM provided were junk and kept pausing after each buffer transfer. Those were some good times. Now everything is so fast and obfuscated, it doesn't matter much anymore how you code.
I never understood why a mainframe had "better" I/O until I wrote this episode, really! One question though - if you have a shared bus like that which any device can become master of and communicate to any other device, don't you saturate it pretty quickly if you have a lot of devices?
@@DavesGarage: And the adapter pictured in your 55SX is for 5250 terminal emulation - AS/400 and System/3x "minicomputers". Microchannel was also multi-processor capable (it's been 35 years since the initial announcement of PS/2 models - 'Computer Chronicals' has an episode where Chet Heath demonstrates a second 286 processor card on a Model 60) and IBM also repurposed many base systems as hosts of dedicated adapters for mainframe and minicomputer controllers, terminal emulation, and specific use-cases (medical, financial, business, and educational markets). As they say, welcome to the club...
@@DavesGarage : I/O would stereotypically be the most limiting factor, and in some cases data wouldn't even need to touch the main bus, but instead just get shuffled from e.g. one RS232 line to another.
@@DavesGarage I too wrote IBM assembler code, but for a non-IBM operating system called MONITOR that originally ran on ICL S4 machines, which were a licensed copy of the RCA Spectra which was a (partial) clone of the original IBM 360 (RCA almost went broke designing that machine). This was back in the days of real core storage (that is ferrite core). It was an OLTP system which ran the air cargo systems in the UK (called LACES) and automated customs clearance systems (DEPS) and was running in the mid 1970s. It was 24x7 and had things like software RAID 1, transactional logging and we ran up to 1,000 terminals on a system with 768 KB of memory and which could barely manage 1 MIP. I got very familiar with the IBM channel architecture (and the detailed difference between it and the RCA semi-clone). The IBM I/O channel architecture was designed in the days when CPUs were very slow, so that they offloaded I/O processing to controllers within the channel itself. On an IBM mainframe, to perform I/O, it was necessary to construct mini programs called a CCP (Channel Control Program) out of what were called CCWs (Channel Control Words). CCWs are a very stripped down set of instructions which were executed in channel controller, which actually directly read this mini I/O program from the mainframes memory. From what I recall, the actual IBM instruction was called SIO for Start I/O. The channel controller would read the Channel Control Program and execute the instructions therein. The CCP would contain CCWs for things you might expect, like read and write data, setting the device address on the channel and so on. However, it also contained some extremely primitive conditional branching instructions, which meant it was possible to generate loops looking for a particular status. Of course, only one CCP could be actively being processed at a time by the channel controller, which could cause issues, and were dealt with by some other features added later. As an example of how the channel architecture was designed to take load off the CPU, it could be used on disk drives to implement some aspects of key searches for sequential files. That's because IBM implemented disk drives using something called CKD (Count Key Data). That low-level formatted disk tracks into variable length soft sectors (for want of a better word) that comprised three parts; C for count, or sector number in track, the K for Key part and the D or Data part. This was entirely soft-formatted and a program could generate a CCP to format a track in whatever form it cared to do so. On IBM operating systems this is literally what user programs could do and on old programs it's at the user level that these CCPs were put together (although almost invariably by library routines) and an executive call was made to issue this channel control program. Needless to say, when multi-user operating systems came along, then IBM had to retro-fit security by vetting these CCPs so they weren't doing illicit things, like wandering off to parts of disks that that user id had no write to access. I mean this quite literally; for the legacy parts - which means a lot of mainframe programs, access control at the operating system is by physical, pre-defined parts of the disk. Later environments would provide more conventional file access control, but this came very late and for legacy reasons all original access systems are there and in use. Of course, CKD is the opposite to Fixed Block Architecture, but it was produced to support some sorts of what would now be considered very primitive access methods without troubling the CPU too much. Most obviously, this was on indexed sequential files. As a simple example, when a data block was written, it was possible to put certain key data, such as the lower key value of a record within the block into the key field. The channel program could then be set to tell the controller to read the next "K" field, compare it to a value in computer store and conditionally execute one of the two next CCWs depending on the result. One of those CCWs might cause the CCP to loop back (using a CCW that I think was called "transfer in channel or TIC") so it would repeat for the next key field. The other CCW might be the instruction to read the next data (D) field to read the data and then a CCW to terminate execution, which would cause the interrupt back to the mainframe. It could get a lot more complicated than that. Data read from a disk block could be put into mainframe memory and be used for things like causing the disk head to switch to a different track on the same cylinder or cause a seek to a different disk cylinder. In principle, this whole complicated set-up could be used to allow a multi-level indexed sequential search to be performed by the controller, using multiple levels of indexes. Of course, in reality, it was all extremely difficult to do and not many applications would structure access techniques of their own and the great majority ended up using library routines of standard access types. The same sort of thing could be used for driving large numbers of terminals, typically driven by synchronous comms lines. A CCP could be set up to poll lots or them, with the work being done by the channel controller rather than the CPU having to poll each in turn. At the hardware level, the active execution of a CCP against an individual device meant that the entire channel was dedicated to just that device. This was clearly a bad thing when multiple disks are involved (and you would not have disks and non-disk devices on the same channel). So what IBM added was the ability to (temporarily) disconnect the channel controller from the CCP and then reconnect later. On disks this was using something called RPS or "rotational position sensing". Basically the CCP would contain a CCW that told he controller to disconnect from the CCP until the disk came to a particular rotational point and then reconnect the CCP. If the channel was busy at that point, you missed the rotation - something called an RPS miss - and really bad for I/O response times. So, later, IBM introduced dual-path connection so that a set of disk drives could be on two separate paths and the reconnect could be down either channel which, statistically speaking, had a radical effect on I/O performance time. On a channel at 30% busy, the search latency would double because of RPS misses (as there was a 30% chance you'd have one RPS miss, a 9% chance of two RPS misses, 2.7% changes of three etc.). With dual path reconnect you could drive channel usage up to over 80% as well as having twice the bandwidth. Needless to say, real CKD disks have been long, long dead. Instead what happens is that IBM mainframes are invariably connected to huge disk arrays and controllers from the likes of EMC or IBM themselves. Those contain masses of HDDs and SSDs with vast non-volatile memory arrays and then they emulate all those arcane features of IBM CKD disks from the 1960s and 70s using fixed block disks. This reply has been a bit long (to put it mildly), but it's triggered a lot of memories of the apparent insanity of all this stuff, all designed in the days when every CPU cycle was precious, and the engineers tried to overcome this by offloading things, but in a rather rigid manner which actually impacted on software. Offloading is now the norm, but it's not done by trying to create programs in system memory to be executed by something that's part of the I/O bus system.
I think this video actually explained a problem I encountered decades ago but was never sure what caused it. While going to college (late 90s), I worked evenings at a datacenter for a small local bank. One of my duties was to download the ATM transaction info for the day from the national service. Doing that required a very ancient MS-DOS-based PC with a special encryption card that I was told cost $12,000. They told me that they attempted to upgrade the PC at one point, but that encryption card would fail in anything newer. I imagine it must have been due to the bus speed issues, as they weren't changing the software at all, just trying to upgrade the PC to reduce the chance of it dying on them unexpectedly from old age. They did say it was because the new system was "too fast" but I couldn't imagine why that would bother a card like that. They weren't willing to buy a newer encryption card, though (banks are super cheap, we used the last running example of an old NCR mainframe, so old that when the 2nd-to-last user of that model replaced theirs with a PC, they gave us theirs for free if we would haul it away. And that's how we got a DR setup.) It was still on that ancient PC when I left in 2000.
One of my earliest jobs was doing phone support for a company called Media Vision, troubleshooting hardware installs of their multi-media kits. Explaining IRQs and DMAs over the phone to grandmas was a challenge I wouldn’t wish on my worst enemy.
Yes, in the early days of the internet, they used to send all our transactions in plain, text across the networks. The SWIFT system, hadn't been updated for 20 plus years at the time it was done. Yet this was used by the entire financial system. Then again, what do you expect from people, that live in a fantasy land where they can lend 1000 to 1, and expect things not to collapse. But better than that are told, congratulations for crashing the world and 53 million jobs, here's 194 million for doing so. Computers not important, no wonder, a calculator might be to complicated and expensive. :)
I loved your story about using Laplink to image machines. That's exactly how we used to do it back in the 80's. Later on once ethernet became a thing, i wrote my own boot disk formatter/loader/installer. We'd shove an ethernet card into the PC being built and boot from my custom floppy which would partition, reboot, format and then go to a menu where you'd select the items to be installed (DOS, Win 3.11, specific video and sound drivers and the like). These all resided on our Netware server. For laptops or machines that we weren't able to shove an ethernet card in, for whatever reason, we would use a Xircom Parallel Port ethernet adapter. My custom boot floppy contained appropriate drivers to suit. All this over our trusty 10Mbps coax network. Cheers 🙂
It took a bit to realize imaging software was the easiest way to refresh a system that was starting to show the ravages of age (not to mention the week of hell waiting for all the system updates or installing some suspect software. Save an image in a pristine state and you are good to go.). It took about a year later from being introduced to the idea to see how system builders would implement this to mass market builds. Thought it was ingenious.
@@quintessenceSL We started using the "Ghost" product by Binary Research in the very late 90's and early 00's to image machines for deployment. This was a big time saver for us. Ghost also supported multicasting, so for larger deployments we would image 10 or 20 machines simultaneously. This was essential for Windows 95 deployment as my previous file copy deployment method no longer worked. This was before Windows Update was even a thing 🙂 Nowadays there are lots of tools available for SOE management and deployment. MDT would probably be one of the most commonly used, however with more cloud deployments taking place this is starting to change over to Windows Autopilot.
1:05 - my answer is 'NOWHERE'; it's not moving! Reminds me of a very old *Bert and I* bit. A guy is lost and he asks "Where does this road go?". His reply: "The road don't go nowhere, it stays right where it is!"
While that is a really good answer also similar to mine, you have to look at the question from multiple perspectives. The formal/business perspective in wich case it would be always right because the "right" position is portrayed by elements of success, positive remark etc, and the human type perspective in wich case you have to answer off your instinct because usually that's what they're looking for, to understand what kind of a human you are. Are you innovative, are you stuck in your own perspective are you an open person etc
When I heard "Peripheral Connect Interface" I thought "what the hell, isn't it Peripheral Component Interconnect"?? Looked it up and yeah, I remembered correctly. Thanks for the trip down memory lane.
I had to pause the moment you said laplink. RS232 null modem cable? Hell yeah, such a godsend for transferring files larger than a floppy "back in the day". I remember building the parallel version, I've probably still got it in "the box of cables that I'll need one day".
Today's episode was truly both informative and entertaining, thanks again Dave for the ride down memory lane in the yellow buss, I missed the bus question so I ended up in software and hardware development and not finance....
From across the pond and back in time.....I started my engineering life with a company called Research Machines (RM - still going but into H/W these days) who were heavily vested in IBM compatibles for the education market. When MCA came out, and for the reasons of cost reduction as well as potential IP, they decided to reverse-engineer the whole PS/2 chipset using the "clean-room" techniques of the old BIOS days. Two of their PC newbies (me, J, and another guy who I'll refer to as S) got sat in front of a model 55SX (and some others), given a pile of logic analysers and oscilloscopes and were told to go figure out what was going on inside their chips - warts'n'all (and yeah, IBM's implementation was pretty warty). 6 months later, we had it and a team of 6-8 H/W engineers set about designing a 2-chip chipset to implement it. Using schematic entry on not enough clunky Sun workstations we worked 24 hours a day in shifts, consuming pizza and coke in a dark, badly air-conned room during most of the summer (air-con units would occasionally drip and take out a workstation and the odd errant and unnoticed pizza slice lent a piquant odour to the place as it slowly toasted on a hot PSU). But we did it. IBM even sent some boffins to evaluate it with the alleged intent to buy it (but I suspect it was a patent-infringement trawl). We dastardly duo were looking forward to the dawn of a new PC age with the names of S&J emblazoned on the nerd wall of fame (it's more of an oversized brick in front of which someone has probably put a dustbin/trashcan by now) - but then PCI came along with ridiculous technical and commercial advantages, the box-shifting knock-offs took over the market and not long after that RM closed its H/W engineering section and we all got the iron-pyrite handshake. Having spent so long developing what was almost instantly a dead dodo, I moved onto working on developing bleeding-edge networking H/W..... token-ring networking that is at a UK company called Madge Networks both of which also rapidly did the extinction tango. I later went on to work on some ground-breaking networking chips (ethernet based this time - I try to learn as I go) which would drive some of the latest advances in internet infrastructure...... at a company called Nortel. Sigh. Anyone out there fancy using me on their latest, ultimate-tech project.... ;) J. For Jinx >:)
I started on the ZX81/Spectrum but have fond memories of the RML380Z. I was even allowed to borrow it for the whole school holiday, I was glued to that green phosphor crt apart from when my friend had a new Atari 2600 game or we'd cycle out to an unexplored wood. Edit: 52 now. Glad I experienced some of the "early" days.
@@georgeprout42 Yeah - it was more fun back then. Like you, we had a 380Z at school and I remember bootstrapping the COS from tape. We had a kid in the class who could enter the binary codes from the prompt to hack the thing and change the prompt to always be the teacher's nickname - Noddy. Drove him nuts. Then a ZX81, BBC-B before building first PC from busted-parts bin at RM. Learnt a lot that way though.
Nice to be refreshed on older bus standards, so thanks for the video. My first computer was an Amiga 500. Later I moved to PC's and my first was a build with an Intel 386 SX CPU. Unfortunatly I'm unable to recall the other spec's, but remembered I could only get 16 colors on my monitor so I had to put in some more memeory later so I could enjoy 256 colors. And that was just great in those days 😀
When I interviewed at Microsoft, the interviewer drew a riddle on a whiteboard and had me work on the riddle for 10 minutes while they checked their email. When I finally said I didn't know the answer, he started to show me the answer and then said "Oh, I drew it wrong." Didn't get that job even though I was a temp already doing THAT job for 6 months. Eventually got on full-time somewhere else in Microsoft.
I remember using FastBack Plus, which used DMA to copy data from the hard drive to floppy at seemingly miraculous speeds. This was on a Tandy 1000 TL and its 720K floppy drive. The 1000TL was a bit of an oddball machine, using an Intel 80286 but equipped with XT-style ISA slots. My hard drive was a Seagate ST-232 half-height MFM drive mounted in the 5 1/4" floppy bay, using a Western Digital WDXT-GEN2 controller.
PCI bus arbitration works by giving each device it's own bus request line (REQ#) and bus grant line (GNT#) in addition to the shared command, data, and address lines. The bus master would assert REQ# when it wanted to do a transaction on the bus, and the root complex would assert GNT# once the bus was free. With PCIe, because each device has it's own lanes, and because it's a packet switched network instead of an old-school bus, there isn't much arbitration apart from condensing packets from multiple lanes onto one lane inside of switches or the root complex (because the interface between the root complex and CPU is also a packet switched network most of the time these days).
This video brought back all the bad feels. All those hex addresses bringing back terrible memories of configuring some hardware that promised so much and yet mostly brought a day off yelling at MS-DOS
This was a great episode! Including the backstory on IBM's actions, I had thought IBM was just like and everyone you can all use ISA made by us for free... and that's where the term IBM compatible came from. I don't know where I got my theory from. I'm just glad that you straightened me out.
Dave, thanks so much for presenting all this interesting information. As usual, your delivery is perfect. Listening to you talk about old computer hardware is pretty much the highlight of my lunch breaks nowadays.
That bus question is easy for me. (I am a transit bus mechanic) When I first got into the trade out of instinct I would constantly walk to the street side as the picture shows to drive the bus instead of the curb side. Back in 2000 I got a job installing AT&T @ home high speed internet in the Seattle area which changed to Comcast HSI shortly thereafter. It was a daily routine to go into customers homes, run a new cable drop from the pole to their computer room. Hook up a cable modem, change the PC name to whatever was on our work order so it would authenticate and work. Opening up peoples computers and installing an ISA network card was standard practice. When ME rolled out it became almost a weekly thing to have someone's computer BSOD during the ISA card install. Ahh the good ol' days.
@@tomwendelken3953 Just for fun! Since I was a kid, I wanted to make stuff like this. Now I understand parts of it, so it would be fun challenge + learning experience for me! Like today I was finally able to run my bootloader and jump to 0x10000 and print a few letters. It's fun!
BTW, FTWAI and IMO OFC (TLAs FTW)... I've worked on developing H/W for all these bus types (up to first-gen PCI-E anyway), and the reason for the big jumps in speed is down to the equally big jumps in technology used: ISA, EISA, MCA all use "asynchronous" busses where basically the controller goes "I've got something to do" and eventually something notices this and replies "Eh? What? Oh, OK", controller then says "well get on with it then" and responder says "yeah yeah - OK, done it". Each stage includes a lot of waiting around to allow time for stuff to actually happen. There is no notion of a clock and everything is just running at its own leisurely pace and it's about as efficient as a 16-member committee trying to decide stuff in the pub/bar. PCI is a fully synchronous bus where all parties are continually awake and in step with each other so when a controller wants to do something it generally just goes "do this..." and proceeds to send or expect data on every clock cycle - it's up to the responder to say "hang on a bit" if it needs to. A whole pile of data (well OK, 16 or 32 bits) is transferred on every step and actions can consist of multiple back-to-back transfers (bursts). The clock speed is only limited by how long it takes that whole load of data bits to all settle down together and this is quite hard to do because physics. Think how long it would take that committee of 16 people to find and agree on which table to sit at in the pub/bar. Plus, data can only go in one direction in any one transfer (from PC to card or card to PC) - you can decide things in the meeting or someone can go to the khazi/washroom but not both. PCI-E and subsequent variants are effectively a collection of 1-bit serial ports (think USB/Firewire/Thunderbolt/blah/blah/blah) which are made of 4 wires - two in one direction and two in the other (there are 2 in each direction because they work as a pair because that can go faster because, again, physics). This way, there is no need to wait for clocks and data signals to settle down and behave each time they change value - with some clever H/W data rate is only limited by how fast the transistors can change state and how fast a signal can propogate down a wire. Compare how long it takes you on your own to find a table in the pub/bar compared to the PCI example. Having separate wires for each direction means you can also transfer data in both directions at once buy only if your clever about it (and enter a quantum state where you're both taking decisions and visiting the khazi/washroom at the same time).
I had an IBM PS/2 with its 286 CPU and a sound blaster card. I was given this small daughter board to evaluate as an upgrade from the 286 to make the PS/2 become a 386 computer that plugged straight into the CPU socket. It really provided a performance boost to my computer but the Sound Blaster no longer worked. It bugged me for the rest of my life what caused the lack of sound from my PS/2 speakers... now I know why. Thanks Dave!
Working at an IBM plant for decades I had a ton of experience working with microchannel bus machines from PCs to PC servers, to the risc systems. I had a fairly substantial library of reference disks (1.4 meg floppies) which were required for setting up the cards. I also had access to stacks of surplus machines, cards, and token ring cards, cables, and hardware, so my first choice for setting up networks for my company (we were a contractor that provided a service at the IBM plant) was Slackware Linux. It came with a kernel setup for installing with built in microchannel and tokenring support (I was too much of a noobie with Linux at the time to know how to set up my own install disk set using a self compiled kernel, and that was before modular kernels where they were compiled monolithic which I learned to do later).
@@IBM_Museum The operating systems I worked with over that period of time were DOS, OS2 ver 1 and 2, Linux, Win 31, Win 31NT and on up, I also set up a few Novell netware serves using micro channel machines, all for supporting my company that worked as a contractor supporting IBM. I was lucky, I had access to a warehouse with a lot of surplus PS-2 hardware. As IBM would cycle through the generations of hardware I had my pick and frankly Linux ran like a scalded cat on a lot of that hardware.
brings back memories, I remember my PS2 SX 55 playing Wolfenstein when I was a teen back in the 90's. I remember finding microchannel stuff was a headache. My computer after that was a 486 with VESA local bus.
I bought my first computer in 1979 ( Apple IIe ) , even today program and support lots of PC's but this is the first clear explanation of the BUS that I have ever heard - sure I remember the days of changing jumpers etc but never without knowing the root cause. Thank's Dave.
Still got my PS/2 model 30 out in storage. I felt like a king in the day having a 3 1/2 inch floppy and a 20 MB HD! Spent many hours writing basic programs and playing Sierra games. Still remember the fight to have enough lower memory available to run some games and how amazing it was when DOS finally allowed the mouse driver to load in upper memory! 🤣
Great Topic Dave, I had worked with the intel multibus-II, for single board computers in the 90s, also still have a working IBM RISC 6000 machine daily running unix 4.3, running realtime simulation programs, works a treat even today. Still amazed what it can do, compared other solutions of the period, Cheers Dave
I worked at a game studio from 1991 to 1995, I was the king of boot disks and getting our games to work. Its neat to reflect back on the crazy things we had to do to get a game working with as much base mem while including a mouse driver, sounds card, CD ROM and other drivers. Kids now days have it easy...
You forgot about PCI-X! I had that in my mid 2000’s workstation for SCSI controller. PCIE didn’t exist back then and broke PCI’s bandwidth limitations. Most people ask what is PCI-X.
Holy crap Dave! I somehow understand almost all your words and I answered the bus question immediately correct when I saw it. My first computer was an IBM model 30 bought in Canada in 1986. I am guessing from your comments in this video that you probably imaged and shipped it maybe. Dave's Garage is very cool!
The bus riddle finally came to me part way through the video, so I would not have thought of it quickly enough for the interview either. I like your original incorrect answer better anyway. Interesting that floppies didn't use DMA in MS-DOS. I just assumed they did because unlike on other early micros you could type away during disk access. But the keyboard had its own DMA channel, so yeah of course you could type anytime (within limits).
Oh gosh I lived those days. The 55SX, wasn't that one of those with the MCA slots upon a riser card? The same riser card that reached almost the top of the case and if you were into putting a heavy monitor upon the top of the system, could bow the top just enough to contact said riser card and make the whole system susceptible to random stops working moments. One is if somebody shut the office door not silently, the sound would vibrate enough thru the walls and floor and up the table leg and induce a tiny weeny shudder that would due to the above, cause the PC to stop working. Fun times.
Thanks for the walk down memory lane. I remember being in a similar situation working for a computer builder and I automated it. The owner was soon catching on and his son was cheaper labor than I was.... Off to Philips I went over in The Netherlands where they were very happy to see the automation and allowed me to get my certifications.
The Bus question: I have it, maybe in 2009 for a system architecture job. My answer was: "It depends on the country" They like it. I was trying to show a detailed "architecture/design" approach, not just a "solve the problem quick" programmer mindset. I got the job, but that was the easy question.
Thanks for what was a trip down memory lane for me, Dave. I started building clones with the advent of the 386. MCA seemed superfast but none of the clones I was building at the time supported MCA and the PS2s were outrageously expensive. I remember flipping dip switches or using jumpers on serial cards, parallel cards, and MFM/RLL cards and eventually ATA/IDE cards. Suddenly all these functions were combined on a single card, and I recall being quite upset when all of these features were included onboard clone motherboards because rather than replacing a single failed card an entire motherboard would have to be replaced. My fears proved to be unfounded, but I still think I was right. Later there was also an AGP bus that was a short-lived fast graphics bus prior to the advent of PCI if I recall correctly.
I figured the interview school bus 🚌 was simply travelling forwards. Then it’s kind of irrelevant as to which side (left or right) in the diagram is actually the front of the bus. 😀
There is no ground... so it is in the sky and falling. if it is not falling then there is still no ground for it to move against. they f'd up the picture by not putting in the ground. Must have been a interview question to work on WindowsME
Who also noticed "All your buses are belong to us"? It's obvious that Dave knows about the older days of the internet! (although that meme is still around)
I just checked, (and as I already knew) PCI was a little more diverse than you mentioned and actually means Peripheral Component Interconnect. Standard PCI as was supplied in household PCs, was 32-bit and clocked at 33 MHz, half duplex. As the bus was shared with all devices a maximum bandwidth of 133 MHz could be achieved through bursting. For servers, PCI-64 bit and PCI-X was developed. PCI-64 slots had an extension and ran at 66MHz, and PCI-X doubled the clockspeed to 66 MHz on a 32 bit bus. PCI-X 2.0 again doubled the clock speed to 133MHz, resulting in a maximum bursting bandwidth of the 533 MB/Second that you mentioned. The same bandwidth could be achieved with a 64-bit bus at 66MHz. PCI-X also fully supported 64-bit - although I am not sure if the theoretical gig per second could be achieved. Both standards supported backwards compatibility with standard 32-bit, 33MHz cards. Half duplex means it could only reach that transfer speed in a single direction at any given time. Full duplex speeds (or interleaved read/writes) would be half of mentioned bandwidth. I hope this clarifies a lot.
Some microchannel bus trivia related to Microsoft: The NT 4.0 HAL for microchannel was said to have had an "off by one" error in the bus adapter enumeration until SP3 corrected it...
Around 1990 or 1992, NCR introduced a line of MicroChannel PCs. We bought a bunch and standardized on them for some things. The desktop unit was small enough that the newly-available 1GB hard drive was an external unit that sat on top or next to the machine. It wouldn't fit inside. Wells American, I think, made an amazing machine that had had both ISA and MCA slots in it. I wanted one SO badly!
Hot Damn! Thank you, Dave! What wonderful memories this is bringing back. I'm only 10 minutes in, and know I will really hate for this video to end. Joyful memories of trying to figure out all these things out by myself.
With ISA/PC-BUS you could build your extension cards yourself. The adress- and IRQ-lines where hardwired. It was simple to make some resistor-logic for adressing and IRQ and then connect your processor to your ISA-Bus. With PCI it's not the simple direct to CPU-connection anymore. PCIe is a very fast serial interface with a heavy protocol stack (unlike ISA with is more or a connection to the main CPU the 8086/8088).
Great explanation of bus history! You skipped the monster that come in 486 computers, the LBA (Local Bus Architecture), which allowed a maximum of three expansion cards to seat directly wired on the processor bus. The spec said a max of three cards were allowed, but my experience was that more than two caused unexplained errors, because of excessive capacitance (the bus was running at 66 MHz). Usually only the video card and the disk controller sat on the LBA, any additional card was on the 16 bit ISA bus. You certainly will recall the nightmare that LBA was. Thankfully the long waited PCI (Please confirm immediately) arrived, ending the bad dream. Thank you Mr. Dave for this piece of history. Regards, Anthony (from the UK).
You know how well the bus wars were going when IBM themselves sold EISA based, and later PCI based machines. That said - I remember seeing an Ultimotion board in a PS/2 record and playback full motion video - something that simply wasn't possible on a ISA based machine and it was a very impressive demo. If IBM had made MCA open and free we might all still be using MCI-Express cards these days.
but would of gotten plug and play without the need for reference disk or an reference disk patron on the hdd? EISA needed them as well? And then VL bus came and give an direct to 486 cpu bus. Maybe VL BUS + MCA to be AGP of the day?
@@JoebDragon you could have just included the configuration data in a ROM or the OS could just handle it during boot. There's no super good reason the system needs to know everything about expansion cards before the OS is up and running? I don't know though ;).
Actually, I have a bone to pick with the official answer. This is apparently a SCHOOL bus, due to the YELLOW color. If the level of detail in that picture is enough to assume they would draw a door, then it's enough to assume they would draw a STOP SIGN opposite the door side of the bus, ie, the side we are supposedly looking at. There is no stop sign, so AWAY from you would be the most logical answer, especially since I've never seen a bus with RED wheels.
@@rameynoodles152 No way is it a bus. I think the correct answer is, its not a bus. Think outside the box, don't take the premise of the question as gospel.
While IBM didn't have any patents on the original PC, they did have 7 on the AT. After the PS/2 strategy didn't work out, they spent the first half of the 1990s threatening to sue the PC chipset makers (all Japanese at that time) unless they licensed those, and other non related patents. They did so, and then IBM went after the clone makers with the same threat until 2001 when the patents expired. I was asked to study those patents (made far harder to understand with a very poor translation to Portuguese - where an engineer would use "duto" or "barramento" as a translation for "bus" the patent used "cabo", which is actually the translation for "cable"). Several of the patents actually were for things that the Apple II had already done, but people were just too scared to go against IBM.
Nice, I love seeing my favourite video people throwing some notice to others, love some LGR, you guys are like different sides if the same history, watching all of them helps make me feel smarter hahaha. Mostly just collecting info, like the Data master thing, thanks for that, that I will never need. Good stuff As for the bus. For me it was going forward. Granted its a stylised and squat looking bus, but those are brake lights on a bumper with reversing/indicating lights in the centre a rear window and all. The question was confusing since we don't have standardised yellow busses like the U.S. so I never thought of the door thing, our busses are pretty symmetrical in general.
Normal PCI was 32-bit at 33Mhz, and could only do 133 megabytes/sec. It was the PCI 2.x standard (not to be confused with the serial-based PCIExpress) that enhanced it to 64-bits and higher clock rates. Later, PCI-X (a name often confused with PCIExpress) that allowed even higher clock rates.
Hi Dave. First I would like to thank you for your work, you did a genius level work at Microsoft and doing the same in your channel. One of the things that seems no one talks about, is related to the transition from parallel to serial interfaces, mainly: line connection cross talk and data bus synchronization... I think that those concepts are fascinating. Can you Dave, make a video about those? Cheers from Portugal and thank you for your time.
Most of the time your videos fly way over my head, but I love your videos. I hope to one day be able to understand and comprehend them. Keep up the good work :)
Part of why PCI has burst mode but ISA doesn't is because PCI multiplexes the address and data lines. With ISA all the lines are available at once so you can read a random address every cycle. With a multiplexed design like PCI you need at least one extra cycle to transfer the address before you transfer data.
Hey, I got the bus question... 1 for ? Amazing how far Bus speeds have come. My early work was with Bus/Tag on the computer room raised floor. Pulling those garden hose size cables around and how easy it was to mangle the pins inside when putting them together. Whopping 4.5 MBps. I had a co-worker who could IML an MVS/XA from power-up to production from memory. I always had to use the book.
I designed a few high-end avionics diagnostic cards for the 16-bit ISA bus in the 90s, so this was a nice bit of history for me. I was always puzzled that it did not allow multiple bus masters, something that was perfectly possible, but I guess it was down to cost optimisation in the original PC architecture.
Oh, do I remember the MicroChannel days. I worked for a government agency, near IBM Building 1. We were an IBM shop all the way. I must have configured hundreds of Model 55s back then. My lab had a Model 80, which, at the time, was the top of the line. When we first implemented networking (other than mainframe emulation on PCs) we went with Token RIng, because of speed, reliability, and mostly because it was IBM, and readily available for MCA bus. Yes, they cost more, but with our IBM discounts, it wasn't much of an issue. I will never forget when I called tech support for one of those MAUs for the ring, I was forwarded to the engineer who designed them back in the day. Seems like second level support was the engineer back in those days. Luckily I am retired now, and don't have to deal with all the mess that things have become in that sector.
I'm the last few of younger gen child of 80's and teenager of the 90's that had the privy of had the luck to use Dos and the bus types from ISA as you mentioned and having to manually config IRQ's and DMA's on the hardware level , the Cards
Bus: I had the same first thought, the bus is falling because there is no ground. Also, it's not perfectly symmetrical. One of the window uprights is thinner. I don't know if that's part of the puzzle or just an error recreating the image. You could also argue that it's going away from you, those are brake lights, and the image excluded the bottom half of the bus with the bumper and the wheels.
Spoiler: It's specifically missing all of the cues I'd expect to see so I subconsciously assumed that the drawing was not at the level of to show the door either. The front windows are usually larger, the front wheel is usually further from the middle, one side usually has a door while the other side usually has a stop sign, etc. Further, looking at actual rudamentary drawings they typically do include either the stop sign or the door, and it doesn't correlate with the direction that the bus is facing (there are drawings with the bus facing left with the door and right with the stop sign).
Just as a hilarious anecdote, when I worked for Tandy, I built an ISA bus breakout cable and 3 slot board for a Tandy HX/EX using a PET D9060 HD chassis that I was more than happy to remove the old Tandon drive from. The HX/EX was PC-Jr like and used a proprietary connector with a very small assortment of expansion cards. I was young and pretty eager to prove my co-workers wrong about whether it could be done. Had I would have known that particular PET HD would have became so sought after I would have not been so lazy and got a project chassis. Please, no death threats. ;)
I was a teen when I had a tandy hx1000. somewhere I found out the slots were isa, just the card connector was different. I bought the appropriate connectors and some cable and made an adapter for an ISA modem. I just put a piece of cardboard over it and put it behind the computer.
We got one of the first PS/2 Model 70 A21 units. It came with the maximum 16MB RAM and cost $25,000. At the time, it was fast and I used it for full builds.
I remember having some IBM machines in the 90's. It was using busses invented by IBM. They were 16bit from memory. But never got adopted. I wonder if it was Micro channel. It was unique in every way, more pins, etc. :) How were you doing the imaging? We used to use "GHOST", invented here in N.Z. And bought by Norton's. They also bought our PC Anywhere. Ah, before Plug n Pray, moving jumpers around on your cards. So much fun. :) Then running out of interrupts or conflicts. :) There was a special version of PCI, that was used on Server Boards. And also not forgetting the fun we all had with the AGP slot, that required USB drivers to work, which MS only released working drivers, in 95B v4.0. Mmm. As I have said elsewhere, we still complain? Who remembers all the iterations of IDE, we had. Before SATA? And all the different connectors cables, Master Slave. My brother liked to program the C64 User Interface (Early IDE), and create contraptions to hang off it. Also could be used for a peer to peer network. :)
@@DavesGarage You nailed it - I was going to ask about these busses and their performance relative to the others. They bring back memories. One day, working in a PC shop, a customer wants to bring a warranty return - it smells like bad plastic smoke and as soon as we open it, the VLB (Vesa local bus) connector has a physical crater the depth of the entire connector in it. After much pushing, the customer admitted fiddling with the card and when he'd turned the machine back on, lightning, sparks, and smoke came out. He had got some traces connecting with multiple prongs, causing a short. No need to explain, that was not a regular warranty issue. I haven't seen that with any other bus type despite working in the industry for over 3 decades.
I recently saw a tweet about how much of a disaster MCA was. Sure, it was 32 bit and could run at 10 MHz, but what if you have a 12 MHz CPU? You'd have to use TWO CPU cycles to access the bus! So effectively that cut it down to 6 MHz. 16 MHz CPUs had similar issues. I think IBM came up with a hack to allow memory expansion cards to run at 12 MHz, but didn't support anything faster. Womp womp.
The floppy BUS question reminds me of opening a dos prompt to format floppies to keep the computer usable during the time. If I recall, either explorer or more would normally be nearly unresponsive until complete if done through the GUI. I think I used that back around XP but it may have been earlier around 9x days; its all a blur to me now.
Based on practical experience of dealing with a range of finance people, I suspect the actual answer to the school bus question is “What direction do you want it to be going in?” Finance is more of an art than a science and the numbers can dance in a variety of ways depending on the intent of the person calling the tune.
School busses exist in the US with the door on the opposite side than the usual. There are pictures of these on the net, you can Google them. So we do not know for sure after all. You can only say there is a high probability it is going in one direction.
Hahaha ernagerd, this brings back memories of putting in a comm card in a DOS 5 I think it was IBM PC then had a problem with a similar but older machine where the comm port settings were changed and the label printer would not work. I had to ask someone for help because it was DOS 3 something and I had no idea how to use the EDLIN command to edit the config.sys… 🤣 The DOS editor function/app/program whatever you call it was a massive improvement! Man I’m feeling old
IBM lamented their loss of control of the market for their own product (the PC introduced in 1981) that they had facilitated by placing the ISA bus standard in the public domain. By the time 1987 came around and they were releasing the PS/2 line, they had decided they didn’t want to commit the same grievous error. So, the MCA bus was deemed proprietary and anyone wanting to make a peripheral device for the higher end models of the PS/2 line had to pay royalties to IBM. But, the Federal Govt apparently had some policy forbidding purchases of products for which there are only one supplier. So, they shot themselves in the other foot.
I don't mind those kinds of interview questions as a "how would you answer this?" exercise, but I would be disgruntled if that were some kind of qualifying question. SPOILERS If I got that explanation from the interviewer, I would respond: "It can't be going left. US traffic law requires a side-view mirror on the driver's side of the vehicle, and there clearly isn't one. So, if it were going left, it wouldn't be road-legal." When you have an illustration with an arbitrary level of detail, you can't make concrete observations about what is missing, since it's ambiguous whether that missing detail is a clue or simply an omission.
Typical Microsoft question which is meant to imply that they are better than you. At least their certification exams were tougher than Netware's, because they made you apply knowledge more than recite it.
I worked with PS/2s, too. I liked them, but they were way, way out of my price range and I wouldn't have spent that much money on them even when I had had it. I remember a 486 system going for some 30k CHF. Anyway, I made our unit switch from OS/2 to Windows NT4.0, although I liked OS/2, people just used it to run Windows software on it (apart from a 5250 Emulaton). I made that with unattened install and imaging, too. Still was the guy paid least there. For OS/2 they had given the (partial) imaging process to a 3rd party and paid them more for that than I would gain in 4 years working there.
I used to have a PS/2 with a 60 MB hard drive. I wanted to expand it, but compatible drives were really expensive. So I bought a parallel port Zip drive. The 100 MB discs were a luxury, and I was surprised to find that it was a lot faster than the HDD.
Hehe, we're currently checking over the parallel ports of different PS/2 model levels for the transfer rates from Zip drives and other aspects. On a recent video, I'm connecting a Zip drive to a Model 30 (originally, an 8086 CPU - but I've also got a 1Gb SCSI HDD in there now too, in addition to the NEC V30 CPU replacement). Very soon I will connect an IBM PC Convertible to a Zip drive through the parallel port, interesting enough as the 5140 never had a harddrive.
@@IBM_Museum Nice! I also cobbled together a DAC using nothing but resistors and soldered it to the parallel port. The output went to an op amp and a small speaker. That was much cheaper than buying a real sound card. It worked really well when I wasn't using the Zip drive. And I learned about cooperative multitasking because Windows 3.1 would pause whenever the driver was playing sounds.
@@nickwallette6201 I didn't know if was called that. I just followed some plans I found somewhere, probably on a BBS or something like that. The hardest part was tracking down precision resistors.
@@OldBaldDad It's hardly novel -- just a ladder DAC in its simplest form -- so it isn't _inherently_ a CST. But, that is probably the most well-known implementation. And, because there was so much software support for that particular cheap DAC, it's the most reasonable one to duplicate. Second most popular would be the Disney Sound Source, which added a small FIFO buffer.
Is it weird that I'm actually nostalgic for the days of fiddling with config.sys to get a new piece of hardware (sometimes even a piece of software) to work?
One of the really annoying things about EISA was that in addition to the usual OS device drivers, the cards themselves had configuration files the BIOS used, which had to be loaded from either floppies or a special HD partition. That partition had to be the first partition on the drive, so if you already had a drive set up, you were SOL. I believe the cards would not work without the configuration unless you knew about the card and could fudge the, I seem to recall trying this a few times and coming up empty handed. In addition to EISA and MCA, there was also the brief VESA Local Bus, which was also 32Bit. Supposedly a 64 bit spec was in the works, but never implemented. These cards thankfully didn't require special drivers outside the usual OS device drivers, but apparently VLB was tied to the architecture of the 32bit CPUS of the time, particularly the 486, though I believe there are 386 and Pentium S4 and S5 systems with it.
The VESA bus was longer than ISA, but EISA at first glance looked just like ISA. It has a second row of pins for the extra signals and if you placed an ISA card it would ignore those and just connect to the bottom row.
During those days, only one slot supported bus mastering. I go back to those days as well, and still use an IBM 595 RS6000 machime running AIX and of course, MCA. But really got excited to run MSDOS 6.22 on a 386 clone. A trip down memory lane. No, not that 30 pin ram, or even 72 pin dimms.
While you were doing Microsoft, I was doing IBM and some amused with their networking support. So glad to finally get to TCP/IP out of the box (Windows 95) so some of those things became simpler...but they were still sitting on a Token-Ring network...weirdness.
The bad old days of trying to juggle resources when configuring busy systems. Especially trying to cram cards into memory space below 1MB and finding variation among hardware manufacturers on allowing end user space within 0xc000 and 0xe000. 0xd000 was generally available on all hardware.
The two most dangerous people in computing - a software engineer with a soldering iron, and a hardware engineer with a software patch
Sounds like the daily life of an embedded engineer.
@@jon9103 As an embedded systems engineer, I was going to comment that I think I'm both of these - you are indeed correct!
I've long repeated a quote I saw in my early days of accessing the internet: "Beware of programmers who carry screwdrivers." I've since amended it to include "or sledgehammers." Impatience and sheer size means I tend to grab the biggest tools available by default.
ROTFL
How many hardware engineers does it take to change a light bulb?
None, we'll fix it with software!
I worked for Intel in chipset validation during the initial rollout of PCIE, at least for desktop and mobile chipsets. We had a multi-day class then to go over the details of the differences between standard PCI and the new PCIE and how to go about designing tests to help isolate various features for testing. The first two rounds of that testing were PTSD inducing at best, with four consecutive 100+ hour workweeks on one of them, mostly because the chipset internal design changed so dramatically from the last PCI/AGP chipset to the first PCIE ones and nobody's device drivers worked even in isolation, much less together. I really don't miss those days much :)
Thank you for your service 😅
@@squirrel1620 I was at least part of filing in excess of 400 issues against the Intel graphics driver over the course of about three years, then moved to CPU validation. When they decided to integrate the graphics into the CPU in the Core i series, that was just about the final straw for when I couldn't take it anymore and had to return home to Indiana.
@@brentkreinop489 damn 🤣 is it just as stressful now? I was looking for a gig there but maybe not now 😅
_"with four consecutive 100+ hour workweeks on one of them"_
That just can't be legal.
@@VivekYadav-ds8oz I can't say. I had some good bosses there, but living in California turned out to be too much for me, so I left in 2006 or so. When I started my newest job here in Indiana much more recently, one of the projects I could have been assigned to would involve travel to both coasts for shipboard installations. I replied to my boss about that saying that I was reasonably sure that the next time my body crossed the border into California, fully half its atoms would spontaneously convert to antimatter and annihilate the other half and that at my current body weight, that would be an approximately 2.2 gigaton explosion :)
Great content Dave, as an old time IBM mainframe assembler programmer, I find it interesting how I/O grew to be similar to mainframe I/O, with several data transfer functions offloaded to more discrete hardware. Perhaps I am oversimplifying, but with mainframe disk drives had to be attached to an HDA (disk actuator/controller) which basically is like the bus services in the pc world.
When we needed the fastest I/O possible, we could bypass the generic get and put type routines, we could construct a CCW (channel command word) with the raw data to move and the instruction to the controller on what to do. It was pretty heady stuff back then as we found a way to drive IBM's 3800 laser printers at a flat out speed, whereas the routines that IBM provided were junk and kept pausing after each buffer transfer.
Those were some good times. Now everything is so fast and obfuscated, it doesn't matter much anymore how you code.
I never understood why a mainframe had "better" I/O until I wrote this episode, really! One question though - if you have a shared bus like that which any device can become master of and communicate to any other device, don't you saturate it pretty quickly if you have a lot of devices?
@@DavesGarage: And the adapter pictured in your 55SX is for 5250 terminal emulation - AS/400 and System/3x "minicomputers". Microchannel was also multi-processor capable (it's been 35 years since the initial announcement of PS/2 models - 'Computer Chronicals' has an episode where Chet Heath demonstrates a second 286 processor card on a Model 60) and IBM also repurposed many base systems as hosts of dedicated adapters for mainframe and minicomputer controllers, terminal emulation, and specific use-cases (medical, financial, business, and educational markets).
As they say, welcome to the club...
@@DavesGarage : I/O would stereotypically be the most limiting factor, and in some cases data wouldn't even need to touch the main bus, but instead just get shuffled from e.g. one RS232 line to another.
@@DavesGarage everything else would just wait
@@DavesGarage I too wrote IBM assembler code, but for a non-IBM operating system called MONITOR that originally ran on ICL S4 machines, which were a licensed copy of the RCA Spectra which was a (partial) clone of the original IBM 360 (RCA almost went broke designing that machine). This was back in the days of real core storage (that is ferrite core). It was an OLTP system which ran the air cargo systems in the UK (called LACES) and automated customs clearance systems (DEPS) and was running in the mid 1970s. It was 24x7 and had things like software RAID 1, transactional logging and we ran up to 1,000 terminals on a system with 768 KB of memory and which could barely manage 1 MIP.
I got very familiar with the IBM channel architecture (and the detailed difference between it and the RCA semi-clone). The IBM I/O channel architecture was designed in the days when CPUs were very slow, so that they offloaded I/O processing to controllers within the channel itself. On an IBM mainframe, to perform I/O, it was necessary to construct mini programs called a CCP (Channel Control Program) out of what were called CCWs (Channel Control Words). CCWs are a very stripped down set of instructions which were executed in channel controller, which actually directly read this mini I/O program from the mainframes memory. From what I recall, the actual IBM instruction was called SIO for Start I/O.
The channel controller would read the Channel Control Program and execute the instructions therein. The CCP would contain CCWs for things you might expect, like read and write data, setting the device address on the channel and so on. However, it also contained some extremely primitive conditional branching instructions, which meant it was possible to generate loops looking for a particular status. Of course, only one CCP could be actively being processed at a time by the channel controller, which could cause issues, and were dealt with by some other features added later.
As an example of how the channel architecture was designed to take load off the CPU, it could be used on disk drives to implement some aspects of key searches for sequential files. That's because IBM implemented disk drives using something called CKD (Count Key Data). That low-level formatted disk tracks into variable length soft sectors (for want of a better word) that comprised three parts; C for count, or sector number in track, the K for Key part and the D or Data part. This was entirely soft-formatted and a program could generate a CCP to format a track in whatever form it cared to do so. On IBM operating systems this is literally what user programs could do and on old programs it's at the user level that these CCPs were put together (although almost invariably by library routines) and an executive call was made to issue this channel control program. Needless to say, when multi-user operating systems came along, then IBM had to retro-fit security by vetting these CCPs so they weren't doing illicit things, like wandering off to parts of disks that that user id had no write to access. I mean this quite literally; for the legacy parts - which means a lot of mainframe programs, access control at the operating system is by physical, pre-defined parts of the disk. Later environments would provide more conventional file access control, but this came very late and for legacy reasons all original access systems are there and in use.
Of course, CKD is the opposite to Fixed Block Architecture, but it was produced to support some sorts of what would now be considered very primitive access methods without troubling the CPU too much. Most obviously, this was on indexed sequential files. As a simple example, when a data block was written, it was possible to put certain key data, such as the lower key value of a record within the block into the key field. The channel program could then be set to tell the controller to read the next "K" field, compare it to a value in computer store and conditionally execute one of the two next CCWs depending on the result. One of those CCWs might cause the CCP to loop back (using a CCW that I think was called "transfer in channel or TIC") so it would repeat for the next key field. The other CCW might be the instruction to read the next data (D) field to read the data and then a CCW to terminate execution, which would cause the interrupt back to the mainframe.
It could get a lot more complicated than that. Data read from a disk block could be put into mainframe memory and be used for things like causing the disk head to switch to a different track on the same cylinder or cause a seek to a different disk cylinder. In principle, this whole complicated set-up could be used to allow a multi-level indexed sequential search to be performed by the controller, using multiple levels of indexes. Of course, in reality, it was all extremely difficult to do and not many applications would structure access techniques of their own and the great majority ended up using library routines of standard access types.
The same sort of thing could be used for driving large numbers of terminals, typically driven by synchronous comms lines. A CCP could be set up to poll lots or them, with the work being done by the channel controller rather than the CPU having to poll each in turn.
At the hardware level, the active execution of a CCP against an individual device meant that the entire channel was dedicated to just that device. This was clearly a bad thing when multiple disks are involved (and you would not have disks and non-disk devices on the same channel). So what IBM added was the ability to (temporarily) disconnect the channel controller from the CCP and then reconnect later. On disks this was using something called RPS or "rotational position sensing". Basically the CCP would contain a CCW that told he controller to disconnect from the CCP until the disk came to a particular rotational point and then reconnect the CCP. If the channel was busy at that point, you missed the rotation - something called an RPS miss - and really bad for I/O response times. So, later, IBM introduced dual-path connection so that a set of disk drives could be on two separate paths and the reconnect could be down either channel which, statistically speaking, had a radical effect on I/O performance time. On a channel at 30% busy, the search latency would double because of RPS misses (as there was a 30% chance you'd have one RPS miss, a 9% chance of two RPS misses, 2.7% changes of three etc.). With dual path reconnect you could drive channel usage up to over 80% as well as having twice the bandwidth.
Needless to say, real CKD disks have been long, long dead. Instead what happens is that IBM mainframes are invariably connected to huge disk arrays and controllers from the likes of EMC or IBM themselves. Those contain masses of HDDs and SSDs with vast non-volatile memory arrays and then they emulate all those arcane features of IBM CKD disks from the 1960s and 70s using fixed block disks.
This reply has been a bit long (to put it mildly), but it's triggered a lot of memories of the apparent insanity of all this stuff, all designed in the days when every CPU cycle was precious, and the engineers tried to overcome this by offloading things, but in a rather rigid manner which actually impacted on software. Offloading is now the norm, but it's not done by trying to create programs in system memory to be executed by something that's part of the I/O bus system.
I think this video actually explained a problem I encountered decades ago but was never sure what caused it. While going to college (late 90s), I worked evenings at a datacenter for a small local bank. One of my duties was to download the ATM transaction info for the day from the national service. Doing that required a very ancient MS-DOS-based PC with a special encryption card that I was told cost $12,000. They told me that they attempted to upgrade the PC at one point, but that encryption card would fail in anything newer. I imagine it must have been due to the bus speed issues, as they weren't changing the software at all, just trying to upgrade the PC to reduce the chance of it dying on them unexpectedly from old age. They did say it was because the new system was "too fast" but I couldn't imagine why that would bother a card like that. They weren't willing to buy a newer encryption card, though (banks are super cheap, we used the last running example of an old NCR mainframe, so old that when the 2nd-to-last user of that model replaced theirs with a PC, they gave us theirs for free if we would haul it away. And that's how we got a DR setup.) It was still on that ancient PC when I left in 2000.
One of my earliest jobs was doing phone support for a company called Media Vision, troubleshooting hardware installs of their multi-media kits. Explaining IRQs and DMAs over the phone to grandmas was a challenge I wouldn’t wish on my worst enemy.
Yes, in the early days of the internet, they used to send all our transactions in plain, text across the networks. The SWIFT system, hadn't been updated for 20 plus years at the time it was done. Yet this was used by the entire financial system. Then again, what do you expect from people, that live in a fantasy land where they can lend 1000 to 1, and expect things not to collapse. But better than that are told, congratulations for crashing the world and 53 million jobs, here's 194 million for doing so. Computers not important, no wonder, a calculator might be to complicated and expensive. :)
I loved your story about using Laplink to image machines. That's exactly how we used to do it back in the 80's. Later on once ethernet became a thing, i wrote my own boot disk formatter/loader/installer. We'd shove an ethernet card into the PC being built and boot from my custom floppy which would partition, reboot, format and then go to a menu where you'd select the items to be installed (DOS, Win 3.11, specific video and sound drivers and the like). These all resided on our Netware server. For laptops or machines that we weren't able to shove an ethernet card in, for whatever reason, we would use a Xircom Parallel Port ethernet adapter. My custom boot floppy contained appropriate drivers to suit. All this over our trusty 10Mbps coax network. Cheers 🙂
It took a bit to realize imaging software was the easiest way to refresh a system that was starting to show the ravages of age (not to mention the week of hell waiting for all the system updates or installing some suspect software. Save an image in a pristine state and you are good to go.).
It took about a year later from being introduced to the idea to see how system builders would implement this to mass market builds. Thought it was ingenious.
@@quintessenceSL We started using the "Ghost" product by Binary Research in the very late 90's and early 00's to image machines for deployment. This was a big time saver for us. Ghost also supported multicasting, so for larger deployments we would image 10 or 20 machines simultaneously. This was essential for Windows 95 deployment as my previous file copy deployment method no longer worked.
This was before Windows Update was even a thing 🙂
Nowadays there are lots of tools available for SOE management and deployment. MDT would probably be one of the most commonly used, however with more cloud deployments taking place this is starting to change over to Windows Autopilot.
Laplink saved me hundreds of hours of work. Those memories are priceless. Thanks Dave.
Own many versions and also even a USB 2.0 to USB 2.0 Network cable. We used to bung modems in and just twist the pairs.
1:05 - my answer is 'NOWHERE'; it's not moving!
Reminds me of a very old *Bert and I* bit. A guy is lost and he asks "Where does this road go?". His reply: "The road don't go nowhere, it stays right where it is!"
While that is a really good answer also similar to mine, you have to look at the question from multiple perspectives. The formal/business perspective in wich case it would be always right because the "right" position is portrayed by elements of success, positive remark etc, and the human type perspective in wich case you have to answer off your instinct because usually that's what they're looking for, to understand what kind of a human you are. Are you innovative, are you stuck in your own perspective are you an open person etc
When I heard "Peripheral Connect Interface" I thought "what the hell, isn't it Peripheral Component Interconnect"?? Looked it up and yeah, I remembered correctly.
Thanks for the trip down memory lane.
I had to pause the moment you said laplink. RS232 null modem cable? Hell yeah, such a godsend for transferring files larger than a floppy "back in the day". I remember building the parallel version, I've probably still got it in "the box of cables that I'll need one day".
Today's episode was truly both informative and entertaining, thanks again Dave for the ride down memory lane in the yellow buss, I missed the bus question so I ended up in software and hardware development and not finance....
"Memory lane", you say... :)
@@denniswilson5384 Did you also notice the reference to "buss" was not a typo...
From across the pond and back in time.....I started my engineering life with a company called Research Machines (RM - still going but into H/W these days) who were heavily vested in IBM compatibles for the education market. When MCA came out, and for the reasons of cost reduction as well as potential IP, they decided to reverse-engineer the whole PS/2 chipset using the "clean-room" techniques of the old BIOS days. Two of their PC newbies (me, J, and another guy who I'll refer to as S) got sat in front of a model 55SX (and some others), given a pile of logic analysers and oscilloscopes and were told to go figure out what was going on inside their chips - warts'n'all (and yeah, IBM's implementation was pretty warty). 6 months later, we had it and a team of 6-8 H/W engineers set about designing a 2-chip chipset to implement it. Using schematic entry on not enough clunky Sun workstations we worked 24 hours a day in shifts, consuming pizza and coke in a dark, badly air-conned room during most of the summer (air-con units would occasionally drip and take out a workstation and the odd errant and unnoticed pizza slice lent a piquant odour to the place as it slowly toasted on a hot PSU). But we did it. IBM even sent some boffins to evaluate it with the alleged intent to buy it (but I suspect it was a patent-infringement trawl). We dastardly duo were looking forward to the dawn of a new PC age with the names of S&J emblazoned on the nerd wall of fame (it's more of an oversized brick in front of which someone has probably put a dustbin/trashcan by now) - but then PCI came along with ridiculous technical and commercial advantages, the box-shifting knock-offs took over the market and not long after that RM closed its H/W engineering section and we all got the iron-pyrite handshake. Having spent so long developing what was almost instantly a dead dodo, I moved onto working on developing bleeding-edge networking H/W..... token-ring networking that is at a UK company called Madge Networks both of which also rapidly did the extinction tango. I later went on to work on some ground-breaking networking chips (ethernet based this time - I try to learn as I go) which would drive some of the latest advances in internet infrastructure...... at a company called Nortel. Sigh.
Anyone out there fancy using me on their latest, ultimate-tech project.... ;)
J.
For Jinx >:)
I started on the ZX81/Spectrum but have fond memories of the RML380Z. I was even allowed to borrow it for the whole school holiday, I was glued to that green phosphor crt apart from when my friend had a new Atari 2600 game or we'd cycle out to an unexplored wood.
Edit: 52 now. Glad I experienced some of the "early" days.
@@georgeprout42 Yeah - it was more fun back then. Like you, we had a 380Z at school and I remember bootstrapping the COS from tape. We had a kid in the class who could enter the binary codes from the prompt to hack the thing and change the prompt to always be the teacher's nickname - Noddy. Drove him nuts. Then a ZX81, BBC-B before building first PC from busted-parts bin at RM. Learnt a lot that way though.
You got to love the UK, I was made redundant 3 times by 30, as manufacturers folded or went seeking cheaper labourer in foreign shores.
Thanks Dave taking me back to good old IRQ conflicts. The good old days.
DMA and IRQ shenanigans!
Nice to be refreshed on older bus standards, so thanks for the video. My first computer was an Amiga 500. Later I moved to PC's and my first was a build with an Intel 386 SX CPU. Unfortunatly I'm unable to recall the other spec's, but remembered I could only get 16 colors on my monitor so I had to put in some more memeory later so I could enjoy 256 colors. And that was just great in those days 😀
'VRAM' - Video RAM to add to the capabilities (color depth and resolution, up to a limited amount).
When I interviewed at Microsoft, the interviewer drew a riddle on a whiteboard and had me work on the riddle for 10 minutes while they checked their email. When I finally said I didn't know the answer, he started to show me the answer and then said "Oh, I drew it wrong." Didn't get that job even though I was a temp already doing THAT job for 6 months. Eventually got on full-time somewhere else in Microsoft.
Small correction: Narrow SCSI the highest priority is ID 7. (With wide SCSI, priority ran from 7 (highest) to 0, then 15 to 8 (lowest).)
PCI was 32-bit, I believe, but had a 64-bit expansion found in specialty systems known as PCI-X
PCI was future proof and could have lasted much longer being a more complex standard than what was actually implemented in hardware. However, the simplicity of AGP made higher PCI implementations useless on the desktop and the fast-paced evolution of PCI Express quickly made PCI irrelevant altogether.
PCI 1.0: 32-bit, 33 MHz, 5V (133.33 MB/s, very late 486s)
PCI 1.0: 64-bit, 33 MHz, 5V (266.66 MB/s)
PCI 2.0: 32-bit, 33 MHz, 3.3V (133.33 MB/s, Socket 5 Pentium)
PCI 2.0: 64-bit, 33 MHz, 3.3V (266.66 MB/s)
PCI 2.1: 32-bit, 33 MHz, 3.3V (133.33 MB/s, Socket 7 Pentium/Pentium Pro/Pentium II)
PCI 2.1: 32-bit, 66 MHz, 3.3V (266.66 MB/s, Pentium II based servers)
PCI 2.1: 64-bit, 33 MHz, 3.3V (266.66 MB/s)
PCI 2.1: 64-bit, 66 MHz, 3.3V (533.33 MB/s)
PCI-X 1.0: 32-bit, 66 MHz, 3.3V (266.66 MB/s)
PCI-X 1.0: 64-bit, 66 MHz, 3.3V (533.33 MB/s, Pentium III/Pentium 4 based servers)
PCI-X 1.0: 32-bit, 133 MHz, 3.3V (533.33 MB/s)
PCI-X 1.0: 64-bit, 133 MHz, 3.3V (1066.66 MB/s)
PCI-X 2.0: 32-bit, 266 MHz, 3.3V (1066.66 MB/s)
PCI-X 2.0: 64-bit, 266 MHz, 3.3V (2133.33 MB/s)
PCI-X 2.0: 32-bit, 533 MHz, 3.3V (2133.33 MB/s)
PCI-X 2.0: 64-bit, 533 MHz, 3.3V (4266.66 MB/s)
Most PCI cards you would encounter were 33 MHz and would rather extend to 64-bit for applications like RAID controllers and network cards than 66 MHz.
I remember using FastBack Plus, which used DMA to copy data from the hard drive to floppy at seemingly miraculous speeds. This was on a Tandy 1000 TL and its 720K floppy drive. The 1000TL was a bit of an oddball machine, using an Intel 80286 but equipped with XT-style ISA slots. My hard drive was a Seagate ST-232 half-height MFM drive mounted in the 5 1/4" floppy bay, using a Western Digital WDXT-GEN2 controller.
I've been watching your channel for sometime now. Thank you for sharing your knowledge, wisdom and humor with us.
PCI bus arbitration works by giving each device it's own bus request line (REQ#) and bus grant line (GNT#) in addition to the shared command, data, and address lines. The bus master would assert REQ# when it wanted to do a transaction on the bus, and the root complex would assert GNT# once the bus was free. With PCIe, because each device has it's own lanes, and because it's a packet switched network instead of an old-school bus, there isn't much arbitration apart from condensing packets from multiple lanes onto one lane inside of switches or the root complex (because the interface between the root complex and CPU is also a packet switched network most of the time these days).
This video brought back all the bad feels. All those hex addresses bringing back terrible memories of configuring some hardware that promised so much and yet mostly brought a day off yelling at MS-DOS
This was a great episode! Including the backstory on IBM's actions, I had thought IBM was just like and everyone you can all use ISA made by us for free... and that's where the term IBM compatible came from. I don't know where I got my theory from. I'm just glad that you straightened me out.
Dave, thanks so much for presenting all this interesting information. As usual, your delivery is perfect. Listening to you talk about old computer hardware is pretty much the highlight of my lunch breaks nowadays.
That bus question is easy for me. (I am a transit bus mechanic)
When I first got into the trade out of instinct I would constantly walk to the street side as the picture shows to drive the bus instead of the curb side.
Back in 2000 I got a job installing AT&T @ home high speed internet in the Seattle area which changed to Comcast HSI shortly thereafter. It was a daily routine to go into customers homes, run a new cable drop from the pole to their computer room. Hook up a cable modem, change the PC name to whatever was on our work order so it would authenticate and work. Opening up peoples computers and installing an ISA network card was standard practice. When ME rolled out it became almost a weekly thing to have someone's computer BSOD during the ISA card install. Ahh the good ol' days.
What a walk down "memory" lane, especially assigning IRQ priorities, config.sys files and such. Thanks Dave!
Writing my own OS for IBM PC, this video will be interesting!!
Great, but why?
@@tomwendelken3953 Because it's there, of course :-)
@@tomwendelken3953 Just for fun! Since I was a kid, I wanted to make stuff like this. Now I understand parts of it, so it would be fun challenge + learning experience for me! Like today I was finally able to run my bootloader and jump to 0x10000 and print a few letters. It's fun!
BTW, FTWAI and IMO OFC (TLAs FTW)...
I've worked on developing H/W for all these bus types (up to first-gen PCI-E anyway), and the reason for the big jumps in speed is down to the equally big jumps in technology used:
ISA, EISA, MCA all use "asynchronous" busses where basically the controller goes "I've got something to do" and eventually something notices this and replies "Eh? What? Oh, OK", controller then says "well get on with it then" and responder says "yeah yeah - OK, done it". Each stage includes a lot of waiting around to allow time for stuff to actually happen. There is no notion of a clock and everything is just running at its own leisurely pace and it's about as efficient as a 16-member committee trying to decide stuff in the pub/bar.
PCI is a fully synchronous bus where all parties are continually awake and in step with each other so when a controller wants to do something it generally just goes "do this..." and proceeds to send or expect data on every clock cycle - it's up to the responder to say "hang on a bit" if it needs to. A whole pile of data (well OK, 16 or 32 bits) is transferred on every step and actions can consist of multiple back-to-back transfers (bursts). The clock speed is only limited by how long it takes that whole load of data bits to all settle down together and this is quite hard to do because physics. Think how long it would take that committee of 16 people to find and agree on which table to sit at in the pub/bar. Plus, data can only go in one direction in any one transfer (from PC to card or card to PC) - you can decide things in the meeting or someone can go to the khazi/washroom but not both.
PCI-E and subsequent variants are effectively a collection of 1-bit serial ports (think USB/Firewire/Thunderbolt/blah/blah/blah) which are made of 4 wires - two in one direction and two in the other (there are 2 in each direction because they work as a pair because that can go faster because, again, physics). This way, there is no need to wait for clocks and data signals to settle down and behave each time they change value - with some clever H/W data rate is only limited by how fast the transistors can change state and how fast a signal can propogate down a wire. Compare how long it takes you on your own to find a table in the pub/bar compared to the PCI example. Having separate wires for each direction means you can also transfer data in both directions at once buy only if your clever about it (and enter a quantum state where you're both taking decisions and visiting the khazi/washroom at the same time).
I had an IBM PS/2 with its 286 CPU and a sound blaster card. I was given this small daughter board to evaluate as an upgrade from the 286 to make the PS/2 become a 386 computer that plugged straight into the CPU socket. It really provided a performance boost to my computer but the Sound Blaster no longer worked. It bugged me for the rest of my life what caused the lack of sound from my PS/2 speakers... now I know why. Thanks Dave!
LapLink and its home made cables brings back memories ...
Working at an IBM plant for decades I had a ton of experience working with microchannel bus machines from PCs to PC servers, to the risc systems. I had a fairly substantial library of reference disks (1.4 meg floppies) which were required for setting up the cards.
I also had access to stacks of surplus machines, cards, and token ring cards, cables, and hardware, so my first choice for setting up networks for my company (we were a contractor that provided a service at the IBM plant) was Slackware Linux. It came with a kernel setup for installing with built in microchannel and tokenring support (I was too much of a noobie with Linux at the time to know how to set up my own install disk set using a self compiled kernel, and that was before modular kernels where they were compiled monolithic which I learned to do later).
Wow, I'm interested in hearing more...
@@IBM_Museum The operating systems I worked with over that period of time were DOS, OS2 ver 1 and 2, Linux, Win 31, Win 31NT and on up, I also set up a few Novell netware serves using micro channel machines, all for supporting my company that worked as a contractor supporting IBM. I was lucky, I had access to a warehouse with a lot of surplus PS-2 hardware. As IBM would cycle through the generations of hardware I had my pick and frankly Linux ran like a scalded cat on a lot of that hardware.
brings back memories, I remember my PS2 SX 55 playing Wolfenstein when I was a teen back in the 90's. I remember finding microchannel stuff was a headache. My computer after that was a 486 with VESA local bus.
I bought my first computer in 1979 ( Apple IIe ) , even today program and support lots of PC's but this is the first clear explanation of the BUS that I have ever heard - sure I remember the days of changing jumpers etc but never without knowing the root cause. Thank's Dave.
Still got my PS/2 model 30 out in storage. I felt like a king in the day having a 3 1/2 inch floppy and a 20 MB HD! Spent many hours writing basic programs and playing Sierra games. Still remember the fight to have enough lower memory available to run some games and how amazing it was when DOS finally allowed the mouse driver to load in upper memory! 🤣
Still have a SCSI hard disk and 2.88 floppy drive from my ps/2 somewhere in my attic
My first pc was the ps/2 with empty mca slots
I didn’t think the lower end models of the PS/2 line used the microchannel bus. I thought it was only used on the Model 60 and Model 80.
Great Topic Dave, I had worked with the intel multibus-II, for single board computers in the 90s, also still have a working IBM RISC 6000 machine daily running unix 4.3, running realtime simulation programs, works a treat even today. Still amazed what it can do, compared other solutions of the period, Cheers Dave
I worked at a game studio from 1991 to 1995, I was the king of boot disks and getting our games to work. Its neat to reflect back on the crazy things we had to do to get a game working with as much base mem while including a mouse driver, sounds card, CD ROM and other drivers. Kids now days have it easy...
You forgot about PCI-X! I had that in my mid 2000’s workstation for SCSI controller. PCIE didn’t exist back then and broke PCI’s bandwidth limitations. Most people ask what is PCI-X.
Dave, you're such a lovely man, and your channel is infinitely addictive, your wit is spot on. God bless you, from another Asperger's chap.
I'm an early adopter, but not a software engineer - so while I don't always understand all the jibber-jabber, I always enjoy each episode. 😊👍Thanks!
Holy crap Dave! I somehow understand almost all your words and I answered the bus question immediately correct when I saw it. My first computer was an IBM model 30 bought in Canada in 1986. I am guessing from your comments in this video that you probably imaged and shipped it maybe. Dave's Garage is very cool!
Please add [SPOILER] to your comment if you discuss the answer :-)
I don’t know what the bus riddle is. I will watch to find out.
The bus in the thumbnail looks symmetrical
@@konradw360 It is, or as close as I could make it, and you should assume the drawing is perfectly so.
@@DavesGarage It's going wherever Otto Mann says it is going ;)
The bus riddle finally came to me part way through the video, so I would not have thought of it quickly enough for the interview either. I like your original incorrect answer better anyway.
Interesting that floppies didn't use DMA in MS-DOS. I just assumed they did because unlike on other early micros you could type away during disk access. But the keyboard had its own DMA channel, so yeah of course you could type anytime (within limits).
Oh gosh I lived those days.
The 55SX, wasn't that one of those with the MCA slots upon a riser card? The same riser card that reached almost the top of the case and if you were into putting a heavy monitor upon the top of the system, could bow the top just enough to contact said riser card and make the whole system susceptible to random stops working moments. One is if somebody shut the office door not silently, the sound would vibrate enough thru the walls and floor and up the table leg and induce a tiny weeny shudder that would due to the above, cause the PC to stop working.
Fun times.
Thanks for the walk down memory lane. I remember being in a similar situation working for a computer builder and I automated it. The owner was soon catching on and his son was cheaper labor than I was.... Off to Philips I went over in The Netherlands where they were very happy to see the automation and allowed me to get my certifications.
The Bus question: I have it, maybe in 2009 for a system architecture job. My answer was: "It depends on the country" They like it. I was trying to show a detailed "architecture/design" approach, not just a "solve the problem quick" programmer mindset. I got the job, but that was the easy question.
Thanks for what was a trip down memory lane for me, Dave. I started building clones with the advent of the 386. MCA seemed superfast but none of the clones I was building at the time supported MCA and the PS2s were outrageously expensive. I remember flipping dip switches or using jumpers on serial cards, parallel cards, and MFM/RLL cards and eventually ATA/IDE cards. Suddenly all these functions were combined on a single card, and I recall being quite upset when all of these features were included onboard clone motherboards because rather than replacing a single failed card an entire motherboard would have to be replaced. My fears proved to be unfounded, but I still think I was right. Later there was also an AGP bus that was a short-lived fast graphics bus prior to the advent of PCI if I recall correctly.
I figured the interview school bus 🚌 was simply travelling forwards. Then it’s kind of irrelevant as to which side (left or right) in the diagram is actually the front of the bus. 😀
Yeah, I thought the same thing. lol
how can you tell it is going forward, maybe it is reversing ?
There is no ground... so it is in the sky and falling. if it is not falling then there is still no ground for it to move against. they f'd up the picture by not putting in the ground. Must have been a interview question to work on WindowsME
Who also noticed "All your buses are belong to us"? It's obvious that Dave knows about the older days of the internet! (although that meme is still around)
I just checked, (and as I already knew) PCI was a little more diverse than you mentioned and actually means Peripheral Component Interconnect. Standard PCI as was supplied in household PCs, was 32-bit and clocked at 33 MHz, half duplex. As the bus was shared with all devices a maximum bandwidth of 133 MHz could be achieved through bursting. For servers, PCI-64 bit and PCI-X was developed. PCI-64 slots had an extension and ran at 66MHz, and PCI-X doubled the clockspeed to 66 MHz on a 32 bit bus. PCI-X 2.0 again doubled the clock speed to 133MHz, resulting in a maximum bursting bandwidth of the 533 MB/Second that you mentioned. The same bandwidth could be achieved with a 64-bit bus at 66MHz. PCI-X also fully supported 64-bit - although I am not sure if the theoretical gig per second could be achieved. Both standards supported backwards compatibility with standard 32-bit, 33MHz cards.
Half duplex means it could only reach that transfer speed in a single direction at any given time. Full duplex speeds (or interleaved read/writes) would be half of mentioned bandwidth.
I hope this clarifies a lot.
Some microchannel bus trivia related to Microsoft: The NT 4.0 HAL for microchannel was said to have had an "off by one" error in the bus adapter enumeration until SP3 corrected it...
Presumably noone noticed for ages because only 3 people had an MCA equipped PC and NT4? :)
Around 1990 or 1992, NCR introduced a line of MicroChannel PCs. We bought a bunch and standardized on them for some things. The desktop unit was small enough that the newly-available 1GB hard drive was an external unit that sat on top or next to the machine. It wouldn't fit inside. Wells American, I think, made an amazing machine that had had both ISA and MCA slots in it. I wanted one SO badly!
You guys are all gods to me. I love the comments as much as the original dialogue. Thank you for your work, for giving us this amazing gift of the PC.
Fascinating as always. The bus riddle was interesting, makes perfect sense in hindsight.
Thank You for all your "de-mystifying Windows and stuff" work here! :D Very much appreciated!
Hot Damn! Thank you, Dave! What wonderful memories this is bringing back. I'm only 10 minutes in, and know I will really hate for this video to end. Joyful memories of trying to figure out all these things out by myself.
With ISA/PC-BUS you could build your extension cards yourself. The adress- and IRQ-lines where hardwired.
It was simple to make some resistor-logic for adressing and IRQ and then connect your processor to your ISA-Bus. With PCI it's not the simple direct to CPU-connection anymore. PCIe is a very fast serial interface with a heavy protocol stack (unlike ISA with is more or a connection to the main CPU the 8086/8088).
Great explanation of bus history!
You skipped the monster that come in 486 computers, the LBA (Local Bus Architecture), which allowed a maximum of three expansion cards to seat directly wired on the processor bus. The spec said a max of three cards were allowed, but my experience was that more than two caused unexplained errors, because of excessive capacitance (the bus was running at 66 MHz).
Usually only the video card and the disk controller sat on the LBA, any additional card was on the 16 bit ISA bus.
You certainly will recall the nightmare that LBA was. Thankfully the long waited PCI (Please confirm immediately) arrived, ending the bad dream.
Thank you Mr. Dave for this piece of history.
Regards,
Anthony (from the UK).
You know how well the bus wars were going when IBM themselves sold EISA based, and later PCI based machines.
That said - I remember seeing an Ultimotion board in a PS/2 record and playback full motion video - something that simply wasn't possible on a ISA based machine and it was a very impressive demo. If IBM had made MCA open and free we might all still be using MCI-Express cards these days.
but would of gotten plug and play without the need for reference disk or an reference disk patron on the hdd? EISA needed them as well? And then VL bus came and give an direct to 486 cpu bus. Maybe VL BUS + MCA to be AGP of the day?
@@JoebDragon you could have just included the configuration data in a ROM or the OS could just handle it during boot. There's no super good reason the system needs to know everything about expansion cards before the OS is up and running? I don't know though ;).
Also, the bus could go forward and what looks like wheels could be stop lights at the back of the bus. 😁
I had thought perhaps tailpipes, but same principle. :-)
Actually, I have a bone to pick with the official answer. This is apparently a SCHOOL bus, due to the YELLOW color. If the level of detail in that picture is enough to assume they would draw a door, then it's enough to assume they would draw a STOP SIGN opposite the door side of the bus, ie, the side we are supposedly looking at. There is no stop sign, so AWAY from you would be the most logical answer, especially since I've never seen a bus with RED wheels.
How about, it's going nowhere. There's no driver.
@@rameynoodles152 No way is it a bus. I think the correct answer is, its not a bus. Think outside the box, don't take the premise of the question as gospel.
@@__teles__ Ok, but what would suggest that it's not just a simplified drawing of a school bus, similar to what a child would draw?
Something tells me I would love Dave's cocktail parties!
While IBM didn't have any patents on the original PC, they did have 7 on the AT. After the PS/2 strategy didn't work out, they spent the first half of the 1990s threatening to sue the PC chipset makers (all Japanese at that time) unless they licensed those, and other non related patents. They did so, and then IBM went after the clone makers with the same threat until 2001 when the patents expired. I was asked to study those patents (made far harder to understand with a very poor translation to Portuguese - where an engineer would use "duto" or "barramento" as a translation for "bus" the patent used "cabo", which is actually the translation for "cable"). Several of the patents actually were for things that the Apple II had already done, but people were just too scared to go against IBM.
Nice, I love seeing my favourite video people throwing some notice to others, love some LGR, you guys are like different sides if the same history, watching all of them helps make me feel smarter hahaha. Mostly just collecting info, like the Data master thing, thanks for that, that I will never need. Good stuff
As for the bus. For me it was going forward. Granted its a stylised and squat looking bus, but those are brake lights on a bumper with reversing/indicating lights in the centre a rear window and all.
The question was confusing since we don't have standardised yellow busses like the U.S. so I never thought of the door thing, our busses are pretty symmetrical in general.
Normal PCI was 32-bit at 33Mhz, and could only do 133 megabytes/sec. It was the PCI 2.x standard (not to be confused with the serial-based PCIExpress) that enhanced it to 64-bits and higher clock rates. Later, PCI-X (a name often confused with PCIExpress) that allowed even higher clock rates.
pci 64 bigger slot with both 33Mhz and 66Mhz versions + pci32 at 66Mhz before pci-x
@@JoebDragon Right, that was PCI 2.x (meaning PCI 2.0 and higher) that included that feature. PCI-X added the faster clock rates.
Hi Dave.
First I would like to thank you for your work, you did a genius level work at Microsoft and doing the same in your channel.
One of the things that seems no one talks about, is related to the transition from parallel to serial interfaces, mainly: line connection cross talk and data bus synchronization... I think that those concepts are fascinating. Can you Dave, make a video about those?
Cheers from Portugal and thank you for your time.
Most of the time your videos fly way over my head, but I love your videos. I hope to one day be able to understand and comprehend them. Keep up the good work :)
Part of why PCI has burst mode but ISA doesn't is because PCI multiplexes the address and data lines. With ISA all the lines are available at once so you can read a random address every cycle. With a multiplexed design like PCI you need at least one extra cycle to transfer the address before you transfer data.
Thanks, I was thinking of that and wondered if anyone did it yet... that's cool to know!
Great and informative video. Is this kind of content that I love!
I’d love to see a much more in depth video on the PCIe standard!
'LapLink', I remember how magical (and useful) it was! 😊
amazing C&C throwback regarding bus ownership!
Hey, I got the bus question... 1 for ? Amazing how far Bus speeds have come. My early work was with Bus/Tag on the computer room raised floor. Pulling those garden hose size cables around and how easy it was to mangle the pins inside when putting them together. Whopping 4.5 MBps. I had a co-worker who could IML an MVS/XA from power-up to production from memory. I always had to use the book.
A lengthy video about DMA and the history about DMA would be cool :)
I always liked the bus - thought provoking puzzle!!
Great stuff! Reminiscing those early glorious days of PC technology!
I designed a few high-end avionics diagnostic cards for the 16-bit ISA bus in the 90s, so this was a nice bit of history for me. I was always puzzled that it did not allow multiple bus masters, something that was perfectly possible, but I guess it was down to cost optimisation in the original PC architecture.
Oh, do I remember the MicroChannel days. I worked for a government agency, near IBM Building 1. We were an IBM shop all the way. I must have configured hundreds of Model 55s back then. My lab had a Model 80, which, at the time, was the top of the line. When we first implemented networking (other than mainframe emulation on PCs) we went with Token RIng, because of speed, reliability, and mostly because it was IBM, and readily available for MCA bus. Yes, they cost more, but with our IBM discounts, it wasn't much of an issue. I will never forget when I called tech support for one of those MAUs for the ring, I was forwarded to the engineer who designed them back in the day. Seems like second level support was the engineer back in those days.
Luckily I am retired now, and don't have to deal with all the mess that things have become in that sector.
I'm the last few of younger gen child of 80's and teenager of the 90's that had the privy of had the luck to use Dos and the bus types from ISA as you mentioned and having to manually config IRQ's and DMA's on the hardware level , the Cards
Bus: I had the same first thought, the bus is falling because there is no ground. Also, it's not perfectly symmetrical. One of the window uprights is thinner. I don't know if that's part of the puzzle or just an error recreating the image. You could also argue that it's going away from you, those are brake lights, and the image excluded the bottom half of the bus with the bumper and the wheels.
Spoiler: It's specifically missing all of the cues I'd expect to see so I subconsciously assumed that the drawing was not at the level of to show the door either. The front windows are usually larger, the front wheel is usually further from the middle, one side usually has a door while the other side usually has a stop sign, etc. Further, looking at actual rudamentary drawings they typically do include either the stop sign or the door, and it doesn't correlate with the direction that the bus is facing (there are drawings with the bus facing left with the door and right with the stop sign).
Just as a hilarious anecdote, when I worked for Tandy, I built an ISA bus breakout cable and 3 slot board for a Tandy HX/EX using a PET D9060 HD chassis that I was more than happy to remove the old Tandon drive from. The HX/EX was PC-Jr like and used a proprietary connector with a very small assortment of expansion cards. I was young and pretty eager to prove my co-workers wrong about whether it could be done. Had I would have known that particular PET HD would have became so sought after I would have not been so lazy and got a project chassis. Please, no death threats. ;)
I was a teen when I had a tandy hx1000. somewhere I found out the slots were isa, just the card connector was different. I bought the appropriate connectors and some cable and made an adapter for an ISA modem. I just put a piece of cardboard over it and put it behind the computer.
We got one of the first PS/2 Model 70 A21 units. It came with the maximum 16MB RAM and cost $25,000. At the time, it was fast and I used it for full builds.
Really good video. I was building my own PC's in the late 1990's. Thank you
I remember having some IBM machines in the 90's. It was using busses invented by IBM. They were 16bit from memory. But never got adopted. I wonder if it was Micro channel. It was unique in every way, more pins, etc. :) How were you doing the imaging? We used to use "GHOST", invented here in N.Z. And bought by Norton's. They also bought our PC Anywhere. Ah, before Plug n Pray, moving jumpers around on your cards. So much fun. :) Then running out of interrupts or conflicts. :) There was a special version of PCI, that was used on Server Boards. And also not forgetting the fun we all had with the AGP slot, that required USB drivers to work, which MS only released working drivers, in 95B v4.0. Mmm. As I have said elsewhere, we still complain? Who remembers all the iterations of IDE, we had. Before SATA? And all the different connectors cables, Master Slave. My brother liked to program the C64 User Interface (Early IDE), and create contraptions to hang off it. Also could be used for a peer to peer network. :)
This stuff is over my head but I am still glad to be on the bus.
Dave - nice touch putting the Bus emoji into the browser tab 😁
I started with my first bus the venerable S100. That was literally the ISA bus and was used by SWTPC. Then the ISA, EISA and PCI. Fun times 😁
Thanks, great video. Brings back memories of my early days working with PCs
I skipped AGP, VESA, and PCIX (which I had!) due to time.. I was already over 20 minutes!
@@DavesGarage You nailed it - I was going to ask about these busses and their performance relative to the others. They bring back memories. One day, working in a PC shop, a customer wants to bring a warranty return - it smells like bad plastic smoke and as soon as we open it, the VLB (Vesa local bus) connector has a physical crater the depth of the entire connector in it. After much pushing, the customer admitted fiddling with the card and when he'd turned the machine back on, lightning, sparks, and smoke came out. He had got some traces connecting with multiple prongs, causing a short. No need to explain, that was not a regular warranty issue. I haven't seen that with any other bus type despite working in the industry for over 3 decades.
I recently saw a tweet about how much of a disaster MCA was. Sure, it was 32 bit and could run at 10 MHz, but what if you have a 12 MHz CPU? You'd have to use TWO CPU cycles to access the bus! So effectively that cut it down to 6 MHz.
16 MHz CPUs had similar issues. I think IBM came up with a hack to allow memory expansion cards to run at 12 MHz, but didn't support anything faster. Womp womp.
The floppy BUS question reminds me of opening a dos prompt to format floppies to keep the computer usable during the time. If I recall, either explorer or more would normally be nearly unresponsive until complete if done through the GUI. I think I used that back around XP but it may have been earlier around 9x days; its all a blur to me now.
Based on practical experience of dealing with a range of finance people, I suspect the actual answer to the school bus question is “What direction do you want it to be going in?” Finance is more of an art than a science and the numbers can dance in a variety of ways depending on the intent of the person calling the tune.
School busses exist in the US with the door on the opposite side than the usual. There are pictures of these on the net, you can Google them. So we do not know for sure after all. You can only say there is a high probability it is going in one direction.
Hahaha ernagerd, this brings back memories of putting in a comm card in a DOS 5 I think it was IBM PC then had a problem with a similar but older machine where the comm port settings were changed and the label printer would not work. I had to ask someone for help because it was DOS 3 something and I had no idea how to use the EDLIN command to edit the config.sys… 🤣 The DOS editor function/app/program whatever you call it was a massive improvement! Man I’m feeling old
IBM lamented their loss of control of the market for their own product (the PC introduced in 1981) that they had facilitated by placing the ISA bus standard in the public domain. By the time 1987 came around and they were releasing the PS/2 line, they had decided they didn’t want to commit the same grievous error. So, the MCA bus was deemed proprietary and anyone wanting to make a peripheral device for the higher end models of the PS/2 line had to pay royalties to IBM. But, the Federal Govt apparently had some policy forbidding purchases of products for which there are only one supplier. So, they shot themselves in the other foot.
Great video, you remember me strugging with IRQ at BIOS trying to config for modem connection 😂...
I don't mind those kinds of interview questions as a "how would you answer this?" exercise, but I would be disgruntled if that were some kind of qualifying question.
SPOILERS
If I got that explanation from the interviewer, I would respond: "It can't be going left. US traffic law requires a side-view mirror on the driver's side of the vehicle, and there clearly isn't one. So, if it were going left, it wouldn't be road-legal." When you have an illustration with an arbitrary level of detail, you can't make concrete observations about what is missing, since it's ambiguous whether that missing detail is a clue or simply an omission.
Typical Microsoft question which is meant to imply that they are better than you.
At least their certification exams were tougher than Netware's, because they made you apply knowledge more than recite it.
What about the stop sign on the left side of a typical bus? I would consider that detail to be at the same level as a door.
FWIW, for those that remember CF cards, they were basically an IDE interface, so also were a subset of ISA.
I worked with PS/2s, too. I liked them, but they were way, way out of my price range and I wouldn't have spent that much money on them even when I had had it. I remember a 486 system going for some 30k CHF. Anyway, I made our unit switch from OS/2 to Windows NT4.0, although I liked OS/2, people just used it to run Windows software on it (apart from a 5250 Emulaton). I made that with unattened install and imaging, too. Still was the guy paid least there. For OS/2 they had given the (partial) imaging process to a 3rd party and paid them more for that than I would gain in 4 years working there.
I used to have a PS/2 with a 60 MB hard drive. I wanted to expand it, but compatible drives were really expensive. So I bought a parallel port Zip drive. The 100 MB discs were a luxury, and I was surprised to find that it was a lot faster than the HDD.
Hehe, we're currently checking over the parallel ports of different PS/2 model levels for the transfer rates from Zip drives and other aspects. On a recent video, I'm connecting a Zip drive to a Model 30 (originally, an 8086 CPU - but I've also got a 1Gb SCSI HDD in there now too, in addition to the NEC V30 CPU replacement). Very soon I will connect an IBM PC Convertible to a Zip drive through the parallel port, interesting enough as the 5140 never had a harddrive.
@@IBM_Museum Nice! I also cobbled together a DAC using nothing but resistors and soldered it to the parallel port. The output went to an op amp and a small speaker. That was much cheaper than buying a real sound card. It worked really well when I wasn't using the Zip drive. And I learned about cooperative multitasking because Windows 3.1 would pause whenever the driver was playing sounds.
@@OldBaldDad You made a Covox Speech Thing. :-D
@@nickwallette6201 I didn't know if was called that. I just followed some plans I found somewhere, probably on a BBS or something like that. The hardest part was tracking down precision resistors.
@@OldBaldDad It's hardly novel -- just a ladder DAC in its simplest form -- so it isn't _inherently_ a CST. But, that is probably the most well-known implementation. And, because there was so much software support for that particular cheap DAC, it's the most reasonable one to duplicate.
Second most popular would be the Disney Sound Source, which added a small FIFO buffer.
I still have my IBM model 3286 with one megabyte of RAM!
It runs word perfect and commander keen perfectly!
Is it weird that I'm actually nostalgic for the days of fiddling with config.sys to get a new piece of hardware (sometimes even a piece of software) to work?
One of the really annoying things about EISA was that in addition to the usual OS device drivers, the cards themselves had configuration files the BIOS used, which had to be loaded from either floppies or a special HD partition. That partition had to be the first partition on the drive, so if you already had a drive set up, you were SOL. I believe the cards would not work without the configuration unless you knew about the card and could fudge the, I seem to recall trying this a few times and coming up empty handed.
In addition to EISA and MCA, there was also the brief VESA Local Bus, which was also 32Bit. Supposedly a 64 bit spec was in the works, but never implemented. These cards thankfully didn't require special drivers outside the usual OS device drivers, but apparently VLB was tied to the architecture of the 32bit CPUS of the time, particularly the 486, though I believe there are 386 and Pentium S4 and S5 systems with it.
The VESA bus was longer than ISA, but EISA at first glance looked just like ISA. It has a second row of pins for the extra signals and if you placed an ISA card it would ignore those and just connect to the bottom row.
During those days, only one slot supported bus mastering. I go back to those days as well, and still use an IBM 595 RS6000 machime running AIX and of course, MCA. But really got excited to run MSDOS 6.22 on a 386 clone. A trip down memory lane. No, not that 30 pin ram, or even 72 pin dimms.
While you were doing Microsoft, I was doing IBM and some amused with their networking support. So glad to finally get to TCP/IP out of the box (Windows 95) so some of those things became simpler...but they were still sitting on a Token-Ring network...weirdness.
The bad old days of trying to juggle resources when configuring busy systems. Especially trying to cram cards into memory space below 1MB and finding variation among hardware manufacturers on allowing end user space within 0xc000 and 0xe000. 0xd000 was generally available on all hardware.
My favorite is the PCMCIA bus... (People Cannot Memorize Computer Industry Acronyms)