Well, d-d-double poost! It's been a day, and I want to say a few words. First: the title screen was a big surprise for me. The last version I played was source code. I like it, although it is clear that this is not the final version. The menu seems simple, and with extra characters at the bottom (test for French characters?) When you take the monitor with an increase in speed, the effect while running is the same as in mania. It's beautiful and cool. You have replaced the monitor in d.m. with a monitor with a super shape. That's smart, but you should replace the graphics with the "S" from Sonic 1 or CD The EHZ2 palette is very beautiful. As well as all the other alternative palettes in this game. OWZ is not finalized again. A pity. This is the first and so far (not for long, I promise you ) the only interpretation of this zone in rom hacks, and I want to have something tangible already. SSZ is cool, but, unfortunately, not finalized. Tails' flight is not implemented badly. I really like. HPZ is just as good, but the second act is not playable again. It is sad. DEZ 1 does not pass without D.M., and this is also depressing. As a result: the hack is not very bad. It has potential, and I will definitely wait for the continuation! I haven't played the French version, but if you need a Russian translation, you know who to contact B) P.S.: I think, "The return of Dr. Eggman" is not good name for this hack, because you wait new story, and, new tricks, but you get reloaded concept art conceptions. Sonic 2 plus was good name for that, IMO
So far, it's really cool! I love the title screen as well. Snazzy! Ocean Wind is utterly gorgeous (both backgrounds). I think that if you work on it more, the final product could truly be something special! Keep it up! I'm gonna keep my eye on this.
Anybody remember this? Not sure why I bothered, but I recreated it using code that wasn't made mostly by someone else. None of the bugs from the version I put out years ago plague this release. I figured since I have since scrapped using it in Sonic: Full Throttle, I'd at least do something with the code for it. Also, I threw in my resetonfloor improvements for the hell of it. Download
My friend Cioss and I were working on this hack for a while now and it's ready to go now. We present to you: The grandma from Coco in Sonic 1! This hack adds the beloved grandmother from one of the most beloved Pixar classics "Coco" into Sonic 1! Will you be able to defeat the evil Doctor Eggman before he takes over the world? Will you be able to save the world before dying of exhaustion? Check it out yourself if you want :D Spoiler: Title Screen EDIT: Since some people can't download this file from here I decided to upload it on my google drive: https://drive.google.com/file/d/1kr7c1oesjRE5ATN1LBCrqOm9k10-XHXJ/view?usp=sharing
I love a good meme hack every once in a while, and this is pretty funny. My only critique is that I wish it were more, well, playable. But then again, who is genuinely wanting to play all of Sonic 1 as Coco? Pretty cool hack.
The comma would likely have been a "TM" symbol or something of the like, probably related to the unused SEGA characters. Either way, nice work~
That does make sense. Now that I think about it, that mini-Sega logo, along with the ROM only having the 'U' region code, might well be leftovers from when it was conceived as a region lockout. Might also explain why the checksum doesn't match the ROM (perhaps it was calculated for an earlier build). And thanks. <3
Don't know how useful this will be since I don't know if anyone else here uses BBEdit as their main code editor, let alone use macOS as their primary platform, but I made a custom BBEdit language module tailored to the Sonic disassembles. It supports all 68000, 68010, and Z80 mnemonics and registers, and also adds keyword highlighting to many of the macros, functions, and assembler directives/commands used in all of the SonicRetro disassembles as well as Hivebrain's and my own disassembles of Sonic 1 and 2.
Hello All! Last year I made a basic GHZ layout hack, and I made some adjustments based on the feedback I got, and designed two more acts. I added a lot more rings this time (shout out to Project FM's Sonic 3 Object/Ring Manager reference), so I increased the extra life ring count to 120 rings instead, for extra challenge. Let me know what you think!
Subtract the LZ length from "v_kos_prgram_counter", and if carry is clear, do an entire copy loop like normal. If carry is set, add the "v_kos_prgram_counter" to the length (it's negative so it'll subtract to get the remaining length of the bank), then do the copy loop of this length, then do the bank switch, then load out "v_kos_prgram_counter", negate it to positive, and use that counter for the second half of the copy, then add the bank size to "v_kos_prgram_counter" (which should still be negative), and it'll get the remaining size of the next bank. This will be done once before the copy loop starts, instead of every single byte of the copy loop, and should significantly speed up decompression. --- --- --- --- --- --- --- --- --- --- --- For the ultimate speed up, and assuming the destination is always fixed at the same starting address $420000. Rewrite the compressor to monitor the size as it's compressing, and split LZ copy loops if they overflow the boundary. You could then perhaps insert the unknown/"does nothing" bitfield patterns of Kosinski inbetween the split copies, and use it to mark it as reaching the end of a bank, then your code doesn't need to check, it just changes the bank when it reaches the "does nothing" bitfield. The "does nothing" bitfield (if you're interested) is 01 #### #### #### #000 (# is normally the offset, and the three 0's is the length). The byte being read next should be $01. It's actually in your code still too: Code (Text): subq.b #1,d4 beq.w .FetchNewCode ; If cnt=1, fetch a new code. If the destination is spurious, then obviously, this won't work... But it's worth thinking about.
Admittedly hadn't actually looked at the algorithm in depth until now, and realized that there may in fact be a huge problem with this approach: while this handles destination writes across bank boundaries, it doesn't handle dictionary match sources that cross or are on the other side of bank boundaries, since it assumes the entire decompressed stream is accessible at once. Since the maximum length for a match is only $100 bytes if I'm not mistaken, there may be a workaround by detecting such matches (e.g., the effective address of the match is less than $420000) and copying them to a buffer in main RAM (bankswitching before and after or during the copy when required), then copying from the buffer to the final destination. Much more complex, but probably not impossible.
You know what, the copy stream between two banks didn't occur to me either... Perhaps a variation of the moduled version of kosinski would be appropriate here. As long as modules are slot within the bank areas, no two modules reference each others data. There are drawbacks, it assumes the starting write address is fixed to ensure the end of a module matches the end of a bank, and compression is slightly less effective. The module decompression window is a power of two, so you have some wiggle room for pricise start addresses in the bank. Either way you look at it, you'll have to make some relatively significant modifications.
Went ahead and followed through with my idea (and incorporating your suggestions for keeping track of bank lengths), but alas still untested (and I don't think there will be an easy way to test it thanks to the lack of any debugging-focused Mega CD emulators).
Swap: Code (Text): sub.l d4,(v_kos_prgram_counter).w ; deincrement counter subq.w #1,(v_kos_prgram_counter).w ; -1 to compensate for loop counter ...for... Code (Text): moveq #$01,dX add.l d4,dX sub.l dX,(v_kos_prgram_counter).w (dX being a free register to use) The carry overflow won't work if the subtractions are split, it has to be in one go. "Gens Re-Recording v11a" has debugging features to see into memory, and control CPU flow. It's one of the few which actually supports Z80 CPU control. I haven't checked, but I wouldn't doubt there being Sub-CPU debugging features appearing if one were to load an ISO. It don't think it supports mode 1, so I suggest making a test ISO, copying a test program (along with the kos and some data) into Main-CPU RAM, letting it run, and watching it in the debugger. Using keys R-F, E-D, and W-S to navigate the RAM viewer. T, Y, U, I, O and P advance the CPU. N skips a BUS word. You should be able to switch between Main-CPU and Sub-CPU in the debugger, so you can advance the CPU slowly, then observe the program RAM. It'll be annoying to switch back and forth, but you're low on options here.
