Jump to content

DBJ314

6502
  • Content Count

    7
  • Joined

  • Last visited

Everything posted by DBJ314

  1. The Sun-1 does burst-mode refresh in software. It's NMI is dedicated to memory refresh. The DRAM row addresses on it are the low order bits, so reading from memory sequentially will read each row sequentially. The NMI handler is simply enough NOPs for the CPU instruction fetch to read from every single memory row. It runs every 2 ms. If you do it correctly, you won't need any extra circuitry for handling refresh (at the expense of software complexity and commandeering the CPU every so often).
  2. If your NMI handler happens often enough and has enough instructions, it will probably refresh a significant fraction of the DRAM rows by itself. The STOP instruction, or 68010 loop mode, or long sequences of DIVU/DIVS instructions will probably idle the bus for long enough to cause problems. The worst individual instruction on the 68010 is DIVS. Disregarding the effective address calculation, it takes 158 clock cycles and only has a single memory read in it (the prefetch for the next instruction).
  3. Getting the system to recognize a minimal Enabler is fairly straightforward. The Enabler needs to have a file type of 'gbly' a 'gbly' -16385 resource with the creation date and a list of BoxFlags for the supported machines a 'boot' 3 resource that contains the code to run That's what the 'boot' 2 resource in the System File looks for when it searches for Enablers. Making a functional Enabler is way harder, and I have no idea how to do it.
  4. I did it by reading the reverse-engineered source code of the NanoKernel. https://github.com/elliotnunn/NanoKernel The NanoKernel has a very complicated system to handle paging-related exceptions. A DSI Exception happens. (An Alignment Exception also triggers this code path). The faulting instruction is read from memory. Certain bits of it are indexed into this table, which tells the NanoKernel's highly-optimized (and dense) instruction emulation engine exactly what it is supposed to be doing. Every PowerPC instruction that loads or stores data (and several others, like
  5. On PowerPC Macs, this code will designate a page as "Quiet Read-Only". Writes to that page will be silently ignored, instead of generating an exception. It can cause all sorts of interesting crashes and misbehavior. Most code assumes that when you make a memory write, memory actually gets written. It is thus an excellent tool for making code behave oddly. Using this when Virtual Memory is on is probably a bad idea. Virtual Memory will have no idea that you did this, and might try to move or page out the page you have modified. It has to be compiled as 68k, b
  6. The easy way to use discontiguous RAM is to have the MultiFinder/Process Manager put different Application Heaps in different RAM blocks. Applications don't care about where their heap is, so it's nice and simple. The hard way is to allow a single Application Heap to exist in several RAM blocks at once. To do that, you would need some Memory Manager magic to get it to work at all. In theory, the hard way can be accomplished without directly modifying the Memory Manager. With some very creative non-relocatable block allocations, you could end up with a pointer block cove
  7. It probably sticks the RAM anywhere in the address space it fits, without worrying about keeping it together. The Virtual Memory Manager does this when in 24-bit mode to fit as much RAM as possible in a limited address space. The accelerator might use a similar trick. Here's page 3-7 of Inside Macintosh: Memory.
×
×
  • Create New...