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.
Line 133 in "_incObj\85 Boss - Final.asm" Code (ASM): exg d0,d1 Swapping d0 and d1 has no effect on the output ROM.
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: Code (Text): 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.
Assemblers tend to assemble exg d1,d0 into exg d0,d1. While those instructions do (almost) exactly the same, they have different opcodes.
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?
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.
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.
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...
I thought most of modern-day OSes were written in C now? 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?
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.
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 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.
*bump* Okay, I was thinking, wouldn't it be better if variables were used for the sounds? It would save issues for example, let's say you ported the Sonic 3 Sound Driver to S1. It may be unpopular due to how it works but sounds are practically everywhere and using variables in place of the audio $** request would probably be better. For example: Code (ASM): audio $8C Would become: Code (ASM): audio Music_Boss And if you wanted to change the music: Code (ASM): Music_Boss = $8C ; change the $** to another music ID Just saying.
I've implemented this in the Sonic 2 disassembly (in a more clever way, even, similar to how object IDs are currently defined) and it would indeed be a nice addition for this disassembly.
It was in the Sonic 2 Split Disassembly, which was the inspiration for my post. Still, variables and equates are useful as long as you don't get over the top with them.
I will be doing this soon. IDs would be defined more like this though: Code (ASM): bgm_Boss: equ (ptr_Music_Boss-Music_Index)/4 That's how I've been doing other IDs. Palette scripts and PLCs could probably do with being IDed as well.
The Sonic 3D disasm also has this kind of IDs too - especially since the SFX ones aren't so obvious as you have to add $32 from what appears in the Sound Test =/
