Find My Content- Group:
- Tech Member: Tech Members
- Active Posts:
- 832 (0.48 per day)
- Most Active In:
- Engineering & Reverse Engineering (687 posts)
- Joined:
- 11-October 10
- Profile Views:
- 12045
- Last Active:
Yesterday, 08:56 PM- Currently:
- Offline
Yesterday, 08:56 PMMy Information
- Member Title:
- Emerald Hunter
- Age:
- 36 years old
- Birthday:
- April 19, 1979
- Gender:
-
Male
- Location:
- Brasil
- Interests:
- In no order: physics, computers and computer programming, reverse engineering, Ultima, Sonic, TASes, atheism, skepticism
Male
Contact Information
- E-mail:
- Private
- 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
- SA2 Emblems:
- 31
Topics I've Started
-
Big's Fishing Derby
15 February 2015 - 09:48 PM
Edit (already): new revision $D9 which fixes input issue in real hardware. Grab it here.
The surprise hack that took last year's contest by storm and almost won the Big Trophy because everyone thought it was the trophy for having Big on a hack, Big's Fishing Derby is finally here. And with some hefty changes from the contest.
Grab revision $D8 here.
(amazing box cover art by themisterfalcon; see below for links for high res versions)
Changes from hacking contest version:
- Amazing new title screen art by E-122-Psi (Big's new sprite still not done);
- Results screens for 1p mode (completion times, for time attack) and 2p mode (who won which stage, who won overall, how many wins each player has);
- Reworked introduction cutscene;
- Brand new ending cutscene in 1p mode;
- Destroying badniks now free imprisoned animals;
- Improved sound driver capable of 6 FM tracks in addition of 5 FM + 1 DAC track;
- Ported over SADX's Sega PCM with Big (with compliments to MainMemory);
- Correctly aligned credits, and fixed MainMemory's;
- Added an entropy pool that collects entropy from several sources and uses it to seed the RNG;
- Gameplay demos if you leave the game on long enough;
- "Press start button" flashes a few times then becomes invisible in 1p mode; p2 can still join at any moment, and will trigger boss music;
- Fixed several bugs in relations to powerups, including the infamous mine crash;
- Mines used for offense now cause the other player to lose rings, work even if he has nothing hooked (being a setback) and fails if the attacked opponent has active invincibility;
- Fixed TM symbol on Japanese MDs;
- Fixed several graphical oddities.
You can grab the box and cartridge art here:
(US versions being done)
Proud winner of the following 2014 Sonic Hacking Contest trophies:
Polygon Jim Trophy: Most unique hack submitted
Robotnik's Revenge Trophy: Best fresh concept using existing concepts as the backbone in a hack submitted
Froggy Trophy: Best implementation of Big the Cat in a hack submitted
Polygon Jim Community Trophy: Voted most unique hack submitted
Are you having fun with Big's Fishing Derby? Do you wish there were more levels?
Well, you can help! Here is what a level needs:
- Background art for the above-water portion; this uses two palette lines at most, and needs a deformation routine, palette cycles, and maybe even dynamic art reloading;
- art for the platforms; these must use the third palette line (the first of the level's palette lines) and are limited to 16 tiles by 5 tiles;
- either background water for the underwater portion or a mention that the "default" underwater background should be used (needs at least one underwater palette line for the platforms, if they extend far down enough, and maybe one more underwater palette line if it has an unique underwater background);
- underwater ripple data or a specification of a default one (LZ, CPZ, ARZ);
- a preferably unique badnik design, possibly including a "charging" animation, with its own palette line (make sure the badnik fits the level in some sense);
- two music tracks for the level, a "primary" and an "alternate" track;
- water surface graphics and wave pattern, or specify a default one (LZ, CPZ, ARZ, TTZ);
- an emerald design (S1, S2, S3, SCD, or a brand new one) and base colors (the flashing I can generate automatically).
I prefer to add an even number of levels each time, so that the total number of levels is an odd number; this guarantees that competition mode can never end in a draw. So if you have suggested a cool new level I haven't added after some time, it is because I am still looking for another level to make a pair. Also, make note of how I edited several backgrounds (ICZ and QQZ are good examples) to change the parallax so a more complete background would be in view; don't just rip a background and discard most of it trying to fit the waterline, be creative.
For added fun, set up a TeamPlayer and try monkeying around with the 3rd controller you set up. Make it a 6-button controller and try pressing mode. By the way, the first part worked on the hacking contest version too, but the second part is only on the new version. - Amazing new title screen art by E-122-Psi (Big's new sprite still not done);
-
Optimizing the DMA queue
09 August 2014 - 01:00 PM
Edit: The improved DMA queue (and instructions for its use) can now be obtained on GitHub. This post will no longer be updated with new developments, but the thread will.
Edit: I make corrections to account for the edge cases described on this post and on this post. Rest of original post follows.
I have been going over the list of things to optimize in the original Genesis games, so I can get Sonic Classic Heroes to work as smoothly as possible. One of the things I just finished optimizing was the DMA queue management function, and I was amazed at how much I managed to save. I am now sharing this so everyone can benefit.
The new functions require that you do two things before you can use (which I will detail later): the first is going through your assembly files and changing the way the queue is cleared; the second is calling the initialization function for the new DMA functions. At the end, you will have gained two bytes in RAM, and a DMA queue that runs much faster.
How much faster? Well, it depends. There are 3 different DMA functions that are used nowadays:
- The stock S2 function;
- the stock S&K function;
- the Sonic3_Complete version that is used when you assemble the Git disassembly with Sonic3_Complete=1.
The stock S2 function is the fastest of the 3:
- 52(12/0) cycles if the queue was full;
- 336(51/9) cycles if the new transfer filled the queue;
- 346(52/10) cycles otherwise.
The stock S&K function is 8(2/0) cycles slower than the S2 version, but it can be safely used when the source is in RAM (the S2 version requires some extra care, but I won't go into details). So its times are:
- 52(12/0) cycles if the queue was full;
- 344(53/9) cycles if the new transfer filled the queue;
- 354(54/10) cycles otherwise.
The Sonic3_Complete version is based on the S&K stock version; it thus also safe with RAM sources. However, it breaks up DMA transfers that cross 32kB boundaries into two DMA transfers(*). The way it does this adds an enormous overhead on all DMA transfers. Its times are:
- If the source is in address $800000 and up (32x RAM, z80 RAM, main RAM):
- 72(16/0) cycles if the queue was full;
- 364(57/0) cycles if queue became full with new command;
- 374(58/10) cycles otherwise;
- 72(16/0) cycles if the queue was full;
- If the source is in address $7FFFFF and down (ROM, both SCD RAMs):
- If the DMA does not need to be split:
- 294(53/10) cycles if the queue was full at the start;
- 586(94/19) cycles if queue became full with new command;
- 596(95/20) cycles otherwise;
- 294(53/10) cycles if the queue was full at the start;
- If the DMA needs to be split in two:
- 436(83/30) cycles if the queue was full at the start;
- 728(124/21) cycles if queue became full with the first command;
- 1030(166/31) cycles if queue became full with the second command;
- 1040(167/32) cycles otherwise.
- 436(83/30) cycles if the queue was full at the start;
- If the DMA does not need to be split:
Yeah, you are wasting hundreds of cycles by using the Sonic3_Complete version... but even more than you think when you note the asterisk I added above. You see, the VDP has issues with DMAs that cross a 128kB boundary in ROM; the Sonic3_Complete tries to handle this, but is overzealous -- it breaks up transfers that cross a 32kB boundary instead. Thus, loads of DMAs are broken into two that should not be broken at all... leading to several hundreds of wasted cycles. The function is bad enough that manually breaking up the transfers would be much faster -- potentially 2/3rds of the time.
So, how does my optimized function compare with this? There are two versions you can select with a flag during assembly: the "competitor" to stock S2/stock S&K versions, which does not care whether or not transfers cross a 128kB boundary; and the "competitor" to Sonic3_Complete version, which is 128kB safe. Both of them are safe for RAM sources, and done so in an optimized way that has zero cost -- the functions would not be faster without this added protection. The times for the non-128kB-safe version are:
- 48(11/0) cycles if the queue was full at the start;
- 194(33/9) cycles otherwise.
The times for the 128kB-safe version are:
- 48(11/0) cycles if the queue was full at the start (as always);
- 214(37/9) cycles for DMA transfers that do not need to be split into two;
- 252(46/9) cycles if the first piece of the DMA filled the queue;
- 368(64/16) cycles if both pieces of the DMA were queued.
I will leave comparisons to whoever want to make them. I will just mention that if you use SonMapEd-generated DPLCs and you are using the Sonic3_Complete function, you are easily wasting thousands of cycles every frame.
Well, so now how to add this function to your hacks.
Git S2 version
Spoiler
Git S&K version
Spoiler
The new function
Spoiler
Additional Care
There are some additional points that are worth paying attention to.
128kB boundaries and you
For both S2 or S&K (or anywhere you want to use this), the version that does not check for 128kB boundaries is the default. The reason is this: you can (and should) always align the problematic art in such a way that the DMA never needs to be split in two. So enabling this by default carries a penalty with little real benefit. In any case, you can toggle this by setting the Use128kbSafeDMA option to 1.
Transfers of 64kB or larger
If you have enabled the version that breaks DMAs into two if they go over a 128kB boundary, this is relevant for you. There is an option that saves 4(1/0) cycles on the case where a DMA transfer is broken in two pieces and both pieces are correctly queued (that is, the first transfer did not fill the queue). This option assumes that you never perform a transfer with length of 64kB or higher; note that 64kB is included here! In these conditions, a small optimization exists that leads to the small savings mentioned. This is disabled by default to avoid this edge case.
Interrupt Safety
The original functions have several race conditions that makes them unsafe regarding interrupts. My version removes one of them, but adds another. For the vast majority of cases, this is irrelevant -- the QueueDMATransfer function is generally called only when Vint_routine is zero, meaning that the DMA queue will not be processed, and all is well.
There is one exception, though: the S3&K KosM decoder. Since the KosM decoder sets Vint_routine to a nonzero value, you can potentially run into an interrupt in the middle of a QueueDMATransfer call. Effects range from lost DMA transfers, to garbage DMA transfers, to one garbage DMA and a lost DMA (if the transfer was split), or, in the best possible outcome, no ill effects at all. You can toggle interrupt safety by setting the UseVIntSafeDMA flag to 1, but this adds overhead to all safe callers; better would be to fix the unsafe callers to mask interrupts while the DMA transfer is being queued.
ASM68k
If you use this crap, all you need to do to use the code above is:
- replace the dotted labels (composed symbols) by @ labels (local symbols);
- replace the last two instances of "endm" by "endr";
- edit the VRAMCommReg macro to use asm68k-style parameters.
Spoiler - The stock S2 function;
-
Generic error debugger + disassembler
30 January 2014 - 02:26 PM
Edit: I made a new version fixing a bug and adding a binary-blob version. See this post for more information. The original post now follows:
I was going to make this an update to the old topic... but decided it would be best suited to a new topic entirely.
So, you remember that aging debugger I made for address/bus errors? I updated. A few things that changed:
- The disassembler is now logically separate from the drawing code and from the debugger (the debugger depends on both of them, the disassembler depends on the drawing code);
- I made sure that the code almost fully position-independent, meaning a binary blob can possibly be made (but see below);
- loads of bug fixes;
- recovers more information from branches and jumps, and does so correctly now for dbCC opcodes;
- brand new font;
- handles far more errors than just the address and bus errors (the latter of which I have since learned never happens on a real Genesis...);
- has code that will make macro haters want to stay away.
There is another warning I must give: I won't give support for anything but the Community disassemblies, so if you insist on using outdated disassemblies, you are on your own.
With those out of the way: first, let me explain how you will go about generating a listing file. In the previous version, I talked about map files; listing files are much better because they are generated much faster; the S2 and S&K disassemblies disable it by default, though. In S2, you have to edit 3 places: one in s2.macrosetup.asm and the rest in s2.asm; so:
in s2.macrosetup.asm: find this:
listing off
and change it to this:
listing purecode
You can also use "on" or "noskipped" instead of "purecode", but I recommend using the latter. So now over to s2.asm, do the same twice. Now whenever you build your hack, a s2.lst file will also be generated.
For S&K, you have to do the same once in sonic3k.macrosetup.asm, then in sonic3k.asm find this:
Z80_Snd_Driver: include "Sound/Z80 Sound Driver.asm"
and change it to this:
Z80_Snd_Driver: include "Sound/Z80 Sound Driver.asm" listing purecode
Now that you are armed with listing files, time to hook up the new debugger! So go on ahead and grab it here. There are seven files in this archive; only 6 are needed for S2, the seventh is for compatibility with the S&K disassembly. Extract these to your hack's main folder. You can move these around, as long as you edit the includes in the relevant files. You want to add these includes:
For S2:
include "_inc/Debugger.asm"
For S&K:
include "skcompat.asm" include "Debugger.asm"
These are enough to get everything working; he other files are pulled in automatically. Now the debugger is being assembled inside your hack; you want to setup the interrupt vector table to make use of it:
In S2: find ";Vectors:" and replace the whole table with this:
;Vectors: dc.l System_Stack , EntryPoint , BusError , AddressError ; 4 dc.l IllegalInstrError , ZeroDivideError, CHKExceptionError, TRAPVError ; 8 dc.l PrivilegeViolation, TraceError , LineAEmulation , LineFEmulation ; 12 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 16 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 20 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 24 dc.l SpuriousException , ErrorTrap , ErrorTrap , ErrorTrap ; 28 dc.l H_Int , ErrorTrap , V_Int , ErrorTrap ; 32 dc.l TrapVector , TrapVector , TrapVector , TrapVector ; 36 dc.l TrapVector , TrapVector , TrapVector , TrapVector ; 40 dc.l TrapVector , TrapVector , TrapVector , TrapVector ; 44 dc.l TrapVector , TrapVector , TrapVector , TrapVector ; 48 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 52 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 56 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 60 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 64
In S&K: find "Vectors:" and replace the whole table with this:
Vectors: dc.l Vectors , EntryPoint , BusError , AddressError ; 4 dc.l IllegalInstrError , ZeroDivideError, CHKExceptionError, TRAPVError ; 8 dc.l PrivilegeViolation, TraceError , LineAEmulation , LineFEmulation ; 12 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 16 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 20 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 24 dc.l SpuriousException , ErrorTrap , ErrorTrap , ErrorTrap ; 28 dc.l H_int_jump , ErrorTrap , V_int_jump , ErrorTrap ; 32 dc.l TrapVector , TrapVector , TrapVector , TrapVector ; 36 dc.l TrapVector , TrapVector , TrapVector , TrapVector ; 40 dc.l TrapVector , TrapVector , TrapVector , TrapVector ; 44 dc.l TrapVector , TrapVector , TrapVector , TrapVector ; 48 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 52 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 56 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 60 dc.l ErrorTrap , ErrorTrap , ErrorTrap , ErrorTrap ; 64
If you try to assemble and you get errors, it is because you are using an older version of AS; get the new version and replace the ones you have. The Git repositories for the Community disassemblies already have this version, by the way.
Now you just need to trigger an error to see it in action; but if you do that, you will notice that your name and e-mail are wrong; so open "Debugger.asm" and find the following lines:
HackerName: vtstring WHITE,"Your name" EMailmsg: vtstring BLUE ,"[email protected]"
Except that the e-mail will not be in yellow and underlined, that is just the forum software being an ass. Anyway, supported colors are WHITE, RED, GREEN and BLUE; you can edit the text at will, but your name should not exceed 11 characters -- this is all the space available in the current setup. As the comment near this says, you can use any of the characters int he ASCII set.
Another thing to do is edit the value of the "Revision" constant in the same file -- this number can be used to uniquely identify the version in which the error happened, so you will know if you already fixed the error or not.
When all is said and done, this is what you will see (using two manufactured examples):
As a bonus: since the code is logically separate, the disassembler can be used on its own; here is an example of a minimal disassembler that can be build using it:
This was done with this code:
DisassemblyTest: bsr.w InitTerminal lea DrawTerminal(pc),a3 tellp.l -(sp) ; Save end of buffer setcursor DisassemblyAlign,0 .instr_loop: shared .instr_loop move.l (sp),d0 ; Get end of screen buffer vtchkp.l d0 ; Is this after current position? blo.w .draw_terminal ; Branch if not tellp.l -(sp) ; Save start of line move.w (a3)+,d5 ; Read instruction lea RewindStub(pc),a4 ; Pointer to rts bsr.w Disassemble_Opcode movea.l a2,a3 ; PC for next instruction tellp.l d0 ; Save current position on buffer seekset (sp)+ ; Seek back to old position .next_line: seekp.l nCols ; Advance it by one line vtchkp.l d0 ; Is this after current position on buffer? bhs.s .next_line ; Branch if not bra.s .instr_loop ;--------------------------------------------------------------------------------------- .draw_terminal: addq.w #4,sp ; Pop end of screen buffer from stack bsr.w DrawTerminal .error_trap: nop nop bra.s .error_trap ; ===========================================================================
-
SMPS2ASM and improved S&K Driver
05 November 2011 - 01:39 PM
Edit:
New version of the sound driver is available: grab v2a here.
New version of SMPS2ASM is available: grab v0.2 here.
New version of the song pack is available: grab v4a here.
Changes:
- driver: now with support for playing songs with 6 FM channels and no DAC channels;
- driver: universal voice bank (UVB) is now included in every music bank; while this reduces the space in banks, this allows much more freedom for expanding the sound driver;
- driver: UVB has been SMPS2ASM'ed;
- driver: all fixes and changes are now always on;
- driver: driver makes use of local labels (instead of nameless temporaries) and uses S2-style memory management for the z80 RAM (instead of hard-coding everything);
- driver: several new coordination flags and fixes based on other drivers from ValleyBell's research pack; specifically:
- meta CF $FF08 (smpsChanTempoDiv) which works like CF $E5 in S1/S2 drivers;
- meta CF $FF09 (smpsChanFMCommand) that allows sending FM commands to the appropriate YM2612 part for the current track;
- meta CF $FF0A (smpsNoteFill) that works like $E8 did in S1/S2 drivers;
- meta CF $FF0B (smpsPitchSlide) that allows you to do pitch slides (use smpsAlterPitch to set slide speed);
- meta CF $FF0C (smpsSetLFO) that lets you enable/disable the LFO and set AMS and FMS.
- meta CF $FF08 (smpsChanTempoDiv) which works like CF $E5 in S1/S2 drivers;
- SMPS2ASM: can now dump z80 banks given an offset to a pointer table within the bank;
- SMPS2ASM: simple dataflow analysis added to propagate key displacement changes throughout a track; this is used to fix the handling of the maximum-frequency PSG note (since it is different in S1/S2 and S3/S&K/S3D drivers);
- song pack: redumped all songs with the new SMPS2ASM;
- song pack: S3, S&K and S3D songs (and SFX for S&K) now have two versions: the 1:1 versions with unused data and the "optimized" versions without it; the optimized versions also have ALZ song fixed.
A warning: songs dumped with the new SMPS2ASM MUST be used with the "_smps2asm_inc.asm" file present on the sound driver file; earlier versions of the include file will fail. Moreover, I strongly recommend that you redump old songs so that they sound correct due to the PSG maximum-frequency note issue mentioned above.
To use the driver, you will need to either use the constants for zQueueVariables, zMusicNumber, zSFXNumber0 and zSFXNumber1 like what is descriped in Alriightyman's guide to use it in S2 or use the exported symbols for these constants to reference the correct z80 variables.
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 this post 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. - driver: now with support for playing songs with 6 FM channels and no DAC channels;
-
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:
CODEsvn: 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:- custom VirtualHost entries in /etc/apache2/sites-available/default must be changed from <VirtualHost *> to <VirtualHost *:80>
- overly restrictive mod_ssl SSLCipherSuite parameter;
- 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:
CODEALL:!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...
