schaefer@ogcvax.UUCP (Barton E. Schaefer) (05/01/87)
[***]
Well. Here I am about to answer my own question about opendir() in C-Power
(thanks to those who sent helpful suggestions). I did what I should have done
quite a while ago and wrote a program to examine the C-64 file descriptor
tables during C-Power disk operations. So, for those interested, here's what
I found out, plus some other comments on C-Power functions and fixes.
According to the C-Power open() manual page, file numbers 5-9 are safe to use
in open() when fopen() is also in use, and file numbers 1-4 are reserved for
system use. Here's a breakdown of file number usage:
File # C-Power Use
====== ===========
1 Standard input. Is not actually opened unless input is
redirected, so references to stdin normally read the keyboard.
2 Standard output. Is not actually opened unless output is
redirected, so references to stdout normally write the screen.
Never closed if output was directed to a file. Files to which
output was redirected can be closed by the shell command
"disk v". (Is there another way, besides an explicit
close(2) before exiting?)
3 Unknown at present. Never opened in my tests.
4 Directory functions. Opened on disk drive channel 4 by
opendir(). Closed by closedir().
5-9 Unused, unless specified by user in open(). Disk drive
channels 5-9 should be used with these file numbers, but
channel 15 can also be open()'d to send disk commands (see
note on file number 15).
10-13 Opened by fopen() on disk drive channels 11-14. The first
fopen() uses file number 13, the next uses 12, etc. See
warning below on use of fopen().
14 Unused, but probably not safe for use with open().
15 Error channel. Opened on disk drive channel 15 by both fopen()
and opendir(), read by ferror(), and closed only by exit() or
abort(). See note below on opendir() bug. Note that multiple
file numbers can reference channel 15 at the same time.
16+ Unused. According to the C-64 manual, file numbers up to 255
are legal, but 128 and above cause carriage return to map to
return-linefeed and are intended for use with non-CBM printers.
Safe to use with disk drive channels 5-9 and with printers or
other devices.
Notes and Warnings on C-Power I/O Calls
=======================================
ferror() Fails (understandably) to detect inability to open the error
channel. This mainly affects opendir() (see below). DO NOT
call ferror() before calling one of fopen() or opendir().
fopen() Opens two files, the one returned and file 15 for ferror().
WARNING: This call can foul up the C-64's descriptor tables!
If fopen() is called when no channel is available, it will
return successfully and cause a file number with a non-existant
channel to be entered in the descriptor tables. The disk error
will be caught by ferror(), but DO NOT fclose() the file that
fopen() returned! If you close this file, which has no
channel, the 1541 will close one of the other open files
instead. In addition to the obvious problems, this can cause
the error channel to be closed, which will break ferror().
fread() Returns 0 if (elsize * nelem) is greater than the number of
bytes in the file. The file IS read, but it is not possible
to determine how many elements were read.
getchar() When reading the keyboard (stdin not redirected), sees a
carriage return at the beginning of a line as two characters --
a space followed by a return. This probably applies to getc()
and fgetc(stdin) as well.
open() File numbers 5-9 and 16-127 can be used with this call. Disk
channels 5-9 are safe.
opendir() Opens two file numbers, file 4 on channel 4 for the directory
and file 15 on channel 15 for use by ferror(). Unfortunately,
lacks a test (apparently present in fopen()) to see if file
15 is already open. This causes opendir() to fail if called
a second time or if called after fopen(). See fix below.
Does NOT accept the syntax "opendir(0:)" as suggested in some
manuals. (Maybe this syntax is ok for C-128?) Opens only
drive 8 (or, possibly, the work drive as specified by the
"work" shell command -- I have only one drive so I'm not sure).
Suggested Fix for opendir()
===========================
Append the following to all work-disk copies of "dir.h":
/*---------------------------------------------------------------------------*/
_diropen()
{
if (opendir())
return(1);
else {
close(15);
return(opendir());
}
}
#define opendir() _diropen()
/*---------------------------------------------------------------------------*/
Note that the #define must be AFTER the definition of _diropen().
Hope all you C-Power and Power-C users out there find this helpful. If anyone
wants a copy of my file-table dump program, send me E-mail and I'll take the
time to upload it and send the source.
--
Bart Schaefer Dept. of CS&E
CSNET: schaefer@Oregon-Grad Oregon Graduate Center
UUCP: {ihnp4,seismo,sun}!verdix \ 19600 NW Von Neumann Dr
{hplabs,ucbvax,decvax}!tektronix !ogcvax!schaefer Beaverton, OR 97006ugbowen@sunybcs.UUCP (05/03/87)
In article <1267@ogcvax.UUCP> schaefer@ogcvax.UUCP (Barton E. Schaefer) writes: > >I did what I should have done >quite a while ago and wrote a program to examine the C-64 file descriptor >tables during C-Power disk operations. So, for those interested, here's what >I found out, plus some other comments on C-Power functions and fixes. Does anyone know if the new Turbo C will be able to be run on the C128? I hear it's total K&R compatible, and C-Power is WAY to unpredictable. Devon Bowen (KA2NRC) University of Buffalo ******************************************************** csnet: ugbowen@buffalo.CSNET uucp: ..!{allegra,decvax,watmath,rocksanne}!sunybcs!ugbowen BITNET: ugbowen@sunybcs.BITNET BBS: (716) 672-8843 (On-line: Computer Access Center) Voice: (716) 836-7358 USnail: 67 Lisbon Ave; Buffalo, NY; 14214 ********************************************************
rex@otto.COM (Rex Jolliff) (05/05/87)
Summary: Expires: Sender: Followup-To: Distribution: In article <1267@ogcvax.UUCP> schaefer@ogcvax.UUCP (Barton E. Schaefer) writes: >[***] > > Never closed if output was directed to a file. Files to which > output was redirected can be closed by the shell command > "disk v". (Is there another way, besides an explicit > close(2) before exiting?) > I haven't had a problem with files left open. I think a 'disk i0:' would probably work a lot quicker, but I don't think either would flush the disk buffers properly... > >-- >Bart Schaefer Dept. of CS&E >CSNET: schaefer@Oregon-Grad Oregon Graduate Center >UUCP: {ihnp4,seismo,sun}!verdix \ 19600 NW Von Neumann Dr > {hplabs,ucbvax,decvax}!tektronix !ogcvax!schaefer Beaverton, OR 97006 One more question. Has anybody looked into the object files or library file format, or C-Power calling conventions? Printf and scanf are pretty slow. It seems like they were written in C themselves. I would like to rewrite them in ML. I would also like to code some other rouitines in ML (like some HiRes functions perhaps...). Any help would be appreciated. ** Rex! ** -- --------------------------------------------------------------------------- Rex Jolliff (rex@otto.UUCP) ------------------------------| The Sun Newspaper - | "Real Programmers don't | Nevada's Largest Daily Morning Newspaper | use BASIC or COBOL..." | Disclaimer: | | The opinions and comments in this article ------------------------------| are my own and in no way reflect the opinions | "Ack!" - bill the cat. | of my employers. -----------------------------
jay@garfield.UUCP (05/08/87)
> > One more question. Has anybody looked into the object files or library >file format, or C-Power calling conventions? Printf and scanf are pretty slow. >It seems like they were written in C themselves. I would like to rewrite them >in ML. I would also like to code some other rouitines in ML (like some HiRes >functions perhaps...). Any help would be appreciated. > > ** Rex! ** I too would be interested in info about the above. Thank you. Jay. ------------------------------------------------------------- J.(Jay) Kumarasingam UUCP: {akgua,allegra,cbosgd,ihnp4,seismo,utcsri}!garfield!jay EAN: jay@garfield.mun.cdn CSNET: jay%garfield.mun.cdn@ubc.csnet -- J.(Jay) Kumarasingam UUCP: {akgua,allegra,cbosgd,ihnp4,seismo,utcsri}!garfield!jay EAN: jay@garfield.mun.cdn CSNET: jay%garfield.mun.cdn@ubc.csnet