Interested in writing plug-ins for AppleWin?

Interested in writing plug-ins for AppleWin?

Post by Michael Beursken » Tue, 09 Jul 1996 04:00:00



What about Mockingboard support?

I think the printer emulation shouldn't be too hard to do. All you have
to do is catch the codes the apple sends to its parallel port (PR#1) and
translate them into Windows GDI-calls (on a pixel-by-pixel basis). The
only printer I know of being supported in about all apple-programs is an
Epson.

Some more features:
* Change each color individually (the apple only supports few colors so
you could adjust them)
* Make the window resizable and give us full-screen-support (easy with
direct-X, I just lack the SDK)
* Add support for 3,5" floppies (there WAS something like that on the
apple)
* Add hot-keys, especially for disk-changing (What about CTRL+F1=Disk1,
and so on to disk 12?) This would be useful, especially for the bigger
games
* Give the user a way to turn the toolbar off.
* Implement a screen smoothing technic (The PC employs HiRes-Graphics
1024x768, as opposed to the apples 280x? screen)
* What about a way to start individual files from a disk (A way to open
apple-disks in Windows explorer would be nice too!)
* Enhance the on-line-help (List of AppleDos R3.3-Commands)
* Let users adjust the disk-speed like the CPU-speed (using a slider)
* Implement an easy screen-capturing-tool
* Implement those data-exchange buttons

Michael

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Mike O'Bri » Wed, 10 Jul 1996 04:00:00


I'm working on a plug-in architecture for AppleWin and I'd like to know
whether there are people out there that are interested in developing plug-ins.
A plug-in is essentially a DLL that you put in the AppleWin directory, which
automatically extends the capabilities of AppleWin.

Some that I'd like to see:

CLOCK CARD
This one would probably very straightforward as long as you have access to a
ROM image and technical info.

MOCKINGBOARD
Not easy, but highly requested.

HARD DRIVE VOLUME
Preferable supporting existing hard drive volume formats from other emulators,
to allow users to easily share data between emulators.

DIRECT HARD DRIVE ACCESS
Harder to implement but ultimately a much cooler feature.  Instead of making a
big file that is a hard drive within a hard drive, just let the user access
his own PC hard drive from within the emulator.  Technically, you need to trap
ProDOS calls and emulate them on the PC side.  The zaniWok emulator on the
NeXT does this.

PRINTER SUPPORT
Another feature everyone wants.  To do it right, you need to emulate not only
the printer port but also the printer itself.  After all, no one wants to hook
up an old Epson dot-matrix printer to their PC.  So the right solution (IMHO)
is to buffer up a page worth of Epson commands and then convert it to Windows
GDI commands and send them to the default printer in Windows.

NEW DISK IMAGE FORMATS
As you can see from aw_image.cpp, the AppleWin disk architecture is very
modular, so adding new disk formats is easy.  The format I would currently
most like to see added is ".gz".  This would save users from having to unzip
everything they download from Asimov, and would save everyone a lot of disk
space.  For purposes of expediency and emulation speed it would probably be
best to treat all ".gz" disks as write-protected.

OTHERS
Post your ideas here.

Before signing up to develop a plug-in you should:
1. Be proficient in C or C++ as well as the Win32 API, and have access to a
compiler.
2. Make sure you have access to the technical information you will need.
3. Be able to dedicate enough time to the project to get a test version up and
running in the next few weeks.

We need to work in together on this.  After all, I don't want to release a new
version of AppleWin with plug-in support, only to find out later that the
plug-in you're developing needs access to something which is not available in
the plug-in programming interface.

If you are interested, post a follow-up to this message.

Mike

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Steven Hu » Wed, 10 Jul 1996 04:00:00



>MOCKINGBOARD
>Not easy, but highly requested.

You could use the MIDI device for sound; that wouldn't be too hard.

Here's one I want:

APPLEAMBIANCE(tm) ;-)

Makes that comforting "thpt-thpt-thpt-thpt" sound upon booting an image, the
nails-on-chalkboard head seek sound when going from track to track, and the
ghastly buzzsaw sound when you get an I/O error.

Steven Hugg

http://pobox.com/~hugg

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Robert Holm » Wed, 10 Jul 1996 04:00:00



>I'm working on a plug-in architecture for AppleWin and I'd like to know
>whether there are people out there that are interested in developing plug-ins.
>A plug-in is essentially a DLL that you put in the AppleWin directory, which
>automatically extends the capabilities of AppleWin.

Mike,

I'm not a programmer, just a fan of your program.  But I guess this
message clarifies something you mentioned last year.  I take it you
will continue development of AppleWin?  Thats great!

Robert

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Josh Silv » Wed, 10 Jul 1996 04:00:00


: CLOCK CARD
: This one would probably very straightforward as long as you have access to a
: ROM image and technical info.

        I've been waiting for clock card support. ProDOS compatible.

: HARD DRIVE VOLUME
: Preferable supporting existing hard drive volume formats from other emulators,
: to allow users to easily share data between emulators.

: DIRECT HARD DRIVE ACCESS
: Harder to implement but ultimately a much cooler feature.  Instead of making a
: big file that is a hard drive within a hard drive, just let the user access
: his own PC hard drive from within the emulator.  Technically, you need to trap
: ProDOS calls and emulate them on the PC side.  The zaniWok emulator on the
: NeXT does this.

        ApplePC does nice hard disk emulation by shrinking and expanding
the .hdv file as needed. That seems like the nicest solution. Direct
access to the PC's hard drive sounds like trouble. People use disk
compression and crazy device drivers for their drives and you need pretty
low level HD access for that sort of thing. Also, how can someone save an
Apple file with the current 8.3 filename format? Win95 long filenames?
What about the 32 MB limit on ProDOS volumes? Don't start patching
ProDOS... (Is that the limit on ProDOS volumes, by the way?)

: PRINTER SUPPORT
: Another feature everyone wants.  To do it right, you need to emulate not only
: the printer port but also the printer itself.  After all, no one wants to hook
: up an old Epson dot-matrix printer to their PC.  So the right solution (IMHO)
: is to buffer up a page worth of Epson commands and then convert it to Windows
: GDI commands and send them to the default printer in Windows.

        I'd recommend just emulating an Epson APL on lpt1: and letting
the user put whatever printer they want off that. Most decent new
printers emulate Epson commands and such.

: NEW DISK IMAGE FORMATS
: As you can see from aw_image.cpp, the AppleWin disk architecture is very
: modular, so adding new disk formats is easy.  The format I would currently
: most like to see added is ".gz".  This would save users from having to unzip
: everything they download from Asimov, and would save everyone a lot of disk
: space.  For purposes of expediency and emulation speed it would probably be
: best to treat all ".gz" disks as write-protected.

        .dsk files are somewhat space inefficient but I can live with
that. Adding support for .gz will introduce speed delays. Hard disk space
is cheap enough to hold 143k files and not sacrifice speed.

: OTHERS
: Post your ideas here.

        Mouse card support? (You'll find this is similar to the clock card
support because both require using interupts.)

        I'd like to help in the developement, but I have very little
Windows programming experience. I do know DOS C though. Anything I can do to
help?

 
 
 

Interested in writing plug-ins for AppleWin?

Post by MMun » Wed, 10 Jul 1996 04:00:00


: Also, how can someone save an Apple file with the
: current 8.3 filename format? Win95 long filenames?
: What about the 32 MB limit on ProDOS volumes? Don't
: start patching ProDOS... (Is that the limit on ProDOS volumes, by the
way?)

Actually, this is quite easy to do (I've done it for the Macintosh). You
patch into the MLI jump vector and process the commands you want (you can
optionally allow Prodos to handles commands you don't want, ie. buffer
management, interrupt handling).

The trickiest part of the whole deal is building the directory structure
(when a directory is "opened") based on the native structure. The 32MB
limit is not really an issue if you are patching calls to
Open,Close,Read,Write. For GetInfo calls, if the size is greater than 32MB
(ie for volume info), then you just limit it to 32MB (as far as the Apple
II product is concerned).

For DOS, it might be tricky to support only 8 characters (instead of 15),
but under Windows95, that shouldn't be an issue.

Likewise, a patch to Prodos would allow you to support any Prodos-based
clock.

Integrating the Apple II environment into the native environment is a big
plus.

Mark Munz
Puppy Dog Software

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Glynne Tol » Thu, 11 Jul 1996 04:00:00



>DIRECT HARD DRIVE ACCESS
>Harder to implement but ultimately a much cooler feature.  Instead of making a
>big file that is a hard drive within a hard drive, just let the user access
>his own PC hard drive from within the emulator.  Technically, you need to trap
>ProDOS calls and emulate them on the PC side.  The zaniWok emulator on the
>NeXT does this.

How about the ability to plug in SCSI (or IDE) hard drives into the PC that
were formatted on an Apple II and read and write to them?

Clock support would be nice.  I think a No Slot Clock emulator would be best,
as it will not take up another slot.

Serial emulation that works.  <grin>

Oh Memory expansion support (as in AE Ramworks card).

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Mike O'Bri » Thu, 11 Jul 1996 04:00:00



>    ApplePC does nice hard disk emulation by shrinking and expanding
>the .hdv file as needed. That seems like the nicest solution. Direct
>access to the PC's hard drive sounds like trouble. People use disk
>compression and crazy device drivers for their drives and you need pretty
>low level HD access for that sort of thing. Also, how can someone save an
>Apple file with the current 8.3 filename format? Win95 long filenames?
>What about the 32 MB limit on ProDOS volumes? Don't start patching
>ProDOS... (Is that the limit on ProDOS volumes, by the way?)

Let's remember that we're talking about Windows here, and the key to Windows
is device independence.  You don't directly read/write the user's hard
drive, so you don't worry about whether it is compressed, etc.  You simply
translate ProDOS "read file" commands into Windows "read file" commands,
ProDos "directory" commands into Windows "directory" commands, etc.

Yes, this would involve dynamically patching or trapping a ProDOS function,
specifically the machine language interface function (MLI) at $BF00.  And
the problem with that is...?  Did you know that AppleWin already dynamically
patches ProDOS every time you boot a ProDOS disk?  (It removes the stepper
delay, drastically speeding up disk access.)

Quote:>    I'd recommend just emulating an Epson APL on lpt1: and letting
>the user put whatever printer they want off that. Most decent new
>printers emulate Epson commands and such.

Again, I pretty much totally disagree.  Windows programs should be device
independent.  Windows doesn't even have a programming interface for sending
commands to the printer; instead it has programming interfaces for things
like drawing text, lines, bitmaps, etc.  The printer driver is responsible
for converting these into appropriate printer commands.

Quote:>    .dsk files are somewhat space inefficient but I can live with
>that. Adding support for .gz will introduce speed delays.

Yes, speed delays on the order of a fraction of a second every time you
insert a new disk.  If you can't stand that type of delay then you can keep
your disk images in one of the other formats.  But that doesn't mean that
having support for the .gz format is a bad thing.

Mike

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Mike » Thu, 11 Jul 1996 04:00:00




> >MOCKINGBOARD
> >Not easy, but highly requested.

> You could use the MIDI device for sound; that wouldn't be too hard.

Well, not easily, unless you have the ability to software-digizize and
play-back via MIDI.  Most Midi boards are defined for a standard set
of musical instruments, and as such, are not sutiable for on-the-fly
wavefore generation. Would be much better to use the WAV-file or
FM-synthesis (Which I belive the Mockingboard was) sound facilities of
Windows.

Mike B.

> Steven Hugg

> http://pobox.com/~hugg

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Josh Silv » Fri, 12 Jul 1996 04:00:00


: : Also, how can someone save an Apple file with the
: : current 8.3 filename format? Win95 long filenames?
: : What about the 32 MB limit on ProDOS volumes? Don't
: : start patching ProDOS... (Is that the limit on ProDOS volumes, by the
: way?)

: Actually, this is quite easy to do (I've done it for the Macintosh). You
: patch into the MLI jump vector and process the commands you want (you can
: optionally allow Prodos to handles commands you don't want, ie. buffer
: management, interrupt handling).

: The trickiest part of the whole deal is building the directory structure
: (when a directory is "opened") based on the native structure. The 32MB
: limit is not really an issue if you are patching calls to
: Open,Close,Read,Write. For GetInfo calls, if the size is greater than 32MB
: (ie for volume info), then you just limit it to 32MB (as far as the Apple
: II product is concerned).

: For DOS, it might be tricky to support only 8 characters (instead of 15),
: but under Windows95, that shouldn't be an issue.

: Likewise, a patch to Prodos would allow you to support any Prodos-based
: clock.

: Integrating the Apple II environment into the native environment is a big
: plus.

: Mark Munz
: Puppy Dog Software

        This idea doesn't thrill me. I like the idea of having the emulated
hard drive seem like a real HD to the emualtor. What if I want to run a bad
block check or write crazy programs in assembly that access the Apple HD
without using standard ProDOS calls? Or even format the HD? As I said earlier I
think it also introduces the possibility of the PC side getting corrupted by
some crazy 1980 Apple program deciding to go nuts.
        I have seen Executor use the PC's HD and it seems to work OK, but I
like the way ApplePC does it by making a .hdv file that on the Apple side
always reads 32MB total but only takes up the size it really needs on the PC
side as a DOS file. If you're concerned about file transferring, write some
utility to do it or build it into the emulator but why bother making the HD
shared with the PC?
        Patching ProDOS to allow a clock to work is fine, but let the user do
that not the emulator.

Later...

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Llam » Fri, 12 Jul 1996 04:00:00



>I'm working on a plug-in architecture for AppleWin and I'd like to know
>whether there are people out there that are interested in developing plug-ins.

BRAVO!!! While the other emulators work well, there is a certain
elegance to AppleWin that is very appealing.

Quote:>Some that I'd like to see:
>PRINTER SUPPORT
>Another feature everyone wants.  To do it right, you need to emulate not only
>the printer port but also the printer itself.  After all, no one wants to hook
>up an old Epson dot-matrix printer to their PC.  So the right solution (IMHO)
>is to buffer up a page worth of Epson commands and then convert it to Windows
>GDI commands and send them to the default printer in Windows.

Most modern PC printers that aren't laser printers have epson
emulation built in. I've been using AppleWorks on my Trackstar Plus
(and SimIIe) with the Epson FX or RX (I forget) commands, and my
Cannon BJ200ex knows exactly what to do. Similarly, I tell TimeOut
SuperFonts that I have a BubbleJet 130 (I think that's the only BJ
there was at the time) and it works too. Laser printers, of course,
would be a different situation altogether.

Anyway, as for suggestions:
MODEM/SERIAL/SLOT2 SUPPORT
Let the emulator map out a Super Serial Card with the jumper block set
up as a modem connector to one of the PC COM ports. For hooking up
modems, of course. Maybe not 28.8 modems, mind you, but something
slower would be nice.

"FTP" IN AND OUT OF APPLEWIN HARD DRIVE
SimIIe has a nice little program that works just like the command line
UNIX ftp program to get and put files into and out of SimIIe's hard
drive volume. Very handy for moving LOTS of files between platforms.
How about the windows equivalent?

Virtually,
Warr

------------------------------+---------------------------------------

"Using Netscape in Windows95" | http://www.deltanet.com/users/wernst/
"Netscape Unleashed"(contrib) | Computer Consultant, Technical Writer
Que and SamsNet Publishing    |         Graphic Artist, Nerd
------------------------------+---------------------------------------

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Llam » Fri, 12 Jul 1996 04:00:00




>Clock support would be nice.  I think a No Slot Clock emulator would be best,
>as it will not take up another slot.

The NoSlotClock requires a patched version of ProDos. Take it from
someone that has an NSC: keeping track of which disks have the patch
and which don't is a real pain in the ass.

Quote:>Oh Memory expansion support (as in AE Ramworks card).

YES YES YES YES YES YES!!!!!! Or in the form of a slinky type memory
card. In fact, I would think the slinky support would be easy - make
it like a 1 meg ram disk that id's itself as memory to those programs
that can use it (like proterm and appleworks). Of course, this would
take up a slot)

Virtually,
Warr

------------------------------+---------------------------------------

"Using Netscape in Windows95" | http://www.deltanet.com/users/wernst/
"Netscape Unleashed"(contrib) | Computer Consultant, Technical Writer
Que and SamsNet Publishing    |         Graphic Artist, Nerd
------------------------------+---------------------------------------

 
 
 

Interested in writing plug-ins for AppleWin?

Post by James R. Iv » Fri, 12 Jul 1996 04:00:00



Quote:>"FTP" IN AND OUT OF APPLEWIN HARD DRIVE
>SimIIe has a nice little program that works just like the command line
>UNIX ftp program to get and put files into and out of SimIIe's hard
>drive volume. Very handy for moving LOTS of files between platforms.
>How about the windows equivalent?

Even better... A disk image explorer.  Drag and drop in and out as
many files as you like.  From DSK to DSK or DSK to hard drive!
 
 
 

Interested in writing plug-ins for AppleWin?

Post by MMun » Fri, 12 Jul 1996 04:00:00


Quote:> What if I want to run a bad block check or write crazy programs
> in assembly that access the Apple HD without using
> standard ProDOS calls? Or even format the HD?

The trick is not to turn the old read/write mechanisms into calls for your
hard drive, but to provide a Prodos-based way of accessing your hard
drive.

Any block-oriented calls would return an error. That would leave the
standard file manipulations, which any Prodos-based application could take
advantage of. While using this method, you would not try to read/write
using the softswitches to turn on the motors, etc.

I've actually written an emulator that runs AppleWorks on a Macintosh (
Deja ][ ) using this approach and it works quite well. For Mac people, it
allows you to store your files on any type of Mac-compatible media as
files. And because PCExchange is part of all new Mac systems, you can
read/write Prodos files to Apple II 3.5 disks.

Obviously this solution does not meet everyone's need. It is not a
solution for DOS 3.3 program users.

My point, however, was that it is quite doable to support Prodos on a
native file system.

Mark Munz
Puppy Dog Software

 
 
 

Interested in writing plug-ins for AppleWin?

Post by Glynne Tol » Fri, 12 Jul 1996 04:00:00





>>Clock support would be nice.  I think a No Slot Clock emulator would be best,
>>as it will not take up another slot.

>The NoSlotClock requires a patched version of ProDos. Take it from
>someone that has an NSC: keeping track of which disks have the patch
>and which don't is a real pain in the ass.

You must live off floppies (ich!).  If you are booting off a hard disk (in
this case we need some HD support in AppleWin) then you are always booting the
same version (patched) of ProDOS.  No biggie.  Like I said, solves the slot
problem.  It would be nice to have a configurable slot setup, though.  Here is
a list of slot people are asking for:
 SLOT   FUNCTION
   1       Printer (serial or parallel card)
   2       Modem/Serial card
   3       80 column card (not useable for anything else)
   4       Mouse or Mockingboard or Clock card
   5       ?  (3.5" drive?)
   6       5.25" Floppy
   7      Hard Drive

Seel, there is more cards then slots.  In listing this I also thought of
another idea.  The HD volume support should support Smartport for the ability
of supporting more then 2 drives in ProDOS.  Yeah, I know, a bit much for an
emulator!