Arlet, I really like the 16x1 RAM trick! I will try to use it.

It would also be wise to disable interrupts before relocating the IO page.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

The C64 does have data port and data direction registers at $00 and $01. Three of the bits in the data port control the memory map. Any of the ROMs and the I/O area can be mapped in or out as needed. That $Dxxxx block can actually appear as the I/O area, the character ROM, or RAM. An interesting trick is that the VIC-II video chip can only see the character ROM or the RAM, so you can copy the character set to the RAM "underneath" it and alter any of the patterns for a custom character set - without losing I/O or any normally available RAM.

More to the point of this thread though is the C128. There is a dedicated memory management chip mapped in at $D5xx. It can also be used to make quite a few different ROM/RAM/I/O arrangements possible, fifteen of which were "officially supported" maps (oddly enough the BASIC interpreter used one that was not "official").

The thing is it is entirely possible to set a memory map that did NOT contain the $Dxxx I/O block. With the MMU's registers no longer visible, how can a program get out of that configuration? It is avoided by having duplicate copies of the relevant registers appear starting at $FF00 in ALL memory configurations. So every program that wants to play with those registers does so using the permanently visible copies rather than the transiently visible originals.

One further thought - although it may very well be that a memory mapping value is set only once, it doesn't follow that it's going to used only once. If the location of I/O is not fixed, software that needs to perform I/O is very likely going to want to be able to find it whereever it happens to be.

I'm a bit late on seeing this (traveled all week). Back in the 80's I opted for the memory map I'm currently using on my little CPU board. Page $FE is I/O. My reasoning was simple (for me at least); using 32KB of RAM and 32KB of ROM makes for a very simple and compact hardware design, and one page carved out for I/O can handle a lot of chips depending on how you decode it. As my early 6502 systems were the Vic-20 and C-64, having contiguous RAM was nice, so in my view I wanted the most available RAM, easy part done ($0000 - $7FFF).

So, where to put the I/O page, I opted for $FE as I always intended to have a standard JMP table in page $FF as the startup vectors are there and I like the Vic-20 kernel setup where the IRQ/BRK handler is also in page $FF and JMPs to the soft vectors in page $03. This provides a large contiguous chunk of ROM from $8000 - $FDFF which is completely flexible. In some odd way it balances out, the first two pages (zero and stack) are dedicated by the CPU design, as is the top page with the hardware vectors, taking the next page down approach, you lose two pages at each end of the overall 64K map. If you get more creative with the HW design (like Enso's FPGA) then you could configure up to 63.5KB of contiguous RAM with the top page containing a boot loader.

As for porting existing SW, I guess it depends. I was able to port the original SyMon code quickly and had it running on a Vic-20 on the first try. I just changed the 6551 base address pointing to my old expansion board which has an Async port (6551 and 1488/1489) and replaced the kernel ROM with an 8KB EEPROM. For my current two-board system, it required moving some stuff around to free up page $FE, but also worked out fine. I then ported Daryl's SbcOS over and sorta got it working (Basic didn't work).... but there a few odd bits on how the WDC assembler codes vs the assembler he used. I also took the carved downed versions he did recently for another forum member and that was fairly quick and easy. So far, so good for me, but I'm just now starting to get into the programming of it.

_________________
Regards, KM
https://github.com/floobydust

Regarding the LUTRAM trick... While it does provide a 4-bit decoder, writing the RAM is only possible one bit at a time, so to reload a different match value would require a complicated circuit that encodes the 4-bit value to 16 bits, and a state machine of sime kind to write the 16 bits one at a time. I can't think of a good way to do this...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Just write one bit at a time, and fix it in software.

That is sensible. I was stuck in hardware-land.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

You could also add some write-only registers below the vectors in $fffx land. Since that area is typically ROM, writes are generally ignored. When it's swapped out to RAM, we're already used to leaving some space right at the top. I think that's the best place for a few memory mapping configuration registers, which could then control where I/O banks are seen.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I am indeed leaning towards a fixed location in $fffx area. Otherwise, I can imagine situations where you might get stuck with a live system, not knowing where the IO base is and having no easy way (other than poking around) to determine how to do IO.

$FFF0 seems a likely candidate, as the rest of the vectors seem to have at least nominal designations.

Does anyone see a conflict with $FFF0?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

The Native Mode Vectors on the 65816 reside at $FFE0- $FFEF. To keep the widest flexibility, you might consider using the $FFD0 - $FFDF range.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Ah, heck. I've spent the day writing a memory test, and I think I answered my own question. I will try to move the IO_BASE to $200. It's been a royal pain trying to fill and test RAM with a hole in the middle.

With IO out of the way, I can just roll from $300 to $FFFF.

And I will hold off the moveable IO page for now. Smells like trouble.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut