8x16 and whatever else unreg wants to know

[unregistered]

So after working on asm6_ today we now provide -U flag for listing file creation.

The -U flag expands only MACROS while they are being used; their definitions are hidden! I'm so thankful to God and happy!!

The -u flag still exists incase anyone uses this and wants the MACRO definitions shown.

-l and -L flags still work like they were designed to

asm6_.zip //current version is now 1.6_0.12


p.s. This asm6_.zip is clean (no viruses) and its executable is way smaller than asm6.exe v1.6. And after some testing I think it performs just as good.

[unregistered]

ASM6_ INFO FOR INEXPERIENCED:


asm6_'s -u and -U flags, and the original -l and -L flags, only affect the listing file .lst that's created... i.e. using the -U flag will not hide your macro definitions in any of your code files .asm. Listing files are super helpful, but are only there to visually help you... changing a listing file has no effect on your .nes file.

No effect on your .nes file itself... but, changes to your .lst may very well affect your ability to benefit while viewing your .lst, which may prevent progress on your game design. That's easy to fix: just rerun asm6_ with a different listing flag (-l, -L, -u, or -U) and the appropriate listing file will replace your current .lst file (caution: your .nes file will also be updated) .

Note: running asm6_ with all of the listing flags will build a -L listing file just like loopy designed asm6 to do.


edit.

[unregistered]

After some reading it seems the limit to an asm6 .hex command is 252 hex codes. (Bc strings in c have, or had, a 509 character limit. 509-5=504. Taking off the 5 characters for .hex and the following space. 504/2=252. Divide by 2 bc each hex code takes 2 characters.) Is this 252 hex code limit for asm6's .hex command true? Or is the limit even lower? If so, why?

Asking this bc I'm trying to include my sister's RLE .hex lines... and they are very long, a line per screen, and the line being tested has been trimmed down to 127 hex codes, the line is 261 characters long bc of the extra space in front of .hex, and I'm still receiving address out of bounds errors while running gdb.

edit: is each line limited to around 256 characters? That nes limitation doesn't make sense, to me, if it applies to asm6 written in c.

[tepples]

After some reading it seems the limit to an asm6 .hex command is 252 hex codes. (Bc strings in c have, or had, a 509 character limit.

C strings have no length limit beyond SIZE_MAX, which is in the tens of kilobytes at minimum and the gigabytes on modern platforms. A particular implementation that allocates a buffer on the stack to hold a string limits the length of the string to the length of the buffer. For example, a 512 (that is, 1<<9) byte buffer can hold 509 characters plus CR, LF, and NUL.

[unregistered]

After some reading it seems the limit to an asm6 .hex command is 252 hex codes. (Bc strings in c have, or had, a 509 character limit.

C strings have no length limit beyond SIZE_MAX, which is in the tens of kilobytes at minimum and the gigabytes on modern platforms. A particular implementation that allocates a buffer on the stack to hold a string limits the length of the string to the length of the buffer. For example, a 512 (that is, 1<<9) byte buffer can hold 509 characters plus CR, LF, and NUL.

That's kind of what was learned from StackOverflow, 512-CR-LF-NUL=509, so, let's say I'm restricted to a 512 byte buffer, what is asm6's limit on the length of the .hex line?

I'm going to try reducing the line to less than 256 characters, even though that doesn't make sense to me bc .hex tells asm6 how to behave in c. As long as the hex codes get into the right spots in the NES' ROM I'll be overjoyed.

[tokumaru]

Why do you need such long strings of hex data anyway? Having lots of data in text format isn't very efficient (takes over twice the space, takes longer to parse), so unless you're constantly hand editing that data, it's best to just include it from binary files.

[unregistered]

Why do you need such long strings of hex data anyway? Having lots of data in text format isn't very efficient (takes over twice the space, takes longer to parse), so unless you're constantly hand editing that data, it's best to just include it from binary files.

Asking this bc I'm trying to include my sister's RLE .hex lines... and they are very long, a line per screen

1.) If my sister decides to change something on a screen, long lines of text would be easier to change than a binary file.
2.) Takes over twice the space before the game is assembled bc a text hex code consists of 2 bytes/characters and a binary byte takes only 1 byte? And it takes longer to parse while assembling the game because the data is twice as big? If you mean both of those, then the .hex text format will run just well as the binary format inside the NES game (bc they'll both end up in binary format). Without a doubt, we decided on using the .hex text format bc, as you mentioned, it is easier to edit. We aren't constantly editing the screens, though it takes a very small amount of time to assemble our game right now, before trying to add .hex text, so the longer parse time seems reasonable. I'll post asm6's .hex limitations if this is figured out.

[unregistered]

Ok, so asm6 is limited to 64 hex codes following its .hex. (i.e. When our game assembles, the cursor at the end of most of our .hex lines is in column 135. The hex codes start, after .hex, in column 7. 135-7=128. 128/2=64.) Why this limitation-have no clue right now. With 65 hex codes per line asm6 gives, "Not a number."

[tokumaru]

1.) If my sister decides to change something on a screen, long lines of text would be easier to change than a binary file.

But doesn't she find it hard to find what exactly needs to be changed in these huge strings? If the screens are made of metatiles in a grid, she should at least consider to have one hex string for each row, as opposed to one the entire screen. It'll be easier to edit and will not cause problems doe to the emulator's maximum line length.

2.) Takes over twice the space before the game is assembled bc a text hex code consists of 2 bytes/characters and a binary byte takes only 1 byte?

Yes. Not that this is a big deal considering today's typical storage capacity, but still.

And it takes longer to parse while assembling the game because the data is twice as big?

It takes longer because the data is twice as big, and it's read as text, meaning it has to be converted to byte values before they can be written to the output. Again, not a big deal considering today's typical processing power, but still.

the .hex text format will run just well as the binary format inside the NES game (bc they'll both end up in binary format).

Yes, whether you use .hex, .db or .incbin has no impact on the final binary.

Anyway, just consider breaking the giant hex strings into smaller units, such as parts representing rows of metatiles. It will be much more readable and easier to edit by hand. I don't think it's even good programming practice to have insanely huge lines of code in your source files.

[unregistered]

Thank you for your wisdom tokumaru! Good to think about; will tell my sister. I believe she doesn't want to install a hex editor... but, you do make lots of sense.

edit: Oh, remember these are screens made of RLE hex codes so separating it into lines of metatiles wouldn't be necessarily pretty. However, our metatiled screens using .db are separated into rows of metatiles like you suggested.

[Pokun]

I don't see why you'd ever need more than 80 characters per line. Any more and you can't guarantee that it isn't cropped when you view the file on another device or environment with a smaller screen, and it also is less readable. If one line represents something in your game (like a row of tiles) but is too long, just break it into two (or more) lines and separate it from other lines with an empty line.

Also a hexeditor doesn't require installation. There are free ones like XVI32 that just needs to be uncompressed. It's a very basic computer tool that I think about anyone working with slightly technical stuff with computers needs, just like a text editor.

[unregistered]

135 characters per .hex line is really ok for me. That's a good point about 80 characters should be the max; though, I don't ever plan to work on this game using a smaller screen. After the game is complete: it seems good to me to convert these long lines into binary files. Thank you, Pokun, for the note that hex editors don't have to be installed! It may not make a difference, but I'll tell my sister.

[unregistered]

Does the PPU only display a screen after it has been in the viewable nametable for an entire frame? It must be frowned on to: clear 2006-and-2007's address latch, disable vblank, disable rendering, write screen to a nametable, clear vblank flag to avoid graphical errors (bit $2002), enable vblank, set variable to enable rendering, and then, inside vblank, enable rendering. "Frowned on" bc the game's screen is black until we run out of screens to display even though each screen is correctly written to nametable.

[lidnariq]

Does the PPU only display a screen after it has been in the viewable nametable for an entire frame?

In an emulator, probably. It can't/shouldn't display the future, because it won't know what's going to be there, and it oughtn't display the past, because the resultant tearing would be misleading.

the game's screen is black until we run out of screens to display even though each screen is correctly written to nametable.

Are you waiting for the screen you want displayed to be displayed after you finish uploading it?

[unregistered]

Are you waiting for the screen you want displayed to be displayed after you finish uploading it?

Actually, no. Right now, the game loads a screen correctly, then sets $2001 inside vblank, then repeats that loop starting with loading the next screen correctly while in the next frame... until all the screens have been cycled through.

"the game loads a screen correctly" is valid to me bc I can see the screen correct in Mesen's Nametable viewer.

How long should I have the game wait before the screen is viewable in most emulators? Maybe I should figure that out myself... at least with Mesen. Thank you lidnariq!


edit: you already answered my question in the first, unquoted, part of your reply; thanks!