Turbo mode?

[VanessaE]

I was looking into RAD lately, and you mentioned the possibility of a turbo mode in the readme...

Are you still planning to make this happen for general Commodore 8-bit uses (i.e. not involving things specific to that DOOM tech demo)?

Will it be anything like the SuperCPU or other accelerators of years gone by?

Will this work with the C128 in native mode?

[frntc]

I've spent my time on the SKpico in the last months, but I think I'll continue with the RAD soon -- just figuring out the "use-case" :-)

It will probably be a plain 6502/6510 accelerator then. In general, it's easy to speed up the 6502/6510, but writes to bus/memory (for the VIC and peripherals) need to be slow, i.e. a turbo mode needs to decide on a strategy when to update memory (every single write, batched writes, ...). Of course I could simply emulate the entire system, but that's a bit boring, isn't it? :-)

I don't think that I will have the time to implement SuperCPU functionality and I don't have a real one so I have no means making experiments with real hw.

C128-native mode: not sure how this might be possible from the expansion port (I just know that the SuperCPU128 has a MMU-add on). At least one can access the VDC from the C64-mode as well... what's left if the accelerator has >=512mb of memory on board? :-)

[doughamm]

GEOS 128, mainly. :)

[VanessaE]

but writes to bus/memory (for the VIC and peripherals) need to
be slow, i.e. a turbo mode needs to decide on a strategy when
to update memory (every single write, batched writes, ...).

On the SuperCPU, there were what CMD called optimization modes, and it used a one-byte asynchronous write cache.

For writes to RAM, only the address range dictated by the optimization mode registers was put through to the C64 using the cache. Everything outside that range was kept inside the cartridge. See page 35 of the SCPU manual (https://archive.org/details/CMD_SuperCPU_128_V2_Users_Guide/page/n33/mode/2up).

All I/O writes and writes to color RAM went through the cache.

The cache was flushed on every C64 1 MHz cycle, except for writes to the CIAs' GPIO ports, those were flushed every two 1 MHz cycles, iirc. If the programmer spaced their writes more than 20 (or 40) turbo cycles apart, then the cache became "transparent". One could do their STA/ROL/INC/etc, and code that follows it would go on running at turbo speed while the write waits for the cache to flush, kinda like how writes to the C128's VDC work.

Reads from RAM always just hit the memory inside the cartridge (the C64 was ignored), and all reads from I/O or color RAM were just regular blocking reads.

If memory serves, only the last cycle of the read or write actually talked to the C64 since that's when the CPU would actually commit it, so e.g. an STA Absolute would still have its first three cycles at turbo speed, then the write hits the cache so the fourth cycle gets stretched-out.

Whether or not you emulate a SCPU, you'll have to implement this in RAD also. I once asked the guys at CMD about the cache size, and the response was that this was the simplest way, and they didn't see there being any significant speed gains by going bigger than one byte, given how most C64 code worked at the time. Plus it was no doubt a bit cheaper.

I don't think that I will have the time to implement SuperCPU
functionality and I don't have a real one so I have no means
making experiments with real hw.

Well I can understand that for sure. At least VICE can emulate the device, if you ever get a bee in your bonnet to play with it. 🙂

That aside, you might at least consider implementing a 65816 core (they already exist now, but I don't know how that works in the context of a Raspberry Pi). Having turbo speed with 65816 capabilities and megs and megs of RAM is basically 99% of what a SCPU is anyway. The rest is the little implementation details for backward-compatibility and whatnot, most of which you wouldn't need in RAD anyway.

C128-native mode: not sure how this might be possible from
the expansion port (I just know that the SuperCPU128 has a
MMU-add on).

I don't recall CMD being particularly clear on what that adapter actually accomplishes. I guess it makes the MMU itself accessible from outside? Or one of the other chips?

At least one can access the VDC from the C64-mode as well...
what's left if the accelerator has >=512mb of memory on board? :-)

Heh, good point 🙂 but the 128 does have a couple of other useful features like burst serial, and $D700 is a good place to put a second SID chip. That and I don't *have* a C64 to begin with, just my 128s and my 128-DCR (there's another benefit -- the keyboard).

[VanessaE]

What is the current state of this feature?

[frntc]

In my dev-branch it basically works, but no "user-friendly" integration (like setting speed/acceleration options etc.). There might be things I'm not doing correctly yet, I think the FLI-bugs looked differently. I hope to find some time soon to finish this part, and maybe I find the motivation for more (btw. thanks for the explanations above, very helpful!)

[VanessaE]

I look forward to it.

[DirkS-71]

What do you think about releasing a Beta of this feature? I think a lot of people might be interessted and some might be able to contribute. And it can't be that bad, I saw the picture of your board without CPU - a few wires and resistors - well and the RAD ;-)

[frntc]

Turbo mode also works with a 6510/8580 still in the socket ;-) I think it makes most sense to release it when it's mature to a certain point. I don't have too much free time, and spending this on "support" afterwards sounds like a suboptimal option :-) (at least not like fun to me)

[DirkS-71]

That is because a lot of people don't understand that github is not a ready-to-run bazar, but a community where people share their work in the current working state ;-) I really appreciate the effort you put into the projects.