- Added Configuration GUI to include checkbox for "50Hz"
- Implicitly use PAL or NTSC base 6502 clocks depending on video refresh rate
- Added new -50hz and -60hz command line switches
- Updated save-state for video refresh rate
1.28.8.0: Updated version & history.txt
Support the old AppleWin 1.25 vertical blending for hires:
- extended Config dialog to include 'Vertical Blend' checkbox
- Persist 'Video Styles' to Registry
- new cmd line options to select this style & also select 'RGB (Color Monitor)'
- code refactor to support enum VideoStyle_e (and replaced g_uHalfScanLines with a bit in g_eVideoStyles)
Bumped version to 1.28.2.0.
Renamed this video mode to: "Color (RGB Monitor)"
Also renamed "Color (Monitor)" to "Color (NTSC Monitor)".
As for the colours: I've changed them from the original 1.25 colours. Instead I runtime-generate the colours from the NTSC code. See NTSC.cpp's GenerateBaseColors(). This shifts the same 4-bit pattern in, combining with NTSC color phase, until the colour stabilises. Then I average the next 4 RGB values to get the final colour. The reason for this is that we now have consistent colours between NTSC and this simplified rendering mode.
NB. The 2 greys (in GR,DGR,DHGR) are now the same RGB value.
Added new cmd-line switch: -videorom <file> to replace the video ROM for the Enhanced //e.
- Support video ROM sizes of 4K, 8K and 16K (top 8K only).
- NB. The rocker switch is set to European video ROM.
F10 (for //e or Enhanced //e models) emulates the PAL //e's rocker switch (under the keyboard) to toggle between European or US video ROM.
Other:
- Fixed debugger's view of the AltCharSet soft-switch (it was showing the opposite state).
. Removed NTSC_VideoVbl(), since it's not accurate during full-speed. (Nothing was using it)
. Renamed VideoGetVbl() to VideoGetVblBar()
. Correctly pass Vbl (not VblBar) to Mouse's SetVBlank()
. Specifically IBIZA.DSK demo which streams data from the disk throughout (ie. so runs at full-speed all the time)
. Update the screen every frame, but only if video memory has changed (check AZTEC.DSK loading time)
. NB. When running at full-speed, then 6502 emulation doesn't do cycle-accurate video updates
Fixed crash that could occur when switch video mode (F9) when running at full-speed
. Occured when g_nVideoClockVert was >= 192
- old 640x480 full-screen deprecated
Fixes for:
. Logo & Debug window scaled/positioned correctly
. Buttons & disk activity (on RHS) drawn in correct position
. Crosshairs for mouse (and when using mouse as joystick)drawn in correct position
. 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
. final rendered window
. print-screen bmps (both sizes)
Fixed full-screen so that:
. all mode (RUNNING, DEBUG and LOGO) all occupy the same screen position
. there's no intermediate data drawn out of position when first switching to full-screen
Tested on Win7 and Win10
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().
