| Posted By
Fuzzweed
on 2024-11-14
19:50:21
|  Scrolling a bitmap
Is there any advantage to using hardware scrolling on a bitmap (vertically), because at some point I have to copy the whole screen manually anyway? Just trying to figure out speed vs complexity.
Draw one pixel line, copy screen down one pixel. Repeat.
This has some slightly more complex line draw routine, but overall simpler loop.
or
Draw 8 pixel lines.
hardware scroll x 7
Copy screen down 8 pixels
Repeat.
This has easy draw routine, but slightly more complex loop.
Any general preference?
|
|
Posted By
Csabo
on 2024-11-14
20:09:30
| Re: Scrolling a bitmap
In bitmap mode, you can use the $FF1A/$FF1B registers to shift the address which specifies the top of the bitmap. With this, you can avoid having to copy the bitmap data altogether. The color map will not be shifted though, for that you have to implement an AGSP effect.
|
|
Posted By
Fuzzweed
on 2024-11-15
03:27:28
| Re: Scrolling a bitmap
OK, so colour is not an issue with what I'm doing, so no problem there, we can forget that.
I can't find anything in the Programmers Guide about 1A and 1B (apart from it exists and I have 9 bits relevant).
My base address is in FF12 of course, so what is 1A 1B doing exactly. Is this an offset to FF12? Or something different. Is there a guide / code example on here?
Edit.
So I know from reading posts on other subjects it is probably way more complicated than this, but broadly it's something like force it to 40 before it builds the screen so it thinks it's already filled one line?
|
|
Posted By
Csabo
on 2024-11-16
08:13:34
| Re: Scrolling a bitmap
Sorry, I missed your reply. It's fairly simple to use, you can set it at any time. Here's a basic example of scrolling the entire bitmap up:
org $1001-2
dw $1001
ptr = $D0
db $24,$40,$00,$00,$DE,$31,$2C,$31,$3A,$E2,$31,$2C,$31,$36,$30,$2C
db $39,$39,$2C,$39,$39,$2C,$2C,$2C,$2C,$2C,$31,$31,$3A
db $9E
db "0"+(start/1000)%10,"0"+(start/100)%10,"0"+(start/10)%10,"0"+start%10
db 0,0,0
start sei
;
lda #0
sta ptr
sta ptr+1
;
loop lda #$03
cmp $FF1D
bne *-3
lda #$02
cmp $FF1D
bne *-3
cmp $FF1D
beq *-3
;
lda ptr
sta $FF1B
lda ptr+1
sta $FF1A
;
lda ptr
clc
adc #40
sta ptr
lda ptr+1
adc #0
sta ptr+1
;
jmp loop
;eof
You can download the PRG and run it to see it in action. Adding 40 to the offset is exactly one line, but you can replace that with any number.
This, combined with soft scrolling via $FF06 would allow you to scroll the entire screen, all you have to do is make sure you draw the new part that's being scrolled in.
|
|
Posted By
Spektro
on 2024-11-16
21:48:31
 | Re: Scrolling a bitmap
Sorry but why do you have to wait for the raster beam three times (first line 3, then line 2, and again line 2)? Is it because of the raster line's 8th bit ($ff1c) or is there some other reason?
|
|
Posted By
Csabo
on 2024-11-16
22:40:55
| Re: Scrolling a bitmap
Exactly, but really because it's a hastily put together hack  I just wanted it to work as a proof-of-concept, and setting up $FFFE/$FFFF would have been a lot more code.
|
|
Posted By
Murphy
on 2024-11-18
08:46:12
| Re: Scrolling a bitmap
@Fuzzweed ff1a-1b is fetched before each character line. So what you set there will be used by TED from the next character line. If you do it before the first character line, it will scroll the entire bitmap.
A bitmap will always fit within a given 8kb area, and ff1a-1b is an internal counter that is 10 bits and wraps around.
If your bitmap uses the $2000-$3fff area, instead of displaying the addresses after $3fff, TED starts to show the memory from $2000.
So you can scroll the bitmap itself simply by increasing the value of ff1a-1b and set it at the beginning of each frame. And all you have to do is to update one column of the bitmap with the new data. Due to ff07 scrolling, this column will be covered by the border.
With the HSP effect, you can also scroll the color memory (with only 0-39 character shift), but that requires much more precise timing and double buffer for the color memory. But this way you can completely eliminate the copying of the color attributes.
Bitmap Scroll without HSP
https://drive.google.com/file/d/1nPN9tINZoz-D8mIJ0OVW7dHWr4Lcl3V-/view?usp=sharing
Bitmap Scroll with HSP
https://drive.google.com/file/d/1ffHcdckmX0vlbXFWcnFp9uS6257V59jq/view?usp=sharing
Actually both versions are good from a CPU point of view, because if you copy the color memory you still have 8-16 frames to copy, but obviously HSP is faster.
|
|
Posted By
Fuzzweed
on 2024-11-21
05:30:49
| Re: Scrolling a bitmap
haha!! for the people that told me to use yape not vice, I think this feature is is one major reason you are correct
Hello again. I have two small questions on this.
1) is the ff1a/b loop at 1000 (visible characters) or at 1024 (logical characters)
2) what is the adc/sbc maths for horizontal scrolling? (I don't need it just now but it's bothering me not quite being able to figure it out)
|
|
Posted By
Murphy
on 2024-11-21
08:05:50
| Re: Scrolling a bitmap
1024, the counter is 10 bit wide. You can also display that $c0 bytes, which is not visible from the bitmap by default.
Just inc your own 16 bit counter and write it to $ff1b/1a before the screen starts.
The lower byte is the $ff1b. and $ff1a only uses the lower 2 bits, so you can write anything to the upper bits.
|
|
Posted By
Fuzzweed
on 2024-11-21
08:37:12
| Re: Scrolling a bitmap
Thank you!
|
|
Posted By
Fuzzweed
on 2024-11-29
12:01:08
| Re: Scrolling a bitmap
One more question on this.
Does the counter loop infinitely, or does it (forced) reset to zero.
I.e if I bump the counter once the bitmap would stay offset? Or it would return to correct position at the start of the next frame?
If it loops infinitely are there any actions that reset unintentionally such as change bitmap base address?
|
|
Posted By
siz
on 2024-11-30
04:31:38
| Re: Scrolling a bitmap
It resets to zero somewhere on the top of the screen (I don't remember the exact location, somewhere between raster lines 0 and 3). Until the raster counter reaches that value it will just get incremented by 40 for every character row.
|
|
Posted By
Fuzzweed
on 2024-11-30
04:53:20
| Re: Scrolling a bitmap
Ok cool, so I'll definitely need to keep refreshing it with current scroll offset. Lovely, thanks.
|
|
| |
Copyright © Plus/4 World Team, 2001-2025. Support Plus/4 World on Patreon |
