[CSDb] - User Forums - Using Ganged to split a koala image

You are not logged in - nap

CSDb User Forums

Forums > C64 Pixeling > Using Ganged to split a koala image

2010-12-06 00:03

Lobogris

Registered: Oct 2010
Posts: 22

Using Ganged to split a koala image

Hi I am trying to split a koala image with this nice tool.
AFAIK a koala pic has the following info:

2 bytes header ($6000)
8000 bytes bitmap data
1000 bytes screen ram data
1000 bytes color ram data
1 byte background color

Well ...

If I use the Ganged option to save only the bitmap data, and
8194 bytes is saved to the file, instead of the 8002 bytes
(2 bytes of the header) I think that Ganged is wrong here, thinking that bitmap data is 8K when is 8000 bytes.

The color and screem rams are saved as expected, not 1026 bytes (2 bytes for address header) and files have the correct size = 1002 bytes.

What I am missing here? Its an error, a bug?
Thanks.

... 3 posts hidden. Click here to view all posts....

2010-12-10 09:38

iAN CooG

Registered: May 2002
Posts: 3132

Quote: As I posten in a comment to your release: why would you want to split the file?

I'm asking this because here, but also in my work, people often want to solve a problem by working out one solution that they came up with.
A lot of times however other people can come up with other solutions that are easier, cheaper, more flexible or otherwise better to be worked out.

What I want to say is: give us insight in the problem behind the problem and let us think outside your box :-)

(For instance, if you're using a cross platform tool to develop, often it can load various parts of a single file and thus split the file up while compiling.)

Because you have to move anyway color and screen manually to display a bitmap, many times you don't even have 10001 free contiguous bytes in memory so the optimal solution is to place the 8000 bytes of bitmap already where it should be, then place screen/color attribs where there is space. In my cracks for example you'll often see the bitmap at $e000, screen at $c400 and colors at $c800, which are the only part needed to be manually copied to $d800.
Splitting a koala with just an hexeditor is trivial once you know the layout, but if you really need to do it several times, a tool can be always handy, why not? =)

2010-12-10 11:33

Lobogris

Registered: Oct 2010
Posts: 22

@Mace I needed for coding purposes... I needed to allocate that parts in concrete memory addresses and not in the koala order. And, sometimes if you exomize a koala the buffer to depack needs to be small, and spliting the file into 3 parts is useful, if you have available in your program a small area for the depack buffer.

I made another loader that loads a full koala instead of a splited one, but I have a different memory map for that file, and the exomized image was considerably smaller than this bitmap, so the depack routine had no problems.

2010-12-10 16:58

TheRyk

Registered: Mar 2009
Posts: 2070

As I already mentioned in my comment to the tool, why not use VICE, LOAD "BLABLA.PRG" (<-- the Koala File) with ,8,1 (,1 is important to have it at the right address), then pushing Alt+M in VICE and then hacking something like:

S "BITMAP" 08 $6000 $XYZZ (the end value you desire) 
S "SCREEN" 08 $7F40 $XYZZ (the end value you desire) 
S "COLOUR" 08 $8328 $XYZZ (the end value you desire)

That's the way I always do it. A little complicated but I got used to it and it enables me to save some RAM if I just want a little multicolour logo and split a part of the screen in textmode anyway (e.g. for a scroller).

2010-12-10 17:05

Lobogris

Registered: Oct 2010
Posts: 22

Quote: As I already mentioned in my comment to the tool, why not use VICE, LOAD "BLABLA.PRG" (<-- the Koala File) with ,8,1 (,1 is important to have it at the right address), then pushing Alt+M in VICE and then hacking something like:

S "BITMAP" 08 $6000 $XYZZ (the end value you desire) S "SCREEN" 08 $7F40 $XYZZ (the end value you desire) S "COLOUR" 08 $8328 $XYZZ (the end value you desire)

That's the way I always do it. A little complicated but I got used to it and it enables me to save some RAM if I just want a little multicolour logo and split a part of the screen in textmode anyway (e.g. for a scroller).

I hadn't figured that :D yeah the vice monitor will be very handy here.
But if you have a lot of images to process, you can avoid a lot of typing using simply a specialized tool...

But I take note of your comment.. using vice is a nice option too.

2010-12-10 17:07

TheRyk

Registered: Mar 2009
Posts: 2070

As hinted in my comment, I don't think that your approach is a bad idea at all, especially if you have greater amounts of pictures to split. Maybe you can make sth of my feedback/request for further versions.

Keep it up, Cheers, Ryk

2010-12-10 17:26

Lobogris

Registered: Oct 2010
Posts: 22

I appreciate all your feedback and it will serve to enhance this version into a more flexible tool in the future. :) Anyway it was not my initial idea... my initial idea was I have this tool wich I builded from scratch seeing that it doesn't existed, and once done... I think... well someone will need this tool, so I will upload it to the csdb.
But seeing the great need in the community (I am greatly surprised) of this kind of tool, I consider upgrading further on this tool in the future ;)

2010-12-11 16:10

MagerValp

Registered: Dec 2001
Posts: 1055

Don't pretty much all assemblers support including just parts of a file?

.segment "BITMAP"
.include "picture.koa", 2, 8000

.segment "CHARS"
.include "picture.koa", 8002, 1000

.segment "COLORS"
.include "picture.koa", 9002, 1000

Only one file to keep in your source repository, directly editable, and no external tools needed to build.

2010-12-11 16:35

iAN CooG

Registered: May 2002
Posts: 3132

not all assemblers are the same and have the same features, besides not everyone uses an assembler to link files, one would only load them manually in memory or use a packer-linker and whatnot, I don't see why everyone should work in the same way, everyone has their own methods, some are easier, some are harder, some take much more time, some completely wrong or giving worse results =) It's up to us to understand what's the more confortable way to do things.

2010-12-11 17:57

Lobogris

Registered: Oct 2010
Posts: 22

sure, @Ian Coog is completely right.

For example, my project is a basic program with machine lang routines :D
so I need the files read by basic. For the basic haters: some great games dont need 100% speed codes. Examples: Pirates!, and (compiled basic) Quod init exit. But I don't wanna open here a discussion about basic games, so please, simply understand that there are many ways to do things...

Anyway is very educative, seeing the varied ways to solve the problem using the different programs and tools available, thanks guys!

2010-12-11 18:20

iAN CooG

Registered: May 2002
Posts: 3132

wait, Quod init exit NEED to be compiled (Basic boss compiler), and most basic crap when compiled can only be better =)

Previous - 1 | 2 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

Enforcer/Deers
Acidchild/Padua
Mythus/Delysid
alwyz/udi
Guests online: 115

Top Demos

1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Bromance  (9.6)
10 Memento Mori  (9.6)

Top onefile Demos

1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)

Top Groups

1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)

Top Crackers

1 Mr. Z  (9.9)
2 S!R  (9.9)
3 Antitrack  (9.8)
4 Mr Zero Page  (9.8)
5 OTD  (9.8)

Page generated in: 0.054 sec.