mirror of
https://github.com/transistorfet/moa.git
synced 2024-11-22 10:32:59 +00:00
18e54f4a44
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
103 lines
6.3 KiB
Plaintext
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?
|
|
|