Snial
Well-known member
This MacGUI blog post covers the boot process for the early System Software on a Mac 512K (or Mac 128K). In part of it, he talks about the Mythical 256KB Mac:
But, I am interested in the Mythical Mac 256K and I was wondering how easy it is to create one using the miniVMac emulator. It turns out it is indeed possible!
Here's the proof:
On a Mac 128K, this 19kB MacWrite 1.0 document of scintillating prose takes up 87% of the remaining RAM (13% free) - it's pretty much the largest document you can write without 'Disk-based' MacWrite. On a Mac 512kB it takes up 5%, leaving 95% free (because 19kB/512kB = 3.7%), but on a Mac 256kB it takes up 23% with 77% free.
Amazing! So, how was it done? It wasn't really that hard. First I had to change a bit of the 64K ROM so that if the Mac didn't have 128kB, it defaulted to 256kB. This involved changing byte 0x2e1 to 0x3 (instead of 0x7 as per the "LEA $0007FFFC,A0 ; 512K RAM" above); then I had to change the ROM checksum so that it would match, which involved changing byte 3 to 0x4c. (The Checksum merely involves adding up all the (32-bit zero-extended) 16-bit words in the ROM and then XORING it with the 32-bit value at the beginning of the ROM at 0x400000).
So, a real Mac 256kB with this ROM will pass the checksum. However it won't run on miniVMac, because it modifies the ROM and then changes the standard ROM checksum to match what it would be. So, I had to modify miniVMac a bit too.
The setup needs to properly support 256kB and I had to change setup/SPBLDOPT.i. I think it already supported a 256K message option.:
But it didn't really process the message properly, so I had to add a bit to:
to support 256kB as a memory size; and then similarly a bit later:
To support 256K. Then I hacked 2 files in the main source code, because I couldn't be bothered to figure out the options for disabling RAM or ROM checking properly. In CONTROLM.h:
and in ROMEMDEV.c I forced DisableRomCheck:
With these changes I was able to setup miniVMac:
./setup_t -t larm -m 128K -mem 256K > setup128K256K.sh
sh ./setup128K256K.sh
make
Then boot up from a 410kB disk containing System 1.1 and MacWrite 1.0 with that document:
./minivmac Blank2.img
Disappointingly, as he also covers in this blog post, the 64K ROM only checks for the 128K or 512K Mac modelsAt the beginning of the boot blocks are several stored parameters. The version number is two bytes. Another two bytes hold flags for the secondary sound and video pages. Then come a series of seven, 16-byte long file names. These are the names of the System resource file, Finder (or shell), debugger, disassembler, startup screen, initial application to run, and clipboard.
Following the names is a value for how many open files there may be at once, and the event queue size. Then come three, 4-byte values which are system heap size for a Mac with 128K of RAM, 256K, and 512K of RAM, respectively. If you could find me a Mac with 256K of RAM, I'd sure be impressed.
<snip>
If you landed from planet Krypton with a Mac 256K, your system heap size would be $8000 (decimal 32,768).
Code:
FindMemSize:
4002DE: LEA $0007FFFC,A0 ; 512K RAM
4002E4: LEA $0001FFFC,A1 ; 128K RAM
4002EA: CLR.L (A0)+
4002EC: TST.L (A1)+
4002EE: BNE.S *+$02 ; branch if 512K
4002F0: MOVE.L A1,A0 ; this is a 128K machine
4002F2: MOVE.L A0,$0108 ; set MemTopBut, I am interested in the Mythical Mac 256K and I was wondering how easy it is to create one using the miniVMac emulator. It turns out it is indeed possible!
Here's the proof:
On a Mac 128K, this 19kB MacWrite 1.0 document of scintillating prose takes up 87% of the remaining RAM (13% free) - it's pretty much the largest document you can write without 'Disk-based' MacWrite. On a Mac 512kB it takes up 5%, leaving 95% free (because 19kB/512kB = 3.7%), but on a Mac 256kB it takes up 23% with 77% free.
Amazing! So, how was it done? It wasn't really that hard. First I had to change a bit of the 64K ROM so that if the Mac didn't have 128kB, it defaulted to 256kB. This involved changing byte 0x2e1 to 0x3 (instead of 0x7 as per the "LEA $0007FFFC,A0 ; 512K RAM" above); then I had to change the ROM checksum so that it would match, which involved changing byte 3 to 0x4c. (The Checksum merely involves adding up all the (32-bit zero-extended) 16-bit words in the ROM and then XORING it with the 32-bit value at the beginning of the ROM at 0x400000).
So, a real Mac 256kB with this ROM will pass the checksum. However it won't run on miniVMac, because it modifies the ROM and then changes the standard ROM checksum to match what it would be. So, I had to modify miniVMac a bit too.
The setup needs to properly support 256kB and I had to change setup/SPBLDOPT.i. I think it already supported a 256K message option.:
Code:
enum {
gbk_msz_128K,
gbk_msz_256K,
//...etcBut it didn't really process the message properly, so I had to add a bit to:
Code:
LOCALFUNC char * GetMemSizName(int i)
{
char *s;
switch (i) {
case gbk_msz_128K:
s = "128K";
break;
case gbk_msz_256K:
s = "256K";
break;to support 256kB as a memory size; and then similarly a bit later:
Code:
LOCALFUNC tMyErr ChooseMemBankSizes(void)
{
tMyErr err;
RAMa_Size = 0;
RAMb_Size = 0;
switch (cur_mdl) {
case gbk_mdl_Twig43:
case gbk_mdl_Twiggy:
case gbk_mdl_128K:
case gbk_mdl_512Ke:
if (cur_msz == gbk_msz_128K) {
RAMa_Size = ln2_msz_128K;
} else
if (cur_msz == gbk_msz_256K) {
RAMa_Size = ln2_msz_256K;
} elseTo support 256K. Then I hacked 2 files in the main source code, because I couldn't be bothered to figure out the options for disabling RAM or ROM checking properly. In CONTROLM.h:
Code:
LOCALFUNC tMacErr ROM_IsValid(void)
{
#if 0 //CheckRomCheckSumand in ROMEMDEV.c I forced DisableRomCheck:
Code:
GLOBALFUNC blnr ROM_Init(void)
{
#if 1 // DisableRomCheckWith these changes I was able to setup miniVMac:
./setup_t -t larm -m 128K -mem 256K > setup128K256K.sh
sh ./setup128K256K.sh
make
Then boot up from a 410kB disk containing System 1.1 and MacWrite 1.0 with that document:
./minivmac Blank2.img
!
