🚀 go-pugleaf

[]

Just got issue no. 2 of "printf", the Megamax Newsletter,
announcing their "lastest" (sic) product.
Here are the news in brief, and then a few inquiries.

Megamax C version 2.0 (now called Laser C) will be available soon.
If you have Megamax 1.1 you can send your original disks + $20 (a
check made to Megamax), and they will send you the new version
(including the brand new manual) as soon as it is ready.

The changes in new version include:

	Better graphical shell, including a "STDIO" window for command-line
	die-hards (like me :-) and a "FILER" tool that is friendlier than
	the desktop for file copy/rename/delete etc.

	A RAM cache that automatically uses the part of RAM that is not
	used by the running programs.  

	A MAKE facility.

	No more 32K limits on code segments or extern vars.
	(Absolute referencing - bigger, slower code?)
	(And what about local vars larger than 32K?)

	DRI compatible linker, and faster than the old one.

	Some sort of debugging monitor.

	Faster and more accurate (read: less buggy) floating point.

My comments:

	Can one now adjust the stack size an application gets without
	recompiling the startup.c (and rearchiving syslib)?
	(I redid the old startup code so that I can now do:
	"long _stacklen = 123456;  main(){...}" )

	I have had the opportunity to try out the new FP package.
	It is very fast (faster than Absoft FORTRAN).
	But did they improve the calling procedures?  I.e., is the
	C statement "a=b+c; (all doubles) translated to a simple
	"jsr _fpadd", or is it still routed through a big jump-table
	lookup scheme?  With the faster FP package, this can introduce
	almost a factor-of-2 slow-down!

	If, when debugging a program, the thing locks up and a RESET
	is necessary: does the RAMcache (and the latest version of the
	source code, if compiled-and-run from the editor, as is now
	possible) get lost?  Since I don't have a hard disk, maybe I'll
	stick with the trusty RESET-proof RAMdisk.

Disclaimer: 

	I am not affiliated with Megamax.

- Moshe Braner