--- Ben Franchuk <bfranchuk(a)jetnet.ab.ca> wrote: AFAIK, the program would run if you could get the p-code to the target system (disk format incompatibilities and what not). I do not know how compatible things like user interface and I/O access were. What I'm not sure is, for instance, how a program formatted to look nice on an 80-col mono PC will look on a 40-col Apple II. Plus, what about file names? Did the P-System enforce the least common denominator? The one engine I know of that was the closest to "write once, run anywhere" was Infocom's Zork Implementation Program (ZIP). Stuff written for it in 1984 runs on Palm Pilots today, and stuff compiled today (in the language "Inform") runs on the C-64 ZIP written in 1984. ZIPs were originally written for the TRS-80, CP/M, PDP-11 (RT-11?), C-64, Atari, Apple, Amiga, Mac, and a few others (I managed to port the C-64 ZIP to the VIC-20, but you need a non-stock machine with a full boat of RAM if you want to play a game without wearing out the diskette; the PET version is still being debugged) Modern run-time platforms are written in C for VMS, UNIX, Palm Pilot, or whatever you want. I'm fairly sure there's a run-time written in Java, too. As a platform for a general-purpose language, there are some limitations that restrict programs written for the ZIP run-time. It does not provide file I/O other than reading in the code and data of the target rogram, and writing the modifiable pages (user-writable data) to disk. There is a journaling print function and that's about it. There is a limited amount of raw variable storage, but you can extend that with a finite amount of user-definable objects. The curious should take a gander at ftp.gmd.de - lots of good stuff there. The original Infocom code isn't open source, but fully compatible modern implementations are. Look in directories named "infocom" and "inform" for this stuff. There's lots of other text adventure platforms out there, and most of them have a home on GMD. -ethan __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/

thanks for the comments! StanStan Sieler sieler(a)allegro.com www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler

of Course yes ... well sort of - see below Now, here we are talking about two things: #1 is is the platform independant coding of an application, which is accomplished by using the same structure across all platforms. #2 is about different mass storage hardware. and here of course an operating system could do next to nothing. Because of #2 you raerly could use a disk from one system on another system, so software distributors had to do media for each system. Well, didn't we have the same situation even within the way more homogenus environment of CP/M ? Where you had to state machine and diskette format when ordering a copy of word star ? (In fact I even remember the same situation for MS-DOS - at least during the time when manufacturers still tried to build better systems, and not just faster versions of the same old crap.) There have been even GRAPHIC games which have been done in UCSD P-Code and ported to other computers without big trouble. One of the most classic games of all times: Wizardry. Well, the P code IS the binary format of the programms. Just as the so called Bytecode is the binary format for Java. Well, the speed difference wasn't that big between the result of 'real' Compilers (fortran for example) and the UCSD-P version of Fortran. As so often it depended on your kind of application. Gruss H. BTW: Total different thing - has anybody erver tried to do a Java to UCSD P-Code compiler ? Could be some fun :) -- VCF Europa 3.0 am 27./28. April 2002 in Muenchen http://www.vcfe.org/

On Thu, 28 Mar 2002, Hans Franke wrote: They did a good job. Their making of such a claim was extremely reprehensible. They claimed to have a "Universal disk format" that would work with ALL computers. That was NEVER true and was false advertising. But it WAS possible, just through attempts at standardization to reduce the format count to a handful (maybe a dozen?), instead of the thousands of CP/M formats and the dozens of MS-DOS formats. (see the list at: http://www.xenosoft.com/fmts.html which is just the soft-sectored double density ones) The number of formats could have easily been limited to one for each type of hardware. I had a brief discussion of that with Gary Kildall. Me: What is the standard format for 5.25" double density? Gary: 8" single density. He held to his convictions of NOT diluting the standard by having a secondary (5.25") standard format. Most people think of "binary" as meaning the NATIVE executable form of a program. By having the input to the P-system interpreter in a non human readable form, it added the additional benefit of making it more difficult to make any changes without going back through the compiler process. Some of the P-Code engines were VERY well written. V some compilers, ... The PC-DOS Fortran compiler 1.0 (written by MICROS~1, sold by IBM) when running a sieve of Erastothanes (a common benchmark in those days) was SLOWER than the MICROS~1 ROM BASIC interpreter! Bob Wallace (PC-Write), who wrote the MICROS~1 Pascal compiler, advised to NEVER EVER use the supplied run-time library. Or a P-code interpreter written in java? Or java virtual machine written in P-Code? Two more fun parts of the UCSD P-System: It would not/could not save a file in non-contiguous space. Thus you could have hundreds of K of free space, but not necessarily enough contiguous to save a file. Periodically you had to run their "CRUNCH" program to defragment. Hope that nothing goes wrong DURING that process! When storing a 16 bit integer (such as starting block number in a directory entry) in two bytes, do you put the MSB (most significant byte) or LSB (least significant byte first? That was NOT standardized on P-System disk formats!! Thus, Intel based machines were LSB first; Motorola based machines were MSB first. -- Grumpy Ol' Fred cisin(a)xenosoft.com

At 04:05 PM 3/28/2002 +0100, Hans Franke wrote: Compiling UCSD Pascal code as Java could be possible. It may already be possible, using Java back-ends to 'gcc'-related compilers, but it might not be perfect UCSD Pascal. Converting UCSD p-codes to Java could also be possible, depending on what sort of memory tricks you expect to work. - John