The mass storage devices like zip drives have always supported 4bit nybble mode and that's how I run a ZIP on my Z80 DIY setup. Slightly slower yes and needs the pc handshake pins but that's true in byte mode as well.
For SD card you can bit bang it over a few unidirectional pins but bitbanging in general is slow so stuffing an Arduino in the flow doing nybble mode would probably be productive and let you do other stuff too. Interesting project and a lot more challenging on the M100 due to the multiple uses of the signals than on most! Alan On Sun, 12 Oct 2025, 03:44 Scott McDonnell, <[email protected]> wrote: > Ugh. Getting tired. I had it right the first time. > > Anyway, I found some more clarity on the ONLINE signal. It is an input > from the printer. The printer goes low if it encounters a problem such > as paper jam or out of paper. So under normal operation, it is held high > which is what we want. > > That means that this should be a pretty transparent solution. > Unfortunately I do not have a printer I can use to make certain of that. > I will do this mod to my experimenter M100 and report the results unless > someone chimes in and tells me where my logic is flawed. > > Now, why would you want to do this? More interesting peripherals > (including faster mass storage options) becomes possible. Joysticks > become possible. An analog to digital converter becomes possible. Etc... > Of course there are other ways of doing these things including > connecting a microcontroller to the serial bus if you are willing to > give up the serial bus. So really, it just opens up another port that > tends to go unused. > > My apologies for flooding the group. Hopefully you can find it interesting. > > Scott > > On 10/11/2025 10:16 PM, Scott McDonnell wrote: > > Oops. Correction. > > > > The 245 DIR signal needs to be LOW for typical operation (output to > > the port). We would need to invert the online signal for it to be in > > that default mode from the pull up resistor. > > > > On 10/11/2025 10:10 PM, Scott McDonnell wrote: > >> ok. I think maybe I have this worked out. Maybe. Please correct me > >> where I may be wrong. > >> > >> OE and DIR would best be controlled externally since the software > >> isn't going to know when the device wants to transmit or receive. > >> > >> So, I read over the description of how the printer port interacts > >> with a printer a couple of times. > >> > >> The M100 looks for the BUSY signal. If it is low, then data is sent > >> to the printer. This would work well as the OE signal of our 245. > >> When the printer is not busy, the 245 is active and allows data to > >> pass. When it is busy, it is tri-stated. This line is pulled up > >> inside the M100 which would disable the 245 and not allow Port A bus > >> activity to reach the connector when either the printer is busy or > >> nothing is attached to the printer port. > >> > >> We can then control this line ourselves with our external device. > >> > >> For direction, we need to set the DIR pin on 245 and ALSO let the > >> computer know that we want to transmit something. The other input is > >> ONLINE. We could use this pin to control direction. > >> > >> The information seems a little sketchy for the operation of this > >> signal. It is pulled up inside of the computer, so I assume that the > >> printer needs to pull it low. But it is not clear if it is low when > >> online or offline. > >> > >> However, the internal pull up if connected to the 245 DIR pin sets it > >> for output which is the default state. If the printer being ONLINE > >> keeps this high, then normal operation is possible. > >> > >> But for non-printer use, we can drive this pin from our own > >> peripheral to indicate direction. And since we can read this pin, our > >> software will know whether we are reading or writing data. The 8155 > >> mode for Port A has to be changed from output to input to read anyway. > >> > >> Seem pretty solid. Now, I don't know if the computer will go insane > >> with data coming in on PORTA, but I don't think so. At least not when > >> it isn't accessing the keyboard or LCD. Software to use this mode > >> would have to be tightly controlled. > >> > >> Of course, what this does not do is give us bit level direction > >> control so it is not truly bi-directional like a modern parallel > >> port. All 8 pins are either inputs or outputs. But if this works, it > >> is a fairly simple mod. > >> > >> Thoughts? > >> > >> > >> On 10/11/2025 5:41 PM, Scott McDonnell wrote: > >>> So, I have been looking into what mods would be needed to make the > >>> printer port bidrectional. > >>> > >>> Looking at the schematic, the printer port data bus is shared with > >>> the LCD and keyboard. It appears that the 244 chip used on the > >>> printer port is always enabled, unlike the one for the LCD and > >>> keyboard. So, I assume that it is always outputting any time there > >>> is activity on the bus? > >>> > >>> From the service manual, the communication with a printer is > >>> controlled via the strobe and busy lines. Of course, that is only > >>> really true when using the print function, not direct port > >>> manipulation. > >>> > >>> Since the '244 is not addressable, there isn't really an I/O address > >>> assigned to it other than the strobe signal at E0H-EFH. > >>> > >>> The 8155 chip used is already bidrectional, so all we really need is > >>> a bidirectional bus driver. > >>> > >>> Replacing the '244 with a '245 would be drop in. The direction pin > >>> becomes pin 1 (/1G on the 244) and the Output Enable becomes /2G. > >>> > >>> OE would become a chip select and the direction pin would just be A0. > >>> > >>> This would be a straightforward mod if the printer port were > >>> addressable. > >>> > >>> Am I missing something? Maybe we could derive the chip select from > >>> the strobe? > >>> > >>> The references I am finding really only talk about printing from > >>> this port and aren't really talking about low level programming. > >>> > >>> Anyone else look into this? > >>> > >>> Scott >
