RAM/ROM addressing in the C64
IQ65535
Hope these questions don't look too obvious... I'm trying to learn more
about the C64
I know the C64 has 64kb RAM and 20kb ROM while the 6510 can only address
64kb so to "see it all" some "mechanism" must be used.
I wonder what exactly happens when you turn on the computer.
1) The ROM contents are copied in system RAM and are available for
reading purposes unless you switch them out.
or
2) Nothing is copied nowhere, the machine sees all the ROM by default
while you can write to the RAM to the same addresses where ROM is
located, unless you switch the ROM out thus you can both read and write.
or none of the above...?
In any case it is then possible to keep a graphic page (e.g. for a game)
or some other data under the ROM space and then reading them when needed
by dinamically switching in/out the ROMs? Was this technic (or something
like this) commonly used within games in the old days?
GB
Corin Talkobt
Location $01 indicates which section of memory should be mapped as ROM
or RAM.
When the computer is turned on there are two sections of ROM that appear
and stay. The top 4k are the kernel; then another 4k below that (after
the $c000 "free-space" and $d000 i/o block ) for the basic interpreter.
Yes, the VIC chip only sees the RAM so it is possible to put the video
under the ROM. However, it makes accessing it for changes a bit of a
pain. Take a look at the $01 address to know how to flip the memory in
and out ( recommended only in ML with interrupts off ) and also a look
at the VIC registers governing which bank and address the video is at (
forget the numbers ).
Peter van Merkerk
news:Ve4Ub.3282$UF1....@bignews6.bellsouth.net...
> The Commodore 64 ( as well as the C128 ) uses a layered architecture.
> Location $01 indicates which section of memory should be mapped as ROM
> or RAM.
>
> When the computer is turned on there are two sections of ROM that appear
> and stay. The top 4k are the kernel; then another 4k below that (after
> the $c000 "free-space" and $d000 i/o block ) for the basic interpreter.
It is 8Kbytes for the kernal ($E000 to $FFFF) and 8Kbytes for the BASIC
interpreter ($A000 to $BFFF).
> Yes, the VIC chip only sees the RAM so it is possible to put the video
> under the ROM.
The VIC does see the character ROM, even in places not seen by the
processor. Thanks to the PLA chip the VIC sees memory differently than the
processor.
> However, it makes accessing it for changes a bit of a
> pain. Take a look at the $01 address to know how to flip the memory in
> and out ( recommended only in ML with interrupts off ) and also a look
> at the VIC registers governing which bank and address the video is at
> forget the numbers ).
If ROM is enabled processor writes to ROM areas bleed through to the
underlying RAM memory. So it is possible to copy ROM memory to RAM and then
bank out the ROM's from BASIC. This makes it possible to change the BASIC
keywords. I once made a dutch translation of the BASIC keywords. Because
BASIC keywords are tokenized listings of existing BASIC programs were in
dutch too.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Peter van Merkerk
news:4020C36A...@IFYOU.CAN...
>
> Hope these questions don't look too obvious... I'm trying to learn more
> about the C64
> I know the C64 has 64kb RAM and 20kb ROM while the 6510 can only address
> 64kb so to "see it all" some "mechanism" must be used.
Don't worry; the question isn't too obvious because the memory subsystem of
the C64 isn't obvious. It is understandable you are confused.
> I wonder what exactly happens when you turn on the computer.
>
> 1) The ROM contents are copied in system RAM and are available for
> reading purposes unless you switch them out.
No, but you can do that yourself if you wanted to.
> 2) Nothing is copied nowhere, the machine sees all the ROM by default
> while you can write to the RAM to the same addresses where ROM is
> located, unless you switch the ROM out thus you can both read and write.
That is correct.
> or none of the above...?
>
> In any case it is then possible to keep a graphic page (e.g. for a game)
> or some other data under the ROM space and then reading them when needed
> by dinamically switching in/out the ROMs?
The VIC chips sees memory differently than the processor. The PLA chip
makes this magic possible; it monitors who is accessing the bus (VIC or
processor) and enabled/disables ROM's accordingly. The VIC chip never sees
the kernal and BASIC ROM's even when they are enabled (for the processor).
OTOH the VIC chip always sees the character ROM even when the character ROM
is not visible to the processor. So you can store graphics below the kernal
ROM and show them on the screen while at the same time the kernal routines
are still accessible for the processor. The I/O lines of the 6510 processor
(controlled via $01) determine what the processor sees: RAM, Kernal ROM,
Basic ROM, Char ROM and/or I/O.
> Was this technic (or something
> like this) commonly used within games in the old days?
That is very likely.
IQ65535
Peter van Merkerk wrote:
> So you can store graphics below the kernal
> ROM and show them on the screen while at the same time the kernal routines
> are still accessible for the processor. The I/O lines of the 6510 processor
> (controlled via $01) determine what the processor sees: RAM, Kernal ROM,
> Basic ROM, Char ROM and/or I/O.
That's what I was wondering, thanks for clarifying. I've found a C64 memory
map, useful indeed, I see ROMs can be switched in/out by turning on/off
specific bits at $0001. The best thing I can think of at first (for games) is
to unload the basic and use the first 48k for code (or it's 46k? I see a lot of
things located in the first 2k, color memory for hires too if I'm not wrong)
and the higher 16k as video memory, is that correct?
BTW a few questions more arise: a bitmapped hires page is 320x200x1bit = around
8K and the video chip accesses 16K at a time. This bitmapped graphics can be
stored in RAM at $E000-$EFFF beneath the kernal ROM. Plus there's another 4kb
($C000-$CFFF) that I can use for the code (the VIC-II doesn't mind if I place
code in there right?) or fill with other things the VIC-II may need such as
redefined characters or sprites. What about the I/O area at $D000-$DFFF? Seems
the most critical to me as if I perform a write I'm actually writing, say, to
VIC or SID registers rather than to RAM.... better leave that alone?
> > Was this technic (or something
> > like this) commonly used within games in the old days?
>
> That is very likely.
eventually, it is possible to use that with basic too? E.g. a basic game within
the 38 kb of space for basic programs and using redefined characters stored,
say, under the kernal.
GB
Peter van Merkerk
>
> Peter van Merkerk wrote:
>
> > So you can store graphics below the kernal
> > ROM and show them on the screen while at the same time the kernal
routines
> > are still accessible for the processor. The I/O lines of the 6510
processor
> > (controlled via $01) determine what the processor sees: RAM, Kernal
ROM,
> > Basic ROM, Char ROM and/or I/O.
>
> That's what I was wondering, thanks for clarifying. I've found a C64
memory
> map, useful indeed, I see ROMs can be switched in/out by turning on/off
> specific bits at $0001. The best thing I can think of at first (for
games) is
> to unload the basic and use the first 48k for code (or it's 46k? I see a
lot of
> things located in the first 2k, color memory for hires too if I'm not
wrong)
> and the higher 16k as video memory, is that correct?
Normally programs start from $0800; below that you have screen memory (1K),
some buffers, pointers, stack and other stuff for internal administration
of the kernal and basic. If you don't use kernal routines you program may
use most of the lower 2Kbytes. The stack of the processor is hardwired to
$0100 - $01FF, so unless you code doesn't use subroutines and doesn't push
processor registers on the stack, you cannot use that area.
> BTW a few questions more arise: a bitmapped hires page is 320x200x1bit =
around
> 8K and the video chip accesses 16K at a time. This bitmapped graphics can
be
> stored in RAM at $E000-$EFFF beneath the kernal ROM. Plus there's another
4kb
> ($C000-$CFFF) that I can use for the code (the VIC-II doesn't mind if I
place
> code in there right?) or fill with other things the VIC-II may need such
as
> redefined characters or sprites.
> What about the I/O area at $D000-$DFFF? Seems
> the most critical to me as if I perform a write I'm actually writing,
say, to
> VIC or SID registers rather than to RAM.... better leave that alone?
As seen from the processor this area can be Char ROM, I/O (VIC, SID, CIA's
and color memory) or RAM. So if you intend to use that area make sure you
select the right memory configuration first.
At $1000 -$1FFF and $9000-$9FFF the VIC always sees the Char ROM; those
areas cannot be used for bitmap graphics, sprite data, screen memory or an
alternative character set.
> > > Was this technic (or something
> > > like this) commonly used within games in the old days?
> >
> > That is very likely.
>
> eventually, it is possible to use that with basic too? E.g. a basic game
within
> the 38 kb of space for basic programs and using redefined characters
stored,
> say, under the kernal.
Could be, but that would also mean that your screen memory has to be in the
upper 16 KByte as well, since the VIC can only address 16K at a time (in
this case that would be $C000-$FFFF). Note that if you cannot use
read-modify-write techniques on graphics located below ROM from BASIC, that
memory is as far as BASIC is concerned write-only memory (WOM?). If you
move video memory to the upper 16 KByte, you free up 1K at the bottom; you
could let your BASIC program start at $0400 with a poke.
BTW. it has been about 14 years ago since I did serious coding on the C64,
I'm relying on memory only (which is in my case notoriously unreliable) so
what I said may not be entirely accurate.
I think you will find the VIC article interesting:
http://www.minet.uni-jena.de/~andreasg/c64/vic_artikel/vic_article_1.htm
IQ65535
Peter van Merkerk wrote:
> Could be, but that would also mean that your screen memory has to be in the
> upper 16 KByte as well, since the VIC can only address 16K at a time (in
> this case that would be $C000-$FFFF). Note that if you cannot use
> read-modify-write techniques on graphics located below ROM from BASIC, that
> memory is as far as BASIC is concerned write-only memory (WOM?).
mmm... sounds correct, but for something like a graphic adventure which needs
just a static drawing maybe it is still useful, place the graphics under the
basic without losing the basic.
> If you
> move video memory to the upper 16 KByte, you free up 1K at the bottom; you
> could let your BASIC program start at $0400 with a poke.
that's ok
> BTW. it has been about 14 years ago since I did serious coding on the C64,
> I'm relying on memory only (which is in my case notoriously unreliable) so
> what I said may not be entirely accurate.
:-)))
> I think you will find the VIC article interesting:
> http://www.minet.uni-jena.de/~andreasg/c64/vic_artikel/vic_article_1.htm
I gave a look at it, interesting though a bit confusing, I also found some more
info on Mayhem UK.
As far as I've been able to see a simple way to proceed could be:
1) set the higher 16k as video memory (49152-65535) by POKE 56576,--- screen
memory is now at 49152+1024 and it's 1K
2) instruct the VIC to get character information at "2048" that is 49152+2048
by POKE 53272,--- and define your own char set
3) claim that 1k for basic (starting at $0400, 39k for code) or unload the
basic (47k for code)
4) the 8k under the kernal are still available for hires graphics and I didn't
mess with the I/O area (yet)
Hope this is not too far from the truth... but I still have to see how to
manage the colors.
GB
Maciej Witkowiak
> 2) Nothing is copied nowhere, the machine sees all the ROM by default
> while you can write to the RAM to the same addresses where ROM is
> located, unless you switch the ROM out thus you can both read and write.
2) with clarification - when you write, you always write to RAM (except I/O
area). The only difference between ROM banked in or out is what CPU 'sees'
upon read.
> In any case it is then possible to keep a graphic page (e.g. for a game)
> or some other data under the ROM space and then reading them when needed
> by dinamically switching in/out the ROMs? Was this technic (or something
> like this) commonly used within games in the old days?
It is possible to keep data under ROM space and switch them on/off when
required, but you cannot keep the data that is meant to be actually visible
(e.g. currently visible bitmap) under ROM and have that ROM active at the same
time. You would see garbage - VIC will read data from ROM, not RAM.
ytm
--
Najlepsza sygnatura to brak sygnatury.
IQ65535
Maciej Witkowiak wrote:
> It is possible to keep data under ROM space and switch them on/off when
> required, but you cannot keep the data that is meant to be actually visible
> (e.g. currently visible bitmap) under ROM and have that ROM active at the same
> time. You would see garbage - VIC will read data from ROM, not RAM.
>
> ytm
>
Now this is confusing... from what I read around it looks like if the VIC doesn't
care about RAM or ROM, for instance if I select the higher 16k block ($E000-$EFFF)
the VIC should be able to access that RAM regardless of what the 6510 sees. Is
this false? Indeed I tried a simple program that plots a sinus. If the base
address for hires bitmapped graphics is at location 8192 (bank 0, highest half)
then it draws a sinus made of dots. If the address is at location 57344 (the last
8k of the whole memory) it plot a sinus of garbage! So is this area useless if I
wanted to write a game and stil want to use the kernal, even once the drawing is
complete everytime I switch the kernal on it will turn into garbage?
On the other hand I was able to place a new charachter set at $c000 and it seemed
to work.
GB
Franz Kottira
> It is possible to keep data under ROM space and switch them on/off when
> required, but you cannot keep the data that is meant to be actually visible
> (e.g. currently visible bitmap) under ROM and have that ROM active at the same
> time. You would see garbage - VIC will read data from ROM, not RAM.
Sorry, Maciej, but as Corin and Peter already explained, the VIC
always will see the RAM behind BASIC and KERNAL, and not the ROM, no
matter if RAM or ROM is aktive for the Processor.
In C= Hacking Issue 7
http://www.ffd2.com/fridge/chacking/c=hacking7.txt there is an
interesting artikel "hiding kilobytes" by Marko Mäkelä, deskribing the
memory configurations.
Franz
Maciej Witkowiak
> Sorry, Maciej, but as Corin and Peter already explained, the VIC
My mistake, I'm sorry for spreading foul propaganda.
:)