Moving beyond 8MHz with standard ICs
Re: Moving beyond 8MHz with standard ICs
ytropek wrote:
Thank you for all comments, very good hints there. Below are my comments regarding some of the "official" boards mentioned earlier.
As far as I know Foenix (256K) run at 6.29MHz and uses standard W65C02 or W65C816 as an option.
drogon wrote:
I was under the impression that the Foenix ran at 14Mhz -however it uses FPGAs ...
Re: Moving beyond 8MHz with standard ICs
ytropek wrote:
I think the Yamaha sound chip is the main reason. [...] Plus, naturally, there is ROM.
I'm mostly surprised that WDC boards are running at 8MHz too and that they didn't make these boards a showcase of what the WDC processor are capable of. I assume that it's again related to ROM, as I can't think of any other reason.
I'm mostly surprised that WDC boards are running at 8MHz too and that they didn't make these boards a showcase of what the WDC processor are capable of. I assume that it's again related to ROM, as I can't think of any other reason.
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.
Re: Moving beyond 8MHz with standard ICs
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
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
Re: Moving beyond 8MHz with standard ICs
BigDumbDinosaur wrote:
Paganini wrote:
Between 14MHz and 20MHz is pretty tricky without programmable logic, but can be done if you're precise.
Not really.
My POC V1.2 unit easily reached 20 MHz using only 74AC logic, and appears to be capable of 24 MHz...
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
Re: Moving beyond 8MHz with standard ICs
Proxy wrote:
there are other DIP SRAM chips that are a lot faster, the W241024AK for example is "only" 128kB but also has an access time of 10-15ns.
but you'd need 4 of those, which will overall be more expensive than a single 512kB chip
but you'd need 4 of those, which will overall be more expensive than a single 512kB chip
Quote:
though ironically, if they didn't stick with their "as much DIP as possible" thing they could've saved some cost and made it run at +16MHz by using the IS61C5128AL, which is a 10ns 512kB SRAM chip in a TSOP-44 package that only costs half as much as the AS6C4008 (current mouser prices).
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.
Quote:
but i guess the overall idea of the X16 is modularitiy and tinkerability (if that is a word) and not absolute performance. then again because they did use DIP, someone could in theory make an adapter for the faster chips but it would also require some extra work on the rest of the board to make running at a higher clock possible.
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.
Re: Moving beyond 8MHz with standard ICs
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.)
- 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.)
Re: Moving beyond 8MHz with standard ICs
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.
Anyhow,
gilhad wrote:
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
- 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
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.
Quote:
- 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.)
(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.)
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.
Re: Moving beyond 8MHz with standard ICs
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
Bill
- GARTHWILSON
- Forum Moderator
- Posts: 8773
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Re: Moving beyond 8MHz with standard ICs
gilhad wrote:
- About standard ICs and prefilling RAM from slow (EEP)ROM
Yuri wrote:
This question might belong in another thread not sure.
Quote:
If it may be neccessary to rule out the ROM (I'am not aware of any that can run at 14MHz), that's fine too - but then I'd be curious about your techniques to prepopulate RAM / intialize such system.
However, the post at viewtopic.php?p=91876#p91876 and the surrounding posts are relevant. What I've done is shown about 80% of the way down the front page of my site, linked below (the link that for some reason is not clickable like the links page link is). (Unfortunately what I did there is for a project that has been put on the back burner yet again. I know there are other related topics... now if I could just think of good search terms to find them...
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?
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Re: Moving beyond 8MHz with standard ICs
gilhad wrote:
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 ...
- 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 ...
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?
Re: Moving beyond 8MHz with standard ICs
plasmo wrote:
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
Bill
Re: Moving beyond 8MHz with standard ICs
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
Bill
Re: Moving beyond 8MHz with standard ICs
Yuri wrote:
plasmo wrote:
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
Bill
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/
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/
Re: Moving beyond 8MHz with standard ICs
drogon wrote:
...
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...
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...
If you don't mind the circuit complexity, absolutely, go for it. (Hence my first two solutions)
Quote:
Or don't have ROM at all
Re: Moving beyond 8MHz with standard ICs
drogon wrote:
... Overlaying the ROM with RAM and doing a copy to itself then disabling the ROM seems like a better way forward...
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.