Printer Emulation..(ie ESC P printer emulation)

[scruss]

I have a couple of Epson ROM dumps, and have been all over the Amstrad printer ROMS that are out there. Yeah, the character dots are stored in a weird format, the same as the ESC/P user defined character command. It might be easier to start with the Effects Eighty source code and pick out the pin matrices from the python.

I've been working on a TTF font family (vector, not bitmap) based on DMP rom data. As for completion, don't hold your breath.

[Coeus]

I have just discovered I have a copy of the Epson FX Printer Operation Manual in my loft so I have fetched it down. In Appendix F the dot patters for the various characters are shown including variations for several languages.

[scruss]

Yeah, they're all in the FX Printer manual, volume 2. That's where the Effects Eighty author got them from

[ThomasHarte]

If you promise not to look at any of the rest of the code, or at least not to judge me on it, you can also grab the FX-80 font directly from the ElectrEm code, where I recall retyping it by hand.

Format is a 256-entry array of arrays, each letter being 11*9 ints:

Code: Select all

		{											// 77 M
			W, 0, 0, 0, 0, 0, 0, 0, W, 0, 0,
			W, 0, W, 0, 0, 0, W, 0, W, 0, 0,
			W, 0, 0, W, 0, W, 0, 0, W, 0, 0,
			W, 0, 0, 0, W, 0, 0, 0, W, 0, 0,
			W, 0, 0, 0, 0, 0, 0, 0, W, 0, 0,
			W, 0, 0, 0, 0, 0, 0, 0, W, 0, 0,
			W, 0, 0, 0, 0, 0, 0, 0, W, 0, 0,
			0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
			0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
},

The 11 coming directly from the fact that the manual lays things out on a grid with six squares, but dots are permitted to be either in the centre of a square or on its boundary. So there are 11 potential strike positions per character per row.

With a helpful comment at the top:

Code: Select all

#define W	1
// W doesn't mean anything, it just contrasts nicely with the 0s in this editor

... and a separate array of character widths, for proportional mode.

So you should be able to copy and paste all of that into a tool that compiles and outputs in your preferred format pretty quickly.

[rwap]

The Retro-Printer is now available for purchase - www.retroprinter.com

There are a few issues with the BBC, so I will start a separate thread for that.

In the meantime, out of interest, I thought I would run the captured test file from above through the ESC/P2 convertor.

I have made some recent changes to the PrinterToPDF also (as we spotted an issue with 9 pin printers (which use different line spacing calculations for ESC 3 and ESC A) - this convertor is the same one as used on the Retro-Printer itself but you need to be careful as to what configuration options you set - https://www.github.com/RWAP/PrinterToPDF

However, I can see that the above conversion has an issue with the page size. I therefore added an option to turn off the default paper margins (which are according to the ESC/P2 manual 8.5mm at the top and 13.5mm at the bottom)

I then got

[richardtoohey]

The Retro-Printer is now available for purchase - www.retroprinter.com

That looks interesting!

On the web page you've linked to, the last three sections all fizzle out mid-sentence?

[jgharston]

On the web page you've linked to, the last three sections all fizzle out mid-sentence?

Yes, I was starting to convince myself that the cold I had was affecting me more than I thought.

[rwap]

The Retro-Printer is now available for purchase - www.retroprinter.com

That looks interesting!

On the web page you've linked to, the last three sections all fizzle out mid-sentence?

So they do - they seem to be missing the "Read More...." link

[Coeus]

A Watford screen dump ROM recently surfaced that raises an interesting question about Epson ESC P emulation. My test case was the mode 0 Mexican hat:

Running *SCDUMP with the printer output to a file gives this start:

Code: Select all

00000000 - 0D 0A 0A 0A 0D 1B 41 08 1B 2A 04 80 02 00 00 00 ......A..*......
00000010 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 - 00 00 00 00 00 00 00 00 00 00 00 00 00 CC 33 CC ..............3.
00000050 - 33 CC 33 CC 33 CC 33 CC 33 CC 33 CC 33 CC 33 CC 3.3.3.3.3.3.3.3.
00000060 - 33 CC 33 CC 33 CC 33 CC 33 CC 33 CC 33 CC 33 CC 3.3.3.3.3.3.3.3.

ESC A <8> is setting the vertical spacing to 8 to allow for the fact that the 9th pin is not driven in graphics mode. Next it uses ESC * to set graphics mode 4 (crt mode) which seems to have a good number of dots for the 640 dot line from the BBC micro screen. Then is the data length followed by the data. At the end of this data is:

Code: Select all

00000280 - 33 CC 33 CC 33 CC 33 CC 33 CC 33 CC 33 0A 1B 2A 3.3.3.3.3.3.3..*
00000290 - 04 80 02 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

so after the last byte of graphics data it is sending a single LF character to move to the next line and immediately starting the next line of graphics. This did not convert correctly using ESCParser from ukncbtl-utils, mentioned previously in this thread, because this interprets LF in the way a teletype would, i.e. advancing to the next line without returning the print head to the left margin. Here is the result:

ESCParser also implements CR as a teletype would, i.e. returning the print head to the left margin without advancing the paper. The only manual I have to hand is for the FX80 and that suggests this is the correct behaviour for CR by giving an example of how underlining can be done by printing text, issuing the CR, the overprinting underline characters. To me, though, it does not seem so clear about LF. Here's what it says:

Advances the paper one line.

When this code is input, all the data stored in the print buffer is printed out and then the line feed is carried out. If no data precedes the LF code, or if all preceding data is space, only line feed is performed.

The code cancels the enlarged print mode set by the SO code.

The amount of paper fed may be set by ECO 0, ESC 1, ESC 2, ESC 3 or ESC A code. If data is input in the order of print data -> CR -> LF, data will be printed by the CR code. Then the printer carries out one line feed because no print data precedes the LF code.

It doesn't say that LF returns the print head to the left, and it doesn't say it doesn't do that and, interestingly, despite the overstrike example, the entry in the manual for CR doesn't mention retuning the head to the left either. So to me, there is a hint that printing a line of data from the buffer also clears the buffer so it will start to fill again with data for the next line, so both CR and LF would do this but the documentation is hardly helpful.

Does anyone know for sure? Is there better documentation or does someone have a real one to try this on? If I modify ESCParser to return to the left margin on LF I get a sensible output:

hat2.pdf

(417.36 KiB) Downloaded 41 times

[sweh]

Page 34 of https://files.support.epson.com/pdf/gen ... cp2ref.pdf says, for LF, that it also moves the horizontal print position to the left-most margin.

[Coeus]

Page 34 of https://files.support.epson.com/pdf/gen ... cp2ref.pdf says, for LF, that it also moves the horizontal print position to the left-most margin.

Thanks. I have updated my fork of ukncbtl-utils

[BeebInC]

Fairly sure my original emulator used to just output all the printer output to "printer.log"