Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #1357 > unrolled thread

How Should I document Printing a DHGR image on an Apple II?

Back to article view | Back to comp.sys.apple2.programmer

Contents

  How Should I document Printing a DHGR image on an Apple II? "Bill Buckels" <bbuckels@mts.net> - 2014-10-24 06:40 -0500
    Re: How Should I document Printing a DHGR image on an Apple II? scott@alfter.diespammersdie.us (Scott Alfter) - 2014-10-24 17:04 +0000
      Re: How Should I document Printing a DHGR image on an Apple II? "Bill Buckels" <bbuckels@mts.net> - 2014-10-25 05:26 -0500
        Re: How Should I document Printing a DHGR image on an Apple II? Antoine Vignau <antoine.vignau@laposte.net> - 2014-10-26 01:15 -0700
          Re: How Should I document Printing a DHGR image on an Apple II? "Bill Buckels" <bbuckels@mts.net> - 2014-10-26 04:12 -0500
            Re: How Should I document Printing a DHGR image on an Apple II? "Bill Buckels" <bbuckels@mts.net> - 2014-10-26 04:23 -0500
        Re: How Should I document Printing a DHGR image on an Apple II? scott@alfter.diespammersdie.us (Scott Alfter) - 2014-10-28 18:16 +0000
        Re: How Should I document Printing a DHGR image on an Apple II? scott@alfter.diespammersdie.us (Scott Alfter) - 2014-10-28 19:37 +0000
    Re: How Should I document Printing a DHGR image on an Apple II? "Bill Buckels" <bbuckels@mts.net> - 2014-10-24 19:43 -0500
      Re: How Should I document Printing a DHGR image on an Apple II? Steve Nickolas <usotsuki@buric.co> - 2014-10-25 02:30 +0000
      Re: How Should I document Printing a DHGR image on an Apple II? "Christopher G. Mason" <cgm1@my-deja.com> - 2014-10-24 23:01 -0400
        Re: How Should I document Printing a DHGR image on an Apple II? "Bill Buckels" <bbuckels@mts.net> - 2014-10-25 05:12 -0500
        Re: How Should I document Printing a DHGR image on an Apple II? scott@alfter.diespammersdie.us (Scott Alfter) - 2014-10-28 19:20 +0000
          Re: How Should I document Printing a DHGR image on an Apple II? "Bill Buckels" <bbuckels@mts.net> - 2014-10-28 16:24 -0500

#1357 — How Should I document Printing a DHGR image on an Apple II?

I want to document printing a DHGR image from an Apple IIe on an ImageWriter 
using a Super Serial Card in a cc65 program.

Has this code been done already and if so can someone point me to it for 
review?

If it hasn't been done in cc65 has it been done in AppleSoft BASIC? That 
code would get me started. Otherwise if this has never been done before I 
will be the first... this is unlikely so someone should have this code 
somewhere I think.

Thanks.

Bill
 

[toc] | [next] | [standalone]

#1358

In article <m2ddsc$nbe$1@speranza.aioe.org>,
Bill Buckels <bbuckels@mts.net> wrote:
>I want to document printing a DHGR image from an Apple IIe on an ImageWriter 
>using a Super Serial Card in a cc65 program.
>
>Has this code been done already and if so can someone point me to it for 
>review?
>
>If it hasn't been done in cc65 has it been done in AppleSoft BASIC? That 
>code would get me started. Otherwise if this has never been done before I 
>will be the first... this is unlikely so someone should have this code 
>somewhere I think.

Pure BASIC code won't work.  You need to send 8-bit data to the printer, but
you can't do that without at least a little stub assembly-language
routine similar to this:

0300: A9 A0     LDA #$A0
0302: 4C ED FD  JMP COUT 

The bigger stumbling block is that the pixels on the HR and DHR screens are
grouped horizontally, but need to be grouped vertically for printing.  BASIC
would be intolerably slow at this sort of bit-mangling.  C would've been
better, but I didn't have a compiler for the Apple II and didn't even start
learning that language until maybe my second year of college (introductory
computer science courses were still using Pascal at the time).

I had a go at it with assembly language back in the day.  I'm pretty sure I
had some working code at one point, but if I still have it, it's probably
packed up in the garage.  I don't recall if it was Hi-Res or DHR; if it was
only Hi-Res, it wouldn't have been that big a deal to adapt to DHR: print at
160x72 dpi instead of 80x72, and alternate between auxiliary and main memory
for each group of 7 columns of pixels.

At one point, I was trying to push the Imagewriter for all it was worth.  I
had a driver (usable from BASIC) that did two-pass printing of text at
160x144 dpi to emulate other printers' "NLQ" mode.  At one point, I was
trying to print color graphics in multiple passes by printing a pass in one
color, winding the paper back, swapping ribbons, and printing the next pass. 
Quality wasn't particularly good, in part because while I could find yellow
ribbons for the Imagewriter, I couldn't find cyan and magenta.  Blue and red
were available, but produced too-dark print.  Seeing how proper color
dot-matrix printers handled printing photos and such a few years later, I
shouldn't have gotten my hopes up too high.  For monochrome images, though,
it worked well enough.

  _/_
 / v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/            Top-posting!
 \_^_/                              >What's the most annoying thing on Usenet?

[toc] | [prev] | [next] | [standalone]

#1363

"Scott Alfter" <scott@alfter.diespammersdie.us> wrote:
>The bigger stumbling block is that the pixels on the HR and DHR screens are 
>grouped horizontally, but need to be grouped vertically for printing.

It's really easy to unmask these into individual pixels.

>BASIC would be intolerably slow at this sort of bit-mangling.

I think BASIC will need some help from ML. I'll get this working in C first 
and decompose it back down to BASIC with as few ML subroutines as possible.

The idea is to document DHGR graphics printing in step form with working 
examples. There isn't much incentive for anyone to use DHGR bitmapped 
graphics without providing some kind of target program. So far SlideShows, 
Movies, and Sprites for games and demos are on my radar (Jonas did a 
prototype movie recently) and I've done the other two prototypes... but 
printing applications expand the potential for a retro experience a great 
deal.

Thanks for your thoughts. You can jump-in and write part of this anytime you 
want. I may need some help with the ML routines for the BASIC examples when 
I get to them. The C code I can easily manage after I get the printer output 
routines fleshed-out.

Bill 

[toc] | [prev] | [next] | [standalone]

#1364

Bill,


Check the issues of the Pom's magazine, I'm pretty sure there is such a code there.

Antoine

[toc] | [prev] | [next] | [standalone]

#1365

"Antoine Vignau" <antoine.vignau@laposte.net> wrote:
>Check the issues of the Pom's magazine, I'm pretty sure there is such a 
>code there.

http://sbm.ordinotheque.free.fr/apple/poms/index.html

Any idea which issue has the DHGR C code?

Bill 

[toc] | [prev] | [next] | [standalone]

#1366

"Bill Buckels" <bbuckels@mts.net> wrote:
>Any idea which issue has the DHGR C code?

HGR DUMP for epson is in poms 17... is this the article?

Bill

[toc] | [prev] | [next] | [standalone]

#1376

In article <m2ftts$fkb$1@speranza.aioe.org>,
Bill Buckels <bbuckels@mts.net> wrote:
>"Scott Alfter" <scott@alfter.diespammersdie.us> wrote:
>>The bigger stumbling block is that the pixels on the HR and DHR screens are 
>>grouped horizontally, but need to be grouped vertically for printing.
>
>It's really easy to unmask these into individual pixels.
>
>>BASIC would be intolerably slow at this sort of bit-mangling.
>
>I think BASIC will need some help from ML. I'll get this working in C first 
>and decompose it back down to BASIC with as few ML subroutines as possible.

I didn't intend to imply that bit-mangling would be difficult (it isn't),
only that a BASIC-only implementation would be intolerably slow due to the
lack of bitwise operators.  Since a helper routine is already necessary for
output to the printer, I suppose another helper routine to do the
bit-mangling wouldn't be out of order either.

>Thanks for your thoughts. You can jump-in and write part of this anytime you 
>want. I may need some help with the ML routines for the BASIC examples when 
>I get to them. The C code I can easily manage after I get the printer output 
>routines fleshed-out.

I'll see what I can knock together.  The only thing I don't recall offhand
is whether the low bit of graphics data sent to the printer will fire the
topmost pin or the bottommost pin.  I'd have to dig up my manuals, as the
Imagewriter II manual I've found online doesn't include graphics commands
and the Imagewriter manual I've found is in French.

  _/_
 / v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/            Top-posting!
 \_^_/                              >What's the most annoying thing on Usenet?

[toc] | [prev] | [next] | [standalone]

#1378

In article <m2ftts$fkb$1@speranza.aioe.org>,
Bill Buckels <bbuckels@mts.net> wrote:
>Thanks for your thoughts. You can jump-in and write part of this anytime you 
>want. I may need some help with the ML routines for the BASIC examples when 
>I get to them. The C code I can easily manage after I get the printer output 
>routines fleshed-out.

Here's something I knocked together in the mini-assembler.  It takes a 7x8
block of pixels and rearranges them from row order to column order.  It uses
a little bit of self-modifying code to copy a block from the screen into
0x0380-0x0387, then rotates the bits into left-to-right order, LSB at top,
at 0x0388-0x038E.  Put the starting address of the pixel block at 0x0303. 

0300  A2 07     LDX #7
0302  18        CLC
0303  AD 00 20  LDA $2000
0306  9D 80 03  STA $380,X
0309  AD 05 03  LDA $305
030C  69 04     ADC #4
030E  8D 05 03  STA $305
0311  CA        DEX
0312  10 EF     BPL $303
0314  A2 F9     LDX #$F9
0316  A0 07     LDY #7
0318  B9 80 03  LDA $380,Y
031B  6A        ROR
031C  99 80 03  STA $380,Y
031F  7E 8F 02  ROR $28F,X
0322  88        DEY
0323  10 F3     BPL $318
0325  E8        INX
0326  30 EE     BMI $316
0328  60        RTS

To test, draw a short diagonal line:

HGR:HCOLOR=3:HPLOT 0,0 TO 7,8

Set up and execute:

POKE 772,0:POKE 773,32:CALL 768

Dump the result:

FOR I=904 TO 910:PRINT PEEK(I):NEXT

You should get this result set: 3 6 12 24 48 96 192.

  _/_
 / v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/            Top-posting!
 \_^_/                              >What's the most annoying thing on Usenet?

[toc] | [prev] | [next] | [standalone]

#1359

"Bill Buckels" <bbuckels@mts.net> wrote:
 >printing a DHGR image from an Apple IIe on an ImageWriter using a Super 
Serial Card in a cc65 program.

I guess this doesn't exist. I'm not looking for code snippets although they 
are interesting.

I was looking for the cc65 source for an end to end program that formats and 
prints DHGR images after it sets-up the printer.

Complete with escape sequences; the whole bit.

For the Apple IIe (not the IIgs) although GSPort sounds like a place to 
test.

Another way to do this (I've done this in the past) is to convert a graphic 
to a "PRN" file of printer codes mixed with bitmap data for a specific 
printer (I did this in the 90's  with various cash register printers for 
company logos, HP PCL printers, Epson Printers etc). The PRN file can then 
be streamed to the printer

I can get info for Epson info printers freely but this ImageWriter seems to 
want money for the Technical Reference Manual. I might just do the PRN file 
conversion for an Epson for now.

>has it been done in AppleSoft BASIC?

Sounds like this doesn't exist.

The simplest thing for me to do is probably to add PRN file output to 
Bmp2DHR and then write a cc65 program that streams the PRN file.

If that works well enough I can port the PRN file routine to cc65 and do 
Print Screen Memory in cc65.

I remember doing this with EGA mode back in the '80's with MS-DOS too.

But we had good documentation and other C coders.

Bill

[toc] | [prev] | [next] | [standalone]

#1360

On Fri, 24 Oct 2014, Bill Buckels wrote:

> I remember doing this with EGA mode back in the '80's with MS-DOS too.
>
> But we had good documentation and other C coders.
>
> Bill

And GRAPHICS.COM that made it all irrelevant.

-uso.

[toc] | [prev] | [next] | [standalone]

#1361

On 10/24/2014 8:43 PM, Bill Buckels wrote:
> "Bill Buckels" <bbuckels@mts.net> wrote:
>
> I can get info for Epson info printers freely but this ImageWriter seems to
> want money for the Technical Reference Manual. I might just do the PRN file
> conversion for an Epson for now.
>

The ESC codes are documented in the GSport source (check 
imagewriter.cpp). Graphics bits are handled in the REVERSE manner from 
Epson ESC/P printers, least significant bit is the top pin while most 
significant is the bottom pin. Parameter numbers for ESC codes are sent 
as ASCII strings, not raw hex values. I have both the Imagewriter II and 
Imagewriter LQ Technical Reference manuals if you have any questions. 
They were not easy to acquire and unfortunately I have no access to a 
book scanner.

Setting Horizontal resolution (pitch):
ESC n: print in 72 horizontal dpi
ESC N: print in 80 horizontal dpi
ESC E: print in 96 horizontal dpi
ESC e: print in 107 horizontal dpi
ESC q: print in 120 horizontal dpi
ESC Q: print in 136 horizontal dpi
ESC p: print in 144 horizontal dpi
ESC P: print in 160 horizontal dpi

Double the above values when printing with the Imagewriter LQ commands 
below. EG: ESC P produces 320 horizontal dpi when printing with ESC C 
and ESC U.

Graphics codes (8 pins/72 vertical dpi):
ESC G nnnn: Print nnnn standard resolution graphics columns
ESC g nnn: Print 8 x nnn standard resolution graphics columns
ESC V nnnn c: Print nnnn repetitions of graphics bit c.
ESC K n: change color (IW II and LQ only)

Imagewriter LQ only high resolution graphics commands (24 pins/216 
vertical dpi):
ESC C nnnn: Print nnnn x 3 high resolution graphics columns
ESC U nnnn abc: Print nnnn repetitions of high res graphics bits abc.

Parts of the original Imagewriter manual are here: 
<http://lisaem.sunder.net/cgi-bin/bookview2.cgi?zoom=-3?page=0?book=10?Go=Go>

Imagewriter II Codes are here: 
<http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Peripherals/Printers/Apple%20ImageWriter%20II/Manuals/Apple%20ImageWriter%20II%20-%20Quick%20Reference%20Card.pdf>

Imagewriter II manual: 
<http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Peripherals/Printers/Apple%20ImageWriter%20II/Manuals/Apple%20ImageWriter%20II%20-%20Owner%27s%20Manual.pdf>

[toc] | [prev] | [next] | [standalone]

#1362

"Christopher G. Mason" <cgm1@my-deja.com> wrote:
>The ESC codes are documented in the GSport source (check imagewriter.cpp).
Thanks for all the help Chris,

The thought had crossed my mind to review the GSPort source. You have left 
me with little choice now:)

I'll probably just do an A size rotated DHGR screen printout routine for 
cc65 initially and add a DHGR graphics catalog printout later.
Also having this in 8 bit 6502 ProDOS makes this accessible to Apple IIe 
programmers and users who might have a real printer.

>Graphics bits are handled in the REVERSE manner from Epson ESC/P printers, 
>least significant bit is the top pin while most
significant is the bottom pin.

After further thought, the Imagewriter is the way to go for a Genuine Apple 
II solution rather than the Epson. Your info is an offer that I can't 
refuse.

Again thanks. Lots of effort went into your posts. I really appreciate it.


Bill 

[toc] | [prev] | [next] | [standalone]

#1377

In article <m2f3qm$154$1@dont-email.me>,
Christopher G. Mason <cgm1@my-deja.com> wrote:
>The ESC codes are documented in the GSport source (check 
>imagewriter.cpp). Graphics bits are handled in the REVERSE manner from 
>Epson ESC/P printers, least significant bit is the top pin while most 
>significant is the bottom pin.

That's the part I wasn't sure about.  Code to follow shortly.

  _/_
 / v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/            Top-posting!
 \_^_/                              >What's the most annoying thing on Usenet?

[toc] | [prev] | [next] | [standalone]

#1379

"Scott Alfter" <scott@alfter.diespammersdie.us> wrote:
>Code to follow shortly.

Sounds good!

Bill 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web