BASIC Program on Cartridge

[groepaz]

Uh. The Problem is your ancient VICE. You absolutely have to use 3.9 for proper crt support in xvic

[SparkyNZ]

Uh. The Problem is your ancient VICE. You absolutely have to use 3.9 for proper crt support in xvic

I have been trying the .crt on different versions of Vice - the ancient one and this (latest) GTK one:

I can't get it to work - below is with the "Smart" options:

This didn't work either - specific Generic and A000 options:

I've attached a .zip with both padded source images (bin.pad, prg.pad) and the 2 .crt outputs from the respective generations:

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.

Here's the version of cartconv that is being used:

Code: Select all

W:\Vic20Dev\VicRom1>cartconv --version
cartconv (VICE 3.9)

What am I doing wrong?

I've just had a look at the PAL Choplifter .crt file from the TOSEC archive. This loads into old and new VICE without any problem but the format doesn't seem to have a "VIC 20 CARTRIDGE" header at all all - it just looks like a dump of everything that should appear at A000.

[SparkyNZ]

I finally got it working! I guess I'm using "old" .crt format here since I have no header.

I had to do a few things:
1) Assemble with CBMPrgStudio -> .prg file
2) Remove the 2-byte header from the .prg file, resulting file is .raw file
3) Pad the .raw file up to 8k
4) Rename .raw to .crt
5) Loads fine into old and new Vice without error

One of things things I blindly copied was this:

>A000 10 A0 ; Reset Vector
>A002 09 A0 ; NMI Vector
>A004 41 30 C3 C2 CD ; A0CBM Signature

.A009 2C 11 91 BIT $9111 ; Acknowledge NMI

Why is the reset vector A010, Mike? Wouldn't that be in the middle of the BIT instruction?

Anyway, I changed my reset vector to A00F and seem to have struck gold:

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

I burned the raw image to my EPROM and tried it on a real Vic but that did nothing.. so looks like I have a few issues with my address decoding for the BLK5 ROM socket to sort out on my PCB design.

(mod: topic drift to hardware split off to the thread "Handling /BLKx signals on a cartridge" in the Hardware section)

[Mike]

I finally got it working! :-) I guess I'm using "old" .crt format here since I have no header.

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.

5) Loads fine into old and new Vice without error

... 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.

As groepaz already wrote, only since VICE 3.9 there is proper support for the cartridge *.crt format. Older versions of xvic were fundamentally broken in that regard. If anything, the *.crt extension merely served as placeholder/reminder to the user that the file did not have any load address nor cartridge header. Again, older VICE versions default $A000 as address to attach to, but that doesn't help for any other cartridge type (for example those with BLK3 and BLK5 populated with ROM).

So, what precise action did you take in point 5 when supplying the file to VICE?

Why is the reset vector A010, Mike? Wouldn't that be in the middle of the BIT instruction?

We're working in hex here. :P

[SparkyNZ]

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?

I attached via, "File > Attach cartridge ...", selected "Generic image..." and then my .crt file.

[Mike]

I attached via, "File > Attach cartridge ...", selected "Generic image..." and then my .crt file.

Following scenarios then apply, depending whether there is a header in the "*.crt" or not:

• "old" VICE, file without header: attach per default to $A000,
• "old" VICE, file with header: either fault due to overlength (with a 8 KB ROM), or mistake the header for ROM data (smaller ROM dump) and attach wrong stuff to $A000,
• current VICE, file without header: attach per default to $A000, and
• current VICE, file with header: works as supposed.

[groepaz]

W:\Vic20Dev\VicRom1>cartconv -t vic20 -i bin.pad -o VicRom_FromBin.crt -l a000

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)

I'll add a warning to cartconv for this case NOW. i can see how its a stumbling block

And yes, .crt support for anything but C64 is brand new (and i am still fixing the last remaining things - hopefully next release will have it all complete). You can be almost sure that a .crt file you find on the net is not actually in .crt format, but just a plain binary - i don't think there is a good source for readily converted actual crt files yet.

(mod: quote block repaired)

[SparkyNZ]

I'll add a warning to cartconv for this case NOW. i can see how its a stumbling block

Excellent, thank you - and noted. It doesn't take much to make me stumble

[Mike]

The hex number must start with 0x - "a000" will be interpreted as 0 - [...]

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.

In the VICE trunk, in 'cartconv.c', the -l parameter is parsed with strtoul() ...

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;
}

(I'd suppose the check for load_address == 0 is what you quick fixed)

... so $9800 in the slightly older version would also have been parsed as 0. I guess I was just lucky that the definition of the Rabbit cartridge's load address in 'vic20-cartridges.c' ...

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},
[...]
};

... overrode my errorneous -l parameter.

Any chance to make the -l parameter also accept "$" as hex prefix instead of "0x"?

[groepaz]

Any chance to make the -l parameter also accept "$" as hex prefix instead of "0x"?

I'm not a friend of this - requires extra code AND it is annoying to use on anything but windows.

And yes, load address really only matters for the generic cartridge type

[Schlowski]

Using 0x instead of $ would have never crossed my mind - everything 6502-related always uses $ as hex notifier.

If both notations are valid everyone could use whatever fits. I think the extra code wouldn't be that much, but that's my personal opinion. I never used cartconv and don't see me using it in the foreseeable future

[tokra]

Maybe the help-screen that pops up when you start cartconv without parameters should clarify this. RIght now it just says:

-l <addr> load address

while it could say:

-l <addr> load address (decimal, use 0x-prefix for hexadecimal, e.g. 0xc000)

[Orangeman96]

[...] it could say:

-l <addr> load address (decimal, use 0x-prefix for hexadecimal, e.g. 0xc000)

Agree 100-percent, tokra. (I have never been fully successful with cartconv.exe, and just gave up on it as a "WIP.") Sorry groepaz. -OGM

[groepaz]

Using 0x instead of $ would have never crossed my mind - everything 6502-related always uses $ as hex notifier.

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)

while it could say:

-l <addr> load address (decimal, use 0x-prefix for hexadecimal, e.g. 0xc000)

Good idea - see r45632

[Orangeman96]

[...] You'd be surprised - most command line stuff supports (only) 0x notation - for exactly the same reason. [...]

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.

At any rate, I am very much enjoying the latest version of VICE, so thanks much for it!

OGM