Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > VIC Bank @ $c000-$ffff
2013-04-03 01:00
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?
2013-04-03 04:21
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.
2013-04-03 06:01
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
2013-04-03 08:35
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.
2013-04-03 08:45
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.
2013-04-03 08:57
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.

2013-04-03 09:12
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?
2013-04-03 09:18
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.
2013-04-03 13:44
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.
2013-04-03 16:46
Count Zero

Registered: Jan 2003
Posts: 1932
Also IO1 and 2 need to be taken care of whenever cartridges are active :)
2013-04-03 17:17
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
 
... 1 post hidden. Click here to view all posts....
 
Previous - 1 | 2 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
macx
Scrap/Genesis Project
Acidchild/Padua
Guests online: 82
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Swappers
1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Violator  (9.7)
4 Acidchild  (9.7)
5 Cash  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.048 sec.