[CSDb] - User Forums - Replacing the 6510 by a 1.2 GHz ARM CPU ?

Welcome to our latest new user Harvey ! (Registered 2024-11-25)

You are not logged in - nap

CSDb User Forums

Forums > CSDb Discussions > Replacing the 6510 by a 1.2 GHz ARM CPU ?

2015-05-16 14:42

Laurent

Registered: Apr 2004
Posts: 40

Replacing the 6510 by a 1.2 GHz ARM CPU ?

The SuperCPU cartridge did this years ago, but it was quite bulky, maybe a little bit pricey too.
A new "better, faster, cheaper, slimmer, ..." SuperCpu cartridge could certainly be made with recent technology.

But is it overkill ? useless ? ridiculous ? Would you consider this kills the spirit of the c64 ?

Here is a FAQ about the SuperCPU:
Q: With a SuperCPU - is the C64 still the C64?
A: Yes, definitely. The original C64 feeling stays, the VIC graphics and the SID musics stays - and I doubt that anybody liked the C64 because of its slow processing speed.
With the SuperCPU, the C64 does NOT become a totally new, totally different computer - it stays as your C64!

I kinda lean toward this observation. To me the most important things are the SID and the VIC.
But I wonder how talented demomakers, 6510 gurus, would feel about interacting with the c64 hardware by constantly (but painlessly) saturating the c64 buses, and this by just writing cross-compiled C/C++ code for ARM processors ?
Sure, demos & games could be developed faster and would look better, but the fact that not everyone owning a c64 would have this cardridge, maybe it would just lose all of its interest ?
or maybe not, if it's super affordable & code is open ?

What are your thoughts ?
Any technical observations too ?

2015-05-16 16:07

Krill

Registered: Apr 2002
Posts: 2969

I would like such a device. Being able to cross-compile standard C/C++ for the C64 would be pretty cool, not to mention the huge processing power you could have.

However, that device should come with some kind of FPGA-based bus handling. You could fill bus-access lists similar to display lists and offload that stuff from the CPU and ease the whole business tremendously, with predictable hardware-governed timing and reasonably low interrupt overhead.

As for scene acceptance, i see no big difference to other accelerators, except it doesn't run 6510 code natively. This may put off some people, but ARM code makes much more sense at these clock speeds and memory sizes in the megabyte range anyways. And again being able to use standard-compliant compilers is a huge plus. You could probably run a Linux directly on the thing (the MMU-less uC variant, anyways), not to mention all kinds of open-source software.

I'm not sure how compatible such a thing could be for emulating a plain 6510 to run native programs including BASIC and KERNAL (with some speedup, possibly), but of course you could always disable the cartridge from software.

I doubt it would be a lot cheaper than other solutions, as the CPU takes just a fraction of the cost. You'd still need a fair bit of glue logic (again, the FPGA), but that FPGA could possibly be on the low end of the range. Other parts like a few megabytes of RAM and a bit of Flash-ROM would also add to the cost, not to mention a few mechanical switches and LEDs, and also USB and ethernet connectors, power switching and I/O buffers and whatnot.

Is there any particular reason you mentioned a specific clock speed? 1.2 GHz seems like an arbitrary figure to me. Also i see no reason not to have many cores working in parallel.

2015-05-16 17:50

Laurent

Registered: Apr 2004
Posts: 40

Yes, a kind of display-list or simple command list sounds good, and unlike the 6510, there is no reason why the main CPU should ever be halt since it has it's own local ram.
Looking at the schematics I haven't seen a way to bypass the c64's RAM so VIC & Cartridge could communicate directly :( I presume the c64 RAM could be just considered as read-only RAM for VIC and write-only RAM for the cartridge since a local 64KB exact duplicate would be kept on the CPU side, where bit-wise screen manipulations would be much faster.

I was indeed thinking about a specific CPU but of course others could be used. The Allwinner A13 has been extremely popular in chinese tablets. That's a cortex A8 with NEON instructions, running at 1.2 GHz.

As for the front-end, even if an FPGA is ideally suited for this kind of glue-logic, i'd try to use a normal CPU if possible. For example a cortex M0 chip like the tiny NXP LPC111x that runs at 50MHz.
If it can work it's better because anyone could alter this ARM C/ASM code easily without having to manipulate VHDL/VERILOG stuff and use proprietary tools for that particular FPGA.
Since interrupts can be used on each pin to fire at either falling or rising edge, PHI2 & BA signals could be handled easily, even there is some IRQ latency and code would have to be tight in the interrupt vector there shouldn't be complicated things to do other than doing 1 or 2 port read/write and sometimes changing the GPIO pin directions.

The communication between the two ARM chips could be done at hi-speed by SPI.

Obviously the devil is in the detail though ;)

After that, it's true many peripherals could be added to that cartridge.
microSD would be almost mandatory, ethernet (or even wifi, the ESP8266 is trivial to use), MIDI ...

2015-05-16 18:39

Oswald

Registered: Apr 2002
Posts: 5086

nay here. if I want a powerful machine I have my laptop to code for. c64's charm is mainly to "break" limits, do things that wasnt done before on a hw soon 35 years old.

also it would be like an a1200 with 060 strapped on: a very fast cpu trying to stuff gfx into a very slow display system.

2015-05-16 22:04

Krill

Registered: Apr 2002
Posts: 2969

Quoting Laurent6581

Looking at the schematics I haven't seen a way to bypass the c64's RAM so VIC & Cartridge could communicate directly

Quoting Oswald

also it would be like an a1200 with 060 strapped on: a very fast cpu trying to stuff gfx into a very slow display system.

There's the Ultimax mode, in which VIC can read data directly from the cartridge's address space. So i think both your mentioned problems don't exist, as there is no need to copy changes in display data from CPU memory to video memory. Okay, well, except $d800. And yes, probably lots of devilish details connected with Ultimax mode.

Quoting Laurent6581

The communication between the two ARM chips could be done at hi-speed by SPI.

That made me chuckle a little. In my experience, you really want double-ported memory-mapped parallel access for sharing large sets of registers between two chips - especially in a scenario like this, where one chip does real-time stuff while the other asynchronically feeds it commands at random times. How fast would that SPI access be?

2015-05-16 23:51

Laurent

Registered: Apr 2004
Posts: 40

I was thinking about using SPI in case VIC can only read from c64's RAM and COLOR RAM and not from the cartridge.
The cartridge would then only write to those 2 memories.
Even if a dumb command-list consisting of 16bits address + 8bits data was used to update bytes in a random way, SPI clock configured at ~24MHz would be enough to saturate the c64 bus.
Certainly, some commands should provide the transfer of blocks of contiguous bytes.
What would be tricky is the update of VIC registers (and less importantly SID registers) at precise cycles.

Now if the VIC has means to directly read from a cartridge, I agree i'd be tempted to use RAM on the cartridge-side that can be accessed by both VIC and CPU, although you already pointed out COLOR_RAM would not be part of this, and there is still a need for cycle-accurate VIC register updates.

Anyways, it's fun to think about such a cartridge, although Oswald does get a point too :-/

2015-05-17 10:31

Oswald

Registered: Apr 2002
Posts: 5086

interesting note about ultimax, still the ram on the cartridge must also run at 1mhz so VICII can access it. probably a good HW engineer can solve that problem tho. I guess its possible to have a ram which is available to the VIC on read cycless, and write to it much faster on the 'other' cycles.

I think a supercpu card compatible fpga cartridge would see a bigger demand / userbase. I'd buy one too probably.

2015-05-18 03:25

White Flame

Registered: Sep 2002
Posts: 136

One thing I want to get to one of these years is hooking up a Raspberry Pi to the C64. I think it would be easy enough to hook it up to the IEC bus, but I'm not sure there are enough GPIO lines to drive the cartridge port. If there was a GPIO expander available, I think that would be the best/easiest/cheapest option for having a CPU accelerator, expanded memory, SDcard, networking, usb, etc on the commie.

However, even in this case, it would likely be a good idea to have hardware assist in driving the bus, to free up the ARM more, so you're still taking some sort of custom logic. A Propeller could bridge the gap; pretty sure it has enough IO pins.

2015-05-18 03:31

mhindsbo

Registered: Dec 2014
Posts: 51

I would be with Oswald on this one. The charm of coding to the C64 is the fixed boundaries of the system and to see if you can squeeze it out of it. OK it is kind of weird to like counting cycles of ML instructions, but ... ;-)

2015-05-18 07:24

AlexC

Registered: Jan 2008
Posts: 298

I have a mixed feelings about it due to several reasons. First of all I agree that the beauty of C64 is ability to overcome hardware limitations and pushing it forward. After more than 30 years we still haven't reach to the limit of its potential.

On the other hand as a person who still loves to work on real thing whenever it is possible obviously I would like a faster machine with more memory for certain tasks. This is why I've been working on C128D with a REU and 1581 for a long time treating it as C64 with turbo option. However when Chameleon64 has been released I'm back to C64. It's turbo mode gives a lot of speedup for certain tasks.

As for SCPU since Vice got support for it anyone can try it out and decide if it is still a c64 or not. The one problem with SCPU and previous accelerator cards is a lack of software and SCPU did best in this area but unless you are using GEOS or just want to code using 16bit CPU on C64 than the software base is very limited.

I guess RPi could be easily used as form of coprocessor to speedup some calculation - just like 1541 drives can be used.

2015-05-18 08:35

Tao

Registered: Aug 2002
Posts: 115

The SuperCPU belonged to the same family as the 6510 though, the ARM doesn't. Most/all (?) 6510 code runs on a 65816 processor, just faster.

If I want something to run fast I've got a PC and a Chameleon.

I'd love to have a backwards-compatible newly produced (or, if someone has an unused that they'd be willing to let go of) SuperCPU though. I don't think I'd be using it for demo programming though (except maybe to produce something just for the novelty). But for C*Base it's an excellent thing to have, and an ARM wouldn't help there at all...

... 5 posts hidden. Click here to view all posts....

Previous - 1 | 2 - Next

Refresh

Subscribe to this thread: