mk2 memory mapping unit - nealcrook/multicomp6809 GitHub Wiki

If you add an external SRAM to multicomp the usual component to use is a 128KByte device. It seems a real shame to tie-off the upper address line.

I designed 2 simple memory-mappers. The first design is described in simple memory mapping-unit and works fine. However, after I got it working I read how the Tandy CoCo mapper worked and decided to do a mk2 design that was a functional superset of that design. Various capabilities of the mk2 memory mapper are used by CamelForth when booting/starting all of the other pieces of software that are stored on SDcard. The ability of the mk2 memory mapper to access >64Kbytes of RAM are used by the Level 2 NitrOS-9 port and the Fuzix port.

The (mk2) memory mapper provides these capabilities:

  • Through a pair of registers it allows any 8Kbyte block of RAM to be mapped to any 8KByte region of the processor address space
  • Each 8KByte region can be R/W or can be set RO
  • The ROM can be disabled (underlying paged RAM can then appear)
  • Supports 1 or 2 SRAM devices, upto 127 blocks of RAM (1MByte)
  • Provides 2 independent sets of mapping registers, as per the CoCo design
  • Supports an (optional) fixed memory region at the top of memory, as per the CoCo design. I call this feature "fixed RAM top", FRT.
  • Through a third register it provides a controllable timer interrupt @50Hz with a highly efficient register interface.
  • Through a spare control bit it provides a software-generated NMI specifically timed so that is can be used to provide a hardware SingleStep capability.
  • The protection, mapping and ROM disable does not interfere with the I/O devices in the high address space

The memory mapper is decoded in the same address space as the SDCard controller. It uses the same chip-select. In the 8-byte region selected by that chip-select it uses the 3 addresses that the SDCard does not. The mapper registers are write-only, the timer register is read/write.

VHDL Changes

The memory mapper requires external wiring changes to connect extra SRAM address lines to FPGA pins (and a second chip-select, if appropriate). For a 128KByte device, connect a new FPGA output to the A16 address line of the SRAM. Change sramAddress output from (15 downto 0) to (16 downto 0) and associate the correct output pin with the new signal.

Grab the mem_mapper2.vhd file, add it to the files list and edit your top-level to include an entity declaration like this:

mm1 : entity work.mem_mapper2
    port map(
            n_reset => n_reset,
            clk => clk,
            hold => hold,
            n_wr => n_WR_sd,
            n_rd => n_RD_sd,

            dataIn => cpuDataOut,
            dataOut => mmDataOut,
            regAddr => cpuAddress(2 downto 0),

            cpuAddr => cpuAddress(15 downto 13),
            ramAddr => sRamAddress_i(18 downto 13),
            ramWrInhib => ramWrInhib,
            romInhib => romInhib,

            n_ramCSHi => n_sRamCSHi_i,
            n_ramCSLo => n_sRamCSLo_i,

            n_tint => n_tint,
            nmi => nmi,
            frt => n_LED7 -- debug
    );

The chip select for the internal ROM has to be tweaked accordingly:

	n_basRomCS <= '0' when cpuAddress(15 downto 13) = "111" and romInhib='0' else '1'; --8K at top of memory

Overview of MMU Operation

This is described in the Programming guide

MMU Programming Interface

This is described in the Programming guide

Timer programming interface

This is described in the Programming guide