cr1901 changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://libera.irclog.whitequark.org/~h~yamahasynths
Degi has quit [Ping timeout: 272 seconds]
Degi has joined ##yamahasynths
cr1901_ is now known as cr1901
<andlabs>
01 3C 00 0A 56 C7
<andlabs>
what 68000 opcode is this supoposed to be
<andlabs>
IDA claims it's not valid
<ZrX-NoMs>
Newer 680x0? Trap?
<Sarayan>
It's a stupid, uncodumented instruction that does *not* trigger an illegal instruction
<Sarayan>
it's btst #0, #0x0a
<cr1901>
Documentation: You RE'd the chip :P?
<Sarayan>
Well, it sets Z
<Sarayan>
but well, ori #4, ccr does it too and is way more obvious
<Sarayan>
oh, and 56c7 is sne d7, it's a bug or crap generated/compiled code. Probably compiled, actually
<Sarayan>
(only compilers use scc)
<Sarayan>
compiler writes may not notice because it can be a result of limited constant propagation and does what's expected
<ZrX-NoMs>
Unless opcode starts from 00 0A
<Sarayan>
ZrX-NoMs: that would assume 013c is not the start
<Sarayan>
also 000a is an illegal instruction (would be or.b #0xnn, Am, and the low word of the address registers is not really accessible to the alu to do the or, so it's not supported)
<cr1901>
Why is the high word accessible?
<Sarayan>
because the high word of every register is on the same segment of the bus
<Sarayan>
while the low word of address and data are not on the same segment
<cr1901>
ahhh
<Sarayan>
(there are three segments)
andlabs has quit [Read error: Connection reset by peer]
andlabs_ has joined ##yamahasynths
<andlabs_>
if this is compiled then it's the most handwritten assembly-like compiler I've ever seen
<andlabs_>
also this is in a commercial game so either the code I'm looking at doesn't actually ever run in real life or something else is up
<andlabs_>
the only clue that it *might be* compiled is that it uses -constant(a6) to refer to all RAM variables
<andlabs_>
it is a japanese made game so it might be using a weird japanese compiler, possibly the x68000 c compiler
<andlabs_>
(this is a mega drive game but the developer has made x68000 software)
<andlabs_>
but it also does things I wouldn't expect compilers to do
<andlabs_>
and it doesn't use scc
<qu1j0t3>
andlabs_: do you play with Godbolt much
<andlabs_>
no
<andlabs_>
I've just disassembled and peeked through a lot of games and have some slight intuition
<andlabs_>
granted it's mostly mega drive and friends
<andlabs>
also does godbolt even support compilers from the 1990s
<andlabs>
or is it just recent versions of gcc
<andlabs>
and clang
<andlabs>
which did not exist back then
myon98 has quit [Ping timeout: 250 seconds]
<fseidel>
andlabs: which game is this?
<fseidel>
address-register relative is a thing I've seen in human-written code too, IIRC it's sometimes used to make data relocation easier
<fseidel>
IIRC the Sharp C compiler doesn't do a very good job of keeping variables in registers (most stuff from BITD tended not to) so if it's not spilling to the stack left and right, it's probably handwritten
<fseidel>
I'd believe that the game was developed on X68Ks though, and doing things A6-relative means you don't have to change memory layout if you want to test code on the X68K but release on the MD
<andlabs>
well it was made by MNM Software who did X68000 developement so yes
<andlabs>
their other MD game (a ressha de ikou md) didn't have this problem iirc
<andlabs>
oh that is another mnm software guy
<andlabs>
(mindware is what the company is called now)
<andlabs>
"if it's not spilling to the stack left and right"
<andlabs>
lol
<andlabs>
I mean it's not like the base system has only 1MB of RAM :V