Took a quick look on the project, just out of curiosity. I like the direction it's taking so far, but some suggestions for the variable naming: I would rename these to v_hscrolltablebuffer and v_spritetablebuffer, since they aren't the actual sprite table or hscroll table data, but a mirror that is copied, I think once every frame, during the vsync, I don't fully remember the details. I would change this to the following since it's not entirely correct: Aditionally I'm gonna suggest to use another prefix after the "variable" or "flag" identifier for the "environment" in which the variable is used. For instance: v_level_rings, v_camera_screenposx, v_snd_fm1_ptr, v_pal_fadestart - you get the idea. Also, the prefix "v" for "value" could be extended to specify the variable length (b, w, l, or array)
Looks like I have found a bug. When time is 9 minutes, and you have more than 0 rings, the time counter label doesn't swap red/yellow colors, it just stays yellow.
I just had to comment on something. Having played around with this disassembly, the only thing I find annoying, as of now, is with mappings. For those of us who use SonMapEd, you would get an error for replacing them and would have to re-add the label to it in the included file. In the old disassembly, they were labeled then included. I think it would be better if it were the other way around. Just a thought though. Other than that, I really like the way this is headed.
Okay, what pisses me off with this disassembly is that previous labels aren't referenced. If possible, could a list be added to the disassembly containing the original 2005 labels and the current ones. You could also contribute to the SCHG:Equivalent Subroutines.
Thanks. I'll make those changes in my next update. I thought about that, but I'm not keen on adding lots of extraneous labels. Maybe we could beg Xenowhirl to make a version that preserves labels. Many labels were changed because they were inaccurate, unhelpful or just plain wrong. I've no intention of putting them back. However, I will add labels from the latest S2 disassembly.
Question: why is the asm68k error log redirected to errors.txt? Logging errors to a file doesn't show anything on the console (not even an "assembly failed with errors; see error.txt for details" message), and there's no error checking in the build.bat file, so I can never be sure unless I cat error.txt each time to make sure it built right.
I can see how errors.txt is useful, but the problem is that when you have it on, asm68k doesn't report anything to the console, and there's no error checking so the rest of the batch file runs, so you'll never know whether or not the build succeeded until you play your ROM, realize it didn't change, then check errors.txt. If we could do something like Code (Text): asm68k blah blah blah if errorlevel 1 goto error rem rest of stuff goto end :error echo build failed; see errors.txt for details :end this problem would go away.
While doing some bits here and there for my SMPS player, I came across this code snippet: Code (Text): word_72790: dc.w $25E, $284, $2AB, $2D3, $2FE, $32D, $35C, $38F, $3C5 dc.w $3FF, $43C, $47C, $A5E, $A84, $AAB, $AD3, $AFE, $B2D dc.w $B5C, $B8F, $BC5, $BFF, $C3C, $C7C, $125E, $1284 dc.w $12AB, $12D3, $12FE, $132D, $135C, $138F, $13C5, $13FF dc.w $143C, $147C, $1A5E, $1A84, $1AAB, $1AD3, $1AFE, $1B2D dc.w $1B5C, $1B8F, $1BC5, $1BFF, $1C3C, $1C7C, $225E, $2284 dc.w $22AB, $22D3, $22FE, $232D, $235C, $238F, $23C5, $23FF dc.w $243C, $247C, $2A5E, $2A84, $2AAB, $2AD3, $2AFE, $2B2D dc.w $2B5C, $2B8F, $2BC5, $2BFF, $2C3C, $2C7C, $325E, $3284 dc.w $32AB, $32D3, $32FE, $332D, $335C, $338F, $33C5, $33FF dc.w $343C, $347C, $3A5E, $3A84, $3AAB, $3AD3, $3AFE, $3B2D dc.w $3B5C, $3B8F, $3BC5, $3BFF, $3C3C, $3C7C I noticed something similar. Then I looked and... It's the FM note values present in the RAM. I've made a little table: Code (Text): 025e = (b-0) 0284 = c-1 02ab = c#1 02d3 = d-1 02fe = d#1 032d = e-1 035c = f-1 038f = f#1 03c5 = g-1 03ff = g#1 043C = a-1 047C = a#1 0A5E = b-1 0a84 = c-2 0aab = c#2 0ad3 = d-2 0afe = d#2 0b2d = e-2 0b5c = f-2 0b8f = f#2 0bc5 = g-2 0bff = g#2 0c3c = a-2 0c7c = a#2 125e = b-2 1284 = c-3 12ab = c#3 12d3 = d-3 12fe = d#3 132d = e-3 135c = f-3 138f = f#3 13c5 = g-3 13ff = g#3 143C = a-3 147C = a#3 1A5E = b-3 1a84 = c-4 1aab = c#4 1ad3 = d-4 1afe = d#4 1b2d = e-4 1b5c = f-4 1b8f = f#4 1bc5 = g-4 1bff = g#4 1c3c = a-4 1c7c = a#4 225e = b-4 2284 = c-5 22ab = c#5 22d3 = d-5 22fe = d#5 232d = e-5 235c = f-5 238f = f#5 23c5 = g-5 23ff = g#5 243C = a-5 247C = a#5 2A5E = b-5 2a84 = c-6 2aab = c#6 2ad3 = d-6 2afe = d#6 2b2d = e-6 2b5c = f-6 2b8f = f#6 2bc5 = g-6 2bff = g#6 2c3c = a-6 2c7c = a#6 325e = b-6 3284 = c-7 32ab = c#7 32d3 = d-7 32fe = d#7 332d = e-7 335c = f-7 338f = f#7 33c5 = g-7 33ff = g#7 343C = a-7 347C = a#7 3A5E = b-7 3a84 = c-8 3aab = c#8 3ad3 = d-8 3afe = d#8 3b2d = e-8 3b5c = f-8 3b8f = f#8 3bc5 = g-8 3bff = g#8 3c3c = a-8 3c7c = a#8
For those who haven't noticed, I've been updating the disassembly again recently. The latest things I added are long conditional jumps for when beq and suchlike are out of range. Here's an example: Code (ASM): jeq: macro loc bne.s @nojump jmp loc @nojump: endm
That's a pretty damn cool idea, it'll make fixing out of range errors much easier for people who are new to ASM. (Or maybe not, since most of them seem to prefer using a 5 year old disassembly instead :/)
Speaking of the Sonic 1 Disassembly, I've noticed that the obHeight and obWidth constants are incorrectly named - they need to be reversed: obHeight to obWidth and obWidth to obHeight. I'm not exactly sure how to do this myself as I've never updated the SVN before.
Problem being there aren't any references to the old labels. Additionally, most guides use the 2005 dissasembly, too.
This is the main problem why people aren't using this disassembly. The Sonic 2 SVN disasm references old labels, the 2005 labels could at least be referenced. Also, I'm sure most people would rather have a quick download rather than having to set up a SVN client for the latest version. As for the guides, that is true. Most people are used to the 2005 disassembly and they will probably use it until issues with the SVN disasm are fixed. Then, guides can be rewritten for the SVN disasm. And once that happens, somebody can fill up SCHG:Equivalent Subroutines
Code (ASM): y_radius = $16 ; collision width / 2 x_radius = $17 ; collision height / 2 The labels are right, the comments are wrong (width and height are switched around). I just fixed that in the S2 SVN, it should be fixed in this too.
I'm pretty sure the reason is because the older disassemblies are generally easier to obtain and setup, there as SVN (having to be downloaded individually unless an SVN client is being use (Which most who aren't deep within the community tends not to use anyway)) is not as easy. And my reason for not using Sonic 2 SVN is because of it's complexity, long lable names, macros' which make it easier but not understandable, and having the lables from the older disassemblies leaves it looking like a complete mess, and messy code tends to make the programmer feel less incline to work on their project, it's like climbing a mountain and seeing that what's up ahead is more bumpy than expected. As for the conditional jumps, not a bad idea and pretty genius, though I can see it being used in places where something more optimal could be written insted and have the same effect.
Just noticed that you uploaded the SVN version on the wiki. Are you going to manually upload the latest version every month as an attempt to get more people to use the disassembly? It's a good idea considering that the WebSVN downloads never work, but again, more people are used to the 2005 disasm.
I've fixed the obHeight/obWidth issue, and created a downloadable copy of the disasm here: http://info.sonicretro.org/File:Sonic_1_Di...ly_July_2010.7z Labels from old disassemblies will not be restored, because they're incorrect in many cases, and they make things look cluttered as MarkeyJester said.