Golden Sun Hacking Community
May 24, 2017, 09:35:20 PM *
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 11406 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: 173

« 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
Today at 06:49:14 PM
Lord Squirtle: I guess I'll make a topic for the GBA concept room in Dark Dawn soon.
Today at 04:27:21 PM
Fox: Yep ... There are many libraries for many languages... Python, etc... And then there are things like  the Google apis - e.g. http://maps.googleapis.com/maps/api/geocode/json?address=(whatever you want to search for)
Today at 07:46:43 AM
Luna_blade: I can see how XML/JSON are a thing these days.
Yesterday at 04:52:18 PM
Fox: Easier in the idea that I can reduce required external stuff where the source code isn't available/modifyable (Well, there is overrides in some cases, but still.) ; So it's possible the only "Events" I would require are those of the Form.... (Mouse Events, Keyboard Events, Paint Events, Etc. when needed.)
Yesterday at 04:42:14 PM
Fox: Anyway... I know I am using built-in controls in my current editor, but it is not out-of-the-question that I might just go and make my own custom controls... so that it is actually easier for me (But that'd take a lot of work.)  I'm thinking about one large bitmap object, and just drawing them on it. Problem is, I'm afraid it might not be efficient enough.  So I haven't decided about doing it.)
Yesterday at 04:33:28 PM
Fox: @XML = If I recall, I believe Visual Studio uses it for Settings Variables that remain even after you close the program. (e.g. There's one variable I have in my program that I call "LastRom" to make it easier to get back into the program.)
Yesterday at 04:17:59 PM
Fox: XML/JSON are simple = They are just a way to store data outside the application... ... The complexity is comparable to learning about data trees, I'd say... XML = Looks like HTML  ; JSON = Think Lists and Dictionaries, and nested ones.
Yesterday at 03:51:19 PM
Luna_blade: @the whole static thing: I recently came across the problem that if you use design patterns, objects of the same class might get duplicate info. Sometimes this is very little information, so it seems better to use something class-wide than making a file
Yesterday at 03:47:41 PM
Luna_blade: another thought I had is that I already made some code better...
Yesterday at 03:45:59 PM
Luna_blade: Sure I will open-source it on github once I rewrite it to be more maintainainable. Now that I think about it, I should put some other stuff there as well
Yesterday at 03:44:54 PM
Luna_blade: Yeah I made some code and screens for it in Java. The last thing I was busy working on was the grid for the values and the selection shape.
Yesterday at 03:41:22 PM
Luna_blade: I will learn a bit of JSON and XML soon. I guess those are pretty good replacements for what I meant with static
Yesterday at 03:40:42 PM
Luna_blade: It's an okay article. I prefer reading the java implementations on tutorialpoint
Yesterday at 12:07:19 PM
Fox: article*
Yesterday at 12:07:06 PM
Fox: Oh yes, there's a whole artice on design patterns at wikipedia? https://en.wikipedia.org/wiki/Software_design_pattern
Yesterday at 07:20:37 AM
Fox: Oh yes.... Just checked.... Program.cs has "Application.Run(new Form1());" ... AND.... Program.cs is a STATIC class, so my hunch is confirmed. (In a way.)
Yesterday at 07:12:43 AM
Fox: So... I'm assuming that it is like a tree, and your top level file should be the static class, with all the other object classes linked from it? (Like a tree?) - Wonder how the Dessigner treats Forms. (How are Form objects linked to a static class, if at all?)
Yesterday at 07:00:51 AM
Fox: (Since I can have incredibly bad wording sometimes :P)
Yesterday at 06:59:50 AM
Fox: (Well, started "?" was more implying whether you made any public releases yet....
Yesterday at 06:59:02 AM
Fox: Wait? You started a Hed Editor? Curious if you were going to open-source it....

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.101 seconds with 22 queries.