Re: BASIC Program on Cartridge
Posted: Fri Apr 04, 2025 8:26 am
Uh. The Problem is your ancient VICE. You absolutely have to use 3.9 for proper crt support in xvic
The Commodore Vic 20 Forum
http://www.sleepingelephant.com/ipw-web/bulletin/bb/
http://www.sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?t=11257
I have been trying the .crt on different versions of Vice - the ancient one and this (latest) GTK one:
Code: Select all
W:\Vic20Dev\VicRom1>cartconv -t vic20 -i bin.pad -o VicRom_FromBin.crt -l a000
Input file: bin.pad
Output file: VicRom_FromBin.crt
Conversion from binary format to VIC20 Generic VIC20 Cartridge .crt successful.
W:\Vic20Dev\VicRom1>cartconv -t vic20 -i prg.pad -o VicRom_FromPrg.crt
Input file: prg.pad
Output file: VicRom_FromPrg.crt
Conversion from binary format to VIC20 Generic VIC20 Cartridge .crt successful.
Code: Select all
W:\Vic20Dev\VicRom1>cartconv --version
cartconv (VICE 3.9)
Why is the reset vector A010, Mike? Wouldn't that be in the middle of the BIT instruction?
Code: Select all
*=$a000
BYTE $0F, $A0 ; Reset vector - ACTUAL START
BYTE $09, $A0 ; 'RESTORE key vector
BYTE $41, $30, $C3, $C2, $CD ; A0CBM Signature
; A009
BIT $9111 ; Acknowledge NMI
JMP $FF56 ; End NMI
; ACTUAL START
; A00F
NOP
JSR $FD8D ; RAMTAS - INITMEM
LDA #$10 ; Force BASIC into
STA $0282 ; unexpanded RAM
LDA #$1E ; ...
STA $0284 ; ...
STA $0288 ; ...
JSR $FD52 ; RESTOR
LDA #$C2 ; Disable
STA $0314 ; STOP key
JSR $FDF9 ; INITVIA - and interrupts
JSR $E518 ; INISK - initialise VIC, screen and pointers
CLI
start
INC $900F
jmp start
There is no "old" *.crt "format" involved in this. You are just attaching a raw memory dump as cartridge in VICE. Of course that is entirely possible even with the current VICE builds. In the absence of any further information from the user, VICE assumes the file is a cartridge image at $A000 (but you can tell VICE it is otherwise), which makes your file work as cartridge. This didn't buy you anything, however.SparkyNZ wrote:I finally got it working! :-) I guess I'm using "old" .crt format here since I have no header.
... please do clearly differentiate between loading and attaching as cartridge. In the context of the discussion here, loading shall mean any action from the user that transfers a file from either a tape image, a disk image or PC directory into RAM, be it manually via LOAD or via the autostart procedure of VICE. Attaching as cartridge strictly means going through the "File > Attach cartridge ..." menu, selecting a file there, and before that, (probably) specifying to VICE where the file should be attached to a write-only(!) memory dump.5) Loads fine into old and new Vice without error
We're working in hex here. :PWhy is the reset vector A010, Mike? Wouldn't that be in the middle of the BIT instruction?
I attached via, "File > Attach cartridge ...", selected "Generic image..." and then my .crt file.Mike wrote: ↑Sat Apr 05, 2025 3:15 am via the autostart procedure of VICE. Attaching as cartridge strictly means going through the "File > Attach cartridge ..." menu, selecting a file there, and before that, (probably) specifying to VICE where the file should be attached to a write-only(!) memory dump.
..
So, what precise action did you take in point 5 when supplying the file to VICE?
Following scenarios then apply, depending whether there is a header in the "*.crt" or not:SparkyNZ wrote:I attached via, "File > Attach cartridge ...", selected "Generic image..." and then my .crt file.
The hex number must start with 0x - "a000" will be interpreted as 0 - which will produce a cartridge that does not work (you also see it in your screenshot)W:\Vic20Dev\VicRom1>cartconv -t vic20 -i bin.pad -o VicRom_FromBin.crt -l a000
I was not aware of that either, and in another thread, I used cartconv (of the r45603) with "-l $9800" to create the minimon.crt file. That file works without issues, and a cross-check with "-l 0x9800" produces a *.crt file that is binary identical. Phew.groepaz wrote:The hex number must start with 0x - "a000" will be interpreted as 0 - [...]
Code: Select all
case 'l':
{
char *endptr = NULL;
checkarg(arg);
load_address = (int)strtoul(arg, &endptr, 0);
if (strlen(arg) != (endptr - arg)) {
fprintf(stderr, "ERROR: invalid characters in number '%s'.\n", arg);
exit(-1);
}
if (load_address == 0) {
fprintf(stderr, "WARNING: load address is 0, are you sure?\n");
}
return 2;
}
Code: Select all
const cart_t cart_info_vic20[] = {
[...]
{0, 0, CARTRIDGE_SIZE_2KB, 0x0800, 0x9800, 1, CRT_CHIP_ROM, CARTRIDGE_VIC20_NAME_RABBIT, "rabbit", save_regular_crt},
[...]
};
I'm not a friend of this - requires extra code AND it is annoying to use on anything but windows.Any chance to make the -l parameter also accept "$" as hex prefix instead of "0x"?
You'd be surprised - most command line stuff supports (only) 0x notation - for exactly the same reason. And the few things that do not are a terrible annoyance once you try to eg use a makefile written on windows on another OS ($ donates a shell variable on *nix, so "$1234" will turn into a blank most likely) - which is why i am not a friend of this (the extra code alone would be tolerable indeed)Using 0x instead of $ would have never crossed my mind - everything 6502-related always uses $ as hex notifier.
Good idea - see r45632while it could say:
-l <addr> load address (decimal, use 0x-prefix for hexadecimal, e.g. 0xc000)
I totally get it, groepaz. If memory serves, the "0x" notation may actually be tied to "80x" (potentially the rationale for not using "$" in the first place, and why "everything" nowadays uses the "0x" convention), although I must admit I am not 100-percent certain.