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