TODO.txt

; TODO items

* Save C64 memory range with optional 2 byte header



* APU: kAPU_IDataRegLoad4 is not being disassembled?!



* For the scaled sprites layers (normal and rotated) add some debug that will show how much time is used (or free) for each scanline up until it reaches the end of sprite list
	** Add an option to debug break the debugger if the time runs out?
	** Also for scaled sprites4 for the whole previous frame output the highest sprite number reached and the time used out of the whole frame, plus output the currently rendering sprite number.
	** Done: Also the Sprites4 extent state
		>> Done: ; TODO: Strange that the borders need to be reset when entering the game?!
	    > jsr Bus20To32Bit1_ShortReset , sets reset low then high
	        * This sets an extra 0 byte write to the 24bit interface
	        * >> Is this behaviour visible in simulation or hardware? Or is it an emulation bug?
	            >> Added this to reflect the schematic: if (bus32LatchAddress != 7 && bus32LatchAddress != 3) {
	** Also the bus32 address and adder state etc




* Pixel picking, when enabled, could display the 7x7/5x5 pixels under the mouse cursor in the off-screen border area as a zoomed in view.




* Write test summary html containing:
		75 Scenarios (75 passed)
		2345 Steps (2345 passed)
		2m31.238s
	And a link to the full report.
	



* Video_WaitVBlank could use a special case to avoid executing the CPU until the vblank happens when encountering this label
	pauseUntilNewVBlank
	But it's not working well...
	Is it because it's not keeping track of the pixels or cycles?
	Check the call path to calculatePixel()
	>> Because Video_WaitVBlank did a read before the main wait, to syn to the next real vsync :D
		Which almost always caused a double wait
	>> e.g. use:
		Given avoid CPU wait during VBlank for address "Video_WaitVBlank_startGuard"




* Add graphical display of C64 screen based on VIC contents
	https://www.c64-wiki.com/wiki/raster_time
	Is there a need to display the video hardware and C64 VIC at the same time?
		It would be nice...
	Add syntax to: C64ROMs.feature
	Existing syntax:
		Given a new video display
		Given limit video display to 60 fps
	It could use a lot of the functionality used by DisplayBombJack, perhaps just add different layer types? For C64 chars/bitmap and C64 sprites
		Also it would need to turn off the palette RAM tests
	Probably just char screen and bitmap display for now
	Update VIC raster H/V pos based on opcode cycle counts
	Emulate raster position read for C64 VIC
	handleDisplayEvents() to include the extra display
	debuggerUpdateRegs() to include the VIC display timings in optionalExtras. displayH/displayV could also use the C64 screen timing, if displayBombJack isn't enabled.
	InitWindow()
	RepaintWindow()
	When the visual display is enabled, will need better handling of "rasterToggle = !rasterToggle;"
	Added:
		Given a new C64 video display
		And show C64 video window
	>> First version of the C64 display works quite well



* Possible to include debug views of the full tile/char map virtual displays in other windows.
	Include a rectangle (guidelines actually) of the area that is on the real display from their scroll positions at the current time in the debugger.
	The scaled sprite view can include a larger unclipped render with a rectangle showing the real view screen, to help debug any clipping issues for example.
	> Two view rectangles, the maximum extent and the current extent with the border registers.	




* Profile: Possible to create a full call stack, by noting the previous caller "func1.func2.func2" etc, and storing the full name in the memory address as a map
	So that each address can have multiple names and cycle counts
	




* To help with cartridge code, in addition to: When I enable uninitialised memory read protection with immediate fail
	Add syntax to mark certain memory ranges as initialised. For ROM/CRT ROM etc
	@Demo6C




* BDD6502: Add text based "mem"/"m" command



* Break of execution for APU
	See wantAPUBreakOnWaitOrPC0 and wantAPUStep
		Check how to operate with receivedBreakAt and isReceivedBreakAt




* Break on memory access (watch)
	CPU and APU


* When the debugger reconnects to BDD6502 force all pending break/watches to be cleared



* Sprites2: Add a configurable threshold to reduce the list scan time used list (com.bdd6502.Sprites2.getDebug)

* Sprites2: Add a breakpoint on exhausted configurable used time for a scanline (com.bdd6502.Sprites2.getDebug)



* calculatePixel() is slow, says the profiler
	Turning off all the layer calculatePixel(), so they quickly return 0, does seem to massively speed up the rendering :D
	Maybe the abstract int calculatePixel() is just really slow?



* ; TODO: This bubble sort is quite slow, use a fast sort instead



* For w$** remove the wrapping d$0 as the data generator has the option now of setting forcing the bus to 0
	* TODO: And test data gen in VC



* Make target/debugchannel.pcmu8 optional



* APU: Cycle exact stateful emulation may be needed to precisely replicate all combinations, for example where ABBRB1/2 is incremented (or loaded) at the same time as reading a value from RAM and assigning it to an internal register



* Note in hardware RH=$180 then $181 but RV = 0 and RV = 1. The first RH pixel is reported as the previous scan index
	Technically the first RH pixel on the new scanline is $181, not $180
	This is going to be very important for the APU emulation




* Simulation of the test data from the chars + sprites test shows char screen/colour uploaded during the screen display have "random" data contention issues.
	This is because the V3.0 hardware prioritises the video address fetch setup over the memory write setup
	This behaviour is observed in the hardware with full user port interface.
	* Not needed for chars with V5.0 hardware. Removed Bus24Bit_WriteMakeSafeReset from demos.




* Emulate RAM contention when their relevant EBBS is set and their address line is set.
	Especially on the character bitplane RAMs and screen/palette data.
	This is to close the emulation gaps to the hardware
	Added for Chars: setAddressBus()




* Does audio frequency need a latch on the high byte to make it read a complete 16 bit value?
	Sometimes yes, if the music updates the frequency a lot, but during tests it isn't that noticeable if the update is done quickly
		In usual cases the update would be done quickly enough not to notice
		Also the latch would mean extra complexity in hardware, which is perhaps not needed



* Measure average instructions between label pairs and output on demand or on schedule



* Create data decompression only unit test



* Add _VBLANK to the proteus debug file write
	The $f8 displayV can then be waited for in the _VBLANK
	This would negate the writes during VBLANK optimisation though?
		See: // This check removes waits for display H/V positions during the VBLANK, the non-visible part of the frame


	
* Match the simulated hardware to the emulated video output, especially the right border, the emulation seems to be a little too far "in"
	Also match the mode7 tiles with the hardware, the left/top of the screen might need syncing slightly with _vynsc/_hsync timing and the dx/dy adds
		Probably 8 pixels



* Real hardware found a bug where mode7 registers way beyond a011 were being written to (see target/DebugData.txt and find d$a02001)
	This needs to throw an exception in this emulation, for all the register sets in all layers



* Detect and fail if Bus24Bit_WaitVSync (the read from the register) is used without Video_EnableDisplay (the register write)
	Or, allow the display enable/disable to just act on the output pixel stage and allow the counters to operate
	
	

* Image comparison needs to output a highlight of where the pixel differences are


* The contention time might need to be a bit longer considering the ageing speed with the 6502 speed
	Make the ageing and video clocks per instruction configurable, to allow a fast or slow 6502 to be emulated



* Have a separate section that animates for a few frames for "// Contention timing test"



* Read config for video display from command line



* I need some syntax that measures the percentage of code executed and memory accessed so I can have code coverage metrics during tests
  and fails if a test doesn't exercise what I think are important code paths




	
	
	
* Add support for simulating IRQs and NMIs called via customised entry points and timings.
	For example FFFE or 0314 entry point can be specified directly



* Branch instructions followed by a $xx value must take into account the current PC and calculate the correct destination address before enriching the disassembly output



* Branch instructions must take into account the current ST and indicate of they will be taken, perhaps by highlighting the destination address



* Try to convert the PC to the nearest function label+XXX value by reading the debugger PDB output



* scenario.write uses a lot of memory for large text dumps. Override this to shorten or summarise a large textual dump and link to an external file for the full version instead.




* Create a test scenario that contains syntax to generate permutations code
	This is to allow permutations of data to be tested and find optimal code sequences within short blocks of code
	Syntax can run features/scenarios/tags to validate the permutations and note the cycle timings or code size, or any other metric, of working code blocks
	Add syntax to enable algorithmic bit twiddling of input data, by emitting extra code.
	Depending on the test scenarios being executed, they can test only the code fragment and score it with cycle timings for example.
	
	
	
* Need syntax to try up to N times to match a line in a file...
	For data debug output in transition...




* Add debugger option to warn/break if updating sprite registers as the sprite is being rendered. Would help catch APU updates when the wrong sprite timing is being used.




* Command and button to display MegaWang sprite hardware registers, and easy to read (dec/hex) sprite debug output
	Flag which sprites are being drawn on the current visible scanline for the Y pos
	Also indicate the sprite being rendered, for the scanline cycle schedule.
	e.g.
		On scanline 20 and hpos 20... note the sprite Y coordinates are inverted
		Sprite 0 9800 : pos 23 , >>224<< full height frame 3 palette 2
		>> Sprite 1 9800 : pos 67 , 124 frame 3 palette 2
	Show as many sprites as the clock rate allows, indicate the partial number of pixels on the last sprite.