barry@rbdc (Barry Newberry) (12/21/90)
I'd like to try some unusual set-ups with GS/OS. I've ordered the GS/OS
Tech Ref, and I should have it in 2 weeks. For programming, I have Orca/C
and Orca/M (updated).
A couple of questions regarding GS/OS :
Q1 : What is the minimum configuration for GS/OS (list files) ? Assume
that I have some application (S16 ?) which takes care of needed tools,
graphics, I/O, and uses GS/OS MLI calls. For ProDOS8, it would be :
Files: /PRODOS, /the_program.SYSTEM (Filetype: SYS)
Q2 : What Toolbox dependencies does the GS/OS Kernel have ?
Q3 : How do I make an S16 file ? Is it as simple as changing the filetype
from EXE to S16 ? Is the GS/OS MLI Quit good enough for a "clean" exit
from the program ? Is there anything special that my program needs to
do at startup ? Assume that I'm using direct screen writes in 40 columns
and reading the keyboard at $E1/C000 to keep things _reeeeeal_ simple.
.. and since there's so much talk ...
Q4 : Did anyone buy/get an Apple IIgs because he needed _MULTI-TASKING_ ?
Personally, background printing and background X-Modem are all I would
have much use for.
Hmmm .... Maybe someone could write a CDA that could initiate an X-Modem
transfer with just interrupts. Intercept the ProDOS8 MLI as soon as the
transfer begins, force any call to wait until X-Modem is ready to write its
buffer (or read, ... keep an eye on close commands) Once the transfer starts,
you could leave the CDA and play with Applesloth (or some other stuff). WHY
I THINK I'LL WRITE IT TODAY !!! :> =sorry, I guess I'm teasing= Even though
I have started work on an interrupt based dumb terminal CDA. Serial IRQ
handler ... crude but it works. Sound IRQ handler ... it's Ok. Main CDA
program segment ... looks good for a couple of diagrams and some notes. :>
--
-------------------------------------------------------------------------
Remember, until there is a cure for Assembly Language Brain Fry,
there will always be the N.C. Home for Deranged Programmers.
-----------------------------------------------------------------------toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/06/91)
AABENSON@MTUS5.BITNET writes: >They WERE talking about shell executables (EXE files). And YES, they CAN be >changed into filetype S16 and expected to work IF: > [1] They weren't using any shell information (no shell calls). > [2] They end with a QUIT call, and not via RTL. Shells don't really > care either way, but GS/OS does when an S16 file exits. Note that this is not always sufficient. Parts of the Orca/C stdio library depend on the shell being present, and barf if you S16 them. >By the way, the way parameters are passed from the shell is NOT automatic. The >shell executable (EXE file) must REQUEST the information. Not according to the Programmers' Intro to the GS. According to page 261, "As soon as a shell application is launched .... It should also check the X and Y registers for a pointer to the shell-identifier string and input line." X & Y are 0 if GS/OS launched the application. The shell identifier is 8 bytes ASCII (BYTEWRKS for APW/Orca) and is immediately followed by a null-terminated ASCII string -- the input line with I/O redirection and piping removed. It is finder messages to S16's that must be requested. Todd Whitesel toddpw @ tybalt.caltech.edu
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (01/07/91)
>Note that this is not always sufficient. Parts of the Orca/C stdio library >depend on the shell being present, and barf if you S16 them. >Todd Whitesel >toddpw @ tybalt.caltech.edu I think that this is not a problem. If you want to do I/O use the Toolbox. Are you complaining that Orca/C does not use Toolcalls when you generate a SYS16 file? ^^in lieu of shell calls UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/08/91)
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes: (In response to this bit which I wrote) >>Note that this is not always sufficient. Parts of the Orca/C stdio library >>depend on the shell being present, and barf if you S16 them. >I think that this is not a problem. If you want to do I/O use the Toolbox. Are >you complaining that Orca/C does not use Toolcalls when you generate a SYS16 >file? ^^in lieu of shell calls Here's the situation. I compile an EXE that uses fopen/fread/fclose. It works but >64K reads return $FFFF in the high word (if I read $1fde8, the return value from fread() would be $fffffde8 instead). When I Filetype that load file to S16 (note: I didn't specify S16 compilation in Prizm, I used compile and link commands in the shell) and launch it from finder, fopen() returns an error ($100, whatever that means). When I replace fopen/fread/fclose with my own little subroutines that rely on gsos.h (GSOpen/GSRead/GSClose is what I call them) my executable shrinks by about 2K and everything works like a charm. I'm really tempted to start writing a real stdio library for Orca that uses GS/OS for everything (even stdin/stdout/stderr) but I have enough projects already to keep me busy. Todd Whitesel toddpw @ tybalt.caltech.edu P.S. Lord High Giffer can display pictures now. Decompression is still entirely in C (slow, but easier to debug and tune) but I expect to be screaming past GIF3200 by the end of the week. I still won't have any conversions other than pre-scale color, so if you know of some really hot color-crunchers let me know.
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (01/09/91)
>When I replace fopen/fread/fclose with my own little subroutines that rely on >gsos.h (GSOpen/GSRead/GSClose is what I call them) my executable shrinks by >about 2K and everything works like a charm. I found that I preferred GSOpen to fopen, so I haven't used fopen much, certainly not on files greater than 64k. Guess it comes writing in Assembly so much. :) Make sure the LHG supports 256 colours, particularly since it doesn't take any extra CPU time. I would really like to see some pictures in the 320x200x 256 mode of the GS. UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
jb10320@uxa.cso.uiuc.edu (Desdinova) (01/09/91)
In article <1991Jan8.072457.198@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: > >Here's the situation. I compile an EXE that uses fopen/fread/fclose. It works >but >64K reads return $FFFF in the high word (if I read $1fde8, the return >value from fread() would be $fffffde8 instead). When I Filetype that load file [...] >When I replace fopen/fread/fclose with my own little subroutines that rely on >gsos.h (GSOpen/GSRead/GSClose is what I call them) my executable shrinks by >about 2K and everything works like a charm. I've not had any problems using fopen/fread/fclose from an S16. I used those to implement the disk storage for a phone book for Telcom (Three lines of code!) and it still works. Of course, I don't know about the FFFF in the high word business- my guess is it's either a bug or just a limitation. >I'm really tempted to start writing a real stdio library for Orca that uses >GS/OS for everything (even stdin/stdout/stderr) but I have enough projects >already to keep me busy. That's not a half bad idea- there's a lot of library type stuff the GS could use to make porting programs easier. The most useful would of course be the curses library. Any ideas on this? Or how about an ANSI/VT100 console driver? >Todd Whitesel -- Jawaid Bazyar | Being is Mathematics Senior/Computer Engineering | Love is Chemistry jb10320@uxa.cso.uiuc.edu | Sex is Physics Apple II Forever! | Babies are engineering