...und die Bedeutung von Byte 18 und 19 ist nun auch geklärt, sie enthalten die Länge des Bildes in Bytes (Lo/Hi).

Damit ergibt sich jetzt:

Header (Zählung ab 0!):
=================
- Bytes 0-6: FF 80 C9 C7 1A 00 01
- Byte 7: Modus 0=unkomprimiert, 1=vertikal, 2=horizontal
- Bytes 8-12: 0E 00 28 00 C0
- Bytes 13-17: Farben Register 708,709,710,711,712
- Bytes 18-19: Länge des Bildes in Bytes (Lo/Hi)
- Bytes 20-25: 00 00 9B 9B 9B 9B
- Bytes 26... : Bilddaten in "Blocks"

Damit wären dem Koala-Header nun wohl die wichtigsten Geheimnisse entlockt !

Gruß,

Michael

Es erscheint nur Gepixel auf dem Bildschirm.

das ist vollkommen richtig. das koalaformat legt immer 8 byte untereinander dann werden rechts daneben wieder 8 bytes untereinandergeschrieben usw bis 40 bytes nebeneinander stehen.
dann geht es in die nächste blockzeile(8 byte tiefer) und das spiel beginnt von vorn. beim c64 werden immer sogenannte charblöcke gesetzt und jetzt kommt es : der atari setzt immer erst eine bytereihe voll und geht dann in die nächste byte reihe. du musst es noch umrechnen und das kann wieder zeit kosten, die nicht wenig ist. darum ist das koalaformat für den atari nicht geeignet.

robbifan hat geschrieben:

Es erscheint nur Gepixel auf dem Bildschirm.

das ist vollkommen richtig. das koalaformat legt immer 8 byte untereinander dann werden rechts daneben wieder 8 bytes untereinandergeschrieben usw bis 40 bytes nebeneinander stehen.
dann geht es in die nächste blockzeile(8 byte tiefer) und das spiel beginnt von vorn. beim c64 werden immer sogenannte charblöcke gesetzt und jetzt kommt es : der atari setzt immer erst eine bytereihe voll und geht dann in die nächste byte reihe. du musst es noch umrechnen und das kann wieder zeit kosten, die nicht wenig ist. darum ist das koalaformat für den atari nicht geeignet.

Hi,

es ging ja auch um das Format des Koala Micro-Illustrator. Da werden die Bytes - in der ATARI-Version - so gespeichert, wie weiter oben in diesem Thema beschrieben. Mit Charblocks kann der ATARI natürlich (so gesehen) nichts anfangen. Andersherum müsste der 64er natürlich auch die Daten umrechnen, aber das soll hier nicht das Thema sein ! Fazit scheint also zu sein, dass die Formate nicht direkt kompatibel sind. Macht aber auch nichts, da ich mittlerweile auch das unkomprimierte Format anhand eines Bildes herausbekommen konnte. Es ist einfach der o.g. Header + 7680 Datenbytes.

Gruß,

Michael

Andersherum müsste der 64er natürlich auch die Daten umrechnen, aber das soll hier nicht das Thema sein

für die c64-grafik gibt es soviele painter für den pc und welche die auch auf den 64 direkt laufen die das 64ziger format herstellen, das es dieses problem da nicht gibt zum umrechnen.


warum machst du solche krückenhafte umstände, programmier dir ein tool und fertig. ich habe für den atari mit purebasic angefangen.

mfg

Dieser Artikel aus Analog "Atari Picture Storage Techniques" kann zum Thema interessant sein

http://strotmann.de/twiki/bin/view/APG/ ... ileFormats

Ciao

Carsten

cas hat geschrieben:Dieser Artikel aus Analog "Atari Picture Storage Techniques" kann zum Thema interessant sein

http://strotmann.de/twiki/bin/view/APG/ ... ileFormats

Ciao

Carsten

Carsten, super, damit sind die letzten Rätsel um einige offene Bytes im Header geklärt!

Dank Dir!

Gruß,

Michael

Tja,
und der Antic-Artikel bestätigt auch, was ich schon vorher gesagt habe - nämlich, dass in den Koala-Bildern noch Platz gelassen wurde für eine Betitelung des Bildes, für den Autorennamen, etc. Allerdings wurden diese Optionen nie genutzt (steht auch in dem Artikel drin). In den Koala-Bildern sieht man das im Header, dort stehen nach einigen Bytes immer mehrere Leerzeilen (einfach mal unter Turbo-DOS mit TYPE Filename.PIC anzeigen lassen)... Ist doch immer wieder schön, wenn sich eigene Behauptungen am Ende bestätigen... -Andreas Koch.

CharlieChaplin hat geschrieben:Tja,
und der Antic-Artikel bestätigt auch, was ich schon vorher gesagt habe - nämlich, dass in den Koala-Bildern noch Platz gelassen wurde für eine Betitelung des Bildes, für den Autorennamen, etc. Allerdings wurden diese Optionen nie genutzt (steht auch in dem Artikel drin). In den Koala-Bildern sieht man das im Header, dort stehen nach einigen Bytes immer mehrere Leerzeilen (einfach mal unter Turbo-DOS mit TYPE Filename.PIC anzeigen lassen)... Ist doch immer wieder schön, wenn sich eigene Behauptungen am Ende bestätigen... -Andreas Koch.

Hallo Andreas,

hmmm, da kann ich nur zu 50% zustimmen. Mit TYPE unter Turbo-DOS sieht es nur so aus, als ob die Leerzeilen da wären. In Wirklichkeit sind sie es aber nicht. Lediglich die in dem Artikel erwähnten Bytes mit dem Inhalt $9B (155) finden sich im Header und die führen zu einem Zeilenvorschub, da sie als ATASCII-EOL interpretiert werden. In der Datei selbst gibt es keine Leerzeilen. Du kannst das am besten mit einem Hexeditor oder Diskdump sehen. Du hast aber insofern recht, dass in dem Format die Möglichkeit vorgesehen wurde, diese Leerzeilen einzufügen (wurde nur scheinbar nicht genutzt). Die würden dann von den in der Datei vorhandenen $9B begrenzt. Dazu müsste aber auch die Länge des Headers über die Längen-Bytes 5,6 eingetragen sein. Dort steht aber bei allen Koala-Bildern, die ich bis jetzt untersucht habe, immer $1A und $00, also 26 Byte. Ich habe das am Wochenende mit meiner Maltafel und dem ATARI Artist getestet und außerdem mit dem Koala Micro-Illustrator. Beide schreiben immer nur vertikal komprimierte Bilder mit einem 26 Byte Header, sonst nichts. Schick mir evtl. mal ein Bild, wo diese Möglichkeit genutzt wurde. Es wäre interessant, welches Programm das erzeugt hat. Grundsätzlich ist dieses Feature nämlich gut.

Woher stammt eigentlich dieses Format? Wurde es mit dem Koala Micro-Illustrator eingeführt oder gab es das schon früher?

Grüße,

Michael

Hmm,
das Format Micro-Illustrator gab es nicht nur für Koala, es wurde von einer Firma entwickelt und dann an div. Hardware Firmen lizensiert. Deshalb gibt es das format auch für das Koala Pad, den Koala Lightpen, Atari Touch Tablet, und div. andere Tablets und Lightpens. Weiss aber nicht mehr genau wer der entwickler von Micro-Illustrator war... Vielleicht ja mal bei atari-age nachfragen "Who invented Micro-Illustrator format ?"... -Andreas Koch.

Hallo Andreas,

hier noch mal ein Hexdump eines Koala-Bildes, das ich mit WinHex erstellt habe.

Code: Alles auswählen

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00000000   FF 80 C9 C7 1A 00 01 01  0E 00 28 00 C0 C5 35 0F   ÿ€ÉÇ......(.ÀÅ5.
00000010   0C 00 7B 0D 00 00 9B 9B  9B 9B A2 02 FF 5D F4 02   ..{...››››¢.ÿ]ô.
00000020   FF 5E F1 03 FF 5D 44 02  FF 5E 11 03 FF 09 44 0C   ÿ^ñ.ÿ]D.ÿ^..ÿ.D.

Du kannst hier gut den Header studieren und die aufeinander folgenden $9B Zeichen sehen.

Das gleiche Bild mit TYPE unter Turbo DOS ausgegeben, erzeugt dann u.a. 4 leere Zeilen (je eine pro $9B).

Hinter dem $A2 geht dann direkt das Bild los: 02 FF 5D ...

Gruß,

Michael

Und äh,
als Nachtrag noch ein Text von Jiri Bernasek (englisch) der sich mit koala beschäftigt... Gruß, Andreas Koch.

-------------------------------------------------------------

KOALA PICTURE FILES
-------------------

By Jiri Bernasek (BEWESOFT)


A short time ago I made a program, which is (besides of other
great functions) able to display nearly any picture from the
disk. It's simple of course. But... The trouble was with loader
for KOALA files. I have a lot of them (Source listings, utility
etc. etc.), but the correct one is missing! Finally I was forced
to crack the original KOALA MICROILLUSTRATOR program. But let's
start from the begin...

There are many formats of picture-files on Atari XL/XE. The most
used formats are MICRO PAINTER and KOALA. MICRO PAINTER format
is quite simple: The first 7680 bytes of the file contains the
whole screen-memory, and the last four bytes contains colors in
order: Background, color 0, color 1, and color 2.

KOALA files contains packed pictures, so they are not so simple.
At the begin of every KOALA file there is a header:

File position Function
---------------------------------------
0...3 Identification of KOALA file.
Allways FF 80 C9 C7 (hex.)
4, 5 Length of header -1 (Normal
length is $1B)
6 ??? (Allways 01)
7 Compression method. It can be
00, 01, or 02.
8 ??? (Allways 0E)
9...C Position and size of window
for loading the picture in.
D...11 Colors. (Copy of memory range
$2C4...$2C8)
12, 13 Length of the whole file -1
14...1A ??? (Allways 00 00 9B 9B 9B
9B A2)
---------------------------------------

Position and size of window are defined by four bytes: Starting
X-position (in bytes - NOT in pixels!), ending X-position (The
first position AFTER the picture), starting Y-position, and
ending Y-position.
The KOALA program uses allways 00 28 00 C0 (the whole screen)
while saving a picture, but there can be files with only parts
of the screen - original KOALA can load them.

Three compression methods can be used (see byte 7 of the
header). 00 is without of compression - the rest of the file
(after header) contains directly the screen-memory. (But don't
forget that it needn't to be the whole screen - see above.)
01 is the most common method. It contains packed data, which
will be placed on screen in well known "vertical" order: First
bytes of lines 0, 2, 4, 6 etc., then first bytes of lines 1, 3,
5, 7 etc., and then next columns in the same way.
Method 02 contains packed data too, but they will be placed on
the screen in normal order - the same as method 00.

The format of packed data is simple. There are two types of
entries:
- Non-packed data. The first byte has "1" in the bit D7 (128),
rest of this byte is length of the data block (max. 127). If
this length is zero, then there are two bytes more - they are
the actual length (16 bits - High byte first!). Next bytes are
data.
- Packed data. The first byte has "0" in the bit D7, the rest is
the length - the same as described above. There is only one
data-byte, which will fill all the bytes in the block.

You can also look at the example below. (All the entries will
make two bytes with value FF.) There is the example:
82 FF FF ;Non-packed block
80 00 02 FF FF ;Long non-packed block
02 FF ;Packed block
00 00 02 FF ;Long packed block

The trouble is that most of "Koala loaders" can load only files
with standard length of header ($1B), with compression method
01, and with the whole screen. Simply: Most of loaders supports
only one thing from the header: Color bytes!

Another trouble is that there are mistakes in the KOALA
MICROILLUSTRATOR program itself! Yes! I found three mistakes
while cracking it:
- It can't load files with a long headers. (There is a mistake
in the program, so it'll skip one byte more.) You need to change
bytes at adress $4AA0 from 20 F8 48 A5 8C D0 04 C6 8D 30 05 C6
8C to A5 8C D0 04 C6 8D 30 08 C6 8C 20 F8 48 to repair this.
- With compression method 00 (no compression) it'll allways load
the whole screen - never mind the X/Y ranges from the header.
(There isn't any simple correction for this, but it isn't very
fatal mistake.)
- With compression method 00 (no compression) it'll save the
screen in a wrong way: It'll add lots of nonsences before the
picture-data, so the file will be very long (I think that it was
about 30 kB!), and it's impossible to load such a file back.
(Because the loader is reading the begin of the file, where are
nonsences...) To repair this (most fatal) bug, you need to
change the byte at adress $4981 from C9 to C0.

And now a little test. It'll show which KOALA loaders are good,
and which are not.
We'll make three KOALA files. The first one can be any picture
which is in the common "vertical loading" format.
Load the KOALA MICROILLUSTRATOR program, and paint large
horizontal lines on the screen. (For example two scanlines full
of a color, two empty scanlines, and so on...) Save it on the
disk - it's the second file.
For the third file we'll make a little BASIC program:
10 OPEN #1,8,0,"D:PICTURE":FOR A=1 TO 7684:PUT #1,PEEK
(53770):NEXT A:CLOSE #1:END
This program will make a Micropainter-file with random
(non-packable) contents. Then load KOALA MICROILLUSTRATOR (With
the correction of the third mistake - see above), switch to the
picture with SPACE BAR (this is necessary because of another bug
in the program), and press "<" key. Your random picture will
appear. Paint only a few lines on this screen (we'll see if is
it displayed correctly then), and save it as the third file.
Now try to load these files with several loaders, which you
have. The first file will work well with every loaders, but the
second and third file will be displayed correctly only by really
good loaders. Personally I have only two good loaders: The
original KOALA, and the one written by me...

----------------------------------------------------------------------------------

Und noch ne Kleinigkeit,
einige A8 Programme neigen dazu beim kopieren, konvertieren oder up/downloaden von dateien einige extra Bytes am ende anzuhängen, sogar einige Grafik-Konverter tun dies. Ich erinnere mich an einen WASEO Grafik-konverter (Waseo-Grafinoptikum, Waseo-Publisher oder sonstwas) und an einige Modem-Programme (Bobterm u.a.) die dieses Verhalten zeigen...

Nun, bei manchen Programmen mag dieser zusätzliche "anhang" von ein paar bytes nicht weiter schlimm sein (Demos und Spiele laufen unter Gamedos trotzdem), bei KOALA Grafiken ist er jedoch meistens fatal: Die meisten mir bekannten Koala Loader und Converter entpacken ein gepacktes Bild und entpacken und entpacken - und wenn sie auf die extra bytes stoßen, dann entpacken sie munter weiter und überschreiben das bild auf dem screen mit datenmüll... Mit PICTRIX.COM konnte ich viele solcher Bilder retten, denn Pictrix stoppte zumeist am eigentlichen Dateiende und lud den überflüssigen anhang nicht...

Schonmal Bilder auf einer teilweise defekten Disk gehabt ?!? Also meinereiner hatte schon das Glück, und bei Micropainter bildern erschienen zumeist streifen odr grafikbugs auf dem screen, wo def. sektoren aufgetreten waren (natürlich nur, wenn hin- und wieder mal ein Sektor defekt war, bei mehreren def. sektoren in Folge ging auch nix mehr). Bei Koala Bildern scheint aber ein einziger def. Sektor oder einige fehlerhafte / fehlende Bytes auszureichen und nix geht mehr (Programmabsturz bzw. Datenmüll auf dem Screen und/oder Computer aufgehängt). Naja, jedenfalls waren dies bisher so meine pers. und rein subjektiven Eindrücke. Deshalb habe ich auch die meisten Koala Bilder in meiner Sammlung in 62 Sektoren-Bilder umgewandelt, denn die Micropainter Pix sind halt weniger empfindlich... -Andreas Koch.

Hi Andreas,

das sind noch mal weitere interessante Informationen zu dem Format. Ich habe mittlerweile den WASEO-Pixlator soweit ausgebaut, dass er alle drei Koala-Kompressionen laden kann. Mit den o.g. Interna kann man da aber noch einiges verbessern, um letzlich auch einen "guten" Koala-Lader zu bauen.

Was es mit den Problemen in den genannten WASEO-Programmen auf sich hat, kann ich nicht sagen. Ich habe mal Thorsten deswegen angemailt, der hat die Progs seinerzeit geschrieben und weiß evtl. mehr dazu.

Gruß,

Michael

CharlieChaplin hat geschrieben:Bei Koala Bildern scheint aber ein einziger def. Sektor oder einige fehlerhafte / fehlende Bytes auszureichen und nix geht mehr (Programmabsturz bzw. Datenmüll auf dem Screen und/oder Computer aufgehängt).

... naja, wenn der "Kontrollblock" mit den Kompressionsinfos verloren geht, wird es schwierig. Das kann man dann kaum mehr rekonstruieren. Denkbar wäre ein halb-manuelles Verfahren, bei dem man z.B. immer ein Byte zu lesen versucht und dann am Bildschirm kontolliert, ob was Vernünftiges angezeigt wird...