Yeah, the SNES is really a different animal. But dispute its differences it is probably worth a look at their solutions.

_________________
I am working on building a 65816 based computer (for personal use)

Eventual goals include:
65816 CPU up to 14-16 MHz (In Turbo Mode)
up to 16MB RAM (512K on the main board)
Dual YM3438 audio
IEC serial device support

According to the timing chart on page 32 of the WDC data sheet, there is a clear opportunity to latch on to an address well before an actual read or write takes place. According to information on page 56, if the RDY pin on a 6502 is pulled, the CPU will complete a write operation. But a 65C16S will not. That means I can hold that state until things are ready and synchronized. Then the data can sent to or retrieved from the proper location on the 1 MHz bus.

_________________
I am working on building a 65816 based computer (for personal use)

Eventual goals include:
65816 CPU up to 14-16 MHz (In Turbo Mode)
up to 16MB RAM (512K on the main board)
Dual YM3438 audio
IEC serial device support

The 65C02's and 65C816's response to RDY being negated is synchronous to the Ø2 clock and does not occur until Ø2 high. Releasing RDY will cause a restart on the next Ø2 high, never on Ø2 low. While the 'C02 and '816 are stopped with RDY they internally are in the Ø2 high state. This characteristic implies the latch being used to capture the 65C816's bank bits must not open during the fall of Ø2 subsequent to RDY being negated—the latch must maintain the bank bits as long as RDY stays low.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Good point.

_________________
I am working on building a 65816 based computer (for personal use)

Eventual goals include:
65816 CPU up to 14-16 MHz (In Turbo Mode)
up to 16MB RAM (512K on the main board)
Dual YM3438 audio
IEC serial device support

So let me know if you think this is a bad or undoable idea. If I implement a buffer that on startup reads the 1k VIC-II registers and the SID registers. It then keeps copies internally. When the CPU attempts to read those registers it simply fetches them from this buffer. Then when it writes to those registers the buffer is updated and it pushes the changes to the 1 MHz bus on a FIFO basis. This way the CPU never needs to slow down for anything. And if an interrupt is generated by a device on the 1MHz bus then the registers corresponding to that device get force updated. That way registers such as sprite collision and raster interrupts will work.

I'm still just exploring my options at this point.

_________________
I am working on building a 65816 based computer (for personal use)

Eventual goals include:
65816 CPU up to 14-16 MHz (In Turbo Mode)
up to 16MB RAM (512K on the main board)
Dual YM3438 audio
IEC serial device support

This will not work e.g. if someone uses SID's internal fibonacchi generator for pseudo random numbers, or accessing VIC's vertical line register to wait for a specific line.
The register itself will change constantly, content of buffer not.


Video effects require cycle accurate changing of registers. Your solution might generate extra headache to accomplish that. (But one might consider that as extra challenge...)


Besides there can be lots of reads independed from IRQ, there is not sufficient time for that:

Even if force update is limited to registers that can change, and even only refresh buffer of the chip that requested IRQ, you will have to read five registers. That is 5*20 cycles for your '816 - which might happily be done with ISR in that time frame.


What you might do instead: constantly refresh your buffer. So every ten VIC/SID cycles buffer is up-to-date. You even could refresh horizontal line register every other cycle, that should be accurate enough. If you detect horizonzal sync and trigger refresh it could be possible to keep buffer fully up-todate. But CPU writes might disturb this process.

Speaking of horizontal sync - an alternative would be to build an external raster counter, no need to read VIC's internal register. Shouldn't be to complicated to keep external and internal counter content in sync. By that far less buffer refresh would be necessary.

With a number of chips required to build a bus-bridge to run the VIC-II and SID, it might be simpler to use two 65c816's. Run one at 1MHz rate on one side of the dual port ram with the SID and VIC-II. On the other side of the dual port ram run a high-speed 65c816. The slow side could be held in a reset state until the system is ready to allow it to run. Have the slow 65c816 check for requests from the fast side and perform the requests. Some dual port rams have interrupt outputs that could be connected.

_________________
http://www.finitron.ca

So in other words it's realistically not doable to have a buffer. It just doesn't solve anything. Having dual CPUs is a possible option, except that it is not software transparent and as a minimum would add several CPU cycles of delay while it handled the request.

This puts me back to one of my other two options, slowing the CPU down to the 1MHz speed when it accesses one of those memory regions. This is way slower than the CPUs potential, but never slower than a real C64.

The other option is replacing the VIC-II with a FPGA equivalent. Something that mimics the VIC-II in function without its handicaps. While this option can't give full compatibility, it would be close enough most of the time. Some extra pros to that method would include: VGA output, ability to add extra graphics modes, and the ability to synthesize other functions. This is both a simple and complex option.

_________________
I am working on building a 65816 based computer (for personal use)

Eventual goals include:
65816 CPU up to 14-16 MHz (In Turbo Mode)
up to 16MB RAM (512K on the main board)
Dual YM3438 audio
IEC serial device support

Using a buffer that is constantly updated might solve a bit. You still have to look carefully where there the buffer possibly could be not up to date and then either kick in RDY or work around in software.

But on the other hand: your machine will not fully behave like a real C=64 anyway. Programms requiring NMOS undocumented opcodes or NMOS timing might not work. So question is: what exactly is your goal?

Then you can compare possible solutions:
- buffer: CPU running as fast as possible, but quite an amount of work to get it working.
- RDY or clock stretching: CPU being slowed on accessing SID/VIC, but much simpler to implement
- Robs way of a dual CPU system. To me sounds most complicated. On the other hand: hooking 65816 on C64 expansion bus with its own memory, keeping internal 6510 working as kind of I/O slave, freezing the internal CPU to pass data to internal slave when needed...
- replacing VIC: as compatibility as limited anyway, this could be a "cheap" solution allowing for features that are important to you.
- hooking VIC to a 65C22 with some data bus buffers to avoid contention when VIC plays bus master. You would have to make sure by software that reads/writes are synced with VIC-timing, but CPU could keep running and do something instead of RDY-sleep. Concerning compatability this is far off, but alas...

Another wrinkle in trying to externally mirror the registers is that the CIAs and VIC-II have registers which perform an action on read, like clearing latches. These chips are made to have reads & writes occur at the time the programmer specifically intends them, because of side effects like this as well as timing constraints. It would also be too much of a hassle to separate individual magic addresses which are "safe" to mirror and others which have side effects, so I'd say get rid of the mirror.

The SuperCPU model, which buffers writes to any 1MHz address without slowing down (unless the buffer is full), and synchronously waits for a 1MHz read for those addresses on the 1MHz bus, really does seem to be the most usable solution, IMO. CMD had some decent thinking behind many of their designs, for compatibility and usability. Any time you simplify the implementation, you're generally going to be putting more burden on the programmer. It'd be great to find something that simplifies both, but it's hard to see one, especially if you want chip access to work like a C64.

If you want to break a bit from the C64 model, other systems deal with crossing buses by having a memory mapped address + data register which reads/writes to the foreign bus instead of directly interfacing the CPU bus, like the C128's VDC and many game console chips.

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

So many options.

My goal is not 100% compatibility. But I do want a reasonable degree of compatibility. My machine all said and done needs to be able to run software that is timed around the jiffy clock, scanline interrupts. So some games will work. I don't care about illegal opcodes. But having the ability to throw more CPU power at problems would be nice. My machine will also have more than 64K RAM (I have not looked at REU implementation yet)

_________________
I am working on building a 65816 based computer (for personal use)

Eventual goals include:
65816 CPU up to 14-16 MHz (In Turbo Mode)
up to 16MB RAM (512K on the main board)
Dual YM3438 audio
IEC serial device support

So a possible workaround is still a buffer. When written to it passes the information along on a FIFO basis. But when the CPU wants to read one of those registers, it is held with the RDY state while the buffer fetches the requested value. Then when the value is fetched it passes it along and resumes things as normal. The result would be that writes to those registers does not result in a slowdown to the CPU so it can work on other things. But reads take priority and the whole system gets slowed to accommodate the old hardware. I think for my purposes this would be acceptable. It would absolutely never be slower than an original C64, in fact if things were timed correctly you could either write to or read from one of those registers every cycle, or every other cycle, while the real machine would be a 3-4 cycle typically maximum with very optimized code. The obvious exception is if the VIC-II sets its AEC flag, in which case nothing gets written till the 40 cycles are complete, or if reading, the CPU gets suspended. But again, this only happens if a read or write occurs when the VIC is busy.

_________________
I am working on building a 65816 based computer (for personal use)

Eventual goals include:
65816 CPU up to 14-16 MHz (In Turbo Mode)
up to 16MB RAM (512K on the main board)
Dual YM3438 audio
IEC serial device support

One feature I am implementing is bits 6 and 7 on registers $00 and $01. Bit six will toggle between 1 MHz and 20 MHz modes. Bit 7 I'm thinking of using as a firmware flash register.

_________________
I am working on building a 65816 based computer (for personal use)

Eventual goals include:
65816 CPU up to 14-16 MHz (In Turbo Mode)
up to 16MB RAM (512K on the main board)
Dual YM3438 audio
IEC serial device support

If I understand this right, you want to achieve a certain level of compatibility to a C-128 but be able to run the CPU at a higher clock. I would not use a dual-port RAM for this purpose. I'd rather use the logic used by a cache and add as much fast cache ram as there is real RAM and ROM. As long as the 65816 is not writing to memory or accessing registers it can run completely independent of the rest of the computer. In order to make it simple you just need to make sure that the cache is "initialised" at power-on. As long as your cache has the same size as the real RAM/ROM you only need to sync it once and then RAM/ROM reads are always cache hits.

Nope, I don't want or need any C128 compatibility.

I don't see the point of your proposal? If I cache the entire thing, it does exactly what I'm trying to do on a smaller scale but with a bigger performance and compatibility penalty. The VIC-II needs access to 64K of RAM. Dual Port ram solves this issue by allowing the VIC-II to access that RAM whenever it needs to and to do it in an asynchronous way. The catch comes in that the VIC-II, SID, and 6526 chips still need to have their registers, and writing to RAM only writes to RAM, it does not update those registers. In order to have a fast CPU access those things, you have to either slow it down, or have some type of bridge that can facilitate the communication between two independent busses running at different speeds.

_________________
I am working on building a 65816 based computer (for personal use)

Eventual goals include:
65816 CPU up to 14-16 MHz (In Turbo Mode)
up to 16MB RAM (512K on the main board)
Dual YM3438 audio
IEC serial device support