As EMS was a kludge that sucked up high memory for its mappings, I eventually had a fancy CONFIG.SYS with different menu options for different memory setups, depending on which game I wanted to play.
Good times.
As EMS was a kludge that sucked up high memory for its mappings, I eventually had a fancy CONFIG.SYS with different menu options for different memory setups, depending on which game I wanted to play.
Good times.
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!
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.
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.
F-ing black box computers...
DMA channels were even more limited but thankfully fewer devices needed them and programs tended to be less picky about which ones you chose.
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 had memory/sound trouble with that, X-Wing, and World of Xeen.
DMA channel number more likely ;-)
(but only because systemd prevents me from configuring X11 by hand (to support nvidia optimus (damn you optimus!)))
I remember getting a borrowed 19" Sony CRT running at some insane resolution for the time, probably 1280x1024, and hearing that worrying thunk changing modes, then reading this book and reconsidering the wisdom of my custom modelines..
> One night at 3 a.m. Pekka caused this to happen, and
> immediately after the screen went black and made that
> clunking noise, it exploded in his face. The front of the
> picture tube was made of heavy glass (it had to be, to
> withstand the internal vacuum) which fragmented and spread
> into Pekka's face, neck and upper body. The very same
> phosphors that had been glowing beneath the sweeping
> electron beam, moments before, were now physically
> embedded in his flesh.Got qbasic, some assembler, and a list of interrupt vectors from somwhere. Messing with int 10h, and activating each individual video mode to see what happens. Somewhere halfway the list I find 'character generator video ram access' or something. I remember thinking it sounded really cool. Anyway, activate!
Today I suppose what happened was that the horizontal and vertical retrace got switched off, and the electron beam concentrates on the center of the screen instead of going everywhere. Or maybe not, you tell me.
I do know what happened next: The screen starts to make actual noise! Something wobbling starting silent and getting louder, straight from some third rate sci fi movie: wowowowowowoewoeoeWOEWOE. It can only guess it took a few seconds, but I heard al kinds of exploding monitor horror stories, so I am scared like hell. A few seconds later, I unstiffen and pull the power plug, not the best course of action but at least the fastest.
Repower, and there is a huge purple blotch on screen. Oh dear. After a few second it shrinks away to the center and disappears. For the next month, this keeps on happening every time the screen gets powered on.
I think it was 2 months later when my dad was sick of the display vageueness that had studdenly started and finally replaced it.('Did you do anything?' - ' Who me'? + Put on the 'I know nothing, Im from Barcelona' face) No idea if parents ever knew what happened (It's about 25 years ago at this point).
Friend of mine says every comptent engineer needs to destroy at least 1 piece of expensive hardware. So I hope I'm competent, but at least I learned a healthy respect for hardware that day.
Your story reminded me of this fun CRT classic, which I kind of hope is real in spite of the replies: http://atariage.com/forums/topic/176969-writing-a-program-fo...