techknight
Well-known member
Thats what ive been saying all along. EAGLE doesnt matter, you patch all that shit out... The hardest part to the whole thing is developing the hardware and figuring out where to "tap in"...
After that, its a matter of patching the different variables in low RAM that tells the OS how much RAM is there. Done....
I havent seen a classic II board in awhile, so its possible the ROM is socketed and an adapter board could be inserted in place of the ROMs, whereas the new board which has RAM expansion also has flashible ROMs with a modded ROM and all the dougg3 additions within it. Youll still need to run an A25 line or other possible lines such as R/W, etc...
The other hard part possibly is when adding the RAM together contiguous, it may move/remap the ROM. if it does, it probably wont work. So its something that has to be played around with.
The address bus is on a 16MB barrier. A24. Technically accessing the 16.1th megabyte, toggles the A25 line, but the bus will just "repeat" as if it were address 0. This may work to our advantage, This will allow system RAM to show up in 2 locations. at 0 to satisfy interrupt vectoring, display refresh, and other stuff. But it repeats itself at the end, and then you map the extended memory right up against the repeated locations, replacing the "ROM repeat" and bingo. you make changes at 0, it gets reflected at the 2nd half of the 16MB chunk. Tell the PMMU to work with ONLY the 2nd 16MB, This allows the OS to still continue to make changes to A-trap handlers, adding.changing vertical blanking stuff, etc... in the upper 16MB. But those changes still point to the same RAM bank. so the "CPU" and hardware is still happy because those changes are being reflected back to the 0 address.
Thats how you solve RAM/ROM address contiguation conundrum without crashing the whole system.
I feel this is the only way to make use of full system memory past 10MB.
Otherwise, your stuck adding RAM at the 2nd 16MB page, and making a program that works like RamDoubler, but uses the additional memory that is segmented. So it still shows 10MB, and then it shows 16MB of Extended memory. So instead of creating virtual memory on the HDD, your creating "virtual memory" in the extended RAM bank. it wouldnt know the difference.
Again, your not thinking 4th dimensional! Total RAM reported by eagle to what? Something has to ask it to report it back. Patch that shit out like I said above! I dont think the MMU is used, the EAGLE probable handles where its mapped in the address map. But that doesnt matter. Use a peice of software to setup the MMU inside the chip with both chunks of memory and their start/end addresses after the machine boots and does its required remap for interrupt vectoring. Since your not modifying the hardware on the lower chunk, everything stays the same. the added upper chunk is put inside the MMU tables, and now you have one contiguous chunk of RAM.From going over the Dev Note carefully, it looks like it would be really difficult to do, the MMU table in the ROM would be easy to handle, but apparently the total RAM amount is reported by the EAGLE gate array, so that would need to be completely reverse engineered,
After that, its a matter of patching the different variables in low RAM that tells the OS how much RAM is there. Done....
I havent seen a classic II board in awhile, so its possible the ROM is socketed and an adapter board could be inserted in place of the ROMs, whereas the new board which has RAM expansion also has flashible ROMs with a modded ROM and all the dougg3 additions within it. Youll still need to run an A25 line or other possible lines such as R/W, etc...
The other hard part possibly is when adding the RAM together contiguous, it may move/remap the ROM. if it does, it probably wont work. So its something that has to be played around with.
The address bus is on a 16MB barrier. A24. Technically accessing the 16.1th megabyte, toggles the A25 line, but the bus will just "repeat" as if it were address 0. This may work to our advantage, This will allow system RAM to show up in 2 locations. at 0 to satisfy interrupt vectoring, display refresh, and other stuff. But it repeats itself at the end, and then you map the extended memory right up against the repeated locations, replacing the "ROM repeat" and bingo. you make changes at 0, it gets reflected at the 2nd half of the 16MB chunk. Tell the PMMU to work with ONLY the 2nd 16MB, This allows the OS to still continue to make changes to A-trap handlers, adding.changing vertical blanking stuff, etc... in the upper 16MB. But those changes still point to the same RAM bank. so the "CPU" and hardware is still happy because those changes are being reflected back to the 0 address.
Thats how you solve RAM/ROM address contiguation conundrum without crashing the whole system.
I feel this is the only way to make use of full system memory past 10MB.
Otherwise, your stuck adding RAM at the 2nd 16MB page, and making a program that works like RamDoubler, but uses the additional memory that is segmented. So it still shows 10MB, and then it shows 16MB of Extended memory. So instead of creating virtual memory on the HDD, your creating "virtual memory" in the extended RAM bank. it wouldnt know the difference.
Last edited by a moderator: