| |
TWW
Registered: Jul 2009
Posts: 545 |
Cartridge - C64 Game System, System 3 Memory Management
Does these cartridges allow memory management in terms of normal ROM/RAM/IO? I.E. Can I use the RAM under $a000-$bfff, $d000-$dfff and $e000-$efff?
Reason I ask i coz I made a frame for this cartridge in CRT format and it loads and executes fine. However I am only able to access ROM and IO.
http://vice-emu.sourceforge.net/vice_15.html#SEC319 |
|
... 12 posts hidden. Click here to view all posts....
|
| |
soci
Registered: Sep 2003
Posts: 480 |
Quoting TWWAlright GPZ, I will check out the source when I sober up, meanwhile, here is the simple frame-setup (I checked it with a hex-editor and it's identical headers for the cartridge and the chips to the original described in the docs): Simple is this not. Now that you've learned how to do it the hard way, I'd like to suggest a different solution this the problem.
Create a raw 512 KiB file instead and let cartconv to do the container for you:
cartconv -i in.bin -o out.crt -t gs -n "cartname"
ps.: Cartconv is part of VICE, just like c1541. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Dumb Question. What are you initialising $00 to? If it is set to inputs, then you will always be $37 on the pins. I really recommenced you put a proper C64 boot up sequence in the code and then test.
I too believe this is the cause. Classic mistake. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
indeed, its a bit silly that they didnt do that in the kernal before the CBM80 check :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Maybe due to circumstantial or even technical reasons. Leaving the CPU port to all-inputs in order not to break whatever would be connected in the final design, before cartridge code takes over, or something like that. Or it's really just a silly oversight. :) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quoting sociQuoting TWWAlright GPZ, I will check out the source when I sober up, meanwhile, here is the simple frame-setup (I checked it with a hex-editor and it's identical headers for the cartridge and the chips to the original described in the docs): Simple is this not. Now that you've learned how to do it the hard way, I'd like to suggest a different solution this the problem.
Create a raw 512 KiB file instead and let cartconv to do the container for you:
cartconv -i in.bin -o out.crt -t gs -n "cartname"
ps.: Cartconv is part of VICE, just like c1541.
Pro tip. Don't bother forcing the assembler to make the right sized file and let cart conv do it for you with -p ;) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I actually think it's nice that the cartridge hook starts up with as little setup before it as possible. That enables all sorts of hacks to the hardware without changing the kernal. |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Yes, strangely enough I initially did set the DDR for the MPU. However when I did, the cartridge ROM would not appear at all.
For sake of good order I added the boot sequence as follows:
.pseudopc CartridgeLocation {
.word CartridgeColdStart
.word CartridgeWarmStart
.byte $c3, $c2, $cd, $38, $30 // CBM80
CartridgeColdStart:
CartridgeWarmStart:
stx $d016
jsr $fda3
jsr $fd50
jsr $fd15
jsr $ff5b
cli
jsr $e453
jsr $e3bf
jsr $e422
ldx #$fb
txs
sei
lda #$35
sta $01
!: dec $d020
jmp !-
}
The boot sequence is followed nicely (basic screen comes up) but once I manipulate $01 to #$35 (Try to access LO/HIRAM), the Cartridge ROM disappears and the border color cycle snippet at the end is never executed but instead a BRK from RAM below Cartridge ROM happens.
EDIT: I could relocate the code and access HI/LORAM from outside Cartridge ROM off course... |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting TWWYes, strangely enough I initially did set the DDR for the MPU. However when I did, the cartridge ROM would not appear at all.
Maybe you just set the DDR before $01? The correct sequence is:LDA #$37
STA $01
LDA #$2F
STA $00
When doing cartridge setup you really should have thoroughly examined the kernal startup code first so you know what's originally there. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting TWWThe boot sequence is followed nicely (basic screen comes up) but once I manipulate $01 to #$35 (Try to access LO/HIRAM), the Cartridge ROM disappears and the border color cycle snippet at the end is never executed but instead a BRK from RAM below Cartridge ROM happens.
EDIT: I could relocate the code and access HI/LORAM from outside Cartridge ROM off course...
This seems obvious? You run code in ROM and try to switch out the ROM and it doesn't work.
If you need to read RAM below ROM you need to use a small accessor somewhere. Writing is possible without switching out ROM though. Even $d000-$dfff can be written using $33->$01. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quoting TWW
The boot sequence is followed nicely (basic screen comes up) but once I manipulate $01 to #$35 (Try to access LO/HIRAM), the Cartridge ROM disappears and the border color cycle snippet at the end is never executed but instead a BRK from RAM below Cartridge ROM happens.
EDIT: I could relocate the code and access HI/LORAM from outside Cartridge ROM off course...
So then it works as expected.
You pull the ROM out from under the CPU and put the RAM there instead, its hits a $00 stored in the RAM, it breaks. That is the correct behaviour.
You want to be able to access the RAM and execute code from the ROM, can't do it. ROM at memory or RAM at memory. But you can write to the RAM at any time. |
| Previous - 1 | 2 | 3 - Next |
