Re: Whatever happened to the KEGS updates?

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

> maybe KEGS.CFG.TXT would look like this:
>
> SPEED = NORMAL
> SLOT6 = SMARTPORT
> PRINTER = EPSON
> SERIAL = 300 BAUD
>
> or should it be raw data?
>
> 1234

Raw data is best on the applesoft side, but the danger of storing raw
values is that it makes it hard to understand or fix things outside
the emulator.  My thoughts are if you use a text file, it should be
readable as a text file.  As for the I/O part, it's really to simplify
the overhead of the glue between the emulated code and the back-end so
that you don't have to get too deep in the muck, so to speak, on the
user interaction side.   You could have the I/O regs such as:

reg 0: latch/commit (poke 0 to start latching data, poke 255 to
commit)
reg 1: action (0=load config, 1=store config, 2=select file)
reg 2... could be used to provide sub-details (say, specifying what
file type is being selected)

Of course other funny tricks could be employed, such as having
configuration being written to a region in memory as text with a
custom amp &print routine to append strings to a memory buffer, and
when configuration is loaded, that region is filled by the back-end
and read with a &read routine that works like the applesoft one only
parsing against the memory buffer.  That would work for having the
emulated side directly spit out values, but that would require a well-
defined format to prevent breakage:

category,option,option...
category,option,option...

And when EOL is encountered, the program should get an empty string
back to signify there is no more data for that category

slot1,grappler+,pngEnabled
slot2,internal,tcpEnabled,port6502 <or, alternatively>
slot2,internal,comEnabled,portCom1

dunno... maybe there is an even more sane approach than this, but it
would still be funny to see applesoft in the mix just for grins.  I
concede that the hybrid approach is probable the most sane route, but
last I checked sanity was NOT a prerequisite for developing an
emulator.  :-D

-B