51–60 of 69 posts
Guess I’ll be porting dahdi to netbsd soon lol.
Tbf, I get why Linux is dropping all this stuff. I wouldn’t mind becoming a maintainer of smaller drivers myself, but I doubt I have the skill level.
Earlier quoted context omitted.
I'm pretty sure the host will run out of IRQs long before 100. Don't most systems only have 16?
You don't really need IRQs for most ISA boards. OPL3/Adlib sound cards don't need one, MIDI doesn't, joystick port doesn't. I saw various I/O boards that don't need IRQ. Soundblaster does, but I don't know for what purpose. Maybe someone here can explain?
Base Address: This is the beginning of the IO port range you use to program the card, commonly it's 0x220, but can be configured with jumpers (or software on later cards). You can add offsets to this address to access different functionality of the card, such as the OPL chip or the Mixer chip.
IRQ: The interrupt number that will be fired when the soundcard finishes playback of an audio chunk. Early cards usually used 7, later models defaulting to 5. More on this below.
DMA Channel: Which channel of the PC's DMA controller will be supplying audio data to the card. Usually 1 for 8-bit cards, with 5 being used for 16-bit cards.
The general process for playback is as follows:
- Program the DMA controller with the address and size of an audio buffer you'll be using to mix your PCM sound into. This buffer will conventionally be used in 2 halves by the interrupt service routine, a front buffer and backbuffer, similar to what you'd have for double buffered video. The DMA channel should also be put in "auto-init" mode so that the DMA transfer will loop back to the start when it finishes, which allows continuous playback.
- Install an interrupt service routine to write data into the "backbuffer" half of the DMA buffer, which switches back and forth each time an IRQ fires.
- Initialize the DSP chip via its IO port, pick a sample rate (usually around 11khz for most DOS games), then issue a continuous playback command. For this part, you tell the soundcard that your playback buffer is half the size it actually is, which causes the IRQ to fire once in the middle of the buffer, and again at the end of the buffer before looping back to the start. These halfway IRQs allow you to fill the unused half of the buffer while the other half is playing, for smooth gapless playback with no clicks or pops.
This is probably more info than you or anyone actually wanted, but it's a fun topic so I couldn't help myself.
Earlier quoted context omitted.
ISA slots are all identical. If you have one slot, you can multiply it to 100 slots just by connecting the wires.
How were different devices addressed? I assume it’s a master and slave system, but even then were address collisions automatically resolved?
Each card must have a unique I/O address, sometimes more than one and sometimes an IRQ and DMA too. For example, Soundblaster cards had an OPL3/Adlib/FM synth chip at address 388h (it's fixed, you can't have two in the same system, or maybe you can and they would play the same tune, I don't know...), the main chip (wave playback and recording) at 220h or 240h configurable by a jumper, IRQ 2, 5, 7 or 9 (two jumpers), a MIDI port at 300h or 330h (another jumper), two DMA channels (another 4 jumpers), and an IDE port (2 more jumpers).
When you install the card, you set those jumpers according to the manual and what other cards you have installed and their addresses, so that there are no conflicts. Then you add the "SET BLASTER=A220 I5 D1 H7 T6 P330" to AUTOEXEC.BAT so that the games know where in memory to read/write the data so that it reaches the correct card.
Then, PnP was invented, because changing those jumpers and avoiding conflicts was very hard, as you can imagine.
On a PnP system, you would enter the BIOS setup and reserve the IRQs of any non-PnP cards you may have, so that they are not auto-assigned to PnP cards. I/O addresses are managed automatically.
The ISA PnP initialization process is actually very interesting:
All the ISA PnP cards power up in a disabled state. They all respond only to a specific address reserved for PnP initialization. Each card has a unique serial number written at factory. The BIOS scans for serial numbers, not by brute force (that would take too long), but bit by bit.
Let's say there are 3 cards:
A: 010...
B: 011...
C: 100...
BIOS sends an "init command" to the reserverd initialization address. All cards enter selection process.
BIOS asks for bit 0 of the serial number. Cards A and B pull down the line for bit 0. ISA lines are normally pulled-up by the chipset when receiving data from the cards. The BIOS remembers "0". Card C notices that the line is down, in conflict with it's own bit (has "1") and disables itself until the next init command.
BIOS asks for bit 1. No cards pull down the line, both A and B have "1". BIOS adds a "1" to the serial number (now "01").
BIOS asks for bit 2. Card A pulls down the line. BIOS remembers "010". Card B is in conflict and disables itself.
Continue until the last bit. Only card A remains active. For each bit, it either pulls down the line and the BIOS adds a "0" or no response and BIOS adds a "1". There can't be any more conflicts to disable it, since card A is the only one remaining. When the BIOS reaches the last bit, only one card can remain, no matter how many were initially active.
The BIOS then asks for config requirements, and the only remaining active card answers. BIOS configures it with bus addresses, IRQs, DMAs, etc.
BIOS sends the "init command" again. Card A now has specific addresses configured and will ignore the reserved init address. Only cards B and C enter the selection process.
BIOS asks for bit 0. Card B pulls down the line. Card C is in conflict and disables itself. Card B remains the only one active and will be configured.
Repeat the process and configure remaining card C.
At the end, when no more cards remain. Serial number scan returns "1111111..." - no cards to pull down any lines. It means the scan is finished.Earlier quoted context omitted.
There are still ISA slots in new systems with fairly modern processors and plenty of RAM, if you don’t mind buying specific models of industrial PCs for way too much money. For $1100 or so you, too, could have a 4th generation Core i3 machine. https://www.rampcsystems.com/product/2-isa-slot Or maybe you need 4 PCI and 9 ISA for some reason. DuroPC’s got you, if you can drop $1800 on a system with the same generation…
ISA slots are all identical. If you have one slot, you can multiply it to 100 slots just by connecting the wires.
https://www.lo-tech.co.uk/wiki/IBM_Personal_Computer_XT_Syst... https://www.lo-tech.co.uk/understanding-pcxt-slot-8/
Earlier quoted context omitted.
Code that is never normally used can sometimes still be gotten to run by an attacker, and therefore can still be a security risk.
But that code would have to be selected in menuconfig, compiled, and the module loaded. I assume that nobody does that for bus mice, and even if someone, by mistake, selects one of the drivers, that's 1 machine in a billion. Who would target that? Same argument for any retro-tech. What hacker would spend hours/days to hack my bare-metal DOS box running Arachne + a packet driver just to mine bitcoins on a K6-2 for a c…
Earlier quoted context omitted.
ISA slots are all identical. If you have one slot, you can multiply it to 100 slots just by connecting the wires.
There was at least one non-identical ISA slot: https://www.lo-tech.co.uk/wiki/IBM_Personal_Computer_XT_Syst... https://www.lo-tech.co.uk/understanding-pcxt-slot-8/
Earlier quoted context omitted.
You don't really need IRQs for most ISA boards. OPL3/Adlib sound cards don't need one, MIDI doesn't, joystick port doesn't. I saw various I/O boards that don't need IRQ. Soundblaster does, but I don't know for what purpose. Maybe someone here can explain?
Coincidentally I'm currently working on a Sound Blaster driver for some DOS homebrew, so here's quick rundown of how an SB is programmed and what its resources do: Base Address: This is the beginning of the IO port range you use to program the card, commonly it's 0x220, but can be configured with jumpers (or software on later cards). You can add offsets to this address to access different functionality of the card, s…
I thought the OPL chip was addressed via 388h (adlib/fm), not 220h (wave)?
Earlier quoted context omitted.
You don't really need IRQs for most ISA boards. OPL3/Adlib sound cards don't need one, MIDI doesn't, joystick port doesn't. I saw various I/O boards that don't need IRQ. Soundblaster does, but I don't know for what purpose. Maybe someone here can explain?
Sound Blasters and compatible cards used IRQ lines because back in the bad old days CPUs were slow, bandwidth was tiny, and buffers were minuscule. To get responsive/real time audio the card needs to signal to the CPU, not the other way around, and at the time IRQs were the way to do that on ISA busses. I would imagine that ISA cards that didn't need IRQs either required CPU polling or DMA.
Earlier quoted context omitted.
Coincidentally I'm currently working on a Sound Blaster driver for some DOS homebrew, so here's quick rundown of how an SB is programmed and what its resources do: Base Address: This is the beginning of the IO port range you use to program the card, commonly it's 0x220, but can be configured with jumpers (or software on later cards). You can add offsets to this address to access different functionality of the card, s…
No, I really appreciate the detailed answer. Things were so simple back then. I thought the OPL chip was addressed via 388h (adlib/fm), not 220h (wave)?
Incidentally, the DSP isn't actually at 220h, it's at 22a/22ch. How the ports are mapped exactly depends on which sound blaster model you have. What's actually at 220h on older cards is the old CMS chips, while the OPL2 is at 228/229h. As CMS chips fell out of use and later cards featured dual OPL2 or an OPL3 chip, 220h-223h were repurposed for FM writes also, which means you can access the OPL chip from a grand total of 3 different IO ports.
Interestingly, cards with dual OPL2 chips would often be designed such that writes to 388h would actually go to both FM chips instead of just one, so that you still get proper mono sound, otherwise it would be panned hard left.
What is a bus mouse? Is it using the old PS/2 port?
tldr: Ball mouse containing only optical encoders and no other electronics. Very popular in late eighties. Atari ST, Amiga 500, Acorn Archimedes (the ARM computer) all used this type of mice because of price.
Bus Mouse controller card used special Alps Electric 64H101 quadrature decoder and counter chip converting raw encoder outputs to neat X Y coordinates computer can read in just a couple of IO operations, much easier and quicker than serial or PS2 mouse.