Forums

Hi there,

For a particular project I'm trying to create a 16KB fixed slot and a 32KB pageable slot. This seems fine, although I'm finding the SMS header at $7ff0 is getting in the way and breaking up the free contiguous ROM space in the 32KB region.

I'm considering moving it instead to one of the other locations such as $1ff0 and advertising the ROM size as 8KB. Is there any compatibility concern for doing this, or other workarounds I should consider first? It would seem that might actually be the optimal location in terms of checksum computing/boot speed going by https://www.smspower.org/Development/ROMHeader

I can't seem to get WLA-DX to use this location though even when I specify the ROM size in the smsheader directive, as it would appear it's still using the actual ROM size. I thought about specifying the header manually at the location but I don't know how I'd calculate the checksum. There's the .computesmschecksum directive but it doesn't seem to define the bytes in that place. I'll continue trying things out but I haven't fully wrapped my head around this or memory mapping yet so would appreciate any advice in this area :)

I think WLA DX puts it at the highest address possible - so maybe you can implement an option for its location and PR it back :)

Sorry, just deleted my last hasty post if anyone saw it.

Looking at code in WLA-DX:

It looks like it can move the header, not sure where `g_max_address` comes from though.

I saw it :) g_max_address is simply the ROM size minus one. A while back I hassled Ville into making almost all of the header user-controllable, for use on disassemblies, but the location wasn’t part of that. I’m sure it’s (relatively) easy to add it as an option and then default to the existing behaviour. I’ve done a few PRs into WLA DX, Ville is very welcoming so I’d recommend giving it a try.

Maxim wrote

I saw it :)

Damn. Don't post and drive, kids. jk, I'm not driving.

Maxim wrote

g_max_address is simply the ROM size minus one.

I couldn't immediately see where it was being set in the codebase, but going by the docs I wonder if it's possible to cheekily redefine the ROM bank map immediately before the `.SMSHEADER` directive in order to trick it into thinking you've got 8KB only while it's calculating the header?

No, you can only do that once. You could try building without a header, but then put some blank data at $1ff0-f; then chop off the first 8KB and build it again with .background of that 8KB and a header; and then re-join it with the newly computed header. Or you could steal tools from devkitsms to correct the checksum. Or you could not care about the header at all… which is fine except for people using emulators with BIOSes, and reproduction cartridges.

A header at $7ff0 and an 8KB checksum range will boot fastest.

Quote

A header at $7ff0 and an 8KB checksum range will boot fastest

Ah interesting, is that just because it checks $7FF0 first (then $3FF0 and $1FF0)? I imagine there wouldn't be any noticeable difference (assuming it just checks the first byte then moves on) but just interested.

I wonder whether it would be helpful to have another option in the SMSHEADER to specify LOCATION (edit: as suggested above), so I might raise an issue in GitHub to suggest that (edit: done so here). I'm a little confused how all these SMS directives play together though (SMSHEADER, SMSTAG, COMPUTESMSCHECKSUM) and how it could be applied to them as well. It seems SDSCTAG also adds the header (at $7FF0), but if all these things respect the options provided to SMSHEADER it might work

I think the difference is that SMSHEADER takes parameters to set things like product code etc. and SMSTAG doesn't. As far as I understand it COMPUTESMSCHECKSUM just inserts the checksum into position, but not really sure why one would want to do that since the other two do it automatically anyway.

It’s just layers of functionality as they got added. If I was using WLA DX to make a game patch I might want to just add the patch code and recompute the checksum, leaving the rest of the header as-is. If I was making a homebrew and wanted to make it boot, I’d add a minimal tag. If I wanted to fill in the header and the unused bytes and have a non-default region code (or a GG code), I’d use the whole header tag.

Author	Message
eljay Joined: 17 Jun 2017 Posts: 19	Moving header checksum to $1ff0 Posted: Sat Aug 19, 2023 1:01 pm Last edited by eljay on Mon Aug 28, 2023 10:39 am; edited 1 time in total
eljay Joined: 17 Jun 2017 Posts: 19	Hi there, For a particular project I'm trying to create a 16KB fixed slot and a 32KB pageable slot. This seems fine, although I'm finding the SMS header at $7ff0 is getting in the way and breaking up the free contiguous ROM space in the 32KB region. I'm considering moving it instead to one of the other locations such as $1ff0 and advertising the ROM size as 8KB. Is there any compatibility concern for doing this, or other workarounds I should consider first? It would seem that might actually be the optimal location in terms of checksum computing/boot speed going by https://www.smspower.org/Development/ROMHeader I can't seem to get WLA-DX to use this location though even when I specify the ROM size in the smsheader directive, as it would appear it's still using the actual ROM size. I thought about specifying the header manually at the location but I don't know how I'd calculate the checksum. There's the .computesmschecksum directive but it doesn't seem to define the bytes in that place. I'll continue trying things out but I haven't fully wrapped my head around this or memory mapping yet so would appreciate any advice in this area :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sat Aug 19, 2023 1:03 pm
	I think WLA DX puts it at the highest address possible - so maybe you can implement an option for its location and PR it back :)

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Sat Aug 19, 2023 1:09 pm
	Sorry, just deleted my last hasty post if anyone saw it. Looking at code in WLA-DX: It looks like it can move the header, not sure where `g_max_address` comes from though.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sat Aug 19, 2023 1:17 pm
	I saw it :) g_max_address is simply the ROM size minus one. A while back I hassled Ville into making almost all of the header user-controllable, for use on disassemblies, but the location wasn’t part of that. I’m sure it’s (relatively) easy to add it as an option and then default to the existing behaviour. I’ve done a few PRs into WLA DX, Ville is very welcoming so I’d recommend giving it a try.

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Sat Aug 19, 2023 1:24 pm
	Maxim wrote I saw it :) Damn. Don't post and drive, kids. jk, I'm not driving. Maxim wrote g_max_address is simply the ROM size minus one. I couldn't immediately see where it was being set in the codebase, but going by the docs I wonder if it's possible to cheekily redefine the ROM bank map immediately before the `.SMSHEADER` directive in order to trick it into thinking you've got 8KB only while it's calculating the header?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sat Aug 19, 2023 1:47 pm
	No, you can only do that once. You could try building without a header, but then put some blank data at $1ff0-f; then chop off the first 8KB and build it again with .background of that 8KB and a header; and then re-join it with the newly computed header. Or you could steal tools from devkitsms to correct the checksum. Or you could not care about the header at all… which is fine except for people using emulators with BIOSes, and reproduction cartridges. A header at $7ff0 and an 8KB checksum range will boot fastest.

eljay Joined: 17 Jun 2017 Posts: 19	Posted: Sat Aug 19, 2023 2:43 pm
eljay Joined: 17 Jun 2017 Posts: 19	Quote A header at $7ff0 and an 8KB checksum range will boot fastest Ah interesting, is that just because it checks $7FF0 first (then $3FF0 and $1FF0)? I imagine there wouldn't be any noticeable difference (assuming it just checks the first byte then moves on) but just interested. I wonder whether it would be helpful to have another option in the SMSHEADER to specify LOCATION (edit: as suggested above), so I might raise an issue in GitHub to suggest that (edit: done so here). I'm a little confused how all these SMS directives play together though (SMSHEADER, SMSTAG, COMPUTESMSCHECKSUM) and how it could be applied to them as well. It seems SDSCTAG also adds the header (at $7FF0), but if all these things respect the options provided to SMSHEADER it might work

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Sat Aug 19, 2023 3:50 pm
	I think the difference is that SMSHEADER takes parameters to set things like product code etc. and SMSTAG doesn't. As far as I understand it COMPUTESMSCHECKSUM just inserts the checksum into position, but not really sure why one would want to do that since the other two do it automatically anyway.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sat Aug 19, 2023 5:00 pm
	It’s just layers of functionality as they got added. If I was using WLA DX to make a game patch I might want to just add the patch code and recompute the checksum, leaving the rest of the header as-is. If I was making a homebrew and wanted to make it boot, I’d add a minimal tag. If I wanted to fill in the header and the unused bytes and have a non-default region code (or a GG code), I’d use the whole header tag.

Forums

View topic - Moving header checksum to $1ff0