wooky / nes-qr-demo Goto Github PK

Need to find a web-based NES emulator that supports the Family BASIC Keyboard.

qrcodegen stores modules (pixels) in memory in the order 76543210. However, the PPU requires them to be in the order 01234567, so bit reversal is required before copying the pixels to the PPU. If qrcodegen can work with bits reversed, some efficiencies can be gotten.

Current Situation

Only background tiles are used to render the QR code. 256 tiles, arranged in a 16x16 grid, produce an image that can have a maximum size of 128x128 pixels, allowing a Version 27 QR code to be displayed.

(Side note, it's somewhat buggy, because tile $00 is reserved as the white tile, so the bottom row(s?) of the generated QR code can spill over into the $1xxx PPU RAM space. That's fine, though, since QR codes are resilient enough against this bug.)

Desired Situation

We can also use sprite tiles to increase the number of pixels that can be rendered. We can use 64 tiles of size 8x16. With an effective size of 384 tiles, an image of 19x19 tiles, or 152x152 pixels, can be created. This bumps the maximum version to 33, allowing up to 2,068 characters to be rendered.

Tasks

Memory usage will increase significantly. To support Version 33, two buffers of 4769 bytes, for a total of 9538 bytes, will be required. This is larger than the maximum PRG RAM window of 8192 bytes. Therefore, #2 will need to be resolved first.

QR code rendering will need to be modified, including rearranging the tile pattern. One way is to have the first 16 rows to be 11 background and 8 sprite tiles wide, and the next 3 rows be 19 background tiles wide. This will use a total of 256 background tiles, 128 sprite tiles, and the maximum allowable 64 OAM objects with 8 sprites per scanline.

This is an extension to #3 and is meant to supersede it.

Version 40, the maximum QR version, has a size of 177x177 pixels, or 23x23 tiles, and supports up to 2953 characters. At a width of 23 tiles, only 11 rows can be displayed due to CHR RAM limitations. By swapping the CHR RAM banks at precise scanlines, the maximum QR code version can be achieved.

After every 11 rows, the CHR RAM bank can be swapped, and the nametable can be reused. As is, three 4KB CHR RAM banks are required, and two bank swaps will be needed mid-frame: one after 11 rows, and one after 22 rows. IF the MMC1 mapper is used, which has no scanline counting, this will be difficult.

Alternatively, if even the rightmost 2 columns are replaced with sprites, 12 rows can be displayed using a single nametable, so only a single bank swap will be needed. This bank swap can be done with a sprite 0 hit, eliminating a lot of complexity. This solution also uses only three 4KB CHR RAM banks: two for background tiles, and one for sprite tiles.

qrcodegen uses two large memory buffers: input text + scratch memory, and generated QR code. During code generation, the input text gets overwritten, and does not appear to be recoverable. For version 27, each buffer is 4001 bytes, for a total of 8002 bytes. PRG RAM supports $2000 bytes, or 8192 bytes, at any time, so there's no way to store a copy of the original text without modifications.

Some ideas as to how to overcome this:

• Store the output QR image directly to the PPU RAM
  • Immediately cuts down on PRG RAM requirement by half
  • No need to copy from PRG RAM to PPU RAM when rendering
  • Potentially slower runtime
  • Requires code change in qrcodegen as reading from and writing to the QR code buffer is different
• Add more PRG RAM
  • Simpler to implement
  • Requires bank switching