Note for mods - I've opted for this forum rather than 'Technical Discussion' as my use case relates specifically to 68K memory mapping but feel free to move if you think it would be more appropriate there. Also please be aware I have a link to my site in the post below, hopefully this doesn't set off your spam-dar! Hey folks, I'm in the process of revamping a section of my site in preparation for a large, long term project and wanted to get your thoughts on the best way to visualise ROM / RAM memory maps along with a bit of feedback on what I've went with so far (if you would be so kind!). You can see what I've went with on the site here: http://www.mybrillgamesite.com/projects/?id=86 and I like to think it is pretty self explanatory. The ROM: section is the section I have updated, the Savestate: section is how it originally looked now updated. Down the line I'll be adjusting the Savestate section as well to be the RAM section, adjusting the offsets as a result, giving it similar headers and functionality along with the ability to show / hide the offsets adjusted for savestates created in different emulators (currently they show only GENS). The layout is based on what I think is useful to have and takes inspiration from the layouts I've seen here at SonicRetro, on the Super Mario World disassemblies and in other people's hacking notes. Nothing is set in cement yet and I'm still not sure about peripheral things like the borders I'm using, what other items will appear in the key, what exactly will appear in descriptions, so if you see anything at all you think is missing / would be useful please let me know. Note also that the 'Opcode / Hexcode' column is intended to be 8 bytes wide because I think that's the longest a typical 68K instruction is, isn't it? I know it can be longer with pre and post statements but in practice I should have enough width to display all code there, right? Links to other sites with good examples also welcome and any questions please ask. Note - The section marked 'Unknown' is still to be populated. I've got the disassembly here and want to get it displayed line by line once the section is expanded. Should be up in the next few days. Additional Note - If you've already saw this topic over at RHDN then don't worry, you don't have to reply twice, I'm monitoring both to get the opinions of both communities and expect there will be a little bit of member overlap.
First of all, congratulations on your efforts so far, many people are often pleased to find that their favourite games are being looked into, by at least someone on the internet. Savestates include all rewritable storage date (including RAM, VRAM, VSRAM, CRAM, z80 RAM, VDP registers/pointers, sprite caché, YM2612 register/operators, PSG frequency/volume, etc, etc), this is practically the entire machine's rewritable memory at the point of saving. Since you are really only after mapping out RAM information (and possibly z80 RAM), my advice would be to drop the whole savestate thing, and concentrate on RAM specifically. Then perhaps have starting RAM savestate offsets for whoever needs information from the savestate, to calculate it themselves, this will keep the information consistent, short, clean, and easy to read. Area such as VRAM are liable to be altered in realtime quite extensively, and if you have a disassembly, then you'll likely not need a map of VRAM or other areas. Having said that of course, Toejam and Earl is quite an old game, so perhaps it's realtime alterations would be at a minimal, but nevertheless, a disassembly would be more suitable for reference. I would strongly advise "IDA Pro", it is an "interactive" disassembly rather than automated. It'll follow the flow of code segments and stop at iterations where it cannot confirm the data is code, you can actively continue the flow if necessary, or subject it as a "data" segment. This will provide you with complete control and will prevent data being incorrectly disassembled as code, which in turn will save you heaps of time. This does of course mean redoing the disassembly from scratch, so it depends on how far in progress you are with your current disassembly. If you are nearly finished, then maybe you won't need the interactive disassembler.
I'm definitely interested in ToeJam & Earl, in particular how the random level generator works if you were to stumble upon it. Unfortunately I don't have programming experience with the Mega Drive or disassemblies in general so I cannot be of much help there.
Thanks. I thought it important to get some work done first before posting up otherwise it runs the risk of becoming yet another project that sounded good in theory but never actually became anything. I'm going to plow on with it just now whilst I let this topic gain replies. Indeed, good point, and this is another reason to rename it RAM as that is all I am interested in for that section. In my experience RAM edits allow for quick wins, editing the amount of lives you have left is a lot easier in RAM than it is in the ROM (or at least it was when I was starting out) and they are good when you want to just mess about or do GameGenie / Action Replay cheats on real hardware. Of course the true fun is had in the assembly hence my efforts moving more and more into that. You may be surprised but yeah, they are low enough that comparing 2 savestates against one another normally gives a good indication where data of interest lies (I.e. create a savestate, die, create another savestate, compare for differences and you can normally spot lives storage pretty quick). If you got the money then by all means buy me a copy and I'll go for it haha! Just kidding, I know of IDA Pro but haven't tried it personally yet. As a software developer I'm reluctant to pirate a copy (not that I'm implying you are or would suggest I do!) and sadly the price tag on it is more than I can justify spending on a hobby. Just starting off basically so it may still be worth while. However the GENS emulator has some great 68K debugging tools that I intend to use so hopefully they will see me through. You never know, as I progress I may just happen to drum up the interests of someone who already owns IDA Pro. />/> Toejam and Earl is amazing, everyone I speak to has fond memories of it so I'm surprised there isn't more information about it online. I'm interested in the level generator as well, and where the level data is stored for the fixed levels. I made some progress (undocumented) on level layouts before and even made a custom level by changing data in the savestate but no solid data on it yet (but it is high on the priority list). Well you may not be a 68K programmer but that doesn't mean I can't fire you the odd file to compare or savestate to try if you are interested down the line.
I highly recommend not using offsets relative to the savestate; instead, use either absolute M68K addresses or offsets relative to a specific component. Genesis RAM is located at $FF0000-$FFFFFF, and is mirrored starting at $E0xxxx up to $FExxxx. RAM in a Genecyst/Gens savestate starts at 0x2478, so to get the actual RAM address, subtract 0x2478 from the savestate offset, then add 0xFF0000.
Thanks GerbilSoft, that's exactly the change I was going to do. Basically the RAM table will show the addresses $FF0000-$FFFFFF with an option to also show the GENS addresses (and others if requested) which will be hidden by default (depending on space allowance).
That's the page just about completed in terms of revised layout. If you've got a minute spare can you check it over and make sure everything makes sense and that there isn't any confusion over what offsets I'm referring to: http://www.mybrillgamesite.com/hacking/?id=86 I've still to make the RAM table and Additional Info table borders match the ROM table and I haven't decided if I'll add colour to the RAM table yet as I think it might make the page too noisy. My initial idea of having every address and instruction listed (collapsed initially) won't work as it makes joomla crap out because there is so much code (1.5 million lines of HTML I ended up with!) so I'll stick to keeping the 'Unknown' stuff as unexpandable with just a little warning when you try. For image data, and maybe for the unknown sections as well, what I plan to do is have a link that opens another little window showing the tilemap / spritemap and the raw data that creates it but no rush on getting that in. I'm going to create a topic on RHDN soon for tracking the project as well so it will be available for discussion there (this topic is centered around how to visualise the memory map rather than the actual disassembly in general).
I've completed an update to the memory map visualisation on the page which is more in keeping with what I had pictured in my head. Sharing here since I reckon it is rather good (if I do say so myself) and may be of interest to others in a similar boat. The first visualisation (which is still present for now) is the visualisation with the actual code / disassembly explanation along side it. I'm not too keen on this one as I think it is a bit crowded, will become hard to navigate as it grows in size, is rather unwieldy code wise and a pain to update Also it will likely become obsolete once the completed assembly file is available. However it remains for now as it is a way to share information I discover as I progress but I will likely look for something better: The one I've just recently added and am quite pleased with is accessed by clicking the little link on the 'percentage deciphered' information you can see in the screenshot above: Here we get a proper indication of how the memory in the ROM breaks down, how much has been deciphered, where clusters of data are or large unexplored / unknown spots. The code behind it is also a lot easier to update given it is a series of javascript loops spitting out styled divs (and js understands hex natively making the loops REALLY easy to deal with). I'd be a little happier if 1 block = 1 byte but that would mean over 1million divs on the page for a 1MB rom and my browser keeps crapping out when trying to render that many. I have managed to render the RAM map at this scale though (65536 divs) and it works most of the time (interestingly it doesn't work if you click the link directly but does if you right-click and select 'Open in new tab'). I will probably look at moving away from divs to a canvas instead but the end result will look very much the same. The thing I really like about this is you can zoom the bowser in and out to get a really clear view of the overall progress, especially if you have a massive monitor like the ones we use at work: So as you can see at a glance, still a lot of work to be done on the disassembly! But I'll soon be moving to work exclusively on that once everything to facilitate doing so is in place. Here are the links to the 3 maps if anyone wants to see them live, be aware though that the 2 bigger ones may crash your browser: ROM Map with detailed explanations - http://www.mybrillgamesite.com/hacking/?id=86 ROM Map Summary Visualisation - http://www.mybrillgamesite.com/rawHTML/TE_ROM_MemoryMap.html RAM Map Summary Visualisation - http://www.mybrillgamesite.com/rawHTML/TE_RAM_MemoryMap.html (Right click -> Open in new Tab if it crashes your browser) EDIT - ROM Map Summary Visualisation Via HTML Canvas - http://www.mybrillgamesite.com/rawHTML/TE_ROM_MemoryMap%20-%20Canvas.html - This is the ROM Map this time rendered as an image via the HTML5 Canvas object. It renders a lot better as may be expected with it even being able to draw the ROM Map on a 1 block = 1 byte scale! That's 1,048,576 blocks! So far I've only drawn the blocks in red as a test but in time I'll switch the maps over to use this so I can get a finer grained scale without worrying about breaking browsers. (Although I think 1=1 is probably a bit excessive for the ROM.)
