Who Else Would Like to See an Open Source Printer Emulator for the Atari?

[UNIXcoffee928]

This would be a visual printer emulator that would be run simultaneously with your Atari emulator, perhaps on a secondary display.

 

I know that a closed-source piece of software exists, but I'd like to see something that could be tweaked & expanded to suit the needs of the user. Software that could fully emulate Epson dot matrix printers, and have add-on extensions for each model, as well as have the ability to add & select other manufacturers & models (Panasonic, Star, etc.).

 

It would be cool if it could provide instantaneous or sequential output, at a variety of carriage-widths, could work with font & dumping programs, word processors, Print Shop, Newsroom, etc. It would be really nice to have the ability to save the output to a .pdf & print it on a modern printer.

 

What other features can you think of that should be in such a program?

[+mytek]

This would be a visual printer emulator that would be run simultaneously with your Atari emulator, perhaps on a secondary display.

 

I know that a closed-source piece of software exists, but I'd like to see something that could be tweaked & expanded to suit the needs of the user. Software that could fully emulate Epson dot matrix printers, and have add-on extensions for each model, as well as have the ability to add & select other manufacturers & models (Panasonic, Star, etc.).

 

It would be cool if it could provide instantaneous or sequential output, at a variety of carriage-widths, could work with font & dumping programs, word processors, Print Shop, Newsroom, etc. It would be really nice to have the ability to save the output to a .pdf & print it on a modern printer.

 

What other features can you think of that should be in such a program?

 

Yesterday I was thinking how cool it would be to have something that could do a print screen directly from real hardware via SIO2PC-USB. And when I say print screen, I really mean true screen capture to either an image, pdf, or actual printer on the PC that would look exactly like what was on the Atari's screen. I know this can be done through emulation, but there are times when only real hardware will work (emulation hasn't yet caught up with new upgrade, ect.).

 

I know this is a bit different than what you are talking about, but perhaps the two ideas can be combined?

 

- Michael

[Madi]

Than you UNIXcoffee928 for bringing such important subject.

Sure, this is one of the really needed features that Atari emulators still do not have.

 

 

Yesterday I was thinking how cool it would be to have something that could do a print screen directly from real hardware via SIO2PC-USB. ...

 

- Michael

@ Michael, did you have a look at this project:
Software/hardware (Raspberry Pi) to provide an easy to use printer interface to allow connecting vintage computers and equipment to any modern printer such as a USB or network printer.

 

madi

 

Edited July 10, 2016 by Madi

[UNIXcoffee928]

Thank you UNIXcoffee928 for bringing up such an important subject.

Sure, this is one of the really needed features that Atari emulators still do not have...

 

You're welcome; I had thought about this several years ago, and recently thought about it again, so I decided that I'd bring it up as a topic, so that others could offer their input on what features a program like this should have.

 

I think that the best way to go about doing it would be to first write a printer driver for a virtual printer. This way, it will work with emulators right away, without having to ask authors to make any changes to any Atari emulators. All you would do is select, say, "emuprinter" from the Atari emulator print dialog box, and the "printed" output of the Atari emulator would go straight to the driver, which, in turn would pass the data to the running printer emulator software application, which could be windowed on the same screen, or, preferably, would occupy a windowed or full-screen secondary display.

 

This application would display, graphically, what would normally appear on the printed page. It could be selectable to put the info on the screen sequentially, like a terminal, or all at once. If it was displayed all at once, interesting things could be done, that couldn't normally be done on a printer... meaning, it would be like having a new display device that operates with ESC codes.

 

I can visualize the layout, having drop-down menus that would allow you to select the make and model of printer that you would like to virtually represent. I think that the ability to load a printer-definition datafile (that can be user-created) is an important part of the program, that way anyone can add to it.

 

It really depends on how you want to look at the type of emulation, though. To truly emulate the actual printers would require a lot of work, including ROM dumps, and emulators of the architecture of the hardware on every printer, and that is simply too much work, and is way beyond anything that I, personally, would attempt. Maybe ROM dumps of the actual character sets, but even that opens up questions of "legal ROM usage", and such. So, I'm thinking at a more Top-Down reverse-engineering would be the way to go. It will get very tricky when it comes to implementing the graphics capabilities of the printers. I am of the opinion that a 9 pin and 24 pin "hypothetical printer" model should be used, and be modified by the datafile, in a subtractive way, to describe the individual printer models. I'm interested in tschak909 Thom's opinion, regarding the details of this post.

 

I also think that it would be very cool to have a whole separate mode of operation that functioned as a virtual Atari 1020 Plotter. This might be the easiest option to implement, initially.

 

I'm also thinking that to start out, as a separate mode of operation, something that translated Epson ESC codes into HTML equivalents would be a neat way to build the skeleton of the program, and ensure the functionality of the virtual printer driver with the emulated printer software application. I'm not sure if it eventually should use TrueType fonts as an option or if everything should be built on a dot by dot basis, (I'm leaning toward dot by dot matrices, and a Top-Down, Hypothetical Super-Dot Matrix Virtual Printer modeling scheme, that is subtracted from to achieve each model).

 

I'm still kind of figuring out the design requirements for the whole thing, & I'm not entirely sure if I, personally, want to commit to this program... it depends on it's complexity, and how long it will take to write it... but I am very interested in spec-ing it out, so that it can be implemented... so for anyone who is reading this, please be sure to share what you would like to see in such a program, and how you think that it should be done. Thanks.

[+mytek]

Than you UNIXcoffee928 for bringing such important subject.

Sure, this is one of the really needed features that Atari emulators still do not have.

 

@ Michael, did you have a look at this project:

Software/hardware (Raspberry Pi) to provide an easy to use printer interface to allow connecting vintage computers and equipment to any modern printer such as a USB or network printer.

 

madi

 

Retro Printer.jpg Retro Printer1.jpg

 

Madi I wasn't aware of that board (thanks). But it probably won't do what I'd really like to see, which is an image capture of the screen on real Atari hardware. So this would be just like what you get by hitting the 'Print Screen' button on a PC, where a bit mapped image (bmp, jpg, png) is generated. The project you linked to looks to be more aimed at translating Centronix (parallel) style printer output to something that can be piped through USB. So with that device you could connect the printer output from an 850, BB, MIO, ect. to a USB printer or capture the 'print' file to the connected PC. And then assuming you ran a suitable software driver on the Atari, it could be possible to capture the screen image including all the special graphics characters and convert that to something a printer would understand. So in a sense that would work, but not quite like what I had in mind.

 

So instead what I am after, is a piece of software on the Atari 8-bit side (client) and the PC side (server, aka RespeQt) that can utilize an existing SIO2PC-USB device and with a simple press of a key on the client send the screen capture to the server rendering an image file of the capture. And if that software pair could also recognize the 'Print Screen' key (key code: 0x36) from Transkey so much the better. So no need to buy yet another hardware device, other than what most Atari enthusiasts already own for doing file transfers.

 

Anyway I think this is getting off-topic from what the OP had in mind, so perhaps can be taken up in a separate topic.

 

- Michael

[Joey Z]

 

Madi I wasn't aware of that board (thanks). But it probably won't do what I'd really like to see, which is an image capture of the screen on real Atari hardware. So this would be just like what you get by hitting the 'Print Screen' button on a PC, where a bit mapped image (bmp, jpg, png) is generated. The project you linked to looks to be more aimed at translating Centronix (parallel) style printer output to something that can be piped through USB. So with that device you could connect the printer output from an 850, BB, MIO, ect. to a USB printer or capture the 'print' file to the connected PC. And then assuming you ran a suitable software driver on the Atari, it could be possible to capture the screen image including all the special graphics characters and convert that to something a printer would understand. So in a sense that would work, but not quite like what I had in mind.

 

So instead what I am after, is a piece of software on the Atari 8-bit side (client) and the PC side (server, aka RespeQt) that can utilize an existing SIO2PC-USB device and with a simple press of a key on the client send the screen capture to the server rendering an image file of the capture. And if that software pair could also recognize the 'Print Screen' key (key code: 0x36) from Transkey so much the better. So no need to buy yet another hardware device, other than what most Atari enthusiasts already own for doing file transfers.

 

Anyway I think this is getting off-topic from what the OP had in mind, so perhaps can be taken up in a separate topic.

 

- Michael

This sounds like all you need to do is write some sort of TSR that runs on the atari (or perhaps an OS mod, if you need it to work without DOS) which installs itself in the KB handler, and looks for a certain key combination which tells it to do a screen capture and print it. From there, it would just process the display list and send some sort of formatted output to a P: device.

[evilmoo]

I found some DOSBox patches for emulating the ESC P2 codes for an Epson. It probably wouldn't be too hard to tie that into an emulator somehow.

[HiassofT]

This sounds like all you need to do is write some sort of TSR that runs on the atari (or perhaps an OS mod, if you need it to work without DOS) which installs itself in the KB handler, and looks for a certain key combination which tells it to do a screen capture and print it. From there, it would just process the display list and send some sort of formatted output to a P: device.

I did this back in the 1980ies but IIRC it was very basic (only a few display modes supported) - can't quite remember the details.

 

On the Atari it's extremely tricky to do produce a screen dump in software. You have multiple screen modes, PM overlays/underlays etc. Once you add in DLIs (even if it's only for color changes) you end up writing a full emulator...

 

so long,

 

Hias

[flashjazzcat]

I'm sure Claus or someone also wrote something like this and it was posted on the forum a few years back.

[+David_P]

There was such a beast published in ANTIC some time, that only did Gr0 screens. I did up an OS version that integrated the screen dump (I think I had to sacrifice the international charset to do so).

 

Once I set up a disk drive I will see if I can find the source disk I used.

[GoodByteXL]

This is something I suggested many times during the last 15 years. A simple receiver for the data send to P: (PRN:) who is capable to display it as a bitmap if it is graphical output e.g. from Print Shop or alike. There are quite some programs producing graphical printouts that would be nice to see on pc, mac, etc. Currently the potential of such programs is a loss as it is not visible what they are capable of.

 

Preferrably an add-on for RespeQt would be fine.

 

Screen dumps can be done using e.g. Altirra, so there is no need to invest in it, in my view.

[danwinslow]

It's a good idea. I would imagine it's something that Avery could put into Altirra rather quickly, were he so inclined.

[Mathy]

Hello guys

 

I once used a Canon Bubblejet printer. It simulated an EPSON compatible printer. Unfortunately it did so by turning what would have been a round dot on a 9 needle printer into a small square. It toke all the fun out of using DaisyDot III.

 

So if this idea turns into reality, please make sure that round dots stay round dots. Or at least put in an option that will keep the round dots round instead of square.

 

Sincerely

 

Mathy

Edited July 11, 2016 by Mathy

[+mytek]

There was such a beast published in ANTIC some time, that only did Gr0 screens. I did up an OS version that integrated the screen dump (I think I had to sacrifice the international charset to do so).

 

Once I set up a disk drive I will see if I can find the source disk I used.

 

Actually that sounds like what I need. And yes I would be very interested in the patched OS version, especially if TK-II's Print Screen key could be used to trigger it (code: 0x36, same as used on the original 1990 Transkey).

 

- Michael

[bbking67]

You'd want the emulation to cover all Atari printers (including the plotter, 825, XMM801/SMM804, 1090, etc.) of course, plus at minimum the popular Epson printers: MX-80, FX-80, FX-85. Many other printers had Epson emulation as well I guess... but whatever the popular printers that are supported by common Atari programs would be nice. Some popular 24-pin printers would be nice for the extra resolution, I just don't know the model names.

 

My Atari 8-bit era was strictly 9-pin printers--I had a Star NX10 (pretty much a cheapified Epson clone).

 

Did any Atari programs directly support the deskjet printers and such? Or were these using Epson FX emulation as well?

[+mytek]

 

Actually that sounds like what I need. And yes I would be very interested in the patched OS version, especially if TK-II's Print Screen key could be used to trigger it (code: 0x36, same as used on the original 1990 Transkey).

 

- Michael

 

Actually I need to correct myself and could no longer edit that post. The actual code seen when pressing the Print Screen key on the PS/2 keyboard connected to either Transkey 1 or Transkey 2 (TK-II) installed in an A8 would be decimal 36 (or in hex: 0x24). So in other words when doing a peek(764) you would see 36 appear when that key was pressed. I just forgot to switch my brain from hex to decimal.

 

- Michael

[JD6502]

By coincidence I've been wondering about printer support in A8 emulators myself lately. It seemed odd that there was this big hole in the emulator world where a lot of popular (at the time) software whose primary output is to the printer is effectively useless on an emulator. I spent ( or wasted) a lot of time creating fonts with daisy dot, and thought it might be fun to see them re-created on a PC. I assumed that there weren't many other people who thought so, otherwise there would've been more done in that area. My thinking was... after all, a dot matrix page is just a bunch of black dots on a white background, how hard can that be? A driver to translate control codes for the more common printers, then put a bunch of dots on the screen with the right spacing, and an option to save it as a bmp or jpeg. But I'm not much of a programmer. My skills (such as they are) are limited to basic and I have no idea how to create a modern bit map file. It sounds like it might be more complicated than I thought, though.

[kogden]

SIO2OSX supports Atari 825, 1020 plotter and Epson FX-80 emulation over an SIO2PC interface if you have a Mac. The 850 emulation is slick too. It's far cheaper than APE ($25) but having source available would be nice. An open-source printer emulator would be great! Would be awesome for RespeQT to have something like this integrated.

 

I haven't seen much development activity with SIO2OSX lately. An open-source project where multiple people could chip in would be awesome.

 

How tied is RespeQT to QT? Does it just use it for the UI layer or many other functions as well? I've been hesitant to dive in. I already have my brain stuffed with too many weird GUI toolkits and QT seems to expand beyond just the UI. And native QT on OSX seems to suck compared to the X11 version.

[Joey Z]

SIO2OSX supports Atari 825, 1020 plotter and Epson FX-80 emulation over an SIO2PC interface if you have a Mac. The 850 emulation is slick too. It's far cheaper than APE ($25) but having source available would be nice. An open-source printer emulator would be great! Would be awesome for RespeQT to have something like this integrated.

 

I haven't seen much development activity with SIO2OSX lately. An open-source project where multiple people could chip in would be awesome.

 

How tied is RespeQT to QT? Does it just use it for the UI layer or many other functions as well? I've been hesitant to dive in. I already have my brain stuffed with too many weird GUI toolkits and QT seems to expand beyond just the UI. And native QT on OSX seems to suck compared to the X11 version.

Qt is pretty in-grained in RespeQt. It does use more than just the UI features. Qt is also the reason RespeQt ports so 'easily' to other platforms, otherwise you'd have to get a more advanced layer of POSIX compatibility on platforms like windows, not to mention possibly an X server.

[kogden]

Qt is pretty in-grained in RespeQt. It does use more than just the UI features. Qt is also the reason RespeQt ports so 'easily' to other platforms, otherwise you'd have to get a more advanced layer of POSIX compatibility on platforms like windows, not to mention possibly an X server.

 

I can see why it's done. I was just hoping it was only used for UI code. For similar portability reasons I've done cross-platform GUI stuff with Tcl/tk and then used native C libraries for performance when needed. You wouldn't necessarily have to have better POSIX layer and X11 for Win32. You would just have to write routines for both platforms when necessary (like twiddling DTR on a serial port) and make use of #ifdef's. For a one-man project this isn't much fun however.

 

As far as printer emulation goes, SIO2OSX and Atari800MacX share the same printer emulation engine. SIO2OSX is shareware, but Atari800MacX is open-source (based on GPL'd Atari800 SDL emulator). The printer emulation code is a little Mac-centric in ways but could probably still be pretty useful for anyone embarking on such a project. Especially the 1020 plotter emulation.

[+DrVenkman]

Sounds like there's a real OS X coder in the house ... GREAT! I ended up as the de facto "OS X app builder" for RespeQt when I was fiddling with AspeQt trying to get CPU usage from spiking and SIO timeouts to interrupt things with my Mac. With a lot of trial and error, suggestions from Hias and others who know better than I ever will, and a lot of luck, I created a version that was reliable and stopped spiking my CPU. Since then others have picked up the ball and run with it, especially on the Windows and Linux side, for which I'm grateful but RespeQt *REALLY* needs a real OS X coder, especially since my Mac is currently on the fritz. You and Joey Z. should discuss it in the RespeQt forum.

[JoSch]

Sounds like there's a real OS X coder in the house ... GREAT! I ended up as the de facto "OS X app builder" for RespeQt when I was fiddling with AspeQt trying to get CPU usage from spiking and SIO timeouts to interrupt things with my Mac. With a lot of trial and error, suggestions from Hias and others who know better than I ever will, and a lot of luck, I created a version that was reliable and stopped spiking my CPU. Since then others have picked up the ball and run with it, especially on the Windows and Linux side, for which I'm grateful but RespeQt *REALLY* needs a real OS X coder, especially since my Mac is currently on the fritz. You and Joey Z. should discuss it in the RespeQt forum.

Do you have built instructions? I was not successful in compiling RespeQT with the latest QT 5 toolkit.

BTW, why is the Mac version ignoring PCLINK commands?

Edited July 20, 2016 by JoSch

[+DrVenkman]

Do you have built instructions? I was not successful in compiling RespeQT with the latest QT 5 toolkit.

BTW, why is the Mac version ignoring PCLINK commands?

I had no trouble compiling the last time I did so (a couple months back). I do have build instructions. I will post them tonight. As for the PCLINK stuff, I don't know. I don't use that functionality. I'd have to download the newest development branch code and compile again.

[JoSch]

I think, you already did. The PCLINK feature should be in R3. The OSX version, I downloaded from the Github page (your build, I think), clearly states, that it ignores the PCLINK commands.

This indicates, that RespeQt R3 knows of PCLINK.

[kogden]

Sounds like there's a real OS X coder in the house ... GREAT! I ended up as the de facto "OS X app builder" for RespeQt when I was fiddling with AspeQt trying to get CPU usage from spiking and SIO timeouts to interrupt things with my Mac. With a lot of trial and error, suggestions from Hias and others who know better than I ever will, and a lot of luck, I created a version that was reliable and stopped spiking my CPU. Since then others have picked up the ball and run with it, especially on the Windows and Linux side, for which I'm grateful but RespeQt *REALLY* needs a real OS X coder, especially since my Mac is currently on the fritz. You and Joey Z. should discuss it in the RespeQt forum.

 

I don't know about "real OSX coder", I've done more on the UNIX side of things but I have yet to pick up Objective C and do any truly native OSX stuff. I did a little bit with Think C on my old 68k Mac way back in the day but I don't think that counts. I've certainly never done any Qt/C++ work. As far as kicking things to get them to behave and/or compile on the Mac I've had success though and I'm quite familiar with the BSD/Mach environment under the hood. I can get around in XCode, make use TCL/tk and Applescript but I don't know if I'd call myself a seasoned Mac developer.