Of course, it is shorter and faster to optionally increment upper bytes instead of `lda/adc#0/sta` chaining on each:

; Adding an 8-bit unsigned delta to a 32-bit num

lda num+0
adc delta
sta num+0

bcc done ; if the addition carried, bump the next number
inc num+1

bne done ; if the increment went ...

I wonder whether "increment if zero" is a reasonable way to avoid that particular issue - however randomness is one of those cases where I know just enough to know that I don't know, and that it's easy to go in with good intentions but come out with really bad results!

I tackled this 0->0 cycle ...

You could store return values directly into the caller's CPU stack frame, past the return address. The top value/values of the caller can be considered temporary, depending on what it calls.

It seems your method is a line accurate counter but my code must have been a cycle exact. Anyway why to use timers when we have raster interrupts?

No, my method is cycle-accurate. If it for instance was off by 1 cycle, then over the course of ~65 frames it would drift to firing on a different ...

I don't have the code on me, but what I did when I did this is use a CIA timer. When the timer interrupt hit, it would read the current raster line. If the line was less than the previous read, it would increment the timer length by 1, and decrement if it ended up on a line further down. If it ...

o need to get super fancy with messing with your stack for this.

The sequence would look something like this:
1) Pop note off stack
2) Stack empty?
Yes -> Turn off sound, exit
No?
3) Is top of stack still pressed?
No -> Goto 1
Yes -> Set note, exit


Really don't see you getting too far down ...

If I'm understanding correctly, you could use a 76-bit state buffer (10 bytes, or 76 bytes if you have plenty of space) to remember the keys that were pressed during the prior keyscan, plus 1 byte to remember which note is currently playing (if any). If in the next keyscan, a key is pressed that was ...

No, the lines could contain any value 0-255, so a backwards scan isn't intended and the tags wouldn't be unambiguous in that direction. Minimizing space overhead means singly linked and it can only traverse forward, that's why there's a cache of prior lines to retrace forward from.

That sounds interesting! Is your editor publicly available?
I've not finished with the implementation, so there's nothing but notes and some partial algo implementations. But feel free to incorporate the ideas.

Which is the essence of my editor prviously mentioned - a list of addresses to each ...

Stefan, I've come up with an extremely similar design, and hadn't noticed this thread. I'm glad it's working out!

An interesting thing is that if you have this block allocation method (which is effectively like a filesystem, but with the ability to shove new sectors into the middle of the "file ...

I have been trying to puzzle together the details of how the SNES PPU works, and was considering how it managed to shuttle all the pixel data for the various sprites; seems like magic to me how it manages to pull in the color data of all the potential sprites, along with the background tile colors ...

Absolutely, but it would not render the sprite the way i want it: AND-mask 0 meaning whatever the sprite bit value is takes priority, since it clears the background bit, i.e:

lda (tileptr),y
and (spritemask),y
ora (sprite),y
sta (tileptr),y


Yes, it still would render exactly the way you ...

This was purely a trademark acquisition, across various existing national jurisdictions that had the mark maintained. Some expired, and other companies re-registered it (I think Italy is a sore spot there).

There have been licensing agreements with Cloanto regarding some of the software licensing ...

Johan, you're using 2 bits for 3 "colors", you could make it 4 "colors" with zero additional cost by using XOR instead of OR to compose your image after the AND mask:


AND XOR Effect
0 0 Off
0 1 On
1 0 Transparent
1 1 Inverted


With the normal inclusive OR, the fourth combination is just a ...

Many 2d home game console video chips of the late 8-bit CPU generation (TG16/PCE etc) and beyond did this sort of thing, with line buffers and painting tiles/sprites onto them, with one hardware renderer instead of duplicated parallel hardware blocks per sprite, wrangling for who should show in real ...