Quote:
The code I wrote checks if the string TETRIS is present at the start of the SRAM memory space. It's very unlikely that this memory would say TETRIS by random chance, so this is taken to mean that the data is valid.
I guess what I'm trying to ask is what happens if the TETRIS string is not found (though I understand this is unlikely)? SRAM would be cleared and if so would that overwrite a previous save file?
Another question I forgot to ask in regards to the string is how does the code know when it hits the last letter S in the string of TETRIS? I see
Code:
ld de,$0134
which loads the string, but Pandocs says the ASCII title at $0134 can go all the way to $0143 if the title is long enough so how does the code know to stop after 6 characters? I see this part in the code:
Code:
ld a,[de] ; Load character from the string in ROM
but does it know it hit the end by hitting 00's?
Quote:
From which angle are you asking?
I wasn't saying I didn't understand why it was needed in the code like it was unecessary or anything, just that I didn't know why it was needed in the sense that I was just using it as an example of simple code that I didn't understand or know why it was in there. A way to write that I probably should be able to know those things in the code if I want to be adding SRAM support.
Thank you for the explanation though. Even with the explanation I'm not sure I fully wrap my head around it, but I will study up. Registers and flags and 8bit/16bit and those types of things are the parts of ASM I understand the least right now.
Quote:
Go to ASMSchool.
Awesome link! This is just what I need to read up on. What's sad is I have been to that old Gameboy dev site these past few days and didn't even notice the ASM section.
Quote:
Why he would choose $A600 is beyond me.
My apologies, I wrote it wrong in that post. $A600 is supposed to be $A000. I think because I had just written $A654 I put a 6 in there on accident. $D654 to $A654 and $D000 to $A000. So there's no table overlap.
Hmm, would it be easier just to change the values in hex like I have been doing (which was working in the emulator before the MBC1 cart type change) instead of writing new code that would copy the high score tables from $D654/$D000 to SRAM and back from SRAM to those values (at startup)? Would seem much easier than writing code if an easy hex change will do the trick.
Quote:
Then in the debugger, you choose debug, access breakpoints and enter 2000. Or if you want to be sure to not miss any writes, you could enter 2000-3FFF which is the full range for this register. Writing a byte to any address in this range does the same thing, change the ROM memory bank.
I think I am finally using the debugger correctly, thank you. I added 2000 to access breakpoints and clicked enabled. Then I ran the game and set "Toggle Breakpoints". It jumped me to the code you said (I guess $0254 is apart of it too?):
Code:
0252: ld a, 01
0254: ld (2000), a
Transfer 01 to the accumulator, and then transfer accumulator to 2000. This takes care of the write to $2000.
Quote:
It's correct that there's very little space. But on the other hand that space only needs to fit the code, not the highscore backup which is stored in SRAM. The size of the code can be the same whether it's copying 1 or 1000 bytes, since that happens in a loop.
The most free space in one area is from 00DA-00FF, which is only 38 bytes. Not enough to fit the code you wrote or additional code I would write to save high scores to SRAM. So if I could use the space where Type-B's score table would go (which I don't care about saving Type-B scores) I might have room to fit the code. Or I could just scatter the code throughout the rom where there's room, correct? Like the clearsramloop can be in a different place than comparepass? Since they are JR'd anyways?
Also if just changing $D654/$D000 to SRAM values ($A654/$A000) in hex so that the high scores are read/written to SRAM directly will work then could parts of the code be deleted like the comparepass part of your code which you put in the comment copies the high score table from SRAM to work RAM. This wouldn't be needed anymore because the high scores are being read/written to SRAM directly? This would clear up space for code. I think I might be misunderstanding exactly what SRAM is or work RAM or both. They both take up A000-BFFF?
Thanks again for the help.