| |
Oswald
Registered: Apr 2002
Posts: 5094 |
SHX/SHY
I cant seem to get them working. I'm not sure wether the value for the AND comes from the PC counter or from the destination address, anyway neither running code at $ff00 or storing to $ff00 does work. maybe vice does not support this illegal?
edit: vice 2.2 unstable, x64 on win7. |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
2.2 o_O i wouldnt expect that to work quite right =P
that said, SHX/SHY are both unstable, and have funny side effects when used in a badline/during DMA. (the bank the value is stored can turn into the value stored). i wouldnt use it at all in code that i want to run reliably on real c64s =) |
| |
Endurion
Registered: Mar 2007
Posts: 73 |
Couldn't Vice emulate the instability of illegal opcodes as well, so coders aren't tempted in the first case? :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
it could (and should and will) once the behaviour is exactly known :) - and it DOES emulate at least some of it (some "emulamer" thingy required it - which doesnt run reliably on all real C64s, btw) |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
Try using $fe00: SHX/Y => save [X/Y & (PCH+1)]
Some more info in this thread:
http://noname.c64.org/csdb/forums/index.php?roomid=11&topicid=3..
Edit:
:BasicUpstart2(start)
.pc=$0900
start:
shx $fe00,y
dex
iny
bne start
dex
jmp start
Execute and use vice monitor to look at the ram behind $fe00 (bank ram). |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Thanks for the help. The mistake is on Graham's page: "{adr}:=X&H" which leaves me anding with #$00 when running the code :P |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
As far as I know SHX/SHY have been emulated correctly in Vice for a long time, including the instabilities. And yes, it's hi-byte of the destination address + 1.
The instability is only that the and'ing sometimes is skipped, so e.g. if you have shy $7e00,x and expected it be anded by $7f, it sometimes isn't anded at all. But for $fe00 there's no problem, since anding with $ff is the same as not anding. And if your values don't mind whether they are anded, e.g. if they are all $00-$7f for shy $7e00,x, there is also no difference whether the and works or not. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"The instability is only that the and'ing sometimes is skipped"
there is another problem when indexing crosses a page boundary, then the page the value is stored might be the same as the value itself. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Groepaz: Interesting, guess I haven't tried crossing page boundaries. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"it could (and should and will) once the behaviour is exactly known :)"
why isnt it known? every single transistor has been reverse engineered. visual6502 anyone ? |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
It is known. I somewhere have a test-program which reliably does SHX/Y with no AND happening because it waits for the VIC to take over the bus. I intended to make that a bit more robust and write an VN article about it, but well, -EBUSY. I seem to recall that idea was later mentioned in this forum, too. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Oh, and visual6502 won't help you since you need interaction with VIC. Note, that XL and AppleII users never noticed dropping off the AND (as far as I found out). |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Whoever feels like it, please go ahead and write a few lines about SHX/SHY and put it in the following section of Codebase64:
http://codebase64.org/doku.php?id=base:6502_6510_coding#illegal..
:) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"It is known. I somewhere have a test-program which reliably does SHX/Y with no AND happening because it waits for the VIC to take over the bus."
thing is that fiddling with BA does _not_ explain that behaviour in any way. so while it is known that the behaviour is somehow connected to DMA, it is not known what exactly happens =) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Ahh, the inexplicable mysteries of the C64, isn't that what makes it magic. |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
That's where its soul is. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quoting FranticWhoever feels like it, please go ahead and write a few lines about SHX/SHY and put it in the following section of Codebase64 I felt like it the other day. :)
Btw, I also tried what happens with page crossing, and it turned out much weirder than expected, since it stores the value to a completely different page. Double confirmed on VICE and real hardware. Gotta do some more testing before I can figure out the logic behind which page it ends up on, since I can't find anything online. But since VICE emulates it, I guess the knowledge has to be out there somewhere. :) |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Quote: Quoting FranticWhoever feels like it, please go ahead and write a few lines about SHX/SHY and put it in the following section of Codebase64 I felt like it the other day. :)
Btw, I also tried what happens with page crossing, and it turned out much weirder than expected, since it stores the value to a completely different page. Double confirmed on VICE and real hardware. Gotta do some more testing before I can figure out the logic behind which page it ends up on, since I can't find anything online. But since VICE emulates it, I guess the knowledge has to be out there somewhere. :)
Nice :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting CruzerDouble confirmed on VICE and real hardware. Gotta do some more testing before I can figure out the logic behind which page it ends up on, since I can't find anything online. But since VICE emulates it, I guess the knowledge has to be out there somewhere. :) So, why don't you simply take a look at the VICE source code? Avoiding confirmation bias and expecting to come up with different results? :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
or why not just read No More Secrets v0.91 ? :) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Because experimenting is fun. :) And I guess I could have just read Groepaz' earlier comment saying that the page becomes the value stored. I.e. for SHX: Page = (H + 1) & X and for SHY: Page = (H + 1) & Y. Codebase article updated. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Both the No more secrets-document and the codebase entry still have some vague phrasing so I dare to ask:
1. DoesSometimes the AND "#<adr_hi>+1" drops off actually mean
iff the write-cycle of the SH*-command is processed during an "X"-cycle (DMA-bus-overtake-cycle), the AND drops off? Or are there more dependencies for the AND to drop off?
2. My understanding is that The page where the value is stored may be equal to the value stored actually meansiff there is a page break, the page where the value is stored is (<adr_hi> + 1) & y (ex. for SHY). Or are there other occasions where the page is miscalculated?
3. Does the page miscalculation as described under 2. also happen on an "X"-cycle? My C64-intuition would say that also the page break fixup works normally on those "X"-cycles, but I did not test anything so far...
@Cruzer: Hurray for doing the tests and for feeding insights to codebase!!! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
1) yes. see the test programs
2) this seems to be unstable behaviour and it didnt happen at all on any of my C64s :) hence - please provide a proper testprogram for this behaviour, so it can be tested and verified further.
(i'll also have to update the ANE behaviour... found one CPU where it doesnt work as advertised. blarg) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Seems like i also got this wrong with the page cross, thought it just drops off the +1 component on the highbyte. But then however this resolves to a pretty powerful opcode that might be misused in funny ways?
Means i could do stuff like sty yy00,x-1 by doing a shy $00ff,x with x being 1. I'm curious if this could be misused for something funky, usually you could only influence the highbyte easily when doing indirect adressing, what could be done faster that way when it is to set highbyte only (and it is okay to live with the given y-value)
As for normal Hi+1-behaviour, i had used shx + shy heavily in one of the carpet effects. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quoting BitbreakerI'm curious if this could be misused for something funky Yes, if you have a funky idea where you only need to store $00 in page $00, $01 in page $01 ... $ff in page $ff. Just can't think of a usecase right now. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Maybe some funny way to initialize sprite pointers? Could even save some LDA's (depends on the no. of different spr-pointers used) ;) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting CopyfaultBoth the No more secrets-document and the codebase entry still have some vague phrasing so I dare to ask:
1. DoesSometimes the AND "#<adr_hi>+1" drops off actually mean
iff the write-cycle of the SH*-command is processed during an "X"-cycle (DMA-bus-overtake-cycle), the AND drops off? Or are there more dependencies for the AND to drop off?
I think your timing's slightly off (the instruction needs to be paused after its 3rd cycle for the drop off to occur), but otherwise yes.
Quote:2. ... The page where the value is stored may be equal to the value stored
That "may be" is technically true; - read on :)
Quote:iff there is a page break, the page where the value is stored is (<adr_hi> + 1) & y (ex. for SHY).
This is correct - hence the page is only equal to the value stored if the &(h+1) drop off you mentioned in (1) does not occur.
Quote:3. Does the page miscalculation as described under 2. also happen on an "X"-cycle? My C64-intuition would say that also the page break fixup works normally on those "X"-cycles, but I did not test anything so far...
The page miscalculation occurs regardless of whether/when the instruction is interrupted by a DMA.
So, the good news is an unexpected DMA won't result in you trashing an unexpected address, it'll just change the value you write to it.
The above behavior has been implemented in VICE for quite some time now, and mostly covered by the test code in
https://svn.code.sf.net/p/vice-emu/code/testprogs/CPU
I added a couple of tests a few days ago to have a closer look at how the &(H+1) drop off compares to cycle stealing; check out *5.s in the shs and shxy subdirectories of the above.
tl;dr:
high byte of address written to, when:
+--------+------------------+---------------+
| | no DMA on cycleN | DMA on cycleN |
+--------+------------------+---------------+
|page | | |
|not | H | H |
|crossed | | |
+--------+------------------+---------------+
|page | | |
|crossed | Y&(H+1) | Y&(H+1) |
| | | |
+--------+------------------+---------------+
value written, when:
+--------+------------------+---------------+
| | no DMA on cycleN | DMA on cycleN |
+--------+------------------+---------------+
|page | | |
|not | Y&(H+1) | Y |
|crossed | | |
+--------+------------------+---------------+
|page | | |
|crossed | Y&(H+1) | Y |
| | | |
+--------+------------------+---------------+
|
