understanding $d018
herbsman
$d018, can someone try to explain it to me
:))
i need to know how to change the bit that controls the picture
locations in memory...
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Jim Butterfield
<ivasujon...@skolan.lysekil.se.invalid> wrote:
>i really cant figure out how to change bitmap locations with
>$d018, can someone try to explain it to me
>:))
>i need to know how to change the bit that controls the picture
>locations in memory...
Long long ago, I wrote a program called SCREENMAP64 that does all the
detail work for you. There are several things that need to be
adjusted in order to move the screen RAM to a new location, including
telling the Kernal where to find the new screen. I thought that it
would be useful and instructive to have a program work them all out
for you (including doing sprites).
I'll be happy to email SCREENMAP64 to anyone who would like it
(there's also a SCREENMAP128) ... and, of course, it can be freely
added to archives or download sites.
--Jim
Jason
> i really cant figure out how to change bitmap locations with $d018,
> can someone try to explain it to me :))
$D018 only handles character set, screen and bitmap pointing for a 16K
bank and is split into two nybbles, the upper four bits tell the VIC-II
where the screen starts (simply multiply by 1K and that's where it
starts) and the lower four control where the charset is coming from (it
ignores the lowest bit, the bank is skipped through in steps of 2K since
that's how long charsets are).
If the VIC-II is in bitmap mode, only the highest bit of the lower four
is important, if it's set ($x8) then the upper half of the bank is used,
otherwise the lower half is chosen. The screen handling for the colour
map remains the same as before.
If you want a charset at $2000 and a screen at $0800, then set $D018 to
$28, the $2x means "the third block of 1K in from the start of the bank"
and the $x8 means the "eighth block of 1K in" ($x9 will do the same as
$x8, remember that lower bit doesn't get noticed).
The highest place you can put the charset with just $D018 is $3800 and
the highest screen at $3C00 and because the bitmap has to be a block of
8K, only $0000-$01FF and $2000-$3FFF are available (even then, only the
second one can be *used*).
If you want to use another bank of 16K, $DD00's lowest two bits control
which bank is in use and, for some odd reason, it works like this:
%11 = bank 0 ($0000-$3FFF [1])
%10 = bank 1 ($4000-$7FFF)
%01 = bank 2 ($8000-$BFFF [1])
%00 = bank 3 ($C000-$FFFF)
When the VIC-II is looking at bank 1, anything you now tell $D018 is
offset into that bank, so the previous example of $28 is now pointing to
a screen at $4800 and a font at $6000. Switch to bank 2 and the values
are offset to start at $8000 ($28 in $D018 will point to $8800 and $A000
for screen and font respectively) and it's obviously $C000 onwards for
bank 3 (and $28 now points to $C800 and $E000).
Examples:
If you want to have a font in bank 3 with the screen at $E000 and the
font itself at $C000, you need to set the lowest three bits of $DD00 to
%00 and put $80 into $D018.
LDA $DD00
AND #$FC
STA $DD00 ;No AND is needed, we want those lowest two bits clear.
LDA #$80
STA $D018
If you want to have a bitmapped screen in bank 1 with the colour at
$4000 and the image at $6000, you need to set the lowest three bits of
$DD00 to %10, put $08 into $D018 and throw the VIC-II into bitmap mode.
LDA $DD00
AND #$FC
ORA #$02
STA $DD00
LDA #$80
STA $D018
LDA #$3B
STA $D011
Hope that helps (and I'm writing in a hurry from memory, there *may* be
errors so someone please proof it! =-)
[1] There is a ROM font stored in banks 0 and 2, starting 4K in and
finishing 4K later (there are shadows of both the upper and lower case
fonts). No matter what data is under that space, only the standard C=
character set shows up when you point the VIC-II at it.
--
Jason =-)
_______________________________________________________________________
TMR / / / / / / / /\
/ /__/ / / /__/ / / / /__/ Email: t...@c64.org / /
/ /\_/ / /__ / / / / __// TMR_C0S on IRC / /
/ /__/ / / / / / / / / / http://www.cosine.demon.co.uk / /
/_____/_____/_____/__/__/__/_____/_____________________________________/ /
\_____\_____\_____\__\__\__\_____\_____________________________________\/
Groepaz
looks ok for me jason ;=P
one should add a common trick with using $d018 / $dd00 ... the essential for a
whole lot of (advanced?) fld/fli type of things
imagine you have setup a raster-irq that is supposed to (among other things)
store some value to $do18 and $dd00 each rasterline.... like:
...
lda tabd018,x
sta $d018
lda tabdd00,x
sta $dd00
...
however, just forget the above method again, since its nothing more than cycle
(and memory) wasting overkill! instead we would just do:
...
lda tabd018dd00,x
sta $d018
sta $dd00
...
voila.... 3 bytes and 4 (?! err...my mind ;=P) cycles saved per loop iteration.
BUT! err... storing the same value to $d018 AND $dd00 ????? well, thats all the
trick about it ;=) Its somewhat hard to explain, but its easily to grasp if you
make yourself a table of all possible videoram/character(bitmap) configurations
and the corrosponding values for $d018 and $dd00. write these values in BINARY.
then look at the values.... keep in mind $dd00 only the lowest 2 bits are of
interest for vic-issues ... $d018 doesnt care about em ;=)
gpz
--
........................................................
/^\
\ /
ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL
/ \
........................................................
.--.--.--.----..--.--.--.-----.----.
C=64 / / / / . / . . / . / . /\
/ / /__/ /__/ / / / / / / / /
PC / / / /\_/ / / / __ / / / /
/ / / / / // / / / / / / / /
PSX / / / / / // / / / / / / / /
/__/__/__/__/ //__/__/__/_____/__/__/ /
\__\__\__\__\/ \__\__\__\_____\__\__\/ Groepaz
........................................................
.. http://fly.to/hitmen-c64 ............................
..... the hitmen c64 home page .........................
.. http://www.hitmen-console.org .......................
..... hitmen psx section ...............................
.. http://start.at/hitnav64 ............................
..... biggest c64 link collection around ...............
.. http://fly.to/hitmen-groepaz ........................
..... my little personal page ..........................
........................................................
Cameron Kaiser
>Long long ago, I wrote a program called SCREENMAP64 that does all the
>detail work for you. There are several things that need to be
>adjusted in order to move the screen RAM to a new location, including
>telling the Kernal where to find the new screen. I thought that it
>would be useful and instructive to have a program work them all out
>for you (including doing sprites).
There is a program on the December 1986 Gazette disk called Video Setup
that does something similar. Same program? You also wrote it, IIRC. :-)
--
Cameron Kaiser * cka...@stockholm.ptloma.edu * posting with a Commodore 128
personal page: http://calvin.flactem.com:3001/~spectre/ >> temporary <<
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/~spectre/cwi/ **
Arndt Dettke
herbsman <ivasujon...@skolan.lysekil.se.invalid> schrieb in im
Newsbeitrag: 0248d5b0...@usw-ex0101-007.remarq.com...
> i really cant figure out how to change bitmap locations with
> $d018, can someone try to explain it to me
GO64! issue #10 (ML) and #11 (BASIC) will reflect on it...
--
Arndt
+------------------------------+
+ Arndt Dettke +
+ GoDot C64 Image Processing +
+ http://www.GoDot64.de +
+ sup...@GoDot64.de +
+------------------------------+
herbsman
like to have a first screen with a bitmap then a second with a mc
bitmap picture, is there enought memory to have both of them in
there? or do i have to load it after or something?
:)
Jason
> lda tabd018dd00,x
> sta $d018
> sta $dd00
> ...
>
> voila.... 3 bytes and 4 (?! err...my mind ;=P) cycles saved per loop
> iteration.
Oooh! *That* is sneaky! =-)
Jason
> if i would like to store 2 bitmap pictures in a one file program,
> like to have a first screen with a bitmap then a second with a mc
> bitmap picture, is there enought memory to have both of them in
> there? or do i have to load it after or something?
There are six possible places you can wedge a bitmap in RAM, $2000,
$4000, $6000, $A000, $C000 and $E000. In practise, because each bitmap
needs a 1,000 byte screen as well, if you use $4000 for the bitmap the
RAM at $6000 can't be used 'cos you'll need to use it for the screen.
Apart from the other data you're using, there's nothing to stop you
having four pictures at $2000, $6000, $A000 and $E000 in the same file.
Alternatively, there's nothing to stop you displaying one picture and
then copying another over the top of it from another part of RAM either.
Jason
> I tried to play around, putting #$18 in $d018 displayed my non-
> multicolor bitmap hires picture at $2000, then i would figure
> since the offset is same if i switched bank to 1 then it would
> be at $6000, but apperantly i was wrong or?
No, you're right but the colour map will now be at $4400 so you need to
move that an' all.
Matthew W. Miller
>Apart from the other data you're using, there's nothing to stop you
>having four pictures at $2000, $6000, $A000 and $E000 in the same file.
Indeed, that's exactly how the old animation of Max Headroom looking back
and forth works. Memory-wasteful, but CPU-efficient. :)
raster = 53266
ci2pra = 56576
c2ddra = 56578
* = $104e
startovr lda #$ff
sta pointr
mainloop inc pointr ; update pointer
lda #3 ; this is some sort of ingeniously subtle
sta c2ddra ; technique for causing the animation to slow
ldx pointr ; down, speed up, slow down, et cetera
cpx #4 ; looped through all four frames?
beq startovr ; if so, start over
lda ci2pra ; set memory bank
and #%11111100
ora data,x
sta ci2pra
ldx $a2
ldy #0
pausloop dey ; kill time
bne pausloop
dex
bne pausloop
sync lda raster ; sync with video signal to prevent shearing
bne sync
beq mainloop
data .byte 3,2,1,2 ; data for frames: 3=bank 0, 2=bank 1, 1=bank 2
--
Matthew W. Miller -- ma...@infinet.com