www.retrosoftware.co.uk
http://www.retrosoftware.co.uk/forum/

Printer Emulation
http://www.retrosoftware.co.uk/forum/viewtopic.php?f=20&t=176		 Page 1 of 2
Author:  ParasS [ Tue Aug 26, 2008 11:25 am ]
Post subject:  Printer Emulation
Whilst sewing up the editor stuff for Repton: The Lost Realms I've realised I've no way of seeing the printer output that the built-in screendump routines for Epson FX80 and compatibles produce.

I dropped a note to Mike of BeebEm and he had a link that someone had sent him about doing something similar... this would be a great thing for someone to take on (I'm no PC coder, or indeed, Beeb coder any more!)
Author:  ThomasHarte [ Tue Aug 26, 2008 3:59 pm ]
Post subject:  Re: Printer Emulation
ElectrEm has always had some FX80 emulation (well, since about 2001 anyway), but really just the basic typographic control codes — never pixel graphics. I'll have a quick look into it and see if I can get anything going and if so, I'll sever the code so that it's suitable for other emulators. I'm not sure the code is terribly well written (it might be using a whole load of explicit state variables rather than just letting your OS's multitasking abilities handle everything ala most of the rest of the emulator), but I'm sure I can pick it up again relatively quickly.

I'm not really able to do a search right now, presumably it's trivial to find a disk at 8BS or elsewhere that'll do some graphics printing? If not, does anybody have anything they can throw my way?

If Repton has Electron support then I could send whatever I achieve over to you for testing, otherwise I guess you'll have to hope that it gets into BeebEm sooner rather than later...
Author:  ParasS [ Tue Aug 26, 2008 4:07 pm ]
Post subject:  Re: Printer Emulation
That's wonderful if you could look at it Thomas... I would have thought PrintMaster or Dumpout ROMs would be Elk compatible actually (sorry, not used ElectrEm - does it support ROMs/Plus1 carts?)... but failing that I do have a Colour Dump ROM that I coded up with the intention of through Watford Electronics, though they just made my evaluation copy disappear when I used to work for them, so we left it at that.

The CDR does support mono FX80 compatibles plus Star LC10 colour and possibly Citizen Swift and Integrex Colourjet 132 (I certainly remember writing dump routines for the latter two!).

I've just Googled "FX80 Emulation" and a lot of interesting stuff comes up, e.g. full graphics support as part of TRS80 and Apple ][ emulators, so you may just be able to lift code from elsewhere...
Author:  ThomasHarte [ Mon Sep 01, 2008 12:53 am ]
Post subject:  Re: Printer Emulation
Update on this: the ElectrEm code is quite simple and relatively easy to get back into. It shouldn't be hard to sever. Graphics emulation is not very difficult to add in terms of interpreting what is coming from the computer, as I'm sure you appreciate from writing data out.

The only snag is that the code currently outputs formatted text to RTF files and nobody seems to agree on how to embed graphics into an RTF. If I can find a method that all the tools will open then I can hopefully fix up my code and submit it for BeebEm relatively quickly.

If not then I'll need to find an alternative file format. One of the pure graphics formats (PNG or whatever) would be tempting but I'd need bitmap copies of all the character glyphs from an actual FX-80, rather than just leaving whatever loads the RTF to do what it can with Courier, etc.

So, an appeal if anyone is reading this: does anyone have a functioning FX-80 and a high resolution scanner? Or a dumped copy of an original FX-80 character ROM (yeah, I know, really unlikely).

Annoyingly, every other emulator I can find that has any sort of FX-80 support is shareware and includes the emulation in registered versions only. I'll contact the relevant authors, but I'll wager that their solutions are not things they feel like giving out for free.
Author:  ThomasHarte [ Mon Sep 01, 2008 1:17 am ]
Post subject:  Re: Printer Emulation
Actually, that all being said, I've found the character matrices for the Epson FX typeface in Volume 2 of the user guide. So it'll be quite a bit of work transferring them by sight to a usable binary format, but completely possible.

I'll continue what I was doing...
Author:  ParasS [ Mon Sep 01, 2008 11:52 am ]
Post subject:  Re: Printer Emulation
Good stuff Thomas. The only thing I'd suggest though is that you could probably get away with something like that from elsewhere as a stopgap and concentrate on the graphic data output. Since the character set would have been different between printers from different brands supporting Epson emulation anyway (and some having an NLQ feature that would be controlled via front panel rather than ESC codes, thereby forcing 'high quality' printouts even if your driver or emulation didn't support it).
Author:  ThomasHarte [ Mon Sep 01, 2008 11:30 pm ]
Post subject:  Re: Printer Emulation
A placeholder might have been a good idea, but I've managed to enter the first 128 glyphs in the last hour or so. The final 128 are just the first 128 adjusted a bit to look italic. So I can just ignore that for the time being and move on.

I'm dithering now on file formats; probably PDF would be a better choice than PNG since I could just export the glyphs I have to a TTF font (not too hard when there's no pair kerning), then encode text sections as genuine text and benefit from reduced file sizes and allow the end-user to cut and paste. That's a back burner for now though, as I'm sure figuring out the PDF file format will add days or weeks to the whole endeavour.

Anyway, I don't want to bore you with little updates all the time, so I'll come back when I've got something visible to show.
Author:  ThomasHarte [ Wed Sep 03, 2008 12:48 am ]
Post subject:  Re: Printer Emulation
Well, I'm not sure it's that close yet, but here are the first couple of shots:
Attachment:
File comment: A graphic. The run of à characters at the bottom suggests that I'm missing an escape code somehow.
Scr2.png [28.97 KiB]
Downloaded 233 times

Attachment:
File comment: Some text; note that typographic escape codes aren't working yet, and the print head isn't automatically wrapping from the right to the left (should it?)
Scr1.png [21.99 KiB]
Downloaded 234 times

Still lots to do, lots to do.

Relevant question: I've managed to dig up a PDF of the manual for the Star LC200, which implements colour using the escape code <ESC> "r" n, where n is 0 for black, 1 for magenta, 2 for cyan, 3 for violet, 4 for yellow, 5 for orange or 6 for green. Was that (and indeed was there) any sort of de facto standard for colour extensions to the FX-80 command set?

EDIT: Oh, yuck, now I'm at work I can see how these are displaying in IE7. It looks like it has a horrid image scaling algorithm. If anyone is using that browser (or, probably, other IEs), please view the attachments in a better piece of software before making any snap judgments!
Author:  ParasS [ Wed Sep 03, 2008 9:36 am ]
Post subject:  Re: Printer Emulation
Whoa! You've really gone Supersize on the printer support! :D LOL - good stuff mate!

From memory "standards" were a bit hit-and-miss... the only colour dot-matrix printers I remember being popular were Star's LC10 and later models, and the Citizen Swift series. I'm not sure that they both dealt with colour the same way...

...even the basic FX80 command set was simply something that most printers sought to emulate simply because Epson printers were abundant and most software supported them.

On the wrapping front, you mean will it go to the next line by default if it reaches the end of the carriage? Yes.
Author:  ThomasHarte [ Wed Sep 03, 2008 12:26 pm ]
Post subject:  Re: Printer Emulation
To be honest, I can't think of a way to get close to semi-accurate without being really very accurate. You've got dots of a certain radius being plotted at sometimes recurring decimals of that radius from each other, and a whole bunch of the text formatting options revolve around double printing the dots with a very slight offset or otherwise adjusting the dpi. So unless and until I can throw a device independent format like PDF at the problem, drawing the buffer large with actual visible imprint dots and then optionally downsampling is the only meaningful solution. Anyway, I'm a tedious stickler for getting things as close to right as possible in my emulator — discs are decoded from DSD/SSD/ADF/whatever to actual magnetic pulses and then re-interpretted from there by the floppy controller. That's one of the reasons that ElectrEm was one of the first emulators able to support FDI.

To be honest, this auto line feed/carriage return stuff still has me a bit confused. The EUG printout program sets 80 dpi mode (to get exactly 640 graphics dots on a line), sends 640 pixels, then a line feed, then another 640 dots, then another line feed, etc. It doesn't seem to do an explicit carriage return, and I guess an implicit carriage return / line feed would just end up producing two line feeds between every block of pixel data. I hope I'm just accidentally dropping an explicit carriage return or something.

Anyway, I'll get in contact with Mike and see what requirements the code would need to fulfill to be acceptable for BeebEm. Thanks for inadvertently pointing me towards an interesting project!
Author:  ParasS [ Wed Sep 03, 2008 1:13 pm ]
Post subject:  Re: Printer Emulation
ThomasHarte wrote:
...drawing the buffer large with actual visible imprint dots and then optionally downsampling is the only meaningful solution... ... It doesn't seem to do an explicit carriage return... ...Thanks for inadvertently pointing me towards an interesting project!

Oh I hope you haven't misunderstood my comment - I think it's great that you've done it this way and I agree that losing detail optionally afterwards is better than approximating in the first place.

I misunderstood your original point on the automatic CR/LF - I assumed you were talking about text, but yes on graphics I believe the printers would just consume the data beyond the end of the line and ignore it.

I'm amazed you've got so far and thanks are due to YOU for solving the problem!!! Anyone can create a problem - only a few can solve them!!! :D
Author:  DaveJ [ Wed Sep 03, 2008 1:58 pm ]
Post subject:  Re: Printer Emulation
This is truly fantastic, and something I always wanted but never expected to see done.
Author:  ThomasHarte [ Wed Sep 03, 2008 2:51 pm ]
Post subject:  Re: Printer Emulation
It's not exactly done yet, there's probably a few weeks of extra things I need to add in - typographic control codes, colours (I guess the ribbon is CMYK and selecting some of the other colours just causes the printer to do the overprinting for you?), half the built-in font, international font mapping, proper print head control - and other things I need to change (make it independent of SDL mainly) if I want it to be usable by other emulators. And probably no-one's going to want incomplete code, so I expect I'll need to do most of that to completion before it actually gets near a BBC emulator codebase.

ParaS - if that part of your code is Electron compatible then I can forward a WIP build of the emulator sufficient for you to test your code, probably quite soon. Or if there's a BBC emulator that can just record the byte output verbatim then I could try to hack together a standalone version for now. Or just write a quick BASIC program and have ElectrEm's "load BASIC from ASCII" tokeniser handle the tedious bit of entering it into the actual machine.
Author:  ParasS [ Thu Sep 04, 2008 10:50 am ]
Post subject:  Re: Printer Emulation
Here's a MODE2 Star LC10C dump routine... does that help you?

Code:
   10REM STAR LC10 COLOUR PRINTER
   20REM LARGE SCREENDUMP FOR GRAPHICS
   30REM (c) 1989 Paras Sidapara
   40:
   50DIMcode%3000
   60mode=&355
   70pixbyte=&361
   80cols=&360
   90palette=&36F
  100rowbytes=&352
  110ramsize=&354
  120charsleft=&70
  130screenstart=&350
  140address=&71
  150curcol=&73
  160curpix=&74
  170totchars=&75
  180linesleft=&76
  190byte=&77
  200curbit=&78
  210tempad=&79
  220temp=&7B
  230FORP=0TO2STEP2
  240rowbytes=&90:!&90=640
  250P%=code%
  260[OPTP
  270.out BRK:EQUB255
  280EQUS"Can't dump this mode":BRK
  290.esc LDA#3:JSR&FFEE
  300BRK:EQUB17:EQUS"Escape":BRK
  310.bigdump
  320LDXmode
  330LDAgetbytehi,X:BEQout:STAjump+2
  340LDAgetbytelo,X:STAjump+1
  350LDAscreenstart:STAaddress
  360LDAscreenstart+1:STAaddress+1
  370LDArowbytes+1:STAtemp
  380LDArowbytes
  390LSRtemp:RORA
  400LSRtemp:RORA
  410LSRtemp:RORA
  420STAtotchars
  430LDA#32:STAlinesleft
  440LDA#2:JSR&FFEE
  450LDA#64:JSRcode
  460LDA#65:JSRcode
  470LDA#8:JSRsend
  480.newline
  490LDA#10:JSRsend
  500LDA#3:STAcurcol
  510.colourloop
  520LDAaddress:STAtempad
  530LDAaddress+1:STAtempad+1
  540LDA&FF:BMIesc
  550LDA#114:JSRcode
  560LDXcurcol:LDAcolbyte,X:JSRsend
  570LDA#13:JSRsend
  580LDA#42:JSRcode
  590LDA#4:JSRsend
  600LDA#128:JSRsend
  610LDA#2:JSRsend
  620LDAtotchars:STAcharsleft
  630.charsloop
  640LDY#7
  650.xfer
  660LDA(tempad),Y:STAtemp,Y
  670DEY:BPLxfer
  680LDApixbyte:STAcurpix
  690.pixloop
  700LDA#7:STAcurbit
  710.bitloop
  720LDYcurbit:LDAtemp,Y:LDX#0
  730.jump JSR&FFFF
  740TXA:PHA
  750LDAcurcol
  760ASLA:ASLA
  770TAX
  780LDYcurbit:LDAtemp,Y
  790ASLA:STAtemp,Y
  800PLA:TAY
  810LDApalette,Y
  820AND#7
  830CMPdottab,X:BEQrotate
  840CMPdottab+1,X:BEQrotate
  850CMPdottab+2,X:BEQrotate
  860CLC
  870.rotate
  880RORbyte
  890DECcurbit
  900BPLbitloop
  910LDXmode
  920LDAbytes,X:TAX
  930LDAbyte
  940.byteloop
  950JSRsend
  960DEX:BNEbyteloop
  970DECcurpix:BPLpixloop
  980LDAtempad:CLC:ADC#8:STAtempad
  990BCCnoinc:INCtempad+1:BPLnoinc
 1000LDAtempad+1:SEC:SBCramsize
 1010STAtempad+1:.noinc
 1020DECcharsleft:BNEcharsloop
 1030DECcurcol
 1040BMInextline
 1050JMPcolourloop
 1060.nextline
 1070LDAtempad:STAaddress
 1080LDAtempad+1:STAaddress+1
 1090DEClinesleft
 1100BEQfinish
 1110JMPnewline
 1120.finish
 1130LDA#3:JMP&FFEE
 1140.getbytelo
 1150EQUB two MOD256
 1160EQUB four MOD256
 1170EQUB sixteen MOD256
 1180BRK
 1190EQUB two MOD256
 1200EQUB four MOD256
 1210BRK
 1220BRK
 1230.getbytehi
 1240EQUB two DIV256
 1250EQUB four DIV256
 1260EQUB sixteen DIV256
 1270BRK
 1280EQUB two DIV256
 1290EQUB four DIV256
 1300BRK
 1310BRK
 1320.code PHA:LDA#27:JSRsend:PLA
 1330.send PHA:LDA#1:JSR&FFEE:PLA
 1340JMP&FFEE
 1350.colbyte EQUD&4020100
 1360.dottab EQUD0
 1370EQUD&10504
 1380EQUD&40602
 1390EQUD&10302
 1400.bytes
 1410EQUB1
 1420EQUB2
 1430EQUB4
 1440BRK
 1450EQUB2
 1460EQUB4
 1470.two
 1480AND#&80
 1490BEQrts
 1500LDX#1
 1510.rts RTS
 1520.four
 1530AND#&88
 1540BEQrts
 1550INX:CMP#&08:BEQrts
 1560INX:CMP#&80:BEQrts
 1570INX:RTS
 1580.sixteen
 1590AND#&2A
 1600.checkloop
 1610CMPcolours,X
 1620BEQrts
 1630INX:CPX#16:BNEcheckloop
 1640RTS
 1650.colours
 1660]NEXT
 1670P%=P%+8
 1680FORB%=0TO7
 1690B%?colours=2*(B%AND1)+4*(B%AND2)+8*(B%AND4)
 1700NEXT
 1710MODE2
 1720*L.S
 1730CALLbigdump


Line 1720 obviously looks to load in an image into the screen buffer
Author:  ThomasHarte [ Sat Sep 06, 2008 12:49 pm ]
Post subject:  Re: Printer Emulation
Quote:
Here's a MODE2 Star LC10C dump routine... does that help you?

Yep.
Attachment:
File comment: A Mandelbrot fractal, as displayed in BASIC via the emulator.
Original.png [11.11 KiB]
Downloaded 275 times

Attachment:
File comment: A Mandelbrot fractal, as printed by ParaS's Mode 2 printing routine against my FX-80/Star LC10 emulator (720 dpi original: http://members.allegro.cc/ThomasHarte/temp/Printout.png).
Printout (thin).png [187.97 KiB]
Downloaded 258 times


That worked first time against my colour emulation code, I didn't have to adjust my code to your program (as if I'd misread the FX-80 spec or whatever) at all. So I'd be reasonably optimistic in saying that if this is the code in Repton then it works.

I've got a bunch of stuff to do with paper sizes, tab stops, reverse line feeds and correct typographic priorities to fix, but am optimistic that I'll have something clean enough to pass to authors of more mainstream emulators soon enough.

A couple more:
Attachment:
File comment: Page 1 of an MX-80 (direct predecessor of the FX-80 that supports a subset of the same typographic controls) typographic demo (720 dpi original: http://members.allegro.cc/ThomasHarte/temp/TextStylesPage1.png).
Text styles - Page 1 (thin).png [432.58 KiB]
Downloaded 258 times

Attachment:
File comment: Page 2 of the demo (720 dpi original: http://members.allegro.cc/ThomasHarte/temp/TextStylesPage2.png).
Text styles - Page 2 (thin).png [397.22 KiB]
Downloaded 257 times


EDIT: lower resolution images substituted for originals as both browsers I tried seemed to really have speed issues with the originals; the original 720 dpi versions are linked and actually have smaller file sizes.
Author:  ParasS [ Sun Sep 07, 2008 10:02 pm ]
Post subject:  Re: Printer Emulation
Fantastic results all round - I don't think my game has a colour dump but I did write the code above as a precursor to the ROM so it's a good benchmark!

Once again, I am truly impressed at how quickly you've got this up and running... writing dumps is mundane and painful, so I expect writing an emulation is more so!!!

Thank you!
Author:  ThomasHarte [ Wed Sep 17, 2008 11:27 pm ]
Post subject:  Re: Printer Emulation
Update for anyone watching this thread: I'm in the process of adding a PDF output target. It's very incomplete, but an early ~2.5mb test file is available at http://members.allegro.cc/ThomasHarte/temp/EPO.pdf (not attached since this board doesn't allow PDFs for some reason). It should hopefully look much like a real FX80 print-out on screen (be sure to zoom in; the caching on some PDF viewers seems to make the file as currently encoded look very bad from a distance), exactly like an FX80 print-out (subject to the sampling limitations of using your printer to produce 1-point size circles) and also allow copy & paste and searching through text.

The PDF writing code is all my own (well, it uses zlib for compression at some points, but you know what I mean), and very far from thoroughly tested so I'd be grateful if anyone who tries this file and finds it to not work could alert me. I'm aware that the way it is organised causes pages rendering to be very slow in some PDF viewers. For now I think that's just going to have to be an accepted limitation.

I've still got about a million things I need to do before this code is ready to submit to BeebEm and/or anything else, but it's getting very close.
Author:  Samwise [ Wed Sep 17, 2008 11:53 pm ]
Post subject:  Re: Printer Emulation
ThomasHarte wrote:
(not attached since this board doesn't allow PDFs for some reason)

Thomas, this forum's only configured to allow a set of default files. For anything else, it's recommended you zip it. Space isn't a huge problem on the server, but it's usually prudent to encourage ppl to archive potentially large files to save on bandwidth too.

ThomasHarte wrote:
The PDF writing code is all my own (well, it uses zlib for compression at some points, but you know what I mean), and very far from thoroughly tested so I'd be grateful if anyone who tries this file and finds it to not work could alert me. I'm aware that the way it is organised causes pages rendering to be very slow in some PDF viewers. For now I think that's just going to have to be an accepted limitation.

I'm afraid your PDF doesn't work at all with KPDF or KGhostView, for me. It just crashes out. Output from the latter, included below.

Sam.

Code:
   **** Error: Cannot find a %%EOF marker anywhere in the file.
   **** Warning:  An error occurred while reading an XREF table.
   **** The file has been damaged.  This may have been caused
   **** by a problem while converting or transfering the file.
   **** Ghostscript will attempt to recover the data.
Error: /undefined in /BXlevel
Operand stack:
   0   1   --dict:5/5(ro)(G)--   (n)
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1905   1   3   %oparray_pop   1904   1   3   %oparray_pop   1888   1   3   %oparray_pop   1771   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   --nostringval--   %loop_continue   --nostringval--
Dictionary stack:
   --dict:1157/1684(ro)(G)--   --dict:1/20(G)--   --dict:97/200(L)--   --dict:108/127(ro)(G)--   --dict:275/300(ro)(G)--   --dict:20/25(L)--
Current allocation mode is local
Last OS error: 2
Current file position is 2222
GPL Ghostscript 8.62: Unrecoverable error, exit code 1
Author:  DaveJ [ Thu Sep 18, 2008 7:40 am ]
Post subject:  Re: Printer Emulation
I am using Windows XP Home, Adobe Acrobat Reader 9.0. I couldn't view the .pdf - it crashed the Acrobat Reader.
Author:  ThomasHarte [ Thu Sep 18, 2008 11:02 am ]
Post subject:  Re: Printer Emulation
Well that's all obviously frustrating. For the record, I've tested against Preview.app, Adobe Acrobat Reader 8 (the most recent version available for my aged copy of Windows 2000) and the latest Foxit.

Neither of the Windows programs give anything helpful in the way of format validation, and Preview.app only seems to generate errors when it really can't figure out what's going on, but the KGhostscript clue is really good - having a look inside the PDF, I've used "%EOF" where I should have "%%EOF". I'll correct my code tonight and try to get a Linux distribution going in a virtual machine in order to increase my testing base.

Since there doesn't seem to be any PDF validation software and the PDF specs are around 1,000 pages long, I'm likely to make several more stupid mistakes like this before this output is bulletproof.
Page 1 of 2 All times are UTC [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/