Add endian option to Sega Genesis and segaCD

[lee4]

Hey rimsky82, is possible to add little and big endian option to Sega Genesis and segaCD in the code database ?

Example:

little endian
FFFF00:00FF

big endian
FFFF01:00FF

[Pyriel]

How the heck is that a change in endianness? It's more of an add/subtract one from the address feature, and hope like hell the results are useful.

What is the goal here? I can't imagine the Genesis can actually change its endian nature arbitrarily, such that you might need the same code to overwrite address or address+1 to change the least significant byte of the value. As far as I'm aware, the 68K is big-endian, so not even the packed and BCD types would break the consistency. Is this some weird quirk of one of the cheat devices?

[rimsky82]

more like

big endian
FFFF00:00FF

little endian
FFFF00:FF00

The site expects big endian and when generating files for emulators that use little endian it swaps the bytes.

[Pyriel]

That way it makes sense. Aside from the emulators apparently storing code addresses one way, and the values another, anyway.

[lee4]

here you can see emulator address are different
http://www.geocities.jp/maga_cd_16bi...inja_burai.htm

[Pyriel]

So what, one of the emulators handles memory with a different ordering, and fouls any 8-bit write code that tries to hit part of a larger variable? Wouldn't you just be hoping that this is one of those cases when you alter the address? Or is it sillier than that, and it also allocates and manages memory with a minimum size of 16-bits or something, so every address is guaranteed to be swapped?

Edit: The reason I ask is because, e.g., this:
(name, GENS code, Kega code)
素早さ 99 FF871A:0063 FF871B:0063
防御　 99 FF881B:0063 FF881A:0063

[lee4]

for example

kega 	(gens / genesis games on ps2/ps3/wii)
FF0000  FF0001
FF0001  FF0000
FF0002  FF0003
FF0003  FF0002
FF0004  FF0005
FF0005  FF0004
FF0006  FF0007
FF0007  FF0006
FF0008  FF0009
FF0009  FF0008
FF000A  FF000B
FF000B  FF000A
FF000C  FF000D
FF000D  FF000C
FF000E  FF000F
FF000F  FF000E

and on real action replay cheat device the value is 1 byte not 2 bytes

[Pyriel]

Yeah, I didn't need more examples, thanks. What I'm asking, is whether or not what you requested is consistent because of whatever quirk creates it. I can't find any good information on the structure of Genesis PAR codes, but apparently these emulators switch between 8- and 16-bit based on the value:
織田信長 金9999 FF6616:270F FF6616:270F
武田信玄 金9999 FF6934:270F FF6934:270F
上杉謙信 金9999 FF688C:270F FF688C:270F

You apparently don't need to add anything to it when it's writing the full 16-bits. So I'm questioning the reason for the change. If the value is 0063 or something, I assume it's writing 8-bits directly to the address in the code, and the zeroes in the value are extraneous. If the address changes because the underlying variable of the game is 16-bits, and the emulator handles it with the opposite byte-ordering, then 8-bit writes to 8-bit variables should not require changes, and you can't necessarily assume that adding or subtracting 1 from the address will yield the right results. If the emulator does something weird like handling all memory as shorts, or if these are actually ROM writes and the ROM data is just interleaved the opposite way, then you can assume the shift will be consistent.

Edit: Another possibility I didn't think of is that one of the emulators switches to 8-bit writes if the upper part of the value is 0 (which is dumb) and the other one doesn't.

[lee4]

more like

big endian
FFFF00:00FF

little endian
FFFF00:FF00

The site expects big endian and when generating files for emulators that use little endian it swaps the bytes.

by doing that cause write the value as 16bit and writes on both FFFF00 and FFFF01 cause glitches (tested)

the code has 8-bit value FFFF01 or FFFF00 not both