| |
andym00
Registered: Jun 2009
Posts: 44 |
Ultimax unleashed..
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..
https://www.youtube.com/watch?v=yy4Gr11EXHM
He's got a few videos up of it in action.. Nothing ultra crazy, but proof it's all working..
https://www.youtube.com/channel/UCDfSVxlHK9AJHPRCoGqDYZQ |
|
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Awesome! What kind of cpu is in the cart though ? And it's able to change the registers every 1mhz cycle, yes ?
These sinus sprites look like a dream |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
WOW |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: WOW
I did similar with an STM437l at 80mhz. ARM core. Cool stuff!! |
| |
TheRyk
Registered: Mar 2009
Posts: 2070 |
amazing! |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Cool concept! I guess something like this could be done using the 1541U2 as platform. I think there was some experimental copper code in there at one time but you could always go full custom. |
| |
ciccior2003
Account closed
Registered: Jun 2012
Posts: 12 |
I agree with tlr. It would be fantastic if 1541U2 will implement it!!! ;) |
| |
knue
Registered: Dec 2012
Posts: 37 |
What kind of sorcery is this? Can someone enlighten me???
My understanding is that an external CPU within the CRT drives the entire machine while the 6510 is idle - correct? Why must it be Ultimax mode and what does DMA mode mean in this context? |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: What kind of sorcery is this? Can someone enlighten me???
My understanding is that an external CPU within the CRT drives the entire machine while the 6510 is idle - correct? Why must it be Ultimax mode and what does DMA mode mean in this context?
Yes, 6510 is idle and he's feeding VIC with registers using external CPU. When you have a BADLINE VIC will raise some line which makes the CPU idle, that's when you can inject your own CPU... I think that's how ultimate 1541-II works but don't quote me on that :P Ultimax mode... I know it banks out all the ram, leaving you with 4kb rom image, but I don't know why it's relevant here |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Ultimax mode is the only PLA setting which allows VIC to fetch external data, due to a lot of open memory ranges.
There will be no chip-select signal to any chips on the motherboard for those, so a cartridge can snoop on the address bus and put anything on the data bus for the open addresses, without conflicts.
This is also why you can briefly see a "charset" in RAM at $1000..$1fff or $9000..$9fff (and not the chargen ROM) when freezing with Action Replay or similar catridges, which exploit the Ultimax mode. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Yes, 6510 is idle and he's feeding VIC with registers using external CPU. When you have a BADLINE VIC will raise some line which makes the CPU idle, that's when you can inject your own CPU... I think that's how ultimate 1541-II works but don't quote me on that :P Ultimax mode... I know it banks out all the ram, leaving you with 4kb rom image, but I don't know why it's relevant here
Ultimax=allow the vic to read external ROM
DMA=put the cpu in idle state |
| |
knue
Registered: Dec 2012
Posts: 37 |
ic, thanks :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
And the ROM doesn't have to be a ROM, it can be any signal from any source. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Martin PiperAnd the ROM doesn't have to be a ROM, it can be any signal from any source. Thought that as well, but technically, VIC always only reads data (except for RAM refresh). =)
Then again, the CPU may also write to external addresses (if not permanently halted by perpetual DMA).
Anyhow, with VIC reading external data, one could make something that would convert whatever video signal to VIC bitmap/characters (with FLI and sprites and whatnot) at full 50 Hz refresh rate. Kinda lame, but kinda cool as well. View random videos through a realthing VIC filter. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Quoting Martin PiperAnd the ROM doesn't have to be a ROM, it can be any signal from any source. Thought that as well, but technically, VIC always only reads data (except for RAM refresh). =)
Then again, the CPU may also write to external addresses (if not permanently halted by perpetual DMA).
Anyhow, with VIC reading external data, one could make something that would convert whatever video signal to VIC bitmap/characters (with FLI and sprites and whatnot) at full 50 Hz refresh rate. Kinda lame, but kinda cool as well. View random videos through a realthing VIC filter.
I'd rather just take out the VIC chip and build the rest of the system around it. The dram refresh feature can be just ignored, right ? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Plugging in a cartridge is way easier and less likely to kill a precious C-64 or VIC itself. =)
And i think running the VIC in a non-native environment comes with a whole new set of problems, including the analogue sort. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Plugging in a cartridge is way easier and less likely to kill a precious C-64 or VIC itself. =)
And i think running the VIC in a non-native environment comes with a whole new set of problems, including the analogue sort.
I wish the day was longer than 24 hours, there's so much stuff I'd love to try, including this. Just few weeks ago I bought myself STM32 board and even managed to generate analog 15Khz RGB video on it. I feel like I could get something like in the OP here, but I've got so many things going on, work, demos intros, games... I regret not getting into this sooner when I was still in school hehe |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting tlrCool concept! I guess something like this could be done using the 1541U2 as platform. I think there was some experimental copper code in there at one time but you could always go full custom. Seeing that "REU release" (https://csdb.dk/toplist.php?type=release&subtype=%286%29) is a thing, going full Copper using 1541U would be the next logical step. But there aren't any plans to permanently add something like that, are there? |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Quoting tlrCool concept! I guess something like this could be done using the 1541U2 as platform. I think there was some experimental copper code in there at one time but you could always go full custom. Seeing that "REU release" (https://csdb.dk/toplist.php?type=release&subtype=%286%29) is a thing, going full Copper using 1541U would be the next logical step. But there aren't any plans to permanently add something like that, are there?
I think they should create a new tag called "steroids" or something, since there's so few releases of this type anyway, no point in dividing it even more. |
| |
Laurent
Registered: Apr 2004
Posts: 40 |
I added a 50 FPS 'movie' here :
https://www.youtube.com/watch?v=PZ6uRSK7x7U |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Nice work! On both the hardware/firmware side and the video conversion.
What mode does VIC think it is displaying? |
| |
Laurent
Registered: Apr 2004
Posts: 40 |
This is basically NUFLI, hi-res bitmap FLI with 7 sprites underlay, X-expanded.
There are a few differences with the NUFLI format though.
There are 9 cycles left per raster-line:
* one to update $d011 to trigger badlines (done at cycle #11 so FLI bug not visible)
* one to update a single sprite Y position to achieve full-screen multiplexing (they are staggered 1 pixel apart vertically)
* seven to update the 7 sprites colors every raster-line
Because of the THCM samples, 4 cycles of sprite colors are used to update SID registers every other raster-line. It doesn't seem to alter the "quality" of the pictures that much.
Last key thing, I don’t listen to the address that VIC requests, instead i use the internal cycle (X,Y) information to grab the right data inside the picture (char matrix, bitmap and sprites graphics) that makes things quite simple especially for sprites. |
| |
ThunderBlade
Registered: Jan 2002
Posts: 75 |
Wow, very cool! I played around with the REU some years ago to put full hires bitmap in border by changing $3FFF all the time or something. But REU timing of 1541U and real REU were different so I stopped. Never got the idea to generate a NUFLI that way, you are great man!! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Can't do this with a REU of course :)
Can you give some more technical data? How big is the file that is played back? Is it compressed? Streamed from what medium?
This reminds me a lot of some things we tested in early chameleon development (before we decided to not create a new platform). Early 1541U drafts also included similar ideas iirc. (And its totally doable on either, with the right core of course) |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
Very Cool! |
| |
Laurent
Registered: Apr 2004
Posts: 40 |
The video is uncompressed and takes 234 MB (!) on the cart’s microSD card.
It is made of 10646 frames, each frame takes 21984 bytes stored in this order:
* 21600 bytes for 200 lines of:
40 bytes : bitmap
40 bytes : char matrix
7 bytes : 7 sprites colors
21 bytes : 7*3 sprites bitmaps
* 128 bytes for SID registers updates
* 256 bytes for THCM samples (although there are only 156 samples per frame) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
jesus =D |
| |
morphfrog
Registered: Mar 2002
Posts: 32 |
Laurent, wow very cool!, 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. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: The video is uncompressed and takes 234 MB (!) on the cart’s microSD card.
It is made of 10646 frames, each frame takes 21984 bytes stored in this order:
* 21600 bytes for 200 lines of:
40 bytes : bitmap
40 bytes : char matrix
7 bytes : 7 sprites colors
21 bytes : 7*3 sprites bitmaps
* 128 bytes for SID registers updates
* 256 bytes for THCM samples (although there are only 156 samples per frame)
Awesome work dude. :) |
| |
Laurent
Registered: Apr 2004
Posts: 40 |
Quoting morphfrogCan 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.
I tried to keep the basic hardware under the red line as cheap as possible.
It has been designed to explore what can be done with a c64 "on steroids". I assume insane new games could be developed too ? :) |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
So this is basically Vampire for C64? :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Laurent, holy fuck, this is awesome :) c64 will not get any better than this, would be interesting to see how some demo/ish effects look like from higher platforms, with modern music :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: So this is basically Vampire for C64? :)
Jammer, no this is hand feeding the vic every cycle to make it display the theoretically possible best gfx it can. on SID part it just emulates lman's music player. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Oswaldc64 will not get any better than this One could argue that it's not a C-64 any more. Put it in a coma, then animate the body with electric shocks... :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
ok then VICII will never get better than that :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
SID might have a few tricks up its sleeve when being driven at 1 MHz as well. :) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Maybe it can generate a PAL signal? :) (note: I don't know anything about the hardware requirements involved to generate a PAL signal.) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Maybe it can generate a PAL signal? :) (note: I don't know anything about the hardware requirements involved to generate a PAL signal.)
that would be the craziest shit anyone ever did :) |
| |
Mr. SID
Registered: Jan 2003
Posts: 421 |
Quote: Maybe it can generate a PAL signal? :) (note: I don't know anything about the hardware requirements involved to generate a PAL signal.)
Certainly not, that requires about 5 MHz of bandwidth... |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
NTSC might be doable - the dot clock is more than double the chroma carrier frequency over there. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Certainly not, that requires about 5 MHz of bandwidth...
a wave of a single channel has that resolution, and you can manipulate 1 sid register at a time at 1 mhz... |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: a wave of a single channel has that resolution, and you can manipulate 1 sid register at a time at 1 mhz...
The SID is clocked at 1 MHz so the sample rate at the output is at most 1 MHz. This gives a theoretical maximum signal frequency of 500 KHz. |
| |
Laurent
Registered: Apr 2004
Posts: 40 |
Speaking about the SID, if only we had a register that simply latches to a voice internal accumulator, with freq = 0 we'd have a trivial way to play 8 bits samples, and voice ADSR would be still available.
I assume back then they didn't think people would want to play PCM samples ? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
There is hardly any memory for it in the first place :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Oh, oops. I missed that the "it" in Frantic's comment was SID. Please to ignore my NTSC remark /o\ |
| |
Comos
Registered: May 2004
Posts: 71 |
Isn't this a similar technique what SuperCPU actually does on the C64 bus? |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Kinda but the SuperCPU does it on the CPU half of the cycle, while this cart does it on the VIC half. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Internal 6510 is stalled most/all of the time by the DMA, isn't it? |
| |
Laurent
Registered: Apr 2004
Posts: 40 |
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 ! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
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 :) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
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. :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting tlrIt 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. |
| |
morphfrog
Registered: Mar 2002
Posts: 32 |
Quoting LaurentQuoting morphfrogCan 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! |
