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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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



On 11/4/2023 8:42 PM, Kent Dickey wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <3eycnckcCKLOZtf4nZ2dnZfqn_GdnZ2d@earthlink.com>,
Hugh Hood <hughhood@earthlink.net> wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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


On 11/12/2023 3:44 PM, Kent Dickey wrote:

In article <3eycnckcCKLOZtf4nZ2dnZfqn_GdnZ2d@earthlink.com>,
Hugh Hood <hughhood@earthlink.net> wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <tv6cnatOse8iB8z4nZ2dnZfqn_WdnZ2d@earthlink.com>,
Hugh Hood <hughhood@earthlink.net> wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)