MiSTer FPGA Forum

Any chance this peripheral can be supported? https://www.c64-wiki.com/wiki/SuperCPU
Some homebrew games take advantage of it.

Could be nice. There is a release of Wolfenstein 3D and Doom for the SuperCPU v2.

http://www.indieretronews.com/2017/12/w ... se-of.html

But probably pretty complicated to implement. I know the Ultimate 64 / Ultimate 1541 II+ have gotten the feature to be able to run at up to 48mhz, while the original C64 only ran at 1mhz. But the solution used here does not support the new CPU calls and such that SuperCPU v2 does, so it does not seem to be enough to run the C64 port of Wolfenstein 3D. Also it will require support for D81 floppy disks. With Doom it requires support for D2M disks. Which not even the Ultimate 64 supports, yet anyway.

Should be noted that the CPU that get's used in the SuperCPU is the 65C816... which happens to be already implemented in the SNES MiSTer core

https://github.com/MiSTer-devel/SNES_Mi ... rtl/65C816

More information here:

http://mclauchlan.site.net.au/scott/C=H ... mdcpu.html

Things of note:

- WDC W65C816S 16 bit microprocessor running at 20 MHz - not sure the 65C816 is capable of this
- Additional 64kb ROM (JiffyDos)
- Some additional RAM added in the unit: 128kb of RAM - upper 64kb mirrors the 64kb of ROM
- Additional ram is SRAM (SDRAM or onboard FPGA logic)
- The 'mirroring' employs some proprietary techniques to sync RAM around

Set of registers and relevant memory locations:

https://www.c64-wiki.com/wiki/SuperCPU

Vice Emulators implementation:
https://sourceforge.net/p/vice-emu/code ... rc/scpu64/

I think it's entirely possible to add this accelerator to the C64 core.

Seems that the T65 implementation (the CPU of the current c64 core) is actually capable of being a 65C816. Need to generate a new clock pulse for the 20 Mhz somehow (the PLL already has 3 setup and could potentially clock divide the 1mhz into 20), but it might be possible to change the mode of the CPU to be the 65C816 and get somewhere near the SuperCPU without the additional RAM that the device provides.

Why SuperCPU? the U64 speedhack to accelerate 6510 is good enough to accelerate the games that support either C128 or SCPU while keeping illegal opcode compatibilty.

raparici wrote: ↑Thu Jan 21, 2021 9:30 am Why SuperCPU? the U64 speedhack to accelerate 6510 is good enough to accelerate the games that support either C128 or SCPU while keeping illegal opcode compatibilty.

I find this to be a good argument:

Caldor wrote: ↑Wed Jan 20, 2021 2:28 pm Could be nice. There is a release of Wolfenstein 3D and Doom for the SuperCPU v2.

http://www.indieretronews.com/2017/12/w ... se-of.html

But probably pretty complicated to implement. I know the Ultimate 64 / Ultimate 1541 II+ have gotten the feature to be able to run at up to 48mhz, while the original C64 only ran at 1mhz. But the solution used here does not support the new CPU calls and such that SuperCPU v2 does, so it does not seem to be enough to run the C64 port of Wolfenstein 3D. Also it will require support for D81 floppy disks. With Doom it requires support for D2M disks. Which not even the Ultimate 64 supports, yet anyway.

But not sure if the SNES CPU is the same as the SuperCPU v2.h

He made a MIPS recompiler to make the Wolf3D port and Doom port possible:
ttps://scpu.amidog.se/doku.php?id=scpu:mipsrecompiler

The pages says the recompiler will translate the MIPS opcodes into 65816 ones. But this means its not enough to have the original C64 CPU to run software developed specifically for the SuperCPU as it is just overall more advanced, not just faster. I had figured it would be enough that the Ultimate 64 core could match its speed, but I found I was wrong. The Ultimate 64 even has an option to try to claim to be a SuperCPU, to let the software at least try to run. But this wont get around the fact that it lacks the full features in the CPU part.

SuperCPU seems to be FPGA based in part... which might complicate things even more. Or... I guess it could possibly also make it all simpler if the... FPGA code stuff is available. But I am guessing it isnt as its a commercial product, or was.

As far as requesting a specific accelerated CPU, it can be any of them honestly. I didn't realize there were others

Overclocking the CPU is entirely possible, however the SuperCPU has some additional advantages relating to RAM and being able to address more of it as a 16bit CPU. That said, overclocking the existing CPU is the first thing I looked at:

I attempted to update the T65 CPU to be 20mhz, but the way the arbitration works is awkward:

fpga64_sid_iec.vhd:
-- System runs on 32 Mhz (derived from a 50MHz clock).
-- The VIC-II runs in the first 4 cycles of 32 Mhz clock.
-- The CPU runs in the last 16 cycles. Effective cpu speed is 1 Mhz.
-- 4 additional cycles are used to interface with the C-One IEC port.

Here's where that is realised:

architecture rtl of fpga64_sid_iec is
-- System state machine
type sysCycleDef is (
CYCLE_IDLE0, CYCLE_IDLE1, CYCLE_IDLE2, CYCLE_IDLE3,
CYCLE_IDLE4, CYCLE_IDLE5, CYCLE_IDLE6, CYCLE_IDLE7,
CYCLE_IEC0, CYCLE_IEC1, CYCLE_IEC2, CYCLE_IEC3,
CYCLE_VIC0, CYCLE_VIC1, CYCLE_VIC2, CYCLE_VIC3,
CYCLE_CPU0, CYCLE_CPU1, CYCLE_CPU2, CYCLE_CPU3,
CYCLE_CPU4, CYCLE_CPU5, CYCLE_CPU6, CYCLE_CPU7,
CYCLE_CPU8, CYCLE_CPU9, CYCLE_CPUA, CYCLE_CPUB,
CYCLE_CPUC, CYCLE_CPUD, CYCLE_CPUE, CYCLE_CPUF
);

So, each 1mhz cycle of the 32mhz is shared. There are several idle cycles, but not enough to give us the 20mhz required.

The CPU has the following comment:

-- Usage:
-- The enable signal allows clock gating / throttling without using the ready signal.
-- Set it to constant '1' when using the Clk input as the CPU clock directly.

So I updated the Altera IP PLL to output a new 20mhz clock, and started to feed that into the CPU, always enabling it with constant enable = 1. At that point, I guess the CPU completely hogs the system bus. Booting the core results in a black screen.

I am not sure how to increase the number CPU cycles in relation to the system bus. Anyone have any thoughts?

The main trick seems to be making sure that the CPU actually has access to something during the extra cycles. At the very least, I think it's currently necessary to assert cpuHasBus during (Maybe one 32 MHz clock cycle before? I'm not very familiar with the VHDL update semantics) a CPU cycle. It's probably also necessary to run various register access cycles at the 1 MHz speed, because peripheral timing is also driven by cpu_phi0. I tried changing it to just run one extra CPU cycle per system cycle for RAM access like this:
But it still doesn't display anything, so there's clearly something else I've missed as well.

kamshaft wrote: ↑Thu Jan 21, 2021 4:51 pm As far as requesting a specific accelerated CPU, it can be any of them honestly. I didn't realize there were others

What the Ultimate 64 and 1541 II+ FPGA developer did was accelerate the original C64 CPU, rather than making a new CPU architecture and then accelerate that. Not sure how many CPU types that can be used with the C64 in total.

But I think its important to differentiate between the CPU type and accelerating the clock cycles. Does not seems it needs to be especially tightly coupled. You can do one without the other.

Hello

If it was possible, it would be really great..

It's been a very long time since I looked at source code but accelerating the cpu on the c64 architecture could be done whilst the cpu has access to the c64 bus.......

I would think this is how the u64 does this,

C64 control,,,,, run x mhz, vic control drop back too 1mhz.....

Just my 2p ........

I've decided to take a look at the ram expansion unit as suggested by Sorgleig. If I have an understanding of how the cartridge slot works, I think I will be in a much better position to work on acceleration of the CPU. I have effectively added a new cartridge ID to the existing core and started to look at implementing geosRam first based on a copy of the ezFlash cart.

https://github.com/MiSTer-devel/C64_MiS ... artridge.v

The chameleon cartridge has some core developer documentation which explains at a high level how to create a cartridge core, a cart core with registers, and finally a cart core that uses DMA and adds external CPUs:

https://www.syntiac.com/pdf/chameleon_coredev.pdf

It seems that you can set the C64 into DMA mode which disables the cpu:

3.2 DMA
When DMA is made low the CPU inside the Commodore 64 computer is stopped. This allows
the Chameleon cartridge to take control over the system bus. As extra protection against core
programming errors, the DMA is automatically set to low when the signal A11−0 OE is made low.
The DMA line is output only.

There's also a VHDL implementation of a REU. I am not so keen on using it directly (I prefer verilog) but it does offer some guidance:

http://www.zimmers.net/anonftp/pub/cbm/ ... 4/rec.vhdl

dentnz wrote: ↑Mon Feb 01, 2021 4:39 am I've decided to take a look at the ram expansion unit as suggested by Sorgleig. If I have an understanding of how the cartridge slot works, I think I will be in a much better position to work on acceleration of the CPU...

The chameleon cartridge has some core developer documentation....

This would be a great addition. CPU boost is absolutely brilliant for games like Total Eclipse.

The Chameleon was my first introduction to FPGA, it's an amazing little cart. I still fantasize about going back in time & giving my 8y/o self the Chameleon with all the games & the Amiga core etc... Just imagine showing those Speccy fans that - Hahaha!

Yes I thought I saw that the minimig core had been ported to the Chameleon. Hilarious. As I said, the REU is the first thing I want to try... It will give me an idea of how the DMA flag works. It should be possible to 'disable' the CPU in the c64 and hand over to another CPU running at a faster clock speed. Have to make sure I keep within the appropriate CPU slot however. Here's someone discussing DMA at least:

https://www.lemon64.com/forum/viewtopic ... 2c8f68a287

Other details around the DMA flag:

https://groups.google.com/g/comp.sys.cb ... 6qLw?pli=1

There's one more reason for SuperCPU now that someone has hacked the original code for Stunt Car Racer to retain the game's timings but increase the framerate - and the results are amazing with the C64 version running faster than the Amiga one.

Stunt Car Racer for SuperCPU

This project is the fruit of playing around in the evenings for a few weeks,
most of which was spent studying the code of SCR out of curiosity. At some
point I realised that the physics time step could be adjusted through a
single hook that handled the integration of every variable. I immediately
thought to myself that a proper SCPU adaptation with silky smooth animation
might be much easier than I previously assumed. I quickly found another
important physics hook that affected the forces generated by contact with the
road, and the rest was just fixing a bunch of minor issues over a few
additional evenings.

The original game steps the race clock by a fixed 0.14 seconds per update, so
I decided to divide the time step by 7 to get a solid 50 fps output with
equivalent timings. As a result, the game has basically the same speed as
usual during practice rounds (the original takes almost exactly 0.14 actual
seconds per update), but it plays slightly faster when racing against an
opponent (where average update times can go as high as 0.18s in the original,
especially right behind the opponent). Thanks to the extra computing time
left, I could also crank up the view distance as well as the LOD to burn the
remaining cycles.

I decided to provide an alternative "turbo" version as well, where the time
step is only divided by 5, for those who want a more thrilling experience.
The clock still follows the real time, so race times are going to be shorter
with this variant.

Due to the nature of the changes some of the mechanics cannot work exactly the
same way, so I made a best effort to match the original experience. Notably,
damage calculation can only be approximated, and may need further tweaking.

Disclaimer: I don't have real hardware, so I could only test in Vice.

Happy racing!

cobbpg, 2021