AppleWin/docs/ToDo.txt

47 lines
2.0 KiB
Plaintext
Raw Normal View History

2006-03-11 11:03:14 +00:00
To-do list (Tom)
================
2006-02-24 16:51:00 +00:00
This is a (non-exhaustive) list of stuff that I personally would like to get done:
. Consolidate the Spkr_SubmitWaveBuffer() & Spkr_SubmitWaveBuffer_FullSpeed() funcs.
This will make the code cleaner & simpler.
. Software mix Speaker & Mockingboard waves before submitting to sound-buffer.
This will:
a) fix the problem with speaker sound be rough when MB is active.
b) probably fix the problem with other processes having problems playing sound at the
same time as AppleWin. (Although I've not experienced this)
c) hopefully simplify things :)
. Run emulation (or message-pump?) in a seperate thread.
So that the sound is continuous when dragging the window or starting other applications, etc.
. Add proper Votrax support (using PinMAME samples & code).
. Fix SSI263 so that phonemes are overlapped (like Votrax).
. Support for zipped disk images (r/w) & harddisk images (read-only, but maybe write too?)
. Save-state supporting Phasor, harddisk & Ramworks III
2006-03-11 11:03:14 +00:00
. [NICK] Floating-bus support (using Nick Westgate's code)
For Drol, Lock'n'Chase, TetrisII, etc
. Support for switching display modes mid-frame
2006-03-11 11:03:14 +00:00
To support Bob Bishop's intros
---
Plans for (1st pass) cleaning up are:
. Ditch the x86 code to access the PC speaker + ditch PC speaker support
. Ditch DLL support completely & re-factor any code that jumps through hoops to be compatible with DLLs:
namely CpuCalcCycles() & CPU_FASTPAGING, etc.
. The arrays ioread[] & iowrite[] in Memory.cpp should be switched from units of 1 byte to 16 bytes.
This will yield 256 entries spanning [$C000<30>$CFFF] <20> currently it<69>s only [$C000<30>$C0FF]. This will mean that:
a) cards with I/O mapped above $C0FF (eg Mockingboard, Mouse?) don<6F>t have to be kludged as in the READ/WRITE macros in CPU.cpp
b) $CFFF (ROMs out) can be emulated
. Talking of CPU.cpp & those macros: I<>d prefer to replace them with inline funcs. Maintenance of these
macros is a bitch & they can<61>t be single-stepped. Inline funs should yield the same code (in release build)
as the macros.