Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > Ultimax unleashed..
2019-11-21 10:59
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
2019-11-21 11:39
Golara

Registered: Jan 2018
Posts: 201
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
2019-11-21 12:04
Count Zero

Registered: Jan 2003
Posts: 1067
WOW
2019-11-21 18:19
JackAsser

Registered: Jun 2002
Posts: 1599
Quote: WOW

I did similar with an STM437l at 80mhz. ARM core. Cool stuff!!
2019-11-23 23:14
TheRyk

Registered: Mar 2009
Posts: 707
amazing!
2019-11-26 20:00
tlr

Registered: Sep 2003
Posts: 1270
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.
2019-11-30 22:06
ciccior2003

Registered: Jun 2012
Posts: 4
I agree with tlr. It would be fantastic if 1541U2 will implement it!!! ;)
2019-12-03 16:02
knue

Registered: Dec 2012
Posts: 32
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?
2019-12-03 16:28
Golara

Registered: Jan 2018
Posts: 201
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
2019-12-03 17:12
Krill

Registered: Apr 2002
Posts: 1409
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.
2019-12-03 18:47
JackAsser

Registered: Jun 2002
Posts: 1599
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
2019-12-03 20:48
knue

Registered: Dec 2012
Posts: 32
ic, thanks :)
2019-12-04 08:05
Martin Piper

Registered: Nov 2007
Posts: 403
And the ROM doesn't have to be a ROM, it can be any signal from any source.
2019-12-04 11:48
Krill

Registered: Apr 2002
Posts: 1409
Quoting Martin Piper
And 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.
2019-12-04 12:50
Golara

Registered: Jan 2018
Posts: 201
Quote: Quoting Martin Piper
And 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 ?
2019-12-04 13:18
Krill

Registered: Apr 2002
Posts: 1409
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.
2019-12-04 15:49
Golara

Registered: Jan 2018
Posts: 201
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
2020-03-04 11:45
Krill

Registered: Apr 2002
Posts: 1409
Quoting tlr
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.
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?
2020-03-04 15:51
Golara

Registered: Jan 2018
Posts: 201
Quote: Quoting tlr
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.
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.
2020-03-22 16:56
Laurent

Registered: Apr 2004
Posts: 21
I added a 50 FPS 'movie' here :
https://www.youtube.com/watch?v=PZ6uRSK7x7U
2020-03-22 21:35
ChristopherJam

Registered: Aug 2004
Posts: 1032
Nice work! On both the hardware/firmware side and the video conversion.

What mode does VIC think it is displaying?
2020-03-22 22:34
Laurent

Registered: Apr 2004
Posts: 21
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.
2020-03-23 11:23
ThunderBlade

Registered: Jan 2002
Posts: 62
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!!
2020-03-23 11:32
Groepaz

Registered: Dec 2001
Posts: 9160
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)
2020-03-23 14:02
Mixer

Registered: Apr 2008
Posts: 319
Very Cool!
2020-03-23 15:06
Laurent

Registered: Apr 2004
Posts: 21
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)
2020-03-23 16:08
Groepaz

Registered: Dec 2001
Posts: 9160
jesus =D
2020-03-23 18:43
morphfrog

Registered: Mar 2002
Posts: 14
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.
2020-03-23 18:55
JackAsser

Registered: Jun 2002
Posts: 1599
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. :)
2020-03-23 21:23
Laurent

Registered: Apr 2004
Posts: 21
Quoting morphfrog
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.

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 ? :)
2020-03-23 21:25
Jammer

Registered: Nov 2002
Posts: 880
So this is basically Vampire for C64? :)
2020-03-23 21:25
Oswald

Registered: Apr 2002
Posts: 4534
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 :)
2020-03-23 21:26
Oswald

Registered: Apr 2002
Posts: 4534
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.
2020-03-23 22:06
Krill

Registered: Apr 2002
Posts: 1409
Quoting Oswald
c64 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... :)
2020-03-23 22:12
Oswald

Registered: Apr 2002
Posts: 4534
ok then VICII will never get better than that :)
2020-03-23 22:31
Krill

Registered: Apr 2002
Posts: 1409
SID might have a few tricks up its sleeve when being driven at 1 MHz as well. :)
2020-03-23 22:37
Frantic

Registered: Mar 2003
Posts: 1406
Maybe it can generate a PAL signal? :) (note: I don't know anything about the hardware requirements involved to generate a PAL signal.)
2020-03-23 22:56
Oswald

Registered: Apr 2002
Posts: 4534
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 :)
2020-03-23 23:50
Mr. SID

Registered: Jan 2003
Posts: 371
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...
2020-03-24 06:34
ChristopherJam

Registered: Aug 2004
Posts: 1032
NTSC might be doable - the dot clock is more than double the chroma carrier frequency over there.
2020-03-24 13:21
Oswald

Registered: Apr 2002
Posts: 4534
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...
2020-03-24 13:28
tlr

Registered: Sep 2003
Posts: 1270
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.
2020-03-24 16:40
Laurent

Registered: Apr 2004
Posts: 21
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 ?
2020-03-24 16:46
Groepaz

Registered: Dec 2001
Posts: 9160
There is hardly any memory for it in the first place :)
2020-03-24 17:49
ChristopherJam

Registered: Aug 2004
Posts: 1032
Oh, oops. I missed that the "it" in Frantic's comment was SID. Please to ignore my NTSC remark /o\
2020-03-24 23:39
Comos

Registered: May 2004
Posts: 49
Isn't this a similar technique what SuperCPU actually does on the C64 bus?
2020-03-25 08:25
MagerValp

Registered: Dec 2001
Posts: 972
Kinda but the SuperCPU does it on the CPU half of the cycle, while this cart does it on the VIC half.
2020-03-25 09:29
JackAsser

Registered: Jun 2002
Posts: 1599
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.
2020-03-25 09:32
Krill

Registered: Apr 2002
Posts: 1409
Internal 6510 is stalled most/all of the time by the DMA, isn't it?
2020-03-25 11:37
Laurent

Registered: Apr 2004
Posts: 21
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 !
2020-03-25 12:39
Groepaz

Registered: Dec 2001
Posts: 9160
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 :)
2020-03-26 11:38
tlr

Registered: Sep 2003
Posts: 1270
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. :)
2020-03-26 12:05
Krill

Registered: Apr 2002
Posts: 1409
Quoting tlr
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.
2020-03-27 00:00
morphfrog

Registered: Mar 2002
Posts: 14
Quoting Laurent
Quoting morphfrog
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!
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Mason/Unicess
Acidchild/Padua
Mike
kazmat
JackAsser/Booze Design
hedning/G★P
Karmic/HVSC/ONS
stefanis
psych858o/MSL/Elysiu..
Medicus
Adam/Onslaught
Guests online: 42
Top Demos
1 Uncensored  (9.7)
2 Coma Light 13  (9.7)
3 Edge of Disgrace  (9.7)
4 Comaland 100%  (9.6)
5 Unboxed  (9.6)
6 The Shores of Reflec..  (9.6)
7 Remains  (9.5)
8 Lunatico  (9.5)
9 We Come in Peace  (9.5)
10 C=Bit 18  (9.5)
Top onefile Demos
1 Dawnfall V1.1  (9.6)
2 Crystal Gazer  (9.6)
3 Space Demo  (9.5)
4 Field Sort  (9.5)
5 Instinct  (9.5)
6 The Tuneful Eight [u..  (9.5)
7 Smile to the Sky  (9.5)
8 Rewind  (9.5)
9 Onef1ler  (9.5)
10 Bad Boy  (9.5)
Top Groups
1 Performers  (9.6)
2 Oxyron  (9.4)
3 PriorArt  (9.4)
4 Booze Design  (9.4)
5 Censor Design  (9.4)
Top Fullscreen Graphicians
1 Joe  (9.9)
2 Veto  (9.9)
3 Facet  (9.8)
4 Duce  (9.7)
5 Mirage  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2020
Page generated in: 0.086 sec.