SNES Hi/Fast ROM Header Problems

[bazz]

Ok I'm done. I'm zipping everything for you.

SPECIAL NOTES: Use .BASE $80, that way you can just phk and plb, you HIROM banks will match the correct LOROM ones, at least for $40 banks or so, that should get you by.

The reason I say this is because only banks 00-3f (pretty sure that's right) can access hardware registers $2000-$4fff or w/e. So if you have code in $c0, it's only ROM from $0000-$ffff, it cannot access the hardware registers without assigning a seperate data bank from its program bank. Therefore, it's more complicated. So if you just use HIROM banks $80-($80+3f), then you can match the program bank with the data bank, and still be able to use hardware registers. You should be fine.

Now, if you really want to get else, I'm not going to help you with that because that's complicated. It involves knowing that your data bank will most likely have to be different from your program bank. But if you do it the way I just told you to do, you shouldn't have a problem with that.

So just use what I gave you, or at least check it out and see what's happening. I'm 100% sure that it works.
here's the zip: http://www.cs.umb.edu/~bazz/Lesson2.zip

[bazz]

Another note is that you never do in fact CLI, the re-enables the interrupts. so if you find yourself adding interrupts later and they don't work. Then you'll know why

[bazz]

You don't yet use your NMI routine, but when you do, take note that the program bank and process register get pushed pulled, but everything else is in your hands. This includes data bank, accum, index regs, and direct page

[tepples]

So is it enough to PHB PHA TDA PHA PHX PHY on entry and PLY PLX PLA TAD PLA PLB RTI on exit?

[bazz]

here's the latest code update for the man who asked this thread:
http://www.cs.umb.edu/~bazz/Lesson2_NMI_final.zip
Please see the below comments for important information regarding your code and my advice to you is to stay LoRom. You are not ready yet. Not in my opinion at least.

Tepples, make sure you rep #$30 before, both times, to ensure saving 16 bits.
also, it's easier to just use phd pld for the direct page.
here's what I am using for the FastRom NMI:

Code: Select all

VBlank:
    jml FastVBlank
FastVBlank:
	rep #$30
	phb
	phd
	pha
	phx
	phy

	; 
	phk			; only works for VBlank being in $00-3f $8000+
	plb			; otherwise data bank must not match program bank
    
	
       ; DO STUFF


    rep #$30
	ply
	plx   	
	pla
	pld
	plb
	rti

LycanLambda, I think you should stay in LoRom. This level of coding you are not ready for it. I'm being honest. You'll have a more enjoyable experience elsewhere. Probably easier to stick to LoRom for now. Ditch the fastRom, SuperMarioWorld was a slow rom game and did you ever think it was running too slow?? Not I..

Among other things, I noticed multiple sections of code with no WLA sections housing them. So I brushed up the code. You need to make sure that in the way his memory map is, that you use SEMIFREE sections .org'd at $8000, this ensures that the code that you want to be able to access hardware registers doesn't accidently get moved to an address under $8000, those addresses are not mirrored into the banks that can access hardware registers.. Coding in LoRom Slowrom will take most of these concerns away. Practically all. except for ROM in banks $40-$5f. But we doubt you need that much, because as I learned, you typically know what you're doing by the time you need that much space anyways.



Anyway mate, here is the code modified, and this one actually enables your NMI routine I modified to preserve important registers, and it changes the screen color every several VBlanks in order to observe successful testing. The colors are black and white, but the white is grey because you didn't turn screen brightness all the way up (at least how it appears in my bsnes and zsnes. I just confirmed that turning screen brightness all the way does indeed make white look white )

There is another caveat in programming with FastRom/HiRom. You must be more explicit in your addressing modes. if you do

Code: Select all

lda $00

or even

Code: Select all

lda $0000

I have observed WLa assembles this as a direct page addressing. Direct page addressing always loads direct address from Bank 0. This may become problematic if that is not what you expected, thinking lda $0000 was loading an absolute address. Therefore, you need to be tighter and more explicit, saying

Code: Select all

lda $0000.w

to sharply express desire for the address to be word-long. and then WLA will assemble as an absolute address which takes advantage of the Data Bank Register DBR.

So once again, here is the fina final version of your code. I manipulated a lot.
One must have a greater understanding of ROM addresses vs. what these addresses become in the SNES memory map. This is easier understood with LoRom. for instance,

Code: Select all

LoRom Example
ROM $00:0000-7FFF = SNES $00:8000-ffff 
ROM 00:8000-ffff = SNES $01:8000-ffff 

so in ROM all the memory is linear 100% always. In the SNES map, it gets chopped and screwed, just depends on the memory map. LoRom is easier because it is basically always chopped in $8000 byte-size chunks, seperated by $8000 in each SNES bank. HiRom is a different story, judging from the SNES Memory maps I have seen (not always corellating, thefore I wait for my conclusion until I dump my own), the difference is big. To say the least. I'll evolve more on that in the future.

Take care, and again, lastly, here's the latest code update for the man who asked this thread:
http://www.cs.umb.edu/~bazz/Lesson2_NMI_final.zip

[bazz]

There is a simpler way to specify the difference between Hardware-accessible ROM and hardware-inaccessible ROM for WLA.

First, we used this Memory map:

Code: Select all

.MEMORYMAP
    SLOTSIZE $10000    ;Slot size of $10000 bytes
    DEFAULTSLOT 0       ;Default Slot for Reset, NMI and other interrupt vectors
    SLOT 0 $8000
.ENDME

Then you had to make sure to use SEMIFREE sections that started at least at $8000 for hardware accessible regions. that's a bit cumbersome and strict. We could more easily do this:

Code: Select all

.MEMORYMAP
    SLOTSIZE $08000    ;Slot size of $8000 bytes
    DEFAULTSLOT 0
    SLOT 1 $0000        
    SLOT 0 $8000
.ENDME

Here we divided the slotsize by 2, and now have 2 seperate slots, SLOT 1 and SLOT 0. You can use SLOT 0 for all your hardware register accessing code, and SLOT 1 for other stuff that cannot access hardware registers.. Wait a minute. Don't forget. SLOT 1 CAN access hardware registers if you manipulate the data bank register and use addressing modes that make use of it

Still, this simplifies.


I also wanted to explain more on the difference between ROM and SNES addresses.
I'm going to make another post explaining the difference between ROM and SNES memory to you.

When you have a ROM chip, it's a black chip, and it has pure linear memory on it. so if it's the size of Super Mario World (4 Mbit), then it is $080000 bytes long. I'm talking $080000 bytes right straight in a row. No gaps.

The SNES comes along, and using the power of technology, only grabs parts of the ROM at a time, only for certain addresses, and it grabs other stuff too, like PPU registers, maps that, and it becomes the SNES memory map.

When you code though, you are only coding a ROM. there is no ROM address at $c00000,for instance. and you need to learn discover that $c00000 in HiRom is actually ROM $000000. That's right! Here's let's observe this in BSNES in a hex editor of the ROM


Now a guy without this knowledge would might think he has to get his code at $c0:0000 in the ROM, making sure to do all kinds of strange things like adding enough ROM banks to get to $c0. When he would be doing it all wrong, $c0 is just a mirror of the very FIRST bank. it gets a little weirder. We won't go that far :0 Ok let's go there so we see $c0 is ROM 00:0000-7FFF, actually ROM 00:8000-FFFF = SNES C0:8000-ffff and also SNES 00:8000-FFFF. That's the gist, and now that you understand that. You can learn the rest yourself from this file (most likely): http://www.cs.umb.edu/~bazz/SNESMem.txt

[bazz]

So is it enough to PHB PHA TDA PHA PHX PHY on entry and PLY PLX PLA TAD PLA PLB RTI on exit?

Tepples want to make one more note on that: when you lack rep/sep in your code, at least on WLA, it may help or even require you to use .INDEX or .ACCU directives to explicitly tell the assembler "the (A/X/Y) register is going to be THIS big (8/16)" this is to make sure that WLA doesn't accidently do the wrong setting without explicit notice through a rep/sep instruction. I used to run into trouble when doing it on my programs that included outside source files that already knew what the P flags would be. But when WLA when to assemble them, IT didn't know, so I got code errors. So Do that. (If you're using WLA), it's good back-knowledge no matter the assembler.

[koitsu]

Comment in passing: I really wish you would stop saying "ROM {some address}", and start saying "file offset {some address}". Example:

When you code though, you are only coding a ROM. there is no ROM address at $c00000,for instance. and you need to learn discover that $c00000 in HiRom is actually ROM $000000. That's right! :)

I just got done dealing with that in another thread on this board. The OP needs to understand that there is no direct correlation between the ROM file offset and actual memory location in the console itself. All this is further compounded by the different memory modes/models available on the SNES/SFC.

TL;DR -- When explaining how something works to someone who has little or no familiarity with a subject, use literal/exact terms and not shortcuts/ambiguous terms (like "ROM"), as all they potentially do is induce confusion in the recipient.

[bazz]

I messed with it some more. Had to add #01 to $420d. Be sure to not bother with this. It's over your head. Why are trying to do this again? I'll be sure to read your original post. Once again, stick with SlowRom, LoRom being the simplest. http://www.cs.umb.edu/~bazz/Lesson2_fas ... _blink.zip

Comment in passing: I really wish you would stop saying "ROM {some address}", and start saying "file offset {some address}".

No. The reasoning behind this is that I cannot identify ROM as a file offset. It's on a black chip, I'm not calling it a file offset. I believe the correct logistic is to use prefix SNES for SNES address, and ROM for ROM address. And to clarify this before details is always a +

[tepples]

I cannot identify ROM as a file offset. It's on a black chip, I'm not calling it a file offset. I believe the correct logistic is to use prefix SNES for SNES address, and ROM for ROM address.

I'm inclined to agree. For ROM images without a copier header that aren't split across multiple chips, "ROM offset" and "file offset" are one and the same.

[bazz]

I cannot identify ROM as a file offset. It's on a black chip, I'm not calling it a file offset. I believe the correct logistic is to use prefix SNES for SNES address, and ROM for ROM address.

I'm inclined to agree. For ROM images without a copier header that aren't split across multiple chips, "ROM offset" and "file offset" are one and the same.

Thanks for the support Tepples, not for me for the facts. I stand for the facts.

[Ramsis]

JSL SNES_init. not JML.. like the guy above me said.

I didn't say anything like that.

[bazz]

that was koitsu i was referring to. i was in turbo mode so i didnt bother checking names.

[ARM9]

+1 to sticking with lorom, hirom is a mess if you're new to the SNES. Fast+lorom is easy enough to implement, can't think of any reason to avoid fastrom.

[koitsu]

ha meh that was koitsu i was referring to. i was in turbo mode so i didnt bother checking names.

I've fixed this. Thank you.