| |
Magnar
Registered: Aug 2009
Posts: 61 |
Kickasm: loadbinary to d000-ffff area = crash
Hi,
I am using the following statement in kickasm:
.const INTER_TEMPLATE = "C64FILE, Bitmap=$0000"
.var interpicture = LoadBinary("C:\test_only_bitmap_6000-7230.prg", INTER_TEMPLATE)
.pc = $ea00 "Inter_Bitmap" inter: .fill interpicture.getBitmapSize(), interpicture.getBitmap(i)
Compiling gives a correct output of:
Memory Map
----------
$ea00-$fc30 Inter_Bitmap
Writing file: C:\test.prg
But - When I run this test.prg together with a code to show the bitmap, the whole program crashes.
if I simply relocate the load of this bitmap to say $8000 instead, then everything works fine.
I believe the problem is that the loadbinary function doesn't use lda#$35 sta$01 or something so that the load actually writes directly in the ROM area instead of the RAM area of e000-ffff.
How do I get pass this issue?
Cheers |
|
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
I very much doubt that Kickass has anything to do with how C64 behaves when you load a program over the I/O area.
Load the program with some fastloader which allows loading in the $Dxxx RAM or exomize your binary. |
| |
Magnar
Registered: Aug 2009
Posts: 61 |
No, it is the .fill command with kickasm that somehow doesn't work.
It seems not to have anything to do with the loading of the finished compiled prg. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
its your code/loading stuff, its not kickass. kickass doesn't even know about $01, it just delivers a binary. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
also, why dont you just:
.pc = $ea00 "bitmap"
.import c64 "C:\test_only_bitmap_6000-7230.prg" |
| |
Magnar
Registered: Aug 2009
Posts: 61 |
@burglar, Because I am a very-unskilled-newbie :)
However, I still think it is kickasm that doesn't work properly. Maybe there is a updated version.. |
| |
ruk
Registered: Jan 2012
Posts: 43 |
It is not KickAssembler's fault. Like others say, KickAssembler just delivers a binary.
What I suspect happens is, that when you attach your test-program, the memory map looks something like this:
Memory Map
----------
$0801-$0900 Bitmap viewer
$ea00-$fc30 Inter_Bitmap
Writing file: C:\test.prg
This test.prg will span from $0801-$FC30, with the gap $0900-$e9ff zero-filled. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
no matter how hard you want it to be, but it's not a kickass bug! ;)
try packing the .prg that kickass spits out, if the resulting prg is max 202 blocks, it'll work. |
| |
Magnar
Registered: Aug 2009
Posts: 61 |
hmm.. maybe the program oversize 202 blocks and that is the issue? |
| |
Magnar
Registered: Aug 2009
Posts: 61 |
Yea, that was the issue... the total compiled prg file became 247 blocks in size when I had the bitmap up in the e000-ffff area :)
When relocate it to $c700, total compiled file becomes $0801-d930 = 211 blocks, which works to load and run.
Output pass
Music play: $1003
Music init: $1000
Memory Map
----------
$0801-$0809 Unnamed (SYS$2000 for autorun)
$1000-$1b9b Music
$2000-$22a8 Demo code
$3100-$3c07 Bitmap1
$3c18-$3fff Main_ColorRAM
$4000-$5f3f Main_Bitmap
$6000-$63e7 Main_ScreenRAM
$63ff-$643f Spritebank
$c700-$d930 Inter_Bitmap
Writing file: C:\test.prg
Running this file within Vice2.4 works fine, 211 blocks. |
| |
Magnar
Registered: Aug 2009
Posts: 61 |
Actually, I find this as a issue more with Vice now than anything else.
Why shouldn't I be able to load the whole memory as a prg straight into Vice without having this block restrain?
In a final result of a demo of course I can pack or load things in smaller chunks with krill loader (say first load bitmaps as separate files then load democode music etc and start it).
But, when I am coding this; I would like to see the end result straight away without having to put up a linking for all smaller things that should be loaded or packed.
Maybe I am just doing this differently because I am not a experienced coder...
But in my favour; A commandline switch for Vice allowing to load longer prg files would be excellent. |
... 7 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
