TylerBarnes

I do have an account over there. I should frequent over there more often. I mostly lurk and read; Not many posts by me. Yes, in theory, except it is not possible to add anything to the NMI routine in ROM. The code execution currently starts at $0500 So execution runs through from $0500-$07FF, But I could move the sprites from $0300 up to $0200, then move execution to start at $0300. Then one would have from $0300-$07FF free for machine code. The idea I had for it is not that big in scope though.

Part 4 - Refactoring, and adding in another exception to compress repeating patterns instead of leaving them as uncompressed strings.

Part 3 - Adding in extra decoding directives for reading uncompressed data

Part 2 - Turning it into a valid NROM format, debugging, and testing the decoder.

So I'm working on learning more about the NES and at the same time like talking about what I'm working on. In this case it's compression for a single screen. Made this as a sort of 'get my thoughts in order' video to help myself learn. As well as, I hope someone else at the same sort of level of learning as I am could get some help from it. Furthermore, I am also hoping that by talking about what I am doing, I could get corrected by more experienced coders if I'm doing stuff poorly. I plan on making more regarding decoding uncompressed strings and special cases.

I collect grudges. People wrong me and I hold on to it forever.

I could not resist when I heard ‘new X-Box’

Made this image quite a while ago. Focus stacked from about 50+ different exposures at different points of focus and stitched together to get everything sharp.

Congrats on the project!

So, this is something I'm trying to develop further into more of a game sort of thing, but I got the mechanic working and think it is fun enough to share. Machine code editing done natively on the NES. ^_^ (The indexing bug was figured out. I was decrementing and using BNE to loop, so naturally when the index hit #$00, it escaped the loop and didn't write $0500 index 0.)

You are too kind. Thank you, sir! Collection looks great btw ^^ Also, I have never seen that red bordered Blades of steel before. Had no idea that was even a thing.

If you collect 15 stars in Mario 64, catch MIPS, but leave the star, and then travel out to the courtyard and circle the water fountain counterclockwise 4 times in a row at full running speed, you can unlock Luigi.

Thank you that makes a lot of sense. Instead of having an array length (Which can possibly be larger than $FF, so extra logic would have to be written), it is a better idea to just have an ending marker and detect it's value to end the stream. And a starting marker to tell if it is a compressed stream or uncompressed. However, the syntax you are using is confusing to me; This took me a few moments to realize what you meant. In ASM6 using "decompressFlag = $FF" would designate location $00FF in RAM as a variable, and then leave the value #$00 unless initialized in setup or in a routine before hand. It is not for value assignment. If the idea is to declare a constant for the decompression routine to detect, you would have to use decimal numbers like decompressFlag = 255 ; Assigned the label with value $FF or use EQU to equate the label to a string decompressFlag EQU $FF ; ASM6 assembler replaces label with $FF However if the idea is to detect $FF as a flag, I do not feel declaring this a variable or constant is too necessary. I would just implement that $FF detection this way with a raw coded value; Set it and forget it. LDY #$00 ; Set index into Level Data DetectCompress: LDA LevelData, y ; Load first item in array CMP $FF ; Compare with value $FF BEQ Decompress ; If equal decompress Uncompressed: ; Otherwise load uncompressed [Load data uncompressed] RTS Decompress: [Do decompression] RTS LevelData: .db $FF,$11,$05,$07,$1F,$FE --------------------------------------------------------- This is actually might not be true, at least the way I'm picturing it. So the routine has two main sections after detecting the compressed/uncompressed value, One is fetching the segment length, the other is fetching the tile number. You only need to detect flags for ending the decompression routine while it is attempting to fetch a segment length. Once a length is actually loaded in, it then just blindly loads the tile value and writes that tile N number of times (based on the segment length). This holds true because there is no reason to load a segment length without any tiles to follow. So the end will always be fetched as if it was a segment length and never a tile value. So tiles $FF and $FE in CHR rom are perfectly fair game. It is just that those segment lengths would not be allowed. So if I take my original simplistic RLE example that could look like: Fetch: LDA (data), y ; Fetch segmentLength CMP #$FE ; Detect if end of Array BEQ EndDecompression ; Exit if true TAX ; Set as decrimentor INY ; Incriment Index LDA (data), y ; Fetch tile . . . . EndDecompression: RTS All these different factors makes me realize there would not be a one size fits all, and writing/modifying something tailor made is the way to go for this stuff.

Yup, this is indeed true for all battery powered devices. I once had a $400 photography flash get bukakked with battery acid from AA cells left in it for too long.

I never even saw a Master System in person growing up. I have one now and I am impressed with it as a whole. It alone is a hidden gem to me.

That debugger looks slick.

This I did not know. Thanks for the info.

Yup. I use this as it is integrated into the sellers module for merchant accounts. Each transaction of payment received has a "Print Label" button that makes things very easy.

I see, that definitely makes a lot of sense. When the space saving starts to impede on performance of a commonly checked bit, it starts become more of a con than a pro.

Very true; Indexing makes many things soooo much easier. My favorite thing to do for code re usability is add pointer support to functions that could be used for multiple tables. Lets say you have different palettes for different levels. ;---------------Variables----------- data = $C2 dataH = $C3 ;----------------Setup-------------- LoadLevel1Palettes: LDA #<Lev1Pal ; Load Level1 Palette's LDX #>Lev1Pal ; location into a pointer. STA data STX dataH JSR LoadPalette ; Run the load palette routine Forever: JMP Forever ;---------------Subroutines---------- LoadPalette: LDA #$3F ; Load PPU location to write LDY #$00 ; $3F00 is for Palettes STA $2006 STY $2006 PalLoop: LDA (data), y ; Index into loacation in Pointer (data) STA $2007 ; Write Byte INY ; Incriment Index CPY #$20 ; Takes 32 writes to complete BNE PalLoop ; Keeps looping till done RTS ;----------------Data---------------- Lev1Pal: .incbin "Level1.pal"

I have been meaning to download that tool. I'm still using a very basic flash based tile editor. Doesn't even have an undo function, lol. Only really chose it cause it would run on mac.

Never thought to use BIT. Being able to BIT through multiple states in a row on the same button state without additional LDAs would be helpful. You are right. Brain fart. Of course MaskLUT, y would be to index. I somehow understood deafcode's example and then proceeded to act like I didn't know how to index a table. lol. Thank you for the example. That definitely shows the advantage of a table vs using the bits for different states.

Ah, I see now. I was over thinking in that it was something more specific than that. I personally like the readability of declaring constants with labels. Seeing too many instances of MaskLUT+1, MaskLUT+3, etc in the code would throw me off in the context I am thinking of. Other contexts I'm sure would be great with the above.

The main inquiry was are people bothering with the extra logic involved when using every bit for flags and masking all the time, or if it is more rare to want/need to use all bits of a byte for flags. Indeed. I forgot to include that sort of section in my example. Jump: LDA PlayerState ; Load Player Flags AND #IsJumping ; Examine Only Jump Flag BNE Skip ; Skip if flag is set LDA PlayerState ; Load Player Flags ORA #IsJumping ; Set Jump Flag STA PlayerState ; Save Flags [Do jump stuff] Skip: RTS Do you have a small digestible example of this lookup table setup? I don't think I can picture what you mean.

Not sure if it has already been discussed elsewhere, but was wondering.... Simple projects on the NES are going certainly going to have plenty of slots in RAM to use for various flags, values, and buffer space. However, I could see certain cases where a project gets very large or large ram buffers are used. Anyone ever use a single byte in RAM for up to status 8 flags? I was thinking about this in that having tons of bytes in RAM that only ever toggle from 0 to 1 all the time is wasteful. Also I could see it used as a sort of organisation system if one byte did many related flags. Too convoluted or no? Setting flags in this way could look like this (in my head at least): PlayerState = $A0 IsStunned = 1 IsJumping = 2 HasPowerUp = 4 IsDead = 8 GameState = $A1 Paused = 1 GameOver = 2 Credits = 4 Jump: LDA PlayerState ORA #IsJumping STA PlayerState [Do jump stuff] RTS Physics: [Do gravity stuff] [Do floor detection] BEQ Landed RTS Landed: LDA PlayerState EOR #$FF ORA #IsJumping EOR #$FF STA PlayerState RTS