Registered: Jun 2009
Well, someone did what I've been wanting to do for some time.. Driving VIC fetches from external memory, and stuffing register writes over the bus.. Hooray for Ultimax mode I guess :)
Always wanted to build something like this, but kudos to Laurent for acutally getting there..
He's got a few videos up of it in action.. Nothing ultra crazy, but proof it's all working..
... 43 posts hidden. Click here to view all posts....
Registered: Aug 2004
Oh, oops. I missed that the "it" in Frantic's comment was SID. Please to ignore my NTSC remark /o\|
Registered: May 2004
Isn't this a similar technique what SuperCPU actually does on the C64 bus?|
Registered: Dec 2001
Kinda but the SuperCPU does it on the CPU half of the cycle, while this cart does it on the VIC half.|
Registered: Jun 2002
Quote: Isn't this a similar technique what SuperCPU actually does on the C64 bus?|
This is more similar to the 2Mhz mode on C128.
Registered: Apr 2002
Internal 6510 is stalled most/all of the time by the DMA, isn't it?|
Registered: Apr 2004
The cart handles both phases of the cycle CPU & VIC, but unlike the SuperCPU or a FPGA-based CPU, the cart CPU cannot be synchronous to the clock and still be efficient.|
The GPIOs are slow so the "c64 bus handler" loop cannot do anything too fancy. Writing or reading prepared data to/from the bus is fine, but not having actual code or CPU emulation there.
So the prepared data are altered in another core of the cart CPU, every frame. By prepared data, i mean a sort of "copper" for the CPU cycle and a "VIC feeder" for the VIC cycle.
Like Krill mentioned, for the copper to be allowed to read/write the bus, DMA must be turned ON (6510 stalled), and to handle data to the VIC, ULTIMAX mode must be ON with A15 low so that RAM is masked from VIC.
(In fact, i am not sure what role should be left to the c64's 6510 and RAM with this cartridge)
So far in all the test examples i have posted on youtube, the code that alters the copper & vic feeder structures and access flash is written in C, compiled for the cart's ARM core and is also mixed with the rest of the firmware.
I understand this is not viable for release, and ideally the cartridge would be supportable by VICE.
I'm working on some way for people to write their code and access the cart features via functions, like allocating memory in the cart, reading/writing flash, moving memory, doing simple logic/math operations on array of data (int & float32), then drawing lines, filling triangles, etc..
The question is what CPU(s) should be made available on the cart for the user ?
I have a simple non cycle-based 6510 emu that i have already used to play SID tunes without involving the C64's 6510 (then the copper updates the C64 SID registers).
But for the main demo/game code, i feel a more powerful CPU would be neat so the code could be written in C with 32bits support.
So I started using the Cortex M0 instruction set in thumb mode only, it quite simple to emulate this small CPU for an emulator, and it runs natively on the cart.
To write code, the user uses a .h and a symbol file for the functions, then uses GCC.
Well, at least that's my plan for now !
Registered: Dec 2001
i'd probably prefer some kind of fixed function pipeline that the C64 CPU can setup and use.... writing the payload in C for an ARM cpu just feels wrong :)|
Registered: Sep 2003
Quote: i'd probably prefer some kind of fixed function pipeline that the C64 CPU can setup and use.... writing the payload in C for an ARM cpu just feels wrong :)|
It feels weird to have the copper more powerful than the main cpu. :)
Registered: Apr 2002
It feels weird to have the copper more powerful than the main cpu. :)I guess it's very sensible to have the copper not be Turing complete. With that prerequisite, it's somewhat a question of perspective whether it's more powerful or not.
Registered: Mar 2002
Can you please tell us a little bit about the custom hardware you are useing for this? I have understand you use a external cpu in the cartport amongst others.
(there are no components on the bottom side)
I used a multi-core ARM CPU, but for now i prefer not telling the exact part, i hope you won't mind :-P
Obviously the specs are outrageous compared to the 6510.
Still, one of the core had to be 'wasted' to solely handle the BUS, the GPIO speed was the bottleneck and barely allowed it.
It doesn't have much RAM, less than 512 KB. I believe with the firmware only about 400 KB will be left for the user.
I used a 8MBytes SPI Flash (the winbond part)
The components above the red line are not necessary for the cart to work, but nice to have for the dev version.
I populated a microSD slot for testing purpose, like you saw i ended up using the SD CARD to make these videos. Under the microSD slot (can't be seen) there is a footprint for a SD NAND flash chip.
The chip near the holes is a UART<->USB converter, most developers already have such converters on small breakaway boards, but i thought it would be nice to include it here.
The non-populated part on the right is for a small WIFI module based on the W600 chip.
Intresting thx for info!
|Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next|