When I put together my CHOCHI (http://forum.6502.org/viewtopic.php?f=10&t=2644)and DILDAR (http://forum.6502.org/viewtopic.php?f=10&t=2638) systems, I mapped IO into page $C0 - for no particular reason (maybe because of Apple ][). So far this has worked out well, but I am wondering if it's the best place for IO. Placing it higher up (maybe page $FE?) will create a bigger contiguous space. But I am wondering if it will be more difficult to port software - high pages are usually ROM.

With an FPGA it's pretty easy to put it anywhere (and even make it movable from within the 6502 system). I don't want to wind up with a whole bunch of different configurations as it creates yet another set of branches to maintain, and I am already at capacity.

Do you have any thoughts on the subject? Is there a best location that would be most compatible to your systems? Or is it hopeless to bother?

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

You could make it dynamic, with a user settable offset register.

Yeah, because of my Apple ][ background, I always think of I/O at $Cxxx. The C64 had that weird chunk of RAM there, but that was just the default of many possibilities. That extra RAM could have been useful in BASIC in some instances, if it had been contiguous. If you don't want to split your ROM, and want a sizeable OS or interpreter on-board, $Cxxx seems to be the logical choice. I thought maybe $Dxxx or $Exxx, and let some optional language or DOS extensions fit in below, but that wouldn't be quite as simple to decode. Definitely do-able, though.

Mike

Decoding is not a problem with an FPGA. And making it moveable is something I've considered for a while. The trick is then how to move it... I could set up an IO port for the address, but then where do I put that port?

One crazy idea I had was to monitor the instruction execution to catch an unlikely sequence of instructions, and use it as a magic number to unlock the IO page register. Say, LDA $100 followed by another LDA $100. The following STA (to anywhere) could also write the IO page register. Hmm.

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

You could just start it out at page $C0 like you had, and put the offset register inside the same area. So, a write of $A0 to $C000 would place it at $A000 instead. If you wanted to move it again, write new page to $A000.

To prevent accidental writes messing up all your I/O, you could add an unlock sequence. First write $AA to $C001, and then write new page to $C000.

This is something most people only need to set once and then forget, so I wouldn't make it too fancy.

Daryl Rictor's SBC4 places the IO at 0x200-0x2ff; I think that makes a lot of sense.

I'm considering a design where I would use the same placement of IO, with one decoded IO device used for deciding whether an E(E)PROM should be mapped for read access at the top of of the first 64K. That way, I could have a minimal reset handler that would copy the monitor code from EEPROM into RAM (using wait states), then switch to executing from RAM with 0 wait states.

Still on the planning stage, but at least I have an EEPROM programmer - and hopefully I'll get around to ordering the components and tools that I need, soon.

Thanks! My thinking was to create the biggest continuous memory area possible. Since zero page is fixed at $00xx and the stack fixed at $01xx, having IO at $02xx seemed the best choice. That leaves $0300-$FFF9 open to the user, who can decide what proportion of RAM/ROM he wants.

My DEC-1 Memory Decoder GAL defaults to that configuration, with ROM from $8000-$FFFF and RAM filling in the lower 32k.

That being said, I don't know of any commercially-developed system that used this configuration.

Daryl

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

EhBASIC requirements page lists RAM in the first 1K... Daryl, did you have to move it in your SBC?

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

Sounds interesting ... how about simply a write to $fffx or something? I haven't seen that much.

It's been a while, but IIRC the C64 used locations 0 and 1 to alter the memory map "on the fly".

Mike

I'd almost suggest the approach taken in the 6280 (PC-Engine / TurboGrafx-16 CPU, a 6502 derivative, but branching off before the 'c02 if memory serves), which was to have a set of 8K banks that could be selected between RAM, ROM, and I/O pages, but they managed that by using some eight opcodes to set which bank was which... And I seem to recall that ZPage and Stack accesses always went to the RAM bank, even if the $0000-1FFF bank was mapped elsewhere. Anyway, it was one I/O page, some number of RAM pages (I forget how many, could have been as low as one), and then a lot of ROM pages (or, more accurately, card port / expansion hardware pages).

You could also hardwire the low page to RAM, the high page to ROM, and then only have six selectable banks, and just overlay them on the zero-page or something.

First let me say, great work on the CHOCHI and DILDAR systems, enso!! As for crazy ideas, you know I enjoy those But with this one you'd need to somehow deal with the possibility of an interrupt occurring in the midst of the instruction sequence that's your "key." That's not impossible to do, but here's a variation to kick around:

As Arlet pointed out, the "set IO page" operation isn't something that'll happen frequently. In fact, a single instance is probably sufficient. That suggests a simple solution, one that stipulates that the only way to repeat the "set IO page" operation would be to reset the processor. Looking at things that way, RESET would be the first part of your "key" -- it would set a flipflop whose function is to allow the "set IO page" operation to occur. And after it did occur, the flipflop would be cleared.

The second part of the key could be a LDA $100, as you suggest, but there are other options. For example, the logic could watch for a CPX# instruction, and snag the Immediate operand as the value written to the IO page register.

Obviously the initialization code would have to execute the "set IO page" operation before any other instance of CPX# occurs -- this would be the programmer's responsibility.

Interesting to contemplate! I like how the Hudson Soft HuC6280 has dedicated opcodes that "talk" directly to the memory mapping hardware (as does my KimKlone computer). But it's probably more solution than is required for the problem at hand. And those new opcodes might better be reserved for other purposes anyway.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

My mapping key sequence was simply the first thing that came to mind. As you have pointed out, there are better ways. But I think the idea is valid, and it should not be too expensive to make the IO page moveable.

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

Strange, that's where my buffers go, since it's RAM down there anyway for ZP.

Normally in an FPGA, compare with a constant can be done with bit per LUT input, so a 4-input LUT can compare 4 address bits. But a simple compare with a variable takes 2 signals, so the same LUT can only do 2 address bits, plus you need a FF to store the variable.

To optimize this, you could configure the LUT as 16->1 bit RAM. Feed in 4 address lines, and output a '1' if they match to an I/O area. To initialize the RAM, add a WE signal derived from some magic.

I vote for the $Dxxx memory range, like on the C64. Depending on the user I/O there might be more than 256 bytes of registers.

Alos with 128k RAM, some sort of bank switching might be good.

_________________
http://www.finitron.ca