FERGUSON@TMASL.EXXON.COM (06/21/89)
To access files with type nil, you must use the Mapped Segment Manager, or ms_$ calls. The call, ms_$mapl, will open the file, and you can directly map whatever byte you want in the file to a pointer in your program. This is nice for many reasons. One is that you never have to perform a 'read' of the data. You just get a pointer to the actual disk file, and do with it what you want. Also, it's the only way I know to work with 'nil' files. Fonts are 'nil' files, and I had always hoped that Apollo would provide a set of system calls for working with fonts. Edfont is nice, but for translating non-apollo fonts to apollo format would take a year by hand. Good Luck Scott Ferguson ferguson@erevax.bitnet
mishkin@apollo.COM (Nathaniel Mishkin) (06/22/89)
In article <8906211239.AA02260@umix.cc.umich.edu> FERGUSON@TMASL.EXXON.COM writes: >To access files with type nil, you must use the Mapped Segment Manager, >or ms_$ calls. The call, ms_$mapl, will open the file, and you can >directly map whatever byte you want in the file to a pointer in your >program. FYI, at sr10 and later, files of type "nil" can be read using standard stream I/O calls (open, close, read, write, etc.). Further, you can make "nil" type files readable by stream I/O at sr9.7 by obty'ing them to the type "unstruct". -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com
danny@idacom.UUCP (Danny Wilson) (06/25/89)
In article <8906211239.AA02260@umix.cc.umich.edu>, FERGUSON@TMASL.EXXON.COM writes: > Fonts are 'nil' files, and I had always hoped that Apollo would provide a > set of system calls for working with fonts. Edfont is nice, but for > translating non-apollo fonts to apollo format would take a year by hand. We make protocol testers which must be able to display many different character sets (ASCII, EBCDIC, JIS, T.61 etc) on our custom display hardware. To speed our development, we used EDFONT to input and edit the fonts in a 10x12 envelope. Once perfect, I wrote a program which reads the font file (using ms_$mapl) and outputs data which goes to a EPROM programmer. It is quite handy. I got this format from a _very_ old Apollo technical bulletin. However, recently I heard that SR10 uses a new format... Is this true? Will my program still work? Any comments out there? -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta alberta!idacom!danny C A N A D A
nazgul@apollo.COM (Kee Hinckley) (07/04/89)
In article <693@idacom.UUCP> danny@idacom.UUCP (Danny Wilson) writes: >I got this format from a _very_ old Apollo technical bulletin. However, >recently I heard that SR10 uses a new format... Is this true? Yes. >Will my program still work? Any comments out there? I don't believe that it will. However the new format is now documented (well, has a header file) in /usr/include/apollo/fontn.h. -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.