moa/todo.txt

* test the Z80 more, add tests
* double check the functioning of the banked areas and register settings for Z80 coprocessor
* address repeater on ym2612 doesn't seem to work the same, when it's on the 68000 device.  The Z80 device doesn't have an affect, but maybe it's not being used

* make the keys easier to config...

* add log crate to core
* can you make the debugger more accessible, so a web interface could access the data and display it, in light of the fact that println isn't available in wasm

Web Assembly:
* the frame rate is pretty bad.  It's definitely faster with a smaller window
* can you limit the size of the window that pixels generates?
* can you automatically adjust the speed based on the calculated framerate (if you moved that to Rust)
* can you limit the frame rate in pixels so that you if it were to run too fast, it would limit it to 60Hz
* the system run is taking 40 to 50ms per frame in web assembly.  Can you cut that by 4 times?

* add sound to web assembly
* add run/stop and ability to change speed through the web interface
* can you make the web interface nicer with like... a picture of a genesis or something


* fix audio, and/or make it possible to disable audio processing/simulation for one or both sound chips (might be nice to have sn76489 but not ym2612)
* should you have a separate attenuation value for each input in the mixer so that you can make one chip quieter (the sn76489 is pretty loud, and I added a fixed offset to the attenuation for now)


Harte Tests:
    * for every failing test in MOVEfromSR, it's caused by an exception where at 0x7F3 it should be 0xF5, it's actually 0xE5, which is the READ/WRITE flag not set correctly (1 = READ)


* you could refactor the instruction loop into a series of functions, and test if there's a performance difference with and without #[inline(always)]
* use the log crate instead of your own
* move parser into its own


* make it possible to compile without audio support (minifb frontend requires it atm)

* I need some better function for dealing with memory, like a function that copies data with a loop, or allows offset reading of
  a fixed piece of data..., the trick is what function are the most common.  You can use generics

* there is an issue with Mortal Kombat 2 where it will crash randomly at the start of a fight.  The code is actually swapping
  stacks a bunch of times, and at some point, the stack is corrupted or something and it `rts`s to the wrong address...

* go through the testcases.rs file and make sure they were decoded correctly

* should you rename devices.rs traits.rs?


Audio:
    * for the mixer, it might be easier to have a buffer for each source, but then you'd need to have a list of all sources, even though
      each source has a copy of the mixer as well... Likely there'd be a sub object in Source which is the buffer and anything else needed
      by the mixer

    * I'm leaning towards having an object that data is written to by the device.  The device can decide how often to update.  The issue is
      knowing what data to exclude or insert when mixing the incoming buffers
    * Removing at a sample-level granularity would compress or lengthen the waveforms, so it would be better to mix/drop a whole chunk at
      once (either predetermined by the audio system or determined by each device by the amount of samples it writes at once).  The chunk
      size could either be specified by the device in microseconds or something, or can be inferred by the sample_rate and the size of the
      chunk.

    * how do you know how big an audio frame should be?  How do other emulators do audio without stretching or compressing the waveforms, and
      can/should I do mixing as well, given that I have 2 sources, and at least for those two, they should be connected to the same output
    * you could make the sound device be an object that is passed back to the simulation section like SimplePty.  You need to either register
      a callback with the frontend sound system that is called when it needs data, or you write to a shared buffer which is passed back to the
      frontend when it needs it, or it has a copy it can use directly


System/Traits:

    * can you make the connections between things (like memory adapters), be expressed in a way that's more similar to the electrical design?
      like specifying that address pins 10-7 should be ignored/unconnected, pin 11 will connect to "chip select", etc
    * should you add a unique ID to devices, such that they can be indexed, and their step functions can reset the next_run count and run them immediately

    * should you simulate bus arbitration?
    * interrupts could be done in a better way
    * need a better way of handling disparate reads/writes to I/O spaces, rather than having multiple devices or having a massive chunk of address space allocated, continuously
    * should you modify Addressable to also take the absolute address as input?  I'm thinking of how the same device could be mapped to multiple addresses in memory instead
      of taking up a whole range of addresses
    * you could modify read()/write() in Addressable to return the number of bytes read or written for dynamic bus sizing used by the MC68020+


Debugger:

    * i need a way to debug only the cpu and not the coprocessor, but that's tricky without a way to id or compare Transmutables
    * add a way to delete a watcher
    * can you improve how the watcher implementation in the Bus works, instead of setting a flag and then checking it every cycle, pass in the System to Addressable??
    * can you use the breakpoint address parser in other commands?
    * get stack tracing working again, but can you do it with just data?
    * how can you improve the debugger?
    * the command line definitely needs to be fixed so it prints the prompt correctly
    * debugger could maybe even allows arrows left/right for editing, and up/down for history


Genesis/Mega Drive:

    * implement sn76489 and ym2612 for audio
    * in some games the controller doesn't seem to work at all (Earthworm Jim, and Mortal Kombat)
    * refactor to print line by line, so that colour palette changes have an effect
    * there's a bug when Sonic 2 goes to the demo screen, it's all corrupted (could it be a dma copy error)
    * colours are still broken in Sonic1
    * sonic3 needs some kind of nvram to run

    * the 68000/Z80 bank switching is probably buggy
    * the H/V counters are not accurate because it seems to count at different speeds in the blanking period (time vs return value numbers don't divide properly)
    * make the ym7101 set/reset the v_int occurred flag based on the interrupt controller
    * add support for the sprite overflow flag (low priority)
    * still possibly a bug with the shadow/highlight colours


Macintosh:

    * issues when booting the rom, attempt to write to rom during the driver init/open phase
    * for the address bus/repeating thing in the mac with the rom and ram, can you make it work for both the 128 and 512


68000:

    * check all instructions in the docs

    * unimplemented:  BFFFO, BFINS, NBCD, RTD
    * >=MC68020 undecoded & unimplemented: BKPT, CALLM, CAS, CAS2, CHK2, CMP2, RTM, PACK, TRAPcc, UNPK

    * add support for MMU
    * add support for FPU
    * Coprocessor instructions: cpBcc, cpDBcc, cpGEN, cpScc, cpTRAPcc

    * add more m68k tests and try to test against a working impl (m68k-test-suite project)


Z80:
    * add instruction timings to Z80
    * unimplemented: CPD, CPDR, CPI, CPIR, DAA, IND, INDR, INI, INIR, INic, INx, OTDR, OTIR, OUTD, OUTI, OUTic, OUTx, RETI, RETN, RLD, RRD


* work on mac128/512
* work on sega genesis
* can you eventually make the system connections all configurable via a config file?