Tinkering with a 68hc000 in an A500

[Yulquen74]

I have done some experimenting using a 20MHz version of 68hc000 in an A500,on a breadboard connected to the 68k socket.

Im exploring ways to use a higher clock speed on the 68k, without breaking
system timing.

Im no expert in this field as I have not designed any 68k accelerators before,
so I dont know which scheme would work best.


I thought of placing some high-speed memory on the "inside" of a cpu board,
and running the cpu at full throttle when accessing local fast-mem, and switching over to the 7MHz clock when accessing chip-mem and custom chips. With some cpld logic the clock changing could be done after the assertion of AS# in a controlled way (freezing the current cpu clock, and wait for the next rising edge of the 7M clock before changing over the 7M to the cpu)

The CIA cycles would have to be converted to regular cycles with DTACK# instead of VPA I guess, and generate my own E-signal.

So far I have only implemented bus bidirectional bus drivers for address and data lines, and tested with regular 7M clock, and it still works, in spite of wiring to breadboard, but I had to improve decoupling and add some thick ground wires. Using even a 7M clock in the wrong phase causes malfunction and flashing power led. So does a 10MHz clock, but If I delay AS# and DTACK# for a cycle, it works. I can spend further time hooking up more stuff like a cpld and RAM, but I feel I lack some vital information before I continue.

If the accelerator was to isolate its control signals (AS#, LDS#, UDS#, DTACK#..) from the mainboard for non waitstate (own DTACK#) full speed fast mem cycles to local RAM (to not confuse Gary), the bus arbitration to devices like the A590 would perhaps not work (?). (a pending bus master is waiting for a AS# low to high transition after receiving BG?)

If only AS# is exposed to Gary and friends, and out of sync with
normal 7M cycles, would that lead to trouble? Does Gary care if he sees
only AS# getting asserted (out of sync with 7M cycles) without the UDS#/LDS#/RW#?


What schemes is used on commercial accelerators when using a clock different and out of sync with the main clock?

The supra 28 accelerator implements a cache memory, how does that actually work?

I would like a scheme that would let me plug in a variety of crystal oscillators,
trying to push the limit somewhat, as the hc version of 68k is known to be able to overclock quite a bit. Compatibility with bus arbitration devices like A590 would also be a demand for me.


Thanks in advance for views, comments and info.

[majsta]

Without CPLD or something it could be hard to go to higher freq. It is possible but waste of time. All questions you asked are already answered on this forum.

[gulliver]

Originally Posted by Yulquen74

What schemes is used on commercial accelerators when using a clock different and out of sync with the main clock?

In an accelerator, any read/writes to chip mem or motherboard chip registers will always be controlled by the custom chips frequency, so you cannot alter that frequency on an A500.

Commercial accelerators just integrate on its own board as many hardware subsystems as they can (memory, storage, graphics, i/o, etc) so these systems can operate at much higher, and totally different frequencies. And then when comunicating with the motherboard, they just do it in a "window" scheme that respects the custom chipset original speed.
Sometimes these accelerators even use fifo memory that works as cache in this "window" so they can let their accelerators carry on executing work without having to wait for the "window" to open to receive and send data.

I suggest you carefully read this project:
ftp://nic.funet.fi/pub/amiga/hardwar...tors/Lucas.lha

Good luck!

[Yulquen74]

Originally Posted by gulliver

In an accelerator, any read/writes to chip mem or motherboard chip registers will always be controlled by the custom chips frequency, so you cannot alter that frequency on an A500.

Commercial accelerators just integrate on its own board as many hardware subsystems as they can (memory, storage, graphics, i/o, etc) so these systems can operate at much higher, and totally different frequencies. And then when comunicating with the motherboard, they just do it in a "window" scheme that respects the custom chipset original speed.
Sometimes these accelerators even use fifo memory that works as cache in this "window" so they can let their accelerators carry on executing work without having to wait for the "window" to open to receive and send data.

I suggest you carefully read this project:
ftp://nic.funet.fi/pub/amiga/hardwar...tors/Lucas.lha

Good luck!

Thanks!

[attilio]

Wow, interesting reading indeed!

[attilio]

This is also a very interesting reading: even tough it's not specifically tailored to the Amiga, it nicely closes teh gap between what's taught at a computer architecture course and what's needed for apractical implementation of a 68K-based computer.

http://www.users.cloud9.net/~stark/hardw68k.htm

[imperious]

Interesting this as I recently was messing around with the old 14mhz hack and a 16mhz capable 68000 cpu on my A500 Rev 5.
I am fully aware that it's practically pointless as far as significant improvements are concerned, but interesting to try anyway.
I noticed that when loading Lemmings the Game runs fine except for the fact that the music plays at double speed. Some games crash or don't load and some work fine. I was convinced that Workbench loaded quite a bit faster though, although that may have been more related to the faster floppy speed due to doubled E frequency.

Next I am going to try again with a proper 74f74 instead of a 74hc74, as I had to wait until it warmed up until I got a proper boot screen. I am going to attempt to build it with a 16mhz crystal running direct to the clk pin of the cpu, then halving the E output through the 74f74 as well as using a switch so I can get the whole thing running at standard 7mhz again.

Please Don't bother posting and telling me all the hassles associated with this as I know about them. I just like tinkering a bit. Will be interesting to see how it goes anyway.

[Yulquen74]

Originally Posted by imperious

Please Don't bother posting and telling me all the hassles associated with this as I know about them. I just like tinkering a bit. Will be interesting to see how it goes anyway.

Tinkering is fun, and I'd hate to put you off, but I can tell you that feeding the 68000 with a 16M clock directly without glue logic to interface the timing to the motherboard will sadly only produce a flashing power led. Even an out of phase 7M clock will produce that result.

To slow down the E-clock for the cia, the frequency divider is not enough in itself as the cpu peripheral timing gets impaired. I tried that same thing many years ago, doing the simple 28MHz/2 cpu clock hack, trying to fix the cia going too fast.

[imperious]

I said don't bother, but actually Thanks for doing so.

I'm a technician, not an engineer. My electronics engineering knowledge is extremely scant, which is why I don't have the ability to come up with this stuff myself, but I enjoy implementing what others have already devised.
I'll still have a play around with this, if it's completely useless, I'll remove it, otherwise might just make up a game compatibility list for myself.

[Shadowfire]

Those kind of 14mhz hacks only speed up any instructions which don't run bus transactions for 2 full bus cycles or more (8 ticks of the sytem clock). You would see the most improvement on the multiply and divide instructions (72 and 144 cycles IIRC, and the only bus cycle is the opcode fetch(es) at the start) which would be sped up almost double. Pretty much every other instruction is mostly limited by how fast memory can be accessed and the improvement you are looking at is going to be <5% overall.

[mc68k]

I can confirm the 68HC000CFN16 is capable of running with 32 MHz clock. Of course, the chip RAM and chip registers are accessed in sync, so speedup is not really measurable without Fast RAM.

Here is the 14 MHz version of the test board with 8 MB Fast RAM. It produces ~1.5 MIPS (2x speed on the A500).

http://amigaprj.blogspot.com/2015/06...with-dram.html

Currently the tests are running at 32 MHz and 50 MHz, with a 68HC000CFN16 CPU.

[Yulquen74]

Cool!

Were you actually able to push the 68HC to 50 MHz??

[mc68k]

Yes, yes and yes. It works stable at 50 MHz and cold like the ice (HC000 is a CMOS version).

[mc68k]

Originally Posted by Yulquen74

I have done some experimenting using a 20MHz version of 68hc000 in an A500,on a breadboard connected to the 68k socket.

Breadboard will not work, I have already tested it. A wire wrap or soldered board is required due to high capacitance of "plastic" breadboard which causes crosstalk.

Originally Posted by Yulquen74

I thought of placing some high-speed memory on the "inside" of a cpu board, and running the cpu at full throttle when accessing local fast-mem, and switching over to the 7MHz clock when accessing chip-mem and custom chips. With some cpld logic the clock changing could be done after the assertion of AS# in a controlled way (freezing the current cpu clock, and wait for the next rising edge of the 7M clock before changing over the 7M to the cpu)

Clock throttling is not required at all, as the synchronization with the MB can be realized perfectly with /DTACK and /AS.

Originally Posted by Yulquen74

The CIA cycles would have to be converted to regular cycles with DTACK# instead of VPA I guess, and generate my own E-signal.

Right, this works, I can confirm it.

I recommend You to try to realize "simple" uP projects, like a Fast RAM expander with TTLs etc. CPU accelerator is a very advanced task.

Read my blog to see how much time I've wasted while it began to work.

http://amigaprj.blogspot.com/2013/05...with-simm.html

[Yulquen74]

Ok,

do you think it would even work well even at 56MHz?

Meaning an accelerator could have an 56,75032 MHz which is divided
by 2 to supply as main board clock (some slight modification would be necessary to mainboard), and run CPU and RAM at 56,75032MHz which is then in sync with the main board clock meaning no chipram speed loss.

I did make an experimental, quite simple accelerator using some ideas from the Lucas,
and some of my own. It currently runs a 68HC000 at the mainboard 28MHz clock, have some local SRAM (16MB, 12,6MB mapped as fastram, and RAM at F80000-FFFFFF exploited for fast-ROM), and have no IDE interface as it works fine along with my A590 SCSI system. Sysinfo speed is 3,08 Mips, which is 4 times stock speed if local fastram is installed.

I was actually planning on making an improved version, so it would be cool to use the 68HC if as you say it is stable at 50MHz.

Btw, are you using an FPGA on your board, or a CPLD? 5V version?
(I used the ATF1508 5V CPLD device, then I could use Wincupl for simplicity, but
I should perhaps dive into verilog/vhdl at some point).

[mc68k]

56 MHz also should work.

Xilinx XC9536XL and XC9572XL are used in my design.

Please attach a photo of your accelerator.

What is the speed of your SRAM (ns)?

[Yulquen74]

I used R1WV6416RSA-7SR which is 70ns. Thats stretching the limits a bit
for writes as #WE is the width of #UDS/#LDS which is shorter for write
cycles, but so far it has been working fine. 5 of the chips on top of my
board is voltage translators (74LVC244 and 74LVC4245's) as the RAM
is 3,3V, but I used SRAMs to not have a too complex design.

Picture:
http://s1314.photobucket.com/user/y_...l.jpg.html?o=0

[mc68k]

How about the RAM autoconfig?

-o-

Can You please test Spaceballs - State of the Art on your turboboard?

It runs perfectly on a 14 MHz synchro board, but crashes on any other async frequencies.

-o-

I have just checked the Zeus speedtest at 50 MHz. It shows 3.81 MIPS. With 0 wait state RAM it should be 50/7 * 0.7 ~ 5 MIPS. It seems it uses slower RAM than required (K4S561632E-TC60) and inserts wait states into CPU cycles. Due to this the real CPU speed is ~35-40 MHz.

http://eab.abime.net/showthread.php?t=65047

At 50 MHz the RAM access cycle is ~45 ns. And don't forget the shortened write access due to /LDS, /UDS delay... A 20-30 ns RAM is required to run the 68HC000 at 50 MHz.

https://picasaweb.google.com/1024428...75039141784946

[Yulquen74]

Autoconfig is not really needed, the kickstart automatically adds the 1,7MB of the
ranger area RAM 0xc00000 - 0xdbffff to the memory pool, and my A590 DMA's to this memory as its internal memory is of course removed and disabled. Also, autoconfig would also not work along with A590 autoconfig as there is no daisy chaining of autoconfig on A500.

the rest is added with 2 commands during HD boot:

addmem e00000 e7ffff pri=-4
addmem 200000 bdffff pri=-6

this way, the e0 memory is used up first, and then the system continues to
use up the C0 memory which is given priority -5 by the system, and the (almost) 10MB chunk is used last.



I will test state of the art, both with 28MHz sync clock and with an oscillator (async).



For 50MHz I would, as you say, need another RAM solution since I am already stretching the limit a bit at 28MHz, but a 20ns SRAM solution would be very expensive (16MB's of 70ns SRAM already costs about 16 euros), so perhaps a fast SDRAM solution is
the way to go although it will not be that easy to implement.

[mc68k]

What is the current price of R1WV6416RSA-7SR? Where have You obtained it?