DEC.BANKS@MARLBORO.DEC.COM@caip.RUTGERS.EDU (01/28/86)
From: Dawn Banks <DEC.BANKS@MARLBORO.DEC.COM> A previous message noted that one of the reasons that executable images of C programs are so large is that a fair amount of space is taken up by the printf library routine. This is particularly painful in that having disassembled printf, I find that all the library routine does is implement the lowest common denominator interface between printf/sprintf/fprintf, etc and pass it all off to RawDoFmt in the exec library, which does all of the actual work. Second observation, this time on the subject of interlace and/or flicker: Some people have mentioned that NTSC is a lousy standard and that other standards don't interlace. I'd like to know which, as NTSC, PAL and SECAM all (to my knowledge) have interlaced pictures. If you happen to notice flicker in PAL pictures, it's not because the screen is scanned 25 times a second, but that you're either noticing the interlace or you're so adjusted to 60Hz, that your really do notice the difference at 50Hz. Personnally, I have seen flicker on normal broadcast NTSC pictures (some of it local station graphics, others just normal pictures that happen to have a spot that flickers due to sharp corners, etc), and I also find PAL unwatchable because of the lower refresh rate. Third observation (back to printf, actually): It is worthy of note that the RawDoFmt routine does not have the 200 byte limit as imposed by the Lattice C library. That limitation is entirely in the library (in the doprnt module, I believe), and would be easily increased and/or bypassed by tweaking or replacing the aforementioned module. In any case, direct calls to the Exec library routine implement as large a string as you allocate space for. Is this routine undocumented because it's liable to change with little or no notice? I find it particularly handy to call from assembler routines, so I don't have to mess with Amiga.lib at all. nevermind. --------