SpritesMind.Net

Posted: **Mon Nov 16, 2009 10:50 am**

GManiac wrote:
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
Why so? I thought MOVE #0 and CLR are working internally the same way if you look from the side of MMU or RAM.

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%).

Posted: **Mon Nov 16, 2009 11:54 am**

notaz wrote: The catch is that they are not. Clr performs dummy read before it writes 0

What the ...? Developers' mistake? Normal CLR must not to make any "reads".
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.

Posted: **Mon Nov 16, 2009 1:50 pm**

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.

Posted: **Mon Nov 16, 2009 2:12 pm**

This is for Gens 32 or Regen?

Very useful info, i like it

I go to Retro Sonic page maybe find something interest

Posted: **Mon Nov 16, 2009 2:36 pm**

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.

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.

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).

Posted: **Tue Nov 17, 2009 8:39 am**

Some hacks hang on Gens 32 Surrial!

I don't know who make these Sonic Hacks for example: Sonic Lost Worlds, in this games lotta bugs which cause to crash even Gens 32 Surrial

Posted: **Tue Nov 17, 2009 9:14 am**

I've tested some instructions and here's what I got:

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

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.

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.

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.

Posted: **Tue Nov 17, 2009 10:32 am**

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).

Posted: **Tue Nov 17, 2009 6:34 pm**

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).

BTST on the VDP STATUS register works fine, just remember that the interesting bits are at offset 5, not 4. Example:

Code: Select all

| wait on VDP DMA
1:
		btst	#1,5(a6)
		bne.b	1b

Doesn't cause any trouble on any of my hardware.

Posted: **Thu Nov 19, 2009 12:26 am**

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

Posted: **Thu Nov 19, 2009 3:23 am**

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

Double facepalm.

[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.

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.

I assume, that all arithmetic and logic instructions uses Read-Modify-Write bus cycle (for external EA ofcourse). And it's true:

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

CLR is arithmetic instruction. It's makes real read, then clears readed value and then write result (actually 0). Does anyone RTFM here?

Posted: **Thu Nov 19, 2009 11:44 am**

HardWareMan wrote:Does anyone RTFM here?

apparently not

Posted: **Thu Nov 19, 2009 7:38 pm**

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.

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.

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.

Posted: **Wed Nov 25, 2009 4:23 pm**

Guys i found glitch in Hq2xS, in last week i install Windows 7 and run Regen, i notice strange very small thin lines on some sprites, i change to another plugin Hq2x and problem solved

Posted: **Fri Oct 29, 2010 3:44 am**

This emulator is just for fun.As the name,it's called "Surreal".