Date   : Fri, 18 Jun 2004 15:42:15 +0000
From   : Jules Richardson <julesrichardsonuk@...>
Subject: Re: Fragmented Emulators was RE: BeebEm under

On Fri, 2004-06-18 at 14:52, peter.3.edwards@... wrote:
> > Maybe there's too many options in terms of hardware spec to 
> > consider it
> > though? What minimum hardware spec works for one person 
> > doesn't work for
> > another. 
> 
> Not sure what you mean here.  I thought the great advantage of the 80's 
> home computer market was the standard hardware.  There's only one BBC B.  
> Only one BBC B+.  Only one Master 128 etc.  If you mean how you would 
> choose to have say a 6502 co-processor emulated or not, I couldn't be sure 
> off the top of my head, not being a MESS driver developer but I'm fairly 
> certain the way to do it is to add another driver.  

Sorry - just to clarify, I meant modern hardware. I mean, do you assume
everyone has display hardware capable of 24 bit mode, or just 8 bit? Do
you make the assumption that target hardware has a something other than
a simple speaker for making noise?

My natural instinct would be to define strict software interfaces at the
I/O boundaries, for things like video, keyboard input (and indeed BBC
hardware ports - Tube, 1MHz bus etc.). 

Then each platform / configuration needs its own bit of driver code,
loaded at runtime, to do the I/O work - e.g. in the case for video, some
code on Linux to talk to a 24 bit framebuffer, perhaps a different bit
of code to talk to an 8 bit framebuffer (although doubtless those two
are sufficiently similar to be combined), and on Windows on a PC some
code to talk to Windows' graphics layer.

Of course, 

 a) I've never written an emulator. 
 b) That sort of flexibility comes at a price in terms of performance,
requiring faster hardware to run - although the abstracted OS-specific
driver approach does allow code to use native OS routines for things
such as display.

Presumably one writes an emulator by not only emulating the CPU, but the
system clock too (i.e. everything occurs according to some master clock
signal)? Therefore speed isn't an issue providing everything that needs
doing on the modern hardware gets done within one emulated clock cycle?

How that works when you are also emulating timing-critical devices (such
as Econet, or something hanging off the 1MHz bus or Tube) I don't know.
Now I'm going to drive myself nuts thinking about it :-)

cheers

Jules