Meyers Lisa 1.75 ROM

--·--- Lisa 1 .75 ROM --------·----------------------·----------------..,-------------~-- To: From: Date: Subject: Ron Johnston, Marian Catelain, Ken c.<in, Gary Marten Rick ·Meyers May 26, 1983 Lisa 1.75 ROM Organization The Lisa· l.75 is expected ti0 have 128K bytes of ROM and 128K bytes of RAfvl on the CPU board. Additional RA!'-1 will range from none·(in a servant) to 768K (full memory board) and upward (given extra memory bo'ards). In a 512K system (assuming a 512K memory board, 128K CPU F~OM, 128K CPL,J RAM), the CPU ROM and RAM account for one third of the memory in the entire system. It's extremely important that we use this CPU memory wisely. Careful coordination bet"veen POS hardware and software group will be required. This memo outlines some of the planning that snould begin 1mmec:Uate1y. 1'1ernory COntents and Budgf!ts we need to carefully select both ROM· ancJ RAf'-1 contents, and budget their use of memory. Possible ROM .contents include: · • diagnostics (CPU, memory, peripherals) • boot code (ini tiallzation, load from disk) . • hardware interface (cursoJ, mouse, keyboards, s·peaker, timers, clock, power, etc.) • drivers (built in disk, twiggy, profHe, priam, RS-232, printers) ,. • partial file system· (for booting, keyboard tables, preferences, etc.) • miniature dubugger • fonts · • QuickDraw Possible RAl'-1 contents include: ., • primary screen (32,...() • optional al temate s;creen (32K) • interrupt and trap vectors (defaults, soft vectors, etc.) 0 hardware interface global data (keyboard mapping, keyboard queue, timers, etc.) • QulcKDraw. global o~ata (screen size, address, etc.) · • disk buffers, caches: ' . ·. • debugger data area (regis,ters, oreakpolnts, etc.) Ard'li tecture The dependencies between tlhe possible ROM contents are complex. For example: • diagnostics need hardware interface, fonts, QuickDraw • boot code needs halrdware interfac:e, drivers, file system • hardware Interface needs dr,lvers and me system (for keyboard definitions) • debugger needs nardware interface, but· hardware. interface must oe. deougged • QuickDraw needs hardware interface • etc. ·· 'There is no currently no linear ordering of the ROM software components which expresses the dependencies. This mak~s ~ layered organizatiori difficult Unfortunately, some ordering is require1ci, if only for initialization. we ~eed to break free from our current organization (or lack thereofl,. shuffle the software around, and define easily understood relatlonsnlps between the ROM components. Ga.llirg Cooventloos Calling conventions must. satisfy assembly language, Pascal, etc. How do we get Pascal lil~raries (QuickOraw, HW!nt, etc.) to point to ROM? If a ROM routine needs to be replaced, now do we override it in RA1'1? Certain ROM routines. will need domain and/or privlledged mode. Mechanism? Bad addresses as parameters to the ROM wm cause disaster. How is this preventea? 1 a Default interrupt and ~p han~lers will be In ROM. How .are t…