Heath H-89: Change how SigmaSoft parallel port connects to IGC

[mgarlanger]

bus/heathzenith/h89/cards.cpp:

• Move slot option config to h89.cpp

bus/heathzenith/h89/sigmasoft_parallel_port.cpp:

• Move class declaration to header file.
• Remove callback variables.
• Add board jumpers to configure address/enable

heathzenith/h89.cpp:

• define card options for left slot cards

[cuavas]

Is this really the best way to do this? Should the card really “know” about the TLBC, or are the signals used to talk to it part of the slot interface? Is the left slot somehow different to the right slot to allow cards that talk to the TLBC, or are they the same? Will these left slot cards physically fit in the right slot? If it has additional lines wired, should it be a different class?

[rb6502]

No. The slot interface on this thing is extremely limited, so almost any card that performs a useful function has cables going to other components of the machine. In this case the TLBC is replaced by a graphics-capable version and it requires a dedicated ribbon cable between the parallel interface card and the TLBC to operate.

If MAME ever gets the capability of cards that can plug into multiple things at once, this is 1000% where you'd want to do the proof of concept though.

[mgarlanger]

The left-side slots are electronically different from the right(see the documentation I created for the slots - https://github.com/mamedev/mame/blob/master/src/devices/bus/heathzenith/h89/h89bus.h#L8-L79) , but cards are physically the same. Every left-card that I'm aware of, requires additional signals that are not on the slot itself. For this card, it has a cable to the CPU board to pick up things like read/write i/o signals. In addition, these signals defined in the PR go directly to a new SigmaSoft graphics board through a 34-pin cable. Then from the graphics board, an additional 34-pin connector routes to the existing Heath TLB plugs into chip sockets. You can find the manual for the IGC which includes info on this parallel port card and how it installs into the H-89 here - https://heathkit.garlanger.com/companies/SigmaSoft/

The H89 CPU board only supported up to 48k on the board and required a left-side 16k board to get to 64k. When installing this board, the user needed to remove one of the memory chips from the CPU board move it to the expansion card, and run a ribbon cable between the CPU memory socket and socket on the expansion board.
There was also a third-party 128k memory board, which also required addition cabling between the expansion board and CPU board.

Another left-side offered 1M RAM, optional SCSI, clock, etc. It actually required Z80 CPU from the CPU board to be moved onto the expansion board, and a ribbon cable connecting back to the 40-pin Z80 socket on the CPU board.

There is also a right-side card that could be used on the left-side, with the addition of a 3 wire cable to get 3 signals from the right-side socket.

Let me know if there is a better alternative.

[mgarlanger]

Note: On the device_h89bus_right_card_interface class there are 3 methods which are not actually on the slot, but is handled through a ribbon cable : set_slot_fdcirq, set_slot_fdcdrq, and set_slot_blockirq. I was considering moving the interrupt slot (heath_intr_socket) to device/bus/heathzenith, and the updating the right side handling of these signals to whatever approach is approved for handling the left-side cards.

[pmackinlay]

IMHO this is the least-bad way to handle this very leaky "slot" (i.e., explicitly pass in parent devices which are essentially connected to the card via arbitrary wires, and not through the slot itself). The slot represents the minimal standard signals which are present on all cards, and then each option machine_config() can arbitrarily pass in references to whatever else the specific card ties into. I am personally happy for this PR to be merged.

I'm not totally convinced that using a port configuration is the best way to handle the m_connected_tlbc thing; perhaps the device itself could be templated and connected/unconnected slot options might be tidier? In any case, I don't think this is a reason to hold up this PR either.

[mgarlanger]

@cuavas any more feedback on this?