| |
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...
|
|
| |
Radiant
Registered: Sep 2004
Posts: 639 |
I don't really understand your first question. As for your second question, opening the sideborder with sprite 0 enabled on a badline is impossible because BA will be low at cycle 56. |
| |
Danzig
Registered: Jun 2002
Posts: 429 |
But it's fun still to see people trying... in somewhat like 2010! |
| |
Ventura
Account closed
Registered: Jan 2006
Posts: 67 |
Quote: But it's fun still to see people trying... in somewhat like 2010!
Well, can't argue with that, but hey psst: don't tell how any of this works!. |
| |
Ninja
Registered: Jan 2002
Posts: 404 |
See this graph: In cycles marked with "X" (during takeover), writing is possible, reading not. RMW opcodes are special because their last *two* cycles are write-cycles. This way, you can still access the cycle yo need for opening the border. STA has just the final cycle as write cycle, that is not enough. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
hmm does the cpu finish off all instructions or may it be stopped in the middle of one ? |
| |
Ninja
Registered: Jan 2002
Posts: 404 |
If that cycle at the first "X" is a read-cycle (and most are read cycles), the current opcode will be halted at this point. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
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: 404 |
What do you expect to happen if you halt the CPU while it is driving R/W# low? :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
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: 5017 |
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: 5017 |
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: 11114 |
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: 404 |
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: 11114 |
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: 5017 |
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
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: 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.
no, I mean on the c64 you have this 3 cycle zone, while atari does not have this. AFAIK. tried to google, but not much on this behaviour, I remember reading somewhere that they simply stopped with the clock line (before sally!), but dunno how they solved the bus business. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Quote:no, I mean on the c64 you have this 3 cycle zone, while atari does not have this.
it should be there too, but unlike its done in the c64, they used a much simplier approach to implement it, and halt the cpu regardless if it could still perfom the read cycles or not.
the whole thing becomes even more interesting if expansionport action comes into play too.... =D |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
i dont get it, could you explain it in depth ? including expansion port :)
(c64 cpu is stopped on first read cycle, how can it be more simpler than that?:) |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Quote: But it's fun still to see people trying... in somewhat like 2010!
Don't you know that c64 is all about making impossible things a reality ;) That is why we love this machine so much. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Quote:could you explain it in depth ? including expansion port :)
sorry, no, that'd be a bit too much =P (and i cant say i really fully understand it either, i am not a hardware guy :))
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quote:could you explain it in depth ? including expansion port :)
sorry, no, that'd be a bit too much =P (and i cant say i really fully understand it either, i am not a hardware guy :))
translation: "I'm rambling about something I dont understand myself" |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
i understand enough of it to look up the information i need - but certainly not enough to explain it to someone else in great detail. even more so to someone who doesnt already fully understand the relatively simple vic bus takeover =P |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
you're playing mr smartass, but the end of the day you're only an arrogant asshole. C64 mechanism can be explained in a sentence or two , you claim atari is even simpler -BUT- now you dont want to explain because that would take too much time. You're simply ridiculous. It's crystal clear you have no idea whatsoever. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
ofcourse, mr. i can't code sideborder =) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
ofcourse I cant. btw the problem with the expansions port IIRC that it doesnt have signals like clock. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
@mr I know better how c64 and atari DMA works,
>>no, I mean on the c64 you have this 3 cycle zone, while atari does not have this.
>it should be there too, but unlike its done in the c64, they used a much simplier approach to implement it, and halt the cpu regardless if it could still perfom the read cycles or not.
- the cpu stops on the 1st read cycle -> you should have written write cycle :P
- if you stop the cpu regardless of the read(write) cycle you dont need 3 cycle safety zone.
- its obvious you have no idea how it works on the atari, just some vague ones :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
no, thats not the problem. there are even two clocks (dotclock and phi2). the "problem" is that the timing at the port isn't all that great (and worse, shifts a bit over time), and you have to gate several signals with either ba or rw "manually" so you can read/write/assert other signals like dma (or even just adress and/or data) at the right time, and that not only for the reason the vic has to use aec/rdy. it's a bit more complex than you think :) its somewhat like "remote controlling" the signals that control the cpu, but "through" the vic instead. (eg the vic controls the cpu by rdy and aec, on the expansion port you have ba and dma instead, which serve a similar purpose, but not exactly). (and at this point some hardware guy should take over, because i really cant explain it without some bus diagrams)
"- if you stop the cpu regardless of the read(write) cycle you dont need 3 cycle safety zone."
but you CANT stop the cpu during a write cycle, read what ninja wrote. and you need the safety zone to make sure the rw line is in the correct state when you take over. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
on the expansion port, I thought you were talking about problems of the atari one, and asked about that :)
2nd part:
but you can. We're talking of Ataris now, and they had a modded 6502 with a HALT line, also IIRC before this they had a mechanism which simply stopped the clock signal. anyway googling doesnt helps me finding more info on this, but I bet a simpler mechanism than c64's means no 3 cycle puffer zone. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Quote:on the expansion port, I thought you were talking about problems of the atari one, and asked about that :)
no :) the atari one seems to miss signals like BA, and there is no phi2 and no dotclock, which makes gating signals (and doing various dirty tricks in particular) a lot harder, if not impossible. (that said, i dont know wether such tricks are needed or possible on ataris. on the c64 you can do fun stuff like putting data ment for the vic on the bus externally this way, for example)
Quote:but you can. We're talking of Ataris now, and they had a modded 6502 with a HALT line, also IIRC before this they had a mechanism which simply stopped the clock signal. anyway googling doesnt helps me finding more info on this, but I bet a simpler mechanism than c64's means no 3 cycle puffer zone.
didnt find detail info either, but "It is identical to the standard 6502 except that it has a HALT input for stopping the processor and tri-stating the system bus so that other chips in the system can do DMA." implies that the logic needed to stop a regular 6502 (by using aec and rdy) was simply moved into the cpu. indeed, this could possibly mean no _3_ cycle buffer zone is needed, maybe 1 is enough.
(btw, simply stopping the clock doesnt work, that again you cant do in a write cycle, because rw would stay low, with the consequences ninja explained. you could stop the clock, assert rdy, and then pray everything goes well though =P) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
cool, glad we could sort it out afterall :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
the downside is: no i am curious about how they really did it. and there doesnt seem to be any 6502C datasheet online anywhere, and all the atari FAQs suck =P |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
Quote: See this graph: In cycles marked with "X" (during takeover), writing is possible, reading not. RMW opcodes are special because their last *two* cycles are write-cycles. This way, you can still access the cycle yo need for opening the border. STA has just the final cycle as write cycle, that is not enough.
thanks ninja.. so on a good line there is no problem when you use RMW opcodes... but on a bad line it is not possible becoz BA will be low at cycle 56....
i have read the vic article about this and i understand it better now.....
well thanks anyway
|
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
The discussion is very interesting, but perhaps a little too technical and therefore i doubt, that it is really helpful for someone asking about it.
There is one rule, which is probably more adequate:
- Use always the last sprites in row when opening the sideborder instead of the first ones and you will not experience most of these problems. So in this case sprites 4,5,6 and 7 would be appropriate.
Greetz Monte
|
| |
Mace
Registered: May 2002
Posts: 1799 |
Monte, that is the general rule.
Testa however wanted to find a way to use sprite 0, despite common knowledge that this is impossible.
Oh noes... did I say 'IMPOSSIBLE'...?
Now I triggered Crossbow! |
| |
Jetboy
Registered: Jul 2006
Posts: 213 |
Would it be possible to use sprite 0 with reu ? |
| |
Ninja
Registered: Jan 2002
Posts: 404 |
Technically yes. SuperCPU seems more fun to me, though. You can use the CPU while the VIC fetches data (as long as you don't access the c64-memory-map). |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
Why on earth would i use sprite 0, if i have 8 over n possibilities to assign all the sprites and get the same effect?
|
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Quote: See this graph: In cycles marked with "X" (during takeover), writing is possible, reading not. RMW opcodes are special because their last *two* cycles are write-cycles. This way, you can still access the cycle yo need for opening the border. STA has just the final cycle as write cycle, that is not enough.
Where can i find some info about this RMW stuff? In particular, is there some webpage where you can see for all instructions what is happening in each of the cycles? |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
http://vice-emu.sourceforge.net/plain/64doc.txt |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
I tought that is a way to use sprite 0 (almost in pal) and open side border with a badline, but it's from top of my mind, so not tested or coded yet.
Sprite zero is fetched at cycle 59, with a takeover of three cycles before it.
Looking at vic article scheme for a badline where sprite zero is enabled, we can see that at cycle 55 BA is up.
That said, in the first part of a badline, BA stay up until cycle 12.
If we have a stable raster routine, via CIA timing that let us to stat a LDA/STA at cycle 8 of a line, we can do an lda #$xx/STA $D016 ending with cycle 3 of STA (last read cycle) on cycle 12 of the badline.
So, cpu is halted here, leaving the write cycle to be executed during the cycle 55 of the badline, theoretically opening the border.
Then we have all time to restore $D016 value as needed.
From the top of my mind... of course.
|
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@Flavioweb: nice idea, but it won't work because also the read cycle causing the cpu to halt is postponed, i.e. there's always a read cycle before any write cycle.
You suggest to shift the 3rd cycle of the STA to cycle 12 of a BL. By doing this, the read cycle of the STA is NOT processed at cycle 12, but (if we stick to your example with only sprite 0 turned on) at cycle 60 of the very same rl. The write cycle of the STA follows at cycle 61. Unfortunatly, this is to late for opening the sideborder :( |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Quoting CopyfaultYou suggest to shift the 3rd cycle of the STA to cycle 12 of a BL. By doing this, the read cycle of the STA is NOT processed at cycle 12, but (if we stick to your example with only sprite 0 turned on) at cycle 60 of the very same rl. The write cycle of the STA follows at cycle 61. Unfortunatly, this is to late for opening the sideborder :(
Ok, maybe that processor is halted BEFORE last read cycle then, last read cycle and write cycle of STA are postponed to cycle 55 of the line.
Here we have cycle 55 with BA up, then 3 cycle of takeover (BA low), then 2 cycle to fetch sprite zero.
Since processor can't be halted during write operations, could not be that we have -read cycle of STA at cycle 55 of the line- and -write cycle of STA at cycle 56 of the line-?
This would work, or not? |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
This only applies on NTSC vics (6567); PAL vics (6569) haven't got 'free' cycles between badline and sprite 0 fetch: BA stays low from cycle 12 to 59, so the cpu stops somewhere in cycles 12-14 and restarts at 60. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
In this demo:
In the Border We Trust
there are 8 sprites and no border at all... |
| |
Mr. SID
Registered: Jan 2003
Posts: 421 |
No bad lines in that one... |
