nesdev.org

I have been trying to make a hirom game and I have been able to essentially make a lorom bank in hirom, but I have not been able to use the lower $8000 half of a bank. I read something online and it told me to do something like this but it doesn't work. (all the graphics I am loading are being taken from the wrong place)
The header for the game looks like this
Just so you know, I am using wla DX

(by the way, why is lorom called lorom if it uses the upper $8000 of each bank?)

"Lo"ROM canonically executes out of $008000 through $3FFFFF.
"Hi"ROM canonically executes out of $C00000 through $FFFFFF.

I believe the system always starts in bank $00, so if you want to run program code in the bottom half of a bank, you'd have to do a long jump to the appropriate bank. Using jml label with the label: immediately afterwards will put you in the bank defined by .BASE.

Except that .BASE doesn't work properly in WLA DX. I found that using .BASE $7F got me to bank $80 (I was using FastROM).

If you know exactly what the 16-bit address of the next opcode is, you can use 24-bit addressing manually - just say jml $40xxxx. But this is brittle and I don't recommend it.

The ROM is normally mirrored from $00-$3F to $40-$7D ($7E and $7F are WRAM), $80-$BF and $C0-$FF, so you get the same data this way unless you're using a memory map with more than 16 Mbit in LoROM mode or 32 Mbit in HiROM. Except in $7E and $7F, obviously. The difference being that $40-$7D and $80-$BF are mapped as entirely ROM, which means you can access the bottom half of a 64 kB ROM bank, but you can't access WRAM or hardware registers without using 24-bit addressing. And of course, any cartridge access in bank $80 or above happens 25% faster if you have written a 1 to $420D.

What I generally do is run my code from a LoROM region and stick bulk data in the bottom half of the bank. This way I can simply specify a HiROM bank number for DMA, instead of having to actually run in a HiROM region and lose fast access to other system resources. It sounds like this is probably what you want to do - just write $4x (or $Cx) to $43y4 instead of $0x.

...

Any experts who see anything wrong with the above, please correct me.

Sorry, but I don't get what you really mean. I just wrote

LoadBlockToVRAM BackgroundPics

with LoadBlockToVRAM being part of a macro that stores tile data in vram and with BackgroundPics being labeled like

BackgroundPics:
.INCBIN ".\\GamePictures\\256color.pic"

under

.BASE $40
.BANK 2 SLOT 0
.ORG $8000
.SECTION "BGCharacterData"

and what does BASE mean anyway? I pretty much just copy and pasted this code from nesteviki's snes starterkit and changed a couple of names of things

.BASE just specifies the base bank number for WLA to use in 24-bit address references. The problem is that it doesn't work right; I think using a number one less than the one you want should work, but I've only ever used it for FastROM, and only on the first bank.

I don't use LoadBlockToVRAM because it uses WLA's :datalabel syntax to auto-generate the source bank, which is asking for trouble if you're using HiROM for the first time. I just write out the preparatory code explicitly, with my own bank number in hex, and use the LoadVRAM subroutine directly.

I haven't used wla in over a year but if I remember things right you need to specify hirom in the header source file else org treats $0000 as $8000.

Hey, wait - are you specifying .BASE right before the data block? Wouldn't it need to be specified before the point where you expect it to do anything, from the perspective of the assembler? Remember, it's not for arranging the ROM; it's for targeting accesses in the code, which sees the ROM in the context of the SNES memory map. It doesn't move the data - it just changes where the code looks for the data.

And as I said, it's apparently buggy, so I'd expect .BASE $40 to give you the wrong address even if you did everything else perfectly...

You can forget what I said about jml for the moment. That trick is mostly useful for FastROM, which is not what you're trying to do. That's probably part of what confused you...

93143 wrote:Hey, wait - are you specifying .BASE right before the data block? Wouldn't it need to be specified before the point where you expect it to do anything, from the perspective of the assembler?

I don't see anything wrong with his .base usage.
Here's a "minimal" test, just assemble and link, you should see a lime green colour (step in a debugger to see the bank change).
https://gist.github.com/ARM9/463f76c21d3e9a57994c

And as I said, it's apparently buggy, so I'd expect .BASE $40 to give you the wrong address even if you did everything else perfectly...

I've experienced a lot of bugs with wla, but the .bank directive being broken wasn't one. Are you guys sure you're using the latest version? If you're using the windows build from his website, that's not up to date, you need to compile it yourselves (requires cygwin iirc) or find a windows build of the latest source.

ARM9 wrote:Here's a "minimal" test, just assemble and link, you should see a lime green colour (step in a debugger to see the bank change).
https://gist.github.com/ARM9/463f76c21d3e9a57994c

Oh, so .BASE applies to labels themselves, not the use of labels by opcodes? I suppose that makes more sense than the way I was thinking of it... (I hate having to figure out someone else's idea of a useful abstraction. That's part of the reason I like SNES programming in the first place.)

Also, that code doesn't work in my environment. WLA doesn't seem to know what a .SNESHEADER is...

I've experienced a lot of bugs with wla, but the .bank directive being broken wasn't one.

You mean .BASE, right? Because if .BANK didn't work, we'd have much bigger problems...

All I know is, the include file template I'm using has a note that "WLA doesn't seem to handle the .BASE directive correctly yet", and sure enough I had to use .BASE $7F instead of .BASE $80 to get FastROM working.

Are you guys sure you're using the latest version? If you're using the windows build from his website, that's not up to date, you need to compile it yourselves (requires cygwin iirc) or find a windows build of the latest source.

That might explain a few things. We're both using Neviksti's SNES starter kit, and I don't recall having to compile anything. [*checks wla.txt*] ...yeah, I'm apparently using version 8.8, which is from 2003; bits of the github repository seem to be only a few weeks old...

93143 wrote: Also, that code doesn't work in my environment. WLA doesn't seem to know what a .SNESHEADER is...

You probably already figured this out, but I'm pretty sure it doesn't work is because you need a newer version of WLA. Ill elaborate on that further down the page.

93143 wrote:All I know is, the include file template I'm using has a note that "WLA doesn't seem to handle the .BASE directive correctly yet", and sure enough I had to use .BASE $7F instead of .BASE $80 to get FastROM working.

Really? I just tried .BASE $3F for SlowROM and It didn't work...

Are you guys sure you're using the latest version? If you're using the windows build from his website, that's not up to date, you need to compile it yourselves (requires cygwin iirc) or find a windows build of the latest source.

Why can't it come compiled already? It's not like It comes in a zip file or anything... Also, I don't have the slightest idea of what cygwin iirc is.

93143 wrote:That might explain a few things. We're both using Neviksti's SNES starter kit, and I don't recall having to compile anything. [*checks wla.txt*] ...yeah, I'm apparently using version 8.8, which is from 2003; bits of the github repository seem to be only a few weeks old...

The only time you have to compile it is when you get it from, what I gather, is the "official" WLA website. I remember because I downloaded the most recent version (9.5?), only to have no clue what I was supposed to do. I think I remember getting a recent version of WLA that had already been compiled on romhacking.com or something like that, and that the .SNESHEADER did work, but I think I accidentally deleted it awhile back. (I'm not sure why I always clean out my recycling bin...)

Espozo wrote:I just tried .BASE $3F for SlowROM and It didn't work...

Can you tell where it's loading from when you use $40? The no$sns debugger lets you see the DMA settings, so a breakpoint or a stp (which no$sns seems to take as a signal to open the debugger) should tell you where the data is actually coming from.

93143 wrote: Oh, so .BASE applies to labels themselves, not the use of labels by opcodes?

That is correct.

93143 wrote: You mean .BASE, right? Because if .BANK didn't work, we'd have much bigger problems...

Yes, sorry I meant .base.

Why can't it come compiled already? It's not like It comes in a zip file or anything... Also, I don't have the slightest idea of what cygwin iirc is.

Presumably because Ville doesn't have time to support binary distributions for every platform, and building it yourself isn't hard. It looks like wla also supports msys now, and VC++, if you prefer any of those to cygwin.
Cygwin is a collection gnu tools ported to windows, iirc is an acronym for if I remember correctly.