Re: [M100] retroprinter and the m100

2024-03-18 Thread Gregory McGill
Glad to hear it

On Mon, Mar 18, 2024, 11:19 AM Will Senn  wrote:

> Hi Gregory,
>
> It's all good. Everything's working now. My exacto knife fix for the
> solder apparently took care of things. I rebuilt the pi's image and got it
> working great.
>
> 1. Configure cups to your printer (mine's a Brother DCP-L2550DW, using
> cups-filter driver) and set the defaults to your liking (mine are):
>
> US Letter
> 2-Sided On (Portrait)
>
> 2. Print a test page (better to know than to wonder, spoken from recent
> experience).
>
> 3. Change two of the settings (ssh into the pi, cd /root/config):
>
> echo -n "CR" > auto_linefeed
> echo -n "ANSI-4" > page_size
>
> 4. reboot the pi (some setting changes don't require them, others seem to,
> better safe than sorry)...
>
> 5. Test by llisting a simple listing in BASIC:
>
> LLIST
>
>
> 6. press F8 to get back to the menu and press enter to test screen print
> (not sure if any graphics will print, but the text works fine).
>
> See the attached image (or look at the scrubbed attachment in the mailing
> list archive).
>
> Absolutely uh-mazing :).
>
> Will
>
>
> On 3/17/24 10:48 PM, Gregory McGill wrote:
>
> Adapter was made because there was a board error on the original board. So
> this adapter fixes whatever was wrong. I'll see if I can get the details
> for you.. If it turns out to be the adapter I could probably get it
> replaced for you if need be or repaired.
>
> On Sun, Mar 17, 2024, 6:47 PM Will Senn  wrote:
>
>> All,
>>
>> Looks like it was a problem with the adapter. My theory that bits 2 and 3
>> were shorted (oh, that's right, not my theory, but Steve's) was confirmed
>> with a few more character test. So, I posted in the retro printer board,
>> sent several 'contact us' posts to the retro folks (their site sucks), and
>> then...
>>
>> Full disclaimer, I am NOT a hardware guy!! But, I madly took that adapter
>> apart and then after doing both sides, saw where some solder was bleeding
>> over from one pin to another on the female side... and a bit of exacto
>> knife  wizardry later and a bit of worry that I'd destroy it, and voila:
>>
>> 10 RMM ABCLMNOLMNOLMNOPQRS\]^_\]^
>> 20 RMM abclmnolmnolmnopqrs|}~|}~
>> 30 RMM 0123<=>?<=0 -_=/_]?>/",<.>
>> <0 RMM /?!@#,-^..,-
>>
>> 10 REM ABCDEFGHIJKLMNOPQRSTUVWXYZ
>> 20 REM abcdefghijklmnopqrstuvwxyz
>> 30 REM 01234567890 -_=+[];:'",<.>
>> 40 REM /?!@#$%^&*()
>>
>>
>> Yay!
>>
>> Now, I can go about setting this goofy retroprinter up properly.
>>
>> Thanks for the forbearance, assistance and sympathy.
>>
>> Will
>>
>>
>> On 3/17/24 5:46 PM, Stephen Adolph wrote:
>>
>> Bit 2 shorted to bit 3?
>>
>> On Sunday, March 17, 2024, Will Senn  wrote:
>>
>>> I tried every config setting... twice or more :).
>>>
>>> It's super consistent in that bits 2, and 3, counting from zero, from
>>> the least significant bits, are having some kind of issue (they aren't
>>> always, zero, or one, but they are always the bits that are wrong and they
>>> are consistently wrong (of the 40 chars or so I tested):
>>>
>>> <0x7f> vs w
>>> 0111
>>> 01110111
>>> 1000 (b3 1->0)
>>>
>>> \ vs T
>>> 01011100
>>> 01010100
>>> 1000 (b3 1->0)
>>>
>>> 4 vs <
>>> 00110100
>>> 0000
>>> 1000 (b3 0->1)
>>>
>>> 5 vs =
>>> 00110101
>>> 0001
>>> 1000 (b3 0->1)
>>> 6 vs >
>>> 00110110
>>> 0010
>>> 1000 (b3 0->1)
>>>
>>> 7 vs ?
>>> 00110111
>>> 0011
>>> 1000 (b3 0->1)
>>>
>>> 8 vs <
>>> 00111000
>>> 0000
>>> 0100 (b3 0->1)
>>>
>>> 9 vs =
>>> 00111001 (b3 0->1)
>>> 0001
>>> 0100
>>>
>>> Weird, huh? Anybody seen anything like it? Can I troubleshoot it with a
>>> multimeter?
>>>
>>> Will
>>>
>>>
>>>
>>>
>>> On 3/17/24 2:13 PM, Will Senn wrote:
>>>
>>> Yep, it's consistent. It took me a while to make some progress on this.
>>> I tried redoing the Centronics side of the cable, and here's my source vs
>>> what the pi sees:
>>>
>>> 10 PRINT "Hello, world!"
>>> 20 GOTO 10
>>>
>>> 10 PRMN\ "Lmllo, orll!"
>>> 20 OO\O 10
>>>
>>> I'm not sure how to troubleshoot...
>>>
>>> I found this in the retroprinter handbook:
>>>
>>> Missing Characters or Repeated Characters:
>>> This is generally because the equipment sending the printout is using
>>> a specific timing mechanism and not necessarily adopting the correct
>>> Centronics signal methods for acknowledgement of data.
>>> We have added the following configuration options to help address
>>> this:
>>> /root/config/handshaking
>>> This allows you to specify how the handshaking is handled between
>>> the computer and the Retro-Printer. This can help overcome issues
>>> with lost characters or repeated characters when the equipment
>>> misses the busy / acknowledge signals.
>>> The parameter takes a value between 0 and 4.
>>> 0 = Busy On (for 5ms), Busy Off, Ack On (for signal time), Ack Off
>>> 1 = Ack On (for signal time), Busy On, Ack Off, Busy Off
>>> 2 = Busy On (for 5ms), Ack On (for signal time), Busy Off, Ack Off
>>> 3 = Ack On (for signal time), Ack Off, Busy On (for 5ms), 

Re: [M100] retroprinter and the m100

2024-03-18 Thread Will Senn

Hi Gregory,

It's all good. Everything's working now. My exacto knife fix for the 
solder apparently took care of things. I rebuilt the pi's image and got 
it working great.


1. Configure cups to your printer (mine's a Brother DCP-L2550DW, using 
cups-filter driver) and set the defaults to your liking (mine are):


   US Letter
   2-Sided On (Portrait)

2. Print a test page (better to know than to wonder, spoken from recent 
experience).


3. Change two of the settings (ssh into the pi, cd /root/config):

   echo -n "CR" > auto_linefeed
   echo -n "ANSI-4" > page_size

4. reboot the pi (some setting changes don't require them, others seem 
to, better safe than sorry)...


5. Test by llisting a simple listing in BASIC:

   LLIST


6. press F8 to get back to the menu and press enter to test screen print 
(not sure if any graphics will print, but the text works fine).


See the attached image (or look at the scrubbed attachment in the 
mailing list archive).


Absolutely uh-mazing :).

Will


On 3/17/24 10:48 PM, Gregory McGill wrote:
Adapter was made because there was a board error on the original 
board. So this adapter fixes whatever was wrong. I'll see if I can get 
the details for you.. If it turns out to be the adapter I could 
probably get it replaced for you if need be or repaired.


On Sun, Mar 17, 2024, 6:47 PM Will Senn  wrote:

All,

Looks like it was a problem with the adapter. My theory that bits
2 and 3 were shorted (oh, that's right, not my theory, but
Steve's) was confirmed with a few more character test. So, I
posted in the retro printer board, sent several 'contact us' posts
to the retro folks (their site sucks), and then...

Full disclaimer, I am NOT a hardware guy!! But, I madly took that
adapter apart and then after doing both sides, saw where some
solder was bleeding over from one pin to another on the female
side... and a bit of exacto knife wizardry later and a bit of
worry that I'd destroy it, and voila:

10 RMM ABCLMNOLMNOLMNOPQRS\]^_\]^
20 RMM abclmnolmnolmnopqrs|}~|}~
30 RMM 0123<=>?<=0 -_=/_]?>/",<.>
<0 RMM /?!@#,-^..,-

10 REM ABCDEFGHIJKLMNOPQRSTUVWXYZ
20 REM abcdefghijklmnopqrstuvwxyz
30 REM 01234567890 -_=+[];:'",<.>
40 REM /?!@#$%^&*()


Yay!

Now, I can go about setting this goofy retroprinter up properly.

Thanks for the forbearance, assistance and sympathy.

Will


On 3/17/24 5:46 PM, Stephen Adolph wrote:

Bit 2 shorted to bit 3?

On Sunday, March 17, 2024, Will Senn  wrote:

I tried every config setting... twice or more :).

It's super consistent in that bits 2, and 3, counting from
zero, from the least significant bits, are having some kind
of issue (they aren't always, zero, or one, but they are
always the bits that are wrong and they are consistently
wrong (of the 40 chars or so I tested):

<0x7f> vs w
0111
01110111
1000 (b3 1->0)

\ vs T
01011100
01010100
1000 (b3 1->0)

4 vs <
00110100
0000
1000 (b3 0->1)

5 vs =
00110101
0001
1000 (b3 0->1)
6 vs >
00110110
0010
1000 (b3 0->1)

7 vs ?
00110111
0011
1000 (b3 0->1)

8 vs <
00111000
0000
0100 (b3 0->1)

9 vs =
00111001 (b3 0->1)
0001
0100

Weird, huh? Anybody seen anything like it? Can I troubleshoot
it with a multimeter?

Will




On 3/17/24 2:13 PM, Will Senn wrote:

Yep, it's consistent. It took me a while to make some
progress on this. I tried redoing the Centronics side of the
cable, and here's my source vs what the pi sees:

10 PRINT "Hello, world!"
20 GOTO 10

10 PRMN\ "Lmllo, orll!"
20 OO\O 10

I'm not sure how to troubleshoot...

I found this in the retroprinter handbook:

Missing Characters or Repeated Characters:
This is generally because the equipment sending the printout
is using
a specific timing mechanism and not necessarily adopting the
correct
Centronics signal methods for acknowledgement of data.
We have added the following configuration options to help
address
this:
/root/config/handshaking
This allows you to specify how the handshaking is handled
between
the computer and the Retro-Printer. This can help overcome
issues
with lost characters or repeated characters when the equipment
misses the busy / acknowledge signals.
The parameter takes a value between 0 and 4.
0 = Busy On (for 5ms), Busy Off, Ack On (for signal time),
Ack Off
1 = Ack On (for signal time), Busy On, Ack Off, 

Re: [M100] retroprinter and the m100

2024-03-17 Thread Gregory McGill
Also this

As shipped, the default setting for the Retro-Printer is to expect 8 bit
data - however, some equipment only sends 7 bit data (and the 8th bit can
be quite temperamental).
Changing the bit_depth parameter for the Retro-Printer Module will address
this

On Sun, Mar 17, 2024, 8:48 PM Gregory McGill 
wrote:

> Adapter was made because there was a board error on the original board. So
> this adapter fixes whatever was wrong. I'll see if I can get the details
> for you.. If it turns out to be the adapter I could probably get it
> replaced for you if need be or repaired.
>
> On Sun, Mar 17, 2024, 6:47 PM Will Senn  wrote:
>
>> All,
>>
>> Looks like it was a problem with the adapter. My theory that bits 2 and 3
>> were shorted (oh, that's right, not my theory, but Steve's) was confirmed
>> with a few more character test. So, I posted in the retro printer board,
>> sent several 'contact us' posts to the retro folks (their site sucks), and
>> then...
>>
>> Full disclaimer, I am NOT a hardware guy!! But, I madly took that adapter
>> apart and then after doing both sides, saw where some solder was bleeding
>> over from one pin to another on the female side... and a bit of exacto
>> knife  wizardry later and a bit of worry that I'd destroy it, and voila:
>>
>> 10 RMM ABCLMNOLMNOLMNOPQRS\]^_\]^
>> 20 RMM abclmnolmnolmnopqrs|}~|}~
>> 30 RMM 0123<=>?<=0 -_=/_]?>/",<.>
>> <0 RMM /?!@#,-^..,-
>>
>> 10 REM ABCDEFGHIJKLMNOPQRSTUVWXYZ
>> 20 REM abcdefghijklmnopqrstuvwxyz
>> 30 REM 01234567890 -_=+[];:'",<.>
>> 40 REM /?!@#$%^&*()
>>
>>
>> Yay!
>>
>> Now, I can go about setting this goofy retroprinter up properly.
>>
>> Thanks for the forbearance, assistance and sympathy.
>>
>> Will
>>
>>
>> On 3/17/24 5:46 PM, Stephen Adolph wrote:
>>
>> Bit 2 shorted to bit 3?
>>
>> On Sunday, March 17, 2024, Will Senn  wrote:
>>
>>> I tried every config setting... twice or more :).
>>>
>>> It's super consistent in that bits 2, and 3, counting from zero, from
>>> the least significant bits, are having some kind of issue (they aren't
>>> always, zero, or one, but they are always the bits that are wrong and they
>>> are consistently wrong (of the 40 chars or so I tested):
>>>
>>> <0x7f> vs w
>>> 0111
>>> 01110111
>>> 1000 (b3 1->0)
>>>
>>> \ vs T
>>> 01011100
>>> 01010100
>>> 1000 (b3 1->0)
>>>
>>> 4 vs <
>>> 00110100
>>> 0000
>>> 1000 (b3 0->1)
>>>
>>> 5 vs =
>>> 00110101
>>> 0001
>>> 1000 (b3 0->1)
>>> 6 vs >
>>> 00110110
>>> 0010
>>> 1000 (b3 0->1)
>>>
>>> 7 vs ?
>>> 00110111
>>> 0011
>>> 1000 (b3 0->1)
>>>
>>> 8 vs <
>>> 00111000
>>> 0000
>>> 0100 (b3 0->1)
>>>
>>> 9 vs =
>>> 00111001 (b3 0->1)
>>> 0001
>>> 0100
>>>
>>> Weird, huh? Anybody seen anything like it? Can I troubleshoot it with a
>>> multimeter?
>>>
>>> Will
>>>
>>>
>>>
>>>
>>> On 3/17/24 2:13 PM, Will Senn wrote:
>>>
>>> Yep, it's consistent. It took me a while to make some progress on this.
>>> I tried redoing the Centronics side of the cable, and here's my source vs
>>> what the pi sees:
>>>
>>> 10 PRINT "Hello, world!"
>>> 20 GOTO 10
>>>
>>> 10 PRMN\ "Lmllo, orll!"
>>> 20 OO\O 10
>>>
>>> I'm not sure how to troubleshoot...
>>>
>>> I found this in the retroprinter handbook:
>>>
>>> Missing Characters or Repeated Characters:
>>> This is generally because the equipment sending the printout is using
>>> a specific timing mechanism and not necessarily adopting the correct
>>> Centronics signal methods for acknowledgement of data.
>>> We have added the following configuration options to help address
>>> this:
>>> /root/config/handshaking
>>> This allows you to specify how the handshaking is handled between
>>> the computer and the Retro-Printer. This can help overcome issues
>>> with lost characters or repeated characters when the equipment
>>> misses the busy / acknowledge signals.
>>> The parameter takes a value between 0 and 4.
>>> 0 = Busy On (for 5ms), Busy Off, Ack On (for signal time), Ack Off
>>> 1 = Ack On (for signal time), Busy On, Ack Off, Busy Off
>>> 2 = Busy On (for 5ms), Ack On (for signal time), Busy Off, Ack Off
>>> 3 = Ack On (for signal time), Ack Off, Busy On (for 5ms), Busy Off
>>> 4 = Busy On and Ack On (for signal time), Ack Off and Busy Off
>>> Default is 0
>>>
>>> Any idea how the M100 handshakes?
>>>
>>> Will
>>>
>>>
>>> On 3/17/24 7:18 AM, Mike Stein wrote:
>>>
>>> Is it consistent, i.e. do you always get the same garbled output for a
>>> given file?
>>>
>>> At a fast glance it looks like bits 2 and/or 3 are being dropped; have
>>> you checked the computer to Pi cable and connectors?
>>>
>>> m
>>>
>>> On Sun, Mar 17, 2024 at 2:14 AM Will Senn  wrote:
>>>
 I am finally coming back around to this. I bought a retroprinter a year
 and half ago or so and shelved it out of frustration. Now, I know a lot
 more about this sorta stuff and so I pulled it out, updated the software to
 latest and tried to get it working.

 The PI prints a test page fine, but it won't 

Re: [M100] retroprinter and the m100

2024-03-17 Thread Gregory McGill
Adapter was made because there was a board error on the original board. So
this adapter fixes whatever was wrong. I'll see if I can get the details
for you.. If it turns out to be the adapter I could probably get it
replaced for you if need be or repaired.

On Sun, Mar 17, 2024, 6:47 PM Will Senn  wrote:

> All,
>
> Looks like it was a problem with the adapter. My theory that bits 2 and 3
> were shorted (oh, that's right, not my theory, but Steve's) was confirmed
> with a few more character test. So, I posted in the retro printer board,
> sent several 'contact us' posts to the retro folks (their site sucks), and
> then...
>
> Full disclaimer, I am NOT a hardware guy!! But, I madly took that adapter
> apart and then after doing both sides, saw where some solder was bleeding
> over from one pin to another on the female side... and a bit of exacto
> knife  wizardry later and a bit of worry that I'd destroy it, and voila:
>
> 10 RMM ABCLMNOLMNOLMNOPQRS\]^_\]^
> 20 RMM abclmnolmnolmnopqrs|}~|}~
> 30 RMM 0123<=>?<=0 -_=/_]?>/",<.>
> <0 RMM /?!@#,-^..,-
>
> 10 REM ABCDEFGHIJKLMNOPQRSTUVWXYZ
> 20 REM abcdefghijklmnopqrstuvwxyz
> 30 REM 01234567890 -_=+[];:'",<.>
> 40 REM /?!@#$%^&*()
>
>
> Yay!
>
> Now, I can go about setting this goofy retroprinter up properly.
>
> Thanks for the forbearance, assistance and sympathy.
>
> Will
>
>
> On 3/17/24 5:46 PM, Stephen Adolph wrote:
>
> Bit 2 shorted to bit 3?
>
> On Sunday, March 17, 2024, Will Senn  wrote:
>
>> I tried every config setting... twice or more :).
>>
>> It's super consistent in that bits 2, and 3, counting from zero, from the
>> least significant bits, are having some kind of issue (they aren't always,
>> zero, or one, but they are always the bits that are wrong and they are
>> consistently wrong (of the 40 chars or so I tested):
>>
>> <0x7f> vs w
>> 0111
>> 01110111
>> 1000 (b3 1->0)
>>
>> \ vs T
>> 01011100
>> 01010100
>> 1000 (b3 1->0)
>>
>> 4 vs <
>> 00110100
>> 0000
>> 1000 (b3 0->1)
>>
>> 5 vs =
>> 00110101
>> 0001
>> 1000 (b3 0->1)
>> 6 vs >
>> 00110110
>> 0010
>> 1000 (b3 0->1)
>>
>> 7 vs ?
>> 00110111
>> 0011
>> 1000 (b3 0->1)
>>
>> 8 vs <
>> 00111000
>> 0000
>> 0100 (b3 0->1)
>>
>> 9 vs =
>> 00111001 (b3 0->1)
>> 0001
>> 0100
>>
>> Weird, huh? Anybody seen anything like it? Can I troubleshoot it with a
>> multimeter?
>>
>> Will
>>
>>
>>
>>
>> On 3/17/24 2:13 PM, Will Senn wrote:
>>
>> Yep, it's consistent. It took me a while to make some progress on this. I
>> tried redoing the Centronics side of the cable, and here's my source vs
>> what the pi sees:
>>
>> 10 PRINT "Hello, world!"
>> 20 GOTO 10
>>
>> 10 PRMN\ "Lmllo, orll!"
>> 20 OO\O 10
>>
>> I'm not sure how to troubleshoot...
>>
>> I found this in the retroprinter handbook:
>>
>> Missing Characters or Repeated Characters:
>> This is generally because the equipment sending the printout is using
>> a specific timing mechanism and not necessarily adopting the correct
>> Centronics signal methods for acknowledgement of data.
>> We have added the following configuration options to help address
>> this:
>> /root/config/handshaking
>> This allows you to specify how the handshaking is handled between
>> the computer and the Retro-Printer. This can help overcome issues
>> with lost characters or repeated characters when the equipment
>> misses the busy / acknowledge signals.
>> The parameter takes a value between 0 and 4.
>> 0 = Busy On (for 5ms), Busy Off, Ack On (for signal time), Ack Off
>> 1 = Ack On (for signal time), Busy On, Ack Off, Busy Off
>> 2 = Busy On (for 5ms), Ack On (for signal time), Busy Off, Ack Off
>> 3 = Ack On (for signal time), Ack Off, Busy On (for 5ms), Busy Off
>> 4 = Busy On and Ack On (for signal time), Ack Off and Busy Off
>> Default is 0
>>
>> Any idea how the M100 handshakes?
>>
>> Will
>>
>>
>> On 3/17/24 7:18 AM, Mike Stein wrote:
>>
>> Is it consistent, i.e. do you always get the same garbled output for a
>> given file?
>>
>> At a fast glance it looks like bits 2 and/or 3 are being dropped; have
>> you checked the computer to Pi cable and connectors?
>>
>> m
>>
>> On Sun, Mar 17, 2024 at 2:14 AM Will Senn  wrote:
>>
>>> I am finally coming back around to this. I bought a retroprinter a year
>>> and half ago or so and shelved it out of frustration. Now, I know a lot
>>> more about this sorta stuff and so I pulled it out, updated the software to
>>> latest and tried to get it working.
>>>
>>> The PI prints a test page fine, but it won't print anything I send it
>>> from the M100. After hours of troubleshooting, it appears that whatever
>>> codes the pi is sending aren't DMP-15, EPSON ESC/P or Plain Text codes...
>>> When I do llist, I see the data coming across to the retroprinter and have
>>> set up a file to capture, but I can't find anything that will make sense of
>>> the data.
>>>
>>> Here's a sample:
>>>
>>> 10 PRMN\ "lmllo"
>>> 1= RMS\ORM =0>NORM=0\O1>RMALR,M-,Q,,M-,C,,M,0-,C,,M,1->CL,M-=0>NM\\M
>>> 20 

Re: [M100] retroprinter and the m100

2024-03-17 Thread Will Senn

All,

Looks like it was a problem with the adapter. My theory that bits 2 and 
3 were shorted (oh, that's right, not my theory, but Steve's) was 
confirmed with a few more character test. So, I posted in the retro 
printer board, sent several 'contact us' posts to the retro folks (their 
site sucks), and then...


Full disclaimer, I am NOT a hardware guy!! But, I madly took that 
adapter apart and then after doing both sides, saw where some solder was 
bleeding over from one pin to another on the female side... and a bit of 
exacto knife  wizardry later and a bit of worry that I'd destroy it, and 
voila:


10 RMM ABCLMNOLMNOLMNOPQRS\]^_\]^
20 RMM abclmnolmnolmnopqrs|}~|}~
30 RMM 0123<=>?<=0 -_=/_]?>/",<.>
<0 RMM /?!@#,-^..,-

10 REM ABCDEFGHIJKLMNOPQRSTUVWXYZ
20 REM abcdefghijklmnopqrstuvwxyz
30 REM 01234567890 -_=+[];:'",<.>
40 REM /?!@#$%^&*()


Yay!

Now, I can go about setting this goofy retroprinter up properly.

Thanks for the forbearance, assistance and sympathy.

Will


On 3/17/24 5:46 PM, Stephen Adolph wrote:

Bit 2 shorted to bit 3?

On Sunday, March 17, 2024, Will Senn  wrote:

I tried every config setting... twice or more :).

It's super consistent in that bits 2, and 3, counting from zero,
from the least significant bits, are having some kind of issue
(they aren't always, zero, or one, but they are always the bits
that are wrong and they are consistently wrong (of the 40 chars or
so I tested):

<0x7f> vs w
0111
01110111
1000 (b3 1->0)

\ vs T
01011100
01010100
1000 (b3 1->0)

4 vs <
00110100
0000
1000 (b3 0->1)

5 vs =
00110101
0001
1000 (b3 0->1)
6 vs >
00110110
0010
1000 (b3 0->1)

7 vs ?
00110111
0011
1000 (b3 0->1)

8 vs <
00111000
0000
0100 (b3 0->1)

9 vs =
00111001 (b3 0->1)
0001
0100

Weird, huh? Anybody seen anything like it? Can I troubleshoot it
with a multimeter?

Will




On 3/17/24 2:13 PM, Will Senn wrote:

Yep, it's consistent. It took me a while to make some progress on
this. I tried redoing the Centronics side of the cable, and
here's my source vs what the pi sees:

10 PRINT "Hello, world!"
20 GOTO 10

10 PRMN\ "Lmllo, orll!"
20 OO\O 10

I'm not sure how to troubleshoot...

I found this in the retroprinter handbook:

Missing Characters or Repeated Characters:
This is generally because the equipment sending the printout is using
a specific timing mechanism and not necessarily adopting the correct
Centronics signal methods for acknowledgement of data.
We have added the following configuration options to help address
this:
/root/config/handshaking
This allows you to specify how the handshaking is handled between
the computer and the Retro-Printer. This can help overcome issues
with lost characters or repeated characters when the equipment
misses the busy / acknowledge signals.
The parameter takes a value between 0 and 4.
0 = Busy On (for 5ms), Busy Off, Ack On (for signal time), Ack Off
1 = Ack On (for signal time), Busy On, Ack Off, Busy Off
2 = Busy On (for 5ms), Ack On (for signal time), Busy Off, Ack Off
3 = Ack On (for signal time), Ack Off, Busy On (for 5ms), Busy Off
4 = Busy On and Ack On (for signal time), Ack Off and Busy Off
Default is 0

Any idea how the M100 handshakes?

Will


On 3/17/24 7:18 AM, Mike Stein wrote:

Is it consistent, i.e. do you always get the same garbled output
for a given file?

At a fast glance it looks like bits 2 and/or 3 are being
dropped; have you checked the computer to Pi cable and connectors?

m

On Sun, Mar 17, 2024 at 2:14 AM Will Senn 
wrote:

I am finally coming back around to this. I bought a
retroprinter a year and half ago or so and shelved it out of
frustration. Now, I know a lot more about this sorta stuff
and so I pulled it out, updated the software to latest and
tried to get it working.

The PI prints a test page fine, but it won't print anything
I send it from the M100. After hours of troubleshooting, it
appears that whatever codes the pi is sending aren't DMP-15,
EPSON ESC/P or Plain Text codes... When I do llist, I see
the data coming across to the retroprinter and have set up a
file to capture, but I can't find anything that will make
sense of the data.

Here's a sample:

10 PRMN\ "lmllo"
1= RMS\ORM
=0>NORM=0\O1>RMALR,M-,Q,,M-,C,,M,0-,C,,M,1->CL,M-=0>NM\\M
20 M=0
2= O=0>OOS]B<0
30 OOS]B<=

It looks like reasonably valid data and not complete
gibberish, but who am I to judge. Is it one of:

Epson ESC/P 9 Pin - didn't work, when I tried it
Epson ESC/P 24/48 Pin
HP 

Re: [M100] retroprinter and the m100

2024-03-17 Thread Will Senn
So... I got out the multimeter and started testing the pins on this 
adapter thingy that the retroprinter comes with and sure enough pin 4 on 
male side maps to both 4 and 5 on the female side and pin 5 on the male 
side goes to both 4 and 5 on the female side - as I read it 
(https://pinoutguide.com/ParallelPorts/ieee1284b_pinout.shtml) pin 4 
drives bit 3 of the data (bit 2 counting from 0) and pin 5 drives bit 4 
(bit 3 counting from 0).


So if one is 0 and the other is 1, or they're both 1, then the output is 
1 and if both are 0, then it's 0? Hmm... off to verify with reality. 
Promising, if annoying.


See the pic (if the list allows it) it's a Male to Female arrangement of 
Centronics 36's. How to fix?


Will

On 3/17/24 5:46 PM, Stephen Adolph wrote:

Bit 2 shorted to bit 3?

On Sunday, March 17, 2024, Will Senn  wrote:

I tried every config setting... twice or more :).

It's super consistent in that bits 2, and 3, counting from zero,
from the least significant bits, are having some kind of issue
(they aren't always, zero, or one, but they are always the bits
that are wrong and they are consistently wrong (of the 40 chars or
so I tested):

<0x7f> vs w
0111
01110111
1000 (b3 1->0)

\ vs T
01011100
01010100
1000 (b3 1->0)

4 vs <
00110100
0000
1000 (b3 0->1)

5 vs =
00110101
0001
1000 (b3 0->1)
6 vs >
00110110
0010
1000 (b3 0->1)

7 vs ?
00110111
0011
1000 (b3 0->1)

8 vs <
00111000
0000
0100 (b3 0->1)

9 vs =
00111001 (b3 0->1)
0001
0100

Weird, huh? Anybody seen anything like it? Can I troubleshoot it
with a multimeter?

Will




On 3/17/24 2:13 PM, Will Senn wrote:

Yep, it's consistent. It took me a while to make some progress on
this. I tried redoing the Centronics side of the cable, and
here's my source vs what the pi sees:

10 PRINT "Hello, world!"
20 GOTO 10

10 PRMN\ "Lmllo, orll!"
20 OO\O 10

I'm not sure how to troubleshoot...

I found this in the retroprinter handbook:

Missing Characters or Repeated Characters:
This is generally because the equipment sending the printout is using
a specific timing mechanism and not necessarily adopting the correct
Centronics signal methods for acknowledgement of data.
We have added the following configuration options to help address
this:
/root/config/handshaking
This allows you to specify how the handshaking is handled between
the computer and the Retro-Printer. This can help overcome issues
with lost characters or repeated characters when the equipment
misses the busy / acknowledge signals.
The parameter takes a value between 0 and 4.
0 = Busy On (for 5ms), Busy Off, Ack On (for signal time), Ack Off
1 = Ack On (for signal time), Busy On, Ack Off, Busy Off
2 = Busy On (for 5ms), Ack On (for signal time), Busy Off, Ack Off
3 = Ack On (for signal time), Ack Off, Busy On (for 5ms), Busy Off
4 = Busy On and Ack On (for signal time), Ack Off and Busy Off
Default is 0

Any idea how the M100 handshakes?

Will


On 3/17/24 7:18 AM, Mike Stein wrote:

Is it consistent, i.e. do you always get the same garbled output
for a given file?

At a fast glance it looks like bits 2 and/or 3 are being
dropped; have you checked the computer to Pi cable and connectors?

m

On Sun, Mar 17, 2024 at 2:14 AM Will Senn 
wrote:

I am finally coming back around to this. I bought a
retroprinter a year and half ago or so and shelved it out of
frustration. Now, I know a lot more about this sorta stuff
and so I pulled it out, updated the software to latest and
tried to get it working.

The PI prints a test page fine, but it won't print anything
I send it from the M100. After hours of troubleshooting, it
appears that whatever codes the pi is sending aren't DMP-15,
EPSON ESC/P or Plain Text codes... When I do llist, I see
the data coming across to the retroprinter and have set up a
file to capture, but I can't find anything that will make
sense of the data.

Here's a sample:

10 PRMN\ "lmllo"
1= RMS\ORM
=0>NORM=0\O1>RMALR,M-,Q,,M-,C,,M,0-,C,,M,1->CL,M-=0>NM\\M
20 M=0
2= O=0>OOS]B<0
30 OOS]B<=

It looks like reasonably valid data and not complete
gibberish, but who am I to judge. Is it one of:

Epson ESC/P 9 Pin - didn't work, when I tried it
Epson ESC/P 24/48 Pin
HP Printer (PCL3 or PCL5)
HP Plotter (HP-GL)
IBM ProPrinter
Plain Text- didn't work, when I tried it
Postscript
Printronix-P Series
Printronix-S Series
Seiko QT-2100P
Siemens PT-88
Apple Image 

Re: [M100] retroprinter and the m100

2024-03-17 Thread Stephen Adolph
Bit 2 shorted to bit 3?

On Sunday, March 17, 2024, Will Senn  wrote:

> I tried every config setting... twice or more :).
>
> It's super consistent in that bits 2, and 3, counting from zero, from the
> least significant bits, are having some kind of issue (they aren't always,
> zero, or one, but they are always the bits that are wrong and they are
> consistently wrong (of the 40 chars or so I tested):
>
> <0x7f> vs w
> 0111
> 01110111
> 1000 (b3 1->0)
>
> \ vs T
> 01011100
> 01010100
> 1000 (b3 1->0)
>
> 4 vs <
> 00110100
> 0000
> 1000 (b3 0->1)
>
> 5 vs =
> 00110101
> 0001
> 1000 (b3 0->1)
> 6 vs >
> 00110110
> 0010
> 1000 (b3 0->1)
>
> 7 vs ?
> 00110111
> 0011
> 1000 (b3 0->1)
>
> 8 vs <
> 00111000
> 0000
> 0100 (b3 0->1)
>
> 9 vs =
> 00111001 (b3 0->1)
> 0001
> 0100
>
> Weird, huh? Anybody seen anything like it? Can I troubleshoot it with a
> multimeter?
>
> Will
>
>
>
>
> On 3/17/24 2:13 PM, Will Senn wrote:
>
> Yep, it's consistent. It took me a while to make some progress on this. I
> tried redoing the Centronics side of the cable, and here's my source vs
> what the pi sees:
>
> 10 PRINT "Hello, world!"
> 20 GOTO 10
>
> 10 PRMN\ "Lmllo, orll!"
> 20 OO\O 10
>
> I'm not sure how to troubleshoot...
>
> I found this in the retroprinter handbook:
>
> Missing Characters or Repeated Characters:
> This is generally because the equipment sending the printout is using
> a specific timing mechanism and not necessarily adopting the correct
> Centronics signal methods for acknowledgement of data.
> We have added the following configuration options to help address
> this:
> /root/config/handshaking
> This allows you to specify how the handshaking is handled between
> the computer and the Retro-Printer. This can help overcome issues
> with lost characters or repeated characters when the equipment
> misses the busy / acknowledge signals.
> The parameter takes a value between 0 and 4.
> 0 = Busy On (for 5ms), Busy Off, Ack On (for signal time), Ack Off
> 1 = Ack On (for signal time), Busy On, Ack Off, Busy Off
> 2 = Busy On (for 5ms), Ack On (for signal time), Busy Off, Ack Off
> 3 = Ack On (for signal time), Ack Off, Busy On (for 5ms), Busy Off
> 4 = Busy On and Ack On (for signal time), Ack Off and Busy Off
> Default is 0
>
> Any idea how the M100 handshakes?
>
> Will
>
>
> On 3/17/24 7:18 AM, Mike Stein wrote:
>
> Is it consistent, i.e. do you always get the same garbled output for a
> given file?
>
> At a fast glance it looks like bits 2 and/or 3 are being dropped; have you
> checked the computer to Pi cable and connectors?
>
> m
>
> On Sun, Mar 17, 2024 at 2:14 AM Will Senn  wrote:
>
>> I am finally coming back around to this. I bought a retroprinter a year
>> and half ago or so and shelved it out of frustration. Now, I know a lot
>> more about this sorta stuff and so I pulled it out, updated the software to
>> latest and tried to get it working.
>>
>> The PI prints a test page fine, but it won't print anything I send it
>> from the M100. After hours of troubleshooting, it appears that whatever
>> codes the pi is sending aren't DMP-15, EPSON ESC/P or Plain Text codes...
>> When I do llist, I see the data coming across to the retroprinter and have
>> set up a file to capture, but I can't find anything that will make sense of
>> the data.
>>
>> Here's a sample:
>>
>> 10 PRMN\ "lmllo"
>> 1= RMS\ORM =0>NORM=0\O1>RMALR,M-,Q,,M-,C,,M,0-,C,,M,1->CL,M-=0>NM\\M
>> 20 M=0
>> 2= O=0>OOS]B<0
>> 30 OOS]B<=
>>
>> It looks like reasonably valid data and not complete gibberish, but who
>> am I to judge. Is it one of:
>>
>> Epson ESC/P 9 Pin - didn't work, when I tried it
>> Epson ESC/P 24/48 Pin
>> HP Printer (PCL3 or PCL5)
>> HP Plotter (HP-GL)
>> IBM ProPrinter
>> Plain Text - didn't work, when I tried it
>> Postscript
>> Printronix-P Series
>> Printronix-S Series
>> Seiko QT-2100P
>> Siemens PT-88
>> Apple Image Writer II
>> Seiko STP
>> Star Micronics SP700
>> Tandy DMP-105 - didn't work, when I tried it
>>
>> Help and thank you.
>>
>>
>
>


Re: [M100] retroprinter and the m100

2024-03-17 Thread Mike Stein
Yeah, definitely something amiss with bits 2 and 3. When I looked at a few
characters it happened that they all became 0 instead of 1 and it was just
dropping bits, but apparently it's also reading a 1 instead of 0 in some
cases.

The M100 printer port is not 100% Centronics-compatible and it's also
partially shared with the keyboard, so there might be a timing issue; I'm
guessing you don't have another computer with a parallel printer port that
you could try?

m

On Sun, Mar 17, 2024 at 4:17 PM Will Senn  wrote:

> I tried every config setting... twice or more :).
>
> It's super consistent in that bits 2, and 3, counting from zero, from the
> least significant bits, are having some kind of issue (they aren't always,
> zero, or one, but they are always the bits that are wrong and they are
> consistently wrong (of the 40 chars or so I tested):
>
> <0x7f> vs w
> 0111
> 01110111
> 1000 (b3 1->0)
>
> \ vs T
> 01011100
> 01010100
> 1000 (b3 1->0)
>
> 4 vs <
> 00110100
> 0000
> 1000 (b3 0->1)
>
> 5 vs =
> 00110101
> 0001
> 1000 (b3 0->1)
> 6 vs >
> 00110110
> 0010
> 1000 (b3 0->1)
>
> 7 vs ?
> 00110111
> 0011
> 1000 (b3 0->1)
>
> 8 vs <
> 00111000
> 0000
> 0100 (b3 0->1)
>
> 9 vs =
> 00111001 (b3 0->1)
> 0001
> 0100
>
> Weird, huh? Anybody seen anything like it? Can I troubleshoot it with a
> multimeter?
>
> Will
>
>
>
>
> On 3/17/24 2:13 PM, Will Senn wrote:
>
> Yep, it's consistent. It took me a while to make some progress on this. I
> tried redoing the Centronics side of the cable, and here's my source vs
> what the pi sees:
>
> 10 PRINT "Hello, world!"
> 20 GOTO 10
>
> 10 PRMN\ "Lmllo, orll!"
> 20 OO\O 10
>
> I'm not sure how to troubleshoot...
>
> I found this in the retroprinter handbook:
>
> Missing Characters or Repeated Characters:
> This is generally because the equipment sending the printout is using
> a specific timing mechanism and not necessarily adopting the correct
> Centronics signal methods for acknowledgement of data.
> We have added the following configuration options to help address
> this:
> /root/config/handshaking
> This allows you to specify how the handshaking is handled between
> the computer and the Retro-Printer. This can help overcome issues
> with lost characters or repeated characters when the equipment
> misses the busy / acknowledge signals.
> The parameter takes a value between 0 and 4.
> 0 = Busy On (for 5ms), Busy Off, Ack On (for signal time), Ack Off
> 1 = Ack On (for signal time), Busy On, Ack Off, Busy Off
> 2 = Busy On (for 5ms), Ack On (for signal time), Busy Off, Ack Off
> 3 = Ack On (for signal time), Ack Off, Busy On (for 5ms), Busy Off
> 4 = Busy On and Ack On (for signal time), Ack Off and Busy Off
> Default is 0
>
> Any idea how the M100 handshakes?
>
> Will
>
>
> On 3/17/24 7:18 AM, Mike Stein wrote:
>
> Is it consistent, i.e. do you always get the same garbled output for a
> given file?
>
> At a fast glance it looks like bits 2 and/or 3 are being dropped; have you
> checked the computer to Pi cable and connectors?
>
> m
>
> On Sun, Mar 17, 2024 at 2:14 AM Will Senn  wrote:
>
>> I am finally coming back around to this. I bought a retroprinter a year
>> and half ago or so and shelved it out of frustration. Now, I know a lot
>> more about this sorta stuff and so I pulled it out, updated the software to
>> latest and tried to get it working.
>>
>> The PI prints a test page fine, but it won't print anything I send it
>> from the M100. After hours of troubleshooting, it appears that whatever
>> codes the pi is sending aren't DMP-15, EPSON ESC/P or Plain Text codes...
>> When I do llist, I see the data coming across to the retroprinter and have
>> set up a file to capture, but I can't find anything that will make sense of
>> the data.
>>
>> Here's a sample:
>>
>> 10 PRMN\ "lmllo"
>> 1= RMS\ORM =0>NORM=0\O1>RMALR,M-,Q,,M-,C,,M,0-,C,,M,1->CL,M-=0>NM\\M
>> 20 M=0
>> 2= O=0>OOS]B<0
>> 30 OOS]B<=
>>
>> It looks like reasonably valid data and not complete gibberish, but who
>> am I to judge. Is it one of:
>>
>> Epson ESC/P 9 Pin - didn't work, when I tried it
>> Epson ESC/P 24/48 Pin
>> HP Printer (PCL3 or PCL5)
>> HP Plotter (HP-GL)
>> IBM ProPrinter
>> Plain Text - didn't work, when I tried it
>> Postscript
>> Printronix-P Series
>> Printronix-S Series
>> Seiko QT-2100P
>> Siemens PT-88
>> Apple Image Writer II
>> Seiko STP
>> Star Micronics SP700
>> Tandy DMP-105 - didn't work, when I tried it
>>
>> Help and thank you.
>>
>>
>
>


Re: [M100] retroprinter and the m100

2024-03-17 Thread Will Senn

I tried every config setting... twice or more :).

It's super consistent in that bits 2, and 3, counting from zero, from 
the least significant bits, are having some kind of issue (they aren't 
always, zero, or one, but they are always the bits that are wrong and 
they are consistently wrong (of the 40 chars or so I tested):


<0x7f> vs w
0111
01110111
1000 (b3 1->0)

\ vs T
01011100
01010100
1000 (b3 1->0)

4 vs <
00110100
0000
1000 (b3 0->1)

5 vs =
00110101
0001
1000 (b3 0->1)
6 vs >
00110110
0010
1000 (b3 0->1)

7 vs ?
00110111
0011
1000 (b3 0->1)

8 vs <
00111000
0000
0100 (b3 0->1)

9 vs =
00111001 (b3 0->1)
0001
0100

Weird, huh? Anybody seen anything like it? Can I troubleshoot it with a 
multimeter?


Will




On 3/17/24 2:13 PM, Will Senn wrote:
Yep, it's consistent. It took me a while to make some progress on 
this. I tried redoing the Centronics side of the cable, and here's my 
source vs what the pi sees:


10 PRINT "Hello, world!"
20 GOTO 10

10 PRMN\ "Lmllo, orll!"
20 OO\O 10

I'm not sure how to troubleshoot...

I found this in the retroprinter handbook:

Missing Characters or Repeated Characters:
This is generally because the equipment sending the printout is using
a specific timing mechanism and not necessarily adopting the correct
Centronics signal methods for acknowledgement of data.
We have added the following configuration options to help address
this:
/root/config/handshaking
This allows you to specify how the handshaking is handled between
the computer and the Retro-Printer. This can help overcome issues
with lost characters or repeated characters when the equipment
misses the busy / acknowledge signals.
The parameter takes a value between 0 and 4.
0 = Busy On (for 5ms), Busy Off, Ack On (for signal time), Ack Off
1 = Ack On (for signal time), Busy On, Ack Off, Busy Off
2 = Busy On (for 5ms), Ack On (for signal time), Busy Off, Ack Off
3 = Ack On (for signal time), Ack Off, Busy On (for 5ms), Busy Off
4 = Busy On and Ack On (for signal time), Ack Off and Busy Off
Default is 0

Any idea how the M100 handshakes?

Will


On 3/17/24 7:18 AM, Mike Stein wrote:
Is it consistent, i.e. do you always get the same garbled output for 
a given file?


At a fast glance it looks like bits 2 and/or 3 are being dropped; 
have you checked the computer to Pi cable and connectors?


m

On Sun, Mar 17, 2024 at 2:14 AM Will Senn  wrote:

I am finally coming back around to this. I bought a retroprinter
a year and half ago or so and shelved it out of frustration. Now,
I know a lot more about this sorta stuff and so I pulled it out,
updated the software to latest and tried to get it working.

The PI prints a test page fine, but it won't print anything I
send it from the M100. After hours of troubleshooting, it appears
that whatever codes the pi is sending aren't DMP-15, EPSON ESC/P
or Plain Text codes... When I do llist, I see the data coming
across to the retroprinter and have set up a file to capture, but
I can't find anything that will make sense of the data.

Here's a sample:

10 PRMN\ "lmllo"
1= RMS\ORM =0>NORM=0\O1>RMALR,M-,Q,,M-,C,,M,0-,C,,M,1->CL,M-=0>NM\\M
20 M=0
2= O=0>OOS]B<0
30 OOS]B<=

It looks like reasonably valid data and not complete gibberish,
but who am I to judge. Is it one of:

Epson ESC/P 9 Pin - didn't work, when I tried it
Epson ESC/P 24/48 Pin
HP Printer (PCL3 or PCL5)
HP Plotter (HP-GL)
IBM ProPrinter
Plain Text- didn't work, when I tried it
Postscript
Printronix-P Series
Printronix-S Series
Seiko QT-2100P
Siemens PT-88
Apple Image Writer II
Seiko STP
Star Micronics SP700
Tandy DMP-105- didn't work, when I tried it

Help and thank you.





Re: [M100] retroprinter and the m100

2024-03-17 Thread Will Senn
Yep, it's consistent. It took me a while to make some progress on this. 
I tried redoing the Centronics side of the cable, and here's my source 
vs what the pi sees:


10 PRINT "Hello, world!"
20 GOTO 10

10 PRMN\ "Lmllo, orll!"
20 OO\O 10

I'm not sure how to troubleshoot...

I found this in the retroprinter handbook:

Missing Characters or Repeated Characters:
This is generally because the equipment sending the printout is using
a specific timing mechanism and not necessarily adopting the correct
Centronics signal methods for acknowledgement of data.
We have added the following configuration options to help address
this:
/root/config/handshaking
This allows you to specify how the handshaking is handled between
the computer and the Retro-Printer. This can help overcome issues
with lost characters or repeated characters when the equipment
misses the busy / acknowledge signals.
The parameter takes a value between 0 and 4.
0 = Busy On (for 5ms), Busy Off, Ack On (for signal time), Ack Off
1 = Ack On (for signal time), Busy On, Ack Off, Busy Off
2 = Busy On (for 5ms), Ack On (for signal time), Busy Off, Ack Off
3 = Ack On (for signal time), Ack Off, Busy On (for 5ms), Busy Off
4 = Busy On and Ack On (for signal time), Ack Off and Busy Off
Default is 0

Any idea how the M100 handshakes?

Will


On 3/17/24 7:18 AM, Mike Stein wrote:
Is it consistent, i.e. do you always get the same garbled output for a 
given file?


At a fast glance it looks like bits 2 and/or 3 are being dropped; have 
you checked the computer to Pi cable and connectors?


m

On Sun, Mar 17, 2024 at 2:14 AM Will Senn  wrote:

I am finally coming back around to this. I bought a retroprinter a
year and half ago or so and shelved it out of frustration. Now, I
know a lot more about this sorta stuff and so I pulled it out,
updated the software to latest and tried to get it working.

The PI prints a test page fine, but it won't print anything I send
it from the M100. After hours of troubleshooting, it appears that
whatever codes the pi is sending aren't DMP-15, EPSON ESC/P or
Plain Text codes... When I do llist, I see the data coming across
to the retroprinter and have set up a file to capture, but I can't
find anything that will make sense of the data.

Here's a sample:

10 PRMN\ "lmllo"
1= RMS\ORM =0>NORM=0\O1>RMALR,M-,Q,,M-,C,,M,0-,C,,M,1->CL,M-=0>NM\\M
20 M=0
2= O=0>OOS]B<0
30 OOS]B<=

It looks like reasonably valid data and not complete gibberish,
but who am I to judge. Is it one of:

Epson ESC/P 9 Pin - didn't work, when I tried it
Epson ESC/P 24/48 Pin
HP Printer (PCL3 or PCL5)
HP Plotter (HP-GL)
IBM ProPrinter
Plain Text- didn't work, when I tried it
Postscript
Printronix-P Series
Printronix-S Series
Seiko QT-2100P
Siemens PT-88
Apple Image Writer II
Seiko STP
Star Micronics SP700
Tandy DMP-105- didn't work, when I tried it

Help and thank you.



Re: [M100] retroprinter and the m100

2024-03-17 Thread Mike Stein
Is it consistent, i.e. do you always get the same garbled output for a
given file?

At a fast glance it looks like bits 2 and/or 3 are being dropped; have you
checked the computer to Pi cable and connectors?

m

On Sun, Mar 17, 2024 at 2:14 AM Will Senn  wrote:

> I am finally coming back around to this. I bought a retroprinter a year
> and half ago or so and shelved it out of frustration. Now, I know a lot
> more about this sorta stuff and so I pulled it out, updated the software to
> latest and tried to get it working.
>
> The PI prints a test page fine, but it won't print anything I send it from
> the M100. After hours of troubleshooting, it appears that whatever codes
> the pi is sending aren't DMP-15, EPSON ESC/P or Plain Text codes... When I
> do llist, I see the data coming across to the retroprinter and have set up
> a file to capture, but I can't find anything that will make sense of the
> data.
>
> Here's a sample:
>
> 10 PRMN\ "lmllo"
> 1= RMS\ORM =0>NORM=0\O1>RMALR,M-,Q,,M-,C,,M,0-,C,,M,1->CL,M-=0>NM\\M
> 20 M=0
> 2= O=0>OOS]B<0
> 30 OOS]B<=
>
> It looks like reasonably valid data and not complete gibberish, but who am
> I to judge. Is it one of:
>
> Epson ESC/P 9 Pin - didn't work, when I tried it
> Epson ESC/P 24/48 Pin
> HP Printer (PCL3 or PCL5)
> HP Plotter (HP-GL)
> IBM ProPrinter
> Plain Text - didn't work, when I tried it
> Postscript
> Printronix-P Series
> Printronix-S Series
> Seiko QT-2100P
> Siemens PT-88
> Apple Image Writer II
> Seiko STP
> Star Micronics SP700
> Tandy DMP-105 - didn't work, when I tried it
>
> Help and thank you.
>
>