Date   : Sat, 24 Jan 2004 02:07:44 +0000
From   : Richard Gellman <splodge@...>
Subject: Re: BBC Hard Drive Package Update

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.
> 
>  
>