LisaList2

Advanced search  

News:

2019.06.07 fixed NChat for the "Curve" theme, will eventually move it to its own page and add it to the default theme as well. Other plugins are next. see post in the Meta board for details

Pages: 1 2 [3] 4 5 ... 10
 21 
 on: February 21, 2021, 10:17:57 am 
Started by stepleton - Last post by D.Finni
Speaking of bitsavers --- that useful second document you found made me head back to http://bitsavers.org/pdf/apple/lisa/pascal_monitor/ to see where you'd extracted that text from. I came up short! Do you have a link to the original somewhere? I probably have just not done a good enough job of scanning the PDFs, but I'm curious to know if there are Monitor docs in a different directory that I may have missed.
I may have misspoken the source. It's from Apple Macintosh developer documentation. It's from the early version of Inside Macintosh, distributed to developers in fall 1983 or spring 1984. It just tells you how to set up Monitor to use for developing Macintosh applications.

 22 
 on: February 21, 2021, 10:11:24 am 
Started by D.Finni - Last post by D.Finni
The Lisa's format for text files is a little weird --- it's faintly block oriented (files are always sized in multiples of 1K, IIRC), and it uses run-length encoding for runs of spaces. I'm still trying to track down where I saw the format documented (the documentation calls it the "One World Text File Format" or something like that),

I attached that text file to this post.

 23 
 on: February 21, 2021, 10:06:29 am 
Started by D.Finni - Last post by D.Finni
Good to know. Maybe we can figure out a protocol for transporting this metadata too. The Macintosh has MacBinary and BinHex formats.

For what it's worth (and for your consideration) there's been a single-file container format for a while :)

It's that tar-based format I mentioned just above. I call it a ".lar" file in the README for my file download program, and there are no prizes for guessing what the L stands for.
Unless anyone has any objections, I suppose this is the way to go. I certainly don't want to invent another format if there's already a good one around.


Will dig again, the question isn't around calling conventions, that's easy enough to sort out. It's about mapping the routines in the LOS Manual to the exact A-Line routines, which are actually addresses in kernel-space, that's what that A-Line trampoline thing really is: a generic jump mechanism. ie. which A-Line is open, which is create, which is close, which is read, etc. And are those stable across LOS releases?
Ah, ok now I understand what you're after. The Lisa documentation is awfully tight-lipped about it, from my review of it last evening. I'm not totally sure that LOS uses A-line traps. I should admit that it's just my assumption based on so many similarities between Macintosh and Lisa architecture. On Macintosh, the trap dispatch table is located at $400 in RAM.

 24 
 on: February 20, 2021, 09:13:42 pm 
Started by D.Finni - Last post by stepleton
Good to know. Maybe we can figure out a protocol for transporting this metadata too. The Macintosh has MacBinary and BinHex formats.

For what it's worth (and for your consideration) there's been a single-file container format for a while :)

It's that tar-based format I mentioned just above. I call it a ".lar" file in the README for my file download program, and there are no prizes for guessing what the L stands for.

As mentioned, there are three files inside the .lar archive. The first is a text file with many of the file attributes written out in a format that serves me but would be fine to change. The second is a file containing the label data. The third is the file data itself.

tar might seem like a heavyweight choice, but the specific file ordering I use simplifies access for homemade implementations (in other words, you don't really need to implement tar yourself). Since the first two files are small, file contents always start at fixed locations: $200 (file attributes), $600 (label contents), and $A00 (the file itself).

Of course any modern Mac or Linux machine will have tar installed already, and so will Lisa Xenix and UniPlus for that matter :). It's easy to come by for Windows too. Choosing a text format for the attributes inside comes from the same desire for easy accessibility.

About the only thing that's not so great is the overhead, at least $780 bytes of it: $200 for each file header, the $180 bytes of tar file block that the label file doesn't use, and probably several dozen more bytes not used by the attributes text file. But: the Lisa doesn't have to store that --- a transfer program can pack and unpack .lar data on the fly, tar is a streaming format after all --- and any modern computer on the other end will probably not be bothered by the extra space.

Sure, all those extra bytes will take time coming over the serial cable, but the amount of my time that this wastes is probably smaller than what would be required by writing decoders for a custom format on a range of plaforms ;)

 25 
 on: February 20, 2021, 09:01:19 pm 
Started by D.Finni - Last post by rayarachelian
My concern since reading the Memory Management chapter of Lisa OS is how to allocate blocks of memory in a heap. On the Macintosh, you call NewHandle or NewPtr to allocate a relocatable or non-relocatable block in the application heap.

Might be wrong on this, but since the Lisa has an MMU, it doesn't have to reorder memory to get rid of gaps, my guess is that it's not necessary to use handles.

One of the Workshop or OS manuals has an Assembly language chapter and it shows how to call Pascal routines from assembly and vice-versa. I was reading it this morning.
...
Or if your Lisa emulator had a fancy debugger ( :P ) you could check the contents of the Line 1010 emulator vector at low memory location $0028 and then disassemble from the address stored there.

Will dig again, the question isn't around calling conventions, that's easy enough to sort out. It's about mapping the routines in the LOS Manual to the exact A-Line routines, which are actually addresses in kernel-space, that's what that A-Line trampoline thing really is: a generic jump mechanism. ie. which A-Line is open, which is create, which is close, which is read, etc. And are those stable across LOS releases?

It's actually pretty easy to capture them all by just using the tracelog facility rather than a debugger, and it would capture them all in one shot, but what's difficult is reading the gigabytes of output.


Hmmm, perhaps I can insert assembly code that doesn't do anything but can let LisaEm know something about what's being called. That might work. Maybe I can insert a set of F-Line traps with a number to note what section of code is being called. i.e. F001 could mean open, F002 could mean close, etc. Then the code could be written in pascal, and then when the next A-Line trap is called, I can map it to that meaning.
Or maybe the F-Line trap could pass a pointer to a string that says "open", etc. and that string can be used to record it.
There we go.

Having a debugger would turn that process manual which would make it painful. But yeah, yeah, I can take a hint. I'll aim for a fancypants debugger in 1.2.8.
I'll even randomly and colloquially refer to it as "The David Finnegan Memory-all Debugger"  ;D

 26 
 on: February 20, 2021, 08:16:22 pm 
Started by stepleton - Last post by stepleton
That file browser is nice. Looking through one of the files reminds me of another problem I've had with the Monitor disk images on Bitsavers: not being able to run Editor.obj. The error message mentions something about a font file, if memory serves. It's been a while...

Like everything Monitor, this feels fixable with some hacking. Even the fact of not being able to boot off the hard drive feels negotiable. The format document you've provided says "Blocks 0 and 1 are the boot blocks", and that ought to be plenty to fit a bootloader that can read the simple filesystem. We have source code for Monitor 11.6, and this might provide hints that would indicate what other changes should be made to the Monitor "kernel" itself (I don't think it calls itself that) so that it's happy to start on a hard disk.

A good reason to do this would be to make a convenient standalone Monitor drive image that can boot the Smalltalk environment that you find on one of the Bitsavers disks. Right now you need a Lisa 1 to run it --- the Monitor in one of the drives and the Smalltalk disk in the other. It's nice if you're patient. (For anyone who feels like trying this: Smalltalk won't run under the version 12 Monitors; I've always run it under 11.6.)

Speaking of bitsavers --- that useful second document you found made me head back to http://bitsavers.org/pdf/apple/lisa/pascal_monitor/ to see where you'd extracted that text from. I came up short! Do you have a link to the original somewhere? I probably have just not done a good enough job of scanning the PDFs, but I'm curious to know if there are Monitor docs in a different directory that I may have missed.

 27 
 on: February 20, 2021, 06:35:23 pm 
Started by D.Finni - Last post by D.Finni
What I'm missing is how to call those kernel pascal procedures from assembly. I can tell what the parameters are from the pascal structures and such, but what I'm missing is some sort of mapping to the syscalls, are they A-Line traps?
They're A-line traps so far as I know. The Macintosh team borrowed all the good stuff from Lisa. I'm continually surprised to discover new similarities.

One of the Workshop or OS manuals has an Assembly language chapter and it shows how to call Pascal routines from assembly and vice-versa. I was reading it this morning.

Quote
How do I find that out?
I would think disassembly would give an answer pretty darn quick. Or even quicker, just isolate a .OBJ on any Lisa .dc42 disk image and check for frequency and spacing of $Axxx words.

Or if your Lisa emulator had a fancy debugger ( :P ) you could check the contents of the Line 1010 emulator vector at low memory location $0028 and then disassemble from the address stored there.

 28 
 on: February 20, 2021, 06:29:06 pm 
Started by D.Finni - Last post by D.Finni
There's a (predictable) additional issue that the Lisa FS has metadata that you won't find on other operating systems. Besides the usual stuff you see in a file listing (creation time, modification time, and so on), there's also "type" and "subtype" fields (reminds me of filetype and creator for Macintosh)
Good to know. Maybe we can figure out a protocol for transporting this metadata too. The Macintosh has MacBinary and BinHex formats.


Quote
I'm still trying to track down where I saw the format documented (the documentation calls it the "One World Text File Format" or something like that)
I have that text file, and actually just glanced at its contents earlier this morning. I already wrote a tool to read the Lisa text files a couple years ago.

Quote
(Since we were talking about it earlier: the system software manual has the programmer's documentation for the QuickPort library, PDF pages 336-392.)
Yeah, I was reading that documentation earlier this morning too. I think QuickPort is the way to go. I also saw that Lisa's register conventions are identical to Macintosh. A5 is used as an application globals pointer, same as on Macintosh.

My concern since reading the Memory Management chapter of Lisa OS is how to allocate blocks of memory in a heap. On the Macintosh, you call NewHandle or NewPtr to allocate a relocatable or non-relocatable block in the application heap.

 29 
 on: February 20, 2021, 06:27:18 pm 
Started by stepleton - Last post by D.Finni
Oh, and by the way, last November I added Monitor format to my Vault archive site so you can click through and browse the contents of Lisa Monitor disks. And you can link directly to files within the disks. The URLs will never change.

This is neat. Take a look at some examples:

https://macgui.com/spyglass/r/7e8a7a533c8dfb56
https://macgui.com/spyglass/r/c65d7e778b0d2b79
https://macgui.com/spyglass/r/0f87d6f7c1cb821d

LisaTest is a Monitor-format disk. The feature is called "look inside with Spyglass" in the Downloads section of my site.

 30 
 on: February 20, 2021, 06:13:45 pm 
Started by stepleton - Last post by D.Finni
I attached two useful text files to this post. The first is an except from Apple's Monitor documentation, from a PDF on Bitsavers. It explicitly says "After the Monitor is installed [on the ProFile], you will still boot with the Monitor Boot disk."

So there's your answer from the horse's mouth regarding booting from a hard disk.

The second text file is the Apple Pascal 5.25" disk format for Apple II. You can also find a description of Apple Pascal disk format in the Call-APPLE publication called "All About Apple Pascal." It's documented in a few other sources too.

Like I said earlier, Lisa Monitor's format is exactly the same (so far as I know) as Apple II Pascal, except that word-length values are in big-endian order.

As far as code, I think that you could take DiscImageChef's Pascal FS module and modify it. Within the Apple II community, you should also find one or two projects which can read Apple II Pascal formatted disks.

Pages: 1 2 [3] 4 5 ... 10