I am working on making a homebrew computer using a 65816 chip running @ 20 mhz. This of course introduces speed compatibility problems on the hardware level. I am designing my system around a dual port RAM design, which solves one issue, namely, now the VIC-II chip has unrestricted access to the entire 64K range through the second ports on the RAM. This means no CPU halting to share the memory bus. And the two buses can run at different speeds without issues.

However here is where my hangup is. My project also calls for dual SID chips. The SID chips need to be mapped into the factory C64 IO space. Obviously this represents an issue that the dual port RAM does not solve. The more I think about it, I'm pretty sure the CPU will have to slow down for IO and SID access.

So to recap, the CPU is going to be clocked @ 20 MHz, the VIC-II will be clocked using the original crystal and will generate a 1 MHz clock for SID (and IO). So my question is, what is the simplest way to handle this issue. I am not an electronics engineer by any standard. For me this project is more a learning project. I do however want the solution to be transparent to software.

_________________
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

Here's what I'm thinking. If I have some sort of chip interface mapped to the IO,SID, and color ram memory addresses on the 20MHz bus. When it intercepts, it toggles the RDY pin of the CPU to halt it, then it writes to these same address on the 1MHz bus. Once the task is complete it resumes the CPU. This approach would be discreet as far as software is concerned. I'm not sure how to actually do this however. The approach would also need to work for both reads and writes. When reading, it halts the CPU, then fetches the data from the appropriate chip on the 1 MHz bus, then sends it to the CPU on the
20 MHz bus and resumes the CPU.

Obviously this needs to apply to ROMs as well, if they are banked in. Obviously with ROMs they can't be written to, so writes to ROM are written to RAM and the CPU is not halted. If the ROMs are not banked in, then RAM is read as normal.

_________________
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

Welcome, KhanTyranitar -- sorry I'm slightly late in greeting you. It's nice to hear about your project. Some rethinking may be in order, however. (Not to worry -- in the early stages this is normal. )

I am not a VIC or C64 guy, and I suspect some our best expertise is presently on vacation! Anyway, I had a quick look at the data sheet for the 6567 VIC-II and also that for the 6560 VIC. To me it seems the dual-port RAM idea leaves a few important issues unresolved, including the question of how the CPU can access the VIC registers (given that the CPU address and data buses don't attach to those for the VIC -- AIUI, the VIC buses attach only to the dual-port RAM). Yes, the VIC would be able to take control and access the dual-port RAM and read video data from it. (BTW I notice the video data is 12 bits wide, not 8, so that needs to be accommodated somehow.) But the VIC also has a passive role where it responds to accesses from the host CPU. If you made provision for this then I overlooked it.

I can think of two alternatives to the dual-port RAM approach.

• have one address bus and one data bus, to which the VIC and the CPU both connect. During the first half of each cycle the CPU would pause while the VIC fetches video data from the RAM. The second half of the cycle would belong to the CPU. According to what the program dictates, the CPU would either access a VIC register or, at the faster rate of its own 14 MHz clock, do as many as seven RAM accesses.
• have two address buses and two data buses, thus allowing independent and concurrent operation of the VIC and the CPU (there would be two RAM's). Tristate buffers -- and some moderately complex synchronizing logic -- would tie the two separate systems together when it's necessary for the CPU to access VIC registers or the VIC RAM.

I suggest you study the C64 and VIC20 and see what's been done there. The first stage of your planning should be a very coarse schematic. Certain details can be omitted but it needs to show all the buses connections, and should let you visualize every step of everything that needs to happen. A schematic of the buses can also be immensely valuable when attempting to communicate your plan to others.

cheers,
Jeff

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

The VIC can read data from anywhere in a 64k area. But it also has fixed registers mapped to permanent locations located in the same block as the IO space. So the same solution that can access the 1MHz bus will also take care of the fixed registers. That's what the extra 4 data bits are for, they access the fixed color RAM. So the VIC chip actively reads from RAM to access things like character data, sprites, bitmaps, etc. the remaining registers are written to by the CPU just like RAM.

[quote=] I can think of two alternatives to the dual-port RAM approach.

• have one address bus and one data bus, to which the VIC and the CPU both connect. During the first half of each cycle the CPU would pause while the VIC fetches video data from the RAM. The second half of the cycle would belong to the CPU. According to what the program dictates, the CPU would either access a VIC register or, at the faster rate of its own 14 MHz clock, do as many as seven RAM accesses.
• have two address buses and two data buses, thus allowing independent and concurrent operation of the VIC and the CPU (there would be two RAM's). Tristate buffers -- and some moderately complex synchronizing logic -- would tie the two separate systems together when it's necessary for the CPU to access VIC registers or the VIC RAM.

[/quote]

I have been looking at that already. And it is a viable option. However I find the dual port ram has many advantages. One, no CPU stealing. See the problem is that as you state, according to what the program dictates, most C64 software doesn't dictate, it was designed around the 1 MHz speed. The VIC2 needs more than just stealing the first half of a cycle. In the stock form, it also steals 40 cycles every 8th scan line while it fetches the next 40 characters of data (more if sprites are being displayed). In my dual port ram, the VIC can do its thing without stealing any cycles. The only loss I can see is when the CPU writes to or reads from the fixed registers located in IO space. But this has to happen anyway.

I have been laying out my rough schematic, which is where these questions are coming from. The C64 is among the harder 8 bit systems to run at a higher clock speed. I have tried looking at what the SuperCPU and other accelerators do, but their solutions are somewhat secret. It appears the SuperCPU users some Altera chip to interface to the C64s 1 MHz bus speed.

_________________
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

I thought the CPLD in the SuperCPU has been fully documented & reverse engineered, so keep nosing around. At the very least, you could look into the VICE implementation to see how it's emulated.

Its primary feature is a one-byte write buffer to allow non-successive writes to run at full 20MHz speed, but I'm not exactly sure how it manages the wait states for slow reads/writes at the CPU pin level.

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

I'll see what I can find. That sounds close to what I'm after.

_________________
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

You can also do it with discrete components (I did), but you want a master clock that syncronizes with the videochip. In a Vic-20 the 6502 and 6560/1 access the RAM at the same time, but one uses rising clock edges while the other uses falling clock edges (so RAM access happens at >2MHz speed). This can only be because the CLK2 signal to the 6502 comes OUT of the 6560/1, so you don't get syncronization issues.

For the C64 you probably don't have this problem as the 6567 and alike will need the whole bandwidth towards RAM access. E.g. the 6510/6502 has to be halted as long as the 6567 access the video memory since it needs more bandwidth. Happily it has a builtin buffer (which the 6560/1 didn't have) so it doesn't need to re-read the same character line 8 times in a row. Thus, 80% of the time the 6510 runs at full speed (after DRAM update cycles have been accounted for).

Now, to run the 65xxx at higher speeds along a 656x you need to syncronize those two chips. In the SuperCPU, the external CPU doesn't really need to bother with the VIC chip since its only accessing the internal RAM of the C64. So it only needs to bother with the internal RAM speed and does so by proloning the high-state of the clock (to around 450ns I think). This can only be done since the 65C02 is happy with whatever speed it gets. There is also some glue logic in the CPLD of the SuperCPU which prevents access as long as the VIC uses the RAM.

Good luck!

I know exactly how the SuperCPU works, and will be more than happy to help. My first guess would be to scrap the VIC idea, and go with linear video memory. Make life easier. PM me for more details about the SuperCPU. I'm your guy on that.

So how does linear video memory give me C64 compatibility?

_________________
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

Not make the 65816 have some features of the 6510, I followed this guide

http://www.baltissen.org/newhtm/10to816.htm

In this he tristates to grab a particular access to a memory location, in this case $01. He uses a 6526 to then generate the IO pins the 6510 has. In my case I followed his guide substituting a 65c22 so that it can run at a faster speed. His circuit also produces the PHI1 and PHI2 clock signals so things will behave. But in his guide things are still working on the 1 MHz signal generated by the VIC2.

Using a CPLD or FPGA is there any reason you couldn't do this to a whole range of addresses?

From my way of looking at it, the main things that only operate at the lower speed is the memory locations from $A000 to $FFFF because that's where ROM and IO reside. If I use ROMs that can operate at a higher speed then I only need to worry about the IO locations from $D000 to $DFFF. The issue is not just the VIC chip, it's the IO devices (2x 6526 or equivalent) and the SID chip(s) as well. Those have to run at 1 MHz regardless of what the CPU is clocked at.

If I use the dual port RAM it solves the VIC chips behavior to access any RAM whenever it pleases. In the dual port RAM I am proposing it can both access at any time without competing with the CPU, and operate at its own speed. But dual port RAM does not solve the need for the CPU to slow down for that IO access to the locations I listed above.

_________________
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

What I do is use a linear backbuffer in order to process graphics easier. When a screen is "dirty" I blit only the dirty area to VIC RAM, converting to VIC format on the fly. Doing it this way allows both the PC ".bmp" format -- and C64 compatibility.

If I can remove the 6526s from the equation, that may make things a little easier. Basically if I use 65c22 for all the IO and connect them to the 20 MHz bus, they can be both written to and read from natively. That just leaves the SID and VIC chips on the 1 MHz memory bus. But since neither of those chips ever write to memory then my buffer only has to work one way. When the buffer writes to the 1 MHz bus, it also writes to the 1 MHz side of the dual port RAM. So any attempt to read those addresses will simply read from RAM at full speed and return the last value that was written. I can see that might not work with the sprite collision registers.

So if I latch to the affected address range, which is just the SID and VIC Registers, and trigger some kind of wait state then things should work discreetly.

This buffer chip could also perform other glue logic functions.

_________________
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

Ok, so I'm finding lots of good suggestions. The problem is still complex, but I think I'm getting closer to a prototype I can build.

I found a possible solution for a CS/A 65816 running at 8 MHz. His solution was to latch the IO addresses and use the RDY pin and some logic to slow the CPU to 1 MHz. With the right components I could do the same. In my design I would still use a dual port 64k RAM to overcome to CPU cycle stealing problem. And CPU cycle stealing will still happen if the CPU attempts to access the 1 MHz bus during the time the VIC2 chip is reading. A possible solution is to isolate the VIC2 address and data lines from the rest of the 1MHz bus so that access to the SID or other 1MHz devices won't be affected. At that point only access to the VIC2 would be affected.

The timing is very critical and requires that a PHI1 and PHI2 clocks are in correct sync. And having them keep in sync to the 1 MHz clock is probably essential too. This means I will probably need to use my 1 MHz clock to generate the 20 MHz clock signals.

_________________
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

Another source of info could be the SNES. Its 65816 has to interface with 3 different bus speeds, depending on which part of the cartridge or I/O it's talking to. Unfortunately, that's the depth of my knowledge of its bus(es).

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

It should be noted the SNES does not have a "real" 65C816 in it. Most of the 65C816 ISA is present, but the hardware interface is sufficiently different that it's really a different device.

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