C64 Demos peek - Nine by LFT
HTML-код
- Опубликовано: 8 фев 2025
- Does this demo show an impossible nine sprites in a horizontal line on a Commodore 64? Is there magic here? Join me for a look at how this demo seemingly does the impossible.
Demo here: linusakesson.n...
Debugging notes: github.com/mar...
Bonus extra video ruclips.net/video/Wjf2r12CGUw/видео.html
Hi! Thanks for a great analysis of the demo! I especially like the way you demonstrate debugging tools as a method that people can use to investigate any demo effect they want. I'm also delighted that you noted the symbolism of how elements on the screen aren't what they appear to be, just as in a magic trick. But what I like most of all is that you left your description of the “impossible” part rather nebulous, which means there's still plenty left for me to expand upon in my upcoming video. =)
I can imagine writing a byte order transfer table for the crunched sprites was pretty impossible. It's so non-linear!
I almost don’t want to view either this video or your upcoming one, to keep it a mystery , and stay in the theme of the demo!
Line 12 cycle 15. A single store expands so many possibilities.
Oh hey, you're the Commodordion guy. No wonder your demo popped up in my recommends last week. I love that you're planning to explain this yourself. Back in the day a demo coder would probably be blacklisted from the 'scene for revealing his secrets. ;)
When you said “it came to me” my instant thought was “on a floppy in the mail”. That’s how we got the demos. It was an incredible system for spreading thing around the continent, no internet or phone lines involved 😅
Ahh yes, happy days or swapping tapes and then later disks.
When they were moving in a circle around the magician I thought, "Okay, multi-plexed sprites. Easy". Then when they began moving horizontally in a smaller circle I thought, "I think there are probably only 8 sprites here but they're moving so fast that it's hard to tell" but then counted nine. The actual solution is way more clever than I thought it would be.
Love LFT's stuff. So glad you dug into it Martin
Thank you! I came across this last night, and wondered whether you might take a look at some point. Didn't expect you to get something out so quickly though. This more-or-less validates my thinking, although I hadn't expected the complexity around the side borders and switching to the sprite-based magician to make that work.. lft obviously put a fair amount of effort into that one - I guess as all good magicians do. Anyway, appreciate your work, cheers!
The really clever bit is the stuff going on in the top border. The multicolour X-expanded sprites interact with the ghost byte in the border to add extra pixel resolution.
Two C64 greats in the one video! Much fun on both accounts thank you Martin and Lft
Don't forget, at around 27:00 the sprite priority with the ghost byte (updates to $7fff) and the screen colour gives the extra pixel resolution in the top border for the multicolour sprites.
Changing all the sta $7fff (8d ff 7f) to sta $7ffe (8d fe 7f) turns off the ghost byte mask update and shows chunky multicolour expanded sprites again.
Okay, so this is completely new to me. I figured that there must have been multicolored sprites behind the hires sprites in front but I couldn't see how he made them look hires. I assumed that there must be 4 multicolor sprites, two on top of identical sprites below but offset one pixel left or right which I think could achieve the right look.
But when your debug view showed only two multicolor sprites I was baffled. :) I wonder if any games ever made use of this.
hmmm to me this was not quite clear from the video... while i have a basic understanding about the "ghost byte", i don't really understand how it's been used in this scenario. isn't it a repetition of the same byte over and over again? how can it be used to create unique masks to "hires-ize" the multicolor chunks?
For example imagine you have a couple of multiplexed sprites next to each other, one of the multicolours is black (like the "border"), the transparent pixel would show the "screen" behind. But in this case the "screen" is the ghost byte and the background colour since it's the border area. The ghost byte is black, so setting this to a pixel pattern with a transparent portion that shows the background colour this will show a more accurate background colour.
If the background colour is set to something other than black at the precise point where the expanded sprites are drawn (invalid bitmap mode helps create a black area during this change) the transparent pixels with the black ghost byte bits, create the hires pixels.
Basically the "black background" where the expanded sprites are is not background, but is instead one of the multicolours (d025).
If you use a monitor to fill the multicolour sprite frames with transparent "f 6800 6cff 0" then you'll see the underlying ghost byte and the background colour.
@@MartinPiper6502 ahhh ok so now i understand... so the background color is also changing in the border area... but due to no badlines in the border, that's possible every ~ 32 pixels
Wow, that came out just in the first month of this new year! Amazing that it was both made and sent to you just this little bit of time before you're showing it to us!
Thanks!
Thank you kindly
Oh wow, you were fast on this one! Can’t talk, must watch video :-)
The complexity of the multicolor expanded sprite part is kept to a minimum by keeping those 3 numbers in a rigid formation. So, two wide sprites are enough to display three numbers. However, I think there's something fancier going on ... and I'm not sure what.
For example, at 31:10 the three background numbers are 4 3 2. But they do not look blocky, the way you'd expect with horizontally expanded multi-color sprites. They still look like they are high resolution, in fact. I don't get it.
edit added: Okay I read the pinned thread about the ghost byte and I ... well I do not understand it, but I get that there is a logical explanation.
Nothing like superb timing!!! Love it Martin!
Amazing demo. Pure c64. Thank you for analysis. Super thanks!
Glad you liked it!
There is a way to show sprites over the left and right borders by switching from character screen to hires screen and setting the char colour of the last char on the RHS to the colour you want the border to be. the vic seems to bleed the char colour into the border. you have to do d016 stuff to switch off the border as usual. Mucked about with it a few years ago. My memory of it is a little vague. Excellent video. The Vic II is a magical beast.
It's a great trick however it's done and I loved the presentation.
Oh come ooooon... I just wanted to write you you should check that demo out and maybe tell us how it works... but you beat me to it with the full production :-D :-D fantastic, will study it later.
Oh by the way, Commodore called Software sprites "Shapes". Commodore 16/116/Plus4 and C128 even had BASIC commands named SHAPE.
I love how the demo never says "sprites", the introduction actually says "spIRIts" and the magician is supposed to do illusion tricks so no one can accuse the demo of illusion tricks,
Dude. You can keep notes in c64debug itself and it will resize the c64debug window automatically. This will help prevent you obscuring the demo with notepad++ at crucial moments
I have a wild guess how it was done though it still seems difficult. Very interested to watch this one...
As soon as I saw the graphics map I understood that it was in multicolor mode.
imho, the weirdest case of "software sprites" on C64 has got to be in Barbarian.
For the bodies of the barbarian, the graphics are very obviously as sprites in the memory, BUT they... actually get blitted to the screen, which is in bitmap mode. (On some cracks of the game, you can reset the game with user port reset button, which brings the game back to the intro screen - leaving previous barbarian graphics blitten in the background)
And why is this extra weird? Graphics for sprites and bitmap are in kind of different format. Sprites have groups of 3 bytes, which define one 8*3=24 pixels row of the sprite. On bitmap screen, 8 bytes define one 8x8 pixels block, next 8 bytes the block to the right of the previous one etc. (both X-resolutions obviously halved in multicolor)
(And yes, it DOES use some actual sprites. The shirt on the enemy barbarian, blood, and most obviously the severed head)
I looked at Barbarian a while ago... ruclips.net/video/bLtoCFE3M6o/видео.htmlsi=tZEEb5oj-SZvEtcd
And few other old "software sprite" examples, Ankh and Goonies, both of which (afaik) came from Apple 2, which lacked sprites. Since both systems share the same CPU, it was probably easy enough to port the code as-is without adapting it to use more advanced target platform features.
I think Zorro might also be, but not 100% sure.
And ruclips.net/video/Su2mKxz9VSc/видео.htmlsi=HAQTXKtBgCPgl_Jf
And ruclips.net/video/sb8n4DNRaPU/видео.htmlsi=mYL6cFdb4Wxg5-Md
Heh, "blitten".
You say they use multicolor sprites in the top border area. But when I pause and look at the pixels, it looks like hires size pixels at the curves of the numerals.
@sa3270 yes those pixels are not from the sprites they are from the background. That's the trick.
9 and 7 are the same sprite but with a mask
Great stuff Martin. btw You call fill the memory with built-in monitor and F from to byte 😉
You seemed to omit the sprite crunching part. I think that was the most difficult part to crack 😅
Yeah for some reason my zero key wasn't working in the debugger.
Sprite crunch in the top border?
Oh yes, a crunch on line 12 (cycle 15 of course)
hmm which if the sprite update routine is disabled ( a 8d53 jmp 8d7a ) and the sprite frames are filled with data, the taller sprites can be seen. :)
When you know you can see it pretty clearly. Exactly like how it is with regular magic. When you know how the trick is done. It loses a lot of the charm. It was a genius trick IMO.
Interesting.. so much going on! ^_^
amazing
The magician looks like zoidberg In disguise
intresting little confusing, will be intresting to see how it compares to LFT's explanation.
i think that trick lies in when the sprites go close to each other .... personally once that the sprites are placed in the top horizontal border, I would have then moved the pixel data around inside the sprites and used the sprites like a 'canvas' rather than moving the sprites about ... unforunately when i tried splitting up a raster line into sub cycle parts .... and relocate a single sprite into each of those sub raster parts you would not get multiple sprites ..... pity!
I was hoping he didn't release the prg, and kept people guessing :)
Extra video for channel members: ruclips.net/video/Wjf2r12CGUw/видео.html
Wow, pretty cool! But why did Commodore make it so hard to disable the borders instead of just giving us a regular command (or set of commands) to disable and re-enable it (or horizontal only, or vertical only), at least in BASIC (if not also a single or 2 assembly commands for it)?
It definitely wasn't something they ever intended to work. In the days of CRT, the border was there so you could resize your screen to fit your TV...
@@davidlloyd1526: What do you mean by "resizing"? There isn't a way to resize the border normally (only to aid in graphical scrolling temporarily). But even then, why not just implement a normal way to turn off the borders instead of forcing them on so hard?
@@HelloKittyFanMana better question is: why visible borders? With a different timing, less cycles would be wasted in the borders. Lower the clock like on the plus4 .
Also why does the VIC-II not allow us to set a frame buffer read pointer in the upper border for easy scrolling?
Why no alternative 48 char pitch for horizontal scrolling instead of two stolen chars .
Why sprite pointers in RAM.
Why color SRAM with this hard limit on 1024 chars in the buffer, while the plus4 does it in main RAM. Why not 2x2 color attribute mode like on NES?
@@HelloKittyFanMan I think resizing was meant in the sense of manually adjusting TV/monitor controls (knobs or dials usually) to center/expand/contract the vertical and horizontal of the screen, which was definitely a thing with CRTs.
@@HelloKittyFanMan CRTs have analog control knobs for the projection area's position and size (values that tweak the deflection coils), CRTs have overscan areas, which means that the actual edges of the image are not shown.
Well if it's using "invalid bitmap mode" then that IS using a bitmap mode, even if you're calling it invalid.
Bro is flossing at 2:45 XDD
This demo is very fun. Is it possible to open the side borders without switching off the bad lines? I.e. could this be done without switching the magician to be a sprite?
You can only have four sprites on a row, which might be enough to pull it off. It's hard to tell from the video, but the code would probably be harder and there wouldn't be as many tricks in the demo.
I had a C64 back in the day, this 'more than 8 sprites' is old chip papper. As I recall it was 8 sprites per vertical interupt, but to look at if you have 8 on one vertical interupt then 8 more on the next vertical interupt it would look like a row of 16
How does this emulator with debugger allow you to edit the graphics that show up in the program just by editing something in a map that we can only see outside of the program in the computer that's emulating it, rather than typing the specific changes in programmatically, which of course we would never see on the real machine? And then how do you resave it for use on the real Commodore computer? It just puts out a D/G64/81, etc.?
@@HelloKittyFanMan graphics in the emulated C64 are stored in memory in the emulator. Modifying memory in the emulator makes the emulated C64 memory change.
@@MartinPiper6502: Wow, that's really interesting! So this is just a highly modern cross-developer tool for the 64, it sounds like! Now what about the resaving aspect?
Once you have the data access, it's possible to just write that data back to a disk image and back to a disk for use on a real C64. It's just data in different formats.
@@MartinPiper6502: Right. But what I mean is: what methodology does this system use to output back to storage that reaches an actual Commodore 64? Do you remember D64s and similar things?
@@HelloKittyFanMan I'm not C64 developer, but I felt I'd try to reinterpret your questions a bit. If you're really interested in storage, you should google "vice c64 format" and read up. The G64 format is an option, but I'm not sure that's the question you wanted to ask.
VICE is not "just a highly modern cross-developer tool", it's an emulator (like a SW machine) with the debugger-like ability to pause, inspect and modify any state of the "machine". Maybe you had a cartridge giving similar possibilities when running on real HW. Martin edited the sprites in RAM directly as a way to identify the parts, the changes were never meant to be saved and used on real HW, but there is a possibility to save a snapshot to reload the saved state to the emulator.
If you really wanted to modify the demo in a runnable way, you would likely alter the actual program instructions themselves. I think you meant that with "changes programmatically". That way the changes would appear every time you run the program, instead of being reset to the original data. Other changes might be possible through editing of the data used by the program, e.g. if you wanted another hat changing the font could be enough. Storing this back "to disk" is then "easy" in the same format as the original. But, as mentioned, in this case there was no need to do any of that, because the demo was running in the emulator and the changes were only temporary.
So again which ones are sprites in order? Magician, side borders, and some of numbers? Sory not a English native speaker.
@@propinki it changes throughout the demo
In Part 1 only the numbers are sprites, the magician is made of custom text characters, the normal screen border is displayed.
Part 2 starts when the screen flashes white, now everything is a sprite, the screen borders are removed and the background colour is changed from black to blue to black as it is being drawn down the screen. Sprites 5 and 7 are completely black and drawn repeatedly down the left and right sides of the screen to hide the missing side borders. There is a transition to Part 3 where only eight sprites are on screen at once, if you look carefully there is never a ninth number immediately above the magician's head.
Part 3 begins when all of the numbers are above the magician's head and the missing number re-appears, now eight of the numbers are sprites and one of them is character graphics, which is always in the background moving left to right.
Part 4 starts when the numbers reach the top "border", which is still not a real border just the background drawn black, now six of the numbers are individual sprites and the remaining three numbers are split across two multi-coloured sprites.
@firstsurname9893 thank you 🙂
@@firstsurname9893ah, so the multicolor sprites are not symmetrical on both ends, but on one and use all 3 of the multi-colors. And both multicolor sprites share those anyway.
@@ArneChristianRosenfeldt That's my, quite basic, understanding. The trick to hide Multicolour 0 and the chunky corners of the sprites is way over my head, but I'm sure LFT will explain that in his follow-up video.
clever
And how is it that with all that multiplexing going on we don't see the sprites flickering?
Well timed updates avoid flicker. :)
@@MartinPiper6502: Interesting!
@@HelloKittyFanMan You can have much more than 8 sprites on the screen at the same time (doesn't cause flickering or anything). You just can't have more than 8 sprites on the same rasterline. That is what the limitation is. :)
Haha, @zaitarh !
@@HelloKittyFanMan Hehe... Wasn't really a joke actually :) I don't remember what the record is, but well over 100 sprites. (For example, 144 sprites in the demo "Krestage" by Crest - maybe it has been beat since, don't know)
The way it works, is that you can change the y-position of the sprites, while the video-chip draws the screen. If a sprite has already been drawn by the video-chip, and you then move it down to a rasterline further down than the VIC-chip has drawn yet, the VIC-chip will draw it again when it gets down to it. So the same sprite is now shown twice - pretty simple. And you can keep on doing this, to reuse the same sprite many times. (And you can ofcourse change the sprite's image/color/etc, when you repeat the sprite, so even though it's the same physical sprite being repeated, it doesn't have to look the same)
Frankly i'm shocked they would try to perpetuate such an outrageous lie! Great demo though.
Yes, a very clever demo and all based on good spirited deception.
I can't tell if you were joking or not, which of the "lies" did you find outrageous?
@@_J_A_G_ just kidding around! about 9 sprites when everyone knows only 8 possible! (sorry another bad joke). 😁
CRT emulation off is uglier? Say what now... To each their own I guess.
Exactly - without CRT-emulation, the graphics looks extremely pixelated and doesn't at all look like what the graphics looks like on a real C64. But of course, to each their own :)