| |
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. |
| |
iAN CooG
Registered: May 2002
Posts: 3194 |
"Why shouldn't I be able to load the whole memory as a prg straight into Vice without having this block restrain?"
Because Vice is emulating a C64 normally, where you would find the same problem.
Anyway just use Settings/autostart settings/inject to ram. Commandline
x64 -autostartprgmode 1 your.prg
Besides using pucrunch on the test prg takes 1 second. make a bat or some script to compile AND crunch, it's not that hard. |
| |
6R6
Registered: Feb 2002
Posts: 245 |
Yes, What Ian said about Pucrunch.. thats the best option. |
| |
enthusi
Registered: May 2004
Posts: 677 |
Expect this to happen many many times with a highlevel 'IDE' such as Kickassember...
It became bad with ACME already and its auto mem-fill ;-)
Please use Input-Assember or AR monitor and store to tape.
;-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
there are generally 3 ways to deal with this problem:
a) the proper way, pack your program (easy enough to call pucrunch in your makefile). then it will not only work in vice but also on the real thing (which you want to use for testing every now and then anyway)
b) the lazy way, use a fastloader cartridge (in vice or the real thing) that handles loading over i/o. grahams "final replay" is a good choice for x-dev (as it handles the virtual devices nicely)
c) cheating. set vice autostart to "inject to ram" which then makes it possible to load whatever with no sideeffects.
i can only warn you though that exclusively using c) will likely generate problems which are a pain to find and fix later when you are moving to the real thing. my personal recommendation is a) exclusively. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: there are generally 3 ways to deal with this problem:
a) the proper way, pack your program (easy enough to call pucrunch in your makefile). then it will not only work in vice but also on the real thing (which you want to use for testing every now and then anyway)
b) the lazy way, use a fastloader cartridge (in vice or the real thing) that handles loading over i/o. grahams "final replay" is a good choice for x-dev (as it handles the virtual devices nicely)
c) cheating. set vice autostart to "inject to ram" which then makes it possible to load whatever with no sideeffects.
i can only warn you though that exclusively using c) will likely generate problems which are a pain to find and fix later when you are moving to the real thing. my personal recommendation is a) exclusively.
I always separate basic init + music as a separate file and the rest in another file. For the stand-alone runnable case I link the first file + music + the rest and crunch into a prg. For the release build I simply copy the last file to the release direction (where proper demo linking takes place). This gives me both a stand alone executable that works on the real thing + a package that is good for linking the demo. This is all done in the makefile with the magic use of segments, the dd-command, and pucrunch.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
that sounds almost exactly like what i do (except i use some ifdef stuff and not dd =)) |
| |
johncl
Registered: Aug 2007
Posts: 37 |
Or if you are into tapes use e.g. enthusi's great tapgen loader generator which loads a bitmap and some music. The bitmap data is actually placed under the kernal at $e000- , and when its finished loading (and de-exomized) you have the bitmap there available as well in your program. :)
But generally I just exomize stuff which works fine with a binary that has data under the IO/Kernal. |
