Sonic and Sega Retro Message Board: flamewing - Viewing Profile - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Loading News Feed...
 

Group:
Tech Member: Tech Members
Active Posts:
564 (0.59 per day)
Most Active In:
Engineering & Reverse Engineering (487 posts)
Joined:
11-October 10
Profile Views:
383
Last Active:
User is offline Private
Currently:
Offline

My Information

Age:
34 years old
Birthday:
April 19, 1979
Gender:
Male Male

Contact Information

E-mail:
Private
Website:
Website  http://

Previous Fields

Project:
Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
National Flag:
br
Wiki edits:
12

Latest Visitors

Topics I've Started

  1. SMPS2ASM and improved S&K Driver

    05 November 2011 - 01:39 PM

    Edit: v3 is out. The changes are:
    • Due to its effects in some S3, S&K and S3D songs, I undid the following bugfix:
      • [bugfix] original S3/S&K/S3D driver could not correctly handle playing the sequence "<note>, <duration>, $80, <duration>, <duration>", and would play <note> again instead of a rest.
    • S1 and S2 songs that were affected by the previous change got a new version that explicitly puts a $80 before the duration of each rest;
    • The "_spms2asm_inc.asm" file now handles the differences in modulation flags that are explained in http://forums.sonicr...t&p=669694]this post[/url] by ValleyBell;
    • I have made a release of the SMPS2ASM tool.

    For the SMPS2ASM tool, I am providing a Windows binary; for those of you that don't use Windows, I am also providing the source code; it is bundled with the source code of my S2 Special Stage editor, which you can nab here.


    Edit: v2 is out. Now includes S3's B2/B3 DAC samples and corrects the Sonic 3 Miniboss and Knuckles songs to use it. Also features the ASM'ed version of the credits medley from Sonic 3 Collection prototype 0517.

    Original post follows:

    As I have been saying elsewhere, I have written a tool that converts a binary music or SFX file (in SMPS format) to an 'universal' ASM format. I was planning on releasing this some two weeks ago; the delay comes about as a result of having to find and fix sound driver bugs, followed by illness; so sorry about that.

    The original idea for this kind of tool is Cinossu's (see his utility); I just made a better one that handles songs and SFX from Sonic 1, Sonic 2, Sonic 3, Sonic & Knuckles and Sonic 3D Blast. I will not be releasing the tool just yet: when I started writing it, I had no idea that the SMPS formats (coordination flags, mostly, but also DAC samples) changed so much between Sonic 1/2 and the others; I hacked them in, but my intention is to rewrite the tool so support for any given game is simply a matter of pointing it to a text file containing definitions.

    But there is no reason people should be denied the fruits of it; specifically: this file. (edit: updated link) The contents are:
    • All songs, SFX and DAC samples* from Sonic 1;
    • all songs, SFX and DAC samples* from Sonic 2;
    • all songs, SFX and DAC samples** and SFX from Sonic & Knuckles;
    • all songs and DAC samples** from Sonic 3D Blast;
    • all songs and DAC samples** from Sonic 3 that are not identical to songs from Sonic & Knuckles;
    • _smps2asm_inc.asm, a file that does the bulk of driver conversion;
    • 'Z80 Sound Driver.asm', a modified and improved version of the Sonic & Knuckles driver;
    • all DAC samples from Sonic 2 (of which the Sonic 1 samples are a subset), Sonic & Knuckles and Sonic 3D Blast.


    The included sound driver has tons of changes and fixes compared to the SVN version (some of which I will eventually optionally backport to SVN). They include:
    • [enhancement] You can select which DAC groups to use;
    • [enhancement] added a coordination flag for setting the tempo divider of a single track;
    • [enhancement] added a coordination flag for setting note fill in the same way it is done in Sonic 1/2 drivers;
    • [enhancement] added a coordination flag to send an FM command to the correct port (from Ristar);
    • [enhancement] added all PSG tones (actually volume flutter) from Sonic 1/2 (the Sonic 1 flutters are a subset of the Sonic 2 flutters);
    • [enhancement] removed unnecessary padding between songs;
    • [bugfix] original S3/S&K/S3D driver could not correctly handle a rest followed by a 'no attack' coordination flag, followed by a note;
    • [bugfix] fixed incorrectly handling of flag to set PSG noise (mainly, interactions with overriding SFX);
    • [bugfix] original S3/S&K/S3D driver could not correctly handle playing the sequence "<note>, <duration>, $80, <duration>, <duration>", and would play <note> again instead of a rest.


    As of this time, the driver is a drop-in replacement for the S&K disassembly; in the future, I will make edits to kram1024's tutorials to use this driver in Sonic 1 or Sonic 2 (unless kram1024 comes back and does it, as we were talking about before he disappeared).

    The _smps2asm_inc.asm file is based off of one from Cinossu's tool; I revamped it and updated it to perform the bulk of the conversion. It handles different pointer formats, different IDs of DAC samples, handles the 12-semitone (1 octave) difference between PSG notes in S1/S2 versus S3/S&K/S3D, and does the bulk of coordination flag conversion. While this makes it trivial to convert songs and SFX in general, converting to Sonic 1 or Sonic 2 drivers is a lot harder (unless you are converting from Sonic 1 or Sonic 2) due to the lack of necessary coordination flags.

    Please feel free to ask any questions that aren't clear after looking around in the driver (or which I failed to convey in this message...).

    * = Sonic 1's DAC samples are a subset of Sonic 2's DAC samples.
    ** = Sonic 3's samples are a subset of those from Sonic & Knuckles. Sonic 3D Blast samples are composed of $1D out of the first $1E DAC samples from Sonic & Knuckles, plus two unique samples.
  2. SVN down -- SSL handshake failed

    25 April 2011 - 03:46 PM

    Recently, updating from or committing to the community SVN has been failing with the error listed as the topic description:
    CODE
    svn: OPTIONS of 'https://sonicretro.org/asm_svn': SSL handshake failed: Secure connection truncated

    WebSVN is working correctly, but using any utility for actual SVN access has been failing.

    This is usually related to a server misconfiguration. 3 known causes for the issue (in Apache servers) are:
    1. custom VirtualHost entries in /etc/apache2/sites-available/default must be changed from <VirtualHost *> to <VirtualHost *:80>
    2. overly restrictive mod_ssl SSLCipherSuite parameter;
    3. system OpenSSL package does not match the one Apache was compiled with (this is usually due to an update in OpenSSL while Apache is running without a corresponding Apache update, and causes a time bomb problem when Apache is next restarted).


    A good value for SSLCipherSuite is:
    CODE
    ALL:!ADH:!EXPORT56:-AES256-SHA:-DHE-RSA-AES256-SHA:-DHE-DSS-AES256-SHA:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP:+eNULL


    Anyway, I hope this helps...
  3. Debugging misaligned read/write

    10 March 2011 - 08:45 AM

    Inside the spoiler tag below is the original post, which I am preserving; here is the new version.

    An address error happens on real hardware (or in good emulators such as Regen) whenever a word- or long-sized read or write happens at an odd address. So, for example, if you try to read the contents of address $FFFF0001 as if it were a word or a long, an address error will happen. Sonic 1 displays a simple error message; Sonic 2 locks up; Sonic 3 and Sonic & Knuckles reset the game. None of these scenarios are useful for finding out what caused the error, which is usually what prevents hacks from working on real hardware.

    I decided to include the bus error in the debugger solely because it has the same data available for debugging as an address error does; the changes were minor enough that I had no real reason not to include it, but I have doubts anyone will need it.

    Here is the debugger: address/bus error debugger; I explain below how it is used. I have tried it with the Hg disassemblies of S2 and S&K; I think it will work on Xenowhirl's 2007 disassembly for all those masochistic enough to insist on using an outdated disassembly; if it doesn't, I would appreciate knowing what errors are printed when assembling so I can fix them. At present, only AS is supported.

    To use the debugger, proceed as follows:

    1) Extract all files to the base directory on your disassembly. At any point (for example, at the end of the disassembly), add the following line:
    	include "Address Error.asm"
    

    2) Find the label 'Vectors:' at the start of the disassembly:
    S2 disassembly:
    Find this:
    ;Vectors:
    	dc.l System_Stack, EntryPoint, ErrorTrap, ErrorTrap; 4
    

    and change it to this:
    ;Vectors:
    	dc.l System_Stack, EntryPoint, BusError , AddressError; 4
    

    S&K disassembly:
    Find this:
    Vectors:	dc.l Vectors, EntryPoint, ErrorTrap, ErrorTrap	; 0
    

    and change it to look like this:
    Vectors:	dc.l Vectors, EntryPoint, BusError, AddressError	; 0
    

    3) Open the file "Address Error.asm". Locate the labels 'HackerName' and 'EMailmsg' and edit them to your heart's content; if 'EMailmsg' is empty, the entire line containing it will be eliminated (see image below). The text must be in all-capitals, and can include letters, numbers, spaces or the following symbols:
    ? @ [ ] \ ( ) + , - . / : ; # $ % & ! *
    

    4) Find the 'Revision' equate and change the number. This is so you can give an internal identifier to any build of the hack.

    5) When building the hack for testing, add '-g MAP' to the line invoking asw/asl. This will generate a file '*.map' file that associates each file/line of the source file(s) to an address on the final ROM. The build will be a lot slower, though.

    6)
    If you are using the Hg disassemblies, you are done. If you are using the S2 2007 disassembly, you still have to do a few things:

    a) Find the following lines in s2.asm:
    dma68kToVDP macro source,dest,length,type 
    	lea	(VDP_control_port).l,a5 
    	move.l	#(($9400|((((length)>>1)&$FF00)>>8))<<16)|($9300|(((length)>>1)&$FF)),(a5) 
    	move.l	#(($9600|((((source)>>1)&$FF00)>>8))<<16)|($9500|(((source)>>1)&$FF)),(a5) 
    	move.w	#$9700|(((((source)>>1)&$FF0000)>>16)&$7F),(a5) 
    	move.w	#((dest)&$3FFF)|((type&1)<<15)|$4000,(a5) 
    	move.w	#$80|(((dest)&$C000)>>14)|((type&2)<<3),(DMA_data_thunk).w 
    	move.w	(DMA_data_thunk).w,(a5) 
    	endm 
    	; values for the type argument 
    	enum VRAM=0,CRAM=1,VSRAM=2 
     
    ; tells the VDP to fill a region of VRAM with a certain byte 
    dmaFillVRAM macro byte,addr,length 
    	lea	(VDP_control_port).l,a5
    	move.w	#$8F01,(a5) ; VRAM pointer increment: $0001
    	move.l	#(($9400|((((length)-1)&$FF00)>>8))<<16)|($9300|(((length)-1)&$FF)),(a5) ; DMA length ...
    	move.w	#$9780,(a5) ; VRAM fill
    	move.l	#$40000080|(((addr)&$3FFF)<<16)|(((addr)&$C000)>>14),(a5) ; Start at ...
    	move.w	#(byte)<<8,(VDP_data_port).l ; Fill with byte
    -	move.w	(a5),d1
    	btst	#1,d1
    	bne.s	- ; busy loop until the VDP is finished filling...
    	move.w	#$8F02,(a5) ; VRAM pointer increment: $0002
    	endm
    

    and replace them with this:
    vdpComm function addr,type,rwd,(((type&rwd)&3)<<30)|((addr&$3FFF)<<16)|(((type&rwd)&$FC)<<2)|((addr&$C000)>>14)
    ; values for the type argument
    VRAM = %100001
    CRAM = %101011
    VSRAM = %100101
    ; values for the rwd argument
    READ = %001100
    WRITE = %000111
    DMA = %100111 
    dma68kToVDP macro source,dest,length,type
    	lea	(VDP_control_port).l,a5
    	move.l	#(($9400|((((length)>>1)&$FF00)>>8))<<16)|($9300|(((length)>>1)&$FF)),(a5)
    	move.l	#(($9600|((((source)>>1)&$FF00)>>8))<<16)|($9500|(((source)>>1)&$FF)),(a5)
    	move.w	#$9700|(((((source)>>1)&$FF0000)>>16)&$7F),(a5)
    	move.w	#((vdpComm(dest,type,DMA)>>16)&$FFFF),(a5)
    	move.w	#(vdpComm(dest,type,DMA)&$FFFF),(DMA_data_thunk).w
    	move.w	(DMA_data_thunk).w,(a5)
    	endm
    ; tells the VDP to fill a region of VRAM with a certain byte
    dmaFillVRAM macro byte,addr,length
    	lea	(VDP_control_port).l,a5
    	move.w	#$8F01,(a5) ; VRAM pointer increment: $0001
    	move.l	#(($9400|((((length)-1)&$FF00)>>8))<<16)|($9300|(((length)-1)&$FF)),(a5) ; DMA length ...
    	move.w	#$9780,(a5) ; VRAM fill
    	move.l	#$40000080|(((addr)&$3FFF)<<16)|(((addr)&$C000)>>14),(a5) ; Start at ...
    	move.w	#(byte)<<8,(VDP_data_port).l ; Fill with byte loop:
    loop:
    	move.w	(a5),d1
    	btst	#1,d1
    	bne.s	loop ; busy loop until the VDP is finished filling...
    	move.w	#$8F02,(a5) ; VRAM pointer increment: $0002
    	endm
    

    b) Open "Address Error Defs.asm" and replace the following lines:
    EniDec := Eni_Decomp KosDec := Kos_Decomp PlaneMapToVRAM := Plane_Map_To_VRAM
    

    with this:
    Chunk_Table := Metablock_Table
    PlaneMapToVRAM := ShowVDPGraphics 
    

    Once all of this is done, the screen is ready for use. To test it and see if it is working, you can add this code anywhere you are sure will execute:
    	movea.w	#$0001,a0
    	jmp	(a0)
    

    Of course, the disassembler does not initialize the z80 or the VDP, instead assuming that they have been initialized already; so the test code must go after the initialization code for them both, or you will get a black screen. Here is a sample of the output:
    Posted Image
    It has a readable version of all data saved on a bus/address error, all registers, and a disassembly of the instruction that caused the address error. The disassembler was hand-coded, and recovers as much information as possible. Jumps, branches and loops usually do not allow full recovery, with jsr, bsr, and being exceptions. Nevertheless, only jmp will be an issue because all the others are caught by the assembler when building the ROM. The disassembler also warns when the disassembly could not retrieve all information.

    Being in possession of all this data and of the map file allows you to quickly find where the error happened and give you an idea why.

    I would appreciate if anyone could test this on real hardware; I know it works on Regen, but I don't know if Regen works the same way as real hardware does with respect to the behavior of the program counter.

    For those that got this earlier in another thread: this version has a bug fix on the disassembler, and does not need separate versions for S2 and S&K disassemblies; you should grab this version.

    Spoiler


    Please ignore this attachment, it is of the older version:
  4. Sonic 2 Special Stage Editor

    09 February 2011 - 09:56 PM

    Edit: New version released:
    Posted Image

    Changes:
    • Fully functional undo/redo: you can now undo your mistakes -- whether it is the deletion of a ring group, a segment or even an entire special stage. The undo/redo are also smart, grouping many related actions.
    • WYSIWYG drag/drop of selections.
    • Rings and bombs can now be drawn in lines, loops, triangles and more in a click-and-drag manner, adding several rings and bombs in a WYSIWYG manner.
    • Added a counter showing total rings, bombs and ring/bomb shadows. This can be used to keep them within limits, which would prevent a segment from ever ending.
    • Grid-lock (toggled through toolbar button, defaults to on) constrains the possible angles for ring and bomb placement.
    You can grab the Windows binary or the source code.

    The original content of the post has been wrapped in spoiler tags.

    Spoiler


    Edit: You can also grab these files in my Google code project.
  5. Sonic Classic Heroes

    02 November 2010 - 02:14 PM

    Quick links:
    Wiki page (Sonic Classic Heroes)
    Wiki page (Sonic 2 Heroes)
    Latest revision (v0.07f6)
    Latest preview video

    Edit: New revision is out.

    Revision 0.07f6: Download it here

    Changelog:
    Bugs fixed from previous revision:
    • Knuckles could gain anti-gravity glitch on Scrap Brain Zone by standing on a vanishing platform as it vanishes if Tails was not standing on that same platform.
    • Fixed some wrapping bugs.

    Bugs fixed from the original games:
    • Jumping from rolling into the MTZ yellow spring walls left you without control, forcing you to use a double-jump action.



    Older revisions and their changelogs are folded below:

    Spoiler

    The rest of the original post follows:

    View PostXenowhirl, on 01 November 2010 - 06:32 AM, said:

    It's been a while...

    "Team player" controls anyone? I just started this. I'll call it "Sonic and Tails and Knuckles in Sonic 2" if no one has a better idea. All three of them are capable of going Super separately too, but I don't know if I should give them separate ring counts or what.
    Posted Image Posted Image


    Argh. Dammit, that is the first hack I am working with and you do this! I was waiting for the hack to be closer to ready (such as character selection, Sonic's AI still does not have a proper animation for getting back on screen, special stages are probably broken), but here is what I have so far. I also have been digging through multitap code to implement 3-players, but so far you can swap the characters with 'A' (the 2nd player can also do this, but only with the AI-controlled players).