1

ROM Hacking Discussion / Re: FF1 MMC5 Disassembly Updates

« on: July 01, 2020, 04:48:28 pm »

I don't know how to continue this thread. It both doesn't feel right to continue on here, and doesn't feel right to just close up and move. I've never been in a situation like this before, and the last thing I want to do is hurt anyone's feelings.

Talking with a friend outside the rom hacking community, I was given the advice to put this thread to rest, and let it be a memorial to Disch.

Talking with Vanya, and considering the scope of the project--being mostly my edits the idea of starting a fresh thread in the Personal Projects forum seems more fitting for the content.

So it seems the best course of action is to let this thread be, and start anew there.

If this is the wrong way forward, please let me know.

Yeah, it's a bit of a tough one. If a new topic doesn't break the flow too much then starting that up, placing a link to it here (and a link back here in the new one) then getting this one locked could be a good way to close it off.

For what it's worth I've put a little tribute up to him on my own site as well, just his profile from here and a wee message.

2

Personal Projects / Re: Toejam and Earl Disassembly

« on: June 19, 2020, 06:24:29 pm »

Progress Report 8

Date: 19-Jun-2020
Current Goal: Moving from Easy68K to VASM.
Complete: 100%.

It's been a long time since my last update. As usual I got distracted with other projects, then something caught my interest that made me think about my own disassembly and now I'm back to make as much progress as I can before I get distracted again.

As you may recall, the last big change I'd made development wise was to start coding exclusively in Visual Studio Code and use Easy68K only for assembling the code and building the final binary. This has worked well, I've made huge progress on the disassembly as a result and even managed to get the build process down to just a handful of keystrokes. However, it still wasn't quite slick enough. Building shouldn't take 3 applications to do it. It shouldn't take a handful of keystrokes. It should be a single keystroke and it should happen from within a single application.

And so that is why I decided it was time to bite the bullet and change assembler, something that I knew was inevitable ever since the day I realised Easy68K doesn't have command line support. Thank you very much Professor Kelly, for the great tool and all the support, but it is time we went our separate ways.

I think the thing that piqued my interest and got me back on the T&E track was the discovery of a new person (new to me at least!) supplying the world with high quality assembly knowledge: ChibiAkumas on his YouTube Channel. And so it seemed only fitting to go with the assembler he uses for his 68K work (well, that and it is modern, well documented, well maintained and widely used): VASM.

VASM is a portable and retargetable assembler to create linkable objects in various formats or absolute code. I have no idea what that means, but what I do know is that ChibiAkumas has a video explaining its setup in the first 5 minutes and also supplies a ready to rock download pack containing everything you need to get assembling fast. I haven't exactly copied his set up but I've certainly lifted liberally from it!

And with VASM setup and working from the Windows command line it was time to set up Visual Studio Code to use it. This was done via a custom build task, allowing the press of CTRL+SHIFT+B to completely assemble and build the source from code to binary, at least it would if the damn thing would build!

Which is where the real fun began!

Turns out Easy68K and VASM aren't perfectly compatible (not huge surprise really). Here are the things I can remember I had to do to get the code reassembling and building once again:

• Make sure all PEA instructions have their opcode length set.
• Make sure all BRA (and related) instructions have their length set.
• Make sure no ORG statements overlap or are duplicated.
• Replace * as the comment marker with ;.
• Move the code that starts at $00000000 to be first in the Master file

And to be honest I think that's about it! It felt a lot more at the time but all in all it wasn't too bad, 4 days in total for the move. Getting the VSCode problemMatcher set up, which jumps you straight to the lines that are causing build problems, made a world of difference. The ORG statement overlaps were harder, as no indication is given as to which areas are overlapping and I have a lot of them spread out over many files. This wasn't an issue in Easy68K since it just overwrites sections that overlap, but VASM is stricter and refuses to generate a build until you sort them. A sure sign that we're working with grown up tools now! With a little Excel and Notepad++ wizardry I was able to set up a macro and spreadsheet that helped narrow it down and root out all the overlap and a lot of duplicate code in the process.

And that was it done! The disassembly once again builds into a bit perfect copy of the original ROM. And best of all, although the Easy68K code wouldn't build in VASM the VASM code will build in Easy68K, so although I don't plan to maintain compatibility going forward it is still nice to know that the first commit will still work with either set up.

Little bit more spit and polish and I'll be ready to commit that very first commit of the future!

3

ROM Hacking Discussion / Re: FF1 MMC5 Disassembly Updates

« on: June 11, 2020, 06:40:31 pm »

Jiggers, I hope you don't mind us taking over your topic for a moment to acknowledge this. If there was elsewhere to put it I would have.

Kuja, I'm afraid I don't have more details than that. I am trying to find out more without prying (at the very least to verify it but I have very little reason to doubt it and feel almost awful for mentioning it). Rest assured if I do get more details I will post them here.

4

Personal Projects / Re: Toejam and Earl Disassembly

« on: June 10, 2020, 08:41:40 pm »

Just thought I'd check in so that people know I'm still around. Haven't updated the site much, not at all this year I don't think, but the T&E repo still get a bit of love every now and then.

Have got a new PC so will need to go about getting that set up again before any more progress is made.

5

ROM Hacking Discussion / Re: FF1 MMC5 Disassembly Updates

« on: June 10, 2020, 08:36:52 pm »

Folks,

Sorry to share this but someone by the name of Sune came into the RHDN Discord and informed us that it appears Disch passed away on the 3rd of June.

Sorry to come to your community to bear bad news. I'm here to inform you all that Disch has passed away last week on the third of June. I know he was pretty active within the ROM community, and he was a great guy and programmer.

https://discord.com/channels/266412086291070988/266412086291070988/720383320344625183

I knew very little about him except that he posted a lot here and his posts were always interesting, friendly and well informed. This looks to be the last topic he was posting in and I know FF1 was very close to his heart so I figured you'd like to know.

6

Personal Projects / Re: Toejam and Earl Disassembly

« on: August 17, 2019, 07:44:42 am »

Looking good LightningSam, keep us posted with how you get on. 

Things are progressing well on my side as well, will do another write up soon.

7

Programming / Re: 68000 Mega Drive Assembly - Move Instruction

« on: July 11, 2019, 03:35:04 pm »

My memory is vague. But I think this is the "indirect with displacement" addressing mode. If so, then D1.w specifies the address and A2 specifies the displacement from that address. The sum of the two is the address where the value in D4 is stored. So which you consider to be the base address and which is the displacement is a matter of your own choice, I think.

You've got the premise right, just a few small details are off: in the example A2 is the address and D1 is the displacement, you can't use A registers for displacement (so for example MOVE.b D4, (A2,A1) wouldn't be valid. Also it isn't a matter of choice, it is always the way round shown, I just give it a quick try to double check and MOVE.b D4, (D1.w,A2). throws a syntax error.

Puyo sounds interesting RadioShadow, look forward to seeing what comes of it. Great to see another Megadrive fan on the go.

8

Personal Projects / Re: Toejam and Earl Disassembly

« on: July 09, 2019, 05:33:24 pm »

Hmmm that's annoying. If you go into the Help -> About in Retro Graphics Toolkit what does it say for when it was built? Mine is: This program was built on Dec 9 2018 02:27:54

What other graphics programs have you used so far to try it? Would be interested to know what others work well.

9

Personal Projects / Re: Toejam and Earl Disassembly

« on: July 07, 2019, 07:13:51 pm »

Thanks LightningSam, look forward to seeing what you produce.

The idea of adding the girls in occured to me as well and with the release of BitG I imagine a lot of people would like to see that. Replacing T&E with them is a good place to start, then you can add them in as 2 options alongside T&E and finally implement a fully fledged 4 player mode once you are a game dev god!

To your questions:

If the music is ever included in the disassembly, how easy or hard would it be to replace songs?
Music will definitely be included in the disassembly but I'm afraid I have no idea how hard it would be to replace as I've never worked with Mega Drive music before (or any other music for that matter). I'm sure this'll become clearer as the first songs are discovered.

Will this disassembly allow for full-on text string editing in the future?
Yes, definitely. Currently I've no plans to make any tools that will facilitate this but so long as you understand assembly you will be able to do as you please and text work should be fairly straight forward.

Would this allow for editing the tile spacing on certain graphics?
Same answer as above, once the disassembly is complete anything will be possible however I imagine making the sprites taller will be trickier that editing the text or name graphics.

How do I edit the "Toejam & Earl" logo at the beginning? I see the file in here, but when I try to open it with Retro Graphics Toolkit, it gives me an error message.
I've only opened the files in Retro Graphics Toolkit which is done by opening both the file and a palette using File -> Open -> Tiles -> Open Tiles and selecting OK on all the menus except "Set 0 as Transparent" then for the palette I don't think I've exported the correct one yet so I just open it with File -> Palette -> Open Palette and then select a random one from one of the directories. I haven't actually tried editing anything yet so keep me posted on how it goes.

Good luck!

10

Personal Projects / Re: Toejam and Earl Disassembly

« on: June 30, 2019, 06:55:59 pm »

Progress Report 7

Date: 30-June-2019
Current Goal: General exploration, commenting, RAM address identifying.
Complete: Unmeasured, progressing well though.

I've been chipping away at the code and making a lot of progress over a wide range of areas. I attribute most of this progress to the decision to start working out RAM addresses and then using Visual Studio Code to rename the given address throughout the source to something meaningful. This works great, not only do you have something more meaningful than LOC_00FF1234 to go on but you can also see clearly the code that interacts with the values, making it much easier to group related code together.

However, that's not what compelled me to write this progress update, what did is the milestone I past last night: extending the ROM to contain custom code!

It wasn't much, but after a passing comment by Malias about adding code I figured it was something I'd always been interested in and that the codebase was probably in a good enough state to give it a try.

So I did!

Here is the original code that sets Toejam's initial presents when the game loads:

Code: [Select]

ToejamInitialPresents:
NOP                     *Adds to Toejam's inventory, 4 on single player, 2 on 2 player.
ADDQ.L    #$4,A7
MOVE.B    #TOEJAM_INTIAL_PRESENT_1, (A2)
MOVE.B    #TOEJAM_INTIAL_PRESENT_2, $0001(A2)
TST.B     EARLS_LIVES
BGE.B     EarlInitialPresents
MOVE.B    #TOEJAM_INTIAL_PRESENT_3, $0002(A2)
MOVE.B    #TOEJAM_INTIAL_PRESENT_4, $0003(A2)
In a previous update I tweaked this to set a few more presents by condensing the code a little and removing the TST.B:

Code: [Select]

ExtraInitialPresents:
MOVE.B    #$05,(A2)
MOVE.B    #$05,$0001(A2)
MOVE.B    #$05,$0002(A2)
NOP
MOVE.B    #$05,$0003(A2)
MOVE.B    #$00,$0004(A2)
This kept the code the same size but gave 5 presents every time instead of the usual 4 on 1 player and 2 on 2 player.

However, last night I wrote my own code at address $100000 (the end of the ROM) which set all 16 present slots to the first 16 possible presents and then I rewrote the original code to jump to it. Since I want to keep the original files building to the original game I created a brand new file and put my code in there using an ORG statement to place it at the end of the ROM. The same technique was used to overwrite the original present setting code with the JMP to my new code.

Code: [Select]

ORG $00100000
CustomPresentSetting:
MOVE.B    #ICARUS_WINGS, (A2)
MOVE.B    #SPRING_SHOES, $0001(A2)
MOVE.B    #INNERTUBE, $0002(A2)
MOVE.B    #TOMATOES, $0003(A2)
MOVE.B    #SLING_SHOT, $0004(A2)
MOVE.B    #ROCKET_SKATES, $0005(A2)
MOVE.B    #ROSE_BUSHES,   $0006(A2)
MOVE.B    #SUPER_HITOPS,  $0007(A2)
MOVE.B    #DOORWAY,   $0008(A2)
MOVE.B    #FOOD,   $0009(A2)
MOVE.B    #ROOTBEER,   $000A(A2)
MOVE.B    #PROMOTION,   $000B(A2)
MOVE.B    #UNFALL,   $000C(A2)
MOVE.B    #RAIN_CLOUD,   $000D(A2)
MOVE.B    #FUDGE_SUNDAE,  $000E(A2)
MOVE.B    #DECOY,   $000F(A2)
RTS

ORG $0001435C
NOP
JSR CustomPresentSetting
ADDQ.L #$4, A7
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
Notice I had to keep the ADDQ.L    #$4,A7 line outside of my custom code. This line increases the stack pointer, A7, by 4 and you can't do this from within the jump to my new procedure since jumping to it sets the stack to point back to where we jumped from. Adding 4 to there will just make us jump back to the wrong place so we need to do it at the original level.

The other, slightly more standout thing, is all the NOPs that have been added in the place of the original code. This is because although we no longer need the original code we do need the memory space it takes up so adding NOPs is the safest way to still use that space whilst having minimal effect on the game state (it can affect processor timings but only testing will reveal if it is an issue or not).

So that's it! A pretty awesome milestone to pass and opens up a lot of possibilities for the future.

11

Programming / Re: Sega 68K Branch on not equal question

« on: June 30, 2019, 03:47:07 am »

Real Life (tm) happens to us all, no need to apologise.

Exodus and Gens KMod are good emulator for looking at the code, they let you set breakpoints, step through one line at a time and so on. Worth checking out when you find a little time.

12

Programming / Re: Sega 68K Branch on not equal question

« on: June 25, 2019, 04:17:25 pm »

...The quick and dirty way to change code flow is to overwrite some of the code with a jump to the code you want to execute, move the code you overwrote to the beginning of your code block, run your code, then jump back into the code to resume normal execution.

Thanks Malias, I've been wondering about that myself and now that you explain it it seems fairly obvious. Overwriting existing code had occurred to me but I'd never thought of putting the code I overwrite into the new location. Sneaky! 

What are you using to generate the code Seraphim423? Because none of the code you have posted there is actually valid 68k, it's close, but it isn't right. If it was from your own memory then I can forgive it but if it is copy and pasted from somewhere then something isn't right.

Identifying items was likely done through constants. For example I could write:

Code: [Select]

SMG_1 EQU $08
and then change the first line of code you posted to

Code: [Select]

cmbip #SMG_1,%a0@(87)
and it would still work. However this information is lost when disassembling the finished ROM as the assembler substitutes out all the nice constant names for the number they represent.

Although the link Malias has gave is certainly a good reference, I prefer http://mrjester.hapisan.com/04_MC68/ for its nice wordy descriptions and examples of how many of the 68k instructions work. I'd start there if you are still new to some of them.

13

Personal Projects / Re: Toejam and Earl Disassembly

« on: May 20, 2019, 06:28:27 pm »

Progress Report 6

Date: 20-May-2019
Current Goal: General exploration, commenting, RAM address identifying.
Complete: Unmeasured, progressing well though.

The code is now public in the BitBucket repository here: https://bitbucket.org/RyanFaeScotland/toejamandearldisassembly

It's finally public but that doesn't mean it is finally beautiful, clean, well documented or any of the other things you might want your code to be before releasing it into the wild! But I have a lot of Real Life (tm) going on so wanted to get this out there for others to enjoy as well rather than just hoarding it until I was finished / 100% happy with it. Let's just say I'm now at a point where I'm happy enough for it to be available to all!

I'm still going to be plugging away at it of course, so expect on going updates as I progress to the beautiful version I hope to one day make.

14

Personal Projects / Re: Toejam and Earl Disassembly

« on: May 02, 2019, 07:56:32 pm »

Random Update

And just like that, the first hack is a reality!



It isn't much, more a proof of concept than anything, but there is a few palette swaps, some damage changes, some changes to the starting presents and a little tweak to the logic for what presents are identified so there is a few bits and bobs in there.

Feel free to check out the short video that goes into a bit more detail: https://www.youtube.com/watch?v=eGYistHOCsc.

Hey @altoiddealer, cool to see you still checking in. 

15

Programming / Re: Super Hang-On (Genesis) Game Timer - inaccurate?

« on: May 01, 2019, 07:09:39 pm »

...the obviously sizeable work you've just done...

Not as sizable as the work I'm going to have to put in to get decent enough to reach the first split point on Arcade before the timer runs out haha, I'm terrible at this game!

Nothing invalidated, will focus on Arcade mode when I next look into it. Keep sharing the values you find and if you want to search the source code for them add 00FF in front (so 00FF0554 for the timer) or sometimes FFFF (so FFFF0554) and you should be able to find most of the code that has an impact on them (assuming it does so directly and not through a pointer)

EDIT - Been in for another look and can confirm that the addresses you have shared are indeed correct and I can see them changing when in Arcade mode. I'll look further into it and see if I can figure out what's happening to the counters to cause the issue you are seeing.

16

Programming / Re: Super Hang-On (Genesis) Game Timer - inaccurate?

« on: May 01, 2019, 06:50:50 pm »

Well, personally it is my belief that as a speedrunner you should be playing the game in the state it is presented, defects and all. If there is an issue with the timer then it is your prerogative to investigate that issue and figure out how to manipulate it in game to your advantage, not to change the code to adjust it to work how you think it should / wish it did. 

That said of course, I'm not going to dictate how you run your game and I'm much more interested in looking at the code than I am debating the semantics of what speed running is all about!

With that in mind, I looked into the timers and I'm afraid I'm getting very different results than you.

For me, offset $040C doesn't contain the timer, it just contains 00s. I see the timers as being stored as follows (each is 4 bytes long):

SPLIT_TIMER             EQU $00FFC82E
TOTAL_TIMER             EQU $00FFC832
RIVAL_TIMER             EQU $00FFC860

These are stored exactly as seen in game, so a value of 00 00 05 86 would display as 0'05"86, here is a screenshot example:



I've disassembled the game and uploaded the source code here: https://bitbucket.org/RyanFaeScotland/superhangondisassembly/ so that it is easier to work out how it all hangs together.

Out of interest, which emulator are you currently using?

17

Programming / Re: Super Hang-On (Genesis) Game Timer - inaccurate?

« on: April 30, 2019, 04:05:08 pm »

Hey TheArbiter, good to see a speedrunner on here, I'm sure they exist but I don't think in all my years dipping in and out of the forums that I've ever saw a post by one.

Can I just check, what rom is it your working on? My copy is 'Super Hang-On (JUE) (REV 01) [!].bin' so if I do find anything it'll be for that.

18

Personal Projects / Re: [SMD] Rock n' Roll Racing Hack v15

« on: April 23, 2019, 05:15:10 pm »

This continues to be one of my favourite hacks out there. A lot of love went into this project!

19

Programming / Re: Assembly Project Structure and File Types

« on: March 14, 2019, 06:50:27 pm »

Cheers tvtoon, "feature" in my head would also include devices, not just the tradition 'game feature' so I'd have a directory for VDP, Sound, Input and so on as well and in them would be the code and data related to processing (however the actual sound/music/graphic files would be in with the game feature they relate to). I've added this clarity to the first post too.

Rest assured I don't want to take the directory thing too far either, so for example there would just be 1 directory for Enemies and then a file per Enemy. File size won't be a factor into it. 

And yup, data and code in different files! Half the work in the disassembly was splitting them out, I'm not letting them get back together now.

Cheers for the thoughts, appreciated.

20

Programming / Assembly Project Structure and File Types

« on: March 13, 2019, 06:36:16 pm »

Hey folks,

Looking for a little debate, discussion and recommendations on the suggested directory layout and file types for assembly projects in preparation of my Toejam and Earl disassembly project progresses to the full blown project stage.

I've been looking over the GitHub repos of Sonic Retro and they are fairly consistent with their file types: .asm for source files, .bin for binary files and, well that's about it including a few batch files which are obvious .bat. Is this the most common style and is there reasoning behind it? My assembler uses .x68 assembly files so I'm sticking with that but I also have .dat files for any source code files made up mainly of DC.B instructions. Finally I've also got .bin files for raw binary data to fit in with the apparent standard (which I might switch all my .dat files over to in due course).

For directory structure though all bets are off! There is even a debate on it in the issue logs of one of the repos. Single file, multiple files, feature based directories, type based, all sorts of options. I've opted currently for a feature based structure currently as it feels most intuitive but if people know better options I'd rather hear now than when I'm knee deep in source code.

Here is what I like the look of (based loosely on this post from Stack Overflow). In the following 'feature' can be game features (players, NPCs, items and the like) or hardware features (VDP, sound, input and the like):

Root
|____ Source
|     |
|     |____Feature A
|     |    |
|     |    |____ Code
|     |    |____ Data
|     |    |____ Graphics
|     |
|     |____Feature B
|     |    |
|     |    |____ Code
|     |    |____ Data
|     |    |____ Graphics
|     |
|     |____Feature C
|     |    |
|     |    |____ Code
|     |    |____ Data
|     |    |____ Graphics
|     |
|     |
...

What's your thoughts on the matter?