| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
Anti badline trick/strech charline 7
hi,
i have a question about the anti badline trick,
in this case streched graphics, open sideborders and 7 sprites each line..
i have used this trick a vieuw times and i never had any problems..
what i did was;
$d011 = $3b
lda #$3c
stx $d016 ;open sideborder atrasterline $8a,charline 7
sta $d011 ;anti badline trick,
sty $d016
no problem
this time i also have some other stuff going on.
i use dma delay at line $30/$31
i use a fld, open borders and sprite fpp rastercode
so the dma delay swings the anti badline graphics from left to right and the fld rastercode moves the graphics up and down..
the problem i have is this..
after the fld/sprite fpp rastercode i want to do the
anti badline trick.
lets say $d011 = $1b and we are at line $8a
lda #$3c
stx $d016 ; open sideborders at line $8a, charline 7
sta $d011 ; anti badline trick
sty $d016 ;
at this point $d012 is $8d instead of $8b and there was a badline.
why was there a badline instead of the anti badline trick
and why is $d012 increased with 2 lines?
thanks
Testa
|
|
| |
Monte Carlos
Registered: Jun 2004
Posts: 359 |
I can only guess, what it is. You have sprites above the anti badline code. You surely have some instructions timing the start position of the anti badline trick. The sprites which were stretched the rasterlines before probably still have some unstretched parts. These parts hang over below the stretched parts of the sprites. They can fuck up the timing before the anti badline trick so that it starts at the wrong position. If the start falls into a badline, the code which was planned to need only one rasterline needs suddenly two rasterlines. |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
well the thing that confuses me is that the timing is correct,,
lda #$3c
stx $d016 ;de border is open now at $8a
sta $d011
sty $d016
if the timing was not correct the border should be closed.
about the sprites your are right.. at the moment i do the anti badline trick i already have 7 sprites at that line..
4 sprites from the spritestretcher and 3 new sprites...
but thanks anyway...
|
| |
Monte Carlos
Registered: Jun 2004
Posts: 359 |
It confuses me too. A last idea: Opening the border works in 7 of 8 lines, anti badline only in one. Have you checked $d012 (i mean poked it into $d020 and $d021)?
|
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
i am not sure what you mean with poking $d012 into $d020/$d021... what must i measure?...
i don't know if i ask too much but is it alright i send you a snapshot???..
well thanks again..
|
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
Any chance it is an emulator bug? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
your anti badlne trick will only work with some given vertical finescroll values ($3b fex.) . the fld will change the finescroll val all the time when moving. also the $d011 write has to be done on the same rasterline inside the char rows.
anyway there's an easyer method, in each frame open the top/bottom border with screen OFF bit set (the modewhen all color si given by d020 and nothing else is visible) you will get a screen without badlines. |
| |
enthusi
Registered: May 2004
Posts: 677 |
Quote: your anti badlne trick will only work with some given vertical finescroll values ($3b fex.) . the fld will change the finescroll val all the time when moving. also the $d011 write has to be done on the same rasterline inside the char rows.
anyway there's an easyer method, in each frame open the top/bottom border with screen OFF bit set (the modewhen all color si given by d020 and nothing else is visible) you will get a screen without badlines.
But also without sprites? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Also, he wants to stretch line 7. The DEN bit trick will not display anything else than $3FFF idle byte.
@Testa: Add a few NOPs infront of the STA $D011 and see what happens. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Can you do some checks with VICE to see at what cycle you are?
I always use an illegal opcode to check when the code is being executed :
lda #$3c
stx $d016 ;de border is open now at $8a
.byte $02 ;JAM
sta $d011
sty $d016
VICE will immediately jump to monitor when the JAM gets executed and shows the rasterline and cycle.
Also, what sprites are you using exactly? Maybe it will help to switch from sprites 0-6 to 1-7. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quote: But also without sprites?
No, if you open the vertical border and turn off DEN you can still display sprites as long as you keep opening the border every frame, keeping the vertical border flipflop from ever getting set. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quoting WVLI always use an illegal opcode to check when the code is being executed
A better way: You can simply set a breakpoint in the VICE monitor. It then allows you to single step through the code, which will tell you at exactly which point something goes wrong. |
| |
Skate
Registered: Jul 2003
Posts: 494 |
Oswald already mentioned it. I believe you should check the value you've given to $d011. Accumulator value may need to be different than usual because of fld. Since you don't have time for table lookups, you may need 8 different code blocks for 8 different startup Y positions. I'd use a macro with a parameter for this. I hope you have enough free memory. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Yes, but you cannot set breakpoints during compiling ;) (I wish I could! wouldnt it be awesome if you could set some breakpoints and conditions automagically?!) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Yes, but you cannot set breakpoints during compiling ;) (I wish I could! wouldnt it be awesome if you could set some breakpoints and conditions automagically?!)
and load your labels into the monitor.... |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: Yes, but you cannot set breakpoints during compiling ;) (I wish I could! wouldnt it be awesome if you could set some breakpoints and conditions automagically?!)
I'm not quite certain whether you're serious or not, but personally I've set up a little script which massages the label file to transform names with a particular prefix (e.g. br_*) into a breakpoint command. And in recent versions of VICE you can use the -moncommand switch to automatically read in the generated label script.
A better idea might be to patch up your assembler of choice to add new pseudo-ops for various useful monitor functions, or just a simpler mechanism to pass on strings as-is. But I haven't gotten around to it yet ;)
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I'm not quite certain whether you're serious or not, but personally I've set up a little script which massages the label file to transform names with a particular prefix (e.g. br_*) into a breakpoint command. And in recent versions of VICE you can use the -moncommand switch to automatically read in the generated label script.
A better idea might be to patch up your assembler of choice to add new pseudo-ops for various useful monitor functions, or just a simpler mechanism to pass on strings as-is. But I haven't gotten around to it yet ;)
Nice hint! Cool! I'll do that aswell. => no more ".byte 2". Also if somebody would be so kind to patch VICE to support segmented labels or atleast support labels > $ffff and assume they're in ram1 on the C128. :D
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Just to give you another option: CCS monitor displays a cycle counter always in the status line; very convenient for single stepping... |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quote: Just to give you another option: CCS monitor displays a cycle counter always in the status line; very convenient for single stepping...
How does that differ from the VICE monitor? :-P |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: I'm not quite certain whether you're serious or not, but personally I've set up a little script which massages the label file to transform names with a particular prefix (e.g. br_*) into a breakpoint command. And in recent versions of VICE you can use the -moncommand switch to automatically read in the generated label script.
A better idea might be to patch up your assembler of choice to add new pseudo-ops for various useful monitor functions, or just a simpler mechanism to pass on strings as-is. But I haven't gotten around to it yet ;)
Please elaborate :D
It would be really nice to automagically be able to create labels and breakpoints for vicemon :)
(Also.. It wouldnt amaze me if Kickass already does this... <sigh>) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: Please elaborate :D
It would be really nice to automagically be able to create labels and breakpoints for vicemon :)
(Also.. It wouldnt amaze me if Kickass already does this... <sigh>)
Oh, it's fairly straightforward really.
I've got a script (technically a C program but whatever) which reads the label file generated by ACME and spits out corresponding VICE monitor commands (e.g. "al $ffff .label"). In addition a break command is also issued for any label name which begins with 'br_'.
That's it. All that remains is to hook it up in your makefile/build script and add a '-moncommand' switch with the generated file's name when starting up VICE (presumably in the form of another build/run script hooked up to a hotkey in your editor or something.)
Well, I guess there's one or two other hacks involved as well. ACME makes no difference between constants and address labels, so the tool can be provided with a set of filters for labels to exclude from the dump so as not to clutter up the zeropage too much. I've also tweaked ACME to spit out local labels.
I'm not saying it's a clean system but it gets the job done. Especially if you prefer straight debugging to actually thinking about what might be wrong with your code ;) |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
wauw thanks for al the help,
Graham: i have tried some extra nops and i get the same result..
WVL: i use 7 sprites. not the 0 sprite becoz vic uses the whole bus to fetch it, just at the cycles needed for the anti badline trick.
i also tried the jam trick. witch is very cool. don't laugh but i never just the vice monitor...
when i add the jam byte $02 to my turbo assembler source,
i indeed go directly to the monitor. but where can i read the rasterline and cycle info.. this sounds really handy!
thanks!
|
| |
Monte Carlos
Registered: Jun 2004
Posts: 359 |
@testa: Poking the nibbles of $d012 into $d020 and $d021 shows you the current rasterline as colors.
@oswald: After the fld it should be possible to continue with increasing $d011, although with a little bit modified timing. Because a hardreset of vertical scroll position (bits 0-3 of $d011) is circumvented, one routine should be enough.
|
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
Monte carlos: i understand. but what is the advange compared to lda $d012 sta $4000.
Skate: i have put the sinus amplitude from the fld off. so the fld stands still so $d011 is always $1b at line $8a..
i also didn't completly understand what you mean with different codeblocks
instead of different codeblocks i do in the anti badline rastercode each line..
and #%00000111
adc #1
ora #$38
sta $d011
so when the fld is moving and finescroll changes i only have to change the first $d011 write of the anti badline trick.. i hope this is what you mean...
but thanks anyway...
|
| |
Skate
Registered: Jul 2003
Posts: 494 |
What I meant was, if you don't have enough cycles per line for additional and, ora etc. stuff, alternatively you can generate 8 different subroutines out of a single macro.
!macro myMacro .yPosition {
lda #((0 + .yPosition) & 7) | $38
stx $d016
sta $d011
sty $d016
...
...
lda #((1 + .yPosition) & 7) | $38
stx $d016
sta $d011
sty $d016
...
...
lda #((2 + .yPosition) & 7) | $38
stx $d016
sta $d011
sty $d016
...
...
}
forYPosition0
+myMacro 0
rts
forYPosition1
+myMacro 1
rts
...
...
forYPosition7
+myMacro 7
rts
Something like this. Then you can call the suitable subroutine depending on the lowest 3 bits of $d011 at the start up raster position.
If you have enough free cycles, you don't need this of course. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: wauw thanks for al the help,
Graham: i have tried some extra nops and i get the same result..
WVL: i use 7 sprites. not the 0 sprite becoz vic uses the whole bus to fetch it, just at the cycles needed for the anti badline trick.
i also tried the jam trick. witch is very cool. don't laugh but i never just the vice monitor...
when i add the jam byte $02 to my turbo assembler source,
i indeed go directly to the monitor. but where can i read the rasterline and cycle info.. this sounds really handy!
thanks!
When you jump to monitor, it says something like
** monitor 050 034
which means rasterline 50, cycle 34 on that line.
You can also check with the 'r' command :
** Monitor 260 048
(C:$0901) r
ADDR AC XR YR SP 00 01 NV-BDIZC LIN CYC
.;0901 00 00 00 f7 2f 37 00100000 260 048 |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
thanks WVL... this is very handy.. shame on me becoz i didn't know this....
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
radiantx: Uhrm, well, the difference is probably that I immediately understood which value means what in CCS while I never noticed the "monitor <x> <y>" thing in VICE up to now :D |
