You can use it to save the data into SRAM and then just copy the output and store as the demo data. This may be of some use.
EDIT: Ralakimus inb4'd me. Yes, it can be reused. Above: Code (Text): move.w (Demo_button_index).w,d0 Place this: Code (Text): lea (ADDRESS).l,a1 Now, "ADDRESS" needs to be a rewrite-able address (such as 68k RAM), a place where the data can be "written" to and extracted afterwards. I'm not too familiar with Sonic 2 to know of a decent and appropriate RAM space to temporarily store the button presses and extract, but that would be the idea. For an example, we could use RAM address 00FF0000, when you're done, you can extract the demo data from either a gsx savestate at offset 2478, or by means of a 68k RAM dump (if the emulator supports such a feature). Another rewriteable address to take in mind, would be SRAM, though you'd need to ensure that the SRAM can be accessed on both odd and even offsets (if possible, not sure since it's technically a peripheral device), and if not, alter the routine to save to SRAM correctly by means of accessing only odd or even positions. You can then get the button press data directly from the SRAM file (though you may need to correct it if it is odd or even only writes).
Thanks both of you, I was able to get new demos recorded. Though the SRAM method didn't seem to be working for some reason, not sure why, I could still dump it to RAM address $FFFFF100 without any problems.
So sometimes I go back to my hack to try some small bits, and my latest experiment was to have a Sonic Colours inspired HUD, as can be seen here: My question is, how can I move the score to be on the opposite side of the screen to the rest? Manually moving the score section to the right in SonMapEd simply results in it not appearing after a certain point. This might be a dumb question, but I'm just not sure how to go about it.
In Sonic 1, you can't move sprite pieces for more than 128 pixels from the sprite center, determined by object's XY-coordinates. HUD is Obj21 and its coordinated to the left edge of the screen. Here's what you can do to try solving it the easy way: 1) Move Life, Rings and Time counters $78 pixels to the left (press Left arrow for these pieces 15 times, provided SonMapEd moves them by 8 pixels per press). If you move them too far, they'll warp and end up on the right side of the screen. 2) Open Obj21's code, find where X-coordinate is assigned and add $78 to it. Code (Text): move.w #$90,8(a0) becomes Code (Text): move.w #$90+$78,8(a0) 8(a0) appears something like obX(a0) or whatever if you're using modern disassemblies. 3) Move Score counter to the right. You should have more overhead for moving it now. If that doesn't still give you enough space, you'll have to split Score sprite to a separate object.
Thanks for the help, with some tweaking here and there I was able to get it laid out the way I wanted to. Thanks again!
ok I got a question... I imported Emerald hill's collision, tileset and everything from emerald hill over wood zone, but the loops are broken and I don't know how to fix it (what I mean by broken is that I start the loop but then I fall right throughit with the path swapper breaking the path and leaving me stuck in my hack. Emerald hill's work fine but the ones I added (replacing wood zone) don't... any help would be appreciated.:v:/>
The E in "score" is loaded separately from the rest (probably due to debug mode having to take up that space). The numbers are also loaded separately as well.
So if I wanted to start experimenting with the sound capabilities of the YM2612, what would be the best recommended way to go about it for a Mac-user? FMDrive looks excellent, but it is PC-only. I also came across GenMDM that directly interfaces with the chip itself, but seems to no longer be getting manufactured by the developer and it's going for exorbitant prices on the second-hand market. I would prefer not resorting to sound fonts, but if that's the only option, so it goes. Having no knowledge of how these kinds of things work, I also was curious to know if it is possible to remove and re-saughter the YM2612 to the board of a midi-keyboard that also uses a yamaha chip? I get the feeling it's a stupid question, but I thought I would ask anyway :P
I'm not a Mac-user, so pardon my ignorance here, but I would make the assumption that you can at least run a Mega Drive emulator of sorts. Now, if I remember correctly, there are a few playback tools that run on the Mega Drive itself, therefore, you can run them on an emulator, on your Mac. However, they aren't exactly user friendly, and you are limited to; not the YM2612, but rather, the software that's running and controlling it. If you're interested, I wrote one myself nearly 8 years ago here, but with this, you'd need to learn more about the format to put it to use (it also only works on less accurate emulators (leave me alone, I was young d=)). As for taking the YM2612 and plopping it into a keyboard that possesses another type of YM chip, I'm not certain this will work. You have for one, different chip designs (different sizes) and "probably" different voltage requirements, but I'm sure those can be got around. What probably cannot be got around, is the internal address/data values which WILL differ from chip to chip, even those of similar design. Though take this information as a grain of salt, I don't claim to know synthesiser chips from a hardware point of view, I'm only going by what appears to be logically sound based on only few bits of information, I could be wrong, and it could be as simple as ripping it from one place, and plopping it into another, I'm just expressing high doubts here.
Thanks so much! I just downloaded your tool and will give it a shot when I have a spare moment Yeah, figured there would be logistics that would stop transplanting the chip to another device; I imagine even if it COULD be done, it would probably be far more effort than it's worth. Thanks again
I have a question about something, and it's pretty far from basic, but I don't feel like this deserves it's own thread. Who here, aesthetically, prefers the Sonic 1 - style Level Select where the Title Screen art is still present in he background, and is just washed out? Of course, I'm asking this for a reason - I do, and for the hack I'm working on, I want to use that system in Sonic 2. I got the level select working fine and everything, works functionally identical to the level select in the Simon Wai prototype (Except, you know, the special stage option works). But, I want a bit more out of it. One major problem with the level select as is, is that with only one column for one level, screen space is REALLY cramped, and I don't have enough room to fit all my intended levels, so I need to expand - I need to at column support. I've gotten that working (almost) entirely, but there's just one thing I need to do before it's complete: Fix the highlighting. Right now, it's impossible to tell what level is being selected, and where there are some other bugs, that's the most pressing. To be clear, the level text is drawn on Plane B so the title art isn't destroyed, and here's the original code for a highlighted level: Code (ASM): textpos: = vdpComm(VRAM_Plane_B_Name_Table+planeLocH40(2,3),VRAM,WRITE) ; text position on screen LevelSelect_MarkFields: moveq #0,d0 move.w (Level_select_zone).w,d0 move.w d0,d1 move.l #$608C0003,d4 lsl.w #7,d0 swap d0 add.l d0,d4 lea (LevelMenuText).l, a1 ; Load Level Select Menu - Text mulu.w #LevSel_LineLength+1,d1 adda.w d1,A1 move.w #$C680,d3 move.l d4,4(A6) bsr.w LevSel_ChgLine move.w #$8680,d3 cmpi.w #LevelSelctLines-1, (Level_select_zone).w bne.s LevSel_DrawSnd move.w #$C680,d3 LevSel_DrawSnd: rts ; --------------------------------------------------------------------------- ; Subroutine to draw one line of the level selecct. ; --------------------------------------------------------------------------- ; ||||||||||||||| S U B R O U T I N E ||||||||||||||||||||||||||||||||||||||| LevSel_ChgLine: moveq #LevSel_LineLength, d2 ; number of characters per line LevSel_LineLoop: moveq #0, d0 move.b (A1)+, d0 bpl.s LevSel_CharOk move.w #$0000, (A6) dbf d2, LevSel_LineLoop rts LevSel_CharOk: cmp.w #$40, d0 ; Check for $40 (End of ASCII number area) blt.s LevSel_CharOk_notText ; If this is not an ASCII text character, branch sub.w #$3,d0 ; Subtract an extra 3 (Compensate for missing characters in the font) LevSel_CharOk_notText: sub.w #$30,d0 ; Subtract #$33 (Convert to S2 font from ASCII) add.w d3,d0 ; combine char with VRAM setting move.w d0,(a6) ; send to VRAM dbf d2,LevSel_LineLoop rts I've made attempts to port Sonic 2's markfields code over, but it's not as simple as changing Plane A to Plane B.... Anybody have any insight?
Inbetween the "move.l #$608C0003,d4" and the "lsl.w #7,d0", you will need to place the following: Code (Text): cmpi.w #ROWS,d0 bcs.s LSMF_StartColumn LSMF_NextColumn: subi.w #ROWS,d0 addi.l #$001C0000,d4 cmpi.w #ROWS,d0 bcc.s LSMF_NextColumn LSMF_StartColumn: Replace all three "ROWS" with the number of rows per column you're going to display (or an equate if necessary). The "1C" will control the number of tiles horizontally per column, increase it by 2 to extend by 1 tile, decrease by 2 to reduce by 1 tile. Since it's a comparison/subtraction loop, you can have as many columns as the screen will permit you (you can have several columns of 3 tiles if you wanted). This assumes of course, that the rest of the level select runs as status quo, though do experiment.
Thanks, MarkeyJester, but I think I confused Rows and Columns... This is what I'm getting right now, unless something's not right? I literally have this: Code (ASM): LevelSelect_MarkFields: moveq #0,d0 move.w (Level_select_zone).w,d0 move.b (a4,d0.w),d0 ;Get the needed column for this zone. move.w d0,d1 move.l #textpos,d4 ; MarkeyJester: cmpi.w #SelectableRowLength,d0 bcs.s LSMF_StartColumn LSMF_NextColumn: subi.w #SelectableRowLength,d0 addi.l #$001C0000,d4 cmpi.w #SelectableRowLength,d0 bcc.s LSMF_NextColumn LSMF_StartColumn: lsl.w #7,d0 swap d0 add.l d0,d4 lea (LevelMenuText).l, a1 ; Load Level Select Menu - Text mulu.w #LevSel_FullWidth+1,d1 adda.w d1,A1 move.w #$C680,d3 move.l d4,4(A6) bsr.w LevSel_ChgLine move.w #$8680,d3 cmpi.w #LevelSelectOptionCount, (Level_select_zone).w bne.s LevelSelect_DrawSoundNumber move.w #$C680,d3 Textpos = vdpComm(VRAM_Plane_B_Name_Table+planeLocH40(2,1),VRAM,WRITE) LevSel_FullWidth = $24 ;The length of one entire row in tiles. Used for printing text. SelectableRowLength = $22 ;Number of selectable rows. LevelSelectOptionCount = (LevelSelect_StartZone - LevelSelect_Order)/2 ;Automatically generated using level order table.
The problem is likely "LevSel_FullWidth", it's the size of 24. To understand why it's a problem, 28 is the entire screen's width. So you technically need half of that, or rather, half of 24 (which is 12). Like I said, the code assumes that the rest of the level select runs as status quo. I cannot advise anything else without much context.
So, I was wondering if it were possible to extract the textures/sprites from Sonic Dash? I tried the java app disunity but, only the 0.4 release kinda worked and it only extracted some of the audio files. I'm mainly trying to extract the various genesis cart textures used for the Classic Sonic promotion going on. They've got a great version of the lock-on Sonic 3 & Knuckles and I really would love to look at that texture closer if possible. edit: crap. Sorry. I hit submit by accident. Was just going to post this question in the Basic Questions & Answers thread instead.
I might be a bit late asking this question but is there a "COMPLETE" guide to adding Knuckles into Sonic 2
Right from our very own SCHG which you can find at info.sonicretro.org. PS Hey MODS WHY CANT I STILL EDIT THE WIKI????? EDIT: Got ninja'd by the creator of said guide... well, really... try his guide out anyway and just work from there... we all can help you out if you get stuck anywhere anyhow...
