The catch is that they are not. Clr performs dummy read before it writes 0, so if you use it on VDP data port when it's configured for write you'll hang (I think, don't remember this 100%).GManiac wrote:Why so? I thought MOVE #0 and CLR are working internally the same way if you look from the side of MMU or RAM.TmEE co.(TM) wrote:the S-Factor had all MOVE #0 replaced with CLRs and well you know what happens when you CLR on VDP
Gens 32 Surrial
Moderator: BigEvilCorporation
What the ...? Developers' mistake? Normal CLR must not to make any "reads".notaz wrote: The catch is that they are not. Clr performs dummy read before it writes 0
Anyway, if it does, operation of CLR.B #0,RAM will take 4 cycles longer than it should without "read", so we can check this moment.
...Hmm, IIRC CLR.L d0 takes 8 cycles insted of 4 (MOVEQ). Maybe you are right.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
CLR, BTST and something else I've forgotten cannot be used on VDP, you'll get a hang... some hacks do that, S-Factor did, in I think 6 places
Notaz is right, there is a read happening, and VDP does not like it if its put into Write mode.
Notaz is right, there is a read happening, and VDP does not like it if its put into Write mode.
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
Theorically, any read modify instructions (MOVE from SR is also one I think) should be affected, maybe also the TAS instruction which is a little more special.TmEE co.(TM) wrote:CLR, BTST and something else I've forgotten cannot be used on VDP, you'll get a hang... some hacks do that, S-Factor did, in I think 6 places
Notaz is right, there is a read happening, and VDP does not like it if its put into Write mode.
However I was not aware that the VDP could hang when reading the DATA port while in write mode (I think that some games actually do this unintentionally), but will just not care and not return any valid data, so maybe it's more related to the signal timing when this kind of instruction is executed (maybe DTACK is not generated correctly by the VDP in that special case).
I've tested some instructions and here's what I got:
So, CLR really takes longer time than MOVE. We can check if CLR performs dummy READ with use of serial autoincrementing port, for example, VDP. But I don't know will it hang or not and I'm too lazy to write demo The goal is:
- we write several various bytes into VRAM (at least 6 bytes). For example, bytes 010203040506 to address 0x0100
- we set VDP into mode R-VRAM, and then perform CLR.W to VDP. At this step I don't know what effect will have CLR to VDP while in R-VRAM mode.
- then we read 1 word from VRAM and then can determine current address. If word is 0102 then address is 0x0100 and no dummy reads were sent to VDP.
What's wrong with BTST? While CLR is "write-only" operation which makes dummy read, BTST is "read-only" operation which makes... what? Another dummy read?
In my stuff I use BTST to A10003 and it works fine.
Code: Select all
clr.b d0 - 4
clr.w d0 - 4
clr.l d0 - 6 (Gens shows 8 cycles)
move.b d0,(a0) - 8
clr.b (a0) - 12
- we write several various bytes into VRAM (at least 6 bytes). For example, bytes 010203040506 to address 0x0100
- we set VDP into mode R-VRAM, and then perform CLR.W to VDP. At this step I don't know what effect will have CLR to VDP while in R-VRAM mode.
- then we read 1 word from VRAM and then can determine current address. If word is 0102 then address is 0x0100 and no dummy reads were sent to VDP.
What's wrong with BTST? While CLR is "write-only" operation which makes dummy read, BTST is "read-only" operation which makes... what? Another dummy read?
In my stuff I use BTST to A10003 and it works fine.
All RW instructions like OR, AND, etc. are not suitable to VDP, because they consist of read and write. But we know that RW is their normal behaviour. In the case of CLR it must be W-only, but indeed it's RW.Theorically, any read modify instructions (MOVE from SR is also one I think) should be affected, maybe also the TAS instruction which is a little more special.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
CLR and BTST have never worked for me when used on VDP ports directly, you will get an immediate hang with Z80 continuing to run (68K is waiting for DTACK).
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
BTST on the VDP STATUS register works fine, just remember that the interesting bits are at offset 5, not 4. Example:TmEE co.(TM) wrote:CLR and BTST have never worked for me when used on VDP ports directly, you will get an immediate hang with Z80 continuing to run (68K is waiting for DTACK).
Code: Select all
| wait on VDP DMA
1:
btst #1,5(a6)
bne.b 1b
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
facepalm time for me
I tend to forget that BTST is byte only on memory
CLR however will not work, you'll get a lovely hang with no action going on on 68K side
I tend to forget that BTST is byte only on memory
CLR however will not work, you'll get a lovely hang with no action going on on 68K side
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Double facepalm.TmEE co.(TM) wrote:facepalm time for me
I tend to forget that BTST is byte only on memory
CLR however will not work, you'll get a lovely hang with no action going on on 68K side
[b][u]MC68000-Programmer-Manual.pdf, pages 176 & 177[/u][/b] wrote: NOTE
In the MC68000 and MC68008 a memory location is read before it is cleared.
I assume, that all arithmetic and logic instructions uses Read-Modify-Write bus cycle (for external EA ofcourse). And it's true:MC68000-User-Manual.pdf, page 53 wrote: 5.1.3 Read-Modify-Write Cycle.
The read-modify-write cycle performs a read operation, modifies the data in the arithmetic logic unit, and writes the data back to the same address.
CLR is arithmetic instruction. It's makes real read, then clears readed value and then write result (actually 0). Does anyone RTFM here?MC68000-Programmer-Manual.pdf, pages 76 &77 wrote: 3.1.2 Integer Arithmetic Instructions
ADD, ADDA Dn,<ea> <ea>,Dn <ea>,An Source + Destination
ADDI,ADDQ #<data>,<ea> #<data>,<ea> Immediate Data + Destination
ADDX Dn,Dn –(An), –(An) Source + Destination + X
CLR <ea> Destination
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
apparently notHardWareMan wrote:Does anyone RTFM here?
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 159
- Joined: Sat Feb 24, 2007 11:35 pm
- Location: San Antonio, TX
CLR is a read/modify/write instruction. It reads the address, changes it to zero (note that CLR.B only changes one byte), then writes the zero. If you use it on a memory-mapped I/O port, bad things can happen.GManiac wrote:Why so? I thought MOVE #0 and CLR are working internally the same way if you look from the side of MMU or RAM. I mean if you perform instruction:
MOVE.B #0,Addr
or
CLR.B Addr
then next steps are performed: after decoding opcode and reading data (for MOVE) CPU generates data byte of #0, then it places it on data bus and Addr on address bus and then this data byte is sent to RAM to address Addr. This step is handled by Memory Management Unit (I dunno how this thing is called exactly), so VDP can't know what instruction CPU used indeed.
In my case (as I mentioned in another thread), I learned this when re-writing the boot rom for a 68000 system that used parity RAM. There was a loop that wrote zero to all of memory to initialize the parity, and when I changed it to CLR, the loop died immediately with a bus error.
-
- Newbie
- Posts: 5
- Joined: Wed Mar 26, 2008 9:59 am
- Contact: