MC68XXXX FP and the LC

By Larry Nedry, Mousehole BBS

From: Emrte

Re: MC68XXXX FP DATA FORMAT

I’m porting some binary data files from a PDP 11 system to the Mac. When I swap bytes on the Mac short ints are OK but floats are still all wrong. The DEC LSI fp data format is the typical sign bit+7bit exp + 24 bit fraction in that order from high byte to low byte. Any help would be appreciated.

From: Istewart

Re: MC68XXXX FP DATA FORMAT

You probably need to get the “Apple Numerics Manual, Second Edition”, published by Addison-Wesley. I’ll try to interpret the format of the single and double floating point formats; I hope I’ve got it right, as I haven’t looked into this before ...

According to this publication, the 32-bit (single precision) floating point format is as follows, from msb to lsb, msb in lowest memory location:

1 bit - sign

8 bits - exponent

0<e<255: normalized, exponent is 2 raised to (e-127)

0 and fraction not = zero: denormalized exponent is 2 raised to -126

0 and fraction = zero: zero

255 and fraction = zero: infinity

255 and fraction not = zero: NaN (type signalled by value of fraction)

23 bits - fraction, if normalized, then there’s an implicit 1 inserted to the left of the fraction; if denormalized, then it’s zero.

For double, it’s similar, except that it’s 1 bit sign, 11 exponent and 52 fraction. For normalized, it’s (e-1023), and for denormalized, it’s -1022.

I hope this is some help; there’s quite a lot more on NaN’s in the manual, which I won’t pretend to understand.

From: Emrte

Re: MC68XXXX FP DATA FORMAT

Thanks for the info. I do have a copy of the Manual. I’m bringing the binaried byte). I’m just wondering whether the byte scan and parsing occurs after the initial byte swap? Straight byte swapping gives me the correct integer (short) values. Anyhow, I’ll keep hacking away. Thanks again.

From: Istewart

Re: MC68XXXX FP DATA FORMAT

I’m not quite sure what you mean by “... add byte”. What I think should happen, when you transfer the files with Kermit, is that you get an exact binary image of the original files from the PDP-11.

Kermit shouldn’t be swapping bytes, and parsing would only be done if you’re transferring the data in character format.

If that’s the case, then you can just call the SANE conversion routines to translate the string into internal (float or double) format, the internal details of the binary format are of no consequence.

However, the way I interpreted the problem initially is that you’re dealing with binary data. That being the case, you’re going to have to pick the PDP-11 version apart byte-by-byte, and possibly bit-by-bit in some cases!

As far as I can tell, the problem isn’t too difficult in principle, but making sure you’ve covered all the special cases (if any) could be another problem.

Let me know if I can give any more specific help (I’ll try, if I can figure it out!) Maybe you could post a detailed description of the PDP-11 format, and some examples of some of the data (just dump out a few of the numbers on the PDP-11 in Hex (or can you only do it in octal?) and post them in a bulletin, along with what they should be in decimal.

From: Mward

Re: MC68XXXX FP DATA FORMAT

Files sent using Kermit’s text mode can have conversions done to them. For example, a text file sent from a DOS machine to a Mac will have the nasty linefeed removed. If you want a bit-by-bit exact image of a file you have to specify a binary transfer.

From: Istewart

Re: MC68XXXX FP DATA FORMAT

Thanks for the information - I must admit that I’m not that familiar with Kermit ... however, I can’t imagine that he’d be doing anything other than a binary transfer if the data contains binary fields!

From: Walrus

Re: The LC

Don’t throw away the LC yet. I’ve heard of a company that is going to be marketing an upgrade for the LC that uses a 68040 processor. It could be the best upgrade deal since the Mac II/fx upgrade package.

From: Frankh

Re: The LC

Yeah, and it’ll probably cost more than the machine itself, and it’ll still be crippled by the narrow 16 bit bus (the ‘040 won’t be able to downgrade itself like the ‘020. I’m sure you can work around that with some simple logic, but that’s more nanoseconds lost...).

[Talk to Fusion Data Systems represented by Quantum Leap Systems at 15875 Highland Ct., Solana Beach, CA 92075, (619) 481-8427 or Fax (619) 481-3192. It costs about $3,000.-ed]

From: Gator

Re: 32-bit QD dev note

Can anyone tell me where I can get a copy of the 32-bit QD developers note mentioned in the Mac Primer Vol. 2? APDA has no ideas. Thanks!

From: Dandu

Re: 32-bit QD dev note

To my knowledge, the only official documentation Apple has issued regarding 32-bit QD was in the premiere issue of d e v e l o p. Aside from IM VI, of course.

From: Btoback

RE: 32-bit QD dev note

I’m enclosing copies of the docs. They were sent to all developers a couple of years ago; these are from the Developer CD series, vol. 4.

From: Btoback

Re: String formatting

I had to look up SysEnvirons! Try this:

sv = myEnv.systemVersion; /* For convenience */

sprintf(systemStr, “%d.%d.%d”, sv >> 8, /* Major version */

(sv >> 4) & 0xf, /* Minor version */

(sv & 0xf)); /* Fix level */

I’m doing it this way in order to split the system version into its three components. The major version is in the high-order 8 bits, hence the shift of 8 bits to the right to isolate it. The minor version is in the next four bits, so shift right four bits, and then mask off all the other bits. Finally, the fix is in the low-order four bits, so just mask off everything else.

Each “%d” is a placeholder for a single decimal number. I changed from hex (“%x”) to decimal because that’s what the user will want to see. The sprintf routine will copy the format string one byte at a time, and whenever it runs into a “%”, it assumes that the next few characters of the format string are a specification for an argument to sprintf.

By the way, if all you want to do is print the version, and don’t need to save the formatted version, you can use printf instead of sprintf, and omit the destination string (the first argument, in your case, <systemStr>). That’ll just print it.

From: Btoback

Re: THINK C Compilation and RAM cache

The RAM disc software on my friend’s PC is interesting: it survives anything except a power cycle, including a hardware reset. What I do on the PC is copy the BIG, static .h files to RAM disc (equivalent to combining most of the toolbox .h files), and let the compiler read everything else off disc. But the biggest win for a compile is to do the preprocessor’s and/or parser’s work for it, like the load/dump facility in MPW C/C++ (or Think C, for that matter).

I’ll have to find time to write the INIT. It would still be interesting, and we don’t know the behavior of the Mac’s file system -- how much looking does it do to find directory entries, etc.? That will also have a bearing on performance.

From: Siegel

Re: THINK C Compilation and RAM cache

The built-in RAM cache uses a linear search, so it does get very slow for large caches. There is an INIT called FTL which speed up THINK C and THINK Pascal builds by hitting the RAM cache as much as possible, but the benefits are superficial: (1) The entire project needs to fit into the cache, or else the cache hit rate drops so low that there’s practically no speedup; (2) The speedup is only noticeable for full builds when the project cache hit rate is very high; (3) Since the cache doesn’t get flushed until after the build is finished, there is a very real danger of project corruption in case of a crash, power outage, etc.

From: Dave

Re: THINK C Compilation and RAM cache

I know about FTL, but I think the author is mistaken about the usefulness of avoiding FlushVol. I believe that the Mac’s ram cache is a write-through cache for data integrity (so that danger you mentioned is moot). If you can verify/debunk this info, let me know.

From: Dave

Re: THINK C Compilation and RAM cache

Check out the upcoming version of 4Plus when it comes out. I have it on inside information from the author that he’s implemented a caching scheme that he and I were working on, based on what we were discussing. Apparently it works great.

From: Istewart

Re: That heap ...

Am I being paranoid?

In my continuing campaign aimed at learning to program the Mac, I’ve come across a situation that I don’t think should be occurring!

I’m testing my (fairly standard TextEdit based text editor!) program under Finder, seeing if I can break something by loading up all the DA’s in sight.

I’ve got this menu that allows me to purge memory, compact memory and break into MacsBug (each is a separate option). I execute them in that order, and examine the heap upon startup.

After loading DA’s and then closing them, I repeat the process, and look for anything that might be swallowing memory (I’ve already gone through this with the program itself).

Surprisingly enough, many DA’s seem to leave non-purgeable resources floating around in memory!!

For instance, the Chooser will leave two STR’s, one of them with my name in. Backdrop is even cleverer! It leaves itself there!? (if that’s the DRVR resource?)

Now, shouldn’t a DA zap anything it’s created, within reason, when it disappears? I mean, in theory, if I keep invoking a DA to do something, and then close it, reopen it ... after a while, couldn’t I run out of memory? (OK, it’ll take me a long time as my little program’s running on a 4meg SE, but surely some users may not have as much ...)

I guess under MultiFinder, it isn’t such a problem as the DA Handler will go away when all DA’s are closed, releasing this memory!

Thanks in advance for any thoughts on the subject ...

From: Mward

Re: That heap ...

You must be looking at the system heap. You would expect DAs like Chooser and Backdrop to leave stuff there, else how could they do their jobs? And the system heap is where you’re supposed to put stuff that survives application launches under Finder.

Do either of these DAs leave multiple copies of their “stuff”? That would be poor.

From: Istewart

Re: That heap ...

Thanks. But I’m actually looking at my application heap. After my purge, there isn’t much in it, except my CODE resources, several blocks of master pointers that I assigned at the start (after I found DA’s could temporarily allocate a lot of stuff, forcing new blocks to fragment the heap), and some MENU type resources etc.

Also, as I understand things, under Finder, the DA’s occupy the application heap. Under Multi-Finder, they’re loaded into a separate heap (the DA Handler that’s loaded for the purpose when a DA is opened).

I checked out the Chooser - it doesn’t seem to create multiple copies of the strings ... it just leaves them loaded and non-purgeable. This seems to me to be a bug - I can’t think of any reason why the Chooser would need them to be left there. After all, if they’re resources (on reflection, there’s more than enough evidence to presume this) it can just reload them next time it’s called!

From: Siegel

Re: THINK Pascal Future...

When THINK Pascal does a Reset, it calls both the user’s IAZNotify hook, if there is one, as well as calling ExitToShell on behalf of the user’s program. The IAZNotify hook is no longer used for standalone applications under MultiFinder, since the application zone is no longer initialized (strictly speaking), but you can use this technique when debugging inside the environment.

For more general-purpose use, you may want to install an _ExitToShell bottleneck.

From: Dave

Re: User-specified line breaks in TextEdit

Anybody out there know how to get TextEdit to break lines where YOU say it should? The best I can do so far is (ugh!) patch the TEWidthHook (See tech. note #207) so that TextEdit thinks that things have different widths from what they actually do. The problem with this is that you have to make assumptions about the algorithm that the Toolbox uses to break lines. I already tried using the wordBreak hook. It isn’t good enough. Please help!

I have an answer that works well, but is probably Apple-illegal. It involves patching the TERecal global variable. The mac will call through your own hook if you change the value of TERecal.

From: Walrus

Re: MacApp and LSP

Just after I posted that original message, I think I know what the problem is -- it’s running out of memory. MacApp under TP oinks, and the manual does say that it needs about 4 megs (I think). But they aren’t very adamant about it and they don’t tell you what might happen if you don’t have quite that much space (i.e. does it give you a friendly DLOG saying low on memory or does it just crash?). I might try to work in that environment again if I get some more SIMMs, otherwise I will work out the basic logic in TP and use MPW for the full-on compiles with MacApp.

From: Atom

Re: MacApp and LSP

You can get by with a 3 meg TP partition for small compiles, if I remember correctly... and I also seem to recall that TP sometimes fails, ah, ungracefully when running out of memory. Corrupted project files seem to be quite common when a MacApp program running inside TP crashes for whatever reason. I was running TP in a 4 MB partition and still had this problem. My suggestion that a file buffer wasn’t being flushed was really a shot in the dark, and I’d be very interested if anyone has any better idea as to what’s really going on here.

From: Bunk

Re: Writing a Time Mgr. Routine in C

*&#^@&$@&*#$. I’ve been trying to write a Time Manager called routine in Think C v4.0, and I can’t find a way to access application globals from the Time Mgr. routine. I’ve tried using the IM routines SetUpA5(etc.), and directly accessing the global CurrentA5 (move.l CurrentA5, A5 etc.) and tried looking at whether A0 (or A?) holds a pointer to the Time Mgr. task queue block (so I can indirectly store the app. A5), but I’ve been marginally successful at best. Can anyone give me any hints? A Time Mgr. task function shell would be nice! I’m slowly reaching the end of my rope about this and thinking of moving on to alternatives......

From: Myschif

Re: CTB and ADSP..

Howdy... I was wondering if anyone out there had had any luck getting some good documentation and source examples using the Comm. Toolbox and the Appletalk Data Stream Protocol. I’ve gotten varying levels of documentation about these two bits of code, but its all a mess.. I’m using Think C 4.0, and I’ve got access to the Dev. CD 5, 7.0b1 CD, and reams of technical documentation from Apple.... Any advice on a good place to start would be helpful...

From: Johnbaro

Re: Desktop pictures

I have several color pictures that I intended using as desktop pictures. I have ColorDesk, v1.0B7 (does anybody know where I can get a more recent version?), which puts up a PICT file as a desktop. The problem is that ColorDesk apparently uses the system’s default CLUT, rather than the CLUT saved with the PICT files. The result is that these great pictures look terrible on the desktop. Anybody know of a way around this, or another INIT that I could use to show color pictures on the desktop with their proper colors?

From: Aikidoka

Re: Desktop pictures

There is an init called CLUT-thing which allows you to use any CLUT you want for the system. A friend of mine has it, and I’ll see if I can get it and upload it here.

From: Rguerra

Re: Desktop pictures

You might consider DeskPicture, a component of Now Utilities 2.0, which does a remarkably good job at displaying (and customizing) desk pictures in their own colors. You can pick it up for a reasonable price from various mail order houses.