Screen memory mapping VIC-20

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Screen memory mapping VIC-20

Baltissen, GJPAA (Ruud)

Hallo allemaal,

 

 

For my own curiosity plus to be able to enhance it in the future I am disassembling the ROM of the Diagnostic Cartridge for the VIC-20.

 

I found this in: http://www.zimmers.net/cbmpics/cbm/vic/memorymap.txt

 

1000-1DFF    4096-7679     User Basic area

1E00-1FFF    7680-8191     Screen memory

 

NOTE: When additional memory is added to block 1 (and 2 and 3), the

KERNAL relocates the following things for BASIC:

 

1000-11FF    4096-4607     Screen memory

1200-?       4608-?     User Basic area

 

9400-95FF   37888-38399        location of COLOR RAM with
                                additional RAM at blk 1
9600-97FF   38400-38911        Normal location of COLOR RAM

 

 

I used my auto disassembler on the ROM and found this:

 

 

.eq BLK1                               = $0400                 ; 1 KB memory expansion

; ... $07FF

 

                lda          #$00

                ldx          #$05

A_A040:                                                                               ;                                                               [A040]

                sta          BLK1+$11,X

 

                dex

                bne        A_A040

 

We know the cartridge has (at least) 1 KB of RAM on board and the above is the proof because it is used.

 

 

.eq D_1E00                         = $1E00

.eq D_1F00                         = $1F00

.eq D_9600                         = $9600

.eq D_9700                         = $9700

 

 

J_A04F:                                                                                ;                                                               [A04F]

                ldx          #$00

                stx          BLK1+$1A

A_A054:                                                                               ;                                                               [A054]

                lda          #$06

                sta          D_9600,X

                sta          D_9700,X

 

                lda          #$20

                sta          D_1F00,X

                sta          D_1E00,X

 

                inx

                bne        A_A054

 

The above means data is written to the NORMAL location for the screen memory and colour RAM. But the text says that this RAM is only used if there is NO extra RAM on board. Did I miss something or is the text wrong?

 

 

Extra, I found a typo in the text:

0332-0333    818-819       Link to save RAM             [F685]
0334-033B    820-827       ??
*003C-03FB   828-1019      Cassette buffer
0400-0FFF    1024-4095     3K expansion RAM area

 

The *003C should be *033C. A bit further the correct address is mentioned (033C-03FB   828-1019 Cassette buffer. ...) so therefore I assumed it is an error. This text is in fact an email but IMHO correctness is more important than authenticy.

 

 

Met vriendelijke groet / With kind regards, Ruud Baltissen

 

www.Baltissen.org

 

 

 

 

 

 



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

Marko Mäkelä
On Fri, Jul 07, 2017 at 10:11:06AM +0000, Baltissen, GJPAA (Ruud) wrote:
>I found this in: http://www.zimmers.net/cbmpics/cbm/vic/memorymap.txt
>>NOTE: When additional memory is added to block 1 (and 2 and 3), the
>>KERNAL relocates the following things for BASIC:

>I used my auto disassembler on the ROM and found this:

Well, does the ROM run any BASIC code? Of course programs are free to
use the available 1 kilonibble color RAM in any way they please. Only
the BASIC and KERNAL are using one half (or actually 22*23=506 nibbles)
of it. Actually, if you configure the screen to have very many
characters per line and very many lines, you should be able to use
almost all of the color RAM, especially on the 6561 (PAL) where the
visible picture area of the video signal is larger than on the 6560
(NTSC).

Hmm, is Pasi Ojala still on this list? He probably implemented some
crazy CPU-intensive graphics modes for the Vic-20, programmatically
changing the VIC-I registers on every raster line. That would easily use
all of the color RAM even with a smaller picture area.

>The above means data is written to the NORMAL location for the screen
>memory and colour RAM. But the text says that this RAM is only used if
>there is NO extra RAM on board. Did I miss something or is the text
>wrong?

You missed the above. Actually, if you duplicate some of the KERNAL
reset code, you can let BASIC think that there is no extra memory even
if you had it there starting at BLK1 ($2000). You could also type some
POKEs after RESET to "downgrade to unexpanded" while having a 3k or 8k+
RAM expansion plugged in.

>The *003C should be *033C.

Yes, definitely, the tape buffer is at $33C. Even without knowing this,
it is kind of obvious, because the memory map is in ascending order of
memory address.

On a related note, I wonder how many cartridges there are that invoke
the BASIC interpreter to run code straight from the ROM? I have seen at
least one such cartridge for the Vic-20. With this trick, you will be
able to use all of the precious internal RAM from $1000 to $1dff or
$1200 to $1fff for BASIC variables while keeping the program code in the
ROM. It is a bit like the separation of program memory and RAM on
Harvard architectures like the Atmel AVR: you would want to keep
constant in program memory, not waste the small RAM by copying into it.

On the Commodore 64, this trick would make little sense, because the
cartridge ROM would make internal RAM or ROM inaccessible, especially in
those configurations that you would need when using the BASIC
interpreter. Maybe you could have a simple cartridge that keeps the
BASIC code at $8000-$9fff and the BASIC variables at $0800-$7fff, but
the only "benefit" might be copy protection.

        Marko

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Screen memory mapping VIC-20

Baltissen, GJPAA (Ruud)
Hallo Marko,


> You could also type some POKEs after RESET to "downgrade to unexpanded" while having a 3k or 8k+ RAM expansion plugged in.

That rang the bell, I indeed missed something. The first thing the cartridge does is programming the VIC chip. And it does it by using the standard values, read: the values for an unexpanded VIC. Thank you!

But there is still another small mystery: the cartridge writes several times a value to $9800 aka I/O block 2. But the cartridge doesn't contain any I/O at all. But as said: only write actions. Maybe some I/O was foreseen but not implemented?


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

Anders Carlsson
In reply to this post by Baltissen, GJPAA (Ruud)
Ruud wrote:

> NOTE: When additional memory is added to block 1 (and 2 and 3),
>
> .eq BLK1 = $0400 ; 1 KB memory expansion
>
> The above means data is written to the NORMAL location for the screen
> memory and colour RAM. But the text says that this RAM is only used
> if
> there is NO extra RAM on board. Did I miss something or is the text
> wrong?

IMHO, your auto disassembler mixes up the terms:

RAM1 = $0400 - $07FF
RAM2 = $0800 - $0BFF
RAM3 = $0C00 - $0FFF

BLK1 = $2000 - $3FFF
BLK2 = $4000 - $5FFF
BLK3 = $6000 - $7FFF
BLK5 = $A000 - $BFFF

It means if you add memory to BLK1 (usually 8K, perhaps you can add
less than that?), the changes in memory structure happen but the
diagnostic cartridge adds memory to RAM1, which does not prompt the
changes.

The reason the memory layout changes at all is to ensure that BASIC has
a continuous memory, plus that the VIC-I chip can only access onboard
memory, not what is on the expansion bus. For a long while there was a
misunderstanding about the VR/W signal on the bus that it would be for
video R/W but it is not, it is just a bad naming convention of the
signal.

So everything works as expected here. You're adding RAM to the 3K area
which normally makes BASIC start at 1025 instead of 4097, retains the
screen matrix at 7680 and colour memory at 38400. Actually the colour
memory is located either at 37888 or 38400 depending on whether the
location of the screen matrix is divisible by 1024 or not. It means even
on an unexpanded VIC-20 if you would move the screen matrix to 7168, the
colour memory follows along and vice versa if you would add 8K and
reposition the screen matrix on an "odd" 512 byte boundary, the colour
memory starts at 38400.

Best regards

Anders Carlsson


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

Pasi 'Albert' Ojala
In reply to this post by Marko Mäkelä
On 07.07.2017 13:39, Marko Mäkelä wrote:

> On Fri, Jul 07, 2017 at 10:11:06AM +0000, Baltissen, GJPAA (Ruud) wrote:
>> I found this in: http://www.zimmers.net/cbmpics/cbm/vic/memorymap.txt
>>> NOTE: When additional memory is added to block 1 (and 2 and 3), the
>>> KERNAL relocates the following things for BASIC:
>
>> I used my auto disassembler on the ROM and found this:
>
> Hmm, is Pasi Ojala still on this list? He probably implemented some
> crazy CPU-intensive graphics modes for the Vic-20, programmatically
> changing the VIC-I registers on every raster line. That would easily
> use all of the color RAM even with a smaller picture area.
Yes, I'm stll lurking here. :D

The ROM relocates the screen for the sole reason of providing contiguous
RAM for BASIC.

The memory map changes depending on whether you have 3k or 8k(up to 24k)
expansions connected.  Note that the VIC-I cannot see any of the
external RAM.

With just 3k added the start of BASIC changes and the screen stays put.
With 8k added, the screen moves to the start of the RAM, regardless of
the presence of the 3k expansion. With 8k+ added the 3k expansion is not
used for BASIC programs, but you could use it (PEEK/POKE) from your program.

I don't think I have changed the location of the color memory on the fly
though.

www.iki.fi/a1bert/Dev/ or www.iki.fi/a1bert/Pu-239/

-Pasi


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Screen memory mapping VIC-20

Baltissen, GJPAA (Ruud)
In reply to this post by Anders Carlsson
Hallo Anders,


> IMHO, your auto disassembler mixes up the terms:

Oops, it did indeed but, being the programmer, I am to blame of course.
Thank you for this pointer!


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org




De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
1�,j�j���a�����^q��i��ɚ�X��X��
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

Pasi 'Albert' Ojala
In reply to this post by Anders Carlsson
On 07.07.2017 14:12, Anders Carlsson wrote:
> For a long while there was a misunderstanding about the VR/W signal on
> the bus that it would be for video R/W but it is not, it is just a bad
> naming convention of the signal.
As far as I remember off-hand, the VR/W is indeed the VIC-I R/W signal.
The problem is that the cartridge port only carries the 6502 databus,
not the part of the bus that it shares with VIC-I. I.e. during a VIC-I
access the cartridge databus is separated from the video databus.

-Pasi


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

Anders Carlsson
In reply to this post by Pasi 'Albert' Ojala
Pasi 'A1bert' Ojala wrote:

>> That would easily use all of the color RAM even with a smaller picture
>> area.
> I don't think I have changed the location of the color memory on the fly
> though.

I think it would require double buffering of the screen matrix, as those two
go hand in hand. In multi colour mode, the four colours basically are:

1. Colour memory, individual for each character
2. Background colour, normally static for the entire screen
3. Border colour, ditto
4. High nybble of the volume register, ditto

In Pasi's picture viewer, at least the background, border and high nybble
would be updated on each raster line instead of being static for the entire
screen. I suppose if you have enough CPU time you could update the colour
memory too, or double buffer the screen matrix and switch the colour memory
for at least one more colour.

I think in the very latest VIC-20 graphics modes, tricks like these and more
have already been taken. It is a matter of how much expansion RAM and CPU
time one wants to invest on an effect like that.

Best regards

Anders Carlsson


       Message was sent through the cbm-hackers mailing list
smf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

smf
In reply to this post by Marko Mäkelä
On 07/07/2017 11:39, Marko Mäkelä wrote:
> Maybe you could have a simple cartridge that keeps the BASIC code at
> $8000-$9fff and the BASIC variables at $0800-$7fff, but the only
> "benefit" might be copy protection.

And load time of course. You might be able to make a rom appear at $c000
by invoking ultimax mode dynamically, which would give you a 4k basic
program with nearly 38k data.

There was a hack for basic that allowed 60k by using the rams under
roms. That might be possible to utilise too.

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

Michał Pleban
Hello!

smf wrote:

> And load time of course. You might be able to make a rom appear at $c000
> by invoking ultimax mode dynamically, which would give you a 4k basic
> program with nearly 38k data.

There is no ROM at $C000 in Ultimax mode, only at $8000-$9FFF and
$E000-$FFFF.

Also, IIRC, in Ultimax mode, all memory disappears except the first 4K?

Regards,
Michau.

       Message was sent through the cbm-hackers mailing list
smf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

smf

This thread seems to disagree.

http://www.lemon64.com/forum/viewtopic.php?t=37410&sid=b7b3b3cd36a079f721ecbbd125c558e5


On 07/07/2017 21:11, Michał Pleban wrote:
And load time of course. You might be able to make a rom appear at $c000
by invoking ultimax mode dynamically, which would give you a 4k basic
program with nearly 38k data.
There is no ROM at $C000 in Ultimax mode, only at $8000-$9FFF and
$E000-$FFFF.

smf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

smf

specifically...

almost... in ultimax mode the pla generates chip selects for: 
- internal ram ($0000-$0fff) 
- internal i/o ($d000-$dfff) 
- external roml ($8000-$9fff) 
- external romh ($e000-$ffff) 

all other areas can still be used by an external extension, but you have to decode the address and generate a chip select "manually" then.


On 07/07/2017 21:14, smf wrote:
This thread seems to disagree.

http://www.lemon64.com/forum/viewtopic.php?t=37410&sid=b7b3b3cd36a079f721ecbbd125c558e5


On 07/07/2017 21:11, Michał Pleban wrote:
And load time of course. You might be able to make a rom appear at $c000
by invoking ultimax mode dynamically, which would give you a 4k basic
program with nearly 38k data.
There is no ROM at $C000 in Ultimax mode, only at $8000-$9FFF and
$E000-$FFFF.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

Michał Pleban
Hello!

smf wrote:

> all other areas can still be used by an external extension, but you have
> to decode the address and generate a chip select "manually" then.

Well yes, it this sense you can indeed put whatever you want at any
memory location, at the expense of building your own address decoding
circuit.

Regards,
Michau.


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Screen memory mapping VIC-20

Jim Brain
In reply to this post by Pasi 'Albert' Ojala
On 7/7/2017 7:08 AM, Pasi 'A1bert' Ojala wrote:
On 07.07.2017 14:12, Anders Carlsson wrote:
For a long while there was a misunderstanding about the VR/W signal on the bus that it would be for video R/W but it is not, it is just a bad naming convention of the signal.
As far as I remember off-hand, the VR/W is indeed the VIC-I R/W signal. The problem is that the cartridge port only carries the 6502 databus, not the part of the bus that it shares with VIC-I. I.e. during a VIC-I access the cartridge databus is separated from the video databus.

-Pasi


      Message was sent through the cbm-hackers mailing list

It is, but it is a preferred signal to use in lieu of CR/W.  I believe VR/W is gated with PHI, and so is a cleaner signal to use.


JIm


-- 
Jim Brain
[hidden email] 
www.jbrain.com
Loading...