BitWrangler wrote on 2024-12-30, 19:08:

Yeah spotting some strings and possibly error messages to determine scope of what that part of it is meant to do out of the whole system, is about best you can hope for unless you know the thing upside down and backwards already. There might be a whole lot of "teaching it how to speak satellite transponder" in there that is unnecessary for local. But not seeing a whole lot of error messages and status messages in there tends to suggest that the driver does a bit more than just point things to the right i/o port.

All I'm finding is a thread about sega channel prototypes on forums dot sonicretro dot org, unlinked due to Vogon's ROM policy. Which gets real interesting around page 22 and top of page 23 there's a link to archive.org of "compuserve drives" which I am not sure what they had to do with the subject but they are dismissed as having boring stuff on, which might include boring stuff for this board, who knows, but a lot to go through.

Then I think this doesn't have any copyrighted software linked, just descriptions, so https://segaretro.org/Sega_Channel#Sega_Chann … l_Server_Boards where all those boards were bought by a guy known as DavyPocket who had an account on X under that name, so maybe he has got something to move this forward.

One of the BINs had some strings, other more gibberish. The DDBD.exe has a good amount of error messages, but no clues. Right now, when I run ddbd.exe on my DOS server with the board in, I get the same output and timeout as I do in a sandbox environment that has no board. I've also been following the thread. Going down the rabbit hole, those CompuServe drives only appear to have accounting data for late subscribers.

These boards came from him. We were collaborating on the project until he moved on to other things.

mkarcher wrote on 2024-12-30, 19:27:

raymv1987 wrote on 2024-12-29, 03:09:

Based on all my research, this cfg/driver situation is the only thing blocking the Sega Channel from pseudo-broadcasting again.

I don't think a CFG file is required at all. Your card seems to be a "halfway EISA" card, in that it supports the EISA bus protocol, but does not support the EISA configuration protocol and uses jumpers instead. As it does not support the EISA configuration protocol, it will not get detected as EISA card and picked up by the BIOS, any ECU or a non-ECU EISA card dumper. This type of card would never have been certified as "EISA compliant", but it obviosly gets the job done as well.

Looking at the pins connected to the EISA part of the bus connector, I find that except for power rails, the only signals used are the high 16 data lines and the pin for negotiating 32-bit bus width, so the EISA bus is only used to allow 32-bit I/O cycles to the card, but in any other way, that card behaves like a plain old ISA card.

So you're saying even without a cfg file, this board should be able to receive information broadcast from the hard drive?

raymv1987 wrote on 2024-12-30, 20:05:

So you're saying even without a cfg file, this board should be able to receive information broadcast from the hard drive?

Indeed, that's what I suspect. I can't be sure, though. We observe that this card does not implement the EISA configuration mechanism. This can be due to two reasons: Either the EISA configuration mechanism was omitted on purpose (in which case a CFG file is completely pointless), or the logic implementing the configuration mechanism is broken. As we further observe, the card has a lot of physical configuration possiblities. While this does not exclude the possiblility of a .CFG file existing, everything that's physically configurable need not be configured using a CFG file. A CFG file might still exist to configure further aspects as the cards.

Another clue that makes me expect you don't need a CFG file: If that card is meant to be identified and configured via the ECU, the matching software is supposed to ask the EISA BIOS for the slot the card is inserted to and the current configuration of the card. The software is not supposed to assume that the hardware is "just there" and emit timeout errors.

mkarcher wrote on 2024-12-30, 21:01:

raymv1987 wrote on 2024-12-30, 20:05:

So you're saying even without a cfg file, this board should be able to receive information broadcast from the hard drive?

Indeed, that's what I suspect. I can't be sure, though. We observe that this card does not implement the EISA configuration mechanism. This can be due to two reasons: Either the EISA configuration mechanism was omitted on purpose (in which case a CFG file is completely pointless), or the logic implementing the configuration mechanism is broken. As we further observe, the card has a lot of physical configuration possiblities. While this does not exclude the possiblility of a .CFG file existing, everything that's physically configurable need not be configured using a CFG file. A CFG file might still exist to configure further aspects as the cards.

Another clue that makes me expect you don't need a CFG file: If that card is meant to be identified and configured via the ECU, the matching software is supposed to ask the EISA BIOS for the slot the card is inserted to and the current configuration of the card. The software is not supposed to assume that the hardware is "just there" and emit timeout errors.

That could make sense. Would explain why the person who originally had the boards also hung on to the ddbd.exe broadcast software but didn't have a driver for this. When running, I get a series of these until the program itself quits and sends me back to my command line

I took a peek in DDBD.EXE, and I noticed that it uses port 0x330 a lot. This will conflict with an MPU-type MIDI card at 330.

mkarcher wrote on 2025-01-01, 01:07:

I took a peek in DDBD.EXE, and I noticed that it uses port 0x330 a lot. This will conflict with an MPU-type MIDI card at 330.

Noted! I've got no other cards installed in here. Hopefully over 2025 this nut can be cracked. Working to make this an educational piece in a pseudo kiosk

Oh! The card as jumpered is not gonna work with DDBD.EXE anyways. That tool is hardcoded to DMA0 (jumpered correctly) and IRQ10 (your jumpering is IRQ11). DDBD.EXE is very simple. It just provides the data on the given drive (which is not formatted with any standard file system) starting at sector 300 and having the size given at the command line via DMA channel 0 to the board. It uses port 330 to reset the board (bit 7) and then to enable data transfer. The data transfer is performed using 32-bit EISA DMA cycles, explaining why the card requires an EISA slot. The "lcount timeout" error message means that the card did not accept data on DMA0 and raised IRQ10. Possibly the jumpering to IRQ11 is the only issue.

It seems that the card is not controlled by the host computer at all, it is only used as data source. Control of that DDB is through the "upstream serial port", as I like to call it, and it works independent of the interface to the host computer. The 80188 is standalone is that regard, both about flashing LEDs, being controlled through the "upstream serial port", forwarding data (or keepalives) to the "downstream serial port" and interfacing with the data delivery stuff on the board. It seems the firmware of the 80188 has some bugs, but they are likely not relevant for the main purpose of the card.

Heh, EISA implementations that should have been a SCSI chip 🤣

mkarcher wrote on 2025-01-01, 11:11:

Oh! The card as jumpered is not gonna work with DDBD.EXE anyways. That tool is hardcoded to DMA0 (jumpered correctly) and IRQ10 (your jumpering is IRQ11). DDBD.EXE is very simple. It just provides the data on the given drive (which is not formatted with any standard file system) starting at sector 300 and having the size given at the command line via DMA channel 0 to the board. It uses port 330 to reset the board (bit 7) and then to enable data transfer. The data transfer is performed using 32-bit EISA DMA cycles, explaining why the card requires an EISA slot. The "lcount timeout" error message means that the card did not accept data on DMA0 and raised IRQ10. Possibly the jumpering to IRQ11 is the only issue.

It seems that the card is not controlled by the host computer at all, it is only used as data source. Control of that DDB is through the "upstream serial port", as I like to call it, and it works independent of the interface to the host computer. The 80188 is standalone is that regard, both about flashing LEDs, being controlled through the "upstream serial port", forwarding data (or keepalives) to the "downstream serial port" and interfacing with the data delivery stuff on the board. It seems the firmware of the 80188 has some bugs, but they are likely not relevant for the main purpose of the card.

Valuable knowledge, thank you. Looks like there's already something configured for jumper 10 on my board. Going to mess with it and report back.

Reporting back. Swapped the jumper to IRQ10. Noticed something built into my board uses that jumper and it wasn't listed as an available resource so moved whatever was previously using it to 9. Same error

The last bit it just does that if it times out a bunch just so the program ends.

Current situation with the machine is it's running dos 6.22. Hard drive is split into 2 paritions. C and D. Cd rom is drive E. That setup is based on the accompanying schedule file for the cd img, it all references the cd drive as the E drive.

raymv1987 ,
are you sure the IO address is correct? I guess you can do some continuity testing on the dip switch towards the ISA slot and determine which address lines correspond to which dip switch. I already had a small look in a previous post and that makes me think the IO address is way off from the 0x330 the program seems to be using.

mkarcher,
are there any environment variables, config files, or command line arguments that can be passed to the program ?

weedeewee wrote on 2025-01-01, 18:29:

raymv1987 ,
are you sure the IO address is correct? I guess you can do some continuity testing on the dip switch towards the ISA slot and determine which address lines correspond to which dip switch. I already had a small look in a previous post and that makes me think the IO address is way off from the 0x330 the program seems to be using.

So, I'm dumb. How do I do that?

raymv1987 wrote on 2025-01-01, 19:13:

weedeewee wrote on 2025-01-01, 18:29:

raymv1987 ,
are you sure the IO address is correct? I guess you can do some continuity testing on the dip switch towards the ISA slot and determine which address lines correspond to which dip switch. I already had a small look in a previous post and that makes me think the IO address is way off from the 0x330 the program seems to be using.

So, I'm dumb. How do I do that?

Erhm, I almost had no clue anymore how you were supposed to do this.
anyway. I am wrong on continuity checking between U45 & isa address lines.
U45 is connected to U49 the LS688, which is an "8-BIT MAGNITUDE COMPARATORS"
So it compares 8 bits, set by U45, the dipswitch, to 8 bits coming from the ISA? bus address lines, and if they match it raises a signal that then gets used together with another signal to tell other parts on the card that something on the E?ISA bus wants to talk to it.

so
find the E?ISA pinout, locate the address pins on it, A0, A1, A2.... A10, and measure continuity on the card from the EISA edge connector to the LS688 (U49), make a note of these connections
then
measure the continuity between U45 the dipswitch and LS688(U49). only count ~0 ohm connections. make a note of these connections.
Find the datasheet of the LS688, https://www.sycelectronica.com.ar/semiconduct … res/74LS688.pdf
See which address line and dip switch go together.
In my previous post I just looked at the photos and tried to follow the traces and just assumed that the dip switch would be linearly set.
I should've noted what I thought was connected were. I can't remember 😀

I think A10 or A11 and U45(1) went together. ISA 27 and U45(1) seem to be connected . which is A4
from that I'm just assuming that A5 is 2, A6 3, A7 4, A8 5, A9 6, A10 7 & A11 8

edit: I had another look

weedeewee wrote on 2025-01-01, 18:29:

are there any environment variables, config files, or command line arguments that can be passed to the program ?

Not at all. IO 330 / DMA 0 / IRQ 10 can not be replaced by any other configuration.

weedeewee wrote on 2025-01-01, 18:29:

I already had a small look in a previous post and that makes me think the IO address is way off from the 0x330 the program seems to be using.

Not that much off. You suggested 0xB30, the program uses 0x330. This is just the top bit. So maybe the top switch is not part of the I/O address.

mkarcher wrote on 2025-01-01, 19:41:

weedeewee wrote on 2025-01-01, 18:29:

I already had a small look in a previous post and that makes me think the IO address is way off from the 0x330 the program seems to be using.

Not that much off. You suggested 0xB30, the program uses 0x330. This is just the top bit. So maybe the top switch is not part of the I/O address.

I was just trying to figure it out from the photos, It wouldn't surprise me if I was wrong and I just edited my previous comment.

edit:
to set the dipswitch to 0x330
set U45 (8) to off
edit2: ... If I accounted for the bits correctly. still not sure.

edit3: additional
A45(8) ... A45(1)
A11 ... A4
10110011 0000 b30

01001100 0000 4c0

00110011 0000 330

I'm not sure if the dipswitch on state means that that line is actually high for the ls688 or if it means that the line is low. That's what's confusing me atm.

Okay, so trace from the eisa pins to see what lines up where on the chip. Then from the chip to the switches to see what lines up.

Based on the doc for the chip, how do I determine what switches to flip?

weedeewee wrote on 2025-01-01, 19:47:

I was just trying to figure it out from the photos, It wouldn't surprise me if I was wrong and I just edited my previous comment […]
Show full quote

mkarcher wrote on 2025-01-01, 19:41:

weedeewee wrote on 2025-01-01, 18:29:

I already had a small look in a previous post and that makes me think the IO address is way off from the 0x330 the program seems to be using.

Not that much off. You suggested 0xB30, the program uses 0x330. This is just the top bit. So maybe the top switch is not part of the I/O address.

I was just trying to figure it out from the photos, It wouldn't surprise me if I was wrong and I just edited my previous comment.

edit:
to set the dipswitch to 0x330
set U45 (8) to off
edit2: ... If I accounted for the bits correctly. still not sure.

edit3: additional
A45(8) ... A45(1)
A11 ... A4
10110011 0000 b30

01001100 0000 4c0

00110011 0000 330

I'm not sure if the dipswitch on state means that that line is actually high for the ls688 or if it means that the line is low. That's what's confusing me atm.

Just refreshed and caught this. So switche 8 goes off? Noted.

raymv1987 wrote on 2025-01-01, 21:10:

Just refreshed and caught this. So switche 8 goes off? Noted.

Erhm, maybe 😀

another option would be

1U45
28......1
311001100

with 1 being on & zero being off.

weedeewee wrote on 2025-01-01, 21:17:

Erhm, maybe :-) […]
Show full quote

raymv1987 wrote on 2025-01-01, 21:10:

Just refreshed and caught this. So switche 8 goes off? Noted.

Erhm, maybe 😀

another option would be

Copy code to clipboard

1U45
28......1
311001100

with 1 being on & zero being off.

Will keep giving this a try when I get home in a bit. Worst case, I get mad and try brute forcing combos until something works 🤣

weedeewee wrote on 2025-01-01, 19:40:

ISA 27 and U45(1) seem to be connected . which is A4
from that I'm just assuming that A5 is 2, A6 3, A7 4, A8 5, A9 6, A10 7 & A11 8

Took a look myself. I think I can confirm at U45:

• Pin 1 (/G) = ISA A11 (AEN)
• Pin 2 (P0) = ISA A27 (A4)
• Pin 3 (Q0) = DIP switch 1
• Pin 4 (P1) = ISA A26 (A5)
• Pin 5 (Q1) = DIP switch 2
• Pin 7 (Q2) = DIP switch 3
• Pin 9 (Q3) = DIP switch 4
• Pin 10 GND
• Pin 11 (P1) = ISA A21 or A23 (A8 or A10)
• Pin 12 (Q4) = DIP switch 5
• Pin 13 (P5) = ISA A22 (A9), you see the via at the "top" edge of C32, and you see a different trace to Pin 11
• Pin 14 (Q5) = DIP switch 6
• Pin 15 (P6) = ISA A21 or A23 (A10 or A8)
• Pin 16 (Q6) = DIP switch 7
• Pin 17 (P7) = ISA A20 (A11), as A22 is routed on front side only and the traces for the other address lines block access to earlier pins
• Pin 18 (Q7) = DIP switch 8
• Pin 20 VCC

This mapping makes it extremely likely that your first guess to 0xB30 is actually correct, and switch 8 needs to be flipped to return the card to the default setting of 330.