moa/todo.txt
transistor 18e54f4a44 Added line-based hscroll and fixed an hscroll bug
The hscroll table was multiplying by 2 (because scroll a and b values
are next to each other) but it should have multiplied by 4 because
each value is also 2 bytes and the array is of u8.

I added hscroll by-line support by using a different function for the
line scroll vs the cell or whole screen scrolling.  There are still
a bunch of glitches in scroll b's scroll values that I need to fix
2021-12-20 20:11:43 -08:00

103 lines
6.3 KiB
Plaintext

* there is possibly a cpu bug in causing the acceleration in sonic 2 to be very slow. Speeding up the CPU makes it playably fast, but I think it's still
incorrect, in that the top speed is faster than it should be, but the acceleration is correct...
* for the speed problem, I've actually noticed the level vint is only called every ~33_200_000 ns which is twice as long as it should be, so maybe there's
a vint problem, maybe even a toggle trigger that should be a one-shot
* there is definitely something related to interrupts; 2 interrupts occur in between each call to Vint_Level (ie. Vint_Level only runs every 2 frames (33.2ms) instead
of every frame (16.6 ms), which perfectly explains the slowdown without it being related to an instruction implementation error... but why is this happening?
Maybe it's because the clock advances too much and first interrupt doesn't complete, or maybe there's a problem with interrupts and masking...
It does appear to do I/O with the VDP between te interrupts so it doesn't seem to be just waiting around
* for the line based hscroll, you need to add that extra cell cycle...
* there is still some kind of hscroll glitch, and it seems to entirely be caused by the horizontal scroll offset value. I could be calculating or adding/moding
it incorrectly somewhere somehow, or the data in the hscroll table could be incorrect due to the cpu impl
* go through the testcases and make sure they are decoded correctly
* should you rename devices.rs traits.rs?
* add command line arguments to speed up or slow down either the frame rate limiter or the simulated time per frame
* 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+
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
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
* 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:
* the 68000/Z80 bank switching is probably buggy, and there's that other banking stuff in the 0xC00000 range, which isn't implemented at all
* add support for the H/V counters at 0xC00008
* need to implement the 1.5ms reset in the genesis controllers
* fix ym7101 to better handle V/H interrupts (right now it sets and then the next step will clear, but it'd be nice if it could 'edge trigger')
* make the ym7101 set/reset the v_int occurred flag based on the interrupt controller
* refactor to allow per-line horizontal scrolling, which might need a pattern iterator than only does a line at a time
* refactor ym7101 into multiple files perhaps. You can separate the DMA stuff, the address/interfacing parts, and the graphics state
* fix sprite/cell priorities so that they're drawn correctly
* add support for the sprite overflow flag (low priority)
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?