NES Development and Strangulation Records message boards
*laugh* You crack me up man. :P Good thing I've been drinking this evening.tepples wrote:So I split out two more files. Now before I push out a new version of NROM, SNROM, and LoROM, I'm just waiting for koitsu to rip me a new one with constructive criticism :?
If you're referring to this post, is there a reason you use .rar instead of the more widely supported .zip?koitsu wrote:if you could download (in the other SNESdev thread, re: "issues with 16-bit indexing") the MetaspriteTestKoitsu stuff, that might give you some insights into how I tend to lay things out.
I have added a comment to lorom256.cfg to address my reasoning behind this:koitsu wrote:and after trying to implement "true direct page" I now understand why you did stuff like leave ZP from $10-FF, although IMO that should really be $00-FF. If there's a reason for $10-FF I'd love to know what it is!
Code: Select all
# I usually reserve $000000-$00000F for local variables # allocated just below the .proc statement of a subroutine. # The rest is open for global variables.
Not sure what you mean by this. Are you referring to my habit of spacing inline comments from the code by 2 spaces instead of tabbing all the way out to column 41 or thereabouts?koitsu wrote:Things aren't formatted very well (aligned spacing, etc.).
The NMI handler is actually in main.s. What you're seeing here are handlers for the unused vectors. The S-CPU has no /ABORT signal, and the program doesn't use the /IRQ signal or BRK or COP instructions or 6502 emulation mode (except for the first couple instructions).koitsu wrote:One of my main complaints is that in snesheader.s (?) you actually have your NMI handler
Code: Select all
cop_handler: brk_handler: abort_handler: irq_handler: ecop_handler: eabort_handler: enmi_handler: eirq_handler: rti
Which makes main.s even longer. I tried to separate it out because it's something the user doesn't need to touch quite as often.koitsu wrote:You'll see in what I implemented for Espozo that I stuck [the init routine] into Main.asm with the rest of the code.
Espozo wrote:another thing that would make the code a lot more "comprehendible" would be if you actually separated these into separate files.
I need the quick reference to save me from having to pull up Fullsnes all the time. You might notice I did the same with "pin8gba.h" back when I was homebrewing for GBA.koitsu wrote:While describing each of the bits in an MMIO register the way you do is understandable (for quick reference), I imagine most people doing development fall into two categories: a) not knowing what the bits do + already have something open (PDF, etc.) that documents them, or b) know what the bits do and don't need the quick reference.
I'm not officially supposed to have access to that manual, and I wanted to avoid the appearance of misappropriation.* So for most MMIO ports, I chose names that made sense to me in the context of the quick reference. You might notice that I left the HDMA-related names commented out because I haven't played with HDMA yet.koitsu wrote:The names of the equates should also be the same as what's in the official SNES developers manual
You can get the address of a segment. If you put define=yes, ld65 will export symbols for the segment's size, its run address (where the data is used), and its load address (where its data was stored in ROM, which doesn't exist in the case of BSS-type segments). In blarggapu.s, based on an example by (guess whom), I use this to send the SPC700's executable image to the SPC700 IPL.koitsu wrote:I wish there was some kind of programmatic way in ca65/ld65 to "get the address of a MEMORY section"
"define=yes" is also supported for MEMORY specifications.tepples wrote:You can get the address of a segment. If you put define=yes, ld65 will export symbols for the segment's size, its run address (where the data is used), and its load address (where its data was stored in ROM, which doesn't exist in the case of BSS-type segments).koitsu wrote:I wish there was some kind of programmatic way in ca65/ld65 to "get the address of a MEMORY section"
".inc" might be a good choice here, given that cc65 library source code also uses it for its assembly include files (https://github.com/cc65/cc65/tree/master/asminc). One more advantage to not using ".h" is that text editors will have an easier job telling apart C and assembly source.koitsu wrote:I would also strongly suggest that the file not be named with an .h suffix, as it implies C header syntax. I'm willing to bend on this, but I think Espozo also mentioned this. Things that get .included I tend to name either .asm or .inc (often opting for the former, because assembly code is assembly code, even if all it is is a huge bunch of FOO = $xxxx statements). But I'm flexible.
Code: Select all
2100=80 // Forced blanking 2101-2103=00 // Skip 2104: OAM write 2105-210C=00 210D-2115=00 00 2115=80 // Increment VRAM after high byte write 2116-2117=00 // Skip 2118: VRAM write 211A=00 211B=00 01 // Top left 1 in identity matrix for mode 7 211C-211D=00 00 211E=00 01 // Bottom right 1 in identity matrix for mode 7 211F-2120=00 00 2121=00 // Skip 2122: CGRAM write 2123-212F=00 4200=00 4201=FF 4202-420D=00
Code: Select all
LDX #$2101 _Loop00: ;regs $2101-$210C STZ $00,X ;set Sprite,Character,Tile sizes to lowest, and set addresses to $0000 INX CPX #$210D BNE _Loop00 _Loop01: ;regs $210D-$2114 STZ $00,X ;Set all BG scroll values to $0000 STZ $00,X INX CPX #$2115 BNE _Loop01
Code: Select all
stz $2101 stz $2102 stz $2103 stz $2104 stz $2105 stz $2106 stz $2107 stz $2108 stz $2109 stz $210a stz $210b stz $210c stz $210d stz $210d stz $210e stz $210e stz $210f stz $210f stz $2110 stz $2110 stz $2111 stz $2111 stz $2112 stz $2112 stz $2113 stz $2113 stz $2114 stz $2114
And poor translation from Japanese to English can be horrendous, as I'm sure we all know.koitsu wrote:Well, the preceding paragraph is badly translated, so it's difficult (without seeing the Japanese docs) to know what exactly they're trying to say. It all sounds flexible up until the very end where it says "...and initial settings must be performed". The chapter is called "Register Clear (Initial Settings)", so the way I've always read the paragraph is: "no matter what you do later in the code, you need to make sure these exact values are written to their associated registers on reset (power-on)".
koitsu wrote: The official docs don't include any code -- they just tell you what each register needs to be set to value-wise on reset. So no, it's simply people being ridiculous and for some reason thinking that this one-time-called routine deserves loops and other nonsense (like "don't bother initialising some registers because we set them in the near future anyway" -- WHO CARES, do the init exactly like Nintendo says, do it one time, and stop worrying about the rest!)
If all they have is register values, they have not mandated any kind of routine; they don't even mandate an order (in the page you posted).koitsu wrote:meaning it's the closest to the official init routine Nintendo mandates,
koitsu wrote:I WISH PEOPLE WOULD STOP SCREWING AROUND WITH THE INIT ROUTINES: THERE IS NOTHING TO FIX/OPTIMISE IN THEM. THEY ARE RUN *ONCE* DURING RESET/POWER-ON. JUST USE THE VALUES NINTENDO GIVES YOU IN THE OFFICIAL DOCS AND BE DONE WITH IT. YOU DO NOT NEED LOOPS ETC. (THOSE ARE JUST SLOWER THAN UNROLLED) AND ALL IT DOES IS OBFUSCATE THE CODE. PLEASE STOP WRITING INIT ROUTINES OR "OPTIMISING THEM".
So, unlike a routine that gets run incredibly often multiple times, it has the worst possible speed payoff for unrolling. (Well, there is code that NEVER gets run, but...) Normally, unrolled loops and heavy-duty for-time optimization are for either a. time-critical code (like in VBLANK on NES) and b. oft-called code. Initialization is neither, and tens of loop iterations are going to lose negligible time. And, if we really are going to insist on having the best possible init routine,koitsu wrote:Again, remember, ROUTINE IS ONLY USED ONCE.
then redundant loads are not going to be the way.koitsu wrote:And yes, there is some redundant code in there