32 replies to this topic

[Cybernoid]

Well, I am having some problems trying to do a good looking vertical scroll. I can do horizontal scrolling just fine in a similar way that mux used in the SMB clone.

I would like to be able to fine vertical scroll up and down. I have 20 lines of ANTIC mode 4 that I would like to scroll and several mode 4 and mode 2 lines I would like to keep static.

My attempted Display List looks something like this:

5800: 8 BLANK
5801: DLI LMS 5010 VSCROL HSCROL MODE 4
5804: DLI LMS 503d VSCROL HSCROL MODE 4
5807: DLI LMS 506a VSCROL HSCROL MODE 4
580a: DLI LMS 5097 VSCROL HSCROL MODE 4
580d: DLI LMS 50c4 VSCROL HSCROL MODE 4
5810: DLI LMS 50f1 VSCROL HSCROL MODE 4
5813: DLI LMS 511e VSCROL HSCROL MODE 4
5816: DLI LMS 514b VSCROL HSCROL MODE 4
5819: DLI LMS 5178 VSCROL HSCROL MODE 4
581c: DLI LMS 51a5 VSCROL HSCROL MODE 4
581f: DLI LMS 51d2 VSCROL HSCROL MODE 4
5822: DLI LMS 51ff VSCROL HSCROL MODE 4
5825: DLI LMS 522c VSCROL HSCROL MODE 4
5828: DLI LMS 5259 VSCROL HSCROL MODE 4
582b: DLI LMS 5286 VSCROL HSCROL MODE 4
582e: DLI LMS 52b3 VSCROL HSCROL MODE 4
5831: DLI LMS 52e0 VSCROL HSCROL MODE 4
5834: DLI LMS 530d VSCROL HSCROL MODE 4
5837: DLI LMS 533a VSCROL HSCROL MODE 4
583a: DLI LMS 5367 VSCROL HSCROL MODE 4
583d: DLI LMS 5394 VSCROL HSCROL MODE 4
5840: DLI LMS 5010 MODE 4
5843: DLI LMS 5480 MODE 2
5846: LMS 54a8 MODE 2
5849: LMS 54d0 MODE 2
584c: LMS 54f8 MODE 2
584f: JVB 5800

I have tried several experiments and nothing seems to have worked the way I expected yet. I am trying to scroll 20 lines (from 5804 to 583d). I am trying to scroll the data from 5801 line into the 5804 line when I try to scroll the screen down, but this doesn't seem to work right.

I also have tried turning off and turning on the vscroll and hscroll bits for lines 5801 and 5840 (off in the example above).




Anyway, is there a good way to scroll up and down by one pixel for 20 antic 4 lines that are placed in an arbitrary location on the screen and can have data on screen above and below? (Without using black PM overlays to hide the bad areas?)

Any experts have any ideas?

Thanks for the help,
-C-

ps - vertical scrolling seems to affect the antic lines below the lines set with the vertical scroll bit. Thus, it seems like 2 antic lines will scroll, and that the vertical scroll bit does not have to be set on every line. Just trying to figure this beast out!!!

[Rybags]

That looks fine. Just a few things:

For smoothness you should change the VSCROL value during VBLANK.
You have DLIs on many lines. How long do they run for? If one runs too long, then the Stage 2 Vblank won't get executed, which means that the system doesn't reload the Display List pointers in ANTIC. Even though you have your JVB setup right, you can still get glitches.

Note that since you have HSCROL enabled that each screen line will have extra DMA. For the first line of a character mode, that leaves virtually no cycles left for DLI processing.

Can you post your DLI code? I would suggest that you ditch any WSYNC stores that it has and replace with a few NOPs instead (just 1 or 2 might be enough). DLIs actually occur on the line before you need them, and a simple sequence like: PHA; LDA #<color>; STA $D01A would change the background color about 16 pixels to the right of a standard width display without HSCROLling enabled.

[Cybernoid]

Rybags, on Tue Dec 13, 2005 7:41 PM, said:

That looks fine.  Just a few things:

For smoothness you should change the VSCROL value during VBLANK.
You have DLIs on many lines.  How long do they run for?  If one runs too long, then the Stage 2 Vblank won't get executed, which means that the system doesn't reload the Display List pointers in ANTIC.  Even though you have your JVB setup right, you can still get glitches.

Note that since you have HSCROL enabled that each screen line will have extra DMA.  For the first line of a character mode, that leaves virtually no cycles left for DLI processing.

Can you post your DLI code?  I would suggest that you ditch any WSYNC stores that it has and replace with a few NOPs instead (just 1 or 2 might be enough).  DLIs actually occur on the line before you need them, and a simple sequence like:  PHA; LDA #<color>; STA $D01A would change the background color about 16 pixels to the right of a standard width display without HSCROLling enabled.

Thanks for the tips.

I am changing hscrol and vscrol during dli, the last dli in the display list. This seems to work great, since I have all the time during the last lines and vbi.

The dli code is complicated and each does do wsync, but it only adjust a few registers. So, it seems it work fine.

I understand that with hscrol enabled then ANTIC grabs data a few locations before where specified by the display list. This doesn't seem to be the problem... hmmm...
but removing the wsync may give some cycles back... I will try this.

I will try to get you more code tomorrow.

Thanks,
-C-

[Rybags]

HSCROL doesn't change where data is fetched from. It just makes ANTIC fetch 8 extra characters, so a 40-column mode will fetch 48.

[Heaven/TQA]

please check your vscrol code as well...

here is the boinxx one:

do_scrolling    dec scroll_flag
                beq do_scrolling00
                rts
do_scrolling00  mva scroll_speed scroll_flag
                LDA svscrol
scroll_dec	sec
	sbc #1
	AND #$07
	STA svscrol
	STA vscrol
	CMP #$07
	BEQ do_scrolling0
	RTS
do_scrolling0   jsr draw_tiles
                inc pos_level
                lda linev
                sub #48  	;hscrol 40
                sta linev
...
dlist  dta $c0,$00,$44,a(logo_t),4,$04
  dta $80,$50,$74
dl_adr  dta a(vram+1000)
:20  	dta $34    ;23x antic 4 screen
  dta $b4,$34,$34,$14
  dta $41,a(dlist)

dlist2  dta $c0,$00,$44,a(logo_t),4,$04
  dta $80,$60,$c2
dl_adr2  dta a(infoscreen)
:10  dta $70,$82  	;10x antic 2 screen
  dta $70,$82
  dta $41,a(dlist2)

tonight i'll go through your code...

[Heaven/TQA]

ok. just checked your dlist... i am wondering regarding your 45 bytes long scanlines... should be 48?

[Rybags]

45 bytes (or even 44) per scanline in normal-width would be fine, since you never see the last 4.

Not that you'd save much memory, since you lose 2 bytes each for the LMS instructions. Plus, 2 more machine cycles which would put yet more strain on his DLI routine.

[Heaven/TQA]

ah...sorry... mixed up because i have in general use overscan-mode (wide screen) and latest boinxx build uses 48 bytes scanlines...

[Cybernoid]

Well, I am using wide playfield... which the ANTIC will fetch 48 bytes/chars, but really only 44 are viewable on screen. My screen buffer has 45 bytes per line, so that I have one column to write in. This column will become the left or the right side depending on scrolling.


You are right about ANTIC not grabbing data ahead of where you specify, but in order for my display to align with the screen for the following case:
* vscrol and hscroll bits set
* horizontal scroll in the normal case (for my code) is set to 8
* Wide playfield set.

Then, I must tell ANTIC to fetch from one byte early. Thus, if you tell ANTIC to read data from 0x5010, the first byte on screen is really 0x5011.

I have done an experiment where I turn on the v/h scroll bits in the display list and keep all other things the same. This causes the first byte on screen to move 4 locations to the left (I think... if I remember correctly).

Anyway, this works... horizontal scrolling is fine. Hmmm...

[Cybernoid]

Heaven/TQA, on Wed Dec 14, 2005 6:18 AM, said:

ah...sorry... mixed up because i have in general use overscan-mode (wide screen) and latest boinxx build uses 48 bytes scanlines...

Thanks for the help Heaven (and everyone). I was actually looking at Boinxx in the emulator before you sent some code to see what was going on.

Here is what I am doing:

Wide playfield
45 bytes per antic line
hscroll set to 8
vscroll set to 0
h and v scroll bits set (as shown in the display list)
DLI every line.

I am using the 45 bytes per line because it seems we can only display 44 on screen. This I has shown with the emulator and the real hardware.

I think that the problem may line in the fact that I am doing a LMS every line for only 45 bytes per line to save some memory.

I have included an excel spread sheet showing my screen memory, and a video clip showing the problem. I have done a few things to highlight the problem areas. The top is a brown color, and the bottom is a green color which wouldn't normally be.

A couple of things are strange about this (if you watch this in slow motion). I expect to see 22 lines of mode 4 and four lines of mode 2, but I only see 21 of mode 4 and 3 of mode 2. Vertical scroll reg in ANTIC is set to zero before scroll.

The other problem is that the green and the brown colors move onto the play area... which I don't want. I think that the dli's move with the vertical scroll (as it probably should), but this is causing a problem.

If I move up (and the screen scrolls down), you see the first 2 lines are brown. I would really like to have the first line black, and the second one the color for that line.

Right, now I can scroll up and down. It smooth scrolls fine, but the top and bottom chars (8 lines), will "snap" in, because they were black, scrolled in, then changed color. If I change color before scrolling in, then you see a double image on the top or bottom.


Anyway, sorry for the long post.... thanks for the ideas.

-C-

Attached Files

•  doavid4.zip   1.34MB   75 downloads

[Cybernoid]

It looks like with the LMS, the best I can do is scroll 19 lines and snap in the other 1 line at the top or the bottom.

Here is a small video. Is this acceptable or objectionable?

Thanks,
-C-

Attached Files

•  doavid5.zip   507.51K   95 downloads

[cbmeeks]

Looks pretty awesome to me! Love the fog of war!

cbmeeks

[Heaven/TQA]

ok...i had the same issues with Boinxx with the popping last line... but this is a well known issue since 1978... when reading De Re Atari (or any other hardware book) you might find the way to avoid this...

5800: 8 BLANK
5801: DLI LMS 5010 VSCROL HSCROL MODE 4
5804: DLI LMS 503d VSCROL HSCROL MODE 4
5807: DLI LMS 506a VSCROL HSCROL MODE 4
580a: DLI LMS 5097 VSCROL HSCROL MODE 4
580d: DLI LMS 50c4 VSCROL HSCROL MODE 4
5810: DLI LMS 50f1 VSCROL HSCROL MODE 4
5813: DLI LMS 511e VSCROL HSCROL MODE 4
5816: DLI LMS 514b VSCROL HSCROL MODE 4
5819: DLI LMS 5178 VSCROL HSCROL MODE 4
581c: DLI LMS 51a5 VSCROL HSCROL MODE 4
581f: DLI LMS 51d2 VSCROL HSCROL MODE 4
5822: DLI LMS 51ff VSCROL HSCROL MODE 4
5825: DLI LMS 522c VSCROL HSCROL MODE 4
5828: DLI LMS 5259 VSCROL HSCROL MODE 4
582b: DLI LMS 5286 VSCROL HSCROL MODE 4
582e: DLI LMS 52b3 VSCROL HSCROL MODE 4
5831: DLI LMS 52e0 VSCROL HSCROL MODE 4
5834: DLI LMS 530d VSCROL HSCROL MODE 4
5837: DLI LMS 533a VSCROL HSCROL MODE 4
583a: DLI LMS 5367 VSCROL HSCROL MODE 4
583d: DLI LMS 5394 VSCROL HSCROL MODE 4
5840: DLI LMS 5010 MODE 4
5843: DLI LMS 5480 MODE 2
5846: LMS 54a8 MODE 2
5849: LMS 54d0 MODE 2
584c: LMS 54f8 MODE 2
584f: JVB 5800

when going through your dlist your last line of the scrolling window should not have set the vscrol bit...

so when i am reading your dlist correct it should be the line at 583d?

[Cybernoid]

Heaven/TQA, on Wed Dec 14, 2005 2:39 PM, said:

ok...i had the same issues with Boinxx with the popping last line... but this is a well known issue since 1978... when reading De Re Atari (or any other hardware book) you might find the way to avoid this...

When you say "had an issue with Boinxx" do you mean that this is now solved? If so how?

Quote

when going through your dlist your last line of the scrolling window should not have set the vscrol bit...

so when i am reading your dlist correct it should be the line at 583d?

Yes this should be line 583d... I will try this. Thanks!

[Heaven/TQA]

ok... of course the DLI should "walk" with the scrolling otherwise you can not sync the dli with the moving on screen... ok...what is the solution? i had the same difficulty with Boinxx as the score panel is done by repositioning player sprites on a certain rasterline...

the solution is really simple... just add the offset of the scroll-register...

here is the DLI code for the score panel:

;score-panel
dli2            pha
                txa
                pha
                lda #15
                sta ^4a
                sta $d012
                sta $d013
                sta $d014
                sta $d015
dli20           lda #48
                sta 53248
                mva #56 53249
                mva #64 53250
                mva #72 53251

;powerup panel
                sta ^4a
                sta ^4a
                sta ^4a
                sta ^4a
                sta ^4a
                sta ^4a
                sta ^4a
                sta ^4a
;sync powerup panel dli with soft scrolling to avoid jumping
powercol0       lda #$00
                ldx svscrol
dli21           sta ^4a
                dex
                bpl dli21
                sta $d012
powercol1       mva #$04 $d013
powercol2       mva #$0a $d014
powercol3       mva #$32 $d015
                pla
                tax
                pla
                rti

* XASM notes

mva = move value to
^xy = $dx0y

[Heaven/TQA]

and if you still can not make it correct...go the c64 way...

now you know how to sync your DLI with vscroll...then simply set all playfield colours to your background colour and no one would see that the last line is "jumping" and popping into the screen...

[Heaven/TQA]

here is the (un)optimised boinxx9 source code in xasm format as it stands now...

Attached Files

•  boinxx9.zip   43.61K   72 downloads

[Cybernoid]

Heaven/TQA, on Wed Dec 14, 2005 2:56 PM, said:

and if you still can not make it correct...go the c64 way...

now you know how to sync your DLI with vscroll...then simply set all playfield colours to your background colour and no one would see that the last line is "jumping" and popping into the screen...

Ah ha. Yup, I am setting all colors to background color for the dli, but I do not have it synced with vscroll. This may very well be the solution!!!! oooh... this may take some experiments to get right, however... but as always...

Thanks!!!

ps - so what is the C64 way? Just start coding for the enemy?

[Cybernoid]

Heaven/TQA, on Wed Dec 14, 2005 3:00 PM, said:

here is the (un)optimised boinxx9 source code in xasm format as it stands now...

Looks great!!! Do any of the enemies do stuff now? I think I landed on a frownie and it made the controls backwards... ?!?

[hawk]

Hi Cybernoid,

I just wanted to put in my 2c worth to say that your demo video looks great. I agree with cbmeeks, the lighting effects look awesome.

I feel guilty just lurking here watching you guys put in the hard yards, but right now I have little to offer in return. I'm very interested in the progress of your project, as I'm attempting a NES style RPG, probably more like FF1 than Zelda. It's easier to do non-realtime combat, which is also my preferred style of play. Your project looks more like Diablo ported to A8.

Anyway, just wanted to offer some words of encouragement...keep up the good work.

Cheers,
Mike.

[Heaven/TQA]

re: sync

just wait x scanlines in your dli until you actually change things on screen... f.e. your dli starts at scanline 8 and you are moving the screen up via increasing vscrol register (which actually tells antic/gtia to skip those scanlines) your DLI moves up as well...as antic/gtia "move" the dlist as well... and so the DLI... so to compensate that why not waiting ("adding") the skipped scanlines? and the amount of scanlines which are skipped are put into vscrol...so as in general you are using a shadow register (as you can not read vscrol and get the value you have put in...) just make this:

sync powerup panel dli with soft scrolling to avoid jumping
powercol0       lda #$00
               ldx svscrol
dli21        sta wsync
               dex
               bpl dli21
;here starts your real dli code...

now you have synced your DLI with vscrol and that is what you have wanted... now you can simply reset all playfield colours to the background and voila...

why c64 way? because c64 way means that you are setting your code to a special rasterline and on c64 the rasterinterrup of the VIC do not care about the hscrol/vscrol register...

re: enemies

the 2 enemies are just put in there for 2 reasons... one is for looking how many raster cycle i have left before i get into trouble... and as it seems they work...(ok...they are not big ones but the "hunting" code is complicated and was written by thomas jentzsch...). if you are really nasty you can see that the last digit is flickering and that is now the 1st time the gfx engine has not enough cpu time left... why? as i have switched to overscan and enabled hscrol for some nice effects which are stealing dma cycles from the cpu...

the 2nd reason is to test the colours, animation routines and in near future the "enemy engine" which has to be written... when are enemies coming, what are they doing...collision routines etc...all the stuff a "real" game needs... and to be honest...never coded such things...this is a complete different task than coding demos...

re: reverse controls

as far as i remember the code has a bug... the reverse test code is enabled when the powerbar is full... not when you are jumping on a special tile... i had to write a new collision routine for boinxx as the 1st one was a more simple one but lead to no recognition on which tile the player moved the ball.... so this extended routine consumes cpu cycle as well... as i am now checking the video-ram for hitting platforms or water and then checking in the tile map on which tile i am moving the ball...the digits are showing debug information... tile_xpos, tile_ypos, tile_no_hi, tile_no_lo....

[Cybernoid]

hawk, on Wed Dec 14, 2005 4:36 PM, said:

Hi Cybernoid,
Your project looks more like Diablo ported to A8.

Anyway, just wanted to offer some words of encouragement...keep up the good work.

Thanks!!! Actually, Diablo was a bit of an inspiration for this project anyway. This thing I am working on is networkable too... all the demo videos I have shown are the Emulator getting data froma game server running on a Linux box... It could be years away from something playable, but that is the idea..

[Cybernoid]

Heaven,

Thanks again... I now fixed the bottom of the screen to scroll properly. I now need to fix the top, but at least I know that there is a fix....


This is the fix for the bottom of the screen... (using cc65 with embedded asm for dlis).

void dlibtm(void)
{
  //Save Used Registers
  asm("        PHA"); 
  asm("        TXA"); 
  asm("        PHA"); 
  
  asm("        LDX  _vscroll_off"); 
  asm("dlibtml:");
  asm("        STA     $D40A");
  asm("        DEX");
  asm("        BPL dlibtml");

  asm("        LDA     #$00"); // c4

  asm("        STA     $d01a"); // BAK 0x2c8 Dark grey
  asm("        STA     $d018"); // PF2 0x2c6 Light Grey
  asm("        STA     $d017"); // PF1 0x2c5 White

  /********************************************************************/
  /* Setup DLI */
  /********************************************************************/
  asm("lda #<(_dlibtm2)");
  asm("sta $0200");
  asm("lda #>(_dlibtm2)");
  asm("sta $0201");
  
  // Restore Used Registers
  asm("        PLA"); 
  asm("        TAX"); 
  asm("        PLA"); 

  // Return from DLI
  asm("        RTI");

}

Quote

as far as i remember the code has a bug... the reverse test code is enabled when the powerbar is full...

Yup, that was the case... the power bar was full, then the controls were reversed... interesting effect btw...

Edited by Cybernoid, Wed Dec 14, 2005 5:21 PM.

[gauntman]

Heaven/TQA, on Wed Dec 14, 2005 2:56 PM, said:

and if you still can not make it correct...go the c64 way...

now you know how to sync your DLI with vscroll...then simply set all playfield colours to your background colour and no one would see that the last line is "jumping" and popping into the screen...

Just verifying that you didn't miss the usual solution to the popping problem that was mentioned above - don't set the vscroll bit on the bottom line of the scrolling display.

The following display list has information at the top and bottom, set for horizontal and vertical fine scrolling (although this was used in a MWP demo, so no LMS changes on each line -- however, the principle is the same)

dlist   .byte 112,112,112,64+2,<top,>top,2,0,2,0
lms1    .byte 64+$36,<screen,>screen
        .byte 64+$36,<[screen+24],>screen
        .byte $36,$36,$36,$36,$36,$36,$36,$36,$36
        .byte $36,$36,$36,$36,$36,$36,$36,$36,$16, ; last line hcsroll only
        .byte 0,64+2,<[top+120],>[top+120],112
        .byte 65,<dlist,>dlist

top    
       .sbyte "    Top...                             "
       .sbyte "                                        "
       .sbyte "                                        "
       .sbyte "...and a line at the bottom             "

Notice that the last line above the text window only has the hscroll bit set, not the vscroll. No palette trickery is necessary (although, it is a pretty cool solution);

[Cybernoid]

Thanks for the info. I found the solution to the simple case by not setting the vscroll bit on the last line, but unfortunately I am setting colors every line with dlis... and this moves with the vscroll... thus I need to cmopensate for this with the method Heaven outlined. This works great!


thanks,
-c-