It is currently Tue Jul 25, 2017 3:26 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Apr 26, 2017 4:19 pm 
Offline

Joined: Wed Apr 26, 2017 2:26 pm
Posts: 11
That format advice is a good one. I was really wondering why there is no "meta header" like they use for NES ROMs for emulators - which are removed if you burn it into a chip to use on a actual NES. Fun, but you need the proper tools like a ROM burner(which I luckely own).


Top
 Profile  
 
PostPosted: Wed Apr 26, 2017 4:39 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 357
Location: ...
Forgot to mention, I recommend you don't take the time to try making aliases for all the SNES's registers (trust me, there's a LOT of them, and that's a LOT of time). Instead use this, as it has everything you need all under a fairly permissive license. Even macros for changing register size.

_________________
Buy stuff from my brother's retro gaming store!


Top
 Profile  
 
PostPosted: Wed Apr 26, 2017 4:53 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18670
Location: NE Indiana, USA (NTSC)
melanokardios wrote:
That format advice is a good one. I was really wondering why there is no "meta header" like they use for NES ROMs for emulators - which are removed if you burn it into a chip to use on a actual NES. Fun, but you need the proper tools like a ROM burner(which I luckely own).

It's because Super NES emulators are capable of reading most parameters needed for emulation out of an internal header at whatever part of the file maps to $00FFB0-$00FFDF. Every game for Famicom Box has an internal header, but it wasn't mandatory for NES games not released for Famicom Box.

Besides, even if all NES games had an internal header, the emulator would still need to know where PRG ROM ends and CHR ROM begins. The Neo Geo and NES are the only well-known consoles to use a CHR ROM on a separate bus. Everything else either multiplexed CHR data over the PRG ROM bus (Atari 2600, 7800) or used a separate CHR RAM inside the console (just about everything else).


Top
 Profile  
 
PostPosted: Wed Apr 26, 2017 5:21 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 128
tepples wrote:
at whatever part of the file maps to $00FFB0-$00FFDF.

That is one of the tricky parts, though, because unless you know ahead of time what that mapping is (e.g. known ROM hashes), you can't figure out that mapping without doing some guesswork. This involves judging whether the data at file offset 0x007fc0 or the data at 0x00ffc0 looks more like a plausible header, by looking at things like whether the title is ASCII, whether the reset vector jumps to something plausible (e.g. sei \ clc \ xce or jmp ...) or something implausible (e.g. brk #$00), whether the mapping the header claims matches where it is in the file, whether the checksums are valid, and so on.

For instance, here are the heuristics that higan uses.


Top
 Profile  
 
PostPosted: Thu Apr 27, 2017 12:08 pm 
Offline

Joined: Wed Apr 26, 2017 2:26 pm
Posts: 11
I found one of the reasons why my code wouldn't work: I set the A, X and Y registers to 16 bits (rep #$38) before setting the processor to native mode (clc followed by xce). Therefore all following opcodes were translated wrongly(with 8 bit registers) as I found out with a help of a disassembler.

In the meantime I got my basic code running, now I'll try to get my first sprite displayed :D

EDIT: Again I see myself confronted with a similar problem: A is set to 16 bits but lda #$0000 will translate to A9 00 in Hex code, which is obviously wrong.

EDIT2: Forget my first edit, I just forgot to tell the assembler what I was using with .smart


Last edited by melanokardios on Thu Apr 27, 2017 12:55 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Apr 27, 2017 12:54 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 357
Location: ...
It makes me wonder if ca65 is confused by the lower half of the byte you're passing through rep; you don't need to set it to 8.

_________________
Buy stuff from my brother's retro gaming store!


Top
 Profile  
 
PostPosted: Thu Apr 27, 2017 1:23 pm 
Offline

Joined: Wed Apr 26, 2017 2:26 pm
Posts: 11
nicklausw wrote:
It makes me wonder if ca65 is confused by the lower half of the byte you're passing through rep; you don't need to set it to 8.


No, that wasn't a problem, it was really switching into native mode after setting the status bits. But so far I am moving along fine, I managed to load CG RAM with my palette using DMA, now I'm off to fill OAM and VRAM.


Top
 Profile  
 
PostPosted: Tue May 02, 2017 1:24 pm 
Offline

Joined: Wed Apr 26, 2017 2:26 pm
Posts: 11
Busy weekend, but today I had some time to code again. And, of course, I ran into a problem again.

Here's another weird behavior: whenever I load my ROM into bsnes emulator, at first it won't work(the Properties viewer will show that some of my initial DMA register settings are off, therefore no proper transfer of OG, OAM and VRAM data) - but when I hit reset after initially loading the ROM it will work correctly.

According to the Programming Manual the behavior at startup and reset should be identical. Has anyone experienced something like this? I guess it's the emulator, but I'm not sure, still trying to find something debugging my code.

EDIT: Found it myself. Apparently, on powerup bsnes will set all registers to $ffff, while on reset it will set them to $0000 - I assumed they're set to zero, there my code set the DMA transfer size to $ff12 instead of $0012 (I only set the lower byte wrongly used A with 8 bits instead of X/Y with 16 bits) hence the wrong behavior on startup but correct on reset.


Top
 Profile  
 
PostPosted: Tue May 02, 2017 2:17 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 128
You should not rely on the state of anything at powerup and reset.

I/O register contents and WRAM/VRAM/CGRAM contents can potentially be anything at power-on, and generally keep their values across resets. In addition, if someone is using a flashcart to run your ROM on the real console, the flashcart will probably display a menu of some sort, so there's no guarantee your code will be the first thing to run on the SNES.

Because of this, it's important to initialize absolutely everything, because bad init code can lead to some really hard-to-find bugs down the road, if your code ends up relying on non-deterministic values.


Top
 Profile  
 
PostPosted: Tue May 02, 2017 2:32 pm 
Offline

Joined: Wed Apr 26, 2017 2:26 pm
Posts: 11
Yes, I can see that now. I know, this wouldn't work on real hardware, but I thought a emulator would give me enough leeway that I could get away with some quick&dirty code(NES emulators seem to be more forgiving in that regard).


let's see if I get finally get a sprite displayed tonight. NMI/VBlank is still troubling me, even with a simple read to $4210 in NMI, my routine is still of somehow.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group