Re: Whatever happened to the KEGS updates?

[BLuRry <brendan.robert@gmail.com>]

On Apr 6, 8:35 pm, "Christopher G. Mason" <c...@my-deja.com> wrote:
> On 4/6/2010 9:52 AM, schmidtd wrote:
>
> > It sounds like it.  I'd like to get a common, up-to-date, cross-
> > platform build cranked up.  I'd like to contribute, but I'm at a loss
> > as to all the fragmented forks out there.  It would be nice to have
> > the One True KEGS, maintained as cross-platform, in a place everyone
> > knows about (hopefully back on Kent's Sourceforge location, currently
> > unmodified since 0.91).
>
> So far the changes I have made are portable and are based off of the
> main 0.91 code base. I'm using the built in text control panel for
> ethernet and printer settings as KEGS doesn't have any sort of GUI, the
> only change is there are some dependencies that one must have to build
> the printer emulation (Freetype, SDL, and optionally libPNG). The issue
> with providing binaries is I only have a Windows build environment set
> up. I do have a Powerbook running OS X 10.5 I could use for building on
> OS X but nothing for Linux or any *NIX for that matter. Long term I
> would like to move to a cross platform library and implement a GUI, the
> text control panel menu is a bit limited in what it can do. Something
> like wxWidgets would work well as it also handles some low level stuff
> like printer dialogs.
>
> Regarding the forks, Kent hasn't updated KEGS in several years now and
> besides the KEGS32 port with minimal GUI, none of the other forks I have
> found use the latest 0.91 code base (KEGS-SDL, CasaGS, etc.) It also
> doesn't help that creators of some of those forks never bothered to
> release their code (CasaGS for example). There is no version management
> system (SVN/CVS) setup for the code base and as it stands, the code is
> kinda messy when it comes to platform specific stuff (lots of #indefs
> for sound and serial support).

One idea I had, and by all means call me a total loony if you will, is
to write the UI using -- well -- Applesoft, perhaps with beagle bros
extensions to add graphics or "print" to hires.

For one thing, it is really easy to write menus in applesoft.  It's
also very easy to add new features as long as you're not shooting for
overly-sophisticated.

How?  Well, here's an algorithm I came up with, but have been kicking
around if I'll actually do it.

1) When it's configuration time, insert a phantom configuration
device, put it in a slot and have it watch the I/O ports for activity
2) Swap out some or all of the active memory with a completely scratch
page of ram so you can resume emulation where you left off
3) Backup stack, stack pointer, flags, processor regs, etc, and most
importantly softswitches.  (Or if you're lazy and the emulation
supports it, suspend the active CPU and swap it out with a different
instance)
4) Dump your configuration program wherever the hell you want it to
run from -- it's your own scratch ram.  Execute it as appropriate.
5) Configuration program pokes to the I/O ports to indicate
configuration changes.  You can pick up the values and handle them in
your high-level language as desired.  More advanced things like disk
image selection should just be some sort of action trigger that is
handled by a native file selector widget (if possible)
6) Persist the configuration values when the user exits
7) Suspend the CPU and Reverse steps 2 and 3.  Reconfigure active ram/
rom, softswitches, etc.  (in short: restore emulation state)
8) Remove the phantom configuration device so it doesn't interfere
with emualtion
9) Resume the CPU

Side note: What did you expect from someone who reads Nibble articles
like "Split personality" with great interest as a kid?!  You could
also do something less cool but equally effective by suspending the
CPU and backing up the video softswitches' state and video ram -- then
implement your own UI that renders itself to RAM and acts like an
apple program.

-B