| |
Trap
Registered: Jul 2010
Posts: 223 |
Loading, packing and linking on crossdev
Hi all,
I've spent some time coding some stuff and now I'm at a point where I need to look at putting the whole thing together. Packing, linking, adding a loader for the parts etc.
I'm using KickAss.
How do you manage files in a crossdev environment? Do I need a D64-editor of some sort to put it all together?
What (IRQ-)loaders and packers are you using these days? .... a lot has happened since SledgeHammer, so please bear with me :)
Trap
|
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Nowadays I'm using the Booze Design tool-chain, but previously I used pucrunch as packer, cc1541 as d64-creator and krill-load as loader. Worked like a charm and all ofcourse command-line driver and Makefilable. |
| |
Digger
Registered: Mar 2005
Posts: 437 |
Booze Design tool-chain? What's that? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Booze Design tool-chain? What's that?
Some internal Booze Design stuff: HCL's d64-utility, ByteBoozer and HCL's loader. Totally similar to the other tool-chain I mentioned (cc1541, pucrunch and krill-load). |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Many people prefer exomizer to crunch their stuff.
And you can also use c1541 (part of VICE) instead of cc1541 to automate the creation of a .d64 file.
And you probably want to use Krill's loader, cause it works. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
I can also recommend :
For packing Pucrunch or Exomizer (though I mostly use pucrunch since depacking is quite a bit faster than exomizer). If you really need a fast depack, you can use a bit simpler packers or even RLE.
For making your disks : C1541 or CC1541. I'd recommend to use C1541, because you can add files one at a time. When using CC1541 you have to add all the files in one go, which can make a really long and unreadable statement. However, CC1541 has some nifty tricks that C1541 doesnt have. So I'd suggest C1541 until it doesnt do the trick for you anymore.
For loading : Krill's loader. You can add and remove options to it, so it fits your purpose like a glove. |
| |
algorithm
Registered: May 2002
Posts: 705 |
I use 64Copy to add files to the D64. Notepad, ACME and WinVice for the development.
By the way, is there a raw incbin image for the Krill loader (something i can just incbin at the end of the c64's ram) |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Yes, you'd still need the cc65 toolchain to build it though.
Edit config.inc to turn the right features on/off.
Then build it like this for example:
make prg INSTALL=0800 RESIDENT=2000 ZP=f0
The build process will spit out a loader.zip containing install.prg at $0800 and loader.prg at $2000, and a loadersymbols.inc containing the entry points into the code and the ZP variables. |
| |
algorithm
Registered: May 2002
Posts: 705 |
I will need to see whether i have all the prerequisites required. Including the make utility etc. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
I would also recommend learning how to use makefiles to do stuff like this. Then you can just configure your text editor to call the makefile in your working directory and it will work no matter if you code c64 stuff or c coding for PC/Mac or whatever...
In case you start writing your own conversion scripts and stuff like that for special purposes it is also easy just to put it into the makefile just as well, i.e. you can also customize the build process for each particular project in just the right way. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Aaargh Makefiles. Used to just using notepad for C64 or PC asm. Will have a look at it later, although would prefer if there was a stand alone raw file instead of having to install all this stuff etc. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I'm in quite a hurry to get my demo finizhed to LCP, so I gave up on getting Krill's loader to work, since some of the prerequisites weren't available on Mac. So I'm glad I found Dekandence's loader, which is really easy to use and doesn't require anything to be installed. So far I have skipped packing as well. Instead I'm just making sure the code and data are stuffed closely together in the memory without too many holes. I doubt it would be much faster to pack it, since depacking takes time too. For copying files to d64 I'm using c1541, called from a shell script. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: I would also recommend learning how to use makefiles to do stuff like this. Then you can just configure your text editor to call the makefile in your working directory and it will work no matter if you code c64 stuff or c coding for PC/Mac or whatever...
In case you start writing your own conversion scripts and stuff like that for special purposes it is also easy just to put it into the makefile just as well, i.e. you can also customize the build process for each particular project in just the right way.
Yeah I'd love if it was as easy as you say, but fact is linking is the hardest, and most scarry part of c64 coding :) Atleast for me :) |
| |
Trap
Registered: Jul 2010
Posts: 223 |
Thanks for all the replies. I will look at C1541 and Exomizer.
As for Krill's loader ... it's beyond me. I'm not a C/Java dev, so 90% of the files in the release is nonsense to me. If there was some proper documentation I might have tried it out. Couldn't even find anything using Google :|
Think I'll take a look at Dekadence loader.
Thanks again for taking the time to help me. Appreciate it!
Trap |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Quote: I'm in quite a hurry to get my demo finizhed to LCP, so I gave up on getting Krill's loader to work, since some of the prerequisites weren't available on Mac. So I'm glad I found Dekandence's loader, which is really easy to use and doesn't require anything to be installed. So far I have skipped packing as well. Instead I'm just making sure the code and data are stuffed closely together in the memory without too many holes. I doubt it would be much faster to pack it, since depacking takes time too. For copying files to d64 I'm using c1541, called from a shell script.
All of the prerequisites compile out of the box on OS X. Let me know if you need any help with that. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: I'm in quite a hurry to get my demo finizhed to LCP, so I gave up on getting Krill's loader to work, since some of the prerequisites weren't available on Mac. So I'm glad I found Dekandence's loader, which is really easy to use and doesn't require anything to be installed. So far I have skipped packing as well. Instead I'm just making sure the code and data are stuffed closely together in the memory without too many holes. I doubt it would be much faster to pack it, since depacking takes time too. For copying files to d64 I'm using c1541, called from a shell script.
Why not try this packer? :) LZWVL |
| |
Digger
Registered: Mar 2005
Posts: 437 |
@Cruzer: Yay! Big up for the demo, good luck with finishing in time. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
I have also stepped into the need of packing & linking recently, I hope to release this demo soon :)
I got used with Dream Load some time ago and it is also very easy to use and customizable. Furthermore I have the problem that I often code on different computers so I cannot install stuff.
My tools: 64tass, Notepad++, Exomizer, DreamLoad, 64copy, visual Basic for Excel for making custom lookup tables / sequence of number generation.
About linking, I use VICE monitor a lot to add the needed parts of code assembled with 64tass. Most hard task is when I have to link stuff when source is not available.
I changed DreamLoad source a bit to be able to compile with 64tass and also to be able to run the loader not as a background program, thus loading only when out of irq, but I dedicate a certain amount of processor cylces to DreamLoad, after which the loader exits automatically and re-enters the next time it is triggered. In this way I can load also during demo effects that use the background program. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@Oswald: Same here. Well, maybe not scary, but at least agonizingly tedious, compared to coding effects.
@Mr.SID: Ok, guess I better take a second look at it after LCP.
@WVL: Will take a look at that too when time permits it.
@Digger: Thanx!
@Trap: Good luck with the Bonzai demo, hope we'll finally get to see some of Walt's 10+ year old unreleased parts! |
| |
Trap
Registered: Jul 2010
Posts: 223 |
still trying to wrap my head around this.
Would some kind soul be willing to share an example of a makefile for putting together a multipart demo.
I am curious to see how the whole thing is built.
Brings me on to my next question ... how do you guys handle loader code and in general main code for multipart demos? It was easy in the old days: write a routine, wait for keypress, load next part. All parts in one closed file. Today it's different and I would love to hear how people are putting stuff together.
My concerns are around memory management and interrupts. Do you have loader and music in one locked space of memory and then run the entire demo from one main interrupt routine and load the routines and graphics as needed or is there an entirely different clever way to do this? |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quoting Trapis there an entirely different clever way to do this?
I suspect there are as many clever ways as there are C64 coders. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
here's what you'd want to keep in memory at all times:
$0200 - $0400 loader & depacker & one permanent raster irq 2 play music
$0400 - ~$1600 music
$1600 - $ffff anything else |
| |
ready.
Registered: Feb 2003
Posts: 441 |
I don't know about makefile, I assemble each demo part individually then link "by hand".
About the loader, it depends a lot on how the demopart is coded.
If the main effect is running in the irq and the background program is not used, you can do "jsr loader" in the baground program, then the loader will return with an rts once all the data has been loaded.
Here:
Aurora 100%
I had the problem that both irq and background programs were used in several parts and I wanted to load inside the parts. I assigned a certain number of processor cylces to the loader, so the demo part can still run, even if a bit slower, but if the cycles stolen are few nobody cares.
To do this I start a single shot CIA2 timer in the IRQ and jump to the loader. After the CIA2 delay an NMI takes care of getting back from the loader to the IRQ and saves the loader location, so that the IRQ can jmp to it the next frame. You can easily decide how much resources the loader can use by setting the CIA2 delay.
And what Oswald said unless you have particular needs. For example in the last part of the Aurora 100% (upscroller) the music is played in the main program. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
once again I'm on packing and linking.
Usually I need to split the file I have to load into parts which are packed individually, so after compiling the file with 64tass, I load it in VICE monitor and save each part of the file separately.
Example in VICe monitor:
l"prg"0 (range $2000-$bfff)
s"prg0"0 2000 9fff
s"prg1"0 a000 bfff
then I pass the files prg0 and prg1 to Exomizer. Is there a way to split the prg file into subfiles from command line instead of using VICE?
|
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
You can use dd to split files. If you're on Unix, you already have it, on Windows you can download one of the many ports, like this one: http://www.chrysocome.net/dd
Then do:
dd if=prg of=prg0 bs=4096 count=8
dd if=prg of=prg1 bs=4096 skip=8 count=2
But I guess you'll also need start addresses in your files? In this case this will not work. |
| |
ruk
Registered: Jan 2012
Posts: 43 |
You can in fact crunch plain files with exomizer by the <filename>@<adress> syntax.
F.ex.
exomizer mem -c -l none part.bin@0x2000 -o part.exo
|
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Ah, good to know! |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting Mr. SID
dd if=prg of=prg0 bs=4096 count=8
dd if=prg of=prg1 bs=4096 skip=8 count=2
But I guess you'll also need start addresses in your files? In this case this will not work.
echo -ne "\x00\xa0" > prg1
dd if=prg of=prg1 bs=4096 skip=8 count=2 conv=notrunc oflag=append
|
| |
ready.
Registered: Feb 2003
Posts: 441 |
reading VICE docs:
6.10.1 Monitor command-line options
-moncommand FILENAME
Execute the commands from the file FILENAME in the monitor after starting up. This command line switch is mainly thought to load labels and to set breakpoints. Not all other commands are useful to be executed in this way, some may even lead to strange effects.
this comand could be useful to drive the monitor via command line, but most commands crash if executed this way :( |
| |
ready.
Registered: Feb 2003
Posts: 441 |
Finally I found a solution which solved my problem of extracting certain areas of a binary file without using VICE monitor, but an automated command line process. Googling I found this for coping part of a binary:
http://stahlworks.com/dev/index.php?tool=partcopy
and this to assign a load address, modifing the first 2 bytes (it's a command line hex editor):
http://sourceforge.net/projects/hexciting/
So, here is an extract of a batch file used for preparing the files to load taken from Ninfa/Level64:
64tass --m6502 m.txt -o 040exp
sfk165 partcopy 040exp -fromto 0x6100 0x8402 a0.part1 -yes
sfk165 partcopy 040exp -fromto 0x8802 0xb002 a0.part3 -yes
sfk165 partcopy entangled -fromto 0x0002 0x0402 a0.part2 -yes
copy /b a0.part1+a0.part2+a0.part3 041exp
sfk165 partcopy 040exp -fromto 0x8400 0x8802 046exp -yes
sfk165 partcopy 040exp -fromto 0xb000 0xda03 042exp -yes
sfk165 partcopy 040exp -fromto 0x0400 0x4002 043exp -yes
sfk165 partcopy 040exp -fromto 0x0000 0x0402 044exp -yes
sfk165 partcopy 040exp -fromto 0x4000 0x6102 045exp -yes
hexciting -v -a -r 0 2 041exp 0x00 0x00
hexciting -v -o -r 0 2 041exp 0x00 0x81
hexciting -v -a -r 0 2 042exp 0x00 0x00
hexciting -v -o -r 0 2 042exp 0x00 0xd0
hexciting -v -a -r 0 2 043exp 0x00 0x00
hexciting -v -o -r 0 2 043exp 0x00 0x24
hexciting -v -a -r 0 2 044exp 0x00 0x00
hexciting -v -o -r 0 2 044exp 0x00 0x20
hexciting -v -a -r 0 2 045exp 0x00 0x00
hexciting -v -o -r 0 2 045exp 0x00 0x60
hexciting -v -a -r 0 2 046exp 0x00 0x00
hexciting -v -o -r 0 2 046exp 0x00 0xa4
exomizer mem -c -l$e000 041exp -o 041
exomizer mem -c -l$2000 042exp -o 042
exomizer mem -c -l$2000 043exp -o 043
exomizer mem -c -l$fe00 044exp -o 044
exomizer mem -c -l$e000 045exp -o 045
exomizer mem -c -l$fd00 046exp -o 046
041, ....,046 are the compressed files to load from disk. This really boosted my work during the last months prior to X'2012, when bug fixing the linked demo disk.
|
