In article ,
 "Michael J. Mahon"  wrote:

> rtk wrote:
> > On Jul 3, 1:22 pm, "John B. Matthews"
 wrote:
> > 
> >>I see what you mean about the S type file. Copy ][+ and Apple's SU copy
> >>it, but the LISP binary can't load it.
> > 
> > 
> > If one were really curious to see what is in the files I think one of
> > my old disk editor programs will change the file type to something
> > else, like B.  Then you could copy it and get a nice hex dump with
> > ECP-8.  But, I suspect it is just pointers to pointers to pointers.  I
> > did look at a hex dump of the Lisp executable hoping to see the names
> > of intrinsic commands but they are not stored as ASCII strings.  I
> > tried running Lisp under ProDOS and it bombs.
> > 
> > Of course, the big question:  what to do with it? :)
> 
> Best to change it to a TXT file, since that won't result in the first
> four bytes being interpreted as address and length.
> 
> Most disk utilities will allow any type of file to be examined in
> hex format.

My stars, it's full of pointers! $5400 of 'em. And not _quite_ regular 
enough to construct at run time. Then there's code again at +$5500. The 
Lisp binary runs to the : prompt, but (LOAD BASE) bombs.

$ ac -g ~/Desktop/lisp/lisp.dsk base | hd 
000000: 00 00 00 00 00 00 00 00 00 00 00 95 04 00 3c 00  ..............<.
000010: 40 00 40 80 00 00 00 00 00 ff c0 ff ff ff ff ff  {at}.{at}.............
000020: ff ff ff ff ff fc 00 00 00 00 00 00 00 00 00 00  ................
000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
*
000100: 00 72 40 04 00 72 40 08 00 72 40 0c 00 72 40 10  .r{at}..r{at}..r{at}..r{at}.
000110: 00 72 40 14 00 72 40 18 00 72 40 1c 00 72 40 20  .r{at}..r{at}..r{at}..r{at} 
000120: 00 72 40 24 00 72 40 28 00 72 40 2c 00 72 40 30  .r{at}$.r{at}(.r{at},.r{at}0
000130: 00 72 40 34 00 72 40 38 00 72 40 3c 00 72 40 40  .r{at}4.r{at}8.r{at}<.r{at}{at}
...
-- 
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews
--- SBBSecho 2.12-Win32