True. Yet, something we CAN improve today, too.
Look at the GSOS for the Apple IIGS. The 6.0.4 was a user group release. That means we Mac folks can have user group updates too.WarpSE: 25 MHz 68HC000-based accelerator for Mac SE
- Thread starter Zane Kaminski
- Start date
True. Yet, something we CAN improve today, too.
Look at the GSOS for the Apple IIGS. The 6.0.4 was a user group release. That means we Mac folks can have user group updates too.
I agree.
That is an interesting take, @Zane Kaminski. If the low memory variables could be updated globally, what about the high memory? I gather that remapping the memory is complicated because it involves many working parts with the hardware and software.
Hi Zane - There was definitely some address magic. I believe the Prodigy SE takes the boot process onboard and replaces the MacSE ROM. The classic Prodigy boot Easter Egg was the Dracula Fang Happy Mac startup (indicating a modified ROM - see attached image). So, the board does its own address decoding. Once you put in a Prodigy board, it's not really an "SE" anymore unless you explicitly disable it with the Programmer's Switch at startup. Otherwise, it doesn't have a software on/off switch, except for SANE and the '020 cache. Also, the board had an optional Bus Transfer Unit (BTU), which passed the bus for use with certain additional SE cards (assuming they fit...and were compatible) -- but don't ask me for a list!
The original ProdigySE boards were 2mb and 4mb and there was a later SKU (and related upgrade mods) to support 8mb that included the PMMU (maybe for older boards that didn't have them -- I think the earlier boards just shipped with an empty socket for the '851) and updated ROM (3.0b, I believe). IIRC, later board manufacturing runs had a built-in PMMU and the newer ROM, and I think the upgrade kits just included the higher density RAM module. I will think about it, but that sounds approximately right.
I hope the above is helpful. I will post some pictures.
See this thread: BFEXTU's ProdigySE Project
The original ProdigySE boards were 2mb and 4mb and there was a later SKU (and related upgrade mods) to support 8mb that included the PMMU (maybe for older boards that didn't have them -- I think the earlier boards just shipped with an empty socket for the '851) and updated ROM (3.0b, I believe). IIRC, later board manufacturing runs had a built-in PMMU and the newer ROM, and I think the upgrade kits just included the higher density RAM module. I will think about it, but that sounds approximately right.
I hope the above is helpful. I will post some pictures.
See this thread: BFEXTU's ProdigySE Project
Attachments
Last edited:
That is awesome, @BFEXTU! I am looking forward to the pictures. You could do a new thread on the Prodigy SE, and I think it would be an excellent discussion about that accelerator board.
I have questions about the Prodigy SE's ability to do 8 MB maximum RAM.
I am looking forward to the pictures. You could do a new thread on the Prodigy SE, and I think it would be an excellent discussion about that accelerator board.I have questions about the Prodigy SE's ability to do 8 MB maximum RAM.
- Were there differences in how many lines connected from the 68020 out to addressable memory at the hardware level?
- If all 0 to 23 lines were connected, then there was software engineering magic to at least get to 8 MB. What exactly is preventing getting to 16 MB of RAM?
- Is it because of how Apple mapped the memory in the ROM and the operating system, as I gathered from many folks?
- What would it take for the SE to be able to address 16 MB of RAM, a redo of memory mapping?
Well...in terms of technical specs, I believe the ProdigySE uses 32-bit addressing onboard. I will see what old info I have. The limitation in the earlier Macs is because ROMBase is at 0x400000 (4Mb). And, in part, the ProdigySE solution was to replace the ROM. Interestingly (but unrelated), it also included a recoverable/bootable RAMdisk. Otherwise, beyond 4Mb, you are probably going to need an SE/30. I don't recall any 8mb+ RAM-only software trickery upgrades for the SE.
See the new project thread here: BFEXTU's ProdigySE Project (also added above)
See the new project thread here: BFEXTU's ProdigySE Project (also added above)
Last edited:
doesn't the Mac Portable support 9MB? seems like a comparison of the SE and Portable ROMs could be pretty fruitful, especially with the supermario source
Of course one can do anything with some combination of hardware and software … but go too far and what one has isn’t really an “SE” anymore!
You can’t use all 16MB for RAM without 32-bit addressing. It just isn’t possible, because in 24-bit mode, there are only 16MB of addressable bytes in RAM. Unless you add a completely new paging mechanism (or something?) to allow memory-mapped device access to work while also making that same memory address represent a byte of RAM, that can’t work with the mechanics of the vintage Mac operating system. ROMbase has to live somewhere and that can’t be an address that someone is also trying to use as RAM.
One CAN move things around in high memory (and make the appropriate low-memory global modifications) to squeeze more usable RAM out of the 16MB 24-bit address space (just not 100% of it). The Portable allows up to 9MB of RAM because the Portable puts ROMbase at 0x900000 instead of (as in the SE) 0x400000. This (and the memory map for all contemporary Mac models) is documented in Guide to the Macintosh Family Hardware, see pp. 125-129. https://archive.org/details/apple-g...ple_Guide_to_the_Macintosh_Family_Hardware_2e
You can’t use all 16MB for RAM without 32-bit addressing. It just isn’t possible, because in 24-bit mode, there are only 16MB of addressable bytes in RAM. Unless you add a completely new paging mechanism (or something?) to allow memory-mapped device access to work while also making that same memory address represent a byte of RAM, that can’t work with the mechanics of the vintage Mac operating system. ROMbase has to live somewhere and that can’t be an address that someone is also trying to use as RAM.
One CAN move things around in high memory (and make the appropriate low-memory global modifications) to squeeze more usable RAM out of the 16MB 24-bit address space (just not 100% of it). The Portable allows up to 9MB of RAM because the Portable puts ROMbase at 0x900000 instead of (as in the SE) 0x400000. This (and the memory map for all contemporary Mac models) is documented in Guide to the Macintosh Family Hardware, see pp. 125-129. https://archive.org/details/apple-g...ple_Guide_to_the_Macintosh_Family_Hardware_2e
Yep.
I am eyeing this like a little kid at the candy store. I am antsy, and I can't wait to get it! 
GW4402B - 8MB ROM SIMM for Mac II-series and SE/30 by Garrett's Workshop on Tindie
32-bit clean 8 MB ROM SIMM for Mac II series and SE/30 with System 7.1 ROM disk
www.tindie.com
GitHub - garrettsworkshop/MacIIROMSIMM: ROM SIMM for Apple Macintosh II-series and Macintosh SE/30 machines
ROM SIMM for Apple Macintosh II-series and Macintosh SE/30 machines - garrettsworkshop/MacIIROMSIMM
github.com
The SE was supposed to be able to have more than 4 MB of RAM, though.
Right. However, Apple only connected 22 out of 24 possible lines out of the 68000 to the mobo. That is the main reason for the 4 MB ceiling. Then the ROMBase is set to 4 MB mapping. The 68000 is a hobbled CPU, too, as while it is a 32-bit processor, it only could address 24 bits.
Yet, SuperMac has ROM that addresses up to 8 MB of RAM. You can follow the discussion on this thread here now.
Please share that in this new thread, too.
Answered above. I also just attached the Dracula Happy Mac image at boot to that post.
The other input I can add is that one of the residual problems with the board from 1988 was that it was not compatible with the FDHD floppies...and the logical reason for that problem is because it was based on the earlier MacSE ROM vs. the updated FDHD version -- so only 800K. I will add it to my research list. I now have old ROM and FDHD SEs.
Last edited:
Ooh very interesting about the boot ROM and the FDHD incompatibility. Of course my accelerator has boot ROM integrated but it’s in the entire Mac ROM (since Apple doesn’t care anymore) as opposed to just a little bootstrap. So are you saying that the Prodigy ROM puts up the “question mark disk” icon, loads the boot blocks into RAM at 0x10000, puts up the “vampire Mac” icon, and then executes the boot blocks loaded from disk? And somewhere in the course of all this, the lowmem global pointers are set to reflect the new address map? Wow, interesting if that’s the case. Maybe I should read the Prodigy boot code. I thought it would be just some basic bootstrapping to enable the ‘020 cache, etc. and then just jump into the reset vector in the actual Mac ROM.
I was going at the problem of remapping ROMBase, etc. a little differently. More like Connectix Virtual where it does this soft reboot thing right after the extension loads, and that’s when the lowmem globals are fixed up.
I was gonna do this—and maybe I still should—but I assume the Portable and PB100 just have the right addresses baked in to the ROM. Their ROMs never try to set up the lowmem globals incorrectly so there’s no issue with 9MB RAM. The obstacle on the SE is different since we have to maybe boot up a little bit and then change the globals. Or maybe the Prodigy approach could be used where our ROM runs first to set stuff up, then boots the system.
I'm not sure exactly how much of the ROM the ProdigySE/Prodigy 4 integrates, except to say that it, at least, replaces the boot code. The bin file is on MacRepo, so you can check it. The User Manual also has interesting programming and architecture notes. Prodigy displays a custom splash screen at power-on/startup and replaces the boot Happy Mac. The fact that FDHDs don't work at max capacity points to integrating more (or all) of the (Old SE) ROM vs. less.
The Prodigy SE uses 32-bit addressing and had a max RAM expansion of 32mb. It is capable of using motherboard ("lower") RAM as a RAMDisk (that bridges motherboard and Prodigy RAM). However, beyond 4mb, the board needed a custom PAL and Gate Array.
Connectix had some great products.
The Prodigy SE uses 32-bit addressing and had a max RAM expansion of 32mb. It is capable of using motherboard ("lower") RAM as a RAMDisk (that bridges motherboard and Prodigy RAM). However, beyond 4mb, the board needed a custom PAL and Gate Array.
Connectix had some great products.
Hmm well the ROM is only 32 kB, of which only like 22 kB is used (i.e. not part of a big string of 0xFF bytes). So not too much but more than the minimum 1-2 kB required to boot a 68000 and do something useful. I haven't disassembled it though. Maybe later I'll put it into IDA and see what it does.
Hey, I find it interesting that some of Connectix's software would not work on older Macs, i.e., Ram Doubler, that needed a 030-based Mac. Daniel Knight on the lowendmacs site explained:
1997 – RAM Charger is a sophisticated memory manager for the Macintosh. It works on any Mac (compare this with RAM Doubler, which requires a 68030 or better and at least 8 MB of RAM). The current version works transparently, allowing you to install and forget it on any Mac running System 7 – even 68000-based Macs that can’t use virtual memory or RAM Doubler.
So, other products worked better when the popular Connectix product did not. Yet, I wonder which product mapped the memory better? If not better, did that depend on the processor, system software, and ROMs?
- RAM Doubler
- RAM Charger
- Apple's MMU
Are you using the Freeware/68K version of IDA or do you have the Pro version? ...and I thought the SE ROM was in the 256K bit (27x256, etc.).
Last edited:
Not sure if info's a help here, but can confirm that the Radius Rocket does much the same thing as Prodigy at startup. Rocket/Whoosh screen exhibits after ROM is copied into memory on the Rocket in second boot.
Two reasons I think:
2nd - access from ROM copied to RAM at the clock of the Rocket's local bus is faster as it would be on Prodigy as well?
1st - Radius licensing for use of the crown jewels uploaded from a single Mac host across a bank of Rockets under RocketShare.