Date   : Sat, 24 Jan 2004 12:59:52 -0000
From   : tom@...
Subject: Re: BBC Hard Drive Package Update

I've had a think about this this morning. It's something I've wanted 
to do too. I've come up with a header file with some structs and 
function prototypes, but it's not out of the ideas stage really.

What are you planning? From what I remember of how BeebEm works, it 
should be straightforward to come up with something that could work 
with model-b too.

My current ideas include some support for exporting configurable 
settings to the emulator, so that it can generate appropriate dialog 
boxes and config file entries. It doesn't currently include support 
for:

1/ accessing PC devices
2/ devices accessed other than through addresses in the IO area
3/ communication with other installed devices
4/ accessing disk drives
5/ asserting VIA interrupts

So it's hardly complete :) I'd be interested in hearing your ideas.

Thomas Harte has a doc about the new Electrem on the the 'Downloads' 
section of his site:

    http://electrem.emuunlim.com/

It's the 'Electrem Future' download. His system works quite similarly 
to the model-b one, it looks like. I suspect all the C++ would make 
it difficult to put in a compiler-agnostic DLL, so my interface only 
uses C features.

--Tom

P.S. "any part of memory" -- what devices have IO addresses outside 
the 0xFC00-0xFEFF area?

On 24 Jan 2004 at 2:07, Richard Gellman wrote:

> I be many steps ahead of you :)
> 
> The operating model of BeebEm permits a plugin system to be written that 
> can not only map to any  part of memory/system, but can also (if needed) 
> generate its own IRQs and NMIs.
> 
> The plugin support is due for a further release. The next version will 
> be 1.5, which will feature major improvements in the area of graphics 
> stability, sound accuracy, speed calibration, and input resolution (I 
> intend to convert the input system for the keyboard, joystick and mouse 
> to use DirectInput), and possibly also set up a much-requested BBC-to-PC 
> keyboard mapping system.
> 
> The version after (most likely 1.6) will feature an extensive plugin 
> system allowing an extremely flexible hardware configuration.
> 
> Does anyone know if Thomas Harte is still doing the rounds? I seem to 
> remember he was developing a unified Acorn hardware plugin spec. which 
> would allow ElectrEm plugins to be used with BeebEm and vice versa. I 
> can't remember how far he got with this or whether he implemented it.
> 
> -- Richard Gellman
> 
> Jonathan Graham Harston wrote:
> 
> >>Message-ID: <40096192.8000200@...>
> >>    
> >>
> > 
> >Richard Gellman <splodge@...> wrote:
> >  
> >
> >>Hard drive support will be in the next version of BeebEm (due out
> >>spring-ish).
> >>    
> >>
> > 
> >I was just thinking of a long list of other emulated hardware to ask you
> >to consider implementing, when I realised there's a better idea.
> > 
> >At http://www.mdfs.net/Docs/Comp/Spectrum/RISCOS/EmulatedIO is a proposal
> >to allow Spectrum emulators running on RISC OS to pass unknown hardware
> >I/O access to other modules, so then other people could build emulated
> >hardware themselves and "plug" it in.
> > 
> >I'm not too up to speed with Windows DLLs and stuff, but I imagine a
> >similar concept could work with BeebEm and Windows-based BBC emulators in
> >general.
> > 
> >What would be needed is a generally agreed protocol by which a BBC
> >emulator passes hardware access to hardware it doesn't implement itself to
> >other modules to allow them to pick it up. A minimum would be the
> >following:
> > 
> >BBC_Resetting:
> >The emulated BBC is performing a hardware reset. To the emulated hardware
> >this would be like the ~RST signal on the 1MHz bus. Nothing should claim
> >this call.
> > 
> >BBC_IOWrite:
> >The emulated BBC is attempting to write to an address in &FCxx/&FDxx to
> >something that is not emulated by the emulator itself. If an external
> >module can deal with this, claim the call.
> > 
> >BBC_IORead:
> >The emulated BBC is attempting to read from an address in &FCxx/&FDxx from
> >something that is not emulated by the emulator itself. If an external
> >module can deal with this, claim the call, and return a value.
> > 
> >So, if an emulator implements, for instance, a SCSI card at &FC40-&FC43,
> >then access to those addresses would not get passed to the calls.  If
> >nothing claims a read call, then the emulator should assume it has read
> >&FF.
> > 
> >The emulator could even pass through access to addresses in &FExx that
> >aren't implemented by the emulator, so, for example, an external module
> >could emulate a 6854 ADLC at &FEA0-A7.
> > 
> >A more advanced implementation would allow the external emulated hardware
> >to generate 6502 IRQs and NMIs.
> > 
> >  
> >
> 
>