Date : Sat, 21 Nov 2009 19:21:41 +0000
From : mfirth@... (Michael Firth)
Subject: Is there a 65Tube-style BBC emulator available
Steven Flintham wrote:
> On Fri, 2009-11-20 at 20:35 +0000, Michael Firth wrote:
>
>> Apologies to anyone who downloaded the archive I uploaded earlier, there
>> were a couple of problems with it.
>>
> [...]
>
> Hi Michael. I did give this a quick go not long after you posted it and
> it seemed a bit unreliable, so maybe this was the problem. I put it to
> one side meaning to go back to it later so I didn't investigate the
> problems in any detail.
>
>
I've now uploaded a new version that fixes a few bugs in the 6502
emulation (though I think at least one
remains, as my suggested test program doesn't work right)
It also (probably more importantly) adds some error handling to the
startup, to give you a syntax message
if you start it with no arguments, and various other sanity checks that
were missing.
I guess I should have done that before dumping my "work in progress"
code from 15 years ago on the Internet!
>> I'll try and rediscover how the code operates enough to fix some more of
>> the problems in the next few days.
>>
>
> Obviously, if this has revived your interest in this code, go ahead. But
> please don't do it on my account! I think there's potential here for a
> 65Tube-ish emulator, but just playing around with it earlier made me
> realise that such an emulator is not quite as trivial as I'd thought.
>
Its given me an attainable target to try and get this application to
reach, that of a CLI 6502 Tube emulator.
When I first wrote it, typical Linux / Unix CPU speeds were slow enough
that there wasn't much point in that, as the emulated CPU from
non-optimised C code would probably have been slower on a 50MHz 486 than
the real CPU on a Beeb.
These days, with 3GHz+ CPUs, I suspect that an un-limited 6502
instruction processor will run a lot faster than a real Beeb, allowing
this to be used as effectively a very fast 2nd processor to a BBC over a
serial port, for example.
> I guess I didn't realise how much 65Tube (presumably) benefits from
> running on top of RISC OS, which really is quite BBC MOS-like. To take a
> trivial example, I wanted to *EXEC my source code into the emulator -
> oops, that doesn't work, because it just gets passed through to the
> shell. So the OS emulation needs to be clever enough to trap things like
> that. Not a massive deal in itself, but annoying.
>
>
The new version has a stub of an improvement in this area - now *
commands are processed in the app. Currently it only does "*HELP",
"*QUIT" and "*UNIX". (as a passthrough to a bug-fixed version of what it
did before)
My plan is to implement versions of the most common OS commands, as a
minimum, I'll aim to do *LOAD, *SAVE, *RUN, *EXEC, *TYPE, *DUMP and
*SPOOL (probably in that order, as I think that's roughly the order of
difficulty)
> The other thing that strikes me as a bit tricky is handling Escape. In
> 65Tube this just works, either because they were clever or because RISC
> OS is BBC-like. But in a naive getchar()-style emulator, you have to do
> Escape then Return (I think, and I'm not sure that will always behave in
> a truly BBC-like way). It doesn't sound much, but I think that could get
> annoying pretty fast. I'd also like to handle Escape properly in the BBC
> code I'm writing, so I'd like the emulator to be 'realistic' in this
> regard.
>
>
That's also on my list. With a lot more years of C coding under my belt
than when I first wrote this, I think I can probably get a much better
implementation of the "Escape" handling than the very dumb hack I
currently have.
My initial thought is to do the programmatic equivalent of "stty intr
^[", to get a Unix SIGINT from the Escape key, which I can then use to
generate a BBC-like Escape behaviour. The only problem is it will mean
you can no longer exit the program using "Ctrl-C", but I may be able to
find a way around that too...
> Maybe I'm exaggerating the difficulties, I have been known to do
> that. :-) Just trying to get something running 'natively' does make me
> appreciate the rpcemu+65Tube approach a bit more though.
>
>
One other big benefit you'll probably get from the RPCEmu layer is some
emulation of BBC Graphics, which may or may not be relevant to your
application. I'm not sure there's an easy way around that problem, short
of writing a full BBC Emulator, and then you might as well use BeebEm.
> Steve
>
>
Thanks for the feedback, I'm frankly astonished that at least 2 people
other than me consider that this might be vaguely useful for something!
Regards
Michael