KEGS v1.03 released

[Kent Dickey]

It's only been 16 years since the last release, but I was thinking I should
release my current version of KEGS in anticipation of Nox Archaist coming
out tomorrow.

KEGS is an Apple IIgs emulator for Mac OS X and Linux. There's an older
version for Win32, but I'm not updating that now. Most Apple II/II+/IIe/IIc
games and applications work as well.

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

And as usual, full source code is included.

Some highlights:
- Works on modern 64-bit Macs (KEGS v0.91 was a 32-bit application).
- Mockingboard support. Set slot 4 to "Your Card". GS/OS won't be able to
use the mouse when slot 4 is set to Your Card, though.
- Disk images can be .gz compressed, or .sdk compressed disk images. They
will be mounted read-only.
- Windows can be resized, and Mac can do full-screen.
- KEGS runs at an emulated speed of 550MHz on my iMac, 750MHz on my Linux
machine, and 1020MHz on a Mac Mini M1.
- Sound works on Linux using Pulse Audio (I don't have a good way to test this
anymore, so let me know if it works).

Press F4 to access the configuration controls.

There are still a lot of usability issues. I'm working on making it better.
If you have an area you would like improved, please let me know.

There's a preliminary Apple //e emulation mode if you point KEGS at a
32KB Apple //e ROM from the F4 configuration control panel. I needed this to
test the Mockingboard support since most Mockingboard applications don't
support the IIgs for a variety of reasons.

Kent

[Kent Dickey]

Post by Kent Dickey
It's only been 16 years since the last release, but I was thinking I should
release my current version of KEGS in anticipation of Nox Archaist coming
out tomorrow.
KEGS is an Apple IIgs emulator for Mac OS X and Linux. There's an older
version for Win32, but I'm not updating that now. Most Apple II/II+/IIe/IIc
games and applications work as well.
KEGS v1.03 is available at: http://kegs.sourceforge.net
And as usual, full source code is included.

KEGS by default has a problem with the 5.25" disk images of Nox Archaist.
The fix is to turn off "Fast Disk emulation" by pressing Shift-F7 anytime
after starting KEGS, but before you make any selections at the game's main
menu.

------------------------------------------------------------------------

The details: KEGS's fast disk emulation was to avoid having KEGS slow
down to access the 5.25" disk--it could run at full speed and still access
the disk. In this mode, KEGS ignores the disk cycle timing and just reads the
"next" byte off of the disk whenever software gets around to reading it.
And for writing, it similarly just writes bytes to the disk image ignoring
cycle timing.

Each sector on a 5.25" disk consists of sync bytes (at least 5 bytes of 0xff
written each 40usec, instead of the usual 32usec), then the sector header D5
AA 96. Then there's the sector information: 2 bytes for volume, 2 bytes for
track, 2 bytes for physical sector number, then 2 bytes for checksum. Then DE
AA EB, then 5-6 sync bytes written at 40usec timing, then the data starts with
D5 AA AD, then the data.

DOS3.3/ProDOS/etc, read all of the header data, including the checksum,
and may read the DE byte as well. So then, when they get around to doing the
write, KEGS in fast disk emulation mode just begins writing at the disk
byte right after the last one read by software, regardless of how much "time"
passes.

Nox Archaist works differently. It doesn't read the header checksum when
writing a sector. It reads the volume, track, and sector number, then does a
small delay loop $24 times, then begins writing the 0xff sync bytes and the
sector data. This will wait a total of 186 clocks, which is 5.8 disk nibbles,
and then begin writing the sync bytes, D5 AA AD and then sector data.
So the checksum, and DE AA EB will have passed by. But not with fast disk
emulation in KEGS. Instead, KEGS with fast disk emulation enabled would
overwrite the checksum bytes with the new sync bytes, and so corrupt the
sector header.

And KEGS 1.03 defaults to fast disk emulation on. I've changed that so it's
now disabled by default, and this will be the default in KEGS from now on.

It would be better if Nox Archaist checked the header checksum before
writing the sector data. Real floppy disks do go bad, and extra checking
is a good idea.

Kent

[[e-mail]]

Post by Kent Dickey
It would be better if Nox Archaist checked the header checksum before
writing the sector data. Real floppy disks do go bad, and extra checking
is a good idea.

Agreed, a good idea, but I have zero bytes left in memory for such a feature, so I had to cut some corners.

[TomCh]

In article,

Post by Kent Dickey
It's only been 16 years since the last release, but I was thinking I should
release my current version of KEGS in anticipation of Nox Archaist coming
out tomorrow.
KEGS is an Apple IIgs emulator for Mac OS X and Linux. There's an older
version for Win32, but I'm not updating that now. Most Apple II/II+/IIe/IIc
games and applications work as well.
KEGS v1.03 is available at: http://kegs.sourceforge.net

Congratulations on this new release!

Post by Kent Dickey
And as usual, full source code is included.

KEGS by default has a problem with the 5.25" disk images of Nox Archaist.
The fix is to turn off "Fast Disk emulation" by pressing Shift-F7 anytime
after starting KEGS, but before you make any selections at the game's main
menu.
------------------------------------------------------------------------
The details: KEGS's fast disk emulation was to avoid having KEGS slow
down to access the 5.25" disk--it could run at full speed and still access
the disk. In this mode, KEGS ignores the disk cycle timing and just reads the
"next" byte off of the disk whenever software gets around to reading it.
And for writing, it similarly just writes bytes to the disk image ignoring
cycle timing.
Each sector on a 5.25" disk consists of sync bytes (at least 5 bytes of 0xff
written each 40usec, instead of the usual 32usec), then the sector header D5
AA 96. Then there's the sector information: 2 bytes for volume, 2 bytes for
track, 2 bytes for physical sector number, then 2 bytes for checksum. Then DE
AA EB, then 5-6 sync bytes written at 40usec timing, then the data starts with
D5 AA AD, then the data.
DOS3.3/ProDOS/etc, read all of the header data, including the checksum,
and may read the DE byte as well. So then, when they get around to doing the
write, KEGS in fast disk emulation mode just begins writing at the disk
byte right after the last one read by software, regardless of how much "time"
passes.
Nox Archaist works differently. It doesn't read the header checksum when
writing a sector. It reads the volume, track, and sector number, then does a
small delay loop $24 times, then begins writing the 0xff sync bytes and the
sector data. This will wait a total of 186 clocks, which is 5.8 disk nibbles,
and then begin writing the sync bytes, D5 AA AD and then sector data.
So the checksum, and DE AA EB will have passed by. But not with fast disk
emulation in KEGS. Instead, KEGS with fast disk emulation enabled would
overwrite the checksum bytes with the new sync bytes, and so corrupt the
sector header.
And KEGS 1.03 defaults to fast disk emulation on. I've changed that so it's
now disabled by default, and this will be the default in KEGS from now on.
It would be better if Nox Archaist checked the header checksum before
writing the sector data. Real floppy disks do go bad, and extra checking
is a good idea.
Kent

I read this and immediately worried, as AppleWin (in a similar 'Fast Disk Emulation' mode) does something similar to what you describe.

But surely this isn't an issue for 2 reasons:
1) If Qkumba's ProRWTS doesn't read the two 4&4 checksum nibbles, then why does it matter if they get stomped on? IE. the RWTS code never checks them, nor does it write them (they are only written once during the disk INIT/FORMAT).
2) When the emulator commits the "dirty" (written) track to the file (.dsk image), then just don't check the 4&4 checksum. (OK, this is obviously dependent on the emulator's implementation.)

I quickly eyeballed the AppleWin code. I've not stepped the code, but it appears to ignore cycle timings in 'Fast Disk Emulation' mode when in write mode (for .dsk/nib images - but not ignored for .woz), so I assume it will also stomp on the 4&4 checksum (and epilogue DE nibbles). Then when AppleWin commits the dirty track to .dsk file, it'll just use the 4&4 sector (ignoring the checksum) and the 343 nibbles of 6&2 data. So for a .dsk, the 343 nibbles get decoded to 256 bytes, and the sector determines the location in the 4KiB track.

Tom

[Kent Dickey]

[ snip ]

Post by TomCh

Nox Archaist works differently. It doesn't read the header checksum when
writing a sector. It reads the volume, track, and sector number, then does a
small delay loop $24 times, then begins writing the 0xff sync bytes and the
sector data. This will wait a total of 186 clocks, which is 5.8 disk nibbles,
and then begin writing the sync bytes, D5 AA AD and then sector data.
So the checksum, and DE AA EB will have passed by. But not with fast disk
emulation in KEGS. Instead, KEGS with fast disk emulation enabled would
overwrite the checksum bytes with the new sync bytes, and so corrupt the
sector header.
And KEGS 1.03 defaults to fast disk emulation on. I've changed that so it's
now disabled by default, and this will be the default in KEGS from now on.
It would be better if Nox Archaist checked the header checksum before
writing the sector data. Real floppy disks do go bad, and extra checking
is a good idea.
Kent

I read this and immediately worried, as AppleWin (in a similar 'Fast
Disk Emulation' mode) does something similar to what you describe.
1) If Qkumba's ProRWTS doesn't read the two 4&4 checksum nibbles, then
why does it matter if they get stomped on? IE. the RWTS code never
checks them, nor does it write them (they are only written once during
the disk INIT/FORMAT).
2) When the emulator commits the "dirty" (written) track to the file
(.dsk image), then just don't check the 4&4 checksum. (OK, this is
obviously dependent on the emulator's implementation.)
I quickly eyeballed the AppleWin code. I've not stepped the code, but it
appears to ignore cycle timings in 'Fast Disk Emulation' mode when in
write mode (for .dsk/nib images - but not ignored for .woz), so I assume
it will also stomp on the 4&4 checksum (and epilogue DE nibbles). Then
when AppleWin commits the dirty track to .dsk file, it'll just use the
4&4 sector (ignoring the checksum) and the 343 nibbles of 6&2 data. So
for a .dsk, the 343 nibbles get decoded to 256 bytes, and the sector
determines the location in the 4KiB track.
Tom

KEGS always slows down to 1MHz during writing, even with fast disk emulation.
But that's only once writing has started, so it doesn't help this case.

KEGS has a problem with Nox Archaist since the code to "unnibilize" the
track to write updates back to the .dsk image checks the header checksum,
and then decides the disk is no longer a valid "DOS" disk.

I'd rather turn off fast disk emulation than remove these consistency checks,
since I want KEGS to only support valid DOS-format .dsk images, and do
something else if the image format changes.

Kent

[TomCh]

Post by Kent Dickey
[ snip ]
KEGS always slows down to 1MHz during writing, even with fast disk emulation.
But that's only once writing has started, so it doesn't help this case.

Why does KEGS slow down to 1MHz during writing?

Tom

[Kent Dickey]

Post by TomCh

Post by Kent Dickey
[ snip ]
KEGS always slows down to 1MHz during writing, even with fast disk emulation.
But that's only once writing has started, so it doesn't help this case.

Why does KEGS slow down to 1MHz during writing?
Tom

KEGS always maintains .woz image level disk images (in a different format,
it's not raw bits, it's a synchronized nibble view) in its memory even when
.dsk images are being used. Reading in "fast disk emulation" mode works fine
ignoring timing, but writing does not, and it could create weird images
which could cause problems (for emulated software, and for KEGS itself).
Easy solution--writes force 1MHz mode only for the duration of the write. If
you're running at "unlimited speed", you almost certainly won't notice it.
It will be slightly noticeable if you've set the KEGS speed to 2.8MHz.

Kent

[Brian Patrie]

GS/OS won't be able to use the mouse
when slot 4 is set to Your Card

This is true of ROM 0, and ROM 1. In ROM 3 the mouse tool is native; so
the mouse works in GS/OS regardless of the setting of slot 4. :)

[David Schmidt]

Post by Kent Dickey
It's only been 16 years since the last release, but I was thinking I should
release my current version of KEGS in anticipation of Nox Archaist coming
out tomorrow.

Exciting news indeed. Glad to see it (and you) back in action!

[I am Rob]

I have a 64 bit Mac, but cannot open the Kegs app. Using 10.7.5.

What is the minimum OS?

[Kent Dickey]

Post by I am Rob
I have a 64 bit Mac, but cannot open the Kegs app. Using 10.7.5.
What is the minimum OS?

Sadly, Apple "obsoletes" software very fast. I have no good mechanism
for compiling and running on modern OS'es and ones 8 years old. If
someone knows how to do this easily, I'm all ears.

I compiled KEGS for 10.15, "Catalina". I suspect it won't work on 10.7.

You may want to use KEGS.0.91, also on the website. That was built for
10.3 (if I remember right), so it should definitely work for you.

Kent

[I am Rob]

I have a 64 bit Mac, but cannot open the Kegs app. Using 10.7.5.
What is the minimum OS?

Sadly, Apple "obsoletes" software very fast. I have no good mechanism
for compiling and running on modern OS'es and ones 8 years old. If
someone knows how to do this easily, I'm all ears.
I compiled KEGS for 10.15, "Catalina". I suspect it won't work on 10.7.
You may want to use KEGS.0.91, also on the website. That was built for
10.3 (if I remember right), so it should definitely work for you.
Kent

I swap between GSPort and SWEET16 right now, but was hoping to get the new KEGS working at the emulated speed of 1 Ghz. GSPort caps out at 250 Mhz (which is still pretty fast). SWEET16 tops out at 100 Mhz. Mostly wanted the speed of KEGS to do graphics compression.

Although I don't believe SWEET16 works on the newer OSes yet, At least KEGS will give me a reason to upgrade now.

[Kent Dickey]

Post by I am Rob

I have a 64 bit Mac, but cannot open the Kegs app. Using 10.7.5.
What is the minimum OS?

Sadly, Apple "obsoletes" software very fast. I have no good mechanism
for compiling and running on modern OS'es and ones 8 years old. If
someone knows how to do this easily, I'm all ears.
I compiled KEGS for 10.15, "Catalina". I suspect it won't work on 10.7.
You may want to use KEGS.0.91, also on the website. That was built for
10.3 (if I remember right), so it should definitely work for you.
Kent

I swap between GSPort and SWEET16 right now, but was hoping to get the
new KEGS working at the emulated speed of 1 Ghz. GSPort caps out at 250
Mhz (which is still pretty fast). SWEET16 tops out at 100 Mhz. Mostly
wanted the speed of KEGS to do graphics compression.
Although I don't believe SWEET16 works on the newer OSes yet, At least
KEGS will give me a reason to upgrade now.

There's no magic change in KEGS to make it faster--it's basically the same
code. Two things have occurred--CPUs have gotten more efficient at executing
code (so, new machines are faster), and compilers have gotten better at
making the KEGS inner loop work better. And the Apple M1 chip is even
faster--giving it a 33% edge over anything else I've run on.

On an old machine running 10.7.5, you're not going to get 1GHz emulation
speed.

New KEGS is basically for Catalina and later, since Apple dropped 32-bit
compatibility, and so 32-bit KEGS no longer runs. KEGS now uses Swift for
the UI code on Mac builds, so you'll need to move to a somewhat new Mac OS
to run it. And Apple has thrown a lot of roadblocks in the way--new OS'es
have upped their hardware requirements, so your 10.7.5 system probably cannot
go too high. If you can, go to Mojave (10.14), which still gives you
32-bit app compatibility. But make sure your system is compatible first.

On an average modern Mac, I'd suspect you'll get around 400-500MHz emulated
speed. I would be curious to collect KEGS speed data if anyone wants to
report it from various Mac models and Linux machines.

Basically, if on a Mac, KEGS.0.91 works for you (or GSPort, or whatever),
you should stick with it. If KEGS on the Mac stopped working for you because
of no 32-bit compatibility on new OS'es, move to KEGS.1.03+.

Kent

[I am Rob]

Post by Kent Dickey
There's no magic change in KEGS to make it faster--it's basically the same
code. Two things have occurred--CPUs have gotten more efficient at executing
code (so, new machines are faster), and compilers have gotten better at
making the KEGS inner loop work better. And the Apple M1 chip is even
faster--giving it a 33% edge over anything else I've run on.
On an old machine running 10.7.5, you're not going to get 1GHz emulation
speed.
New KEGS is basically for Catalina and later, since Apple dropped 32-bit
compatibility, and so 32-bit KEGS no longer runs. KEGS now uses Swift for
the UI code on Mac builds, so you'll need to move to a somewhat new Mac OS
to run it. And Apple has thrown a lot of roadblocks in the way--new OS'es
have upped their hardware requirements, so your 10.7.5 system probably cannot
go too high. If you can, go to Mojave (10.14), which still gives you
32-bit app compatibility. But make sure your system is compatible first.
On an average modern Mac, I'd suspect you'll get around 400-500MHz emulated
speed. I would be curious to collect KEGS speed data if anyone wants to
report it from various Mac models and Linux machines.
Basically, if on a Mac, KEGS.0.91 works for you (or GSPort, or whatever),
you should stick with it. If KEGS on the Mac stopped working for you because
of no 32-bit compatibility on new OS'es, move to KEGS.1.03+.

The highest OS I can go to is 10.12 for this computer. I have a 64-bit computer and with the latest Intel Core2 Duo. So not about 32-bit compatibility.

Since you compiled under 10.15, I wouldn't even be able to use it on 10.12.

But even if it could run, would there be a speed difference between the 32-bit and 64-bit apps?

[Steve Nickolas]

Post by I am Rob
But even if it could run, would there be a speed difference between the
32-bit and 64-bit apps?

It's possible in theory.

I run both 32-bit and 64-bit versions of Avisynth, because some of the
plugins I rely on are not compatible with the 64-bit version. 64-bit
Avisynth is a little faster.

-uso.

[Brian Patrie]

Post by Kent Dickey
I would be curious to collect KEGS speed data if anyone wants
to report it from various Mac models and Linux machines.

On a 3.5 GHz i7-4770K, under Linux Mint 19.3 (after chasing a few
dependencies (libpulse-dev libx11-dev libxext-dev) to get it to build).

About 1750 MHz emulation, idling at an AppleSoft prompt.
About 600 MHz emulation, idling in GS/OS 6.0.4 Finder.

[Kent Dickey]

Post by Brian Patrie

Post by Kent Dickey
I would be curious to collect KEGS speed data if anyone wants
to report it from various Mac models and Linux machines.

On a 3.5 GHz i7-4770K, under Linux Mint 19.3 (after chasing a few
dependencies (libpulse-dev libx11-dev libxext-dev) to get it to build).
About 1750 MHz emulation, idling at an AppleSoft prompt.
About 600 MHz emulation, idling in GS/OS 6.0.4 Finder.

Unfortunately, idling at an Applesoft prompt is not a realistic speed.
Applesoft calls a monitor routine to read input, and it reads the keyboard
at $C000 very often--and that always takes one full "slow" cycle per read,
which KEGS tries to make take one microsecond in real time as well.
KEGS is fast enough that it can do that more than 1 million times per second,
so the effective speed is infinite. KEGS limits its speed to 1.9GHz
currently (or about that), so you're just hitting that limit.

The Finder result is fine--that's a good indication of KEGS running code.
Alternatively, run an Applesoft program like this:

10 SUM = 0
20 FOR I = 1 to 345678
30 SUM = SUM + SIN(I)
40 NEXT
50 PRINT SUM

This will take 10-40 seconds, and the speed shown while it runs is more
indicative of the real speed. It doesn't really matter what the BASIC
code is doing, as long as it doesn't try to read the keyboard much (and
SIN() is pretty slow).

I find KEGS runs Applesoft at about ~95% of the finder speed, so I expect
your Applesoft speed will be about 550MHz if your Finder speed is 600MHz.

Kent

[Brian Patrie]

Post by Kent Dickey

Post by Brian Patrie

Post by Kent Dickey
I would be curious to collect KEGS speed data if anyone wants
to report it from various Mac models and Linux machines.

On a 3.5 GHz i7-4770K, under Linux Mint 19.3 (after chasing
a few dependencies (libpulse-dev libx11-dev libxext-dev) to
get it to build).
About 1750 MHz emulation, idling at an AppleSoft prompt.
About 600 MHz emulation, idling in GS/OS 6.0.4 Finder.

Unfortunately, idling at an Applesoft prompt is not a realistic
speed. Applesoft calls a monitor routine to read input, and it
reads the keyboard at $C000 very often--and that always takes one
full "slow" cycle per read, which KEGS tries to make take one
microsecond in real time as well. KEGS is fast enough that it
can do that more than 1 million times per second, so the
effective speed is infinite. KEGS limits its speed to 1.9GHz
currently (or about that), so you're just hitting that limit.
The Finder result is fine--that's a good indication of KEGS
10 SUM = 0
20 FOR I = 1 to 345678
30 SUM = SUM + SIN(I)
40 NEXT
50 PRINT SUM
This will take 10-40 seconds, and the speed shown while it
runs is more indicative of the real speed. It doesn't really
matter what the BASIC code is doing, as long as it doesn't try
to read the keyboard much (and SIN() is pretty slow).
I find KEGS runs Applesoft at about ~95% of the finder speed,
so I expect your Applesoft speed will be about 550MHz if your
Finder speed is 600MHz.

Yup, about 550 Mhz running that (which took about 18 sec).

(The $C0xx i/o slowdown is why i included the Finder figure. But i
should have been less lazy and written a simple i/o free loop. heh heh)

[Jerome Vernet]

Post by Kent Dickey
I compiled KEGS for 10.15, "Catalina". I suspect it won't work on 10.7.

Do not work also on 10.13, that's bad.

JV

[Jerome Vernet]

Post by Jerome Vernet

Post by Kent Dickey
I compiled KEGS for 10.15, "Catalina". I suspect it won't work on 10.7.

Do not work also on 10.13, that's bad.
JV

Got it built and running under 10.13. Don't forget to add all the
libSwiftLibrary dylib in a Frameworks folder inside the app, and use

install_name_tool -add_rpath @executable_path/../Frameworks
./KEGSMAC.app/Contents/MacOS/KEGSMAC

to get them found.

Think that it could be run under at least 10.10 .

JV

[Kent Dickey]

Post by Jerome Vernet

Post by Jerome Vernet

Post by Kent Dickey
I compiled KEGS for 10.15, "Catalina". I suspect it won't work on 10.7.

Do not work also on 10.13, that's bad.
JV

Got it built and running under 10.13. Don't forget to add all the
libSwiftLibrary dylib in a Frameworks folder inside the app, and use
./KEGSMAC.app/Contents/MacOS/KEGSMAC
to get them found.
Think that it could be run under at least 10.10 .
JV

I am interested in fixing this, but I have no idea how to do anything you
are suggesting. Is there documentation on this I can read? Or can you
give more detailed steps?

I could see that when I told Xcode to build for 10.13 (for example), it would
add some .dylib's to Frameworks inside KEGSMAC.app/, but I don't know
how to do that outside of Xcode (which is my preference) and how to
do this in an automatic build process. I don't know how to determine
which .dylibs are not valid for a given older OS and so need to be copied
in to the app. I guess I could just copy everything.

I also haven't looked up how to generate an executable that supports x86_64
and Apple silicon. I used to do this for PowerPC/x86, but that was pretty
clearly documented and easy to do.

Kent

[Jerome Vernet]

Post by Kent Dickey
I could see that when I told Xcode to build for 10.13 (for example), it would
add some .dylib's to Frameworks inside KEGSMAC.app/, but I don't know
how to do that outside of Xcode (which is my preference) and how to
do this in an automatic build process. I don't know how to determine
which .dylibs are not valid for a given older OS and so need to be copied
in to the app. I guess I could just copy everything.
I also haven't looked up how to generate an executable that supports x86_64
and Apple silicon. I used to do this for PowerPC/x86, but that was pretty
clearly documented and easy to do.

Is there any XCode Project for KEGS ?

JVernet

[Jerome Vernet]

Post by Jerome Vernet
Is there any XCode Project for KEGS ?

I made an XCode project for KEGS, it's building, but I need
Mainemenu.nib as an original .nib, not compiled nib. Or even better, as
.xib files (export form Xcode).

JV

[Kent Dickey]

Post by Jerome Vernet

Post by Jerome Vernet
Is there any XCode Project for KEGS ?

I made an XCode project for KEGS, it's building, but I need
Mainemenu.nib as an original .nib, not compiled nib. Or even better, as
.xib files (export form Xcode).
JV

KEGS uses nothing from Mainmenu.nib. I may try to get rid of it altogether
at some point, but for now I use the NIB-based init sequence, so some sort
of NIB file is needed. If you created a new project, XCode created one
for you, so that should just work.

XCode is user-hostile--after much googling and searching, it seems there's
no programmatic way to add/remove files from an XCode project. There are
some programs on the net which claim to do this, but I suspect they
break with every XCode release.

Here are my raw notes on creating an XCode project for KEGS:


Open Xcode
Select "Create a new Xcode Project"

Select macOs->App, then Next
Product Name: Kegs
Org name: Kegs
Language: Swift
User Interface: XIB
Uncheck "Use Core Data", "Include Unit Tests", "Include UI Tests"
Pick the directory to make the .project dir
Uncheck "Create Git repository"
Click "Create"

Delete AppDelegate.swift
Right click on Kegs folder on left side, select "Add Files to Kegs".
Add all *.[csh] *.swift files, and nothing else
Don't create bridging header
Then, click on Kegs icon on left, go to Build Settings, search for
"bridg". Double-click on Objective-C Bridging header, and manually
enter: "Kegs/Kegs-Bridging-Header.h"

Change to the signing tab, and click the tiny 'x' to the right of
the "App Sandbox" settings. If put in a sandbox, KEGS couldn't access
$HOME (and $HOME becomes the directory the App was compiled in).

Kent

[Jerome Vernet]

Post by Kent Dickey
Open Xcode
Select "Create a new Xcode Project"
...

Thanks, it's working (need to remove some .c like to_pro, partls).

JV

[Kelvin Sherlock]

Apple has a very simple universal binary makefile here:
developer.apple.com/documentation/xcode/building_a_universal_macos_binary
which essentially involves compiling and linking twice, then using
lipo to merge them together.

Post by Kent Dickey

Post by Jerome Vernet

Post by Jerome Vernet

Post by Kent Dickey
I compiled KEGS for 10.15, "Catalina". I suspect it won't work on 10.7.

Do not work also on 10.13, that's bad.
JV

Got it built and running under 10.13. Don't forget to add all the
libSwiftLibrary dylib in a Frameworks folder inside the app, and use
./KEGSMAC.app/Contents/MacOS/KEGSMAC
to get them found.
Think that it could be run under at least 10.10 .
JV

I am interested in fixing this, but I have no idea how to do anything you
are suggesting. Is there documentation on this I can read? Or can you
give more detailed steps?
I could see that when I told Xcode to build for 10.13 (for example), it would
add some .dylib's to Frameworks inside KEGSMAC.app/, but I don't know
how to do that outside of Xcode (which is my preference) and how to
do this in an automatic build process. I don't know how to determine
which .dylibs are not valid for a given older OS and so need to be copied
in to the app. I guess I could just copy everything.
I also haven't looked up how to generate an executable that supports x86_64
and Apple silicon. I used to do this for PowerPC/x86, but that was pretty
clearly documented and easy to do.
Kent

-------
ProLine: ***@pro-kegs

[Kent Dickey]

Post by Kelvin Sherlock
developer.apple.com/documentation/xcode/building_a_universal_macos_binary
which essentially involves compiling and linking twice, then using
lipo to merge them together.

Post by Kent Dickey

Post by Jerome Vernet

Post by Jerome Vernet

Post by Kent Dickey
I compiled KEGS for 10.15, "Catalina". I suspect it won't work on 10.7.

Do not work also on 10.13, that's bad.
JV

Got it built and running under 10.13. Don't forget to add all the
libSwiftLibrary dylib in a Frameworks folder inside the app, and use
./KEGSMAC.app/Contents/MacOS/KEGSMAC
to get them found.
Think that it could be run under at least 10.10 .
JV

I am interested in fixing this, but I have no idea how to do anything you
are suggesting. Is there documentation on this I can read? Or can you
give more detailed steps?
I could see that when I told Xcode to build for 10.13 (for example), it would
add some .dylib's to Frameworks inside KEGSMAC.app/, but I don't know
how to do that outside of Xcode (which is my preference) and how to
do this in an automatic build process. I don't know how to determine
which .dylibs are not valid for a given older OS and so need to be copied
in to the app. I guess I could just copy everything.
I also haven't looked up how to generate an executable that supports x86_64
and Apple silicon. I used to do this for PowerPC/x86, but that was pretty
clearly documented and easy to do.
Kent

-------

OK, so they've modified lipo under Big Sur to merge the two executables
together. I'll look into that once I update to Big Sur. I still don't
know how to create an executable to run on older OS'es.

Kent

[Jerome Vernet]

Post by Kent Dickey
OK, so they've modified lipo under Big Sur to merge the two executables
together. I'll look into that once I update to Big Sur. I still don't
know how to create an executable to run on older OS'es.

Seems that you need to build it on an older system...
JV

[mmphosis]

Thanks for the update. I built from source on Linux Mint 20 excluding Pulse
Audio, I don't need sound. dcycs: 182.9 sim Mhz: 2089 Eff MHz:1778.82,
Limit:Unlimite

[Garrett Meiers]

Post by Kent Dickey
It's only been 16 years since the last release, but I was thinking I should
release my current version of KEGS in anticipation of Nox Archaist coming
out tomorrow.

Awesome! Thanks!

[Kent Dickey]

I've updated KEGS, an Apple IIgs emulator for Mac OS X and Linux, to 1.04.
I compiled the Mac version on 10.14, so the executable should run on 10.14+.
I tried to compile it so it would run on 10.13, but I don't have a way to test
that. Let me know if it works. There's a Linux executable as well.

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

As usual, full source code is included.

From the current CHANGES.txt file:

Changes in KEGS v1.04 since v1.03 (01/10/21)
- Paste works from the host to the emulated machine. On the Mac,
select text in another app, do Cmd-C, and then in KEGS select
the Edit menu->Paste. On X11, select the text in another application,
then in KEGS, click the middle mouse button to paste. Up to ~32KB
can be pasted, but I recommend smaller amounts.
- On the Mac, the Config menu item will bring up the Configuration screen
(same as pressing F4).
- Fix bug where Nox Archaist running on 5.25" floppies with fast_disk_emul
on (which is the default) would cause KEGS to halt and not write
modified data back to the disk image. Nox Archaist doesn't read
the entire sector header, waits about 7 disk nibble times, then
writes new sector data. This confused fast disk emulation which
doesn't move the emulated disk position just by waiting. Now, when
a write begins, KEGS will move the emulated disk position.
- Added logpc debugger command in the F7 debugger window. KEGS can keep
track of all registers after each instruction for up to 2 million
instructions. This is dumped out to the file pc_log_out in the
directory where config.kegs was found.
In the debugger window "help logpc" gives basic help. "logpc on"
turns on logging, and "logpc save" writes out the last 2 million
instructions to the file "pc_log_out" where the config.kegs file was
found.
- Reading $C020 and $C030 return a floating bus value. This fixes
Beyond Castle Wolfenstain randomness as reported by Vladimir
Ivanov.
https://groups.google.com/g/comp.sys.apple2/c/3gH0dUpLI3Q/m/JJYnhRYBrY4J

Kent

[awanderin]

Alas, the link on http://kegs.sourceforge.net/ for KeGS v1.04.tar.gz is
invalid.

The 1.03 tarball is valid.

[Kent Dickey]

Post by awanderin
Alas, the link on http://kegs.sourceforge.net/ for KeGS v1.04.tar.gz is
invalid.
The 1.03 tarball is valid.
--
--
Jerry awanderin at gmail dot com

I fixed it. Apparently sftp doesn't support "mput" like FTP does.

Kent

[[e-mail]]

Hi,
I'm trying out KEGS 1.04 on BigSur, but need an idea to switch to fullscreen, I tried the usual suspects F11 and Ctrl + F11. (and more :-) )
I switched off the "F11 - desktop show" under shortcuts inside my system settings.

thanks
Stephan

[Kent Dickey]

Post by ***@vanradecke.de
Hi,
I'm trying out KEGS 1.04 on BigSur, but need an idea to switch to
fullscreen, I tried the usual suspects F11 and Ctrl + F11. (and more :-)
)
I switched off the "F11 - desktop show" under shortcuts inside my system settings.
thanks
Stephan

Just click the maximize button of the main KEGS window (the green circle in
the left title bar).

To leave full screen, move the mouse to where the menu bar would be, and
it will appear, and then you can re-click the green circle to make the
window the usual size again. There is no keypress to enter/exit full
screen on the Mac anymore, the documentation needs updating.

Kent

[[e-mail]]

hm, yes I tried the green button, but didn't realised that the menu bar will appear after a little delay.
(a keypress would be nice)

Thanks
Stephan

[awanderin]

***@provalid.com (Kent Dickey) writes:

This link works
https://sourceforge.net/projects/kegs/files/kegs.1.04/kegs.1.04.tar.gz/download

[Kent Dickey]

I've updated KEGS, an Apple IIgs emulator for Mac OS X and Linux, to 1.05.
The Mac executable should run on 10.13 or later. It's also a universal app,
so it runs native on Apple M1 silicon. There's a Linux executable as well.

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

From the current CHANGES.txt file:

Changes in KEGS v1.05 since v1.04 (01/24/21)
- The Mac executable is now universal, support M1 silicon and x86_64.
- F8 works again to confine the mouse to the KEGS window. Press F8 again
to release the cursor.

As usual, full source code is included. Compiling is easy, just select the
right makefile for your system, and then type "make".

It's slightly more user-friendly to get started--the default config.kegs
file runs NUCLEUS. The user only has to provide a ROM file.

Kent

[Jerome Vernet]

Le 25/01/2021 à 06:08, Kent Dickey a écrit :

Hello

Do not work under 10.13 (Ask for 10.14 at least). But it should work, as
my previous version from your sources was working.


JV

[Kent Dickey]

Post by Jerome Vernet
Hello
Do not work under 10.13 (Ask for 10.14 at least). But it should work, as
my previous version from your sources was working.
JV

I think I have this fixed for the next KEGS release--it should work on
10.13.

Kent