Ghetto Image Converter for HGR modes

[Osgeld]

I entered ludum dare last weekend, which is a 48 hour from scratch
game development compo, and I decided I was going to make an Apple II
"battleship" clone (since the theme was discovery) currently its 4
days past deadline and I am still fighting with it lol

anyway a half hour before the competition started, I decided I needed
a way to draw highres graphics and export them to the II, so I whipped
up this little ghetto system to do just that

Requirements:
PC running The Gimp
PC with lua 5.1 installed (older versions of the lua interpreter will
not work)
The Gimp palette file I made for the Apple II HGR colors
The Lua conversion script I made

Basic Rundown: you make a 280x192 or 280x160 graphic using the gimp
and the pallet, save it as a ppm file, edit the convert.lua file to
change what image file your working on, that spits out a ginormous
list of HPLOT and HCOLOR commands that you copy n paste (hopefully in
a emulator running as fast as it will go, otherwise prepare to be
bored ... for a long while)

Gimp pallet:
Apple-II.gpl (save as)
open The Gimp, right click in the main window, choose Windows >
Dockable Dialogs > Palettes, this will open a pallets window, right
click on that window, and choose Import Palette, choose Palette file
and select the Apple-II.gpl file to install

Lua 5.1
debian based systems do sudo apt-get install lua5.1
MS windows download from http://luabinaries.sourceforge.net/download.html
and unzip to c:\lua

Graphics:
Make an image or convert an image using the supplied palette at
280x192 or 280x160 and save as a *.ppm file

Script:
convert.lua (save as)
edit the convert.lua file to point to the *.ppm file you are currently
wanting to convert, and save

The convert.lua script as posted needs to be in the same directory as
your ppm files !!
If your using windows, AND unzipped to the suggested location above
there is a "click n go" cmd file for you, everyone else will need to
run lua convert.lua OR lua5.1 convert.lua from the command line. This
reads the ppm file and produces a *.ppm_out file, which is just a
bucket-ton of basic statements

You can then copy and paste them into an Apple II system, BSAVE them
and recall them

BE WARNED!!
this produces tens of thousands of HPLOT and HCOLOR statements, I
strongly recommend you paste them into an emulator running at full
tilt warp speed, Apple II win can do it in a matter of seconds, but
needles in eyes speed at 1MHz, ALSO this does not account for any of
the funnier aspects of the Apple II video system, what you see in the
gimp is NOT what you get on the apple, but its close

Links:

Download here http://www.cheesefactory.us/apple2/gfxcv/
Screenshots here (apple IIc) http://www.cheesefactory.us/apple2/gfxcv/screenshots/

enjoy

[Xerxes409]

This is such a ghetto fabulous brute-force solution. I love it!

Recently I've been trying to take my ridiculously huge 12 megapixel
DSLR photos and scaling them down to Apple IIGS (and given the
scalability of the image, standard Apple II DHR / HGR) resolutions.
Convert 3200 seens to have the best all-round SHR mode conversion
chops, though the images I get from a program called JpeGS are the
most supernaturally amazing 16-color graphics I've ever seen on my
Apple monitor.

Unfortunately JpeGS is lacking a "save" function and timed CDA screen
savers don't work :(

Wondering if anyone else has done any nutty graphics conversions or
has any tips for a modern+retro process.

[Sheldon Simms]

This reminded me of something I did a long time ago and, rather than dig through old archives, I decided to start rewriting it, so here's the first release:

http://wsxyz.net/tohgr.html

Right now, it only converts XPM images to HGR format. DHGR is almost finished and I'll update when that's done. For what it's worth, enjoy.

[sicklittlemonkey]

On Jan 6, 12:46 pm, Sheldon Simms <wsspa...@gmail.com> wrote:
> Right now, it only converts XPM images to HGR format. DHGR is almost finished and I'll update when that's done. For what it's worth, enjoy.

Looks great. Would be even better with the “Atkinson” dithering
filter:
http://www.tinrocket.com/software/hyperdither/
(scroll down)

Cheers,
Nick.

[Sheldon Simms]

Ok I took a look at the Atkinson dither. It is interesting that it does seem to get subjectively better results on some images because algorithmically, it looks like Atkinson's main concern was performance: his dither doesn't require any multiplications. I'll include it as an option in the next release.

To anyone reading - is there a preferred file format for DHGR images? I'm leaning towards a straight memory image, like HGR, but even then, should the file contain the aux memory image followed by main memory? The other way around? Interleaved in display order? If there's no "standard" then I'll probably go with the first of the options I just mentioned.

[Toinet]

Hi,
The standards are binary files, with auxtype of either $4000 or $4001.
Data being compressed with PackBytes.

There's a standard for HGR, described in a file type note:
http://mirrors.apple2.org.za/ground.icaen.uiowa.edu/Mirrors/uni-kl/filetypes/ftn-08-4000

and one for DHGR, described in a file type note:
http://mirrors.apple2.org.za/ground.icaen.uiowa.edu/Mirrors/uni-kl/filetypes/ftn-08-4001

For the DHGR format, the aux part always come first in a file.

antoine

[sicklittlemonkey]

On Jan 7, 4:50 pm, Sheldon Simms <wsspa...@gmail.com> wrote:
> To anyone reading - is there a preferred file format for DHGR images? I'm leaning towards a straight memory image, like HGR, but even then, should the file contain the aux memory image followed by main memory? The other way around? Interleaved in display order? If there's no "standard" then I'll probably go with the first of the options I just mentioned.

I think of Dazzle Draw as the "standard", but might be wrong. IIRC
their format is [Aux][Main], whereas another app (Blazing Paddles?)
used [Main][Aux].

Cheers,
Nick.

[Wizard Of Oz]

On 11-01-06 09:50 PM, Sheldon Simms wrote:
> Ok I took a look at the Atkinson dither. It is interesting that it does seem to get subjectively better results on some images because algorithmically, it looks like Atkinson's main concern was performance: his dither doesn't require any multiplications. I'll include it as an option in the next release.
>
> To anyone reading - is there a preferred file format for DHGR images? I'm leaning towards a straight memory image, like HGR, but even then, should the file contain the aux memory image followed by main memory? The other way around? Interleaved in display order? If there's no "standard" then I'll probably go with the first of the options I just mentioned.

This probably won't be much of a help... I was working on a
utility/program subroutine which stored the data of a DHGR page as a
linear buffer of 4bit pixels and made the conversion to DHGR whenever
requested by the programmer. I got kind of busy when I was near the end
so I was only able to get it partly working. Maybe reversing the process
would let you perform different forms of compression on the data...

Later
Mike

[ict@ccess]

> For the DHGR format, the aux part always come first in a file.
> antoine

That baffles me as it requires 2 moves. From Main $2000 to Aux $2000
then Main $4000 to Main $2000, whereas the the other way is just one
move, Main $4000 to Aux $2000 as the first part is already in the
right place. Can anyone see a good reason for this?

> To anyone reading - is there a preferred file format for DHGR images? I'm leaning towards a straight memory image, > like HGR, but even then, should the file contain the aux memory image followed by main memory? The other way
> around? Interleaved in display order? If there's no "standard" then I'll probably go with the first of the options I just
> mentioned.

Yes, it is preferred my way. :)

You might want to check out my Dbl hi-res screen compressor. It has
one of the highest compression algorythms as well as it can compress
any part of the screen. This allows for compressed animation that can
be animated in one spot on the screen. Loading a smaller file and
uncompressing the file is faster than loading the complete file
uncompressed plus it save a lot of disk space.

My compressor saves anywhere from 1 to 5 blocks over Beagles Double
Scrunch routine.

You are welcome to it here: www.pv3.ca/Apple/MyDblCruncher.2mg.zip

I am slowing bringing my software to the light of day. A couple of
more off the top of my head is: for users of the extended keyboard on
their IIGS, a way to turn the caps lock, scroll lock and num lock
lights on and off for Prodos 8 users. and short and simple font
routines for the Dbl Hires screen.

Rob

[Toinet]

On 7 jan, 19:55, "ict@ccess" <gids...@sasktel.net> wrote:
> > For the DHGR format, the aux part always come first in a file.
> > antoine
>
> That baffles me as it requires 2 moves.  From Main $2000 to Aux $2000
> then Main $4000 to Main $2000, whereas the the other way is just one
> move, Main $4000 to Aux $2000 as the first part is already in the
> right place.  Can anyone see a good reason for this?
>

Because Apple said it is the way it should be. If you want your images
to be loaded by existing software, it is the best solution to choose
(not the most efficient for sure) but I doubt somebody will write a
new/update an existing software to handle your format.

That is what was done on the IIgs with the Apple Preferred Format
(handles all kinds of image files) vs proprietary formats like the
Dreamgraphix one (better LZxx (c) (tm) compression), that one being
compatible with... Dreamgraphix only.

In French, we say "le mieux est l'ennemi du bien", is "let well alone"
correct?

antoine
antoine

[ict@ccess]

> In French, we say "le mieux est l'ennemi du bien", is "let well alone"
> correct?
>
> antoine

we English have many sayings too, "Let by-gones be by-gones"
but I am the type of guy that looks under every cloud for a silver
lining
and sometimes even killing 2 birds with one stone comes in handy.

[Sheldon Simms]

Good info. Thanks. I'm not so sure about those crazy packbytes image formats, but the algorithm seems to be really simple, so I'll go ahead and include it as an option.

[Sheldon Simms]

Probably just because the aux memory byte leads every scan line.
It seems like it would be possible to load the image directly into auxiliary memory at $2000
and then copy the second half to main.

[Jerry]

Sheldon Simms <wssp...@gmail.com> writes:

Even from BASIC and ProDOS it's not so bad:

load the aux half:
BLOAD DHR.PIC,A8192,L8192,B0

move it to aux with the $C311 routine (using a short asm routine to set
up $3C-3F,$42-43)

BLOAD DHR.PIC,A8192,B8192

In assembly it would be even simpler since you don't have to open the
file twice.

OPEN
READ 8192 bytes => $2000
...
jsr AuxMove
READ 8192 bytes => $2000
set DHGR display mode

--
Jerry awanderin at yahoo dot ca

[Sheldon Simms]

I have completed the double hires output option so there is a newer version of 'tohgr'
for anyone who is interested. If anyone has actually downloaded the program, you will
want to get this update because I fixed a bug in the scaling algorithm that negatively
impacted image quality.

I'm actually pretty impressed at some of the double hires images produced. The extra
colors available really improve the results considerably.

http://wsxyz.net/tohgr.html

I also added Atkinson dithering as an option in this release. It works best on greyscale
images. I prefer Floyd-Steinberg for most color pictures.

The next thing I will probably do is add the option to produce the crazy packbits-enabled
HGR and DHGR image formats. After that I'll probably work on IIgs graphics modes.
After that I'll see about some other input options (better than XPM).

[Bill Buckels]

"Sheldon Simms" <wssp...@gmail.com> wrote:

>To anyone reading - is there a preferred file format for DHGR images?

Here's what I do...

http://www.appleoldies.ca/azgraphics33/bmpa2fc.htm

This utility will allow you to convert to Apple II Double Hi-Res 140 x 192
x 16 color images from IBM-PC graphics files in the following formats:

CGA 320 x 200 x 4 color BASIC BSAVED IMAGE (.BAS) Files
CGA 320 x 200 x 4 color ZSOFT .PCX Files
EGA 320 x 200 x 16 color Windows .BMP Files

Double Hi-Res Graphics

The double high-resolution display mode that is available for the Apple IIe
displays 140 columns of color, for which all 16 of the low-resolution colors
are available. Because the double high-resolution graphics mode provides
twice the horizontal dot density as standard hi-res graphics does, double
hi-res requires twice as much memory as does standard hi-res.

The double hi-res display interleaves bytes from the two different memory
pages (auxiliary and motherboard). Seven bits from a byte in the auxiliary
memory bank are displayed first, followed by seven bits from the
corresponding byte on the motherboard. The bits are shifted out the same way
as in standard hi-res (least-significant bit first).

http://www.appleoldies.ca/azgraphics33/index.htm#doublehi

You might also want to check-out some of my other utilities including
Clipshop...

http://www.clipshop.ca/

Cheers,

Bill

[Sheldon Simms]

On Sunday, January 9, 2011 5:18:24 PM UTC-5, Bill Buckels wrote:
>
> Here's what I do...
>
> http://www.appleoldies.ca/azgraphics33/bmpa2fc.htm
>
> This utility will allow you to convert to Apple II Double Hi-Res 140 x 192
> x 16 color images from IBM-PC graphics files in the following formats:

Thanks Bill. Source code like that is why I can't release my source code yet. I've been
shamed!

Your program and my program have a similar purpose, but mine takes XPM files as
input.

[ict@ccess]

On Jan 7, 10:22 pm, Jerry <awande...@yahoo.ca> wrote:

You can also use this pure applesoft routine to load dbl res without
having to use ML move routine.

10 D$=CHR$(4): ? D$ "PR#3": ?
20 F$="DBL.RES.PIC,A$2000,L$2000"
30 HGR : POKE 49246,0
40 POKE 49237,0: ?D$"BLOAD" F$
50 POKE 49236,0: ?D$"BLOAD "F$",B$2000"
60 POKE 49234,0

[Jerry]

"ict@ccess" <gid...@sasktel.net> writes:

Hey, that's cool. I assumed ProDOS would diddle with the $C054/5
switches, but apparently not! Good stuff!

[Bill Buckels]

"Sheldon Simms" <wssp...@gmail.com> wrote:
>Source code like that is why I can't release my source code yet. I've been
>shamed!

Don't worry about stuff like that...

Release early and release often... There aren't that many people left in the
world interested in Apple II's so play with them while you have the chance:)

And if people can easily convert from a common image format to an apple II
graphic they won't worry about your source code.

Cheers,

Bill

[Bill Buckels]

"Sheldon Simms" <wssp...@gmail.com> wrote:
>It seems like it would be possible to load the image directly into
>auxiliary memory at $2000 and then copy the second half to main.

Here's what I do...

/* dlode.c by bill buckels 2009 */
/* a picture viewer for the apple II */
/* written in Manx Aztec C65 Version 3.2b */
/* runs under DOS 3.3 */
/* displays BSaved double hi-res Images */

http://www.appleoldies.ca/azgraphics33/dlode.htm

[John B. Matthews]

In article <igerh7$5oj$1...@speranza.aioe.org>,
"Bill Buckels" <bbuc...@mts.net> wrote:

> "Sheldon Simms" <wssp...@gmail.com> wrote:
> >Source code like that is why I can't release my source code yet.
> >I've been shamed!
>
> Don't worry about stuff like that...
>
> Release early and release often... There aren't that many people left
> in the world interested in Apple II's so play with them while you
> have the chance:)

Bill's points are well taken; and, like so many others here, his code is
exemplary, as well as instructive. One of my favorite examples of
constructive analysis is Neil Parker's examination of this old demo:

<http://www.llx.com/~nparker/a2/kal2.html>
<http://home.roadrunner.com/~jbmatthews/apple2.html#rp2>

I just can't resist learning new ways to bum the code:

<http://www.iwar.org.uk/hackers/resources/faq/jargon.htm#bum>

> And if people can easily convert from a common image format to an apple II
> graphic they won't worry about your source code.

Agreed!

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[Bill Buckels]

"Bill Buckels" <bbuc...@mts.net> wrote:
>Here's what I do...

Loader Code only with comments...

http://www.appleoldies.ca/azgraphics33/drlode.c.txt

Program Main:

http://www.appleoldies.ca/azgraphics33/dlode.htm

[Sheldon Simms]

I've just uploaded a new version of my little command line image
converter 'tohgr' (new name suggestions are welcome...)

http://wsxyz.net/tohgr.html

The new features are conversion to 3200 color super hires "Apple
Preferred" images and the ability to select packed output (filetypes
$08/$4000 & $08/$4001) for hires and double hires images.

This is a feature-incomplete release, but it's been a while and I
wanted to get something out there.
The Mac (Snow Leopard) executable is up and I'll get a Mac PPC
executable and a Windows EXE up sometime later today. I've also put up
a disk image of 3200 color pictures.

[theycal...@gmail.com]

I'd love to try this, but the Windows download (tohgr.exe.gz) appears to be broken/corrupt. I've tried decompressing it with more than one tool.

Will you please look into this? Perhaps a .zip file would be handier for Windows users.

Thanks!

[Bill Garber]

<theycal...@gmail.com> wrote in message news:a42a
0301-b638-41b4-a...@googlegroups.com...

> I'd love to try this, but the Windows download
> (tohgr.exe.gz) appears to be broken/corrupt.
> I've tried decompressing it with more than one tool.
>
> Will you please look into this? Perhaps a .zip
> file would be handier for Windows users.
>
> Thanks!

I concur that the file within the archive is corrupt.

SEPA Electronics
http://www.sepa-electronics.com
Bill Garber

[BluPhoenyx]

On 06/04/2012 12:45 AM, theycal...@gmail.com wrote:
> I'd love to try this, but the Windows download (tohgr.exe.gz) appears to be broken/corrupt. I've tried decompressing it with more than one tool.
>
> Will you please look into this? Perhaps a .zip file would be handier for Windows users.
>
> Thanks!
>
> On Tuesday, January 25, 2011 1:19:46 PM UTC-6, Sheldon Simms wrote:
>> I've just uploaded a new version of my little command line image
>> converter 'tohgr' (new name suggestions are welcome...)
>>
>> http://wsxyz.net/tohgr.html
>>
>> The new features are conversion to 3200 color super hires "Apple
>> Preferred" images and the ability to select packed output (filetypes

>> $08/$4000& $08/$4001) for hires and double hires images.

>>
>> This is a feature-incomplete release, but it's been a while and I
>> wanted to get something out there.
>> The Mac (Snow Leopard) executable is up and I'll get a Mac PPC
>> executable and a Windows EXE up sometime later today. I've also put up
>> a disk image of 3200 color pictures.
>

a quick look at the file suggests you simply strip the .gz suffix off
the 'archive' name and the file should execute.

Cheers,
Mike T

[theycal...@gmail.com]

Mike,

No, that doesn't work.

Here are some of the things I've already tried:

Decompressing with 7-Zip for Windows
Decompressing with gzip for Windows
Renaming to tohgr.exe and trying to execute
Renaming to tohgr.exe and trying to execute in DOSBox
Renaming to tohgr.tar.gz and trying to decompress as a tar archive
Renaming to tohgr.exe.zip and trying to decompress as a zip archive with both 7-Zip and Windows
Poking around in a hex editor to check for obvious issues
Scouring the Internet looking for a good copy, or the source so I can build it myself

I've also tested the other gz archives on the site and they do not appear to be corrupt.

I have emailed the author about this problem, so hopefully we will hear something soon.

On Monday, June 4, 2012 3:00:28 PM UTC-5, BluPhoenyx wrote:

[Kevin Dady]

Same here I wanted to try out the DHGR modes but the windows archive
is bad, I have sent a couple of emails over time but no response or
fix

[theycal...@gmail.com]

Well, I don't have any more time to waste waiting for tohgr, so I've extracted some code from Apple // Game Server (http://sourceforge.net/projects/a2gameserver/) that seems to do what I want. I'm a .NET guy so my Java skills aren't that great, but I have it loading jpgs and pngs and converting them to hgr with preview output.

I haven't tested it on real hardware yet, and the inputs and outputs are currently hard-coded, but I'm optimistic.

[theycal...@gmail.com]

Just to follow up, the Game Server code works fine, and I even have a little program that loads the output into hi-res screen RAM from disk on a real Apple IIe.

[BLuRry]

:-) Glad that the code was of use to you! There are a couple more conversion routines in there should you find them of interest. You can also convert to Lo-res, Double-hires, and "flicker" modes where it generates two lo-res or two dhgr images that you can alternate during vblank to produce a perceptually higher color image. It does actually work, though the flicker will be apparent.

-B

[BluPhoenyx]

On 06/04/2012 06:26 PM, theycal...@gmail.com wrote:
> Mike,
>
> No, that doesn't work.
>
> Here are some of the things I've already tried:
>
> Decompressing with 7-Zip for Windows
> Decompressing with gzip for Windows
> Renaming to tohgr.exe and trying to execute
> Renaming to tohgr.exe and trying to execute in DOSBox
> Renaming to tohgr.tar.gz and trying to decompress as a tar archive
> Renaming to tohgr.exe.zip and trying to decompress as a zip archive with both 7-Zip and Windows
> Poking around in a hex editor to check for obvious issues
> Scouring the Internet looking for a good copy, or the source so I can build it myself
>
> I've also tested the other gz archives on the site and they do not appear to be corrupt.
>
> I have emailed the author about this problem, so hopefully we will hear something soon.

Glad to read that you worked out an alternative method for your needs.
My suggestion was essentially correct as the file has the proper windows
PE header but there appears to be garbage right after the header so
essentially the program is still corrupt. I suspect it might be the
cross compiler used (mingw if I read the code right.)

Cheers,
Mike T

[theycal...@gmail.com]

Mike,

I'm not sure where you're getting your info, but the tohgr.exe.gz file I downloaded has neither an MZ header nor a PE header anywhere in the file.

Windows executables start with bytes 4D 5A (ASCII "MZ") and have the byte sequence 50 45 00 00 (ASCII "PE" followed by 2 nulls) somewhere in them. The gz archive in question has neither of these.

In fact, the GZIP specification says that gz files start with the fields ID1 and ID2, with values 1F and 8B, respectively. The first two bytes in the tohgr archive are 1F and 8B. I don't think that's a coincidence.

You can find a copy of the spec here: http://www.gzip.org/zlib/rfc-gzip.html#file-format

And what code are you talking about? The binary file? What do you see that makes you think mingw was used, and why is that relevant?

Sorry, but you're not making a lot of sense.

On Thursday, June 7, 2012 4:35:40 PM UTC-5, BluPhoenyx wrote:

[BluPhoenyx]

On 06/07/2012 09:45 PM, theycal...@gmail.com wrote:
> Mike,
>
> I'm not sure where you're getting your info, but the tohgr.exe.gz file I downloaded has neither an MZ header nor a PE header anywhere in the file.
>
> Windows executables start with bytes 4D 5A (ASCII "MZ") and have the byte sequence 50 45 00 00 (ASCII "PE" followed by 2 nulls) somewhere in them. The gz archive in question has neither of these.
>
> In fact, the GZIP specification says that gz files start with the fields ID1 and ID2, with values 1F and 8B, respectively. The first two bytes in the tohgr archive are 1F and 8B. I don't think that's a coincidence.
>
> You can find a copy of the spec here: http://www.gzip.org/zlib/rfc-gzip.html#file-format
>
> And what code are you talking about? The binary file? What do you see that makes you think mingw was used, and why is that relevant?
>
> Sorry, but you're not making a lot of sense.

Hmmm, the file I downloaded from the site actually does have such a
header. Perhaps we have different files although I don't see how that
could be true unless we downloaded different files. I downloaded it on
separate occasions. I just checked the file again and a hex listing
verifies the header. FWIW, I know Windows programs having had decades of
experience using and maintaining PC's. In the hex listing of the file I
have the name 'mingw' is in the code. This usually happens when that
compiler is used to create a Windows executable.

At this point it really doesn't matter as the file doesn't do what it's
supposed to so the point is moot.

Cheers,
Mike T

[biafra....@gmail.com]

On Thursday, December 23, 2010 1:24:18 AM UTC-6, Osgeld wrote:
> I entered ludum dare last weekend, which is a 48 hour from scratch
> game development compo, and I decided I was going to make an Apple II
> "battleship" clone (since the theme was discovery) currently its 4
> days past deadline and I am still fighting with it lol
>
> anyway a half hour before the competition started, I decided I needed
> a way to draw highres graphics and export them to the II, so I whipped
> up this little ghetto system to do just that
>
> Requirements:
> PC running The Gimp
> PC with lua 5.1 installed (older versions of the lua interpreter will
> not work)
> The Gimp palette file I made for the Apple II HGR colors
> The Lua conversion script I made
>
> Basic Rundown: you make a 280x192 or 280x160 graphic using the gimp
> and the pallet, save it as a ppm file, edit the convert.lua file to
> change what image file your working on, that spits out a ginormous
> list of HPLOT and HCOLOR commands that you copy n paste (hopefully in
> a emulator running as fast as it will go, otherwise prepare to be
> bored ... for a long while)
>
> Gimp pallet:
> Apple-II.gpl (save as)
> open The Gimp, right click in the main window, choose Windows >
> Dockable Dialogs > Palettes, this will open a pallets window, right
> click on that window, and choose Import Palette, choose Palette file
> and select the Apple-II.gpl file to install
>
> Lua 5.1
> debian based systems do sudo apt-get install lua5.1
> MS windows download from http://luabinaries.sourceforge.net/download.html
> and unzip to c:\lua
>
> Graphics:
> Make an image or convert an image using the supplied palette at
> 280x192 or 280x160 and save as a *.ppm file
>
> Script:
> convert.lua (save as)
> edit the convert.lua file to point to the *.ppm file you are currently
> wanting to convert, and save
>
> The convert.lua script as posted needs to be in the same directory as
> your ppm files !!
> If your using windows, AND unzipped to the suggested location above
> there is a "click n go" cmd file for you, everyone else will need to
> run lua convert.lua OR lua5.1 convert.lua from the command line. This
> reads the ppm file and produces a *.ppm_out file, which is just a
> bucket-ton of basic statements
>
> You can then copy and paste them into an Apple II system, BSAVE them
> and recall them
>
> BE WARNED!!
> this produces tens of thousands of HPLOT and HCOLOR statements, I
> strongly recommend you paste them into an emulator running at full
> tilt warp speed, Apple II win can do it in a matter of seconds, but
> needles in eyes speed at 1MHz, ALSO this does not account for any of
> the funnier aspects of the Apple II video system, what you see in the
> gimp is NOT what you get on the apple, but its close
>
> Links:
>
> Download here http://www.cheesefactory.us/apple2/gfxcv/
> Screenshots here (apple IIc) http://www.cheesefactory.us/apple2/gfxcv/screenshots/
>
> enjoy

Okay, the lua script is giving me some interesting errors here:

Saving the PPM as ASCII gives me this error:

convert.lua:66: attempt to concatenate field '?' (a nil value)
stack traceback:
convert.lua:66: in main chunk
[C]: ?

Saving it in RAW gives me this error:

convert.lua:23: attempt to perform arithmetic on field '?' (a string value)
stack traceback:
convert.lua:23: in main chunk
[C]: in ?

I'm fairly certain this will require an ASCII PPM file as it seems to analyse text, but doing it either way doesn't work.

I've also tried this script using both Lua 5.1 and 5.2 x64

My setup
OS: Windows 8 Pro with Media Center x64
Lua: 5.1 x64 and 5.2 x64
GIMP: 2.8.2

[osgeld]

> Okay, the lua script is giving me some interesting errors here:
>
>
>
> Saving the PPM as ASCII gives me this error:
>
>
>
> convert.lua:66: attempt to concatenate field '?' (a nil value)
>
> stack traceback:
>
> convert.lua:66: in main chunk
>
> [C]: ?
>
>
>
> Saving it in RAW gives me this error:
>
>
>
> convert.lua:23: attempt to perform arithmetic on field '?' (a string value)
>
> stack traceback:
>
> convert.lua:23: in main chunk
>
> [C]: in ?
>
>
>
> I'm fairly certain this will require an ASCII PPM file as it seems to analyse text, but doing it either way doesn't work.
>
>
>
> I've also tried this script using both Lua 5.1 and 5.2 x64
>
>
>
> My setup
>
> OS: Windows 8 Pro with Media Center x64
>
> Lua: 5.1 x64 and 5.2 x64
>
> GIMP: 2.8.2

Yes its ASCII, did you dither using the palette in the gimp? If the color does not meet an exact RGB value it will barf

[biafra....@gmail.com]

I converted the image to Index color using the colors in the Apple-II-LGR.gpl pallete in the GIMP. Color Dithering in the GIMP was off, and Transparency Dithering was off.

[biafra....@gmail.com]

Also, I checked things out and ruled out GIMP as well, a solely Black and white palette (which use the same RGB values for Black and White in your script) isn't working at all, either.

[osgeld]

the LGR palette is 16 colors, HGR is only 6 so there is your problem, you need to use appleII.gpl

[biafra....@gmail.com]

Tried using AppleII.gpl. It didn't work either. Neither did using a monochrome image. I keep getting this error:

lua5.1: convert.lua:66: attempt to concatenate field '?' (a nil value)

[osgeld]

yea its not reading soemthing correct, take me step by step though your process, this thing is very sensitive to everything being 100%

[cybernesto]

maybe you should give this a try:
http://www.harmlesslion.com/cgi-bin/showprog.cgi?search=converthgr
Even if you are not running windows, it works pretty well under wine or equivalents.