[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mockingboard emulator (was: Late night musings...)
- Subject: Mockingboard emulator (was: Late night musings...)
- From: jefbla@bconnex.net (Jeff Blakeney)
- Date: 1996/09/01
- Newsgroups: comp.sys.apple2
- Organization: Barrie Connex newsserver
- References: <4vmdd1$dmv@nntp.seflin.lib.fl.us> <27AUG199603215915@vax2.concordia.ca> <500di6$gvu@seeker.the-hermes.net> <504ru0$orh@news.bconnex.net> <5050sm$r6f@darla.visi.com>
nathan@visi.com (Nathan Mates) wrote:
>In article <504ru0$orh@news.bconnex.net>,
>Jeff Blakeney <jefbla@bconnex.net> wrote:
>>The original post of this thread was musings about making an 8 bit
>>Apple II emulator for the IIgs. That way, the IIgs could make 8 bit
>>programs THINK there was a Mockingboard in a slot and route that
>>information to the Ensoniq to produce the sounds.
> A program can NOT make fake hardware on the GS. No way in hell
>you're going to make a mockingboard "appear" in a slot and have
>accesses to that slot be magically routed to the ensoniq via software
>on the GS. The way to do things is to MODIFY the program to hit a
>different piece of hardware. In other words, take it apart, muck
>around with it, and change it. That is a job for a programmer; alomst
>no way you could safely do that "automatically." [You'd have to write
>a program toscan a disk for what looked like Mockingboard code and
>then try and squeeze in alternate code. Not easy, not safe, not
>reliable.]
Perhaps I didn't make my statement very clear. When I'm talking about
emulating an 8 bit Apple II on a IIgs, I'm talking about either
interpreting every opcode of machine language, to watch what the 8 bit
programs are doing, or to simply watch for accesses to certain areas
of memory, like GSBug does although I admit I'm not really sure how
that works.
Basically, when the emulator sees an access in the "virtual slot" that
we wish to make into a "Mockingboard" we check to see what the 8 bit
program is telling the Mockingboard to do and reproduce the same
effect using the Ensoniq. This same technique can be applied to
emulating a 5.25" disk controller which will allow access to a real
5.25" drive or to a disk image file on a hard drive.
>>Besides that, I believe there were patches put out for the Ultimas to
>>allow the Mockingboard music in them to be played through the Ensoniq
>>on the IIgs. This technique could also be applied to other
>>Mockingboard aware software.
> Clue: _PATCH_. In other words, a piece of software that modifies
>the program directly to access the ensoniq _instead_ of the
>Mockingboard. Once patched, it won't access a real mockingboard, even
>if present. As Geoff correctly stated, you need to REWRITE the
>program's sound routines to access the alternate hardware. Said
>patches work _only_ for the software they're patching, nothing else.
Yes, a patch. That is why I said that there were "patches put out for
the Ultimas." This paragraph was made separate from the first to help
distinguish between emulating and patching but I guess it didn't help.
:-/
Yes, you are correct that patching the software will no longer allow
it to access the original hardware but who cares? The reason you are
patching, and I would assume that anyone who does a patch will do so
ONLY on a backup, is to make the program work with the hardware you
HAVE and not the hardware the program wants that you obviously don't
have.
Besides, patching programs, which are far easier and friendlier for
non-hackers to use than a list of locations and bytes, can be written
to undo whatever patching they perform. It just depends on whether
the author of the patching program wants to provide this option or
not.