clones quickstart

clones.md

Installing Clones

May need to brew install libsdl2-dev

brew install sbcl # or apt-get if you nasty playa
curl -O https://beta.quicklisp.org/quicklisp.lisp > quicklisp.lisp
sbcl --load quicklisp.lisp # and follow the prompts
git clone [email protected]:kingcons/clones.git ~/quicklisp/local-projects/clones.git

Running Clones

Start rlwrap sbcl and ...

(ql:quickload :clones)
(in-package :clones)
(change-game "roms/commercial/dk.nes") ;; this path is relative to the clones installation folder/git checkout
(step-frames 4)

Dumping Nametables

Make sure to do this on the mezzanine branch...

(ql:quickload :cl-json)
(defvar *nt* (clones.ppu::ppu-nametable (memory-ppu (cpu-memory *nes*))))
(cl-json:encode-json *nt*)

Dumping Images

Make sure to brew install libpng first and use my fork of cl-png...

git clone [email protected]:kingcons/cl-png.git ~/quicklisp/local-projects/cl-png

Then ...

(ql:quickload '(:zpng :clones))
(in-package :clones)
(change-game "roms/commercial/smb.nes")
(step-frames 30)
(defvar *image* (make-instance 'zpng:pixel-streamed-png :color-type :truecolor :width 256 :height 240))
(with-open-file (out "test.png" :element-type '(unsigned-byte 8) :direction :output
                 :if-does-not-exist :create :if-exists :supersede)
  (zpng:start-png *image* out)
  (dotimes (i (* 256 240))
    (let ((pixel (list (aref clones.ppu:*framebuffer* (+ (* i 3) 0))
                       (aref clones.ppu:*framebuffer* (+ (* i 3) 1))
                       (aref clones.ppu:*framebuffer* (+ (* i 3) 2)))))
      (zpng:write-pixel pixel *image*)))
  (zpng:finish-png *image*))

Did some performance investigation. On the epidernes side, main performance improvement is likely not updating Disassembly/NES component unless the render loop is s topped. If things are still choppy after that, we should manually run an effect that updates the canvas rather than going through state management. Frames are heavy!

On the rawbones side, dropping sprite handling killed over 50% of our runtime! We can definitely optimize better than we're currently doing. find_sprite seems to be the main culprit. We can probably trade a one time Array allocation in the context for 256 ints, each one representing the pixel of a sprite on the scanline. Then, every scanline we could clear the array, loop over the sprite candidates, and render them into it all in one go. We'd just have to modify pixel priority to pull pixels from the context.

More importantly, we've got some palette issues that still need to be fixed (visible in DK, ex: 68,43 should have same color as 66,51 and 90,50 should match 100,50; visible in SMB, ex: 35,200 should be same color as 30,200) and there's still some incorrect scrolling behavior that could be caused by periodic resets to CoarseX(0)/CoarseY(0). Could be something else but merits further investigation.

Fixed a few bugs this morning. Mostly seems like stuff we would've caught sooner if we had good tests. We were picking the wrong high bits for background tiles, the switch statement was just mismatching cases. Then, we weren't switching on the right values for determining quadrant. We were testing whether coarse_x and coarse_y themselves were odd when we should've checked whether coarse_x / 2 and coarse_y / 2 were even or odd, since each "area" in a quad is a 2x2 tile square.

i.e.

|    | 00 | 01 | 02 | 03 | < coarse_x
| 00 | tl | tl | tr | tr |
| 01 | tl | tl | tr | tr |
| 02 | bl | bl | br | br |
| 03 | bl | bl | br | br |
  ^ coarse_y

The bulk of our remaining scrolling problems are coming from resetting the scroll position to zero. Like a lot.

I added some logging to our STA instructions when they were to PPUSCROLL and found that writes to $2005 do seem responsible. Based on the lovely disassembly here (https://gist.github.com/1wErt3r/4048722) I found that the two locations doing the writes are InitScroll at 0x8ee6 and SkipSprite0 at 0x815c. I confirmed those addresses using the logged pc from our STA instruction and Clones disassembler. As far as I can tell, InitScroll always writes zeros and SkipSprite0 is only writing zeroes for the second vertical byte of the scroll which is fine. Now, to figure out why InitScroll is being called so much. At the moment I'm a bit suspicious of our Hblank and Vblank timings...

Instrumented ANESE today and found that it is subject to the same InitScroll writes as we are so it probably isn't a timing issue. I'm becoming more suspicious of how we approach Nametable Mirroring in general. I wouldn't be mad at double checking both mirroring as detected in ROM parsing and the VRAM reading code to make sure what it's doing seems reasonable. Provided it does, we're looking at seeing if there's something wrong with how we read the ScrollInfo to compute the NT bytes to read for the background and how that stacks up to the "shift registers" approach on PPU rendering.