| |
robo
Registered: Nov 2012
Posts: 9 |
VIC Bank @ $c000-$ffff
I'm trying to code a game and got into trouble with free memory space.
So I want to use RAM behind I/O and kernal ROM for graphics data storage.
I know how to manage that $01 and $dd00 things, but how can I upload data to that area >$cfff?
I'm using kernal routines for loading and don't know how to do it another way, so I will have to switch RAM off.
Is it possible since writes to ROM locations are sent to RAM?
I guess at least this will not work for $d000-$dfff.
If I'm totally wrong, how would you do it? |
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Kernal loading usually cannot load to RAM at $D000-$DFFF. Exceptions are for example the Action Replay loader. But to maintain compability, you should always assume that loading into the I/O area RAM is not possible and you have to use other means to access that RAM, for example by packing your PRG or by loading the data somewhere else and copy it to the I/O space.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
VIC does not regard $01 settings it will always read from ram, $01 only changes things from the CPU's perspective. Action Replay loader is backwards compatible with the kernal, but if you dont have it the kernal is not able to load to $dxxx. Best thing to do is Graham's suggestion, load somewhere else and copy to final place afterwards (minimal extra time compared to kernals sluggishness).
http://codebase64.org/doku.php?id=base:memory_management |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Easiest thing to do is to pack the whole thing using exomizer or pucrunch or so, and then just let the depacker code take care of the copying of data to the upper memory range for you. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
If you load your file manually byte-by-byte, ie. using CHRIN and not LOAD, you can switch $01 value in between each byte to store it to the RAM underneath I/O space.
|
| |
Monte Carlos
Registered: Jun 2004
Posts: 359 |
As we have seen shortly (Nocode-slide) you can indeed load to $d000-$dfff, but you do not load to ram but to the io registers. If you load valid register values there should be no problem loading over that area and also to $e000-$ffff(writes are going into ram). Some registers are even suitable to store data which can be copied to ram below $d000-$dfff later on (for example sprite coordinates, bgcolor nibbles, color ram nibbles). But be aware of mirror registers! Temporary screen mess should be not a problem.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: As we have seen shortly (Nocode-slide) you can indeed load to $d000-$dfff, but you do not load to ram but to the io registers. If you load valid register values there should be no problem loading over that area and also to $e000-$ffff(writes are going into ram). Some registers are even suitable to store data which can be copied to ram below $d000-$dfff later on (for example sprite coordinates, bgcolor nibbles, color ram nibbles). But be aware of mirror registers! Temporary screen mess should be not a problem.
How do one guarantee that writing to $dd00 doesn't screw up loading? How did you do it TLR? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: As we have seen shortly (Nocode-slide) you can indeed load to $d000-$dfff, but you do not load to ram but to the io registers. If you load valid register values there should be no problem loading over that area and also to $e000-$ffff(writes are going into ram). Some registers are even suitable to store data which can be copied to ram below $d000-$dfff later on (for example sprite coordinates, bgcolor nibbles, color ram nibbles). But be aware of mirror registers! Temporary screen mess should be not a problem.
one other question arises, whats up with mirrored VIC/SID/CIA registers? and I guess mirroring changes from machine to machine, so that demo might not be compatible with all machines. |
| |
robo
Registered: Nov 2012
Posts: 9 |
Thanks a lot, guys!
I think I will do as cadaver suggested and slightly modify graham's byte-by-byte file-reading routine from codebase.
Maybe I'll upload a demolevel in a few weeks. |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Also IO1 and 2 need to be taken care of whenever cartridges are active :)
|
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: one other question arises, whats up with mirrored VIC/SID/CIA registers? and I guess mirroring changes from machine to machine, so that demo might not be compatible with all machines.
I guess its the same for C64's but not for a C128 |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting JackAsserHow do one guarantee that writing to $dd00 doesn't screw up loading? How did you do it TLR? I assumed CLK and DATA (and ATN) would be the same state after fetching a byte. A quick check of ACPTR ($EE13) indicates that is true.
So basically I just replicate that setup in every mirror. Timers are set to $FFFF and IRQs and timers disabled.
Quoting Oswaldone other question arises, whats up with mirrored VIC/SID/CIA registers? and I guess mirroring changes from machine to machine, so that demo might not be compatible with all machines. On all stock C64s it should be the same. On the C128 it is different IIRC (is that true for C64 mode?) but as long as there are no (too evil) side effects on those additional mirrors it could work.
Quoting Count ZeroAlso IO1 and 2 need to be taken care of whenever cartridges are active :) I write those all 00 as I assumed it would be the "safest". Verified working with AR in vice.
In hindsight I should have made the load address $00ae though to force cartridges to use kernal load. Now you need to do OFF. |
