Re: Lisa Fonts

Rebecca Bettencourt wrote:
> Running the font files through that algorithm (with modifications to
> handle an arbitrary number of compressed bytes) gives me some
> interesting patterns, so it's a possibility. Of course just because
> it's interesting doesn't mean I'm barking up the right tree. A
> compression scheme like that would explain some of the patterns I'm
> noticing between the font file and the metrics file, but the bytes
> around the patterns are not consistent. Are there any compression
> scheme reverse engineering specialists around here? :)
>

Not me, sorry. I'd imagine researching the original Mac's font storage mechanism might help as the Lisa fonts are likely stored in a similar way.

http://developer.apple.com/documentation/Carbon/Conceptual/Managing_FontManager/fm_concepts/chapter_2_section_3.html#//apple_ref/doc/uid/TP30000982-TP30000221-TPXREF109 Sort of has some information, but nothing about the actual FONT resource.

However, Inside Mac IV p42-47 covers FOND and FONT resource formats, so that might be helpful. There is of course no guarantee that any of this matches what was used on the Lisa.
There is some stuff here. but doesn't appear to be too useful: http://developer.apple.com/technicalnotes/LegacyTechnologies/idxTextFonts-date.html

> Is there a way to get LisaEm to produce trace logs, just to see what's
> going on?
>

There is a mechanism for this, but it isn't provided to the user. You'll need some way to turn the traces on and off by calling debug_on(char *reason) and debug_off(), and you will need to change the debug_on() function to actually save the data to a log file - this is found in lisaem-aeon/lisa/glue.c - there's an inserted "return" statement before the original version of the function. Note that trace logs are extremely slow and very huge. The emulator will run at something like 1/100-1/500th of the normal speed.

You'd want some way to turn them on and off when certain code is hit. A good place to insert those switches would be inside reg68k.c. There is a bit of code that figures out what procedure/function is about to be executed. I'd tie it into that. This was how I normally used the emulator, I'd hard code the tests I wanted to turn debugging on, compile & run the emulator, then spent hours if not days reading the results. :-) Not very fast, but it captured everything that happened in the emulator.

These facilities were removed between the plain old X11 version and the move the wxWidgets. They will make their way into a future version when a debugger is added.

You'd also have to compile it like this "build.sh clean build --with-debug --with-tracelog"

> (Let's hope Google Groups lets this one through... :| )
>

It did. Received on 2007-04-07 13:15:08