Date : Thu, 07 Sep 2000 16:17:35 +0100
From : James Fidell <james@...>
Subject: Re: yet another BBC emulator? (New MESS BBC emulator will have 8271 d isc support)
Quoting Russell Marks (russell.marks@...):
> I did some minimal hacking on xbeeb 0.3.5 (not quite the latest
> version, it seems, and certainly not now :-), but hopefully not too
> far off?) which might possibly be of interest. Here's what I did (from
> change log entries in the diff I kept):
>
> > + * src/Keyboard.c: changed keyboard support to be set/unset rather
> > + than keeping count of presses/unpresses. This should save needing
> > + the keyboard kludge added earlier, so I've removed that.
Probably good plan.
> > + * src/Bitmap.c: should have been >=312, not >312 (at least, I presume
> > + so - it cured a segfault ;-)).
Yeah, I found that one, too :)
> > + * src/Bitmap.c: kludge to halve frame rate. Seems to be needed to
> > + stop the heavy bitmap output demands from making it painful to use
> > + (even with MITSHM in 8bpp). Still runs at 25 fps in mode 7 though,
> > + to avoid blinking problems there otherwise. :-)
Hmmm. I think I might have done that, too, but I can't honestly recall.
> > + * src/Keyboard.c: kludge to stop it screwing up badly if keys are
> > + let go before being pressed on startup. Note this can still happen
> > + with things like the commonly-bound Alt-Tab, so this needs doing
> > + properly at some point (i.e. should take notice of EnterNotify or
> > + whatever).
Yes, I've found that happening :) It is on my list of things to fix.
> > + * src/KeymapStrict.c: also allow Meta_L/Super/Hyper for Control
> > + key. This means e.g. on Linux/XFree you can use Alt or (on a W95
> > + keyboard) a Windoze key. Also allow Meta_R for shift-lock.
Good plan.
> > + * Now works in 16bpp, as long as you compile without MITSHM
> > + enabled. Which makes it agonisingly slow, of course. :-) Hope to
> > + fix that (at least for 16bpp) soon-ish...
I now have it working in TrueColor as well as 8-bit PseudoColor, with MITSHM.
> > + * Added speed control. I think in some cases it's waiting for two
> > + frames where it should wait for one, but apart from that it seems
> > + to work.
I've put some control in to try to match the emulation speed to "real"
time, though it's a bit gross. Five years ago, working on a 486DX2-66,
running too fast wasn't exactly a problem. On my PIII-733 however, it
was stuffing data at the display so fast that it was tying itself in
knots, so I put in some code to cause a delay in execution every so often.
I also have sound much better implemented than before, although it's still
not as perfect as I'd like.
What I want to do next is to put in support for X11 DGA, so I can take over
the entire X display. I believe that will make it much more responsive.
Unfortunately documentation for DGA seems to be negligible, to the point
where I've considered just doing an SDL interface.
If you want to send me patches and can write a little bit of explanation
on why they're required, I'm more than happy to roll them into the next
release. Feel free to send even the stuff I think I might have fixed,
'cos I could always have cocked it up :)
James.
--
"Yield to temptation -- | Consultancy: james@...
it may not pass your way again" | http://www.cloud9.co.uk/james
|
- Lazarus Long | James Fidell