The Beast 030 (CD32)

[Akiko]

Very cool project.

Does it have any disable functionality so the CD32 can revert to stock when required?

Good luck with it, can't wait to see more updates.

[Lunda]

Originally Posted by Akiko

Very cool project.

Does it have any disable functionality so the CD32 can revert to stock when required?

Good luck with it, can't wait to see more updates.

No, the current board doesn't have that functionality. It's a great feature though, so I'll try to add it to the final version.

What I have planned for the final version:

- RTC onboard to free up the expansion port. A small connector(like on some
laptops) for the battery is probably needed because lack of space.

- A jumper for switching boot order between the two IDE channels.
Toggle switching is currently done using the reset button.

(- Board disable function for running CD32 in stock mode)

Thanks for the suggestion. Keep them coming!

[cloverskull]

Resurrecting this fascinating thread that I clearly missed out on ... how is this project going? Would it be possible to see some gameplay with the 030 at 70MHz? I would love to compare it to more traditional 030 speeds (i.e., 50MHz) or even a non-accelerated CD32 speed.

[utri007]

I just wonder why nobody has made something like this with Dragonball CPU? https://en.wikipedia.org/wiki/Freescale_DragonBall

It is 68k CPU clockable to 66mhz 10.8 MIPS with display controller. Almost like computer on chip, but for a 68k series CPU.

Should be easy and tiny accelerator, compared to this.

[Lunda]

Originally Posted by cloverskull

Resurrecting this fascinating thread that I clearly missed out on ... how is this project going? Would it be possible to see some gameplay with the 030 at 70MHz? I would love to compare it to more traditional 030 speeds (i.e., 50MHz) or even a non-accelerated CD32 speed.

I have been busy fixing a battery damaged A4000, so not much time spent on the 030 board.
I do use the CD32 as my main Amiga already. Which is another reason why I don't want to mess too much with the FW.

I'm using the PLL option now, instead of the 140MHz oscillator.
So currently the CPU is running 5 X the 14MHz Amiga clock. This makes it easier to sync and get best possible performance. I used the oscillator first because it's more difficult to synchronize with, and I want the board to be able to use oscillators too. It might not always be possible to find a good PLL/CPU combo.

All communication to the Amiga goes through latches, so address, data and needed control signals are latched when they are available(AS,DS) for writes. This means it might be possible terminate a bus cycle in about 2 bus cycles in the future.

All needed control signals are already "decoupled" from the CPU, and the board is already working this way, but without fast bus termination.

I've got it working for the Akiko C2P, which means you will have around 38 free CPU cycles with access to fast RAM during the Akiko write(some writes will need more than 8 slow clocks).

The plan is to get it working for all Amiga writes in the future.

The SRAM cannot run at 2 cycles for read at 70MHz. When I designed it, I calculated with a frequency around 60MHz.
AS to data ready is around 10nS which is what the SRAM can do. The CPLD is rated 7nS pin to pin, so using the AS signal is impossible, but using address decode makes it almost fast enough. I might fix this in the future, but it will probably require a separate FPGA/CPLD that is faster and controls only RAM. I'm using MUXed signals now, which adds around 4nS delay.

I haven't stared working on the P96 driver yet.