Clock qualified chip selects on a RAM can wreck havoc ..... I did this and when I changed chip manufacturer the system became really unstable. It turned out - after a long search - that it created power supply issues that were so strong it led to incorrect data being read.

So, my lesson learned is to use unqualified chip selects and maybe even /OE, but clock qualified /WE to make sure writes work ok

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I agree with you, at least for systems that you want to go fast, but why do you bring it up?

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I had that in a system with 1 MHz.

I brought it up as the post before that quoted another post talking about un/qualified r/w strobes and select signals.

Just hoped it might help. Sorry if it was a distraction

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Aaahh, I see that. I'm planning to go fairly fast with this system (14 - 16Mhz), so I'm going "by the book" with early chip selects and ø2 qualified RD\ / WR\ signals. Michael's proposed design is even faster - ROM is always selected, and RAM is only de-selected for I/O operations.

ø2 qualified chip-selects should be fine for a 1MHz system though. That must have been some strange RAM you were using!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

BTW, if your design is meant to copy ROM to RAM and then map out ROM first thing then the following variation allows for inserting an I/O page anywhere in address space (pages $02..$FE, inclusive) instead of just in pages $02..$7F. The I/O page is mapped out of address space when ROM is active to avoid contention when the I/O page is in the $80..$FE range.

A question, if I may? How are you using this banking method? Does your ROM code copy a block from ROM to RAM in lower memory, turn off ROM, then copy a monitor or bios into the RAM now available in upper memory?

If ROM is active only briefly after reset, copying ROM to RAM needs no glue logic. I/O resides in memory space previously occupied by ROM, also does not need glue logic. This is the basic of zero glue-logic 6502 SBC.

viewtopic.php?f=4&t=6455

https://www.retrobrewcomputers.org/doku ... 6502r1home
Bill

This is similar to what I started with; I made a couple of changes for two reasons: first, I only want a half-page of I/O space so that I retain the option of mapping it into Zero-page; and second, I wanted to have 8 device selects so that there would be some spares available for future expansion.

Since this system will mostly run from RAM, I think the most sensible thing to do is keep the RAM selected all the time and have decoded read/write signals, the way you have it a couple or so schematics ago. However, I will need clock stretching to interface with my ACIA (it's a 4MHz part) and also for the initial copy-from-ROM. The clock stretcher needs a (fairly early) enable signal, so I would have to do all that decoding anyway. Later today (or maybe over the weekend) I'm going to try a "clean room" redesign from the same concepts see if I can keep RAM enabled all the time.

I haven't written it yet, but my plan is to do it in software more or less like how you describe. In my imagination, the RESET code will install a little program in the lower 32K of RAM that will copy the upper 32K of ROM into the upper 32K of RAM. I can imagine two versions: one that uses a buffer (say 16K) of lower RAM so that the data path goes ROM -> LOW RAM -> HIGH RAM. A variation of this one uses a (tiny) ZP buffer for more compact / faster code. On the other hand, it's really easy to bank the ROM in and out, I might could just do the whole job one byte at a time using a register.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Hi Bill,

I followed that thread when it was current, and then read it again last week. It's really impressive. Conceptually, I kind of get your technique, but I'm not sure I understand it well enough to modify it.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I whacked this out this afternoon: I think it would work, but I don't think it's an improvement. The bottom line is that every access is bounded by how long it takes the `688 to decide whether or not we're doing I/O. As long as the rest of the decoding logic is done by the time the `688 finishes with that it really doesn't matter if the RAM is selected all the time or not. I do kind of like in this version how the I/O signal flips back and forth between the line decoders though. For some reason that's very satisfying.

Edit: Actually, as I'm going over this again, the limiting factor is the entire I/O select logic, not just the `688. Chip selects have to be finished before Ø2 for the VIAs to work, so no matter what happens with RAM/ROM, the top speed with this design is going to be 12.5MHz. I must have been sleepy when I did the math yesterday to think I could get away with a 30ns pulse width.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

For clock stretching, the decision to do that can be very late, even close to the fast phi2 going low again - just make sure fast enough to not glitch phi2 to low.

If your ACIA is a four MHz part, your access from the CPU can start at any phase of the ACIA clock. So you have variable duration of stretching until the ACIA ends the transfer.

I did this even with two clock domains in my PET816 CPU board that you can plug into a Commodore PET CPU socket. The 65816 was running 8 MHZ (or 10, don't remember) derived from an own clock oscillator - but accesses to the main memory of the PET were synchronized to the main PET phi0 coming from the CPU socket.

If CPU and ACIA clocks are derived from the same clock source that should be easier though

Edit: 10MHz http://www.6502.org/users/andre/pet816/gallery.html

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/