How to assemble a bigger (>8 KB) cartridge image?

[MrSterlingBS]

Hi at all,

I Hope this is the right post.

I dont know how i can create a cart stub with more than 8k.
Normally i used the code from the ChibiAkumas examples.

Code: Select all

 * = $A000
        dw ProgramStart
        dw ProgramStart
        db $41,$30,$C3,$C2,$CD        ;ROM Header
ProgramStart:

If there is a post with an explanation.
I would be grateful for the link.

Best regards
Sven

[Mike]

I dont know how i can create a cart stub with more than 8k.

The address range of BLK5 ($A000..$BFFF) is exactly 8 KB, you can't fit a bigger cartridge image in there, as it would 'reach' into the BASIC ROM beginning at $C000. Bigger cartridges require you to define a storage layout in the other available blocks, BLK1..3, each of which map in another 8 KB as well. How this is done entirely depends on the used (cross-)assembler.

Code: Select all

 * = $A000
        dw ProgramStart
        dw ProgramStart
        db $41,$30,$C3,$C2,$CD        ;ROM Header
ProgramStart:

This isn't exactly a BASIC stub, what the thread you originally posted in is about. A BASIC stub usually contains a minimal BASIC program with a SYS statement to call the machine code directly behind it in memory (so the user doesn't need to remember those SYS addresses - a simple RUN then suffices to start the program). What you posted here is a cartridge autostart signature. The first word actually contains the entry called upon power-on/reset, the second word contains the address of the NMI entry.

Is there a specific reason you want to package a program into a 'oversized' cartridge image?

[MrSterlingBS]

Hi Mike,

I use the tools from ChibiAkumas. And for me it works fine with the cartridge.

About the question „how to assamble a bigger (> 8KB) cartridge“ is just the how can i do this.


BR
Sven

[Mike]

I use the tools from ChibiAkumas.

TBH, it is the first time I heard about this forum. I took a quick peek: it has just four threads/YT videos specifically about the VIC-20, and is even spreading half-truths ("the VIC-20 can't do bitmap graphics", which just repeats Wikipedia nonsense), and merely two-digit numbers of threads for other computers/consoles. There are more ample resources around.

And for me it works fine with the cartridge.

You should be more specific in that regard. What cartridge? Is that a project of your own?

About the question „how to ass[e]mble a bigger (> 8KB) cartridge“ is just the how can i do this.

As I wrote, you earn the extra "problem" that the cartridge ROM contents are not anymore in one piece within the address space of the CPU. This needs extra preparations/assistance from the assembler, to distribute routines and data over the two disjunct ranges $2000..$7FFF and $A000..$BFFF. It could also be done manually, by assembling the cartridge ROM in those two pieces, but even shifts more responsibility to you, the programmer. Some parts, like bigger data structures that depend on continuous addressing couldn't anyway be split between BLK1..3/BLK5.

Whatever tools the other forum recommends, these tools should come with documentation that explains how a binary can be assembled to two or more distinct address ranges. For example, the cc65/ca65 tools use the linker and *.cfg files to assign memory ranges.

Sorry I can't be of more help this time.

[MrSterlingBS]

Hi Mike,

okay i understand. I will take a look at the other assemblers.

And i think like you, ChibiAkumas is not the biggest expert for the 6502 and VIC,
but his videos, source code and tools are good for me at the moment.

If i am a better 6502/VIC coder in the future, maybe, i think i change the tool.


BR Sven

6502 coding is fun!

[Mike]

I will take a look at the other assemblers.

Yes, please definitely do that! See below:

ChibiAkumas is not the biggest expert for the 6502 and VIC, but his videos, source code and tools are good for me at the moment.

I also made a quick look of the YT video regarding bitmap graphics.

I am sorry, but this video is a strain to watch. They're approaching the VIC-20 hardware with a mindset belonging to platforms with a Z80 CPU. The few parts of the source code concerning the VIC-20 are buried within lots of preprocessor #ifdefs for other platforms, which is not helpful to get an overview. In the name of "portability", they arrive at the lowest common denominator, and what they tell about VIC-20 graphics has been superceded by improved methods (shown here in Denial) that have been around for more than one decade. For API level, OS conformant bitmap graphics on the VIC-20, MINIGRAFIK and its assorted tools are still State of the Art.

If i am a better 6502/VIC coder in the future, maybe, i think i change the tool.

You should probably make the switch immediately, before your current tool set lets you strand on an island, so to speak. When it comes to (cross-)assemblers, ACME, xa65, ca65, DASM ... for any of them you can ask questions here, and you will get an answer. And there is nothing wrong about taking other people programs, dissecting them, and then transferring the findings to new, own code.

It should go without saying, that one good way to learn programming is actually doing it. Preferably with reliable sources and examples. One book I seriously recommend is "VC-20 intern" from Data Becker, in German. It contains lots of info about the VIC-20 hardware and software, about the memory map (zeropage, OS workspace, application memory, I/O registers, etc.) and a fully commented listing of the ROM (BASIC and KERNAL). Over at Forum64, they provide the "F64 Wolke" where that book can be downloaded as *.pdf (you'll need to do a few introductory postings though to be granted access).

[chysn]

I'm not sure what tools you're using, but xa has this cool trick for generating padding:

Code: Select all

; Start code at Block 1
* = $2000
Welcome: etc...

end_of_code:
* = $a000
.dsb (*-end_of_code)
* = $a000

.word Welcome       ; Welcome Screen
.word Restart       ; NMI Address
.byte $41,$30,$c3,$c2,$cd

Restart: etc...

MaybeAdditionalCode: etc...

It works like this... the label end_of_code is defined as (of course) the end of your code. The next line sets the program counter to the start of Block 5. The next line puts a number of data bytes equal to $a000 minus end_of_code. If no additional parameters are provided to the .dsb pseudo-op, it just uses $00 for the padding. This will pad over character ROM, etc., but that doesn't matter. The next line resets the program counter to $a000, and you add the auto-start data. What you wind up with is a binary file that's up to 40K, with an 8K "hole" in it.

The auto-start code will be in the right place, as long as the emulator starts the image at $2000.

For my cartridge game The Archivist (which is 24K), I used a shell script to chop up the program and lay it out for an MCes Jolly Cartridge, but that's only required for physically burning an image onto a 27C512 chip.

[MrSterlingBS]

Thank you very much for your help.
My tools are Not so common here in the Forum and i like to Change it. What do you mean with xa?
WaX Assembler?

[chysn]

Thank you very much for your help.
My tools are Not so common here in the Forum and i like to Change it. What do you mean with xa?
WaX Assembler?

For cross assembly (development for VIC on a modern computer), I use Andre Fachat's xa: https://www.floodgap.com/retrotech/xa/

Different folks will recommend different ones, but I got used to xa, and it gets my job done. And it's still actively maintained, which is a huge bonus. It nicely supports my shell-script-oriented toolchain and build process. There's also an accompanying disassembler, dxa, but I've only used that a handful of times.

Lots of people like CBM Studio, but I'm on a Mac so I can't use it (or... at least it's not a compelling reason to virtualize Windows).

Somewhere around here, there are one or more discussions about cross assemblers.

wAx, on the other hand, is a native assembler/disassembler. I usually use it for two things: (1) debugging code that I already wrote with xa, and (2) whipping up proofs-of-concept that I want to try right now. When I post code examples in Denial, I'll usually bash them out with wAx first to avoid dumb errors, even if they're just a few lines.