Re: [Atari800-users] Atari800-users Digest, Vol 111, Issue 2

[Chris C. <chr...@gm...>]

On Sun, Jun 20, 2021 at 12:52 PM <
ata...@li...> wrote:

> Send Atari800-users mailing list submissions to
>         ata...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/atari800-users
> or, via email, send a message with subject or body 'help' to
>         ata...@li...
>
> You can reach the person managing the list at
>         ata...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Atari800-users digest..."
>
>
> Today's Topics:
>
>    1. "basic" tatget (Christian Groessler)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 20 Jun 2021 15:20:43 +0200
> From: Christian Groessler <ch...@gr...>
> To: ata...@li...
> Subject: [Atari800-users] "basic" tatget
> Message-ID: <9b6...@gr...>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
> the "basic" target, which doesn't use GUI nor termcap/terminfo, just
> stdin and stdout, would be a good candidate to create automated tests
> for CC65.
>
> For this to work I would need a way to terminate atari800 from within an
> Atari program. (Maybe also an emulator detection would be nice.)
>
> Is something like this already implemented? If not, I would try to
> implement it. Do you have ideas how the "Atari program" <--> "atari800
> emulator" communication should look like?
>
> regards,
> chris
>

Interesting ideas.  I can certainly see these being useful.

However, my immediate reaction is that we'd want to be careful not to
implement something that encouraged the writing of software, for the
emulator, that would misbehave too greatly on a physical Atari.  (I
consider backward-compatibility at least as important as forward-...)  Too,
the very idea of an emulator is that software running on it *should not *be
able to detect that it is running on an emulator rather than a physical
machine, so we would need to be very careful, right from the start in the
design/specification phase, to make it work in a way that wouldn't disrupt
existing software.

That said, I do have a couple of ideas.

First, I seem to remember that on the Atari 800 there were / are a number
of high-memory addresses that didn't dereference to anything -- memory or
hardware -- or which, at the very least, simply accessed the *same hardware
*as a "legitimate" register, but at an unofficial/unsupported address.   I
don't remember whether these "went away" in later models (XL, XE, XEGS,
etc.), e.g. perhaps as a consequence of the added ability to switch out the
OS ROM for RAM -- but if any of them remain, to me it would seem an ideal
solution to simply define a pseudo-register at one of those addresses
which, when accessed, performed one or both of the functions you desire.
"Detect Emulator" would depend upon whether, on a real machine, you could
count on the address to return a known value -- or, at least, *one *of a *small
set *of known values -- when read; if so, we would simply arrange for that
address to return a *completely different *value in atari800.
Unfortunately, this probably eliminates "unofficial addresses that access
the same hardware," because *those wouldn't *deliver a predictable value on
a physical machine.  I think the concept bears consideration, though, if a
suitable do-nothing address can be identified.  "Terminate Emulation" would
then also be quite simple: instead of *reading *the new pseudo-register,
*write *it.  Boom, done.  This register would need to be at an address that
didn't get bank-switched out of the address space, or superseded by
plugging in a device such as e.g. the Black Box.

Second, if no suitable address can be found, perhaps a currently unused
byte value or two could be defined as emulator-specific CPU instructions
which performed these operations.  One of them would be defined as "loads
accumulator with <value> if running under emulation," and another to "exit
emulation."  The problem, though, is that you have to consider what those
"instructions" do when running on a *real *machine -- and arrange for *that
*to happen, even under emulation, in case some software, somewhere, relies
on it.  The obvious solution here is to make the behavior of these
instructions configurable in the emulator.

If no suitable *unused *byte values can be found, or we want to avoid the
slippery slope of being too cavalier about hijacking bytes, perhaps *existing
*instructions can be pressed into service.  Theory suggests that there
"surely must" be a Halt instruction in the 6502; if so, and if it truly
stops the processor from executing any further instructions (including
servicing interrupts), it is the perfect candidate for (when configured)
"Exit Emulator."  "Detect Emulator" is trickier.  The only way I can think
of would be to add a new side effect to some existing instruction.  As long
as we make the behavior configurable, though, we might be able to pull it
off.  Let's say we pick the NOP instruction, and have it (when the behavior
is enabled) set a couple of bits, in the Status register, that can *never
both *be set at the same time on a physical machine, and which of course
the NOP instruction would ordinarily *not affect.*  You could push the
Status register onto the stack, execute a NOP, then compare the pushed
value of the Status register with its previous value.  (Restoring the
original value of the Status register, if needed / desired, is left as an
exercise for the reader!)

Just some thoughts.

Chris