3 ms·

Memory Mapping Issue with M68k Virtual Computer

4 points by mouhamed_ 3y ago

Hey Hacker News community, I'm currently working on developing an emulator for a legacy computer using the m68k CPU architecture. I've encountered an interesting memory mapping challenge that I could use some advice on. In my virtual computer's memory map, the RAM is mapped before the ROM. This is causing a problem with the initial memory reads during boot-up, as they're fetching data from RAM instead of ROM, which is leading to unexpected behavior. Has anyone dealt with a similar situation or can provide some insights into how I might redirect those initial memory reads to the correct ROM location? Are there any best practices or techniques I should consider when working with memory mapping in the context of emulating legacy systems? Any guidance, code snippets, or references would be greatly appreciated. Thanks in advance for your help! lang: c++. memory map: RAM_LOW 0x0000000, RAM_HIGH 0x0D00000, VRAM_LOW 0x0E00000, VRAM_HIGH 0x0F00000, IO_LOW 0x0F00000, IO_HIGH 0x0F80000, ROM_LOW 0x0F80000, ROM_HIGH 0x1000000,

johndoe0815 3y ago
In addition to the initial stack pointer and reset vector (at addresses 0 and 4, respectively), the 68000 has non-relocatable exception vectors in subsequent memory locations - this is one of the major reasons why you want these addresses to point to RAM (the 68010 and following fixed this by introducing the vector base register VBR which allowed to relocate the exception vector base address). On real 68k machines, hardware took care of mapping the ROM starting at address 0. Often, the ROM was mapped to 0 and its actual location in the system's memory map simultaneously, so the reset vector could point to init code at the actual ROM location. To switch off the mapping of ROM to 0, either a special memory-mapped I/O address was used to switch off the mapping (so the ROM code would write to that location) or hardware monitored accesses to ROM and switched the mapping off at the first access. For example, the original Mac used the vOverlay port bit in one of the SY6522 VIA I/O ports to switch off the mapping, see https://macgui.com/news/article.php?t=493 https://macgui.com/news/article.php?t=493 for details.
- johndoe0815 3y ago
  The instruction to switch off the vOverlay bit can be found at location 0xce in the Mac Plus ROM listing: https://www.bigmessowires.com/rom-adapter/plus-rom-listing.asm https://www.bigmessowires.com/rom-adapter/plus-rom-listing.a... The VIA vOverlay bit is connected to one of the PALs (early programmable logic chips) in the Mac, the BMU1. The relevant equations to create the RAM and ROM chip selects are (from http://www.retro.co.za/ccc/mac/ReverseEngineering/PALs.html http://www.retro.co.za/ccc/mac/ReverseEngineering/PALs.html): /ROM := /A23 * A22 * /A21 * /AS ; 0x40 0000 - 0x5F FFFF + /A23 * /A22 * /A21 * /AS * OVERLAY ; 0x00 0000 - 0x1F FFFF when OVERLAY enabled + A23 * /A22 * /AS ; 0x80 0000 - 0xBF FFFF + A23 * /A21 * /AS ; 0x80 0000 - 0x9F FFFF and 0xC0 0000 - 0xDF FFFF /RAM := /A23 * /A22 * /A21 * /AS * /OVERLAY ; 0x00 0000 - 0x1F FFFF + /A23 * A22 * A21 * /AS * OVERLAY ; 0x60 0000 - 0x7F FFFF when OVERLAY is enabled Here you can see that the OVERLAY bit coming from the VIA is 1. used to additionally map the ROM at address 0 and 2. used to map RAM to 0x600000 (when OVERLAY is enabled) and to 0x000000 (when OVERLAY is disabled).
- mouhamed_ 3y ago
  Thank you so much for the explanation and the valuable information! I really appreciate your help.

4 points by mouhamed_ 3y ago

johndoe0815 3y ago

In addition to the initial stack pointer and reset vector (at addresses 0 and 4, respectively), the 68000 has non-relocatable exception vectors in subsequent memory locations - this is one of the major reasons why you want these addresses to point to RAM (the 68010 and following fixed this by introducing the vector base register VBR which allowed to relocate the exception vector base address). On real 68k machines, hardware took care of mapping the ROM starting at address 0. Often, the ROM was mapped to 0 and its actual location in the system's memory map simultaneously, so the reset vector could point to init code at the actual ROM location. To switch off the mapping of ROM to 0, either a special memory-mapped I/O address was used to switch off the mapping (so the ROM code would write to that location) or hardware monitored accesses to ROM and switched the mapping off at the first access. For example, the original Mac used the vOverlay port bit in one of the SY6522 VIA I/O ports to switch off the mapping, see https://macgui.com/news/article.php?t=493 https://macgui.com/news/article.php?t=493 for details.

johndoe0815 3y ago
The instruction to switch off the vOverlay bit can be found at location 0xce in the Mac Plus ROM listing: https://www.bigmessowires.com/rom-adapter/plus-rom-listing.asm https://www.bigmessowires.com/rom-adapter/plus-rom-listing.a... The VIA vOverlay bit is connected to one of the PALs (early programmable logic chips) in the Mac, the BMU1. The relevant equations to create the RAM and ROM chip selects are (from http://www.retro.co.za/ccc/mac/ReverseEngineering/PALs.html http://www.retro.co.za/ccc/mac/ReverseEngineering/PALs.html): /ROM := /A23 * A22 * /A21 * /AS ; 0x40 0000 - 0x5F FFFF + /A23 * /A22 * /A21 * /AS * OVERLAY ; 0x00 0000 - 0x1F FFFF when OVERLAY enabled + A23 * /A22 * /AS ; 0x80 0000 - 0xBF FFFF + A23 * /A21 * /AS ; 0x80 0000 - 0x9F FFFF and 0xC0 0000 - 0xDF FFFF /RAM := /A23 * /A22 * /A21 * /AS * /OVERLAY ; 0x00 0000 - 0x1F FFFF + /A23 * A22 * A21 * /AS * OVERLAY ; 0x60 0000 - 0x7F FFFF when OVERLAY is enabled Here you can see that the OVERLAY bit coming from the VIA is 1. used to additionally map the ROM at address 0 and 2. used to map RAM to 0x600000 (when OVERLAY is enabled) and to 0x000000 (when OVERLAY is disabled).
mouhamed_ 3y ago
Thank you so much for the explanation and the valuable information! I really appreciate your help.