Golden Potato
Well-known member
I’m so glad it worked!Golden Potato, I've tried your proposed ROM patch and can confirm that it works as intended! Now my Mac 512K boots with a 1.5MB RAM expansion and the ROM-INATOR. Once again, you nailed it!
I’m so glad it worked!Golden Potato, I've tried your proposed ROM patch and can confirm that it works as intended! Now my Mac 512K boots with a 1.5MB RAM expansion and the ROM-INATOR. Once again, you nailed it!
A little update: The 74259 sub-circuit can now be activated without causing issues. The Mac boots normally, recognizes the RAM expansion, and seems to function correctly. The only changes I made since the prototype build were to add pull-ups to A22 and A23 and patch the code of the ROM-INATOR ROM at 0x0003F0. Since this circuit was intended for the Mac 512KE (MacPlus ROM) ,I'll keep it activated and set as the default.It looks like it brings pin 15 high/disabled for writes to 0x200000-0x300000. I don't know why off the top of my head though.
The macSnap board doesn't use pull-ups for A21, A22, A23. So, I guess I use it at some point testing the circuit. I eliminate them and everything works fine.A little update: The 74259 sub-circuit can now be activated without causing issues. The Mac boots normally, recognizes the RAM expansion, and seems to function correctly. The only changes I made since the prototype build were to add pull-ups to A22 and A23 and patch the code of the ROM-INATOR ROM at 0x0003F0. Since this circuit was intended for the Mac 512KE (MacPlus ROM) ,I'll keep it activated and set as the default.
View attachment 78727
Yes, eventually.Yes yes I want =)
Would there be ready to use builds for sale eventually?
Already took 512k logic board on my desk![]()
A little update: The 74259 sub-circuit can now be activated without causing issues. The Mac boots normally, recognizes the RAM expansion, and seems to function correctly. The only changes I made since the prototype build were to add pull-ups to A22 and A23 and patch the code of the ROM-INATOR ROM at 0x0003F0. Since this circuit was intended for the Mac 512KE (MacPlus ROM) ,I'll keep it activated and set as the default.
View attachment 78727
Do you have this software? Maybe this part of the circuit has something to do with the RAM disk?There was dove Macsnap software, but that was solely for creating a RAM-disk
Dove only implemented the 74259 in 'E' board models (524E, 548E), which were advertised for the Macintosh 512KE.Was there any special software which came with the MacSnap board? Perhaps the purpose of this memory mapped latch is for a software controlled configuration change?
Quite a mystery, those memory ranges. I will try to dig into the Mac Plus disassembly looking for them. **It's strange that the system would write to these ranges which are mirrors of RAM, so I don't think it would typically do so. In fact, a 4MB mod would not be possible, since 0x200000-0x2FFFFF lands within the 4MB memory range (0x000000-0x3FFFFF) and writes to 0x280000-0x2FFFFF will disable a portion of RAM.
Thank you, it works as expected with 2MB of RAM. What the app does is setting a RAM disk of the preferred size and copying a selected folder into it during boot-up. It also lets you reserve a desired RAM size for cache.
Here is the same link on Internet Archive from before MacGUI locked down their articles to signed in users only: https://web.archive.org/web/20220711020335/https://macgui.com/news/article.php?t=470I read something here about memory map differences between the Mac Plus and the Mac 512K, and something about the RAM space not being contiguous in 512KE models with certain RAM expansions.
Maybe the RAMDisk app makes use of those noncontiguous RAM spaces... I think we need to start digging in detail into the memory map of the 512KE when a RAM expansion is implemented.
Your interpretation is correct! So in summary, the non-contiguous memory problem in early Macs was primarily due to a limitation in the original ROM design. The introduction of the 128K ROM, with its ability to dynamically adjust the screen buffer pointer, addressed this issue. Therefore, it seems the 74259 subcircuit is not directly involved in this particular problem.The noncontiguous-ness isn’t a problem for 512Ke systems, but it is for non-e systems. It’s not a hardware memory map difference, since both types of 512K systems are identical. The issue is with the ROM.
The original 64K ROM has a pointer to the screen buffer in RAM which was coded to be found in only two places which was the top of RAM in 128K or 512K systems. If RAM was added above 512K and the hardware adjusted to put the screen buffer at the new top of RAM (should happen automatically due to address line pull up resistors), the software in the ROM still points to the old location, so the screen buffer was essentially fixed at that point in memory due to the software running in the ROM. The article mentions at least one memory upgrade company building a ROM patch straight onto the upgrade board.
But all of those problems went away with the release of the 128K ROM (Mac Plus ROM). Now the ROM detects all memory and points the screen buffer to the top of the memory found.
At least that’s how I interpreted the article!
Am i right that there is a patched ROMINATOR ROM for the RAM expansion + ROM boot option?