commits
i.e., don't create a bridge interface and pass it, just pass the
interface to be bridged to and vmnet will create the vmenet and
bridge interfaces
In case there are other network implementations later.
When we're idle and nothing is happening on screen, we can save some
host CPU by not having to constantly iterate through the video
memory buffer and send it through SDL just to redraw the same thing
over and over.
This greatly speeds up EtherTalk since we are no longer dropping
additional packets and having to wait and retry them.
When double-clicking fast enough, Mac OS doesn't seem to register
the mouse up and re-mouse-down, despite the 6522 seeing both mouse
events. Add the ability to delay processing mouse events in the SDL
event queue for a small amount of time which seems to fix the issue.
This requires a patched ROM but otherwise works as expected.
The command may need to change permissions to allow us to open it in
the first place.
When the mouse cursor is at the edge of the screen (as read from the
RawMouse low-mem global) and the mouse is moving out of bounds,
automatically unbind the mouse and keyboard. Once the mouse cursor
is back in bounds, grab.
This uses the native vmnet framework instead of requiring a 3rd
party tap/tun kernel driver. Unfortunately there is no way to
configure this without root permissions, like we can by setting
permissions on a tap device.
Also fix the SCSI mode selection in mac_scsi_cmd_set_interface_mode
and mac_scsi_cmd_set_mcast_addr. These get data sent by the driver
so we need to be in the data out phase. This fixes the error in Mac
OS when switching the AppleTalk connection to EtherTalk, so now
EtherTalk works properly and we can do AppleShare over emulated
ethernet.
This is easier to press than Control+Option. Also allow right-side
keys to match these, since Caps Lock changed to Control comes
through as right Control.
Command+Q and Command+W on macOS cause the app to quit but we want
to pass them through to the emulated Mac.
Continue passing up events to allow the OS to see that the
grab-exiting keys (Ctrl+Alt) were released.
This gets the requested window size even on aggressive tiling window
managers that try to force a window size
Such as scale_quality = "nearest"
When running at the normal slow CPU speed and there is a lot of
keyboard input in a short amount of time, the keyboard data into the
6522 doesn't seem to be written in or read out properly which causes
the OS to figure the keyboard is no longer responding to its Inquiry
commands, so it sends out a Model request which the PCE keyboard
driver handles by flushing out its buffer of keys queued up.
Work around this by tracking the last time data was sent to the 6522
and waiting a very short while before shifting another byte (either
keyboard data or an inquiry response) into it. This ensures that
every keyboard response can be properly read by the OS so it resets
its inquiry timeout watchdog.
A proper way to do this is probably to know when the data was
properly read out of the 6522 and make it available again, rather
than just relying on a timer.
From http://www.mac.linux-m68k.org/devel/plushw.php:
The first command the Macintosh sends out is the Model Number
command. The keyboard's response to this command is to reset
itself and send back its model number to the Macintosh. If no
response is received for 1/2 second, the Macintosh tries the
Model Number command again. Once the Macintosh has successfully
received a model number from the keyboard, normal operation can
begin. The Macintosh sends the Inquiry command; the keyboard
sends back a Key Transition response if a key has been pressed
or released. If no key transition has occurred after 1/4
second, the keyboard sends back a Null response to let the
Macintosh know it's still there. The Macintosh then sends the
Inquiry command again. In normal operation, the Macintosh sends
out an Inquiry command every 1/4 second. If it receives no
response within 1/2 second, it assumes the keyboard is missing
or needs resetting, so it begins again with the Model Number
command.
Currently only works on OpenBSD and requires read/write access to
the tap device (/dev/tap0 by default). A helper script is run after
bringing up the device to do things as root like assign an IP (for
NAT) or configure bridging (for ethernet).
SCSI protocol information was gleaned from the DaynaPORT driver in
RASCSI and my real DaynaPORT device.
Every hook function now has its own opaque pointer.
This changes the default behaviour from always decoding clock rate tolerances
to only decoding them if requested by setting 'decode-clock' to true.
Values outside the range [0,63] now indicate that the gcr format
byte is unspecified, rather than the value 0, which is a valid
gcr format byte.
Multiple 'ROTATE' commands are now accumulated. A 'ROTATE SET' command
resets the rotate counter to 0.
Option "system.alt_ram_sizes" specifies that the ROM uses
alternate RAM sizes.
Option "system.model" now only specifies a 6 MHz or 8 MHz
model.
Before this patch, system.model = 2 implied
system.alt_ram_sizes = true.
The video display height was off by one in most modes.
The pri utility now recognizes a new parameter 'psi-pos' which
is set to false by default.
After a key is acknowledged port 0x60 should be reset to 0x00.
If a key name is not prefixed by either a '+' or a '-' then
the key is pressed and released.
If the resize event does not change the size of the window
then autosizing should not be disabled.
This uses the native vmnet framework instead of requiring a 3rd
party tap/tun kernel driver. Unfortunately there is no way to
configure this without root permissions, like we can by setting
permissions on a tap device.
Also fix the SCSI mode selection in mac_scsi_cmd_set_interface_mode
and mac_scsi_cmd_set_mcast_addr. These get data sent by the driver
so we need to be in the data out phase. This fixes the error in Mac
OS when switching the AppleTalk connection to EtherTalk, so now
EtherTalk works properly and we can do AppleShare over emulated
ethernet.
When running at the normal slow CPU speed and there is a lot of
keyboard input in a short amount of time, the keyboard data into the
6522 doesn't seem to be written in or read out properly which causes
the OS to figure the keyboard is no longer responding to its Inquiry
commands, so it sends out a Model request which the PCE keyboard
driver handles by flushing out its buffer of keys queued up.
Work around this by tracking the last time data was sent to the 6522
and waiting a very short while before shifting another byte (either
keyboard data or an inquiry response) into it. This ensures that
every keyboard response can be properly read by the OS so it resets
its inquiry timeout watchdog.
A proper way to do this is probably to know when the data was
properly read out of the 6522 and make it available again, rather
than just relying on a timer.
From http://www.mac.linux-m68k.org/devel/plushw.php:
The first command the Macintosh sends out is the Model Number
command. The keyboard's response to this command is to reset
itself and send back its model number to the Macintosh. If no
response is received for 1/2 second, the Macintosh tries the
Model Number command again. Once the Macintosh has successfully
received a model number from the keyboard, normal operation can
begin. The Macintosh sends the Inquiry command; the keyboard
sends back a Key Transition response if a key has been pressed
or released. If no key transition has occurred after 1/4
second, the keyboard sends back a Null response to let the
Macintosh know it's still there. The Macintosh then sends the
Inquiry command again. In normal operation, the Macintosh sends
out an Inquiry command every 1/4 second. If it receives no
response within 1/2 second, it assumes the keyboard is missing
or needs resetting, so it begins again with the Model Number
command.
Currently only works on OpenBSD and requires read/write access to
the tap device (/dev/tap0 by default). A helper script is run after
bringing up the device to do things as root like assign an IP (for
NAT) or configure bridging (for ethernet).
SCSI protocol information was gleaned from the DaynaPORT driver in
RASCSI and my real DaynaPORT device.