Romwbw printer with Z80 P/IO

[Tom Plano]

I was digging around in the RomWBW source the other day, and I noticed that there is actually a parallel port printer driver option that has been developed. However, I still dont totally understand the boot process of the hbios so its not totally clear to me how that driver would get  initialized and what hardware configuration that drivers supports. 

From reading the lpt.asm and pio.asm files, it seems like the printer driver needs at least 2 z80pio cards, to accommodate the 3 8 bit ports spec'ed in the driver. It is also not clear if passing though other cards like the 82C55 as a parallel io card would be compatible with the lpt driver.

Id love to hear from anyone who has exercised this driver, how it sets up, and what hardware you needed.

Thanks,

Tom P

[Wayne Warthen]

Hi Tom,

The PIO (pio.asm) driver in RomWBW is just a generic parallel interface driver.  In fact, it is actually just a stub at this point.  It can detect the presence of a Zilog PIO, but that is all.  It is a work in progress.  You are correct that the Zilog PIO has only 2 8-bit ports which is just a little insufficient for an actual printer interface.  I suppose it would be possible to use a pair of Zilog PIOs to cobble together an actual printer driver, but I don't plan to go down that path.  It would be pretty messy.

Support for a parallel printer (Centronics interface) is provided in the LPT (lpt.asm) driver.  This driver currently supports a couple hardware options, but the only one that exists on the RCBus systems is the MG014 Module (https://www.tindie.com/products/mrgelee/mg014-parallel-port-interface-designed-for-rc2014/).  This module is an excellent solution for parallel printer support and also allows connection to devices such as Zip Drives.

Thanks,

Wayne

[Alan Cox]

On Mon, 18 Sept 2023 at 18:59, Wayne Warthen <wwar...@gmail.com> wrote:
>
> Hi Tom,
>
> The PIO (pio.asm) driver in RomWBW is just a generic parallel interface driver. In fact, it is actually just a stub at this point. It can detect the presence of a Zilog PIO, but that is all. It is a work in progress. You are correct that the Zilog PIO has only 2 8-bit ports which is just a little insufficient for an actual printer interface. I suppose it would be possible to use a pair of Zilog PIOs to cobble together an actual printer driver, but I don't plan to go down that path. It would be pretty messy.

You can do a Z80 PIO parallel port on 8 bits providing you don't need
the status lines and you make the PIO generate the strobe directly. 2
is sufficient for all printer uses, but not some of the weird stuff.
Some care is needed because you want TTL signal levels with static
protection and some inputs have particular properties. You also really
want some resistor protection against unexpected direction reverses
from a device.

[Tom Plano]

Oh thats interesting. I actually have that module, but was having trouble getting good results from BASIC. I was ready to switch to the PIO for this driver, but if its already supported thats even better.

Tom

[Tom Plano]

As always, I'm impressed by how simple you've made adding hardware to a system. My follow up question then is, could the TALK program be modified to use the character device exposed by the printer driver. Skimming the driver code, it looks like the printer presents itself as a read only serial device, but Im not 100% on the interpretation. It seems like TALK hasn't been updated in a while, because I dont recognize the labels for types of conn devices. Perhaps Ill try my hand at patching it.

On Monday, September 18, 2023 at 12:59:10 PM UTC-5 Wayne Warthen wrote:

[Wayne Warthen]

On Monday, September 18, 2023 at 1:38:21 PM UTC-7 Tom Plano wrote:

Skimming the driver code, it looks like the printer presents itself as a read only serial device, but Im not 100% on the interpretation.

More accurate to say that the printer presents as a write-only device, but you are essentially correct.

 

It seems like TALK hasn't been updated in a while, because I don't recognize the labels for types of conn devices. Perhaps I'll try my hand at patching it.

Indeed, TALK is quite old.  The device names that you see are actually CP/M 2.2 device names.  TALK is currently a CP/M 2.2 application that does not use the RomWBW HBIOS level API at all.

Yes, TALK could and should be modified to allow specifying RomWBW HBIOS character devices.  That has been on my long-term todo list for quite a while.  By all means, take a shot at it.  My thought was to allow use COMn: as a way to specify direct HBIOS character devices where n is the HBIOS character device unit number.

Thanks,

Wayne

[Tom Plano]

I finally got a chance to beat on this code a little and it’s coming along nicely. If Im being honest its my first attempt at writing assembly for anything other then university assignments so its taking longer than it would in more experienced hands. That said I feel strongly that I will be able to get it shipshape. 

Tom 

[Wayne Warthen]

On Monday, September 25, 2023 at 9:06:42 PM UTC-7 Tom Plano wrote:

I finally got a chance to beat on this code a little and it’s coming along nicely. If Im being honest its my first attempt at writing assembly for anything other then university assignments so its taking longer than it would in more experienced hands. That said I feel strongly that I will be able to get it shipshape. 

Excellent.  Take your time.

-Wayne 

[Tom Plano]

Hi Wayne,

Is the lpt printer driver dev branch only? I had been running on dev for a while, but wanted to start testing my program against a stable production env, so switch back to main. When I did, my lpt0 interface disappeared (for the same config). Switched back to dev and lpt0 is back again! Not sure if this is intended behavior.

-Tom

[Wayne Warthen]

On Thursday, October 5, 2023 at 10:55:29 AM UTC-7 Tom Plano wrote:

Is the lpt printer driver dev branch only? I had been running on dev for a while, but wanted to start testing my program against a stable production env, so switch back to main. When I did, my lpt0 interface disappeared (for the same config). Switched back to dev and lpt0 is back again! Not sure if this is intended behavior.

Yes, sorry, the LPT driver has not yet made it to a stable release yet.  I hope to generate a new stable release in the next couple months, but no guarantees at this point.

Thanks,

Wayne 

[Tom Plano]

Wayne 

Good news code is basically done and tested. I don’t have a full suite of cards to test against but i was able to verify sio, mg014, and tms all work in large part. I say that because there 2 open questions for me that arnt resolved in the system guide. Firstly, when and how should I reinit devices? The printer in particular benefited greatly from a reinit to flush buffers and the like, while the tms did not like it very much at all. Second, how should I handle the boot console (say, SIO0) talking with the ANSI term associated with the TMS, with VDUEMU_SERKDB .SET 0? In that case basically half at random of characters are printer back to sio0 and the other half are printer the the ansi term. 

Finally, as i was writing this I realized that this utility had nothing to do with CP/M at all and that maybe it would be a good fit for inclusion in dgbmon.  To that end I have a version of the app that uses identical IO routines as are found in dbgmon.asm, instead of BDOS calls. Other the the cmdline parsing code, is should be a drop in inclusion. 

I know core rom functionality is a higher bar for quality and stability, so you thoughts are welcome on this idea. 

Tom 

[Wayne Warthen]

Hi Tom,

Good news code is basically done and tested. I don’t have a full suite of cards to test against but i was able to verify sio, mg014, and tms all work in large part. I say that because there 2 open questions for me that arnt resolved in the system guide. Firstly, when and how should I reinit devices? The printer in particular benefited greatly from a reinit to flush buffers and the like, while the tms did not like it very much at all. Second, how should I handle the boot console (say, SIO0) talking with the ANSI term associated with the TMS, with VDUEMU_SERKDB .SET 0? In that case basically half at random of characters are printer back to sio0 and the other half are printer the the ansi term. 

Sounds like great progress.  You really should not need to test against all hardware if you are just making HBIOS API calls -- that is the whole point of the HBIOS.

Initializing devices is not something that would normally be needed.  There are a couple scenarios where it makes sense to use that call: 1) if you have reason to believe the the device is in an error state and needs the big hammer to recover, or 2) if you have made direct hardware calls to the device and need to get it back into a "sane" state for HBIOS.  Using init on LPT will cause the Centronics reset line to be pulsed which will have different effects depending on the actual printer.  I'm not sure why you needed to flush the printer buffers.  In summary, I don't think it would make sense to use the reinit call -- will likely cause more problems than it will solve.  What did the TMS driver do?  It should have reinitialized the display controller and cleared the screen.  If not, I need to look at that.

Finally, as i was writing this I realized that this utility had nothing to do with CP/M at all and that maybe it would be a good fit for inclusion in dgbmon.  To that end I have a version of the app that uses identical IO routines as are found in dbgmon.asm, instead of BDOS calls. Other the the cmdline parsing code, is should be a drop in inclusion. 

Yeah, the HBIOS calls do not require CP/M at all.  I'm not exactly sure what you mean by inclusion in dbgmon.  The dbgmon code is pretty maxxed out on space right now.  It could certainly be loaded as a hex file from dbgmon.  Maybe I'm not quite understanding.

Thanks,

Wayne

[Tom Plano]

Ok I pulled out the init calls and everything seems to play nice. I also fast forwarded the dev version of my rom. I was working against a branch from a few month ago and forgot to pull. That seems to have helped stability a bit. TMS is behaving as expected on reinit, though I did notice that the <CTRL+L> form feed cmd code  doesn't clear the screen the way I expected it would. Id like to leave the screen in a good state after writing to it. A bunch of the TMS demo programs dont do this and is super annoying to have to reset to get my console back.

As for dbgmon, I figured since sending characters back and forth with no additional prompting is such a low level utility it would be useful to include as a sub-utility in dbgmon. Something like "a> C xx" to chat with a specific char device. Might be useful in bringing up new char device drivers. But as you say, that program is already basically maxed out, so no worries there.

Tom

[Wayne Warthen]

On Saturday, October 7, 2023 at 12:06:01 PM UTC-7 Tom Plano wrote:

Ok I pulled out the init calls and everything seems to play nice. I also fast forwarded the dev version of my rom. I was working against a branch from a few month ago and forgot to pull. That seems to have helped stability a bit. TMS is behaving as expected on reinit, though I did notice that the <CTRL+L> form feed cmd code  doesn't clear the screen the way I expected it would. Id like to leave the screen in a good state after writing to it. A bunch of the TMS demo programs dont do this and is super annoying to have to reset to get my console back.

Sound good.  The reason ^L is not clearing the screen is that the screen uses ANSI/VT-100 escape sequences.  Are you sure you want to clear the screen on exit?  I understand your comment, but if you clear the screen at exit, then you will suddenly lose visibility to the characters you just sent to it.  I guess this really depends on the use case.

As for dbgmon, I figured since sending characters back and forth with no additional prompting is such a low level utility it would be useful to include as a sub-utility in dbgmon. Something like "a> C xx" to chat with a specific char device. Might be useful in bringing up new char device drivers. But as you say, that program is already basically maxed out, so no worries there.

I see what you are getting at.  After you check-in the standalone application, I will take a look.  Not sure how much space will be required to integrate it yet.

Thanks,

Wayne 

[Tom Plano]

Just sent in a PR. Thanks for chatting about this stuff. Glad to contribute.

Tom

[Wayne Warthen]

Thanks Tom.  I see it.  I just need to confirm that nothing breaks the build process.  If not, I will merge.

-Wayne

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/157b4f5f-ad02-4223-93e1-61eae7391592n%40googlegroups.com.

[larrylan...@gmail.com]

Has anybody seen This?

[larrylan...@gmail.com]

Sorry , left out the link

https://github.com/abaffa/Baffa-2_Printer_Interface/tree/main

[Augusto Baffa]

Hi, I was looking for information about how LPT works in RomWBW to try to make it work with the PIO interface and I found this thread. 

Last year, I made a board adapting Stephen Cousins' sc103 module by adding a db25 connector to use it with a centronics cable. I also made an example in basic to show it working but I wasn't able to add support to the bios. I used port A for Control/Status and port B for data. Recently, I found the MG014 module using 8255 and I was reading the lpt.asm to understand if it's already working with RomWBW ... 

As I don't have much experience with the asmz80 and CPM80 bios, I've been studying to understand how LPT works and here we are... :)

Last week, I was studying a Grappler+ board for Apple][ and I noticed that the flat cable (26 wires) only uses 13 wires to connect the printer. I related the apple cable connections to the centronics/db25 cable and got the following pins:

- pin1 Strobe, pin2-9 D0-7, pin10 ACK, pin11 Busy, pin12 PaperEmpty, pin13 Selection, pin16 Init is gnd, pin18-25 gnd

- pins 14, 15, 17 are disconnected

This sounds like older printers used fewer pins to comunicate with the printer interface and that the Z80 PIO really meets the minimum requirements to work as a printer interface.

- Augusto Baffa

[Wayne Warthen]

On Thursday, November 9, 2023 at 7:32:40 AM UTC-8 Augusto Baffa wrote:

This sounds like older printers used fewer pins to comunicate with the printer interface and that the Z80 PIO really meets the minimum requirements to work as a printer interface.

I think you are correct.  You would only need more than 16 lines to do the full IBM PC Centronics interface.  However, as you say, you don't need all the signals defined by IBM to make a printer work.  You would not be able to use other parallel port devices such as Iomega Zip drives or SyQuest SparQ drives which do require all of the IBM defined signals.

Thanks,

Wayne 

[ladislau szilagyi]

Hi Augusto,

I also confirm that it's possible to print using the SC103 PIO, with only 11 wires (8 data, plus Busy, Ack, Strobe):

;PIO B (output)
;DATA1...DATA8 
;
;PIO A (control)
;BIT0 (IN) = BUSY
;BIT1 (IN) = ACK
;BIT2 (OUT) = STROBE

But, because I used interrupts, also the following wires were needed:
;
; Dupont wire SC103 IEI <---> SC110 IEO
; Dupont wire SC103 GND <---> LPT GND (any PIN from 18 to 25)
;

The printer is a Epson LX 350.

The software I used: my RTM/Z80 multitasking system.

Ladislau

[Tom Plano]

Cogent to this conversation is the notion of a IEEE 488/GPIB/HPIB driver for one of the parallel IO cards under ROMWBW, since its nearly the same in form as the LPT interface.  I recently acquired a few pieces of older HP/Fluke test gear and thought it might be fun to build up a full testing rig centered on the RC2014 for a fun workshop experience. I may take a look at the PIO driver in more detail as a good starting point for a future GPIB driver. It should be just possible to fit the GPIB signals onto the PIO. Then again, maybe it would be better to design a board for something like the TMS9914A and friends? The best docs I can find are here. If either of these options are of interest to the community, Ill dig further into it.

-Tom

[Dave White]

I've actually been looking into creating an IEE488 card for the RCBUS and the Z50 bus over the past few weeks. I have so many systems now, I thought it might be a good idea to create a master system, then link the rest as slaves via IEE488. I do have a dozen or more TMS9914 chips, and Z80 code to drive them. The cabling and connectors are the tough bit, if I want to do it properly. I'm also looking into using IDT7000 family FIFOs or dual port RAMs to interface them too, so still in the investigative stages.

[Alan Cox]

On Tue, 14 Nov 2023 at 05:43, Dave White <mrgcm...@gmail.com> wrote:
>

> I've actually been looking into creating an IEE488 card for the RCBUS and the Z50 bus over the past few weeks. I have so many systems now, I thought it might be a good idea to create a master system, then link the rest as slaves via IEE488. I do have a dozen or more TMS9914 chips, and Z80 code to drive them. The cabling and connectors are the tough bit, if I want to do it properly. I'm also looking into using IDT7000 family FIFOs or dual port RAMs to interface them too, so still in the investigative stages.

I recently finished building one using the National chip and the buffers. Still on the testing pile but I've attached the schematic.

It's possible to bitbang it with a Z80 PIO but you still want the 75160/161/2 parts because the bus itself isn't a TTL signal bus and in some configurations you need to switch direction very fast to avoid contention. A PIO style implementation can't make spec compliant timings but almost nobody ever cared because lots of people did it that way. If you are trying to do it with a PIO grab the schematics for the Osborne 1 off the net. That uses a different GPIO chip but the rest of the bus side logic is identical to what you need.

The 160/1/2 are still in stock at most places but were discontinued a few months ago by the manufacturer. Mouser also still has the connectors.