KEGS 1.31 - Windows ROM fix, printer fixes

[Kent Dickey]

I've updated KEGS to v1.31 to fix a severe Windows crash if you changed the
path to the ROM file, and to improve printing support. KEGS is an Apple IIgs
emulator for Mac, Windows, and Linux with source code.

KEGS v1.31 is available at: http://kegs.sourceforge.net

Changes in KEGS v1.31 since v1.30 (11/04/23)
- Fix Windows failure where KEGS would quit on startup if config.kegs
contained a new ROM path.
- Fix a Code Red halt running the Printer57.6 driver where KEGS thought it
might need to generate a baud rate event every .5 cycles.
- Fix disk image selection screen bug where s7d10-s7d12 could wrap and make
it hard to leave the screen.
- Add a Slinky RAM card in slot 4 (with no firmware), works even with
Mockingboard.
- Fix scanline interrupts which were happening too early starting with
version 1.24.
- Another false read bug was causing 16-bit RMW cycles to read the next
address (which is incorrect).

Kent

[Hugh Hood]

Kent,

Thanks for fixing the Code Red Printer57.6 driver issue.

I have noticed one thing in KEGS 1.31 that was not previously an issue
-- Mouse movement in GS/OS now has, for lack of a better term, a startup
lag. It's just not as initially responsive or as fluid as in KEGS 1.30
and prior versions.

I've noticed this on both MacOS and Windows 10. Changing the IIgs
Control Panel Mouse parameters does not seem to improve it. Could this
be related to the scanline interrupt issue you mentioned, or is
something else causing it?




Hugh Hood

Post by Kent Dickey
I've updated KEGS to v1.31 to fix a severe Windows crash if you changed the
path to the ROM file, and to improve printing support. KEGS is an Apple IIgs
emulator for Mac, Windows, and Linux with source code.
KEGS v1.31 is available at: http://kegs.sourceforge.net
Changes in KEGS v1.31 since v1.30 (11/04/23)
- Fix Windows failure where KEGS would quit on startup if config.kegs
contained a new ROM path.
- Fix a Code Red halt running the Printer57.6 driver where KEGS thought it
might need to generate a baud rate event every .5 cycles.
- Fix disk image selection screen bug where s7d10-s7d12 could wrap and make
it hard to leave the screen.
- Add a Slinky RAM card in slot 4 (with no firmware), works even with
Mockingboard.
- Fix scanline interrupts which were happening too early starting with
version 1.24.
- Another false read bug was causing 16-bit RMW cycles to read the next
address (which is incorrect).
Kent

[Kent Dickey]

Post by Hugh Hood
Kent,
Thanks for fixing the Code Red Printer57.6 driver issue.
I have noticed one thing in KEGS 1.31 that was not previously an issue
-- Mouse movement in GS/OS now has, for lack of a better term, a startup
lag. It's just not as initially responsive or as fluid as in KEGS 1.30
and prior versions.
I've noticed this on both MacOS and Windows 10. Changing the IIgs
Control Panel Mouse parameters does not seem to improve it. Could this
be related to the scanline interrupt issue you mentioned, or is
something else causing it?
Hugh Hood

I'm not sure I'm able to reproduce this issue. If I boot GS/OS, set KEGS'
speed to 2.8MHz, move the mouse down about 15% of the screen, and then move
the mouse left and right slowly but continuously, the mouse cursor can
disappear for several seconds (but reappears as soon as I stop moving the
mouse). Is that what you're referring to?

Kent

[Hugh Hood]

Kent,

I'm seeing the mouse change when working at unlimited speed, which is my
preferred speed at which to work. KEGS at unlimited speed is the GOAT.

When I slow the speed down to 2.8 MHz, like you, I don't really notice
much of a change in mouse behavior between 1.30 and 1.31.

Try setting the speed to unlimited, boot into the GS/OS Finder, and
place the mouse cursor in the middle of the screen at the bottom. Then,
sharply (rather than slowly) move the mouse upward toward the top of the
screen.

On KEGS 1.30, the mouse cursor is visible during the travel. On KEGS
1.31, the mouse cursor hides while being moved and then becomes visible
when the mouse either stops or slows down. It's as though there is a lag
before the mouse cursor re-appears.

Yes, it's subjective, no doubt. But, the mouse in 1.30 (where the cursor
is visible the entire time) gives a more natural feel, FWIW.





Hugh Hood

Post by Kent Dickey

Post by Hugh Hood
Kent,
Thanks for fixing the Code Red Printer57.6 driver issue.
I have noticed one thing in KEGS 1.31 that was not previously an issue
-- Mouse movement in GS/OS now has, for lack of a better term, a startup
lag. It's just not as initially responsive or as fluid as in KEGS 1.30
and prior versions.
I've noticed this on both MacOS and Windows 10. Changing the IIgs
Control Panel Mouse parameters does not seem to improve it. Could this
be related to the scanline interrupt issue you mentioned, or is
something else causing it?
Hugh Hood

I'm not sure I'm able to reproduce this issue. If I boot GS/OS, set KEGS'
speed to 2.8MHz, move the mouse down about 15% of the screen, and then move
the mouse left and right slowly but continuously, the mouse cursor can
disappear for several seconds (but reappears as soon as I stop moving the
mouse). Is that what you're referring to?
Kent

[Kent Dickey]

Post by Hugh Hood
Kent,
I'm seeing the mouse change when working at unlimited speed, which is my
preferred speed at which to work. KEGS at unlimited speed is the GOAT.
When I slow the speed down to 2.8 MHz, like you, I don't really notice
much of a change in mouse behavior between 1.30 and 1.31.
Try setting the speed to unlimited, boot into the GS/OS Finder, and
place the mouse cursor in the middle of the screen at the bottom. Then,
sharply (rather than slowly) move the mouse upward toward the top of the
screen.
On KEGS 1.30, the mouse cursor is visible during the travel. On KEGS
1.31, the mouse cursor hides while being moved and then becomes visible
when the mouse either stops or slows down. It's as though there is a lag
before the mouse cursor re-appears.
Yes, it's subjective, no doubt. But, the mouse in 1.30 (where the cursor
is visible the entire time) gives a more natural feel, FWIW.

My usual GS/OS boot disk doesn't seem to show it consistently, and I'm not
sure why. The KEGSTest.hdv you sent me previously shows the problem very
easily.

It's a KEGS bug--how it was finding the "next" SCB byte was a dumb algorithm
which could be confused by moving the mouse up the screen slowly. KEGS
would scan ahead, find the SCB at line 190 (for example), and set an event.
Then the mouse would move, GS/OS would move the scanline interrupt to
line 185. KEGS would miss this, and when the display got to line 190 KEGS
would say "there's no more scanline interrupt" and do nothing (since GS/OS
cleared the interrupt bit in the SCB). KEGS always scans for SCBs when it
draws line 0, so that would happen again, it would set an event for line 185.
But then the mouse moved a little more, and GS/OS moves the SCB scanline
interrupt to line 183. Again, no interrupt would occur. If you moved the
mouse just at the right speed, it could cause KEGS to fail to take any
SCB scanline interrupt for more than 1/2 a second.

The solution was to make SCB scanline interrupts more robust. Now, KEGS
looks at all writes to $e1/9dXX, and moves the expected SCB scanline
interrupt event up to the earliest possible time always.

Kent