Couldn't agree more! I was like 10 years old in the 90's (before Windows 95 on 1995) when all good games run on DOS. I had became an expert on how to edit config.sys and autoexec.bat to enable EMS or XMS or save a few KB off the 640 kb limit - some games needed more than 590 kb from base memory free even though they were also using extended memory!
And of course you needed to know exactly your sound card configuration (IRQ number and COM port) and your video driver capabilities and memory size (I started with a hercules and moved over to a trident before getting a 3dfx voodoo).
Yes, running a game then was much more difficult than double clicking an icon but it was worth it. The games of that era were great and you could aquire skills (persistance, attention to detail, thinking on finding solutions) useful for the rest of your life - if you were a kid at least!
We're close to the same age. I remember that I had certain games with awesome boot disk creation utilities, and I knew which disks would help with which games. Although, those were always just the next step after running memmaker again, hoping that it would find just a little extra (but not really understanding what it was doing).
And I remember being a little disappointed when a game only supported the PC Speaker or Adlib, but shrugging, and deciding to be grateful that I didn't have to worry about getting digital audio working too.
I think...maybe Star Trek: Judgment Rites, and some of the later Wing Commander games. Oh, and a demo of A Final Unity that I never actually got to run (to my memory).
wow these comments are bringing back old memories... the one thing I can't recall is how I even figured out how to get started with all this stuff so long before I had internet access. I didn't really even know anyone who knew much about computers to get me on the right path. Somehow, one thing in particular that eluded me for years about learning computers and technology is that bookstores had tons of books back then to teach me programming and CS. Instead I just spent hours staring at code until it clicked.
Sound cards had to have IRQ #, IO port base address, and often a DMA channel.
The IRQs were handled by the PIC controllers, usually two with the secondary piggybacking on the main controller's IRQ #2. This was how the hardware could signal to the software that it wanted attention. The sound driver needed to know what interrupt to listen for or it would never reply to the sound card's requests. It was setup this way because these were physical pins! If you look at the ISA slot pinout there are physical traces for IRQ 3-7. 16-bit ISA slots added pins for IRQ 10-14. A bunch of IRQs were permanently assigned from the old IBM PC days which is why turning off COM ports in the BIOS would free up the IRQ for use by other peripherals. I seem to remember having a card at one point that was 8-bit, but had a little extension off the end with a couple of traces for 16-bit slot support only so it could support higher IRQs; The manual told you not to use IRQs > 9 if plugged into an 8-bit slot.
The IO port base address is directly related to the article: It selected where in main memory the device was memory-mapped. Writes to that address would cause the device to latch onto the bus and start receiving data. Anything not in the appropriate range was ignored even though all devices technically received the signal electrically. If the driver had the wrong address it would either write to unmapped memory (not that there was an MMU so the data words just went by on the bus without any listeners). Or worse: the write went to a different device that might ignore what it considered malformed data, but in many cases would do random things, scribble on memory, or just blast the bus and cause a lockup. IO base addresses were pre-assigned to peripherals like COM and LPT ports too but they were not in such high demand compared to IRQ or DMA channels; still in some BIOSes you could change the COM port's base address which would make it show up as COM3 instead of COM1 for example.
The DMA channel was exactly what it sounds like: the system had a limited number of direct channels to the memory controller. Often the protocol for a sound driver was to write a "Read audio from address XYZ, length X" to the IO port. The sound card would use the DMA channel to read the audio from that address. Then it would signal an interrupt when it finished so the driver could submit the next batch of samples.
You usually configured ISA cards by setting jumpers on the card. The available jumper settings were usually much narrower than the hardware supported so conflicts were more common.
PCI still used the physical IRQ system but had a protocol for devices to negotiate available settings with BIOS on startup.
PCI express uses a higher-level protocol abstraction. An interrupt is just a special message on the bus and doesn't have any dedicated pins.
Some later ISA cards also supported "negotiation", iirc. It was marketed as plug and play, but often referred to as plug and pray (because sometimes the result would be less than useful). Also made DOS drivers downright massive!
I remember those 'Plug and Play' ISA cards. The PnP bit never worked, I eventually hard set the IRQ, IO port and DMA channel directly to get sound working, and that was that. At least, until the Windows95 install was messed up enough that it was time to reinstall again.
See? There are people who actually know and fully understood all this stuff and then there are guys like me who just played with the numbers until it worked. :) I applaud you
And sometimes it feels like this is still the way to fix MS products, rote memorization of magical incantations.
Right now i am trying to figure out what it is that makes a Windows 10 tablet i own lose the content of dropdown menus. All i get is the "drop shadow" frame around them, if that.
Funny thing is that if i fiddle with the screen resolution it sorts itself out, for a while.
Oh man, IRQ and DMA numbers, there's another set of optimizations for your boot disk. Some games would require your sound card to be on a certain IRQ, or only give a limited number of options. Of course, your other devices like your mouse, CD drive, modem or network card need interrupts too, leading to the dreaded IRQ Conflict error message.
DMA channels were even more limited but thankfully fewer devices needed them and programs tended to be less picky about which ones you chose.
We now use the APIC. The first APICs had only 16 interrupts, but with the introduction of 82093AA in 1996 they now have 24 interrupts separating the ISA and PCI ones completely.
And of course you needed to know exactly your sound card configuration (IRQ number and COM port) and your video driver capabilities and memory size (I started with a hercules and moved over to a trident before getting a 3dfx voodoo).
Yes, running a game then was much more difficult than double clicking an icon but it was worth it. The games of that era were great and you could aquire skills (persistance, attention to detail, thinking on finding solutions) useful for the rest of your life - if you were a kid at least!