[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Disk ][ Launcher (was: Late night musings...)
- Subject: Re: Disk ][ Launcher (was: Late night musings...)
- From: jefbla@bconnex.net (Jeff Blakeney)
- Date: 1996/09/01
- Newsgroups: comp.sys.apple2
- Organization: Barrie Connex newsserver
- References: <4vn6h8$h60@seeker.the-hermes.net> <Pine.SGI.3.91r.960828085432.8301A-100000@freenet> <502lfq$3jc@pith.uoregon.edu> <504ruq$orh@news.bconnex.net> <5050e1$qum@darla.visi.com>
nathan@visi.com (Nathan Mates) wrote:
>In article <504ruq$orh@news.bconnex.net>,
>Jeff Blakeney <jefbla@bconnex.net> wrote:
>>This is where emulating a piece of hardware, like the Mockingboard,
>>could also be used. Emulate the hardware of the Disk ][ controller
>>and any RWTS routine that accesses the hardware can be handled without
>>a problem.
> I don't supposed you've ever actually done said act of writing an
>emulator for anything, let alone programmed an Apple II at the low
>level? Basically, an emulator emulates _everything_, because it has
>to. Some program hits the memory locations that control/access the
>disk, the emulator _must_ handle it if it wants to emulate anything.
Well, I have been programming Apple IIs in BASIC and Assembly since
1983 and I was programming on other platforms starting in 1981.
I have not yet started coding this emulator that I have been talking
about, but I have been thinking about how I would implement it for the
past couple years. I still hope to start work on this project if no
one beats me to it. :-) I believe it can be done but I certainly
won't say it will be easy and I can't even estimate how well it would
perform.
> On the other hand, the Apple II has no emulators because said
>functionality is done _in hardware_. There is NO way of trapping the
>memory locations that control/access the disk hardware. Emulators have
>the luxury/duty of behaving differently when the hardware is hit. On
>the Apple II, there's no _safe_ way to detect, let alone replace
>hardware accesses in software. [Except, as Neil said, f***ing around
>with a program's source code to find where it hits the disk]
The hardware "emulation" of an 8 bit Apple II that is done by a IIgs
is GREAT. If it wasn't for that backwards compatibility built into
the IIgs, I never would have upgraded my //e and would have moved on
to IBMs. The only thing is, when you use 8 bit programs this way, you
are simply making your IIgs into a slightly enhanced //e.
The driving force behind my wanting an 8 bit Apple II emulator on my
IIgs is so that I can use older programs in a more native way on the
IIgs. Having AppleWorks v3.0 running in a window, possibly under the
Manager, would be fantastic. You would have access to all DAs, inits
and CDEVs. You could also add the ability to paste text to an 8 bit
program by having the emulator send each character to the program as
if you had typed them with the keyboard.
> The fact that emulators work one way does not mean that the real
>computer has a chance of duplicating some functionality in software,
>especially when hardware is involved.
What it comes down to in my vision of this emulator is that, when
possible, always use the actual hardware to do what is needed but when
some new feature is desired or the hardware doesn't physically exist
in the machine, emulate the hardware when possible. This means that a
IIgs that doesn't have a Video Overlay Card (VOC) will not be able to
emulate having a VOC because there is no way to emulate it. But a
IIgs can emulate a Phazor or Mockingboard by using the Ensoniq. It
could even possibly emulate the speech of an Echo Speech Synthesizer,
especially if the IIgs has the ByteWorks Talking Tools installed.
Keep in mind, though, that this emulation of hardware is only
available to 8 bit programs being executed by the emulator.