Sonic and Sega Retro Message Board: Basic Questions & Answers thread - Sonic and Sega Retro Message Board

Jump to content

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

Basic Questions & Answers thread NEWBIES: Start here!

#5176 User is offline Clownacy 

Posted 21 July 2014 - 09:32 PM

  • Posts: 130
  • Joined: 06-July 13
  • Gender:Male
  • Project:Sonic 2 Clone Driver v2

View PostXeta, on 21 July 2014 - 06:22 PM, said:

Okay, so I've been using SMPS2ASM with a Sonic 1 disassembly to make music ports lately, and I'm trying to do Angel Island Act 1. I've fixed up the PSG and DAC, but this is a song that uses Sonic 3's UVB. So, I copy-pasta'd it from the Clone Driver v2 to the end of the song, but it still sounds totally messed up. Is there something I need to do to remove its dependency on the UVB and make it actually read from its own instrument table?

Did you make the song actually point to the copy of the UVB at the end of the song? It shouldn't be messed up if you did as you said. At least, I don't think it should.

To answer your question: There is no dependency outside of SMPS2ASM's smpsHeaderVoiceUVB. Switch that to a smpsHeaderVoice and you should be good to go. The only thing that differs a UVB song from a normal song is the goofy voice pointer. Once you put the UVB at the song's end and changed the pointer, you should be good to go, but it is awfully inefficient; it'd be worth trying to remove the unused voices. Look for the Voice Change commands (smpsSetvoice), and note the numbered IDs listed by them. Those are the IDs of the voices from the UVB that you want to keep. Once you have all the IDs noted, go through the UVB and copy the voices whose IDs matches those of the commands to the end of your song. After that, begin changing the Voice Change commands to match the new list of voices.

I want to say that backporting the Clone V2 to S1 is easy, but you've really got to know what you're doing. It requires a lot of code restoration, and even the relocating of the flag sound slots. Boo...

EDIT: Quoted due to page break
This post has been edited by Clownacy: 21 July 2014 - 09:54 PM

#5177 User is offline redquebec 

Posted 21 July 2014 - 10:45 PM

  • Posts: 8
  • Joined: 29-April 14
A basic question, but interesting. How far could we trust the ROM Headers? I recently tried to organize a lot of beta roms, and I try to rely on the date included in the rom headers. It seems correct, building up chronologically.

Is it true for released Genesis games? Here are the info from the last official No-Intro romset, the date in header, and the release date:
Sonic The Hedgehog Apr-91 4M 23-Jun-91
Sonic The Hedgehog 2 Sep-92 8M 21-Nov-92
Sonic The Hedgehog 3 Nov-93 16M 02-Feb-94
Sonic & Knuckles Jun-94 16M 18-Oct-94

If the infos are correct, that means they were ready to deliver way ahead their sales. Does that seemed correct? Was Sonic 3 really completed by November 1993? How are the build date generated at first? At compile time or was it a manual entry?

#5178 User is offline OKei 

Posted 21 July 2014 - 11:33 PM

  • OKeijiDragon
  • Posts: 1390
  • Joined: 04-September 05
  • Gender:Male
  • Location:Blah
  • Project:My MOTHER-fucking-3 Documentary
  • Wiki edits:11

View Postredquebec, on 21 July 2014 - 10:45 PM, said:

A basic question, but interesting. How far could we trust the ROM Headers? I recently tried to organize a lot of beta roms, and I try to rely on the date included in the rom headers. It seems correct, building up chronologically.

Is it true for released Genesis games? Here are the info from the last official No-Intro romset, the date in header, and the release date:
Sonic The Hedgehog Apr-91 4M 23-Jun-91
Sonic The Hedgehog 2 Sep-92 8M 21-Nov-92
Sonic The Hedgehog 3 Nov-93 16M 02-Feb-94
Sonic & Knuckles Jun-94 16M 18-Oct-94

If the infos are correct, that means they were ready to deliver way ahead their sales. Does that seemed correct? Was Sonic 3 really completed by November 1993? How are the build date generated at first? At compile time or was it a manual entry?
There would always be that large gap of time between the game actually finalized and the game actually reaching store shelfs, especially in the 8-bit and 16-bit eras. Game cartridges always had to take a lot of time and money to assemble and manufacture before being shipped to retailers. Normally, game carts would take up to two or three months to manufacture (depending on the amount of units the game publisher had ordered), and so developers had to finish a game before the deadline line given by publisher to be sent the master ROM to Nintendo or Sega to produce the carts. For high profile, mass-produced games as those four Sonic titles, those dates seem just about right. I'm no expert so I could be totally wrong though. But I don't think so. =)

I've never seen those ROM header completion dates before though, and I didn't know there could be dates attached to cartridge-based ROMs in their headers (I too would like to know how these dates are generated). The Sonic 2 date does ring a bell as the last known proto for that game was dated September 24, 1992. And come to think of it, S&K's last known proto was dated June 19, 1994 too.
This post has been edited by OKei: 22 July 2014 - 12:26 AM

#5179 User is offline Clownacy 

Posted 26 July 2014 - 12:29 PM

  • Posts: 130
  • Joined: 06-July 13
  • Gender:Male
  • Project:Sonic 2 Clone Driver v2
A while ago I read somewhere that multiplying a register by a multiple of 2 is best left to add, instead of a bit-shift, but only with words or longwords. So 'add.w d0,d0' is faster than 'lsl.w #1,d0'. Is there any truth to this?
This post has been edited by Clownacy: 26 July 2014 - 12:30 PM

#5180 User is offline FraGag 

Posted 26 July 2014 - 01:30 PM

  • Posts: 648
  • Joined: 09-January 08
  • Gender:Male
  • Location:Qu├ębec, Canada
  • Project:an assembler
  • Wiki edits:6

View PostClownacy, on 26 July 2014 - 12:29 PM, said:

A while ago I read somewhere that multiplying a register by a multiple of 2 is best left to add, instead of a bit-shift, but only with words or longwords. So 'add.w d0,d0' is faster than 'lsl.w #1,d0'. Is there any truth to this?

The answer to this is in the M68000 User's Manual, which lists (in sections 7 to 9) the number of clock periods each instruction takes to execute. We shall look at section 8, because as far as I know, the processor in the MD/Genesis operates in 16-bit mode.

We can see, for example, that ADD.W <ea>,Dn takes 4 clock periods, including 1 read cycle*, plus the effective address calculation time (table 8-4, page 8-4). The effective address calculation times are listed in table 8-1 (page 8-2). The calculation time for Dn is 0 clock periods, so it has no additional cost over the instruction's base execution time. Therefore, add.w d0,d0 simply takes 4 clock periods to execute.

We can also see that LSL.W to a register takes 6+2n clock periods (where n is the shift count), including 1 read cycle*. Therefore, lsl.w #1,d0 takes 8 clock periods to execute, which is more than add.w d0,d0 takes.

Likewise, it's faster to perform 2 adds than to LSL by 2: 2 add.w d0,d0 instructions take 8 clock periods to execute, while one lsl.w #2,d0 instruction takes 10 clock periods to execute. If we want to shift by 3, then it's equivalent: 3 adds takes 12 clock periods, and lsl.w #3,d0 also takes 12 clock periods. Shifting by more than 3 is faster with LSL than with a sequence of adds.

* At the very start of section 8, the manual states:

Quote

In this data, it is assumed that both memory read and write cycles consist of four clock periods. A longer memory cycle causes the generation of wait states that must be added to the total instruction times.

I don't know if the memory cycle on the MD/Genesis is in fact 4 clock periods, but in general, you'll want to minimize the number of reads and writes if you can. :)

#5181 User is offline GerbilSoft 

Posted 26 July 2014 - 04:00 PM

  • RickRotate'd.
  • Posts: 1958
  • Joined: 11-January 03
  • Gender:Male
  • Location:USA
  • Project:Gens/GS
  • Wiki edits:158
On the MC68000, adding a register to itself is faster than left-shifting by 1, since the shift function can only shift by 1 position at a time.

This changed on later CPUs, which added a barrel shifter. Barrel shifters can shift by any number of bits in a single cycle. The downside is it requires more transistors, which wasn't possible at the time of the 68000 due to cost and the manufacturing process, but was implemented on later processors after it became feasible.

Some CPUs that have barrel shifters:
  • Motorola 68020/30/40/60
  • Intel 80386 and later (but NOT Pentium 4)
  • ARM (in the instruction pipeline, which allows for a "free" shift on pretty much every instruction)


  • 346 Pages +
  • ◄ First
  • 344
  • 345
  • 346
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users