ProDOS Emulator v0.1 in incoming on ftp.asimov.net
Matthew Ghio
Prodosemu combines 65C02 processor emulation with an operating system
emulator to translate ProDOS MLI calls to native unix calls. Prodos
applications run directly from your unix filesystem, with no need to
create disk images. Simply create a subdirectory, place your ProDOS
system binaries in it, and run them with Prodosemu.
When Prodosemu is run, the current directory (or another directory that
you specify with the -r option) becomes the root of a simulated prodos
filesystem, mounted as /UNIX on slot 7, drive 1. The named application
is loaded into a virtual machine at $2000 and executed by a simulated 65C02
processor. As files are read and written by Prodos applications to the
simulated filesystem, they are read and written to the corresponding
directory in your unix filesystem. Prodos-specific filetype information
is stored in a .prodosdir file, which is automatically created in each
directory if it does not already exist. Filetypes are ignored by Prodosemu
when launching applications.
To launch a prodos application, just type 'prodos' and the application name,
at your shell prompt, for example,
prodos BASIC.SYSTEM
will launch Applesoft Basic. Type CAT,S7,D1 to see the files in your
directory. Remember that Prodos filenames are UPPERCASE and limited to 15
characters. (Prodosemu actually does allow you to create and access
filenames longer than 15 characters, but only those filenames 15 characters
or less will show up in directory listings. This is due to the fact that
Prodos's directory entries have a fixed size buffer which can only hold 15
characters.) When you are finished with basic, type BYE to return to the
unix shell prompt.
If you have ShrinkIt, you can use it to unpack software by typing
prodos SHRINKIT.SYSTEM
This will unpack file archives and set all the filetypes correctly.
You do not need a copy of ProDOS to run Prodosemu. You will need a copy of
the Apple IIe's ROM to run most applications. The rom file is a copy of the
data from $C100 to $FFFF and should be placed in the file apple.rom in the
directory you launch Prodosemu from.
Prodosemu will work with all ProDOS applications except those which attempt
to read or write the disk at the sector level. I haven't tried it on any
systems other than Linux, but it shouldn't be hard to port. Source code is
free. The current version supports text modes only (no mousetext).
Let me know if you find any bugs, and/or tell me of applications that you
ran successfully.
Matthew Ghio
>In article <4css...@news.alias.net>, gh...@netcom.com (Matthew Ghio) says:
>>Announcing ProDOS Emulator v0.1 for Linux
>>Prodosemu combines 65C02 processor emulation with an operating system
>>emulator to translate ProDOS MLI calls to native unix calls. Prodos
>>applications run directly from your unix filesystem, with no need to
>>create disk images. Simply create a subdirectory, place your ProDOS
>>system binaries in it, and run them with Prodosemu.
>
>based systems? Sure beats having to worry about making disk images!
>I could just modem them over to my pc!
Well, most systems that can run MS-DOS can also run Linux...
The main problem with doing this on a dos filesystem is the 8.3 filenames,
while prodos's are 15 characters. You'd have to have something which
creates a hashed name that will fit into 8 characters and then maintains a
database of prodos->msdos filename mappings. It would work, but you'd lose
some of the transparency of it. (Of course umsdos does that too...)
Other than that, the code should be fairly easy to port, it's all written
in C. Essentially, you would want to compile the prodos.c part and patch
it into an emulator like ApplePC. (I'm not exactly sure how you'd do that
tho, I haven't looked at the ApplePC source code - actually I don't know
where to get it.)
With as86/ld86, I think the linux gcc can build a dos .exe (I've never
tried it tho, does anyone here know how to do it?)
The current release of Prodosemu is mostly a 'proof-of-concept'
distribution, as I didn't implement high-res graphics (Appleworks runs
great tho, and I think it is neat to be able to run Shrinkit on your ISP!)
In future releases I plan to include the graphics code (console + X) from
some of the other Linux-based Apple II emulators.
Romeo
>Announcing ProDOS Emulator v0.1 for Linux
>Prodosemu combines 65C02 processor emulation with an operating system
>emulator to translate ProDOS MLI calls to native unix calls. Prodos
>applications run directly from your unix filesystem, with no need to
>create disk images. Simply create a subdirectory, place your ProDOS
>system binaries in it, and run them with Prodosemu.
That's an EXCELLENT idea! Is there a way to port that program to DOS
based systems? Sure beats having to worry about making disk images!
I could just modem them over to my pc!
Romeo
Lim Thye Chean
I second that! Either DOS or Windows will be really welcome!
Come to think of it, is it possible to do a GS emulator this way?
--
Lim Thye Chean: Lim is my surname. My name is Thye Chean.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Institute of Systems Science Windows 95/NT and Apple IIGS programmer
Welcome to web page: http://www.iss.nus.sg/RND/MS/Projects/alp/ltchean.html
Lim Thye Chean
: Well, most systems that can run MS-DOS can also run Linux...
But most will not install Linux just to run Apple II software.
: The main problem with doing this on a dos filesystem is the 8.3 filenames,
: while prodos's are 15 characters. You'd have to have something which
: creates a hashed name that will fit into 8 characters and then maintains a
: database of prodos->msdos filename mappings. It would work, but you'd lose
: some of the transparency of it. (Of course umsdos does that too...)
Try MS-DOS 7, or Windows 95, or Windows NT, or OS/2 then. All of them support
long file name.
: The current release of Prodosemu is mostly a 'proof-of-concept'
: distribution, as I didn't implement high-res graphics (Appleworks runs
: great tho, and I think it is neat to be able to run Shrinkit on your ISP!)
: In future releases I plan to include the graphics code (console + X) from
: some of the other Linux-based Apple II emulators.
I really hope you can release a DOS/Windows based emulators. There are a
more users and demand in DOS/Windows world, and we would really welcome such
a project.
Richard Pieri
>>>>> "LTC" == Lim Thye Chean <ltc...@iss.nus.sg> writes:
LTC> Try MS-DOS 7, or Windows 95, or Windows NT, or OS/2 then. All of
LTC> them support long file name.
See your own comments about not installing Linux just for an Apple ][
emulator. I could maybe get Linux to run on my machine (486DX2/50, 4Mb
RAM); I won't even consider '95 or OS/2 with less than 8-12Mb RAM , and
NT's requirement of 16Mb+ RAM is just not an option.
And BTW, DOS 7, upon which Windows 95 is layered, uses FAT filesystems
with the 8.3 filename limits along with a redirector that fakes out the
long file names, much like the Linux-on-FAT partition fake out
functions.
From: rat...@unilab.dfci.harvard.edu Newsgroups: comp.emulators.apple2
Message-ID: <x7zqbhp...@unilab.dfci.harvard.edu> Date: 21 Jan 1996
12:10:35 -0500 Subject: Re: ProDOS Emulator v0.1 in incoming on ftp.asimov.net
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
iQCVAwUBMQJzj56VRH7BJMxHAQEBnwQAjdac8eOlFQL8F+FKkB0OsHjzS3feZ/Ge
YSn6Qz3bRpSI7zKoyzjmww767f/EB/CpjzRKr8DBZu6EcaWnJBwzvuEB3Vkdxzh9
WdXPiks54iZQAvbcIccCvZai5mYcHc+YzLRI9hQXjL4EvZIDy8BnfqTMsJ2VACcj
V/NoIooveFw=
=BuE0
-----END PGP SIGNATURE-----
--
Richard Pieri/Information Services \ Variety is the spice of life: one day
<rat...@unilab.dfci.harvard.edu> \ ignore people, the next day annoy
http://www.dfci.harvard.edu/~ratinox \ them. -A cat's guide to life
Kurt Olsen
> Try MS-DOS 7, or Windows 95, or Windows NT, or OS/2 then. All of them support
> long file name.
I'm currently working on this. I partly works, but I've run into a bit of a
sticking point and am trying to decide if it would be better to rewrite the
assembler that I want to run or finish the job. Currently I'm using watcom
to compile things and had to write up some quick and dirty 'curses' emulation.
Other than that it went pretty nicely. Except that there were plenty of these:
location = MegaGetMem(foo++)||(MegaGetMem(foo++)<<8);
which needless to say ends up not working under all compilers. Had to change
them all. Yuck.
--
Kurt Olsen (ku...@cc.usu.edu)
<a href="http://www.mcs.usu.edu/~kurto/">Me & my Atari Lynx</a> archive.
Matthew Ghio
Lim Thye Chean <ltc...@iss.nus.sg> wrote:
>Romeo (ro...@unicomp.net) wrote:
>: In article <4css...@news.alias.net>, gh...@netcom.com (Matthew Ghio) says:
>: >Announcing ProDOS Emulator v0.1 for Linux
>: >Prodosemu combines 65C02 processor emulation with an operating system
>: >emulator to translate ProDOS MLI calls to native unix calls. Prodos
>: >applications run directly from your unix filesystem, with no need to
>: >create disk images. Simply create a subdirectory, place your ProDOS
>: >system binaries in it, and run them with Prodosemu.
>:
>: That's an EXCELLENT idea! Is there a way to port that program to DOS
>: based systems? Sure beats having to worry about making disk images!
>: I could just modem them over to my pc!
>
>I second that! Either DOS or Windows will be really welcome!
>
>Come to think of it, is it possible to do a GS emulator this way?
I don't see why not, but completely emulating the GS toolbox would be a
massive project, which would take much more resources than my little ProDOS
re-write. On the other hand, you might be able to run most of the tools in
the emulator (since you can ftp them for free from ftp.apple.com) and just
rewrite the disk access stuff and the memory manager.
In article <x7zqbhp...@unilab.dfci.harvard.edu>,
Richard Pieri <rat...@unilab.dfci.harvard.edu> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>>>>>> "LTC" == Lim Thye Chean <ltc...@iss.nus.sg> writes:
>
>LTC> Try MS-DOS 7, or Windows 95, or Windows NT, or OS/2 then. All of
>LTC> them support long file name.
>
>See your own comments about not installing Linux just for an Apple ][
>emulator. I could maybe get Linux to run on my machine (486DX2/50, 4Mb
>RAM); I won't even consider '95 or OS/2 with less than 8-12Mb RAM , and
>NT's requirement of 16Mb+ RAM is just not an option.
>
>And BTW, DOS 7, upon which Windows 95 is layered, uses FAT filesystems
>with the 8.3 filename limits along with a redirector that fakes out the
>long file names, much like the Linux-on-FAT partition fake out
>functions.
I developed it for Linux because:
- It has a decent filesytem.
- It is inexpensive, and comes with a free C compiler.
- There is plenty of free source code available upon which to build.
- It has plenty of freely available technical documentation.
None of which is true for MS-DOS/Windows or OS/2.
(To be fair, OS/2's filesystem is pretty good from what I've heard, but
the potential user base for an OS/2-based Apple emulator seems to be much
smaller than for Linux, and OS/2 is still vastly more expensive than Linux.)
Furthermore, as Richard Pieri said, Win95 is not a feasible option if you
have only 8 megs of RAM (as I do), while Linux will run just fine in that
configuration (plus $90 for Win95 is a rip-off compared to what you can get
for Linux for a fraction of that price.)
DOS/Windows is just not a feasible development platform for freeware right
now (at least not for me). Hopefully with some of the new gcc ports to
dos/windows this situation will change. It was cheaper and faster for me
to develop for Linux than for DOS (and like I said the emulator isn't really
complete yet anyway.)
In short, I would be happy to compile it for msdos, but I don't see an easy,
inexpensive way to do so.
If the dos/windows developers out there would like to see more development
interest in their platform, they should make source code more available to
encourage people to enhance the software.
In article <1996Jan22.1...@cc.usu.edu>,
Kurt Olsen <ku...@cc.usu.edu> wrote regardng a dos port:
>I'm currently working on this. I partly works, but I've run into a bit of a
>sticking point and am trying to decide if it would be better to rewrite the
>assembler that I want to run or finish the job. Currently I'm using watcom
>to compile things and had to write up some quick and dirty 'curses' emulation.
>Other than that it went pretty nicely. Except that there were plenty of these:
>
> location = MegaGetMem(foo++)||(MegaGetMem(foo++)<<8);
>
>which needless to say ends up not working under all compilers. Had to change
>them all. Yuck.
What's (specifically) wrong with it? (Aside from the fact that it should
be a single | which it is in my actual code.) Only potential problem that
I can see is that you might need to explicitly specify the conversion to a
unsigned short int.
BTW, This particular statement reads a 16-bit value from the Apple memory
and converts it from lsb-first order to host order (which, in the case of
an intel processor is the same thing).
By all means, continue porting it and/or send me patches & bugfixes.
I'm starting school soon tho, so Prodosemu will probably be on the back
burner for awhile. Also, if anyone wants to send me some code that will
handle an actual prodos filesystem, that would be welcome too!
Kazimir Kylheku
Matthew Ghio <gh...@netcom.com> wrote:
>I developed it for Linux because:
> - It has a decent filesytem.
> - It is inexpensive, and comes with a free C compiler.
> - There is plenty of free source code available upon which to build.
> - It has plenty of freely available technical documentation.
>None of which is true for MS-DOS/Windows or OS/2.
For the same reasons, I have also developed a 68010 emulator for UNIX last
year. It needs a little bit more work in the area of device emulation, and a
user interface would be nice too! I'm planning to pick up the project sometime
soon.
One University professor has shown interest in using it to emulate the Xinu
multitasking OS to increase the opportunities for students in his course to
write and test Xinu code. All of the execution core is there; it correctly runs
all kinds of bizarre code, even hand-coded floating point routines from the GNU
library which do flex the instruction set a little bit.
In its current state, the thing is portable to extended DOS, but I just don't
support platforms like that.
When it is finished, it will rely a heavily on special UNIX features; a full
port to a non-OS will then be next to impossible.
--
E. Lefty Kreouzis
>
> In article <1996Jan22.1...@cc.usu.edu>,
> Kurt Olsen <ku...@cc.usu.edu> wrote regardng a dos port:
> >I'm currently working on this. I partly works, but I've run into a bit of a
> >sticking point and am trying to decide if it would be better to rewrite the
> >assembler that I want to run or finish the job. Currently I'm using watcom
> >to compile things and had to write up some quick and dirty 'curses' emulation.
> >Other than that it went pretty nicely. Except that there were plenty of these:
> >
> > location = MegaGetMem(foo++)||(MegaGetMem(foo++)<<8);
> >
> >which needless to say ends up not working under all compilers. Had to change
> >them all. Yuck.
>
> What's (specifically) wrong with it? (Aside from the fact that it should
> be a single | which it is in my actual code.) Only potential problem that
> I can see is that you might need to explicitly specify the conversion to a
> unsigned short int.
>
The order of evaluation of the post increments (foo++) is undefined in the C standard.
This means that any compiler can choose to evaluate them in any order. In fact the same compiler
can evaluate differently in different optimisation levels.
To be extra sure one should split the assignment in two.
location = MegaGetMem(foo++);
location |= MegaGetMem(foo++);
Using gcc one could do this using an inline function:
inline short int getw(unsigned char *foo)
{ short int x;
x = MegaGetMem(foo++);
x |= MegaGetMem(foo++);
return x;
}
Lefty Kreouzis
Olaf Marx
In article <3111F9...@eexi.gr>, "E. Lefty Kreouzis" <le...@eexi.gr> writes:
|>Matthew Ghio wrote:
|>>
|>> In article <1996Jan22.1...@cc.usu.edu>,
|>> Kurt Olsen <ku...@cc.usu.edu> wrote regardng a dos port:
|>> >I'm currently working on this. I partly works, but I've run into a bit of a
|>> >sticking point and am trying to decide if it would be better to rewrite the
|>> >assembler that I want to run or finish the job. Currently I'm using watcom
|>> >to compile things and had to write up some quick and dirty 'curses' emulation.
|>> >Other than that it went pretty nicely. Except that there were plenty of these:
|>> >
|>> > location = MegaGetMem(foo++)||(MegaGetMem(foo++)<<8);
|>> >
|>> >which needless to say ends up not working under all compilers. Had to change
|>> >them all. Yuck.
Assuming
typedef unsigned char byte;
typedef unsigned int word; // or unsigned short depending on the machine
byte mem[xxxx];
I think MegaGetMem is referring to such an array.
what's about
location=*(word *)&(mem[foo]);
foo+=2;
Greetings
Olaf
Internet: om...@adler.biologie.Uni-Osnabrueck.DE
Matthew Ghio
Olaf Marx <om...@ax3301.biologie.Uni-Osnabrueck.DE> wrote:
>
>In article <3111F9...@eexi.gr>, "E. Lefty Kreouzis" <le...@eexi.gr> writes:
>|>Matthew Ghio wrote:
>|>>
>|>> Kurt Olsen <ku...@cc.usu.edu> wrote regardng a dos port:
>|>> >I'm currently working on this. I partly works, but I've run into a bit of a
>|>> >sticking point and am trying to decide if it would be better to rewrite the
>|>> >assembler that I want to run or finish the job. Currently I'm using watcom
>|>> >to compile things and had to write up some quick and dirty 'curses' emulation.
>|>> >Other than that it went pretty nicely. Except that there were plenty of these:
>|>> >
>|>> > location = MegaGetMem(foo++)||(MegaGetMem(foo++)<<8);
>|>> >
>|>> >which needless to say ends up not working under all compilers. Had to change
>|>> >them all. Yuck.
>
>typedef unsigned char byte;
>typedef unsigned int word; // or unsigned short depending on the machine
>byte mem[xxxx];
>
>I think MegaGetMem is referring to such an array.
>what's about
>location=*(word *)&(mem[foo]);
>foo+=2;
That might work on a big-endian processor, but you have to be careful when
dealing with other cpus.
-- xx
XXXXXXXXXXXXXXXXXXXXXx*####w
|~~ | | /~~ | / XXXXXXXXXXXXXXXXXXXXXXx#####* |~~ \ / /\ |\ |
|~~ | | < |< XXXXXXXXXXXXXXXXXXXXXXx*####o o |- >< < > | \ |
| |__| \__ | \ XXXXP"~~~~~~~~~~~~~~~ "" o |__ / \ \/ | \|
XXXXX:, o
9P^"',
Civil disobediance .sig -- This is a .sig virus; add it to your own .sig