[Hivebrain]

Discuss changes here, particularly controversial changes. The disassembly builds a ROM which is almost identical to the original ROM. There is one instruction that had to be changed. It may be possible to correct this now that we're using asm68k.

Here's a brief to-do list:
- Split some more stuff.
- Use more local labels in objects that don't have them.
- Do text search for "loc_" and "locret_" and rename them better.
- Use ids instead of object numbers, level numbers and game modes.
- Implement ids in all files (already done for sonic.asm).
- Macros for angle/trig object stuff.
- Merge obRange and obRanges macros.
- Add JP1 files with 0/1 variable to switch between them.

[Oerg866]

Mind telling what this instruction was?

[drx]

I'm guessing exg d0,d1

[Hivebrain]

Line 133 in "_incObj\85 Boss - Final.asm"

Syntax Highlighted Code: ASM

[color= #00bfff;]exg[/color]	d0,d1

Swapping d0 and d1 has no effect on the output ROM.

[Sik]

...

What the hell was rejecting that instruction? o_o;

[nineko]

Maybe I'm using an outdated disassembly so I don't know if this has been fixed, but right after Title_LoadText there is this line:

move.w	#0,($FFFFFFF0).w; disable debug mode

The comment is misleading, it should read "disable DEMO mode".
I'll post more if I find them.

[drx]

Sik, on Dec 26 2008, 07:27 AM, said:

...

What the hell was rejecting that instruction? o_o;

Assemblers tend to assemble exg d1,d0 into exg d0,d1. While those instructions do (almost) exactly the same, they have different opcodes.

[Hivebrain]

Object ids are defined in "_inc\Object Pointers.asm". I've used them in sonic.asm, but they still need adding to all the smaller asm files where relevant.

Could exg be redefined with a macro?

[FraGag]

Thanks, I've been waiting for this for a while! I'll have to get used to your naming convention before I get started though. Speaking of which, we should decide whether we take your names or Xenowhirl's for Sonic 2, to make porting code between both games easier.

[Sik]

drx, on Dec 26 2008, 07:49 PM, said:

Sik, on Dec 26 2008, 07:27 AM, said:

...

What the hell was rejecting that instruction? o_o;

Assemblers tend to assemble exg d1,d0 into exg d0,d1. While those instructions do (almost) exactly the same, they have different opcodes.

So basically assembler developers love to make their life harder? Because implementing such a behaviour requires extra code, in fact >_>

[Overlord]

Sik, on Dec 29 2008, 09:58 PM, said:

drx, on Dec 26 2008, 07:49 PM, said:

Sik, on Dec 26 2008, 07:27 AM, said:

...

What the hell was rejecting that instruction? o_o;

Assemblers tend to assemble exg d1,d0 into exg d0,d1. While those instructions do (almost) exactly the same, they have different opcodes.

So basically assembler developers love to make their life harder? Because implementing such a behaviour requires extra code, in fact >_>

For anyone still coding in assembly today voluntarily, that's probably true, to be honest =P

Note I said voluntarily, before the legions of hack coders jump on me.

[Sik]

Overlord, on Dec 29 2008, 11:13 PM, said:

Note I said voluntarily, before the legions of hack coders jump on me.

And OS developers.

Besides when proramming for very old (and hence slow) hardware trying to achieve for full speed, assembly is the only option. Now, if you try to do that with new hardware...

[Overlord]

Sik, on Dec 30 2008, 02:31 PM, said:

Overlord, on Dec 29 2008, 11:13 PM, said:

Note I said voluntarily, before the legions of hack coders jump on me.

And OS developers.

I thought most of modern-day OSes were written in C now?

Quote

Besides when proramming for very old (and hence slow) hardware trying to achieve for full speed, assembly is the only option. Now, if you try to do that with new hardware...

You're quite correct on the first sentence. The second - it's a bit ehhh. It's like Gentoo users who compile every app for their system - sure, it'll go faster, but is an app starting in 0.98 seconds really noticable over 1.0?

[Delta]

Overlord, on Dec 30 2008, 06:10 PM, said:

Sik, on Dec 30 2008, 02:31 PM, said:

Overlord, on Dec 29 2008, 11:13 PM, said:

Note I said voluntarily, before the legions of hack coders jump on me.

And OS developers.

I thought most of modern-day OSes were written in C now?

Ideally most of it would be written in C. However, at the very lowest levels of the OS, you'd eventually have to get into assembly because you simply can't directly interact with hardware in the same way you can with assembly. That said, you can create a higher-level C interface over some nitty-gritty asm and have the vast majority of the OS written in C/C++.

Not that I'm an expert on OS design or anything, but that's how I understand it. :P

Semi on-topicness: One of these days I should get into Genesis programming and 68k asm, and create/hack something awesome. Just that I'm already doing a ton of other stuff.

I do love all the work that's gone into Sonic disassemblies; I can almost understand it, even without extensive knowledge of assembly.

[Sik]

Delta, on Dec 31 2008, 06:51 AM, said:

Overlord, on Dec 30 2008, 06:10 PM, said:

Sik, on Dec 30 2008, 02:31 PM, said:

Overlord, on Dec 29 2008, 11:13 PM, said:

Note I said voluntarily, before the legions of hack coders jump on me.

And OS developers.

I thought most of modern-day OSes were written in C now?

Ideally most of it would be written in C. However, at the very lowest levels of the OS, you'd eventually have to get into assembly because you simply can't directly interact with hardware in the same way you can with assembly. That said, you can create a higher-level C interface over some nitty-gritty asm and have the vast majority of the OS written in C/C++.

This. No matter what, some things are very processor specific, and those things have to be done in assembler because they aren't featured in any high-level language. They're often wrapped into functions, indeed, but still you need to use assembly, unless you're so crazy you create your own high-level language exclusively for the operating system. But then you're using assembly for the compiler, unless you're even crazier and compile directly into machine language X_X

Overlord, on Dec 31 2008, 12:10 AM, said:

Quote

Besides when proramming for very old (and hence slow) hardware trying to achieve for full speed, assembly is the only option. Now, if you try to do that with new hardware...

You're quite correct on the first sentence. The second - it's a bit ehhh. It's like Gentoo users who compile every app for their system - sure, it'll go faster, but is an app starting in 0.98 seconds really noticable over 1.0?

More to my point. There's little point programming in assembly for new hardware both because most likely it won't be noticeable, and actually there are so many different types of technology that what speeds up in one processor may slow down horribly in another one - even if newer. Sometimes it may even hurt (using RDTSC for timing fails miserably in any kind of multiprocessor or multicore enviroment). So no.