That's really cool! Thank you for sharing, tokumaru!tokumaru wrote:Even when using CHR-ROM, addresses $0000-$1FFF can be used to READ from the pattern tables, as some NROM and CNROM games did back in the day. Since these games had very limited PRG-ROM space, they used some of the CHR-ROM space to hold data.
I never thought of doing that ; but, was pondering if we could somehow transfer bank15 from ROM to CHR-RAM to bank!15, our 15th bank if the P bit is set inside "CHR bank 0" (using SXROM), in ROM; but, that's not possible, I think, because ROM can only be set during assembly and RAM must be set after assembly.
There isn't ever a time when one could make a transfer from RAM to ROM. Remember learning that earlier in this thread, I think.
True of mask ROM, false of flash memory. Some recent homebrew games, such as Study Hall, save by writing back to flash instead of using battery RAM.unregistered wrote:There isn't ever a time when one could make a transfer from RAM to ROM.
After using bvs in our game before and it, our game, working just fine on the powerpack, it seems to me that the 6502.org article, linked above, is talking about editing other already-created games.
Yes, the SO pin is floating inside the 2A03. (Visual2A03 node 11246)unregistered wrote:Trying to use a signed comparison because a part of our game needs one, I believe; my question, after reading this really helpful page, is: is the SO pin free from connections to it in our game?
Thank you so much tepples! That's excellent! It's great to not have to worry about the SO pin! Learned from this wikipedia page that the SO pin is at the upper right corner of the 6508 chip... and so that's what it means to connect something to the pin. Thank you lidnariq and tepples for helping my small understanding of the SO pin.tepples wrote:The 2A03 contains a second source 6502, a PSG, and a primitive DMA controller. The SO pin of the 6502 in the 2A03 isn't connected to anything.
edit: It is also nice to understand that 6502.org explains about 6502 chips used in many different types of machines. And that the NES's 2A03 is a unique 6502-based chip.
Code: Select all
altoX = emu.readWord(0x0038, emu.memaType.cpuDebug) emu.drawString(12, 30, "38 | altoX: " .. printf("%4X"), 0xFFFFFF, 0xFF000000, 1)
Did try to add int before the text on the line where altoX was assigned but, received an error. Please help me; I don't know how to make this work.Loading script...
Script loaded successfully.
MemDisplay00.lua:16: attempt to call a nil value (global 'printf')
I realize now that you were talking about addition, but wouldn't the carry always be affected after subtraction too?Kasumi[color=#FFFF00] in [url=http://forums.nesdev.com/viewtopic.php?p=112830#p112830]the middle of page 67[/url][/color] wrote:Anytime you add a number and result would have been greater than the byte can hold, the carry is set. Otherwise it is cleared.
If so, since the carry flag is affected by cpx, why does cpx #00 not clear the carry... ohh, think I get it now... you would say, "Anytime you subtract a number and the result would have been less than the byte can hold, the carry is cleared. Otherwise it is set." That seems correct to me. I'm so happy now!!
edit: Kasumi already answered this in the same post in page 67:
Kasumi wrote:1. The carry is ALWAYS taken into account when you use adc or sbc, so make sure it's right for the operation you intend to do before that operation runs. (Clear before addition, set before subtraction)
2. The carry will become the opposite of what you would normally initialize it to if the operation goes outside the boundaries of a byte. (So if an addition would have yielded more than 255, or a subtraction would have yielded less than 0.) Otherwise, the carry becomes what you would normally initialize it to.
final-edit: highlighted most important part of quote. | 20181012: corrected 69 to 67
I am blessed to be able to present a small asm6 fork named asm6_. I'm clueless about if anyone will care. All it does is allow a user to use a -u flag when creating a NES file. That -u flag currently allows the listing file to be created with:
1.) REPTs contracted
2.) MACROs expanded
This really helps my browsing through our .lst file because most of our banks begin with a .rept 256 and that causes lots of repetitions of 256 lines. Thankfully, now with the -u flag none of those 256 lines appear in our listing file.
I really like looking at our expanded macros and, if God works with me on this again, I hope to also remove the macro definitions from the .lst file when using the -u flag bc they just sit there doing nothing for me.
The asm6_.zip contains: asm6_.c, asm6_.exe, and README_.TXT. ...in the same format as asm6.zip.
asm6_.zip <that's hosted on my unsecure website. My website has been unchanged for a looong time, oh well.
The file, link is in my post two-posts-above this post, has been replaced again.
This is my first time creating an executable file for others to use.
final edit. 20190202 ~11AM