How 286 turbo cards that NOT plugs into the CPU socet works

[per]

Most 286 Expansion cards works by controlling the system through a cable connected to the 8088 socket. This sollution is easy but the card can usually only use the < 640Kb of system memory, and the user have to move the processor (something that's rather inconvenient for most people not used to open their computer at all).

There is a few cards that works in another way. Instead of doing it simple by replacing the CPU, they kind-of makes the host computer a dual-processor-system. Those cards got it's own RAM (EMS paged for the host computer), and communicates with the system in a turn-based manner (I think). Those cards just plugs into an empty slot, and the user only have to run a small program (driver) to activate it.

I have not done any dissassembly of the driver of the card I got, but I see only one way how it may work. When the driver is run, it loads a copy of the system onto the card's RAM, takes controll of the Non-maskable interrupt and signals the card to start the 286 processor rigth before halting the 8088 with a "HLT" instruction. When the program needs to do anything with the host system (interrupts/IO/etc...), it generates a NMI and waits for the 8088 to return controll.

Does this sounds rigth, or should I really try to dissassemble the driver?

 

[Chuck(G)]

That's certainly one way to handle things, but there's no need for the 8088 to stall on a halt instruction. It can continue to run and service whatever devices require it and simply sit in a loop when it's idle. No need to use interrupts.

Of course, this scheme requires some sort of semaphore or "mailbox" facility for the two processors to communicate. This can be as simple as an I/O port or a block of shared memory.

Another possible way is for a device to serve as bus master, letting the 8088 in every 10 or so clock cycles to keep its state intact. Whether or not this was actually used, I don't know.

The big issue is with programs that directly access I/O ports. Accesses can be trapped on the accelerator board and forwarded to the 8088, but at a penalty in performance.

 

[per]

That's certainly one way to handle things, but there's no need for the 8088 to stall on a halt instruction. It can continue to run and service whatever devices require it and simply sit in a loop when it's idle. No need to use interrupts.

Of course, this scheme requires some sort of semaphore or "mailbox" facility for the two processors to communicate. This can be as simple as an I/O port or a block of shared memory.

Another possible way is for a device to serve as bus master, letting the 8088 in every 10 or so clock cycles to keep its state intact. Whether or not this was actually used, I don't know.

The big issue is with programs that directly access I/O ports. Accesses can be trapped on the accelerator board and forwarded to the 8088, but at a penalty in performance.

I have done some more researching, and I see that it is enough for the card to pull /IO-CH-RDY low. This will put the 8088 in a wait state, and the card can controll the status lines freely. However, it does only have controll of the bus, so there must be some handshaking with the host system.

In the host system, the driver is running when the card is active. All I/O calls below 100h are problably forwarded to the 8088, along with all BIOS calls (There may be an option to upload an image of the BIOS to the card, but I don't know how to activate this option).

When using my card, the speaker usually sounds weird (out-of-tune and choppy) when running some programs that utilizes the speaker (like on keyboard-buffer overflows).

 

[Marrr]

When using my card, the speaker usually sounds weird (out-of-tune and choppy) when running some programs that utilizes the speaker (like on keyboard-buffer overflows).

Perhaps the card has its own speaker?
I've got some card with 486 CPU and tiny piezoelectric speaker, which obviously sounds different than the dynamic one in the case.

 

[per]

Perhaps the card has its own speaker?
I've got some card with 486 CPU and tiny piezoelectric speaker, which obviously sounds different than the dynamic one in the case.

Nope, that's not the cause. There isn't any speakers on the card at all.

I'm currently dissasembling the file. It's quite big, so it may take some time. I'm currently working on the initialazion checks.



The 486 cards you tell about, do they work in an XT?

 

[Marrr]

The 486 cards you tell about, do they work in an XT?

I've never tried it, but it's safe bet the one I've got doesn't - it's a 16-bit ISA card.

 

[per]

I've never tried it, but it's safe bet the one I've got doesn't - it's a 16-bit ISA card.

It's problably designed for ATs or 386s.

As far I have come in the dissassembling, I've started to figure out some of the parameters:

Syntax: TURBO [/i=#][/a=#][/at][/d=#][/f][/b][/v][/s][/r][/h][/c][/!][/~][/g][/m]

Parameters/Variables:

Running on Compaq     > Byte ptr [0172] = 01h, Byte ptr [0C08] = 01h
Not running on Compaq > Byte ptr [0172] = 00h, Byte ptr [0C08] = 00h


      Byte ptr [016B] = 07h (default)
i=2 > Card has IRQ 2
i=3 > Card has IRQ 3
i=5 > Card has IRQ 5
i=7 > Card has IRQ 7

      Word ptr [0182] = E000h (default)
a=a > Address segment at A000
a=A > Address segment at A000
a=d > Address segment at D000
a=D > Address segment at D000
a=e > Address segment at E000
a=E > Address segment at E000
A=a > Address segment at A000
A=A > Address segment at A000
A=d > Address segment at D000
A=D > Address segment at D000
A=e > Address segment at E000
A=E > Address segment at E000

      Byte ptr [0189] = 00h (default)
at  > Byte ptr [0189] = FCh
aT  > Byte ptr [0189] = FCh
At  > Byte ptr [0189] = FCh
AT  > Byte ptr [0189] = FCh

      Word ptr [0186] = 0280h, Byte ptr [0CAB] = 00h (default)
d=6 > Word ptr [0186] = 0280h, Byte ptr [0CAB] = 01h
d=7 > Word ptr [0186] = 02C0h, Byte ptr [0CAB] = 01h
D=6 > Word ptr [0186] = 0280h, Byte ptr [0CAB] = 01h
D=7 > Word ptr [0186] = 02C0h, Byte ptr [0CAB] = 01h

      Byte ptr [0170] = 01h (default)
f   > Byte ptr [0170] = 00h
F   > Byte ptr [0170] = 00h

      Byte ptr [0CAB] = 00h (default)
b   > Byte ptr [0CAB] = 01h
B   > Byte ptr [0CAB] = 01h

      Byte ptr [0185] = 00h (default)
v   > Byte ptr [0185] = 01h
V   > Byte ptr [0185] = 01h

      Byte ptr [016C] = 00h (default)
s   > Byte ptr [016C] = 01h
S   > Byte ptr [016C] = 01h

      Byte ptr [016D] = 00h (default)
r   > Byte ptr [016D] = 01h
R   > Byte ptr [016D] = 01h

      Byte ptr [0170] = 01h (default)
h   > Byte ptr [0170] = 01h
H   > Byte ptr [0170] = 01h

      Byte ptr [016E] = 01h (default)
c   > Byte ptr [016E] = 00h
C   > Byte ptr [016E] = 00h

      Byte ptr [0CAC] = 00h, Byte ptr [016E] = 01h (default)
!   > Byte ptr [0CAC] = 01h, Byte ptr [016E] = 00h

      Byte ptr [0177] = 00h, Byte ptr [016F] = 01h (default)
~   > Byte ptr [0177] = 01h, Byte ptr [016F] = 00h

      Byte ptr [018A] = 00h, Byte ptr [0CAB] = 00h (default)
g   > Byte ptr [018A] = 01h, Byte ptr [0CAB] = 01h
G   > Byte ptr [018A] = 01h, Byte ptr [0CAB] = 01h

      Byte ptr [018B] = 00h (default)
m   > Byte ptr [018B] = 01h
M   > Byte ptr [018B] = 01h

 

[Chuck(G)]

I wonder if the /at parameter doesn't have something to do with telegraphing the system type to sofware. 5150 and 5160 BIOSes store FE or FF in the next to the last byte of the BIOS (F000:FFFE), whereas 5170 and above store FC there. Many programs used that to tell them what kind of CPU they were using. I can see where there might be cases where one would want to have software run in AT mode rather than XT and vice-versa.

 

[per]

I wonder if the /at parameter doesn't have something to do with telegraphing the system type to sofware. 5150 and 5160 BIOSes store FE or FF in the next to the last byte of the BIOS (F000:FFFE), whereas 5170 and above store FC there. Many programs used that to tell them what kind of CPU they were using. I can see where there might be cases where one would want to have software run in AT mode rather than XT and vice-versa.

A, it all makes sense... the parameter is activated with /AT /At /aT or /at, so you're problably rigth there. The card has faster memory than the AT (70 ns), so it will actually boost up an AT a little too...

I've now gotten to all the parameters that just changes some bytes in memory from 00 to 01 or vice versa. Those are a pain in the @rse to figure out.

 

[per]

I have done some more progress. It seems like the /! switch activates the coprocessor, and the user may be able to swap between non-coprocessor mode and coprocessor mode pressing Alt-Grey+ (whatever that corresponds to).

I'm not sure yet, but a warning about using disc drives in coprocessing mode is being printed when the parameter is used.

 

[per]

Okay, a lot of the settings has been unsolved when I realized what the /v switch do.

Ok...

This driver and card has several curiosities like EMS capabilities. It even got a CGA-simulator for the Hercules graphics card (even there is no way to activate it!). It also got a Color Graphics Fast-mode (Activated by using the card in a Compaq-branded computer), an EGA driver for a special EGA daugtherboard, and several settings for memory configuations.

The Turbo interface uses:
- A 64Kb memory window shared with the host system, either 1Mb or 2Mb RAM on the card itself (can be split into EMS and AT memory). (My card has 1Mb.)
- I/O address 300h to 307h, non-changeable.
- IRQ 2, 3, 5 or 7. (My card uses IRQ 7.)
- The card may take use of an optional EGA daugthercard. (I don't have this daugthercard.)

Here is the known parameters so far:

       (only the first character after the '=' is checked)
/i=2 > Card has IRQ 2
/i=3 > Card has IRQ 3
/i=5 > Card has IRQ 5
/i=7 > Card has IRQ 7 (Default)

       (only the first character after the '=' is checked)
/a=a > Address segment at A000
/a=d > Address segment at D000
/a=e > Address segment at E000 (Default)

       (only the first character after the '=' is checked)
/d=6 > Assign 640Kb of DOS memory on card (Default)
/d=7 > Assign 704Kb of DOS memory on card

/f   > Boot card from hard disk

/v   > Print Configuration Information on driver startup

/s   > 'Function currently not supported'

/~   > Activate 1Mb daugthercard for AT memory (problably XMS)

Parameters partly known:

/!   > 287 Coprocessor enabled, Byte ptr [0CAC] = 01h, Byte ptr [016E] = 00h

/g   > Activate EGA daugthercard, Byte ptr [0CAB] = 01h