| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
fetch the 0-sprite. with open borders...
hi,
ik have a little problem.. i want to open the sideborders with the 4 lowest sprites... i have two questions about it..
when i do the D016 write i use a dec d016 or a lsr or ror as opcode... why does a sty, sta, stx not work....
has it something to do with cpu takeover cycles at that point...
second question... what to do on a badline....
there are not enough free cycles. with 4 sprites for a inc, ror or lsr d016 instead of a sta, sty or stx...
i realize it is common knowledge.. but sorry i dont. know it...
bye...
|
|
... 36 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
so why is this whole BA mechanism at place at all then? I thought its purpose is to let instructions finish before letting the bus go. Atari 8 bits simply stop the cpu when needed, there's none of this messy ready cycle business. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
What do you expect to happen if you halt the CPU while it is driving R/W# low? :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Atari 8 bits simply stop the cpu when needed, there's none of this messy ready cycle business.
the _c64_ does also only stop the cpu (exactly!) when needed - using that "messy" ready cycle business :) the atari stops the cpu _more_ than needed, because it does not have such mechanism :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: What do you expect to happen if you halt the CPU while it is driving R/W# low? :)
what does the "lets wait for a read cycle" rule has to do with that ? a read cycle doesnt drives the R/W(rite)# low ? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Quote:Atari 8 bits simply stop the cpu when needed, there's none of this messy ready cycle business.
the _c64_ does also only stop the cpu (exactly!) when needed - using that "messy" ready cycle business :) the atari stops the cpu _more_ than needed, because it does not have such mechanism :)
"lets wait for the first read cycle to stop, 3 cycles before we need the bus" doesnt sounds like stopping exactly when needed. it may be as much as 3 cycles too early. AFAIK atari just stops the CPU when needed, no questions asked. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:AFAIK atari just stops the CPU when needed, no questions asked.
yes, exactly. and on the c64 the cpu can still perform non-write cycles (if any) until it really stops. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Oswald: Please, take some time to really think about it. If you halt the CPU while it is writing, the VIC would not fetch but push data, because R/W# is driven low. And it is 3 cycles because this is the maximum the CPU ever writes in a row (interrupt entry).
So, next reply is either "OK, I got it" or a precise description how you want to achieve that the VIC is not accidently writing instead of reading with 0-delay cycles ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:If you halt the CPU while it is writing, the VIC would not fetch but push data, because R/W# is driven low.
and some kind of flaw in this mechanism is most likely causing the well known VSP fuckups :) |
| |
Mace
Registered: May 2002
Posts: 1799 |
This is probably all understandable when I read it over another 20-odd times... for now, it's a bit dazzling :-)
Always interesting to see how people explain difficult stuff they fully understand themselves. A lot of information is assumed common knowledge, while in fact for others it's all new and not too logical. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I got it, but your explanation was very implicit and well hidden, because I did NOT know the VIC can not put the bus into read state by itself :P :)
VICII can not drive the R/W line, so it has to wait until the CPU hits a read memory state and then stop the CPU
|
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
