 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by d4s |
| Pages: 1 2 3 4 5 |
| User | Post | ||
d4s Shyguy                   Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by Bio duuude, 80% of your code is pushing and popping stuff. for example, you dont have to save y to the stack when you dont modify it.also try to use more jsrs instead of static jumps. i bet your problem is either accumulator/index width or incorrect jumps. also, be sure your assembler translates the lorom adresses correctly and knows what size the accumulator is. the following code snippet does the exact same thing as your code, just simpler, more flexible and with 13 lines of code instead of 28. 
you could make it even shorter, but that would probably reduce the readability. .org $d948 ;watch the different offset! jsl MarioLuigiJump .org $somewhere MarioLuigiJump: sep #$20 ;be sure that your assembler knows the size of the accumulator! pha lda $0db3 beq MarioLuigiJumpCase1 pla clc ;clear carry, that opcode was overwritten by our jsl adc $c453,y rtl MarioLuigiJumpCase1: pla clc ;clear carry, that opcode was overwritten by our jsl adc $d7a5,y rtl oh, and snes adress $00  948 in lorom mode is rom adress 0x5948, just in case you didnt know.
also, keep in mind that your rom most likely has a $200 byte header, so snes adress d948 would be 0x5b48 in a hexeditor if your rom has a header. one last thing: if you want to learn how to code effectively, take a look at other games disassembly. there are lots of little tricks and optimizations you can do specifically on the snes' processor you will hardly find documented on the net. just DONT assume smw is a good example of how to drive the hardware, its horribly static and unflexible most of the time. (edited by d4s on 12-01-05 03:47 PM) (edited by d4s on 12-01-05 03:49 PM) (edited by d4s on 12-01-05 03:52 PM) (edited by d4s on 12-02-05 05:54 AM) (edited by d4s on 12-02-05 05:56 AM) |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by andres well, i wouldnt call it help, its rather a completely new feature. i coded that hdma stuff entirely from scratch. some people tend to believe that i just magically digged up a feature in smw that was previously hidden, thats not true of course. smw in its original form wasnt capable of doing any advanced hdma effects at all and certainly not multiple ones at the same time. but thanks, anyway.
i just have the feeling that 95% of the users here cant really appreciate the hdma kit because they have no idea just how much work was put into it and how advanced this whole thing is compared to your usual "make mario jump higher"-asm hack, in terms of complexity. thats kinda sad, but i guess i'll have to live with that. (edited by d4s on 12-01-05 04:25 PM) |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by BMF54123Originally posted by d4sI can vouch for that. My HDMA system is nowhere near as complex as yours, and doesn't have any spiffy user-friendly tools, but it still took me days to figure out exactly how it should be implemented. yeah, ive grown used to that.
besides, i dont think i'd still be here if i was deriving all my motivation from the reactions of others. however, i think that breath of fire 2 will be my last "serious" romhacking project anyway. i moved on to a point where i find it much more challenging and rewarding to develop stuff from scratch rather than hack existing games. for example, i finished programming a mod music player on the spc700 the other day, was quite hard to pull off. who knows, maybe i'll drop that into smw one day for the hell of it and you guys will finally be able to do real custom music and sound effects.
this whole n-spc driver stuff is way too limited for my liking. imho, a completely different sampleset for each tune plus a way to upload samples/sound effects during runtime to be able to do some basic voice acting is a must for a half-decent sound driver. (edited by d4s on 12-01-05 08:59 PM) (edited by d4s on 12-01-05 09:10 PM) |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
| old news!
and i really mean it, like 15 year old news. besides, you can get that very same unit (gd7) and the above-mentioned flashcart for $70 each on tototek.com. and if you want to have your hacks on a real snes cartridge, my suggestion would be to have a look at my homepage dealing with selfbuilt snes cart: http://snesdev.romhack.de Originally posted by Trinity dw:tlc is 48mbit, too much for the gd7 in that auction. smo crashes on real hardware. in fact, many hacks dont work on real hardware. (edited by d4s on 12-03-05 03:42 AM) |
|||
|
d4s Shyguy  Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by Bio no problem. =) how about not coding in hex? its a total waste of time, i cant understand why anyone would still want to do this. get a decent 65816 assembler with rom-patching ability (wla dx for example), and you will be able to: 1) produce readable and commentable sourcecode 2) use labels 3) let the assembler take care of all the adress calculation stuff i really mean it, start using an assembler now, you wont get very far without one. (edited by d4s on 12-04-05 02:46 PM) (edited by d4s on 12-04-05 02:46 PM) |
|||
|
d4s Shyguy  Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by KailieannOriginally posted by d4s hehe i feel sorry for you in case that wasnt meant to be ironic. |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by MathOnNapkins i dont say nothing against being able to code in hex first in order to grasp the whole concept of machine language, id even say its imperative to understand the concept of hex, adressing and such before you are able to learn assembler, but as soon as you start doing more ambitious projects, you will have a very, very hard time with hex coding, you cant deny that. i think your example of driving a car without knowing whats inside better fits the topic of c/c++ versus assembler. in that case, the compiler translates a high level language into low level machine code the user doenst have to be familiar with at all.(although its highly reccomended, of course) assembler and hex coding, on the other hand, are not two different languages, assembler sourcecode is just a different representation of machine code. the underlying concept and idea are exactly the same. thus, if you can grasp the concept of assembler, you have understood everything thats needed to master hex coding and vice versa, you already know whats "under the hood". the only difference is the vastly improved flexibility. you probably guessed it already, i dont have a problem with people coding in hex in order to better understand assembler. i have a problem with people believing hex coding is superior to assembler, or that, in order to "keep it real", you have to prefer hex coding over assembler. thats bullshit. |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
| ive heard from various sources that xkas is superior to wla dx.
for example, wla dx wasnt really meant to be a 65816 assembler in the first place after all, its a matter of personal preference. i think i currently use wla dx cause thats whats got me started, my small library of functions relies on wla dxs functions etc. i will look into xkas later this week. |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by BioOriginally posted by d4s great to hear you sorted it out. in the beginning, it can be difficult to get things like accu size, pushing and popping and jumps right on the first try. you'll eventually master it, just keep on practicing
in case you dont do that already, i suggest using geigers snes debugger. btw, are you sure $D7A5 does what you want/believe it to do? doublecheck if youre unsure, cause if your routine isnt crashing, theres litte that can go wrong with it. |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by Keitaro im not sure if i understood your question correctly, so i'm gonna reword it. you have a table in the rom thats at some point uploaded to the spcs memory. the table is loacted between other data in the rom, giving you no room for expansion. thus, you want to put it somewhere else in the rom. once the table is uploaded to the spcs memory, theres plenty of free space behind it so you dont have to worry about expanding it there, right? i dont have the rom here, so i cant check that for myself ok, this is how you do it (you probably know some of this already): -locate the table in the rom. -fire up geigers snes debugger. -set a read breakpoint to an adress in the table (remember: snes lorom adress) this will give you the routine(s) that access the table. most likely, it will just be one. trace back how it sets up the pointer to the table using the cpu logging feature. it will most likely be totally static, for example something like ldx #$3e00 lda #$00 stx $00 sta $02 jsl UploadStuffToSpc and then it will most likely load from that pointer like so: lda [$00],y or it will load the pointer from a pointertable, probably 2byte with fixed bank. what you will want to do is modify the pointer to the table. mind you, i dont know how the game does that in detail. you have to tell me what rom youre using exactly in order to help you there. regular smas? smw + demo world 3 patch? oh, and by the way: rom adresses have nothing to do with spc adresses. it doesnt matter to the game where your table is in the rom. the table will most likely be part of a data set. the actual upload location for that table is either passed to the spc seperately (often in form of a small header in front of the actual data thats uploaded) or the spc already knows where to put it. either way, you dont have to worry that it will be uploaded to a different location if you just change the rom adress of the data. (edited by d4s on 12-06-05 06:46 AM) (edited by d4s on 12-06-05 06:47 AM) |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by insectduel ZOMG!!!!!!!! 
who is ssm, anyway? |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
| yeah, right.
if software fails, blame the cpu! 
i say its the printer! |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by Sukasa unless you dont mind that your changes will be erased once they scroll out of the screen boundary: yes. |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
| you can also use tile priority to make only selected tiles of a layer translucent.
the concept is a bit hard to grasp for people who have no idea how the PPUs actually work, though. do some trial and error and you will eventually succeed. however, i dont know if lunar magic supports per-tile priority editing for the layers. |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by HyperHacker you dont use layer priority to do transparency, you use it to put individual tiles in front of the translucent layers. obviously, you'll have to enable color addition and put a layer on the subscreen for that to work. i think the above-mentioned level modes 1e and 1f handle that for you. say bg1 is on the subscreen with color addition enabled. bg2 is on the mainscreen. all tiles on bg2 without the priority bit set will appear behind translucent layer 1, and thus are affected by the color addition. the tiles on bg2 that have the priority bit set will be rendered after (=in front of) bg1 and remain unaffected by the color addition. thats how you make different tiles on one layer translucent and opaque at the same time, simple as that. funny that this is news to you guys, cause thats pretty much basic knowledge when it comes to snes graphics. (edited by d4s on 01-12-06 02:10 PM) (edited by d4s on 01-12-06 02:15 PM) (edited by d4s on 01-12-06 02:16 PM) |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
some of this has been answered already, but im gonna comment on some stuff, anyway.
Originally posted by Rom Manic the spc700 is just a processor, like the snes' main processor, thus its executing a program. what that program does doesnt necessarily have to result in musical notes or even audio, for that matter. the snes sound system consists of spc700 and dsp. the dsp is the chip that actually generates the sound. in order to play sounds or music on the snes, the cpu first uploads one or more data blocks to the tiny audio ram (64kb) by communicating with the spc700 through the i/o ports. one of this data blocks contains a program the spc700 starts executing, another one may contain samples and so on. in order to play music or any sound in general, the spc700 has to tell the dsp when to trigger certain samples at a certain pitch. how the spc actually does that is entirely up to the programmer. however, the dsp only accepts samples in brr-format (brr stands for bit rate reduction). its a lossy compression with a 32/9 compression rate. it certainly doesnt accept data in mp3 format. btw, the snes sound chips sport a 1989 copyright and have you seen any post-1991 console that has built-in hardware-support for mp3, anyway? i doubt it. Originally posted by Ailura i made it and that was a tech demo, you werent meant to be able to start the game at all, geez... 
btw, i didnt destroy the smw soundsystem, i completely replaced it. the whole point of that demo was to test how hard it would be to port my music player to another game, nothing more and nothing less. for the record, im using the very same music player in my bof2 intro, so if you're curious how it works, have a look at that smw demo. Originally posted by Gideon Zhi you are right, its no mp3 decoder. it works like this: the song is about 6mbits in size, in brr format, and present in the rom file. the spc sets up a 6kb buffer in the audio ram that, to the dsp, looks like a single looping sample. basically, this buffer gets constantly rewritten by seperating the song into small chunks that are then uploaded to the spc through the i/o ports every frame, while the dsp is playing the sample. of course, the timing has to be perfect and you cant afford to loose sync. and i can tell you that, although im just passing the data through to the spc without actually modifying it (well, apart from setting some flags in the brr data here and there), performance takes a noticeable hit, mostly due to the bottleneck of the i/o ports. sample rate is around 11khz, but the added echo effects and the low-pass filter make it sound quite nice. it might just be possible to decode mp3s on the snes using a combination of spc, 65816 and maybe sa1. however, you have to keep in mind that after decoding from mp3 to pcm, you also have to re-encode the output to brr, otherwise the dsp wont be able to play it back. imho the snes is one of the worst platforms you could try to write a software mp3 decoder for. a month ago, i also wrote a pro tracker (*.mod) player for the spc. turned out quite nice, apart from the fact that choosing the mod format was not so wise in the first place, cause that means 4channels only, amongst various other shortcomings. plus, a few volume change commands still cause a clicking noise, but i'll work that out eventually. you cant possibly imagine how hard it is to play back samples on the spc without clicking if you havent tried it yourself. this is one of the major downfalls of the brr format, imho. also, sample loop conversion is a bitch to get right if you're converting songs. and the two major emulators (snes9x, zsnes) still dont get the key on, key off regs right, if i might add. was a major pain to get this player sound right on both the emulators and a real snes. well, in case anyone is interested, here are two songs in spc file format that use my player: http://bof2.supernes.de/d4s_spc_mod_player_stuff.zip i think the song from super battletoads (arcade) turned out quite nice. cant say that of the ff7 victory tune, though, its absolutely crappy. its official, i suck at creating music.
i hope youre at least able to recognize that song. someone more talented would probably make it sound 10 times better than that. the battletoads song was tracked by someone else, it was a 200kb 8channel fast tracker module before, i just shrunk it down to 4channels and 50kb. (edited by d4s on 01-14-06 05:22 AM) (edited by d4s on 01-14-06 05:44 AM) |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by Sukasa just have a look at that "game". it uses badly ripped character tiles for mario, yoshi etc, tries to badly imitate mario worlds physics and uses crappy renditions of mario worlds tunes. i highly doubt nintendo supplied them with anything to code that thing. the one fact that really makes it obvious is that their apu driver doesnt even support envelope effects. i had a quick look at the format the music patterns are stored in, and it appears to be very linear and grid-like, looks alot like a pro-tracker derivate. based on that, i'll say its highly doubtful it uses the n-spc format. (edited by d4s on 01-14-06 11:02 AM) |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by Sukasa do you really like the music that much? rather than disassembling everything, it might be quicker to rip the samples, then try to recreate the songs in a common music format like pro tracker, for example. you'd have to somehow recreate the music by hand anyway, in case solar soundtrack gets released. you could also try to contact the composer, sam powell, maybe he will send you his original files over. most developers are really friendly and helpful if you are nice, polite and show some respect for their work. his current email adress is sam@plyitagn.com. good luck. (edited by d4s on 01-14-06 05:44 PM) (edited by d4s on 01-14-06 05:45 PM) |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
| yet another ct retranslation?
anyway, good luck. |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6030 days Last view: 5928 days |
| ||
Originally posted by Rom Manic hate to say it, but i dont think you've understood how mp3 works at all. that's a common problem, people without experience in the field of romhacking or programming in general tend to oversimplify things. "just throw some simple formula and a mp3-file at the spc, piece of cake!" its not that easy, dude. im not saying that to diss you, its just the way it is. i'm no expert on mp3s either, but at least i took a couple of minutes to look up how decoding an mp3 actually works. the important steps involved in restoring pcm audio from a mp3 bitstream are as follows: -Huffman decoding -inverse quantization -inverse discrete cosine transform (the mdct you referred to is only used in the encoding process, not for decoding mp3 files) -filter-bank reconstruction from 32 sub-bands (these 32 sub-bands together form the whole audible tonal bandwidth, 60hz-20khz or so) heres a rough outline of how i understand it, probably not very accurate: after examining the frame header, the huffman-compressed data needs to be decompressed. this gives you 32 still quantified frequency sub-band lines. next, you inverse-quantify the sub-band lines to their original size, then create "samples" from these lines using the imdct formula. keep in mind we are still working with 32 different sub-bands that all need to be processed one after another. finally, these 32 sub-band samples are mixed together into one pcm audio stream using the filter-bank reconstruction. now, to be able to actually play bank that pcm audio stream on the snes, you have to convert it to the brr format, which requires quantization aswell. not so easy anymore, is it. i think decompressing mp3s on the spc700 alone is absolutely out of question, due to the very limited working ram and processing speed, plus lacking features to do fast sine transformations. what might be possible is having several megabits of external ram on a cart, decompressing the mp3 to that ram in brr format using the cpu, then streaming that brr data to the spc in order to actually play the song. that way, you eliminate the problem of the slow processing speed... if you dont mind waiting several minutes for a song to decompress, that is. another way of playing back mp3s on the snes would be to have an mp3-decoder on a chip in the cart ( http://www.st.com/stonline/press/magazine/challeng/2ndedi99/chal02.htm ), then feeding its output into the external sound inputs of the snes (only the satellaview and the super game boy do this afair). of course, youd have to find a way of constantly feeding data into the chip. all of this is highly theoretical, of course and imho not really feasible. after all, all youre gaining from preferring streamed mp3s over streamed brrs is saved romspace. although mp3 compresses around 24:1 at a realistic bitrate of 32kbit/s (opposed to around 4:1 for brr), i'd favor a 64mbit rom with 48mbit audio data over a 24mbit rom with additional mp3 decoder chip or endless loading times anytime. bottom line: although the idea of playing back mp3s on the snes is nice, its not a particulary feasible one. Originally posted by Stifu thanks. =) maybe i'll improve them one day. got a whole bunch of other converted mod files playing on the spc here, but i havent yet decided what project i'll actually use the player for. (edited by d4s on 01-16-06 11:22 AM) |
| Pages: 1 2 3 4 5 |
| Acmlm's Board - I3 Archive - - Posts by d4s |
any help?
