Golden Sun Hacking Community
June 24, 2017, 08:51:00 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
  Home   Forum   DC Wiki Help Search Calendar Downloads Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: LSDJ RAM Dump stuff  (Read 12035 times)
0 Members and 1 Guest are viewing this topic.
Seto Kaiba
the blind-oriented developer
Jupiter Clan

Regular Member
*

Coins: 2
Offline Offline

Gender: Male
I am: owner of kaiba corp
Posts: 178

« on: June 30, 2015, 06:21:25 PM »

LSDJ is a tracker for the Gameboy that allows players to create their own chiptunes with it. I've done quite a bit of music with this nifty piece of software and I can say it's pretty dang awesome. Unfortunately, being a Gameboy game, it's completely inaccessible outside of memorization. So I may be writing a specific GB emulator that will allow blind musicians to explore this pretty awesome tool.

I may just make it so that you can write your own files and then just load it into VBA but whatever, I found these, so have fun.

Anyways, I'm dumping my findings here, so hopefully someone else finds it useful.

LSDJ Memory Values:

0xB290-0xB68F

On the SONG screen, these values include the values of the various Chains.

These values do NOT reflect the actual values on any other screen. This should only be referenced when SONG is the active screen.

Each 4 bytes indicates a row of Chains. For example, the first byte in a set of 4 is PU1, then PU2, then WAV, then NOISE. Then it repeats until reaching FF.

These values seem to be stored elsewhere when not on the SONG screen, but I can't find them.

Idea: Extract these values when SONG is first loaded and place them in an array for quick access while on this screen, and flush the array when the screen changes.

0xA080-0xA87F

On the CHAIN screen, these values include references to various phrases.

These values do not reflect the actual values on any other screen. This should only be references when CHAIN is the active screen.

Each 16 bytes reflects a single chain. Chain 00 starts at A080, chain 01 starts at A090 ect.

These values are stored elsewhere but I can't find them.

Idea: Extract these values when CHAIN is first loaded and place them in an array for quick access while on this screen, and flush the array when the screen changes. Only reference the CURRENTLY SELECTED CHAIN.

0xA880-0xB07F

On the CHAIN screen, these values are the pitch offset for each individual phrase.

Similar to the references to the phrases, each 16 bytes corresponds with each chain. So A880 is chain 00, A890 is chain 1 ect.

0xA000-0xAFEF

On the PHRASE screen, represents the various notes. C3 (the lowest note) is represented with 01 while the highest note, B8, is represented by 48.

This has a weird update format. When deleting a note, it completely erases all the notes. This also occurs if you insert the same note. Adding the same instrument clears the memory as well. The list is resorted when you change the current note.

Each 16 bytes represents a single phrase. A000 is Phrase 00, A010 is phrase 01, ect.

0xC0AD

Current screen. Values correspond to:

01 - PHRASE screen
02 - GROOVE screen
03 - CHAIN screen
04 - SONG screen
05 - TABLE screen
06 - INSTRUMENT Screen
08 - FRAME screen
09 - PROJECT screen
0A - BANK screen

I might be missing a few, it's always tricky to go and figure this one out. lol

0xC1EF

5 character string representing currently selected instrument's name. Only applicable on INSTRUMENT screen.

The following are values that monitor the cursor. They stay the same when switching screens unless otherwise specified.

0xC1CC

PHRASE screen:

Horizontal cursor position. Starts at 1. 1 is note, 2 is instrument, 3 is type of modulation and 4 is modulation modifier.

0xC1CD

PHRASE screen:

Vertical cursor position.

0xC1D2

CHAIN screen:

Horizontal cursor position. 0 is chain, 1 is transpose.

0xC1D3

CHAIN screen:

Vertical cursor position.

0xC1D7

SONG screen:

Horizontal cursor position.

0xC1D8

SONG screen:

Vertical cursor position.
« Last Edit: June 30, 2015, 07:23:15 PM by Seto Kaiba » Logged

View Profile WWW
Pages: [1]   Go Up
  Print  
 
Jump to:  

Cbox
Yesterday at 02:25:42 PM
Seto Kaiba: you know I miss how SMF is almost dead now because having 1pt text to hide my true feels was perhaps the best part of web 2.0
Yesterday at 04:19:13 AM
Fox: Alright. Sounds good.  I agree it does seem a bit silly.  Sounds more of an April Fools type of thing. (Maybe having an ability for people to change their names limitless times specifically on April Fools is an idea.)
Yesterday at 04:09:25 AM
Kain: Sala asked me about the name, I thought it was silly but agreed he could have it only for a week.  Tomorrow his name goes back to Salanewt.
Yesterday at 03:29:10 AM
Fox: And yay! Atrius is back! Thanks for the reply. Somehow I didn't notice the recuriveness before.
Yesterday at 03:25:29 AM
Fox: @ridiculous name for a week =  Hm? So, how many characters would you say should be the maximum to have a name "permanently"... or better yet... How many characters can a name have on registration?
Yesterday at 01:00:50 AM
Atrius: @Javi3, Lo siento, ya no tengo tiempo.
June 22, 2017, 08:57:37 PM
Fox: @conundrum = Think about 8/16/32 bit aligned address, and what that means... Etc.
June 22, 2017, 08:55:23 PM
Fox: @Space manager thought for gsmagic = What a conundrum... Whelp... I'll just do whatever.... Probably would waste more time thinking about preventing bugs than coding anyway. :P
June 21, 2017, 09:30:34 AM
Fox: Because he quit a long time ago and has other priorities?
June 21, 2017, 08:35:54 AM
javi3: Atrius, por que no sigues con el editor de golden sun?
June 20, 2017, 10:52:48 AM
Fox: It feels like the safest bet is to do Atrius's repointering system, and have something that organizes the tables done a bit separate... er... Well, it's something to think about.
June 20, 2017, 08:53:41 AM
Fox: HOWEVER... I can see other problems that might cause..... (Even with just the pointer in the MFT)  Meh. It's like you actually need a program to apply patches to do it appropriately.
June 20, 2017, 08:46:38 AM
Fox: ... So... What am I thinking? You ask? That the patches the point data after MFT, should have had pointers in the MFT themselves.... In that case, I can see a possibility of everything working smoothly even if space is needed to the very end of the ROM.
June 20, 2017, 08:37:22 AM
Fox: It's basically that everthink from the point of  editing, to the closest free space to the last entry's address would get repointed forward/backwards depending on space needed... and if space is mapped after patches are added, then that could mean the patches are also repointed. (:o)
June 20, 2017, 08:29:03 AM
Fox: Well, I mean if I map the space out the same way Atrius did it.
June 20, 2017, 08:26:41 AM
Fox: I have a hunch... when I add Map Palette editing the way I'm thinking about... it will cause all patches that repoint to after the MFT to break.... Especially if Atrius's editor wasn't used beforehand. Etc.
June 20, 2017, 07:27:17 AM
Fox: Hmmm... Let's see... regardless of method, I think I still do want to take some of Atrius's Space Manager code... Hmm.....
June 20, 2017, 07:07:27 AM
Fox: say*
June 20, 2017, 07:07:19 AM
Fox: I'd go so far as to see.. even if you are trying to be accurate, there could still be inaccuracies... However, that one was just an example where it was clearly intentional.
June 20, 2017, 07:04:03 AM
Fox: Like*

Affiliates
Temple of Kraden Golden Sunrise
Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.074 seconds with 22 queries.