Jump to content

Printer support?


Wertzui
 Share

Recommended Posts

Just out of curiosity. Will there be any kind of printer support built in? IEC port printers? Or something more modern and available? Or none?

Is the interface for it will be like accessing device number 4 or 5?

Link to comment
Share on other sites

14 hours ago, Wertzui said:

Just out of curiosity. Will there be any kind of printer support built in? IEC port printers? Or something more modern and available? Or none?

Is the interface for it will be like accessing device number 4 or 5?

Note that the "support" for IEC printers is just having a printer that runs as an IEC device ... IEC assumes a smart device on the other end, so once you support IEC (as the CX16 is supposed to do, according to the FAQ), you automatically support any IEC device. Any special driver software might have to be ported, but anything that is done by passing a control string on a command channel then reading and/or writing data on a data channel should just work.

The User Port will be compatible with a Centronics parallel port interface, but given the variety of parallel port printers, the drivers might have to be written in the community. Since the I/O routine vectors in RAM from the CBM 8bit systems are retained, that includes allowing a non-IEC device to have a numbered device driver installed.

Edited by BruceMcF
Link to comment
Share on other sites

2 minutes ago, BruceMcF said:

Note that the "support" for IEC printers is just having a printer that runs as an IEC device ... IEC assumes a smart device on the other end, so once you support IEC, you automatically support any IEC device. The User Port will be compatible with a Centronics parallel port interface, but given the variety of parallel port printers, the drivers might have to be written in the community.

There are still printers on the market that have Epson FX and LQ emulation, as well as for IBM Proprinter.

And on GEOS, we had a printer driver for an HP LaserJet... so PCL is doable. Likewise, geoLaser and geoPubLaser imply that a BR-Script driver might be possible, though it might be a bit of a challenge.

Link to comment
Share on other sites

On 3/10/2021 at 11:50 AM, kelli217 said:

There are still printers on the market that have Epson FX and LQ emulation, as well as for IBM Proprinter.

And on GEOS, we had a printer driver for an HP LaserJet... so PCL is doable. Likewise, geoLaser and geoPubLaser imply that a BR-Script driver might be possible, though it might be a bit of a challenge.

Quite, when I said drivers might have to be written by the community, the comment already took for granted that they are write-able. Just pointing out that providing a Centronics compatible parallel port option via the User Port does not imply that the system will ship with some specific printer driver.

  • Like 1
Link to comment
Share on other sites

  • 4 months later...

This thread is a bit old, but I've too been thinking about printer support.

Being a complete novice on the matter, I would also believe that it's doable to write a driver that outputs PCL (or Postscript). Outputting plain text without a lot of formatting and other options might not even be hard.

I don't know if it's true, but I would think that the biggest problem is how to transfer data to the non-vintage printers typically found in our homes today. The small HP LaserJet I have got at home only has an USB port as an example.

As far as I can tell, you would need an "active adapter" between the X16 and the printer to solve this.

Building this around a microcontroller such as the Arduino is probably very hard. You can find discussions online where people are trying to make Arduino based printer servers. I don't know if any of these attempts has been successful.

The next level is something like a Raspberry Pi. You would then probably end up with a complete Linux OS on the Pi. The X16 could send PCL or Postscript data to the Pi (for instance over I2C), and the Pi could send it to the printer. The actual printing could be done by calling the Linux lp command.

It might, however,  be disturbing for some that this "adapter" is a lot more capable than the X16. We would need to hide the Pi in a nice box not to keep thinking about that 🙂

Or are there any better ideas?

Edited by Stefan
Link to comment
Share on other sites

Reality has simple text printing shouldn’t be that hard, but yes you need some type of microcontroller based bridge adapter to translate between say an Epson protocol to a modern printer. Probably pretty steep got Arduino, but a Pi could absolutely do it provided you are running some widely supported Linux host do that it can use standard print drivers. The it could take the source machines text or simple graphics output, convert it to some type of image, probably PDF or ODF and then print that image to a modern USB or network printer.


Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

The ESC/P (Epson) printer protocol is interesting for historical reasons, and supporting it might also make it easier to port programs made for other 8 bit platforms. It is, however, quite closely tied to functioning of dot matrix printers. Not everything makes sense on a laser printer, and you are also loosing some possibilities supported by a laser printer. I guess that's why Postscript was invented in the first place.

If I was to design a printer solution, I would like to keep the options open, supporting more than one printing protocol/format, and making it expandable.

To print an ESC/P byte stream, you would need to find or create a program that runs on the RPi and that converts the ESC/P input to Postscript or PDF. Making this from scratch is not an easy task. There are some open source alternatives available that I haven't yet tried. An example is found here: https://github.com/RWAP/PrinterToPDF/. If there is a ready-made conversion tool, implementing support for ESC/P would be very doable.

Postscript input is easy to print from the RPi. But making your X16 program output raw Postscript might be too big of a challenge for most programmers.

Having your X16 program outputting TeX or LaTeX is a lot easier than Postscript, and that has the benefit over ESC/P that you could use all features supported by a modern laser printer.

And there are of coarse a multitude of other markup languages that could be used as the basis of a printing system.

Link to comment
Share on other sites

I've never looked closely on PostScript before, and I find it demanding but quite interesting.

I think a PostScript based printing solution would work very well. As you may know, PostScript is just plain ASCII text which a X16 program could generate easily, send it to an RPi based printer adapter over I2C, which would send it to the actual printer.

My initial attempt to write a PostScript "program" that handles line and page wrapping by itself is enclosed.

I printed it with Ghostscript on MacOS to a PDF file with the following command:

gs -sDEVICE=pdfwrite -o test.pdf test.ps

test.ps

Link to comment
Share on other sites

I continued on making a PostScript template that could be used as the basis for a printing solution.

After some initial hurdles, I come to like PostScript a lot. 

The template is attached. Some remarks:

  • There are some variables you may set in the header
    • pagh = page height
    • pagw = page width
    • lmarg = left margin
    • bmarg = bottom margin
    • tmarg = top margin
    • rmarg = right margin
    • leading = line spacing
    • All of those in points, 1 inch = 72 points
  • Custom procedures defined in the header
    • normal = select default font, in the template that's Courier 10 pt
    • NP = Create new page
    • NL = New line
    • PR = Print text string (one or many lines)
  • The template supports printing with Latin1 encoding

I have written this template mostly with the needs of X16 Edit in mind. I could make X16 Edit output the PostScript header quite easily.

The header could be condensed by removing comments and white space. It should then be less than 1 kB.

You then need to continue to output the actual content to be printed.

  • Enclose each line of text to be printed in parenthesis. That's the way PostScript marks strings, not using quotes as most programming languages
  • Thereafter call PR to print and NL to insert a line break
  • After all text has been outputted you lastly need to call the showpage function

The actual printing part would not contain a lot of overhead. It would look something like this.

(Hello world) PR NL
(Another hello) PR
showpage

My next step is to fire up my old RPi and see what I can do with that. Can I configure it as a I2C slave and make it print a PostScript file transferred to it? I cannot say I have a lot of experience, but learning to do something new is half the fun.

template.ps

  • Like 1
Link to comment
Share on other sites

Some thoughts on X16 <-> RPi communication

  • As far as I can tell, the X16 Kernal is bit banging the I2C protocol. I do not know what speed we are to except.
  • Furthermore, I assume from skimming over the X16 Kernal source code that it will only work in I2C master mode
  • Making the RPi act as an I2C slave might not be straightforward, but there seems to be a hardware supported slave mode
  • I found this discussion thread on using the RPi as a slave
    • Link: https://raspberrypi.stackexchange.com/questions/76109/raspberry-as-an-i2c-slave
    • According to this, you must use GPIO 18 and 19 in slave mode (not the same pins as in master mode)
    • My old RPi (actually the first version ever launched) does not expose those two pins.
    • I need to buy a newer RPi. I have ordered a RPi zero W, which I understand has both GPIO 18 and 19 linked to the header.

If anyone of you have practical experience on how to set up an RPi as an I2C slave, please share.

If it's possible to make this work, that opens a lot of possibilities beyond printing:

  • You could get access to the Internet over the RPi (even over WiFi)
  • You could use the RPi to store files (may not be very interesting, an SD card holds a lot of data)
  • You could communicate with other USB devices than printers

My plan is to build a test rig with an Arduino as I2C master and RPi Zero W as slave. The Arduino has good I2C support and is mostly using 5V levels as the X16, so I can test that the voltage level converters I have at home are good (fast) enough for this application.

Link to comment
Share on other sites

I've made some small progress.

I have managed to setup a Raspberry Pi Zero W as I2C slave and a Ardunio Uno as I2C master:

  • Electrical connections
    • The Arduino is powered by USB
    • The RPi is powered from the Arduino 5V pin to RPi pin 2 (5V)
    • The Arduino ground is connected to RPi pin 6 (GND), ensuring a common ground
    • I have a voltage level converter (5V/3.3V). This is driven by the 5V and 3.3 V outputs of the Arduino.
    • Arduino pin A4 (SDA) is connected to the voltage level converter 5V side. The low voltage side is connected to RPi pin 12 (GPIO 18)
    • Arduino pin A5 (CLC) is connected to the voltage level converter 5V side. The low voltage side is connected to RPi pin 35 (GPIO 19)
  • The Arduino runs a program that sends the text "Hello world" once every second to I2C slave address 4
  • The RPi runs a loop that listens on that slave address and prints incoming text to the terminal

 

Arduino code

#include <Wire.h>
 
void setup() {
  // put your setup code here, to run once:
  Wire.begin();
}
 
void loop() {
  // put your main code here, to run repeatedly:
  Wire.beginTransmission(4);
  Wire.write("Hello world");
  Wire.endTransmission();
 
  delay(1000);
}

 

RPi code

The code I used on the RPi is basically identical to the example/instruction published here: https://raspberrypi.stackexchange.com/questions/76109/raspberry-as-an-i2c-slave

 

Attached is a short video showing this contraption running. Not Ben Eater quality, I'm afraid 🙂 But hopefully you get the idea.

Link to comment
Share on other sites

As I now might have the basis for a transport layer over I2C I'm thinking about a communication protocol.

So far this is what I have in mind.

X16 to RPi requests

  • The first data byte sent would select a command to be executed on the RPi
  • The rest of the data sent would be command specific
  • A command that invokes the Linux program lp to print a file could be formatted as follows:
    • A null terminated string containing the command line params to be given lp
    • Then the content to be printed as a stream of characters/bytes
  • A command that invokes curl to fetch a web resource could contain the following:
    • A null terminated string containing the params to curl

RPi to X16 responses

  • Reading from the RPi would always return the response of the last command. 
  • The response could be formatted as follows:
    • One byte: Response code (interpretation command specific)
    • Three bytes: Length of response stream (three bytes addresses more than a fully expanded X16)
    • The actual response stream

Please let me know if you see problems or better ways of doing this.

Link to comment
Share on other sites

This would work with my port multiplexor idea.... 

Although now that I'm back to the drawing board, I'm probably going to go with "Plan B", which is a more standard serial interface, with some extra control wires to select which device on the multiplexer is active: make pin 1 active, and the Pi is talking to the console. make pin 2 active, and it's talking to a network device. Pin 3 for serial port 1, and so on....

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use