Update: Bmp2DHR and A2FCBmp - All Apple II Graphics Modes including Mode320 and Mode3200 SHR now provided

[Bill Buckels]

http://www.appleoldies.ca/bmp2dhr/heroes/

Bmp2DHR and A2FCBmp come together. I have updated the website with the
latest source code and Win32 binaries as of this morning. A2FCBmp is used to
make SHR images. People who use Linux or OSX will need to build their own
binaries. A gcc compatible makefile is provided. Visit the Bmp2DHR page
(link above) for the download link. Together these two converters provide
output for all the Apple II graphics modes including Mode320 and Mode3200
SHR. Mode640 SHR has not been added yet.

Samples including recent SHR and BROOKS images have been recently posted to
the Apple II Enthusiasts FaceBook Group:

https://www.facebook.com/groups/5251478676/

All the best,

Bill Buckels

[Nicola]

In article <mfjb1l$kam$1...@speranza.aioe.org>,

"Bill Buckels" <bbuc...@mts.net> wrote:

> http://www.appleoldies.ca/bmp2dhr/heroes/
>
> Bmp2DHR and A2FCBmp come together. I have updated the website with the
> latest source code and Win32 binaries as of this morning. A2FCBmp is used to
> make SHR images. People who use Linux or OSX will need to build their own
> binaries. A gcc compatible makefile is provided.

Thanks for this little tool! Very cool!

I'm trying to build it from source in OS X. The makefile is not really
Unix-friendly as it uses the backslash character for the path. Anyway,
I've tried to compile it myself using different compiler options (-arch
i386, -m32, -m64, -ansi, ...). I can get it build and run, but with
every image I try it I get "XYZ is in the wrong format!". This does not
happen when I use the pre-compiled binary linked from your page.

So, could someone help me figure out how to build it correctly for
Darwin?

Nicola

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Bill Buckels]

"Nicola" <nvitac...@gmail.com> wrote>

>I can get it build and run, but with every image I try it I get "XYZ is in
>the wrong format!".

I haven't a clue. Thanks for giving this a shot.

>This does not happen when I use the pre-compiled binary linked from your
>page.

Good to know:)

Bill

[Bill Buckels]

"Bill Buckels" <bbuc...@mts.net> wrote:
>"Nicola" <nvitac...@gmail.com> wrote:
>>I can get it build and run, but with every image I try it I get "XYZ is in
>>the wrong format!".
>I haven't a clue. Thanks for giving this a shot.

But if I had to guess, I would suspect that the structures are not being
packed on byte boundaries or they are misaligned in some way.

Did you try building both programs? To my knowledge Bmp2DHR works fine in
Linux and OSX but A2FCBmp has never been built or run in Linux or OSX.

Almost without fail my code works by the time I distribute it, so I strongly
suspect the structures are not being packed correctly. But perhaps the
typedefs need to be cleaned-up... there's lots of short integers in use, or
perhaps an unsigned long is more than 4 bytes on your system.

Bill

[mmphosis]

> I'm trying to build it from source in OS X. The makefile is not really
> Unix-friendly as it uses the backslash character for the path. Anyway,
> I've tried to compile it myself using different compiler options (-arch
> i386, -m32, -m64, -ansi, ...). I can get it build and run, but with
> every image I try it I get "XYZ is in the wrong format!". This does not
> happen when I use the pre-compiled binary linked from your page.
>
> So, could someone help me figure out how to build it correctly for
> Darwin?

The makefile included with the source code has been modified from the
original one that I provided. I suspect that the backslash was put in there
so that the makefile works with MinGW on Windows. For Darwin and similar
platforms, it will build a binary named "..b2d" inside the src directory,
although I don't think that the program will work as expected. ie. "XYZ is
in the wrong format!"

The binaries on this page:

http://hoop-la.ca/apple2/appleoldies/bmp2dhr/

I built these some time ago from older source code. They may work but with
fewer features. The PowerPC binaries may not work because of byte ordering
issues.

I did take a look at newer source code a few months ago, but it would take
effort to make the source portable.

You could run the exe using wine, or bootcamp or a virtual machine booting
windows. The alternative is tohgr:

http://wsxyz.net/tohgr.html

tohgr works well with png images (requires libpng.) tohgr doesn't do as many
modes as bmp2dhr. And, I have to say I am quite impressed with the results
using "Buckels Dithering" :)

[Nicola]

In article <mfkvv6$f3s$1...@speranza.aioe.org>,

"Bill Buckels" <bbuc...@mts.net> wrote:

> "Bill Buckels" <bbuc...@mts.net> wrote:
> >"Nicola" <nvitac...@gmail.com> wrote:
> >>I can get it build and run, but with every image I try it I get "XYZ is in
> >>the wrong format!".
> >I haven't a clue. Thanks for giving this a shot.
>
> But if I had to guess, I would suspect that the structures are not being
> packed on byte boundaries or they are misaligned in some way.

Yes, I was thinking the same. Or some endianness problem. But I guess we
are using similar processor architectures (I have an Intel Core 2 Duo
and i5).

> Did you try building both programs? To my knowledge Bmp2DHR works fine in
> Linux and OSX but A2FCBmp has never been built or run in Linux or OSX.

For me it's the opposite: a2fcbmp runs fine, but I cannot get bmp2dhr to
accept any file.

[Nicola]

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

> "Bill Buckels" <bbuc...@mts.net> wrote:
> there's lots of short integers in use, or
> perhaps an unsigned long is more than 4 bytes on your system.

Yes, that's 8 bytes on my system. But defining ulong as unsigned int is
not enough. As mmphosis has said, porting it to non-Windows systems may
be less trivial than I thought. I'll try to take a deeper look at the
source code.

[Steve Nickolas]

Try #include <stdint.h>
and using stuff like uint16_t?

Of course MS-DOS compilers are too old for that, but you can detect and
work around that. :P

-uso.

[Nicola]

Foolish me, I thought that the MINGW flag was a compiler-specific
option, but it is essential for the correct alignment. Now I can run all
the binaries just fine! For OS X users, now bmp2dhr, a2fcbmp and xpack
can be easily installed with

brew install bmp2dhr

(you need to `brew tap lifepillar/appleii` first, of course).

Time to create some graphics... :)

[Bill Buckels]

"Nicola" <nvitac...@gmail.com> wrote:
>Foolish me

I was just being polite:) The code is messy but it's portable. The MINGW
flag should really be the default with the Microsoft C default being the
option. This compiles in MS-DOS Turbo C from 1987 and every version of
Microsoft C since the 90's so why wouldn't it compile with a real compiler?
Problem with Microsoft C today is that its Win32 binaries are twice the size
(at least) as MinGW binaries and since MinGW is portable to gcc that worked
out!

I suffered the indignation of watching you suffer... I felt the slings and
arrows too but to me it's just chit-chat. My C code works. Has since the
80's. End of discussion...

>I thought that the MINGW flag was a compiler-specific option, but it is
>essential for the correct alignment.

It is a compiler specific option.

>Now I can run all the binaries just fine! For OS X users, now bmp2dhr,
>a2fcbmp and xpack can be easily installed with
>brew install bmp2dhr

So what's next? Remember that this all supports VBMP output and in fact
offers the most robust VBMP output available on the planet...

It makes sprites for every Apple IIe graphics mode, etc. etc. User definable
dithering, user definable palettes, and I hardly think anything provides an
alternative to any of this. It will also convert DHGR files back to modern
graphics files. It does monochrome and everything else...

But I'm making myself sick from talking about it.

Thanks again. You have the source and the comments and now you can make your
own version if you wish to explore any of this.

It's a good day for those pesky non-windows machines...

Bill

[Nicola]

In article <mfmafl$hah$1...@speranza.aioe.org>,

"Bill Buckels" <bbuc...@mts.net> wrote:

> I suffered the indignation of watching you suffer... I felt the slings and
> arrows too but to me it's just chit-chat. My C code works. Has since the
> 80's. End of discussion...

I didn't mean any lack of respect!

> So what's next?

A port to the Apple Watch? The screen should make a good fit, and you
may give us one reason to buy it :)

Btw, another question from a beginner: I'm trying to open those .A2FC
files with Dazzle Draw, but I always get "Not a Dazzle Draw picture".
Isn't bmp2dhr's output (created with `b2d input.bmp dhgr`) supposed to
be readable by Dazzle Draw? Or do I need to provide some other option?

[Bill Buckels]

"Nicola" <nvitac...@gmail.com> wrote:
>I didn't mean any lack of respect!

Then I am diappointed:) There's nothing here to respect... this is all just
standard parts... that's why it's amazing that they never did this on the
Apple like we did on the PC when it was worth money.

>A port to the Apple Watch? The screen should make a good fit, and you may
>give us one reason to buy it :)

Please don't tell anyone if that happens...

>I'm trying to open those .A2FC files with Dazzle Draw, but I always get
>"Not a Dazzle Draw picture".

I'll definetly look into that one.

While I'm thinking about it, if you modify the code make sure you extend the
buffers. There are still some memory over-runs on the dithering buffers that
can go out of bounds if they get changed.

I kept this line oriented and stayed away from structures but it comes with
a risk.

I'll get back to you on this dazzle draw question. But use the preview
option output and reprocess it again after editing and that way you can just
use a modern paint program if you want to clean-up a conversion.

Bill

[mmphosis]

Thanks Nicola that works. Here is what I did...

I downloaded brew into a local directory because I don't want to run things
as the Administrator.

https://github.com/Homebrew/homebrew/tarball/master

You must: brew install git

./Homebrew-homebrew-436a759/bin/brew install git

Tap Nicola's appleii...

./Homebrew-homebrew-436a759/bin/brew tap lifepillar/appleii

Try to install bmp2hr...

./Homebrew-homebrew-436a759/bin/brew install bmp2dhr

Error: SHA256 mismatch

So, I edited bmp2dhr.rb to match the SHA256, and tried again...

./Homebrew-homebrew-436a759/Library/Taps/lifepillar/homebrew-appleii/

rm /Library/Caches/Homebrew/bmp2dhr-1.1.zip

./Homebrew-homebrew-436a759/bin/brew install bmp2dhr

bmp2hdr works like a charm. Thanks Bill Buckels.

./Homebrew-homebrew-436a759/bin/bmp2dhr

-----

Turns out all that was needed was the "-arch i386" option to make things
work.

gcc -DMINGW -arch i386 -o ../$(PRG) $(SRC).c

I changed that one line in the makefile and bmp2dhr can be built and seems
to work without having to install brew and git.

Yes, back to creating graphics! :)

[Bill Buckels]

"mmphosis" <mmph...@macgui.com> wrote:
>bmp2hdr works like a charm. Thanks Bill Buckels.

My hands are in windows but my heart is in unix:) Sheldon would have done
what I did too if he had the time I'm sure... but then I wouldn't have had
the fun. I hope we are good to go on the next phase of these converters:)
I'll keep picking at making this more portable and bulletproof too... my
brain needs the exercise at my age obviously.

>Yes, back to creating graphics! :)

What do you do in your spare spare time:) Thanks for continuing to shep this
through... it really saves me the distraction of actually needing to
remember who I am and clawing back some of my other computers instead of
writing on my old XP box.

Good to see Nicola busy too:) Although his reference to the new dick tracy
watch made me recoil in horror... I took his link and plastered it on a
couple of Apple II Facebook Groups... that should give them something to do
besides polishing their keyboards.

Bill

[Nicola]

In article <mmphosis-...@macgui.com>,

mmphosis <mmph...@macgui.com> wrote:

> ./Homebrew-homebrew-436a759/bin/brew install bmp2dhr
>
> Error: SHA256 mismatch

Thanks, sha fixed (until bmp2dhr gets updated again, at least!).

[Bill Buckels]

"Nicola" <nvitac...@gmail.com> wrote:
> (until bmp2dhr gets updated again, at least!).

I am trying to group the updates into something that makes sense. Nobody has
time to look at updates unless they offer a significant advantage.

I have also kept this code completely independent of special libraries which
hampers me from linking to image format libraries but keeps this portable
from the 1980's to today. It's a real hack so it'll probably survive the
dick tracy watch and MS-DOS for mobile phones.

Bill

[Bill Buckels]

"Bill Buckels" <bbuc...@mts.net> wrote:
>"Nicola" <nvitac...@gmail.com> wrote:

>>I'm trying to open those .A2FC files with Dazzle Draw, but I always get
>>"Not a Dazzle Draw picture".
>I'll definetly look into that one.

And I did.

Dazzle Draw 1.2 running under kegs32 works just fine loading these A2FC
files freshly created with the latest version of Bmp2DHR on my Windows XP
box.

I used Ciderpress tags but you can place them by hand as a ProDOS BIN file
($06) with a load address of $2000

Why anyone would want to use dazzle draw is completely beyond me but alright
do as you wish:) ][gif also loads them. If you can't get ][gif to load them
then you are not placing them on the disk correctly. There's no header in
these so just any bin file of 16384 bytes with a load address of $2000
should load as a dazzle draw PIC file (that's what the dd menu calls these).

Bill

[Nicola]

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

> "Bill Buckels" <bbuc...@mts.net> wrote:
>
> Dazzle Draw 1.2 running under kegs32 works just fine loading these A2FC
> files freshly created with the latest version of Bmp2DHR on my Windows XP
> box.
>
> I used Ciderpress tags but you can place them by hand as a ProDOS BIN file
> ($06) with a load address of $2000

I can open the pictures with ][gif, but not yet with Dazzle Draw. It may
depend on the method I'm using (mounting the pictures's folder as a
ProDOS OmniDisk in Virtual ][), although I've double-checked the file
types and they indeed look right. Anyway, I'll try to put the images on
a regular disk image instead.

Thanks for your help!

[Bill Buckels]

"Nicola" <nvitac...@gmail.com> wrote:
>Thanks for your help!

I was no help at all:) I just made more work for you...

And thank you for inspring me to aspire further... it's fun to see this
stuff get passed around and used.

Bill

[Bill Buckels]

I continue to update A2B and B2D with the latest changes. There have been
several. The source is updated in the distro and there are new Windows
binaries as of this PM.

Visit the A2B page for a list of the latest links:

http://www.appleoldies.ca/a2b/

Samples including recent SHR and BROOKS images and youtube videos have been

recently posted to
the Apple II Enthusiasts FaceBook Group:

https://www.facebook.com/groups/5251478676/

Here's today's latest youtube:

https://www.youtube.com/watch?v=KGftEmCGitc

[Chris Torrence]

Resurrecting an old thread... For anyone looking to call b2d from Python...

First step was to build b2d on macOS (10.12.3) following nicola and mmphosis:
gcc -DMINGW -arch i386 -Wno-pointer-sign -Wno-comment -o ../b2d b2d.c

The next crucial step is to resize your input images to be the correct size for HGR/DHGR etc. If you don't have the correct size then b2d will complain about "wrong format!".

Here, my Python code is reading an image from a URL (works just as well from a .jpg or .png file), resizing to be 280x192 (since I want HGR), saving it to a BMP, then calling b2d. Then I read in the bytes and do something with them.

from PIL import Image
import subprocess
img = Image.open(requests.get(url, stream=True).raw)
img = img.resize((280,192))
img.save('temp.bmp')
subprocess.check_call(['./b2d', 'temp.bmp', 'hgr'])
f = open("TEMPC.BIN", "rb")
data = f.read(8192)
f.close()

Hopefully this will help anyone else who is doing something similar.
Cheers,
Chris

[Lifepillar]

On 18/02/2017 19:48, Chris Torrence wrote:
> Resurrecting an old thread... For anyone looking to call b2d from Python...
>
> First step was to build b2d on macOS (10.12.3) following nicola and mmphosis:
> gcc -DMINGW -arch i386 -Wno-pointer-sign -Wno-comment -o ../b2d b2d.c
>
> The next crucial step is to resize your input images to be the correct size for HGR/DHGR etc. If you don't have the correct size then b2d will complain about "wrong format!".
>
> Here, my Python code is reading an image from a URL (works just as well from a .jpg or .png file), resizing to be 280x192 (since I want HGR), saving it to a BMP, then calling b2d. Then I read in the bytes and do something with them.

Perhaps it is worth mentioning that you first need to install PIL and
requests packages:

pip install Pillow
pip install requests

> from PIL import Image
> import subprocess

I also had to add:

import requests
url = 'https://some.url/to/some/image.png'

> img = Image.open(requests.get(url, stream=True).raw)
> img = img.resize((280,192))
> img.save('temp.bmp')
> subprocess.check_call(['./b2d', 'temp.bmp', 'hgr'])
> f = open("TEMPC.BIN", "rb")
> data = f.read(8192)
> f.close()

In my (limited) testing, b2d complains that temp.bmp does not have the
right format, although it looks fine if I open it with a graphics program:

Palette 5: tohgr NTSC DHGR Colors
Preview Palette 5: tohgr NTSC DHGR Colors
temp.bmp is in the wrong format!

> Hopefully this will help anyone else who is doing something similar.

Sure, this comes in handy. Thanks for sharing!

Nicola

[Lifepillar]

> In my (limited) testing, b2d complains that temp.bmp does not have the
> right format, although it looks fine if I open it with a graphics program:
>
> Palette 5: tohgr NTSC DHGR Colors
> Preview Palette 5: tohgr NTSC DHGR Colors
> temp.bmp is in the wrong format!

It turns out that the problem was in the version of b2d installed from
https://github.com/lifepillar/homebrew-appleii, which was missing the
-arch i386 flag. I have fixed that and now it works!

If you have installed bmp2dhr using Homebrew, please reinstall it:

brew update
brew reinstall bmp2dhr

Nicola

[Bill Buckels]

"Lifepillar" <lifep...@lifepillar.me> wrote:
> I have fixed that and now it works!

Of course it works :)

[Bill Buckels]

"Chris Torrence" wrote:
>Resurrecting an old thread...

Me too... try this one...

The "Mixed-Up Toy" and other "Incredible Toys" - An Apple II DHGR
Programming Adventure for the C Language Programmer

http://www.appleoldies.ca/bmp2dhr/silly/

[Presley Acuna]

Hi all,

Looks like Bill's link to grab bmp2dhr for macos is a 404 these days. Anyone have a link to a current site for the static binary?

Thanks!

[David Schmidt]

The Wayback machine is your friend. But that page was mostly pointers
to elsewhere anyway. You might want to have a look at buckshot now:
https://apple2.gs/buckshot/

[mmphosis]

Bring Up My Post (bump)

https://mmphosis.netlify.app/bmp2dhr/

[Oliver Schmidt]

Hi,

It seems to me that this link too belongs in this thread:

https://github.com/digarok/b2d

Regards,
Oliver