Quite simply, you CAN'T get video information in the screen borders! No memory
corresponds to the border locations. However, you can create the illusion that
stuff is going there by delving DEEP into the inner mysteries of the video
chip. Check out any recent Demo for evidence of this, and hit back issues of
mags to find out how to coerce VIC into doing something that it's not supposed
to!
David
Anyway, one way (perhaps the only?) to get graphics in the borders is to use
sprites, after switching off the borders by playing with the 38/40 column
switch on $d016, and the 24/25 row switch on $d011 (though I have heard of
other techniques using $d013(?), of all things). The top and bottom borders are
easy to take out, the sides not so easy. If anyone's interested in more info,
I'll be happy to oblige. Realise though that a decent background in 6502 code
would be appreciated.
Tarragon/Menace/Gothic Designs
: Quite simply, you CAN'T get video information in the screen borders! No
Hmm? Yes you can, there are two methods of doing so, I will elaborate below.
: memory corresponds to the border locations. However, you can create the
: illusion that stuff is going there by delving DEEP into the inner mysteries
: of the video chip. Check out any recent Demo for evidence of this, and hit
This is not an "illusion," there are actual pixels/graphic data there silly.
: back issues of mags to find out how to coerce VIC into doing something that
: it's not supposed to!
I don't know of any magazine with information on such.
Ok, here's the scoop:
You can put sprites in any border. In the bottom border, this is easy,
but in the side borders, it requires precise timing. The concept is this:
put the VIC in 25-line mode. A rasterline or two before the bottom border
starts, put the VIC in 24-line mode. But now the VIC is allready past the
rasterline where the bottom border is supposed to start! Voila'! No
bottom border - any sprites there will be displayed. The sideborderers
are done in the same way, but the timing must be precise to the cycle
rather than w/i a few rasterline. Plus, the last byte in the video bank
($3fff, $7fff, $bfff, or $ffff) will be overlayed in black on top of the
border, repeated.
--
Firefoot/Style
fire...@netaxs.com
215/579-0336
"Where's my Tractor?"
: Anyway, one way (perhaps the only?) to get graphics in the borders is to use
: sprites, after switching off the borders by playing with the 38/40 column
: switch on $d016, and the 24/25 row switch on $d011 (though I have heard of
: other techniques using $d013(?), of all things).
I use the same method you do, Tarragon. What's this about $d013? My PRG
says that this is "Light-Pen Latch X Pos"? Any info you have on
displaying data in the border, other than the standard sprites (by using
the row/column switches on $d011/$d016) and the last byte in the video -
I'd be interested to hear!
>Anyway, one way (perhaps the only?) to get graphics in the borders is to use
>sprites, after switching off the borders by playing with the 38/40 column
>switch on $d016, and the 24/25 row switch on $d011 (though I have heard of
>other techniques using $d013(?), of all things). The top and bottom borders are
>easy to take out, the sides not so easy. If anyone's interested in more info,
>I'll be happy to oblige. Realise though that a decent background in 6502 code
>would be appreciated.
I'd like to be able to take out the side borders and still leave the
text/pic thats already in the same rasterlines on the screen... I could
sure use the help!
(hint hint)
__ __ ___
/\ \ __/\ \ /'___\
\ \ \/\ \ \ \ __ __ __ __ /\ \__/ ___ _ __ ___ ___
\ \ \ \ \ \ \ /'__`\ /\ \/\ \ /'__`\ \ ,__\/ __`\/\`'__\/' __` __`\
\ \ \_/ \_\ \/\ \L\.\_\ \ \_/ |/\ __/\ \ \_/\ \L\ \ \ \/ /\ \/\ \/\ \
\ `\___x___/\ \__/.\_\\ \___/ \ \____\\ \_\\ \____/\ \_\ \ \_\ \_\ \_\
'\/__//__/ \/__/\/_/ \/__/ \/____/ \/_/ \/___/ \/_/ \/_/\/_/\/_/
>I'd like to be able to take out the side borders and still leave the
>text/pic thats already in the same rasterlines on the screen... I could
>sure use the help!
>
>(hint hint)
Do you even have an idea to start? There have been about 5 different
answers to your guestion(or rather 5 similar answers from different
people)
I don't think anyone here is really going to write the code for you,
especially for something as mundane as sideborder removal. You should
have an idea of how to start by now...
But I don't understand why you want the side border removed. You say
you want to leave the pic in the same place on the screen, so just
make the $d020 the same value as $d021.... Removing the sideborers is
very time consuming(cpu wise) And there really isn't much value in
it..
No I take that back, removing the top and bottom borders is fairly
simple and doesn't take much time, and it allows you to display stuff
outside the normal viewing area. It would allow you to put a status
line, or a menu bar in, and still have a 25x40 display.
The basic concept for removing the borders is to set the VIC to
displaying 40 columns and/or 25 rows. When the raster gun is pointing
at the 40th column, or the 25th row, set the VIC to 38 columns or 24
rows. Turning the top and bottom borders off is easy since you have 8
rasterlines to make the switch. And it only needs to be done once per
Vblank. The side borders on the hand is much more difficult as you
have like ONE cycle to do it in, and you have to turn it off EVERY
raster line!
I know Compute Gazzette had at least different articles dicussing the
technique, but I'm sure it was in others.
Chris
--
> In article <CuyL8...@eskimo.com>, WaveForm <Wave...@eskimo.com> wrote:
> >In article <e7a_940...@unique.pronet.com>,
> [Side Border techniques fadded away]
>
> >I'd like to be able to take out the side borders and still leave the
> >text/pic thats already in the same rasterlines on the screen... I could
> >sure use the help!
[...]
> But I don't understand why you want the side border removed. You say
> you want to leave the pic in the same place on the screen, so just
> make the $d020 the same value as $d021.... Removing the sideborers is
> very time consuming(cpu wise) And there really isn't much value in
> it..
[...]
With sprites in the left and right border in addition to the normal
graphics, you can get a horizontal resolution of more than 400 pixels,
provided that your monitor/TV can display it.
It matters which sprites you use, because some sprites take away the
CPU time that is needed for side border removal. I tried to use
sprites 0-3 the first time and didn't get it to work. After
dis-assembling some demo program, I tried sprites 4-7 and was
successful.
Also, when using bitmap mode, I couldn't get more than 199 raster lines
displayed correctly. However, it worked with all 200 lines when I used
a set of character sets to display graphics.
Displaying the extended graphics (I called it "cinemascope mode") takes
approximately 2/3 of the CPU time on a PAL machine. On an NTSC
machine, it would be even worse.
Richard
--
E-mail: Richar...@jk.uni-linz.ac.at
*click* Who turned off the lights?
Actually all of the sprites take the same amount of time, BUT WHEN
they take it is the more important thing. (Read Marko Mäkelä's VIC-II
timing doc) If you use sprites 0-2, you can't open the border after
the bad line, because sprite-fetches continue right after the character
data fetches and when the processor gets the bus again, it is too late!
When you use sprites 4-7, you have just enough time to open the border
and restore it when the sprite fetches start.
>Richard
-Pasi
--
"Take my Worf, please."
-- Data in ST:TNG "The Outrageous Okona"
I> Tarragon Moon (Tarrag...@p5.f100.n638.z3.fidonet.org) wrote:
>> Anyway, one way (perhaps the only?) to get graphics in the borders is to
>> use sprites, after switching off the borders by playing with the 38/40
>> column switch on $d016, and the 24/25 row switch on $d011 (though I have
>> heard of other techniques using $d013(?), of all things).
I> I use the same method you do, Tarragon. What's this about $d013? My
I> PRG says that this is "Light-Pen Latch X Pos"? Any info you have on
I> displaying data in the border, other than the standard sprites (by using
I> the row/column switches on $d011/$d016) and the last byte in the video -
I> I'd be interested to hear!
I'm pretty certain that someone pulled his leg, and did it hard! I don't say
it's TOTALLY impossible, but it will have to include fuzzing with $d011, $d018
or even $d016. No other registers could be involved! ($d030 on a 128 i 64 mode
perhaps...)
From: Pontus Berg AKA:Bacchus of FairLight 64
Sveavägen 88,5tr
113 59 Stockholm Bac...@p71.anet.bbs.bad.se
SWEDEN Fido: 2:201/411.71
... 500 years ago, "fact" was that the earth was flat!
Would you STILL accept "facts" in the bible, written 1500 years ago?
(Pontus Berg)
--- Spot 1.3 #676
>> Anyway, one way (perhaps the only?) to get graphics in the borders is to
>> use sprites, after switching off the borders by playing with the 38/40
>> column switch on $d016, and the 24/25 row switch on $d011 (though I have
>> heard of other techniques using $d013(?), of all things). The top and
>> bottom borders are easy to take out, the sides not so easy. If anyone's
>> interested in more info, I'll be happy to oblige. Realise though that a
>> decent background in 6502 code would be appreciated.
W> I'd like to be able to take out the side borders and still leave the
W> text/pic thats already in the same rasterlines on the screen... I could
W> sure use the help!
This can be done, but it takes critical timing and lots of the available
raster time! I have this done using 4 sprites on the screen, but you have to
have a layer of sprites that is moved so you don't have lines without sprites,
or overlapping sprites, b'cos then you run out of rastertime on that line, and
it all f**ks up!
From: Pontus Berg AKA:Bacchus of FairLight 64
Sveavägen 88,5tr
113 59 Stockholm Bac...@p71.anet.bbs.bad.se
SWEDEN Fido: 2:201/411.71
... Poor student, again herassed for lack of payment:
- Every month I put my bills in my hat and pick one to pay!
If you don't calm down, you risk not being in next months lotttery!
--- Spot 1.3 #676
: >> Anyway, one way (perhaps the only?) to get graphics in the borders is to
: >> use sprites, after switching off the borders by playing with the 38/40
: >> column switch on $d016, and the 24/25 row switch on $d011 (though I have
: >> heard of other techniques using $d013(?), of all things). The top and
: >> bottom borders are easy to take out, the sides not so easy. If anyone's
: >> interested in more info, I'll be happy to oblige. Realise though that a
: >> decent background in 6502 code would be appreciated.
: W> I'd like to be able to take out the side borders and still leave the
: W> text/pic thats already in the same rasterlines on the screen... I could
: W> sure use the help!
: This can be done, but it takes critical timing and lots of the available
: raster time! I have this done using 4 sprites on the screen, but you have to
: have a layer of sprites that is moved so you don't have lines without
: sprites, or overlapping sprites, b'cos then you run out of rastertime on
: that line, and it all f**ks up!
I've coded stuff which modifies the timing-code each frame, depending on
where the sprites are. BTW, has anyone in PAL gotten 5 sprites across
with the sideborders out (on the bad rasterline, ofcourse)??? That's
part of a demo I'm working on, and hoping to get PAL fixed, but I'm
guessing the extra two cycles/line make a few effects (like this)
possible in NTSC but not in PAL?
: I> Tarragon Moon (Tarrag...@p5.f100.n638.z3.fidonet.org) wrote:
: >> Anyway, one way (perhaps the only?) to get graphics in the borders is to
: >> use sprites, after switching off the borders by playing with the 38/40
: >> column switch on $d016, and the 24/25 row switch on $d011 (though I have
: >> heard of other techniques using $d013(?), of all things).
: I> I use the same method you do, Tarragon. What's this about $d013? My
: I> PRG says that this is "Light-Pen Latch X Pos"? Any info you have on
: I> displaying data in the border, other than the standard sprites (by using
: I> the row/column switches on $d011/$d016) and the last byte in the video -
: I> I'd be interested to hear!
: I'm pretty certain that someone pulled his leg, and did it hard! I don't say
: it's TOTALLY impossible, but it will have to include fuzzing with $d011, $d018
: or even $d016. No other registers could be involved! ($d030 on a 128 i 64 mode
: perhaps...)
Hmm. Sounds silly. If my leg is being pulled, it's being done fairly
well. Just recieved this mail:
From alb...@cs.tut.fi Sat Aug 27 02:39:48 1994
Date: Wed, 24 Aug 1994 12:51:48 +0300
From: Ojala Pasi 'Albert' <alb...@cs.tut.fi>
To: fire...@netaxs.com
Newsgroups: comp.sys.cbm
Subject: Re: c64 border graphics
In article <33avjn$a...@netaxs.com> you write:
>What's this about $d013? My PRG
>says that this is "Light-Pen Latch X Pos"?
Light-pen latch can be used to synchronize the processor to the raster
beam. It is a very clever trick which I found from one demo.
In the interrupt routine:
1) Program the joy button into output and
make it logic 1 (before making it output)
2) Toggle the joy pin
3) restore the joy button to input
4) You now have the exact 'position' of your code in the LatchX-register,
just use the value to synchronize
Drawbacks:
Can use it only once per frame
An easier way is to use one or more sprites and INC/DEC. Read the
'missing cycles' article from C=Hacking (and Marko Mäkelä's doc on
the VIC-II timing).
-Pasi
--- __
/\/./.
* Offline Orbit 0.70a *
Well, this is an important part of the code to remove the sideborders.
: You can stop the shaking with $D011 too,
I've used this but I prefer the two-interrupt method.
: but $D013 is more useful when the screen is blanked, when making a
: rasterscroll for instance and also in some full-screen sideborder
: situations - this may be the cause of the confusion...
I'd appriciate it if someone could describe in detail HOW to stabilize
the raster with $d013, and WHY it works?
> Nicolai Thilo (ni...@login.dknet.dk) wrote:
> : The $D013 register can't be used to remove the sideborder. However,
> : a friend of mine (Microtop/Starion) used it for timing the beam so
> : that it would not "shake".
>
> Well, this is an important part of the code to remove the sideborders.
I know. I wrote the above because it seemed that some people thought
the $D013 register could be used *instead* of the $D016 register.
> I'd appriciate it if someone could describe in detail HOW to stabilize
> the raster with $d013, and WHY it works?
I can't. I'm not a programmer.. :-)
I can give you routines if you like.
Tarragon/Menace/Gothic Designs
I haven't been able to get the sideborders open with an FLI displayed...
Though I have yet to give up, mind you.
: you cannot use sprite 0 and have a sideborder active (to my knowledge anyway),
: and if you have more than 4 sprites active it gets VERY tricky to take out the
: border on a DMA ("bad") scan line.
But still possible to get 5 sprites on DMA scan lines, in PAL? I've got
it in NTSC, but I needed the two extra cycles...
(mail me)
Thanks
>I haven't been able to get the sideborders open with an FLI displayed...
>Though I have yet to give up, mind you.
Give up :)
the timing is impossible... even if you fiddle with d013 at the earliest
possible moment, you still cannot get four cycles before the right border
starts...
>: you cannot use sprite 0 and have a sideborder active (to my knowledge anyway),
>: and if you have more than 4 sprites active it gets VERY tricky to take out the
>: border on a DMA ("bad") scan line.
You can, but you can only change the appropriate register (d017 ? damn, it's
a long time) with INC and DEC, as they are able to use two of the three 'gray'
cycles, where the vic attempts to grab the bus...
>But still possible to get 5 sprites on DMA scan lines, in PAL? I've got
>it in NTSC, but I needed the two extra cycles...
It is NOT possible on a pal (prove me wrong or believe me! I have counted more
cycles than you have eaten broccoli :)
Spot / triangle 3532
--
Spot / l...@daimi.aau.dk
Triangle 3532 - The solution to your confuzion
GCS d p+ c++ l u+ e+ m- s !n h f g+ w+ t+(++) r(+) y+
Faith without Judgement merely degrades the Spirit Divine..
Well basically a "bad" raster line is the one that the VIC chip is
DMA'ing the characters in.
Every 8 raster lines the VIC needs to grab the next 40 characters it
is going to display. It takes about a cycle to grab a character, so it
takes just over 40 cycles to DMA a line of characters. Each raster
line is approximately 60 cycles. What this means is you have only
about 20 cycles on the "bad" raster line.
This really screws up loops that are timing specific, as you must
always take into account this eighth line. In other words you can;t
write a routine that works for a given line, then execute it 40 times,
you'll have to write another routine for that mean ol nastly 8th line.
FLI forces a DMA EVERY visible line, and thats why FLI routines eat up
processing time...
Chris
--
> I> I use the same method you do, Tarragon. What's this about $d013? My
> I> PRG says that this is "Light-Pen Latch X Pos"? Any info you have on
> I> displaying data in the border, other than the standard sprites (by using
> I> the row/column switches on $d011/$d016) and the last byte in the video -
> I> I'd be interested to hear!
>
>I'm pretty certain that someone pulled his leg, and did it hard! I don't say
>it's TOTALLY impossible, but it will have to include fuzzing with $d011, $d018
>or even $d016. No other registers could be involved! ($d030 on a 128 i 64 mode
>perhaps...)
$D013 can be used to stretch sprites vertically, and also to alter the
sprite/border priority... i'll ring a guy who has done some code for it
and post a description about it here soon. The $d013 side-border knock
out works not by knocking the side border out, but by putting the sprites
_ON TOP_ of the border.. its weird , coz u can still have a different colour
side border :-)
I wont babble more till i have the code in my hands.
>
>From: Pontus Berg AKA:Bacchus of FairLight 64
---
+------------------------------------------------------------------------+
|Paul Gardner-Stephen USENET: gard...@ist.flinders.edu.au |
| BBS: Fishbowl +61 8 2771361 v.22bis |
| 64NET Author Voice: +61 8 2777479 +9:30 GMT |
| C64 Programmer Snail: 1 Hurst St,Morphettville SA 5043 |
| "Who needs an emulator Australia. |
| when you have the Alias: Highlander/Fairlight64 |
| real thing!?" |
+------------------------------------------------------------------------+
>> This can be done, but it takes critical timing and lots of the available
>> raster time! I have this done using 4 sprites on the screen, but you have
>> to have a layer of sprites that is moved so you don't have lines without
>> sprites, or overlapping sprites, b'cos then you run out of rastertime on
>> that line, and it all f**ks up!
I> I've coded stuff which modifies the timing-code each frame, depending on
I> where the sprites are. BTW, has anyone in PAL gotten 5 sprites across
I> with the sideborders out (on the bad rasterline, ofcourse)??? That's
I> part of a demo I'm working on, and hoping to get PAL fixed, but I'm
I> guessing the extra two cycles/line make a few effects (like this)
I> possible in NTSC but not in PAL?
I did 4 sprites and had one cycle left, which was wasted on an STX $D016,X (X
being zero!) just to fill the last cycle!
From: Pontus Berg AKA:Bacchus of FairLight 64
Sveavägen 88,5tr
113 59 Stockholm Bac...@p71.anet.bbs.bad.se
SWEDEN Fido: 2:201/411.71
... Sybok: - I'm sorry, but I can't surrender today!
--- Spot 1.3 #676
: >I haven't been able to get the sideborders open with an FLI displayed...
: >Though I have yet to give up, mind you.
: Give up :)
: the timing is impossible... even if you fiddle with d013 at the earliest
: possible moment, you still cannot get four cycles before the right border
: starts...
I wasn't being serious, I could never get it to work for that very reason.
: >: you cannot use sprite 0 and have a sideborder active (to my knowledge
anyway),
: >: and if you have more than 4 sprites active it gets VERY tricky to take
out the
: >: border on a DMA ("bad") scan line.
: You can, but you can only change the appropriate register (d017 ? damn, it's
: a long time) with INC and DEC, as they are able to use two of the three 'gray'
: cycles, where the vic attempts to grab the bus...
: >But still possible to get 5 sprites on DMA scan lines, in PAL? I've got
: >it in NTSC, but I needed the two extra cycles...
: It is NOT possible on a pal (prove me wrong or believe me! I have counted more
: cycles than you have eaten broccoli :)
Well, unless some other person in PAL contradicts you, I won't attempt to
PAL-fix that demo-part...
: $D013 can be used to stretch sprites vertically, and also to alter the
: sprite/border priority... i'll ring a guy who has done some code for it
: and post a description about it here soon. The $d013 side-border knock
: out works not by knocking the side border out, but by putting the sprites
: _ON TOP_ of the border.. its weird , coz u can still have a different colour
: side border :-)
: I wont babble more till i have the code in my hands.
Sounds interesting. Please post anything you can!
But prove me, if I am wrong!
One more thing:
more than 4 sprites on a BAD LINE is definitly impossible.
(on PAL c64)
If you want to do more than 4 you must avoid bad lines, but I already
posted this.
-Christian-
You don't really need to change it every line to avoid DMA. Just four (4)
times during the character row (8 raster lines). Even three times can
be enough, I just don't remember those old demos (1992) of mine.
(Again: I don't expect to be the first, but I really invented it on my own.)
>The trick is to use graphic mode because graphic mode only needs DMA to
>collect colour information.
Well, the first and second demopart where I used this 'character cloning'
I used a multicolor-text-mode.. After all, you do have 16 character sets
to choose from.. !
>Using this routine you might also notice that the colours
>of the line above (before the routine starts) will be held on the screen all
>the time. This is why you`d better use three colour graphics.
Just three colors in one character column, no other restrictions :-)
>By the way, the routine only displays every eigth line of the graphics, so you
>must transform your graphics a bit.
?? Not my routine. It nicely displays the multicolor picture, just that
it only uses the first line's colors.. OK, I don't open borders and thus
your sta $d011 is probably doing something 'bad'..
-Pasi
--
"Madam, have you ever considered a career in security?"
"If it's anything like baby-sitting, I'm an authority."
-- Worf and Brenna O'Dell in ST:TNG "Up The Long Ladder"
Yep..
>more than 4 sprites on a BAD LINE is definitly impossible.
>(on PAL c64)
#define NitpickingMode ON
No, it is definetely possible to have all eight sprites on a BAD LINE.
It is just impossible to open the borders also :-)
#undef NitpickingMode
> NT> From: ni...@login.dknet.dk (Nicolai Thilo)
>
> Nicolai Thilo ??
> I have heard about you, or atleast I know that you are one of the guys who
>
> have got the JCH-Editor directly from the creator...
Yes, I had it. I guess you must have seen my name somewhere in the
presentation program..? I've known Jens Christian Huus personally
since the good old days, before his player was worth anything. He
was very eager that I should use his editor, so he included my name
in his presentation program (Deluxe-something... I forgot the name).
However, I never composed anything with his editor. I've only used
Laxity's (Thomas Petersen) editor and the terrible Soundmonitor and
Rockmonitors (yuck!).
> Now, I just wonder if he included an instruction file with it ???
> It's some functions which I still wonder about in the soundedit of the
> newer
> versions (in the macrotables of 20.g2-20.g4), and some others
> like the loop and glidefunctions in the same ??
Sorry, I can't help you - I don't know anything about it. I saw the
editor back in '89 and I actually thought it was rather weird. Since
I was already used to Thomas' editor, I continued to use that. Back
then, disks were expensive, so I scratched it. Why don't you mail
Jens and ask him personally? He still lives at the same address. I
assume it's somewhere in the stuff you have; if not, I can email it
to you...
At first, I wanted to email you about this, but then I thought that
there might be other people monitoring this group who has some info
about this that you could use, so I kept it public (and changed the
subject).
> It would be nice to get these things explained, since I know how to use
> them,
> but don't really understand what they do...
>
> Thanx..
>
> Twoflower/Triad
> ---------------
> Mikael Backlund
--- __
/\/./. (Zenox/Starion)
* Offline Orbit 0.70b *
яяя
I've written a fair amount of music in the editor, and was
planning on releasing an in-depth "manual" of all the ins and outs of the
editor in a disk-mag I started work on. However, the mag never quite
made it off the ground (but might some day), and my article never was
seen.
You can mail me with questions, but I make no promises... it's
been a while since I used the 64, not to mention Jen's editor. I could
probably help you more with A-Man's or Magicman's editor, as those are
ones I used more than Jen's. I don't even know if those have been spread
or not... as I said, been a while.
Probably the best authority on the JCH stuff is Sequencer (Neil),
whom I have kept in contact with. He has a business address on AOL, I'll
ask him if he'd mind you sending him questions. The guy definately knows
his shit when it comes to 8-bit analog, though. Much moreso than I.
Cheers,
Wolfgang/[Not!]
--
He was a self-made man, and owed his lack of success to nobody.
_Catch-22_
I worked on this code with a friend of mine before he moved interstate. I
will call him up (as he has the code) and get him to post it to me.
There was atleast one demo i can think of that used this method (from
memory), i cant remember the name but it had FULL SCREEN sprites which moved
around really fast. some of the pictures were a Tutankhamen head and a logo of
the group/crew that did it. I will try and find this also.
> But prove me, if I am wrong!
>
> One more thing:
> more than 4 sprites on a BAD LINE is definitly impossible.
> (on PAL c64)
>
> If you want to do more than 4 you must avoid bad lines, but I already
> posted this.
>
> -Christian-
>
>
---
Also, doesn't it depend which 4 sprites you use ? from memory sprites 0-3 stuff
up the side border, but 4-7 are ok?
> #define NitpickingMode ON
> No, it is definetely possible to have all eight sprites on a BAD LINE.
> It is just impossible to open the borders also :-)
> #undef NitpickingMode
>
> -Pasi
>
>
> --
> "Madam, have you ever considered a career in security?"
> "If it's anything like baby-sitting, I'm an authority."
> -- Worf and Brenna O'Dell in ST:TNG "Up The Long Ladder"
---
> As far as I know, it is not possible to do FLI (I mean real
> FLI!!!!) together with border sprites. But if you change $d011
> every second line instead of every line you might be able to
> code plasma with sprites or you can (as Crest did a long time ago)
> put sprites in the border (but the are, of course, onl< displayed
> every second line.
By "Real FLI" I presume you mean "forced DMA *and* background/$D021 changed on
every line"? True. Sideborders and FLI are possible if you remove the $D021
changes. This shouldn't effect too many FLI pics. I believe Crossbow/Crest has
done this, in the demo Avantgarde and also swung the logo, though the edges
that swung over the border were only 3 colour.
--Bits about more than 4 sprites in sideborder chopped--
> The trick is to use graphic mode because graphic mode only needs
> DMA to collect colour information.
What do you mean by Graphic mode exactly? Is this Hires Bitmap mode?
> By the way, the routine only displays every eigth line of the
> graphics, so you must transform your graphics a bit.
Every eighth line? Why? And how do you get any detail, working under such
limitation? Do you change $d018 every line as well? Wouldn't this be close to
using FLI anyway?
Tarragon
--
FidoNet: Tarragon Moon 3:638/100.5
Internet: Tarrag...@p5.f100.n638.z3.fidonet.org
Assuming you are talking about opening the sideborders at the same time..
: Also, doesn't it depend which 4 sprites you use ? from memory sprites
: 0-3 stuff up the side border, but 4-7 are ok?
Nope. You CAN'T use sprite 0, but all others can be used. It might be
possible to have 5 sprites on a line using a command like ROL or INC,
which use up some of those cycles taken by the BA signal (just before the
DMA). I'll look into this.
--
Tarragon Moon - Tarragon/Menace/Gothic Designs
Intenet - ral...@zikzak.apana.org.au
Fidonet - Tarragon Moon (3:638/100.5)
Zikzak public access UNIX, Melbourne, Australia.
MB>> have got the JCH-Editor directly from the creator...
NT> Yes, I had it. I guess you must have seen my name somewhere in the
NT> presentation program..? I've known Jens Christian Huus personally since
NT> the good old days, before his player was worth anything. He was very
NT> eager that I should use his editor, so he included my name in his
NT> presentation program (Deluxe-something... I forgot the name).
NT> However, I never composed anything with his editor. I've only used
NT> Laxity's (Thomas Petersen) editor and the terrible Soundmonitor and
NT> Rockmonitors (yuck!).
Any chance you might give it away? I'm alway interested in new tools, and
musiceditors are high-value swapping goods, even for tone deaf crackers like
myslelf (I actually played the guitarr, so it not ALL true! =o) (That is the
Laxity one!) Address below, and I'll send you the new Reformation (Finnished
when I get a letter from you for sure. Issue
#10) in return!
From: Pontus Berg AKA: Bacchus of FairLight 64
Sveavägen 88,5tr E-mail: P...@HK.Mobitel.Telia.Se
113 59 Stockholm or: Bac...@p71.anet.bbs.bad.se
SWEDEN Fido: 2:201/411.71
... - The klingons don't exactly like you, Jim
- The feeling is mutual, doctor
--- Spot 1.3 #676
[Itemus Deletia]
>About the JCH-Editor :
>Too bad, since it's the best... Atleast the newer versions of it...
>What did Laxity's Editor include, was it 'trackerstyled' too ???
Maybe not... Jeroen Tel's newest ed has 2x, 3x, and 4x, and a
shitload of other goodies. Too bad he probably won't be doing any more
music on the 64. Well, too bad for some people, I suppose.
Cheers,
Wolfgang
--
A: "Is that cat dead?"
B: "Dunno... been sitting there for a couple weeks."
*Nudge*
B: "Yep... it's dead."
> PB>NT> in his presentation program (Deluxe-something... I forgot the
> PB>NT> name).
>
> Yes, I saw your name in the Deluxedriver. 'Zenox', wasn't it ???
Yes.
> Still, I wonder if the other ones which stands high on the list, as
> Scarzix
> and those blokes have been releasing anything... Atleast I haven't seen
> anything...
Long time ago. Most of what they did is probably lost, unless JCH
has it somewhere. That wouldn't surprise me, he has more than 3,000
5.25" disks, I think.
> PB>NT> However, I never composed anything with his editor. I've only
> used
> PB>NT> Laxity's (Thomas Petersen) editor and the terrible Soundmonitor
> and
> PB>NT> Rockmonitors (yuck!).
>
> Too bad, since it's the best... Atleast the newer versions of it...
> What did Laxity's Editor include, was it 'trackerstyled' too ???
Nope. You entered raw hex values for notes, instruments and pauses.
Didn't seem like a problem back then, though. I actually preferred
it that way... Go figure.
--- __
/\/./.
Since you seem to know, perhaps you could post some info about
what some former 64 musicians are doing on the PC. I would be interested
in hearing. I heard some .MID's from JCH which utterly stank, but I know
they're capable of a lot, having pushed the 64 to new levels musically.
> NT> Nope. You entered raw hex values for notes, instruments and pauses.
> NT> Didn't seem like a problem back then, though. I actually preferred
> NT> it that way... Go figure.
That's the way Jeroen Tel always composed... straight hex. For
everything.
Cheers,
Wolfgang/paha
: I worked on this code with a friend of mine before he moved interstate. I
: will call him up (as he has the code) and get him to post it to me.
: There was atleast one demo i can think of that used this method (from
: memory), i cant remember the name but it had FULL SCREEN sprites which moved
: around really fast. some of the pictures were a Tutankhamen head and a logo of
: the group/crew that did it. I will try and find this also.
The Demo was named "Totally Stoned 2" by HCL of BOOZE DESIGN !
cheers ART-URO of THE ANCIENT TEMPLE
Markus (Art-uro/TAT) Brejla
bre...@freenet.fsu.edu
Why documenting a source?
If it was hard to code, it should be hard to read !
I used to write demos sitting on the front of the hacks I did and often
used border sprites to do scrolling messages by ROLing the bitmaps of the
characters through a line of them. I can't remeber the assembler but it
worked (if I remember correctly) by messing with the vertical scroll
registers.
The same applied for side borders but you had to catch the raster at a
certain horizontal position and this would be pretty time consuming for
the CPU. I guess that's why it wasn't that popular a thing to do.
One trick I heard about was scrolling a full bitmap around Amiga style. I
never saw this but was told there were a few demos and the Trilogic Expert
cartridge did it, on later versions of the software, on the intro screen.
I ripped the code for side border sprites from Mules Music demo. Can't
remember where I got the side border code from...
TTFN.
I forgot to mention that you'll probably end up with strange stripes in
the top/bottom borders. To clear these Poke 16383,0 (assuming you're using
the first video page).
I think Metal and Drax are members of Bonzai (demo group) on PC aswell.
/Unifier
>> About the JCH-Editor :
>> Too bad, since it's the best... Atleast the newer versions of it... What
>> did Laxity's Editor include, was it 'trackerstyled' too ???
YAI> Maybe not... Jeroen Tel's newest ed has 2x, 3x, and 4x, and a
YAI> shitload of other goodies. Too bad he probably won't be doing any
YAI> more music on the 64. Well, too bad for some people, I suppose.
About Jerone; I know for a fact you're wrong! (I guess you are as pelase to
hear it as I was!)
/Pontus Berg (AKA Bacchus/FairLight)
Speaking ONLY for myself, unless stated differently
(========================================================================)
( o P...@HK.Mobitel.Telia.SE or Bac...@p71.anet.bbs.bad.se )
( (!) )
( / Ö Fido: 2:201/411.71 BadNet: 92:901/231.71 AmigaNet: 39:164/1.71 )
(========================================================================)
... Close the WINDOWS, shut the GATES and live happily ever after!
(Pontus Berg)
--- Spot 1.3 #676
: The same applied for side borders but you had to catch the raster at a
: certain horizontal position and this would be pretty time consuming for
: the CPU. I guess that's why it wasn't that popular a thing to do.
The side-border routines were basically $d016 instead of $d011 col 38/40
instead of row 24/25 trick for vertical borders. The code is very straight
forward, if you can do split-rasters, you can do side-borders fairly easily
if you just sync your irq right and count your cycles. (In another words,
use the $fffe irq and try the fld trick or some other trick to get the
correct timing.) I had fixed a few side-border graphics editors to NTSC
in the past, believe me, it's not hard, it's all in the timing.
: One trick I heard about was scrolling a full bitmap around Amiga style. I
: never saw this but was told there were a few demos and the Trilogic Expert
: cartridge did it, on later versions of the software, on the intro screen.
If I am correct, this is the technique used to scroll (or actually swing)
full-blown pics left and right. This is somewhat like a horizontal FLD (I
guess), since its done with $d011 if I remember correctly.. You can swing FLI
pics (atleast I remembered you can, haven't coded this machine for years!)
with this technique.
Hope it helps,
Guardian/ex-Lords
Sprites on Sideborder can be done by $d016, eventually (if you want to hold
more than 4 border-sprites + GFX in one line) you need some $d011 changes, too.
I am going to post this routine these days (if I find it).
As I already said, I do NOT believe in border-gfx by $d013. Maybe together with
$d016, but you cannot put sprites on the border without changing $d016.
-Christian-
Jeroen Tel is a pretty good coder in his own right, actually.
And judging from his music, his system of entering hex worked pretty damn
well. :)
Cheers,
Wolfgang
>Mike Davis (mi...@ittpub.nl) wrote:
>Hope it helps,
>Guardian/ex-Lords
This is one technique I am not totally familiar with... with FLD's ($d011)
you need to 'push' the character update down each raster line. How can you
mimick this with horizontal FLD?
Oh! The 'long' sprites in the previous note could have been $d017 flexers!
This is also the 'cheat' technique for doing sprite DXYSP's
(Differential X Y sprite plotter) if you leave the top and bottom line of
your sprite $00's you can 'flex' them to the Y position using one timing
routine instead of writing a new one each frame of the sin/cos function!
and just use a table of bits for which sprite to stretch! (Look at the demo
Digital Psychosis by The Force Australia for example! -ME!)
-Joe/x-TF (Dream Quest)
: If I am correct, this is the technique used to scroll (or actually swing)
: full-blown pics left and right. This is somewhat like a horizontal FLD (I
: guess), since its done with $d011 if I remember correctly.. You can swing FLI
: pics (atleast I remembered you can, haven't coded this machine for years!)
: with this technique.
The routine is called VSP (Variable Screen Positioning?) and uses $d011.
I'll be damned if I know how/why it works, and I've coded one myself. It
takes no time other than that required for two $d011 stores. (and, I
guess, two more to "restore" the scren below the swing if you so
desire). You can swing FLI pics just like any others.
--
Firefoot/Style
fire...@netaxs.com
215/579-0336
"Where's my Tractor?"
Here's some code to do that (off the top of my head)
;First you heve to time this to the cycle precise.
lda $number
sta jump+1
lda #$1c
sta $d011
clc
jump bcc * ;is changed anyhow..
lda #$a9 ;The opcode of lda immediate.. which needs two cycles.
lda #$a9
... ;etcetera.. some 20 times I think..
lda #$a9
bit $ea ;$ea = nop
lda #$1b
sta $d011
By the way: odd things may happen because the VIC suddenly starts/stops DMA,
and on some C=64 revisions random bytes may be written into the memory,
depending on the instruction after the sta $d011..
This is just off the top of my head, so don't expect it to work immediately..
Check the code of said demo's ..
CU!
--
Willy/Silicon Ltd.
Willem-Jan> To clearthings: here's what you do: At the EXACT right
Willem-Jan> time, you set $D011 so that the VIC's on a bad-line and
Willem-Jan> starts DMA.. Then, a variable number of cycles later (The
Willem-Jan> number of cycles is the number of chars the screen is
Willem-Jan> moved) you change $D011 so that the VIC is no longer on a
Willem-Jan> bad line
And how is that possible? When the video chip wants to do explicit DMA,
it stops the processor, and you cannot switch the DMA off before it has ended
(unless you use an external processor).
Actually, the way how you do horizontal scroll with $D011 is that you start
the bad line with $D011 in the middle of the screen. The write to $D011 must
occur on the rasterline preceding the wanted top line of the picture. (Well,
that must be what your example did; however I didn't read it through.)
Marko
>To clearthings: here's what you do:
>At the EXACT right time, you set $D011 so that the VIC's on a bad-line and
>starts DMA..
>Then, a variable number of cycles later (The number of cycles is the number
>of chars the screen is moved) you change $D011 so that the VIC is no longer
>on a bad line, and it happily stops DMA halfway the screen
Exactly the opposite. You change $d011 so that VIC thinks it is on a bad
line and it continues from there to the end of that line, thus not
completing the full 40 columns, just the number that was left when you
forced the bad line..
>from there. Easy huh? the hard part is the timing.. You have to wait a
>variable number of cycles between the two $D011 accesses..
No, VIC will use all of the raster time from the sta $d011 forward, thus
you will always end up synchronized to the same exact space, not
depending on where you started the DMA. You just have to wait a
variable number of cycles before forcing the DMA..
However, if you are really talking about forcing DMA on the second
STA $d011 in your code, the we are both correct.. :-)
>Here's some code to do that (off the top of my head)
>;First you heve to time this to the cycle precise.
> lda $number
> sta jump+1
> lda #$1c
> sta $d011
> clc
>jump bcc * ;is changed anyhow..
> lda #$a9 ;The opcode of lda immediate.. which needs two cycles.
> lda #$a9
> ... ;etcetera.. some 20 times I think..
> lda #$a9
> bit $ea ;$ea = nop
> lda #$1b
> sta $d011
^^^^^^^^^ This sta should trigger the DMA..
-Pasi
--
"Data is a toaster."
-- Captain Louvois in ST:TNG "The Measure Of A Man"
): By the way: odd things may happen because the VIC suddenly starts/stops DMA,
): and on some C=64 revisions random bytes may be written into the memory,
): depending on the instruction after the sta $d011..
)Which sta $d011, the first or the second? Or both? And does anyone know
The second, which forces DMA on, which makes the VIC not wait three cycles
after pulling BA high, so that VIC and CPU battle for the bus..
)exactly what's happening? And how to avoid it? It sounds similar to the
)FLI bug which kills the left three chars, in that the DMA of the VIC and
)the 6510 bus get a bit mixed up.
It is the same... Three chars, and three cycles after BA goes high, remember?
Fiddle with the instruction after the sta $d011 to see what colours you get..
(NOP gives pink..)
How to avoid it? I guess you just do a NOP or two after the second sta $d011
--
Willy/Silicon Ltd.
#EOT
: By the way: odd things may happen because the VIC suddenly starts/stops DMA,
: and on some C=64 revisions random bytes may be written into the memory,
: depending on the instruction after the sta $d011..
Which sta $d011, the first or the second? Or both? And does anyone know
exactly what's happening? And how to avoid it? It sounds similar to the
FLI bug which kills the left three chars, in that the DMA of the VIC and
the 6510 bus get a bit mixed up.
--
>)Which sta $d011, the first or the second? Or both? And does anyone know
>The second, which forces DMA on, which makes the VIC not wait three cycles
>after pulling BA high, so that VIC and CPU battle for the bus..
>)exactly what's happening? And how to avoid it? It sounds similar to the
>)FLI bug which kills the left three chars, in that the DMA of the VIC and
>)the 6510 bus get a bit mixed up.
>It is the same... Three chars, and three cycles after BA goes high, remember?
>Fiddle with the instruction after the sta $d011 to see what colours you get..
>(NOP gives pink..)
>How to avoid it? I guess you just do a NOP or two after the second sta $d011
>--
>Willy/Silicon Ltd.
>#EOT
Okay, I suppose this kinda wraps up the problem of FCPS... Or VPS or
whatever you call it... Anyway what I want to know is, what is a
reliable way to create a Straight IRQ? I don't know if this term is
used in other places, so lemme explain: it's a way to ensure exact
timing for eg. sideborder open, fcps, or other routines where timing
is essential...
Another question... What is a good way to get rnd numbers? I
once used some register (forgot the location) to get rnd numbers,
this worked fine, but when I tried again it didn't work... The
first time I only fetched a number once every frame, while the
second time I wanted to get several right after one another...
Final question: which parts of the JCH player (v14) are always
the same... I want to know this to save memory in a music
collection, and I prefer to know a fullproof way to do this,
I could just compare musics, but then I'm not 100% sure it
will work on all musics...
That's all...
Oh yeah anybody know if that 64 programmer email list is active,
and if many programmers are subscribed to it? If so, I'll join
that one... Would be easier to ask questions there...
L8r!
Trax/SCS+TRC...
Well, this is the way I've always used, because it's reliable, flexible
doesn't mess up, or set restictions on the display, unlike routines that
depend on D011 etc...
This one only observes the VIC chip:
It's some time since I actually coded a routine of this kind,
and I'm writing this off memory, so there might be some errors in the
following code.
<irq is initiated in the usual way, I almost always use FFFE/FFFF instead
of 0314/0315 for interrupt vectors, but the routine should work with
0314/315, but delay timing will be different becouse of the time being
up by the kernal>
<Set up irq vector to label 'irq1' and program desired rasterline with
d012 & $ d011 in the usual way>
<other initiation of program>
...
jmp mainPrg
;----------- Standard routines for all sharp irqs ----------------
sharp inc $d012 ;Set interrupt to the next line.
inc $d019 ;Ready for new interrupt
;same as lda #1 : sta $d019
sta storeA
lda #<sharpirq
sta $fffe ;Alter interrupt vector
lda #>sharpirq
sta $ffff
cli ;Allow new interrupt even if we
;still are in the previos irq call
noploop
nop
nop ; We add nop's here so that the next interrupt
; will interrupt while we are executing nop
... ; commands. Since nop commands use two cycles
... ; the interrupt will at most be delayed 1
... ; cycle.
... ; I think we needed about 11 nop's to be sure
; that execution is interrupted while they are
; run. (I'm not sure about this number)
jmp noploop ; Although we are sure that the interrupt will
; interrupt before we reach this point, we
; add this loop to be on the safe side.
; Imagine if the program happened to be frosen
; by a carterigde and later restarted while
; executing the nop's.
sharpirq pla ; Delete data put to stack by the last
pla ; interrupt, we don't intend to return from
pla ; it.
stx storeX
sty storeY
nop ; Now we only have an uncertainty of 1 cycle
nop ; as to where the interrupt is.
; By waiting until the edge of the current
; rasterline we can determine if the interrupt
... ; was delayed by one cycle or not.
... ; (How many nop's that is required to reach the
... ; edge of the rasterline i don't remember.
; You'll just have to find it out yourself)
; These nop's may of course be exchanged by
; equivelent time consuming instructions.
lda $d012 ; get current rasterline
cmp $d012 ; still on same line = was delayed;
bne addCycle ; add 1 cycle if not delayed.
addCycle ; doing a branch jump takes 1 cycle more than
; not doing one.
; the rastertiming is now 'straight'/sharp
rts ; return to routine that cal led sharp
endIrq ; restore a x y
storeA = * + 1
lda #0 ; For those who don't like self modifying code
storeX = * + 1 ; this can be changed easy.
ldx #0
storeY = * + 1
ldy #0
rti ; Return from interrupt.
nextIrq
stx $fffe
sty $ffff
sta $d012
inc $d019 ;or lda #1 : sta $d019 if you prefere
rts
;------------------ The actual interrupt ------------------------------
irq1
jsr sharp ;Make interrupt sharp and store A X Y regs.
<here you put your sharp interrupt dependant code>
<other code that you need executed this interrupt>
ldx #<irq<?> ;<?> is the next interrupt that is due
ldy #>irq<?> ;1 if irq1 is the only interrupt.
lda #<rasterline for interrupt>
jsr nextIrq
jmp endIrq
;--------------- Main program ---------------------------------
mainPrg
cli ;allow interrupt
<wait for space or something>
sei
<shut everything down and restore what needs to be restored>
rts ; Or jmp exitCode
*******************************************************************
By adding this routine:
saver sta storeA
stx storeX
sty storeY
rts
...you can at any time turn on/off the sharping by exchanging 'jsr sharp'
and 'jsr saver'.
I hope this is what you were looking for. Sorry for not supplying a
complete source, but as I said this is all from memory.
PS. My native lanuage is not english and I typed this in a hurry, so sorry
for the lousy lanuage / source.
Furhermore, ways of getting an rnd.
* lda $d012, only in large complex programs with lots of variable execution
times where rnd is only needed once in a while.
(Never use in raster interrupts of obvious reasons)
* lda $d800 ; The 4 upper bits of mem at area $d800 - $dc00 are completly
lsr ; unpredictable...
lda $d801
lsr
lda $d802
...
* Read the values from the white noise generator to the SID.
3rd voice set to whitenoise, and read the result.
(sorry don't remember address to read, think it is around $d416-$d41c)
These give you _true_ random numbers. It's also possible to create
'random' routines that create 'random' numbers based on a seed value.
Anything unclear? Mail me at s5...@ii.uib.no
Bye...
- Rolf Wilhelm Rasmussen
Equal of Eternity
Patrick> Okay, I suppose this kinda wraps up the problem of FCPS... Or
Patrick> VPS or whatever you call it... Anyway what I want to know is,
Patrick> what is a reliable way to create a Straight IRQ? I don't know
Patrick> if this term is used in other places, so lemme explain: it's
Patrick> a way to ensure exact timing for eg. sideborder open, fcps,
Patrick> or other routines where timing is essential...
The best way is to use a double raster interrupt. The first interrupt
sets the interrupt vector to the second one, can do some
preinitialization, increments the Raster Compare register ($d012) by
two and acknowledges the raster interrupt. Then it does CLI and some
2-cycle-instructions like NOPs. The routine is timed so that the
second interrupt occurs while the processor is executing these
2-cycle-instructions.
When it jumps to the second interrupt, there still is the
one-cycle-jitter to be removed. No problem, just do a LDA$D012:CMP$D012
in the right place, and then do a BEQ *+2 (F0 00). This will fix the timing.
But note that either the $d012 must be read in the right cycle either by
the LDA$D012 or by the CMP$D012.
In your timing calculations, note that the interrupt sequence takes 7 cycles.
Patrick> Another question... What is a good way to get rnd numbers? I
Patrick> once used some register (forgot the location) to get rnd
Patrick> numbers, this worked fine, but when I tried again it didn't
Patrick> work... The first time I only fetched a number once every
Patrick> frame, while the second time I wanted to get several right
Patrick> after one another...
You're probably refering to the SID OSC3 register. It gives the waveform
of the third voice. The idea is to set the third voice to noise waveform
and to use the maximum frequency, so that this register changes every 16
clock cycles. If you use a lower frequency, the register won't change so
fast.
Patrick> Oh yeah anybody know if that 64 programmer email list is
Patrick> active, and if many programmers are subscribed to it? If so,
Patrick> I'll join that one... Would be easier to ask questions
Patrick> there...
Or better, join the c64-h...@lists.funet.fi mailing list and ask your
questions there. I already forgot the address of the new list.
Marko
But have you ever had any problems with just plain old FLI? A few
people have told me that they have heard of other people having
problems. And I know at least one of my 64's(which is no longer on my
desktop) that doesn't like regular ol FLI (of course this was after I
spent hours going through my code) Basically it set bits in "random"
areas of memory(always the same areas) eventually crashing my program.
So anyways my question is, does anyone out there have any problems
viewing regular LFI's for longer than a few minutes or more?
Chris
--
I don't know if it's a good way, but you can get RND numbers in ML by calling some
routine in BASIC or KERNAL ROM that does just that. I seem to remember that it took a
couple of lines of raster time, so that might not be fast enough. I can look up the
address and stuff, if you're interested.
/Unifier
(E-mail address: uha...@hvdc.hv.se)
>Willem-Jan Monsuwe (wil...@blade.stack.urc.tue.nl) wrote:
>: By the way: odd things may happen because the VIC suddenly starts/stops DMA,
>: and on some C=64 revisions random bytes may be written into the memory,
>: depending on the instruction after the sta $d011..
>Which sta $d011, the first or the second? Or both? And does anyone know
Any 'late' DMA, that starts immediately as the sta is done. SO
definately the second, possibly the first, depending on how
you are setting things up.
In most instances, you can guard against this by placing a NOP
immediately after the sta $d011. On newer c64s, this gives
100% protection. Older vic revisions, particulary if the
chip is starting to die anyway (eg I have one where the
sprites often flicker black at the leftmost pixel) will
die very quickly, and may even start to get worse if
you are doing a lot of forced DMA (eg FLI).
>exactly what's happening? And how to avoid it? It sounds similar to the
>FLI bug which kills the left three chars, in that the DMA of the VIC and
Normal DMA is 43 cycles: the first three must be ignored by the VIC as
the CPU may still be writing (in the case of an interupt, when it
writes p, pclo, pchi) since the 6502 ignores (RDY?) during
write cycles.
Hence, char DMA is normally 3 cycles early. It is only if you delay
by at least three cycles that the line counter (that says which line
of pixels within the current row of characters is being displayed)
is not reset. This three cycle delay pushes the setup-reads onto
the screen.
>the 6510 bus get a bit mixed up.
--
| chris'Topher' Phillips | (shrydar on IRC/#c-64) \________/words words |
| work:+619 380 1769 | home: +619 450 6212 / \___ words |
| phil...@ee.uwa.edu.au | http://ciips.ee.uwa.edu.au/~phillips/ \________|
: >>The routine is called VSP (Variable Screen Positioning?) and uses $d011.
: >To clearthings: here's what you do:
: >At the EXACT right time, you set $D011 so that the VIC's on a bad-line and
: >starts DMA..
: >Then, a variable number of cycles later (The number of cycles is the number
: >of chars the screen is moved) you change $D011 so that the VIC is no longer
: >on a bad line, and it happily stops DMA halfway the screen
Wrong. It's the other way around. You make sure that the VIC is NOT on a
bad line, ie, bad lines always occur on every eighth raster line
starting at ($D011 AND $07 + $30), so if $D011 is $1B, then a bad line
will occur on rasterlines $33, $3B, $43 etc. So, cause a raster IRQ on
rasterline $32, set $D011 to $1C, then wait until you are part way across
the screen (on rasterline $33) and flip $D011 back to $1B. The DMA will
start from there, and (I think) will overlap to the next line.
: Ojala Pasi 'Albert' (alb...@cs.tut.fi) wrote:
: Exactly the opposite. You change $d011 so that VIC thinks it is on a bad
: line and it continues from there to the end of that line, thus not
: completing the full 40 columns, just the number that was left when you
: forced the bad line..
I have seen this overlap to the next rasterline... does it use the
leftover cycles on the next rasterline too? I would expect so. Does BA get
triggered twice for this kind of DMA?
Tarragon Moon
aka Tarragon/Menace/Gothic Designs
-Christian-
>PS. My native lanuage is not english and I typed this in a hurry, so sorry
>for the lousy lanuage / source.
The same goes for me. :-)
>Furhermore, ways of getting an rnd.
>* lda $d012, only in large complex programs with lots of variable execution
> times where rnd is only needed once in a while.
> (Never use in raster interrupts of obvious reasons)
>* lda $d800 ; The 4 upper bits of mem at area $d800 - $dc00 are completly
> lsr ; unpredictable...
> lda $d801
> lsr
> lda $d802
> ...
On $de00 compatible C64/C128 computers the 4 upper bits of $d800-$dc00 are
NOT random. The bits are the same the VIC read in phi1 and if you use this
in a syncronized routine, you will always get the same values.
>* Read the values from the white noise generator to the SID.
> 3rd voice set to whitenoise, and read the result.
> (sorry don't remember address to read, think it is around $d416-$d41c)
>These give you _true_ random numbers. It's also possible to create
>'random' routines that create 'random' numbers based on a seed value.
But can you PROOVE this randomness?
MfG Andreas