mirror of
https://github.com/transistorfet/moa.git
synced 2024-11-18 14:05:57 +00:00
105 lines
5.8 KiB
Plaintext
105 lines
5.8 KiB
Plaintext
|
|
* 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, CHK, ILLEGAL, NBCD, NEGX, RTR, 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?
|
|
|