The C256FMX has a 65c816 running at 14.3MHz, although this model is now discontinued. The lower-cost version of this (C256U) runs at the same speed, and may return at some point (I think).

well like BruceRMcF said, it very likely is because of the RAM speed.
IMO, ROM or Peripheral/IO speed should never be a reason to overall slow a system down.

the general rule i follow with CPUs like these is that you don't want to run them as fast as the slowest component of the system, you want to run them as fast as the fastest component and then slow them down for everything slower than that.
that's how may 65816 SBC does it for example, 70ns Flash and 10ns SRAM, and it runs fine at ~15-20MHz (with clock stretching whenever ROM or IO is accessed)

usually the ROM is the slowest part which is why there are so many threads on here about shrinking or completely removing ROMs from Systems, having something else preload a program into high speed RAM before the CPU starts executing.

W27C512 is a 45nS flash, so it is capable of 10MHz operation with W65C02; it can be reliably overclocked to 14MHz. You can build a 6502 computer without glue logic, so prop delay over glue logic can be eliminated.

W65C134 is a 65C02 microcontroller with built-in fast ROM so it can run 14MHz using a fast external RAM.

Dual port RAM is fairly fast, so you can run to 20MHz. You can also bootstrap from FIFO or CF disk, although I have not figured out a state machine for fast CF bootstrap using standard TTL logic.

If you'd entertain 22V10 as the ROM, you can run W65C02 to about 25MHz.

Above 25MHz I prefer CPLD because it it a 5V part. FPGA is mostly 3.3V and need voltage translation which slow it down.
Bill

Yes, but that's you. I suspect you are one of those precise people.

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

They have an 8KB High RAM window in the 16bit memory map, so an 8bit latch for the high address lines of the HighRAM gives 2MB, and the Dev Board has sockets for four 512KB SRAM ... so using 128KB would be 4-16 of them.



If they didn't stick with the "as much DIP as possible", it seems like they could replace most of the glue logic in the system with a CPLD. And of course if I filter the 512KBx8 parallel 5v search at Mouser by surface mount, I see a 10ns surface mount 512KB for under $4.50 with over 500 in stock, and a 25ns surface mount with over 5,000 in stock.

The cost reduced X16 console seems like it will be all-surface mount, with a soft core YM2151 on an FPGA replacing the old-stock / pulled YM2151 chips, so it seems likely to have a 25ns or 10ns SRAM soldered onto the board, and any YM2151 speed constraint seems like it would be able to be eased as well, but since the Console is going to aim for compatibility with the first generation Dev Board, the design isn't likely to be reworked into, eg, 12.5MH RAM full speed zone and a 6.25MHz ROM / YM2151 speed zone.



Well, it's Dave's dream computer, My preference would have been 65816 from the outset and 12.5MHz to have the system clock in sync with the internal 25MHz pixel clock of the VGA video chip, with clock stretching to 6.25MHz for the ROM part of the memory map, but different people have different dreams. I do know that the clock speed selection circuit is based on a counter, so the choices are powers of two, but I don't know whether accommodating the YM2151 and its 4MHz clock made the next option after 1/2/4/8 into 2/4/8/16, where 16MHz just isn't practicable with a 65xx bus with 55ns SRAM.

However, since he also runs the smaller 8bit Keys channel, it wouldn't be surprising if he was willing to compromise top speed to accommodate the YM2151 -- an 8channel 4-op, 4 waveform, ADSR envelope FM chip supports a lot of Genesis type chiptunes that would be hard to convert to play on Vera's 16 channel PSG without hardware ADSR envelope. Some people might not realize that an FM chip with only sine waveform needs to use two operators to emulate triangle, sawtooth or square waves, so for a number of patches, 4-waveform, 4-op FM is akin to 1 waveform FM with 5 or 6 ops.

I got some ideas, that I want also use somewhere, so if there are some holes, please point them out for me

- About standard ICs and prefilling RAM from slow (EEP)ROM - I would (on boot) cut out the CPU (halt+BE pin or so), make my slow enought clock (divide with D-flops or counters) then use combination of '590 (8-bit binary counter with output register) for low byte and two '161 (Presettable synchronous 4-bit binary counter) for high byte of address, connect RAM and ROM addresses and data together and set RAM to Write. Then the counters would go up to FFFF and effectively copy the ROM to the RAM at speed of slow clock. Then the whole ROM and counters would be cut of buses forever (well to next reboot) by setting HiZ (not select) where possible, or by '245 (Octal bus transceiver; 3-state) where needed and let the CPU start

- paralel system - I plan to use dedicated RAM chip(s) which could be connected either to buses of CPU or to buses of Coprocessor ('245 on both sides, on address, data and signals (Read,Write, chip select ...)) (with some device/register/address cell to set, who can connect it just now) to be used as 'block device' (or poor man's DMA), so CPU will write there something like "give mi file <FILENAME>, from <offset>, <maxsize>" and deassert the RAM and later assert the RAM and read "Here is <actual size> of data, with <status>: <up to 32KB of data>". Or send "put this to videoRAM <offset>,<size>,<data>" or send "interpret this <cmd>,<cmd>...."
(I am targeting lower speeds, so you may need for this some wait states or so, but it would still allow more independent CPUs work at the same time, with just such "memory sharing" (playing ping-pong with this RAM). In my setup also opening all then '245 gates will allow for coprocessor to pre-fill CPUs RAM/ROM, say from file.)

_________________
http://micro-corner.gilhad.cz/, http://8bit.gilhad.cz/6809/Expanduino/Expanduino_I.html, http://comp24.gilhad.cz/Comp24-specification.html, and many others

This question might belong in another thread not sure.

Anyhow,



This can be done, the technique is called "shadow RAM" and has been done for years in PCs. While it certainly can be possible to build it up with just 74 series logic, you might find that the complexity starts to get tricky; especially if you have to use multiple counter ICs to cover the whole range of memory. I'd probably use a CPLD to handle this.

I see two potential ways of possibly doing this:

1) Copy a byte of ROM into the CPLD, and then push it back out to RAM on the next clock cycle.
Would be slower, but would be easier to wire up.

2) Wire the address lines for the RAM and ROM separately and let the byte copy directly from ROM to RAM.
More complex to wire up, but you could copy one byte per clock tick.



My mind has drifted to something like this a fair amount when considering the devices I would like to build for my projects. I invariably end up thinking about adding a FIFO buffer to the device, and then kind of realize that what I really need is an actual DMA.

The other option is to have your coprocessor do this. You'd give your coprocessor space on the main CPU address bus and transfer bytes to it, and then let it sort out how to deliver the bytes to the bits on the other side. This is effectively what the VERA module does on the X16.

Another simple way to put data into RAM is rig up a simple battery-back circuit to retain the memory contents as RAM is moved from TL866 programmer to your circuit board. TL866 can write the bootstrap software into RAM then move the RAM to the target circuit board. Now the RAM has the basic software to boot, it can load more software. The circuit board has more permanent battery-backed circuit for RAM. To protect the boot section of RAM, a bank can be write protected.
Bill

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Compared to the alternative of booting into a slow mode that also diverts reads, but not writes, to ROM, and doing a block copy with identical source and destination, and then the latch that triggers fast mode also directs reads to RAM ... what is the problem being solved? Is it that the boot-up with that approach is too slow?

For example, the bootless start-up that reads a boot code into RAM from a serial flash can addressing the In-Service-Programming issue by having a serial flash programming port that the source of new contents for the flash can use, so the "remove EPROM from SBC, place in programmer, program, return to SBC" cycle is upgraded.

Is it the amount of ROM that you have to copy means that having the CPU doing the copying gives a boot-up that is going to be annoyingly long?

A forth (and probably the easiest solution, which I should have thought of at first) is to have code in ROM that just copies itself into RAM and then jumps to there.

In case where you have ROM and RAM, the best way to maximize ROM access time is to enable it for the entire memory space during bootstrapping. 6502 changes it’s addresses almost immediately after the falling edge of clock, so you’ll have stable addresses to access ROM from falling edge of clock to almost the falling edge of next clock. For 45nS W27C512, it can run to about 20Mhz like that. Once ROM contents is copied to RAM, you can transition by turning on both RAM and ROM and there won’t be contention because both devices have the same values; then you can leisurely shut off ROM and leave RAM running.
Bill

The down-side of this is that the ROM remains as part of the memory map, and that means it's up at $FFFx where the reset, nmi and irq vectors are, so you will need clock stretching to access those locations and it will slow down IRQ and NMI processing. Maybe not enough to notice, but it still needs complexity.

Overlaying the ROM with RAM and doing a copy to itself then disabling the ROM seems like a better way forward...

Or don't have ROM at all

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Yea, I was thinking in terms of the complexity of the circuitry. You can do it in software this way pretty easily, and the circuit wouldn't be any different than normal. As you note however, you lose that spot in the memory map. There are various ways around this that I can think of, paging for example, but that adds more complexity to the circuit.

If you don't mind the circuit complexity, absolutely, go for it. (Hence my first two solutions)



Yea, ROMless booting seems like voodoo to me still.

That's what I'm thinking. And there is no address decoding to do, as long as active high ROM_latch_Q lead to the /ROM_OE and an active low complementary /ROM_latch_Q lead to /RAM_OE ... if the ROM is smaller than the address space, just don't program the ROM to wander into the mirrors of its contents.

If the variable speed clock is from a loadable counter, ROM_latch_Q and /ROM_latch_Q also provides the change in the load lines ... with one half of a 74x74, a single /Preset or /Clear may well generate a seamless transition from slow clock, Read ROM, Write RAM, to fast clock, R/W RAM.