1.26.0.1
. NTSC video modes (TV Color, TV B&W, Monitor Color, Monitor B&W)
. Full Screen using native resolution (not 640x480)
NB. 6502 emulation is slower now, which means disk loading (ie. full-speed) is slower.
. EG. Aztec.dsk: from F2 boot to "Press any key". (Release build, 50% "TV Color", not run in VS, VAIO laptop)
~4 secs: AppleWin 1.25.0.3 (built with VS2005)
~7 secs: AppleWin 1.26.0.1 (built with VS2008 or VS015)
. means that disk accesses (eg. loading) is much quicker
Correct naming of video modes (in UI and code)
Pixel adjust for NTSC B&W and Color video modes to align with other video modes
. Format now extensible for supporting new hardware types in the future
. Include missing items like Apple2Type, CyclesThisVideoFrame (#255)
Continue to support loading of old v1 format.
Added card save/load for:
. Mouse (#260)
. HDD (#260)
. Printer
Extended card support for:
. SSC
Other:
. Added save-state v1 struct size checks
. Create SaveState_Structs_v2.h and split out common into SaveState_Structs_common.h
. Refactor HardDisk.cpp to use imagehandle; and consolidate with Disk.cpp
. Fix Disk/HD_GetFullPathName() which wasn't always returning full pathname
. Consolidate common GetImageTitle() and move into DiskImage.cpp
Removed complex case below for:
. VideoHasRefreshed(), 'anyupdates'
. VideoCheckPage()
Detailed notes below.
---
Video updates in ContinueExecution() loop:
'anyupdates' gets set if there were any page-flip(s) in last ~17030 cycles:
anyupdates |= VideoHasRefreshed();
ie. VideoRefreshScreen() was called outside of this loop.
If there's been a call to VideoRefreshScreen() outside of this loop,
and then the video framebuffer gets written to, ie. VideoApparentlyDirty() returns TRUE,
then don't call VideoRefreshScreen() from this loop for 3 frames.
(If a VideoRefreshScreen() is called outside of this loop then restart the 3 frame count.)
So..
if the game is flipping, the VideoApparentlyDirty() will return FALSE (since game writes to other framebuffer).
if the game is not flipping, then VideoHasRefreshed() will return FALSE (since no flips occur).
Therefore this complex case above probably only arises at a boundary eg. when the game is transitioning between these 2 modes,
and so if the emulator does the very occasional screen update in this main loop, it is of no consequence.
(I guess this extra logic was to throttle video updates on very old slow machines)
---
VideoCheckPage(BOOL bForce) was called twice in main-loop:
UnexpectedPage if g_bVideoDisplayPage2 != SW_PAGE2
Once each time through the loop (ie. every 1ms), with bForce=0
if UnexpectedPage && >500ms since last flip then VideoRefreshScreen()
Once each video frame (ie. ~17030 cycles) when not flipping, with bForce=1
if UnexpectedPage then VideoRefreshScreen()
Basically this was all about supporting FullSpeed mode, and limiting the calls to VideoRefreshScreen().
