| |
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 |
|
... 43 posts hidden. Click here to view all posts....
|
| |
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? :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
