. simplify the interface FrameBase to make it easier to implement it for different cases (remove HDC and make parameters more explicit)
. remove functions which are only called on a Win32Frame (in which case a cast is guaranteed to succeed)
. otherwise there is the risk that every FrameBase implementation wants to add its own variants.
. FrameBase::FrameRefreshStatus() simplify implementation: pass all flags explicitly
* Video / FrameBase: move arch specific code to FrameBase.
* Video::Initialize & SetFrameBuffer.
Ensure initialization and SetBuffer can only happen in the right order.
* Video: move virtual functions to FrameBase.
With these changes all the virtual functions are in FrameBase and Video gets closer to be (only) the Apple ][ Video device.
* Move a few more functions from Video to FrameBase (snapshot related)
Now, the inclusion is one way with Video *not* including FrameBase.
* FrameBase::VideoRefreshScreen move Video related code to Video.
And only leave management to FrameBase.
. class hierarchy: WinVideo IS_A Video (ie. WinVideo is a subclass of Video)
. GetVideo() singleton instance of WinVideo in AppleWin.cpp, exposed via Interface.h
This is not complete as header files from Windows/.. are still included in:
Keyboard.cpp
SerialComms.cpp
Joystick.cpp
But probably these are arch specific and will have to be completely reimplemented elsewhere.
. Split AppleWin -> Core with the functionality really needed by the emulator.
. Split AppleWin -> Utilities for generic code not called by other emulator components.
. Split AppleWin -> CmdLine for the command line option parsing.
Split MouseInterface to isolate DirectInput code.
Avoid overflow in platforms where RAND_MAX is a big integer constant.
Fix include files for gcc (where enums cannot be forward declared).
Whenever harddisks/disks are inserted (or removed) and *if path has changed* then:
. Then the internal save-state's path & filename will be updated to reflect the new defaults.
. LoadConfiguration(): Read the save-state pathname from Registry before harddisks/disks.
Also:
. CiderPress: only save pathname on OK.
. Refactored CPropertySheetHelper::BrowseToFile().
. Extended support for -d1,-d2,-h1, etc such that if the param is "", then it will eject/unplug the disk/harddisk.
. The auto-switch is done on each reset, or on inserting a disk at the start-up screen (MODE_LOGO).
. The Window's title include '(S6-13)' if DiskII card has 13-sector f/w.
. The debugger's 'disk info' cmd will show FW13 or FW16 depending on f/w.
Also:
- Allow creation of a blank (WOZ2) image
- multi-zip support extended to scan for the first valid image (useful for most woz-a-day zips which have at least 2 entries and were previously failing)
Support 2nd Disk][ in slot-5, via command line:
- -s5 diskii
- -s5d1 \<imagefile\>
- -s5d2 \<imagefile\>
NB. there's currently no Configuration UI support, except the Drive icons' tooltips show what's in slot-5 & slot-6 (for drive-n). So there's no way to eject the disks or insert new disks. The use-case I'm supporting it Wasteland which just has the 4 disks in the 4 drives.
Improved card management:
- Added `class Card` (in Card.h) which all other cards (that exist as classes) derive from (eg. LC,SSC,Mouse,Disk2).
- Added `class CardManager` (in CardManager.cpp\h) which now manages the 8 slots (and aux slot).
- Added `class Disk2CardManager` (in Disk2CardManager.cpp\h) which provides methods for operations that act on all Disk2 instances at the same time.
- Currently limited to just 1x SSC and 1x Mouse card (why would you need more?). This simplifies things, meaning there's no need to have dedicated SSCManager / MouseCardManager objects.
- Currently the 2nd Disk2 card can only be put into slot-5. This limitation is just due to the complexity of the Configuration UI. Having a more general drop-down per slot UI would remove this limitation.
. set m_headWindow = 0, after >50 bitcell gap
. bias fake bits to be ~30% chance of a 1 bit
Disk logging:
. added timestamps to I/O accesses
. DumpTrackWOZ() now outputs sync bits between nibbles
This change does two things:
1. Updates the registry APIs to reduce the likelihood of uninitialized
variables.
The code wasn't always checking the return value of registry load operations.
In some cases, this led to uninitialized memory being used, and crashes could
result. For example, LoadConfiguration in Applewin.cpp was using an
uninitialized value for the computer type if no registry variable for the
"Apple 2 type" was set.
New registry reading methods and macros have also been introduced, allowing
default value fallbacks for the cases where a registry variable is not found.
This makes registry access simpler and safer when a default value is known in
advance.
The registry code's style has also been updated to conform with the rest of
the code base (tabs instead of spaces, naming conventions, etc.)
2. Introduces string safety improvements.
A number of code paths have been modified to use safe-string functions instead
of their unsafe counterparts (e.g., strcpy, sprintf). In the process, some
strings were converted from "char" to "TCHAR". This was done mostly for
consistency with the rest of the code-base.
