| |
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 |
|
... 10 posts hidden. Click here to view all posts....
|
| |
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. |
| Previous - 1 | 2 - Next |
