| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Making your own cartridge ROM
Hello!
I wonder if there is any good reference/tutorial/info text material on creating your own cart ROM (primarily in "Retro Replay format"). I never did this myself, but I am planning to do so. I know there is a special "header" ("CBM80" or something?) first of all which makes the c64 recognize that a cart is plugged in, and then there is all the bank switching stuff (there are docs from Jens Schoenfeld on that I guess), and also assemblers with special features for memory bank handling and so on (dreamass has some features in this direction, or...?). Is the "action replay" source code available somewhere (I heard that this was "floating around on the net")? I think all kind of info like this would be nice to have on http://codebase64.org
The main point here is not primarily that I wouldn't be able to figure things out from various sources of information, but rather that it would be nice to collect already existing info on this on codebase, since there isn't that much on this topic there right now.
Anyone got some info/tutorials on this topic? If there isn't any available, then I would love to see someone write a little about the requirements for making cart software on codebase. Yeah?
(By the way.. Is it just me, or do you people also get "Frantic" as one of the hotlinks on google when searching for "CSDb"? Huh? I guess I must be a very important c64 scener? ;)
//FTC
|
|
... 19 posts hidden. Click here to view all posts....
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Thank you everyone for your replies!
@WVL: The program in question is rather large (would require switching between ROM banks), and the reason for putting it into a cart would be to have as much ordinary C64 ram free as possible in order to make yet another bunch of features possible (so, not just loading it quickly from cart, even though the quick "loading" is also part of the picture here of course).
By the way.. I still wonder about assemblers.... Is there a reason for why you would need any other feature for assembling a cart ROM than some "pseudo PC" directive, like the one you use for drive code for example?
//FTC
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Thank you everyone for your replies!
@WVL: The program in question is rather large (would require switching between ROM banks), and the reason for putting it into a cart would be to have as much ordinary C64 ram free as possible in order to make yet another bunch of features possible (so, not just loading it quickly from cart, even though the quick "loading" is also part of the picture here of course).
By the way.. I still wonder about assemblers.... Is there a reason for why you would need any other feature for assembling a cart ROM than some "pseudo PC" directive, like the one you use for drive code for example?
//FTC
Not sure but when I've had ideas like this I've always thought it would be nice if $8xxx and $axxx went into separate binaries. This can easily be achieved with ca65/ld65 by choosing a file as output on the MEMORY directives in the link file instead of the ordinary "%O". |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Quote: Thank you everyone for your replies!
@WVL: The program in question is rather large (would require switching between ROM banks), and the reason for putting it into a cart would be to have as much ordinary C64 ram free as possible in order to make yet another bunch of features possible (so, not just loading it quickly from cart, even though the quick "loading" is also part of the picture here of course).
By the way.. I still wonder about assemblers.... Is there a reason for why you would need any other feature for assembling a cart ROM than some "pseudo PC" directive, like the one you use for drive code for example?
//FTC
Despite standard *=$xxxx and .offs(et) directives you don't need a lot more. Macros are really hand but this applies to any code. Directives like include and incbin or similar are also useful becouse you can easly attach binary data or have separate files for $8000 and $A000 for example. Local labels and blocks are also usefull, especially if you have a lot of loops.
Basic "copy protection" scheme is also quite easy to develop using almost any assembler as it goes likes this:
*=$8009
lda #$02
sta crash
crash: nop
|
| |
enthusi
Registered: May 2004
Posts: 675 |
AlexC, hehe.
Well why make it that complicated?
I just exomized the game, wrote a small 5 liner to copy $8000-xxxx to $0801.
It uses PSEUDOPC $0400.
The cart-reset-routine copies the "launcher" to $0400, executes it and somewhere near $0430 it says JMP $080b.
Case solved.
Of course you need the CRT header.
Ans fiddling with $01 allows you to copy beneath $8000 as well.
And yes, that is NOT useful as copyprotection at all since the raw PRG is there all the time...
;this is for a 8KB cart!!
*=$0000
.asc "C64 CARTRIDGE "
.byte $00,$00 ;header length
.byte $00,$40 ;header length
.word $0001 ;version
.word $0000 ;crt type
.byte $00 ;exrom line
.byte $01 ;game line
.byte $00,$00,$00,$00,$00,$00 ;unused
.asc "CRT TITLE"
name
.dsb ($0040-name),0
;chip packets
.asc "CHIP"
.byte $00,$00,$20,$10 ;chip length
.byte $00,$00 ;chip type
.byte $00,$00 ;bank
.byte $80,$00 ;adress
.byte $20,$00 ;length
;ROM part
;---------------------------------
*=$8000
.word launcher
.word launcher
.byte $c3 ;c
.byte $c2 ;b
.byte $cd ;m
.byte $38 ;8
.byte $30 ;0
launcher
sei
stx $d016
jsr $fda3 ;prepare irq
jsr $fd50 ;init memory
jsr $fd15 ;init i/o
jsr $ff5b ;init video
cli
;inc $d020
;jsr $e453 ;load basic vectors
;jsr $e3bf ;init basic ram
jsr start_all ;move basic prg
jmp $0400
;jsr $a68e
;jmp $a7ae
; inc $d020 only for basic
;ldx #$fb
; txs
;---------------------------------
start_all
lda $d011
and #%11101111
sta $d011
ldx #$00
sa1
lda movecode1,x
sta $0400,x
inx
bne sa1
rts
;------------------------------
movecode1
;803d here
*=$0400
movecode2
basic_move
ldx #$00
bm1
lda main_file_start,x
bm2
sta $0801,x
inx
bne bm1
inc bm1+2
inc bm2+2
lda bm1+2
cmp #$c0
bne basic_move
jmp $080b
movecode3
;---------------------------------
*=movecode1+(movecode3-movecode2)
main_file_start
.bin 2,0,"game.bin"
main_file_end
.dsb ($a000-main_file_end),0
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Sorry if I was unclear. My question was not intended to be about assemblers in general, but about assemblers with features that may be especially useful when assembling a cart ROM file. |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Quote: Sorry if I was unclear. My question was not intended to be about assemblers in general, but about assemblers with features that may be especially useful when assembling a cart ROM file.
Old Turbo Assemblers starts at $9000 so it leaves small address space for you. Turbo Macro Assembler uses memory from $8000 so it's not really suitable unless you are using version for RR (or RR the one embedded in Cyberpunx rom). You can also use Turbo Action ROM. Anyway the best option today is probably to use any cross assembler like dremass or kick.
enthusi: I like your idea - neat trick. But you don't need CRT header if you are going to burn the EPROM. Anyway using RR/Retro Replay mapper is the best option I suppose. There is interesting project regarding cartridge for c128 going on too with similar cart mapper capabilities. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Sorry for being unclear again... :)
I was of course referring to cross assemblers in this case, since testing a big cart ROM image on the real hardware during development would be... too much. :)
Btw, I added some bits and pieces of info on codebase now, from various sources. The "crt.txt", enthusis code posted here and another similar short snippet of code that I found lying around on my harddrive.
http://codebase64.org/doku.php?id=base:thirdparty
//FTC |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Frantic to conclude: I doubt there are any special functions in assemblers for cartridge development because even native ones like TA supports all requirements. It's the burner software that can be more or less helpful in the process. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Yes.. After a brief look into various assemblers (like dreamass, WLA DX, ca65) who mention cartridge programming in their docs, it seems to be mostly about providing "segments", i.e. supporting cart coding on a conceptual level. Functionally, a lot of assemblers are of course able to pull the stunt of having several pieces of code in the binary with the same start address... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
personally i think dreamass is the only assembler that has actually useful support for building cartridges.... segments alone do not help much. |
| Previous - 1 | 2 | 3 - Next |
