I think most people replace move.X label(pc,dN.w),dest with lea label,aN / move.X (aN,dN.w),dest, but your way works too.
Is there a full list of all compression methods used on Megadrive / Genesis games and how they work? I remember Saxman commenting on his James Pond 3 thread that the Kid Chameleon (possibly Dynamite Headdy, I can't remember exactly) graphics compression was the most effective he has ever seen. I know that Sega Retro contains some notes on the Nemesis compression routine but I wondered if there was a full list of all of the compressors and how they work. Sorry, if this is obvious, just feeding my curiosity.
From what I've seen on the wiki, only the main KENS compression is up, with exception to the Saxman LZ compression which doesn't seem to be documented. There might be a few additional compressions up hidden away (The cracker's art compress for example). But in general, it seems only the stock compressions provided by SEGA (KEN(-S)) is documented. I think it would be nice to have a page dedicated to compression forms from various games of the Mega Drive, kind of like the list of Sound Drivers that we have. Even if the compression itself isn't documented (yet), a list would be useful.
Okay, having another problem because I seem to be completely incapable of troubleshooting /> I'm hoping someone can help me with this, it's a bit more... Specific. Kind of. Using Markey's Sonic 1-28 as a reference, I've ported over the 128 chunks, planeswappers, and 2-layer collision to my Sonic 1 disassembly (running on HG). Here's the thing, though: The planeswappers aren't working. I've ported over the object code, and I've checked that both collision layers work properly when the "active plane" RAM value is set, but in-game, there's no effect. I ported over the level layouts included in 1-28 to make sure everything ported correctly, so the planeswappers are exactly the same. I've tried even looking at the two files side-by-side but I just can't find anything that explains what's going on. I figure it's a bit of a long shot, but does anyone know where I should start looking/what might be going on here? EDIT: FUCK ME I'm DUMB, figured it out.
I can respect wanting to figure it out on your own... but that said, may I suggest trying the pre-made HG 128 disassembly here? Might save you a little bit of trouble. NOTE: there are still a couple of bugs to be had there... involving using the Revision JP1 mode... as noted earlier on by some members. Mainly with regards to background tilesets that are modified in the JP1 revision. I've been too lazy to fix that but I will at some point.
I provided a fix for REV01 here, but I haven't come across any background graphical issues. Go check it out, perhaps there's something there that you might be missing.
I took a peek at it, yeah. In the end I figured I'd try it myself, because I figured I'd get a better understanding out of doing it. As for bugs, after looking at it, I can't say I've seen what you're referring to (in the HG version you've made). Kinda off-topic, but what exactly isn't working properly?
I can name at least one background being shot in the arse, and that is Marble Zone's. There are some clouds close to the mountains that aren't supposed to be there. From what I know, they're a leftover from the REV00 version of the background. I think the clouds overlapped incorrectly too, but don't quote me on that. EDIT: Applied MJ's fix to HiveBrain Two-Eight disassembly with REV01 backgrounds, the above problem's still there. Of note, the HG version's DrawBlocks_2 does differ from MJ's guide's loc_712C. While MJ's calls for this: Code (ASM): andi.w #$FF,d3 ; '' ror.w #7,d3 ror.w #2,d3 ; MJ: ..plus an extra 2 (so it's within 80 bytes, not 200) andi.w #$70,d4 The HG SVN community one uses this: Code (ASM): andi.w #$FF,d3 ; MJ 128: keep within 7F lsl.w #7,d3 ; MJ 128: multiply by 80 andi.w #$70,d4 ; MJ 128: keep Y pos within 80 pixels Changing that doesn't seem to have an effect on the above problem though.
Indeed, there is very little documentation on Saxman compression; the best I found was a very rough draft by Saxman, which did not do a very good job of documenting it. I suppose I could write up some documentation for it; the Saxman formatS are very simple (there are actually two very similar variants, one for z80 and one for 68k), and I have hands-on experience with it.
The design of MZ is done such that the clouds are suppose to give the impression they are behind the mountains. Due to the main hardware quirk of plane scrolling, naturally the clouds will scroll along with the mountains. So unless you edit the level graphics so that clouds don't display there, or construct some sort of art updating to give the illusion of clouds running behind the mountains, I'm afraid you're stuck. I also wouldn't class that as a "bug". SYZ however with its cut off mountain is a bug. And the cause of that is down to the fact that SYZ does not redraw the backgrounds horizontally based on specific X positions. All sections wrap to display the first two chunks over and over on a repeat. The original REV00 code had a special system setup for each background section, to have its own horizontal drawing, see "LevSz_Unk" for details and you'll find this table: Code (Text): dword_61B4: dc.l $700100, $1000100 <- GHZ dc.l $8000100, $1000000 <- LZ dc.l $8000100, $1000000 <- MZ dc.l $8000100, $1000000 <- SLZ dc.l $8000100, $1000000 <- SYZ dc.l $8000100, $1000000 <- SBZ dc.l $700100, $1000100 <- Ending (GHZ) Now, the actual values are split into words, not long-words. Each zone has four words, each word represents the Y size of each scroll section starting from the top, as you can see, GHZ's is 0070 pixels for the top part, and 0100 pixels for the next part. The other two 0100 pixel words on that line are unused, and they are unused because the current draw code only takes two scroll sections into account. However, when progressing to REV01, they ditched this system and resorted to "specific" routines to deal with the scrolling. The scroll sections themselves are still used, but instead of using the table above, they used a specifically unique table, here is SBZ act 1's for example: Code (Text): unk_6DF4: dc.b 0 ; unk_6DF5: dc.b 0 ; dc.b 0 ; dc.b 0 ; dc.b 0 ; dc.b 6 ; dc.b 6 ; dc.b 6 ; dc.b 6 ; dc.b 6 ; dc.b 6 ; dc.b 6 ; dc.b 6 ; dc.b 6 ; dc.b 6 ; dc.b 4 ; dc.b 4 ; dc.b 4 ; dc.b 4 ; dc.b 4 ; dc.b 4 ; dc.b 4 ; dc.b 2 ; dc.b 2 ; dc.b 2 ; dc.b 2 ; dc.b 2 ; dc.b 2 ; dc.b 2 ; dc.b 2 ; dc.b 2 ; dc.b 2 ; dc.b 2 ; dc.b 0 ; Where the values 0, 2, 4 and 6 represent one of the four scroll sections (I.e. scroll blocks), where: 00 = FFF700 02 = FFF708 04 = FFF710 06 = FFF718 Each of those RAM spaces (being a word each) being changed using the call to the "ScrollBlock#" routines. This is a nice method, except the original REV00 method (with applied four sections) would have done the job perfectly fine, due to how simple the background designs of Sonic 1 are. It would have saved them time and space too. So it's mind boggling to think that they went to such trouble in creating specific routines for these backgrounds. The only level that doesn't have one that really needed one, is SYZ. It does not perform any "ScrollBlock#" calls except for one that only alters the Y position redrawing, leaving the X position stuck in place and drawing the same two chunks over and over again. To fix the issue with the older REV00 system (if it were setup for using 4 scroll blocks) would have been extremely simple to do, unfortunately with REV01, it'll require a unique routine possibly with a unique table of values like SBZ and MZ, etc. It'll also require calling the right "ScrollBlock#" routines and using the right X position RAM storage locations (The current REV01 SYZ background uses the main FG X position for all sections and simply alters the speed accordingly, which alters the scroll positions but not the draw section positions).
Hi, I'm having the most strangest error when trying to build my hack "Sonic: Into the Void" which is a sonic 1 hack. Recently I've added the sonic 3 sound driver to it. The error what keeps on popping up is: ... \SONIC INTO THE VOID V3.1\SONIC1.ASM<1> : Error : Illegal Character , ' , <239> in input Errors during pass 1 - pass 2 aborted I've gathered that the <1> means the error is on the first line in the file "SONIC1.ASM" but when I've opened up the file in visual studio, there's nothing on the first line. I don't know what the <239> means, but I honestly don't know what to do, and the thing is, I've tried to backtrack by "CTRL-Z" ing, to the point where I know it was working and the error is still there. To import the sonic 3 driver, I have tried to use the Sonic Retro's version but I get a whole bunch of incorrect op-code errors, but still get above error. So I've merged the unideal SSRG version of importing the driver with this one and it worked fully, and as I can remember my last pause was when I got up to sorting the sound C0 in the Sonic Retro's version. Then after that, it went kaput. Can someone help me with this very annoying error as soon as possible please, it will be much appreciated! Thanks
Hi, PROBLEM SOLVED! The problem probably was that the original file went corrupt somewhere. So I've solved it by opening an older SONIC1.ASM file and copying and pasting the new code to the old, which replaced the old file, then moved the new file elsewhere, and moved the old file to the current version file and then, it works. So if anyone has this problem, the above tells you how to solve it, if you didn't know. Thanks.
I know exactly what your problem was: your text editor converted s1.asm from ASCII to UTF-8, inserting a byte order mark (U+FEFF), which in UTF-8 is represented as EF BB BF. EF in hex is 239 in decimal. Also, this probably belongs in Engineering & Reverse Engineering, since it's related to a Sonic disassembly.
I'm sorry, are we talking about the same thing? Some cloud art is printed on the same software... 'scrolling plane' as the mountains. This is present in all REV00's, but not in the 256 REV01, SCHG or official. This is also present in all 128 equivalents. In fact, if you compare the art of the lowest row of clouds on the 256 REV01 background to the second lowest row of clouds (counting the mountain clouds) on all of the 128s', they appear to use different art; they use the same art they did in REV00. On my incomplete S2 port, the highest row uses underground art. They simply seem to be allocating the wrong art. Sonic 1 REV00 Spoiler Sonic 1 REV01 Spoiler Sonic 1 Two-Eight REV00 Spoiler Sonic 1 Two-Eight REV01 Spoiler Sonic 2 REV00 Spoiler Sonic 2 REV01 Spoiler EDIT: Fail grammar
Oh wow, hah, I totally hadn't noticed. I still don't see it as a "bug", more of a design quirk. You're only real way of "fixing" it though as I said, is by altering the mappings.
Oh man, I feel like a moron. I could have sworn I had checked this before with no results, but it literally was down to the mappings. REV01 had different chunk mappings, and here I thought the only change was to fix a certain block misalignment you can see in Act 3. Two-Eight's should just need updating to fix the problem.
Okay, I've got a slightly advanced question for you guys, but it -shouldn't- be too hard. I was just having trouble with a few parts of of it. The Block Table and Chunk Table in Sonic 2 take up TONS of Ram, $C00 bytes and $8000 bytes, respectively. Obviously, that's a lot, and I would like to eliminate the Chunk Table from my hack (I don't care about the Block table, but I think I'll ultimately need that space for this anyway). The problem is that the Chunk Table is used for right many things in Sonic 2, besides just storing chunk data (Hill Top Zone is a prime example of this). My Blocks and chunks are already uncompressed, so that's step one I've taken care of already. So, is anyone willing to step me through the process if they know?
I may not have a step-by-step, but one solution to HTZ's unique chunk layout would be to copy EHZ's chunk file and manually merge it with HTZ's, then remove the checks and code for HTZ that would merge the two in RAM, this can be done with the other instances. It might be worth trying to adapt ReadySonic's method of using uncompressed chunks. If I remember correctly, chunk_table was replaced with a longword RAM address that functioned as a pointer. However, my past attempts at adapting said method to Sonic 2 have all ended in failure due to lack of understanding. I don't have access to a computer at the moment to use for reference, so I'm going from memory here.
That is not the problem. Hill Top Zone's Blocks are patched by loading EHZ's, and then decompressing special blocks over it. The chunks however, aren't merged in such a way, but many of them are bugged out, when in fact, they are EHZ's exact chunks with nothing unique about them. At any rate, HTZ's block and chunk data unique already; EHZ isn't in my hack. I in fact did do that, and got it to load the chunks fine, but there were 2 problems: 1: The collision didn't seem to load 2: That doesn't resolve the other isolated cases where the chunk table is loaded to do something outside of the normal game.I want to entirely eleminate the Chunk table so that RAM is completely free.
You're not going to be able to free up ALL of the RAM, there has to be a buffer somewhere for the title card letters and other things that get decompressed to RAM before being copied to VRAM. As for the collision, it's probably using a shortcut to load $FFFF0000 into the register by doing moveq #-1,reg / clr.w reg. This is done by GetBlockAddr, sub_E244, and Floor_ChkTile. If you need to get merged tiles and blocks for HTZ or WFZ, you can just use LevelConverter to convert the level to Sonic 2 format, and it'll output combined files.
