ca65 Indirect Indexed labels

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
Trozze
Posts: 4
Joined: Thu Jul 11, 2013 3:27 am
Location: Sweden

ca65 Indirect Indexed labels

Post by Trozze »

Hello, I am new to 6502 assembler and are working on a project for the FamicomBox.
I am using CA65 and I have gotten most of the things working, but there is one thing that I just cannot understand how to do...

Let us say I make a label "OBJECTLIST:" and the assembler puts the code to $8090.

If I later in the program wants to do Indirect Indexed to "OBJECTLIST", how do i get the high/low offset byte of "OBJECTLIST" so I can write it in RAM so I can modify the high-byte when needed?

Now I have to keep a record of the location and hard code it. I guess there is a simple solution to this. :?

Thanks! :lol:
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: ca65 Indirect Indexed labels

Post by Memblers »

For the low byte, LDA #<OBJECTLIST. For the high byte, LDA #>OBJECTLIST. So, using the > and < symbols
Trozze
Posts: 4
Joined: Thu Jul 11, 2013 3:27 am
Location: Sweden

Re: ca65 Indirect Indexed labels

Post by Trozze »

Thank you Memblers! :D How could i have missed that?! :| :shock:
This will help me alot with my FamicomBox BIOS development, much easier to move around the data now!
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: ca65 Indirect Indexed labels

Post by Fiskbit »

What are you doing with the FamicomBox? I've been making changes to the menu software, as well. Definitely interested in whatever people are doing with it.
Trozze
Posts: 4
Joined: Thu Jul 11, 2013 3:27 am
Location: Sweden

Re: ca65 Indirect Indexed labels

Post by Trozze »

Fiskbit wrote: Tue Aug 09, 2022 4:47 am What are you doing with the FamicomBox? I've been making changes to the menu software, as well. Definitely interested in whatever people are doing with it.
First I started disassemble the BIOS to understand how it worked. I am writing my own BIOS for the FamicomBox from scratch, thought it would be a great place to learn 6502 and the NES.

Last night I finally got it to check my internal checksum database and list the names of all cartridges inserted into the machine.
It does this by adding the 3 16-bit interrupt vectors (And for a few games that has the same it checks some extra bytes).
Right now, it recognizes almost every NTSC and PAL NES game. Still got some bugs but it work 90% of the time.

Here are two blurry pictures I took yesterday, Some graphical glitches aside :D
Box1.jpg
Box2.jpg
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: ca65 Indirect Indexed labels

Post by Fiskbit »

This is really cool! Making a menu from scratch is something I'd love to do at some point and I think it's great someone else is working on this, too. So far, I've been hacking the original menu software to go along with a hardware mod we've been developing that improves the console's compatibility with various cartridge hardware. The modified menu contains bug fixes, load time reductions, and usability improvements, and allows any game to be played. I still need to add a new game database with the full NTSC/PAL set and some hacks and homebrews. I've about settled on a way of handling this, by generating two 16-bit checksums covering $E000-EFFF and $F000-FFFF, which appears to be enough to uniquely identify games outside of some edge cases like multicarts. I want to make absolutely sure I'm not misidentifying games, and I'll be extending the Nintendo header so new games can override the database, allowing them to avoid the possibility of collisions. Using just the vectors is nice because of the speed and I actually use them to verify a slot isn't empty, though I really worry about collisions with new or unknown software, however rare it might be. Even with having to generate checksums, I can probably do the work for all 15 slots in about 1 second, so it's thankfully not too expensive.

I'm doing this as a hack rather than new software for two reasons. I want to preserve the feel of the original, which is best done by keeping the original implementation. I also want to keep all of the original functionality, and there is a lot in the original code I simply don't understand or which would be difficult to test, such as CATV billing.

Not sure if you've seen it, but I recently documented the system on the wiki here. If you end up using this, please let me know if you find any errors or missing content!
Trozze
Posts: 4
Joined: Thu Jul 11, 2013 3:27 am
Location: Sweden

Re: ca65 Indirect Indexed labels

Post by Trozze »

I was unsure if some mappers would boot on unknown banks, that's why I chose to just checksum the vectors (thinking it was more likely they kept the same in all banks).

But as you said, there are checksum collisions, my program does an 8bit "extra checksum" of $FFE0-FFFF, so when the program finds a "collision"-marked 16-bit checksum - it also checks the extra byte. Maybe it's overcomplicating it, but hey, it works :)!

Updating/Patching the original BIOS is the right way to go (And to keep the catchy music :lol: ). But it's rewarding to build it yourself to, I have learned lots working on it :D

Do you have a thread that you post about your updates? Would be nice to follow your progress and read about the bugfixes!
I am also working on increasing the compatibility with more "modern games", like enable read/writes to cart SRAM instead of using the one on the motherboard.

That wiki article is really great, have had lots of help from it when I started! Still can't find any errors in it, but I'm sure to update it if I find any or some "new" discoveries. :D
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: ca65 Indirect Indexed labels

Post by Fiskbit »

Some mappers do boot up with the highest bank in an unknown state. This is actually a significant problem and may have even prevented such games from working reliably on the original system. MMC1 is the main example of this. Unfortunately, just checking the vectors isn't sufficient even in this case. For example, Zelda 1 has different vectors for banks 0-6 vs bank 7, because the bank 0-6 vectors reference the swappable region of memory, not the fixed one. Specifically, bank 0-6 vectors are "84 E4 50 BF F0 BF", while bank 7 vectors are "84 E4 50 FF F0 FF", and bank 7 is the only one with a Nintendo header. The original menu attempts to put the mapper into a good state before it checks the header and performs a checksum, but its actions aren't sufficient for MMC1, which would benefit most from being reset (written anywhere with bit 7 set). Because you can't simply know the mapper of whatever game is plugged in, it seems you need to come up with a way of initializing that puts the most games into the best state, which is something I haven't solved yet. Because many mappers have bus conflicts, it's also preferred that writes be done that don't cause bus conflicts, which means scanning the ROM looking for a suitable value to write to, which might take time. This is unfortunately a very messy problem.

The mod work has been discussed just on the Discord server (linked on the wiki) as problems come up. After many revisions, I think the hardware stuff is all done now, and a guide for it will be written. There were some surprising issues along the way, such as the 5V and ground connections on the EXP pins damaging carts (the guy actually making the mod fried the expansion audio on an Everdrive N8 Pro, and I fried a level shifter in a prototype for a modern game), and the capacitor on PPU A12 in MMC3 carts interfering with other cartridges in the same column. On the software side, I'll release the hack's source code alongside the hack. Probably the biggest fix I have in there is ensuring APU registers are properly initialized before starting a game, which was breaking audio in Mega Man 1. There's more initialization I should do, but haven't gotten to that yet.

For the $6000-7FFF memory region, our solution was to repurpose the unused register bit $5004W D7 as a chip enable for the console's RAM (1 = enable). When the menu cart is selected, the RAM is enabled, and otherwise it's disabled. I intend to include a mechanism in the expanded header format for a game to request that this RAM be left enabled for it.
Post Reply