8x16 and whatever else unreg wants to know

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

unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by 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!! :mrgreen: :D

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. :)


********
edit: The -U and -u flags both contract REPTs; the -u flag was explained at the bottom of page 97:
unregistered wrote: Thu Jan 31, 2019 5:23 pmI 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. :D

...

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.
Last edited by unregistered on Tue Feb 16, 2021 11:54 pm, edited 2 times in total.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by 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
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by 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
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by tepples »

unregistered wrote: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
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

tepples wrote:
unregistered wrote: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. :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by 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
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

tokumaru wrote: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 wrote: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
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by 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."
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru »

unregistered wrote: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
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Thank you for your wisdom tokumaru! :D 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
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: 8x16 and whatever else unreg wants to know

Post by 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
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by 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! :D It may not make a difference, but I'll tell my sister.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by 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
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: 8x16 and whatever else unreg wants to know

Post by lidnariq »

unregistered wrote: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
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

lidnariq wrote: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! :D


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