| |
Krill
Registered: Apr 2002
Posts: 2839 |
Release id #205500 : Freespin
Allow me to comment on some tech details here, as i don't have an FB account to comment on the blog.
Great idea about the table-less 3:2 GCR-compliant codec to have maximum spare space for actual payload effect code. =)
(But table sizes of traditional decoding schemes aren't all that big, really.) |
|
| |
mankeli
Registered: Oct 2010
Posts: 110 |
Does the music playback in this demo make the drive to misalign? I've heard the stepping the head a lot into the mechanical stop causes that. |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
I wonder if this can be emulated on the Ultimate some day? Especially the drive music. :-) |
| |
Raistlin
Registered: Mar 2007
Posts: 552 |
Totally love this. Thinking about Trap's comment, though, and moving my thoughts to the Forums before the admins trash the review thread of the demo (as is common)...
Should this be classed as a C64 Demo or something else? I'm not 100% sure. Most big demos nowadays have 1541 code for IRQ loaders etc ... but, of course, having to cut the serial cable and rewire it (or to one day perhaps have some sort of splitter cable) kinda makes this a hardware "extension"... that cable is hardly certified by Commodore after all ;-)
Moving it out of the charts doesn't feel fair, either, as the amount of work done on this and the thought that's gone into it is incredible.
Trap for sure has other reasons for wanting it knocked off the #1 spot of course ;-) .. but .. yeah. Not sure. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
Nice question. It surely requires a C64 and a C1541 compatible drive but then also requires some special hw (a modified cable but still is special custom hw) so it's a mixed C64+other platform release
That also poses another question: releases that run only on SpeedDos/JiffyDos etc are to be questioned if they're C64 releases? =)
/me throws some more fuel in the fire and goes away |
| |
Raistlin
Registered: Mar 2007
Posts: 552 |
Maybe CSDb needs tags..? |
| |
Higgie
Registered: Apr 2002
Posts: 113 |
Frankly, I don't think that the demo belongs in the c64 demo category. The demo runs on the 1541. The c64 is only used to upload the code. As far as I remember, you can also connect the 1541 to a VC20, C16 C128 or even to an E-Mu Systems SP-12 drum machine and transfer the drive code from there to the 1541 if necessary. OK. I'm not sure about the SP-12. ;) Maybe CSDB needs a category "Wild with Commodore Hardware involved". Just my 2 cents. ... BTW: I love the demo for what it is ... running on a 1541. :) |
| |
BiGFooT
Registered: Mar 2002
Posts: 31 |
Quote: I wonder if this can be emulated on the Ultimate some day? Especially the drive music. :-)
I wonder if this can be "emulated" on my breadbin some day? ;-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
i put it on my todo list :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: I wonder if this can be "emulated" on my breadbin some day? ;-)
emulated? just put the damn thing on a cart, cut the serial cable on from the c64 and be done with it. :d |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
the 1541 is on different clockspeed tho? I was wondering what is needed to provide sync signals to the monitor? so the 3rd 'color' does that I guess? ~63 cycles per lines, then how many cycles sync? and how long for vblank? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Oswaldthe 1541 is on different clockspeed tho? I was wondering what is needed to provide sync signals to the monitor? so the 3rd 'color' does that I guess? ~63 cycles per lines, then how many cycles sync? and how long for vblank? According to http://www.quiss.org/freespin/raster.html
- 5+ cycles for horizontal sync
- 64 cycles per scanline (max. 52 visible)
- 256 visible/effect lines
- 56 lines vertical blank |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: the 1541 is on different clockspeed tho? I was wondering what is needed to provide sync signals to the monitor? so the 3rd 'color' does that I guess? ~63 cycles per lines, then how many cycles sync? and how long for vblank?
It’s not timing critical, CRTs adapt |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting JackAsserIt’s not timing critical, CRTs adapt So do modern flatpanel monitors (if they still have Y/C or composite input), albeit with arguably lower tolerances while often doing weird things like insisting on interlace output. =)
I'd say it still is timing-critical, but not all that tight. As long as a scanline is about 64 µs long* and a frame/field about 1/50 s for PAL-ish output, all should be good. :)
* Which is why it's 63 cycles on a PAL machine with slightly below 1 MHz and 65 cycles on NTSC with slightly above 1 MHz. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsserIt’s not timing critical, CRTs adapt So do modern flatpanel monitors (if they still have Y/C or composite input), albeit with arguably lower tolerances while often doing weird things like insisting on interlace output. =)
I'd say it still is timing-critical, but not all that tight. As long as a scanline is about 64 µs long* and a frame/field about 1/50 s for PAL-ish output, all should be good. :)
* Which is why it's 63 cycles on a PAL machine with slightly below 1 MHz and 65 cycles on NTSC with slightly above 1 MHz.
That's what I mean with not timing critical. You can be quite off on the VSYNC and it'll still lock. HSYNC is ofc a bit more critical. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting JackAsserHSYNC is ofc a bit more critical. Yes, there probably was a reason why they replaced 64-cycle NTSC VIC with the 65-cycle one. =)
And as for timing-critical, i thought this mostly means having a stable timing (not having exactly X time for thing Y).
Pretty sure that randomly having +/- 1 cycle per line and possibly +/- a few cycles/lines per frame isn't all that feasible across most video output devices. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsserHSYNC is ofc a bit more critical. Yes, there probably was a reason why they replaced 64-cycle NTSC VIC with the 65-cycle one. =)
And as for timing-critical, i thought this mostly means having a stable timing (not having exactly X time for thing Y).
Pretty sure that randomly having +/- 1 cycle per line and possibly +/- a few cycles/lines per frame isn't all that feasible across most video output devices.
Ofc! Stable timing is required. |
| |
Quiss
Registered: Nov 2016
Posts: 37 |
Quoting Krill
Pretty sure that randomly having +/- 1 cycle per line and possibly +/- a few cycles/lines per frame isn't all that feasible across most video output devices.
Not sure about video grabbers etc., but at least my PAL 1802 was actually kind of fine with different line "widths" (i.e., a jittery hsync position)
It then takes a few lines to "adjust" to the new hsync offset, moving towards it at about 1 pixel per line. So you get a diagonal. Could maybe be used for tech-techs, if you really want to.
Didn't try on the 1084. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Quote:Not sure about video grabbers
i am willing to bet they hate this sort of thing. a lot. :) |
| |
enthusi
Registered: May 2004
Posts: 675 |
You can check with the Atari2600 folks, there it is only software that determines the size of a frame (and hence PAL/NTSC) and it often varies even within (commercial) games depending on scene /o\
http://www.digitpress.com/library/techdocs/vcs_scanlines.htm |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting enthusiYou can check with the Atari2600 folks, there it is only software that determines the size of a frame (and hence PAL/NTSC) and it often varies even within (commercial) games depending on scene /o\
http://www.digitpress.com/library/techdocs/vcs_scanlines.htm Seems like that is about number of lines per frame only, not length/duration of individual lines. |
| |
enthusi
Registered: May 2004
Posts: 675 |
Oh, yes of course.
HSYNC is (and must be) stable. And that is part of the video hardware (TIA), naturally. Or it wouldn't be 'racing the beam' but rather 'dragging the beam' :) |
| |
willymanilly
Registered: Jan 2016
Posts: 27 |
I'm not game to use my real hardware to run this demo so I've included "Drive GPU" support in Z64K (WIP - still needs a bit of work) which adds support for this demo.
For those who want to try it now, the demo doesn't play reliably in Z64K yet but it does play the sounds and graphics reasonably well when it does work. I have had it almost reach the end a few times but in most cases will spasmodically crash relatively early in the demo. note: If the disk track is not sitting at track 2 after the drive code is loaded and run, you will need reset and try again before switching to the drive GPU in machine settings and opening/closing the lever by reloading the same disk. http://www.z64k.com
It could be a number of reasons but I'm suspecting Z64K is having issues with correctly handling the bit banging of the track stepper which possibly causes reading of data from wrong track, eventually causing the demo to crash.
Does anyone have any info on what the mechanical delays are for the stepping motor on real hardware that should be taken into consideration for accurate emulation? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting willymanillyI'm suspecting Z64K is having issues with correctly handling the bit banging of the track stepper which possibly causes reading of data from wrong track, eventually causing the demo to crash.
Does anyone have any info on what the mechanical delays are for the stepping motor on real hardware that should be taken into consideration for accurate emulation? Have you checked Release id #160665 : Stepper Test 1.0 ?
Does Z64K currently pass Drive-emu-check (which checks for some/minimal modelling of r/w head inertia)? |
| |
willymanilly
Registered: Jan 2016
Posts: 27 |
Quoting KrillHave you checked Release id #160665 : Stepper Test 1.0 ?
Does Z64K currently pass Drive-emu-check (which checks for some/minimal modelling of r/w head inertia)? Cheers for that! I haven't checked out those tests yet. I'll have a play with them. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting willymanillyCheers for that! I haven't checked out those tests yet. I'll have a play with them. Alright! Will dig out the bug-fixed version of the latter, otherwise analysing it might cause more headache than necessary. =) |
| |
willymanilly
Registered: Jan 2016
Posts: 27 |
Quoting KrillAlright! Will dig out the bug-fixed version of the latter, otherwise analysing it might cause more headache than necessary. =)
Thanks for the heads up. :) I just ran the latter in Z64K and it displays the expected result for emulators "00,EMU,00,00". |
| |
Quiss
Registered: Nov 2016
Posts: 37 |
Quoting Raistlin
Should this be classed as a C64 Demo or something else?
FWIW, I'm fine with changing the category. Unsure which of the existing categories would be more fitting, though. (Or, if creation of a new category is on the table, what that should be?)
Quoting willymanilly
It could be a number of reasons but I'm suspecting Z64K is having issues with correctly handling the bit banging of the track stepper which possibly causes reading of data from wrong track, eventually causing the demo to crash.
Hmm, freespin typically doesn't crash if it's just on the wrong track (as long as it's not on a half-track). There's one part per track, so it'll just play whatever part is on that track. Send me a PM if I can help debug. |
| |
willymanilly
Registered: Jan 2016
Posts: 27 |
Quoting QuissHmm, freespin typically doesn't crash if it's just on the wrong track (as long as it's not on a half-track). There's one part per track, so it'll just play whatever part is on that track. Send me a PM if I can help debug.
Cheers, that's good to know re: one part per track. I've sent you a pm. :) |
| |
Trap
Registered: Jul 2010
Posts: 222 |
A category that covers all "Wild" c64 demos would be a good idea IMO. Covering, REU, SCPU, 1541, YAM etc. etc. (thus replacing the current REU only category) |
| |
Higgie
Registered: Apr 2002
Posts: 113 |
I totally agree with you, Trap. +1 for a category that covers all releases that rely on hardware other than c64 + c1541. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Good idea to have a "C64 on steroids" category!
One's tempted to just use the already existing "REU"-category for it right away, but I pretty much assume the mods won't accept such a friendly takeover ;) So we'll have to wait for upcoming wonders... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
A new category for ONE release. seems sane :) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@Groepaz: "ONE hit wonders" you mean ;) ? |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
How is it not a C64 demo? |
| |
Quiss
Registered: Nov 2016
Posts: 37 |
Quoting Zyron
How is it not a C64 demo?
It's possible to argue both sides. It *is* a demo, and it runs on the original C64 hardware.
But most C64 demo compos don't allow modification of (or even non-trivial interaction with) the hardware. And at Gubbdata, where it was released, freespin wasn't part of the demo compo, either, for that very reason. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
mod the launcher so it loads itself via &-file ... :=) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Groepazmod the launcher so it loads itself via &-file ... :=) Still needs a load command issued via serial bus, no? :) |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
We already have "Related release" - with one binary and two entries overall so far. Fill that up :)
Also looking at bugjam and Bigfoot for content on Tom & Jerry |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Quote:Still needs a load command issued via serial bus, no? :)
sure, but anything that connects to it could issue that command... even zoomfloppy or sth :) |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
When it comes to CSDb categories I think C64 Demo is perfectly valid for this. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
At least I am sure it is not an Amiga demo |
| |
Trap
Registered: Jul 2010
Posts: 222 |
Quote: When it comes to CSDb categories I think C64 Demo is perfectly valid for this.
For it to be a C64 demo I would argue any day that it should involve a C64. |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
I would go even further and argue that for something to be a c64 demo it would have to be a demo running on a Commodore 64. |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
I advice the thread gets back to the interesting technical questions. Learn some drive code instead of ranting that a "special" demo ate the top demo vote charts and spilled them out. You just want it out of the top list anyhow - open another thread on that then. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Quiss[...]
Quoting willymanilly
It could be a number of reasons but I'm suspecting Z64K is having issues with correctly handling the bit banging of the track stepper which possibly causes reading of data from wrong track, eventually causing the demo to crash.
Hmm, freespin typically doesn't crash if it's just on the wrong track (as long as it's not on a half-track). There's one part per track, so it'll just play whatever part is on that track. Send me a PM if I can help debug. Hm, ok, so this means the shorter parts are to be found on the higher tracks?
Now when I start pondering about this, how does the avarage drive speed influence the demo? Do the effects "slow down" on slower drives? And if so, can the demo get out of sync relative to the drive music or are the means to keep the syncing? |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Quote: Quoting Quiss[...]
Quoting willymanilly
It could be a number of reasons but I'm suspecting Z64K is having issues with correctly handling the bit banging of the track stepper which possibly causes reading of data from wrong track, eventually causing the demo to crash.
Hmm, freespin typically doesn't crash if it's just on the wrong track (as long as it's not on a half-track). There's one part per track, so it'll just play whatever part is on that track. Send me a PM if I can help debug. Hm, ok, so this means the shorter parts are to be found on the higher tracks?
Now when I start pondering about this, how does the avarage drive speed influence the demo? Do the effects "slow down" on slower drives? And if so, can the demo get out of sync relative to the drive music or are the means to keep the syncing?
I could do without your speculations about what my motivations for replying are!
On the point of it being off topic, you’re quite right. I didn’t check the initial post, and I’m sorry to have fed the off topic discussion. My apologies - bad form.
Edit: this was supposed to quote Count Zero’s post.. epic fail. :D |
| |
Trap
Registered: Jul 2010
Posts: 222 |
Sorry for the hi-jack. I was replying to other peoples comments. As for your original post, Count Zero (that you have since edited), I will address that with you in a private message. |
| |
willymanilly
Registered: Jan 2016
Posts: 27 |
I finally got this demo reliably running to the end in Z64K now! It had nothing to do with half tracks or mechanical delays. Long story short it was because my attempt to emulate VIA latching as described in VICE bugs #582 and #1462 still needs some work. Basically freespin was not always getting the latest valid and expected data from the VIA ports because of the incorrect latching emulation. |
| |
Quiss
Registered: Nov 2016
Posts: 37 |
Quoting mankeli
Does the music playback in this demo make the drive to misalign? I've heard the stepping the head a lot into the mechanical stop causes that.
Freespin doesn't actually bang against the mechanical stops, outside of the "load error" interlude during the horizontal stripes part.
In all other parts of the music, the head just goes back and fro between two half-tracks.
Haven't seen any drive misalignment or damage happen during development. (Two drives "died" on me, but one had a fused VIA that I blame on the power adapter, and for the other, the door mechanic broke.)
Quoting Copyfault
Hm, ok, so this means the shorter parts are to be found on the higher tracks?
Parts are all the same length, 1792 bytes. They only use the lower tracks. (Because PVCF said those sound better. :))
Quoting Copyfault
Now when I start pondering about this, how does the avarage drive speed influence the demo? Do the effects "slow down" on slower drives?
Worst that can happen is that the gap between two effects gets longer. This would affect both video and audio, so the demo stays in sync, but music will briefly be off-beat. |
| |
Quiss
Registered: Nov 2016
Posts: 37 |
Also, changed the release type of Freespin to "C64 Misc". Back to work, everybody. :) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting QuissAlso, changed the release type of Freespin to "C64 Misc". Back to work, everybody. :) The fact aside that C0 just did the right thing in mentioning that this thread is about the tech details of this outstanding release I have to take my hat off for Quiss' move.
Now create a demo for the vanilla c64-platform and reclaim the top1 easily, Quiss ;) |
| |
Raistlin
Registered: Mar 2007
Posts: 552 |
I’m actually a little sad that Freespin has now dropped off the always-visible charts on CSDb… but I do agree it’s not a “vanilla” demo - it’s something far more awesome.
“ this thread is about the tech details of this outstanding release”
- I disagree. Every release on CSDb has a comment section most commonly used for review-like commentary. But.. there’s also a link to discuss the release in the forum. This thread is titled “Release ——-: Freespin”. Because it’s a thread about the release. Everything about the release. IMO if a discussion is wanted about the technical aspects without interruption from everyone else, that could be a new thread just as easily as Trap’s about whether this is a C64 Demo or not … my 2c, anyway, that’s certainly the way I’ve seen this go on other releases on CSDb….
If there was a new category for these things, like C64 Misc Demos, then Freespin could he #1 on the “All Demos” chart at least.. perhaps? (If it in fact is - I haven’t checked).
Final point: I wish people would stop caring about who is #1. This is a database site - the voting just gives a little bit of interaction. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
All of that with sugar on top. That demo deserved the #1 spot more than any other recent one afterall. Deal with it :) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Raistlin[...]
“ this thread is about the tech details of this outstanding release”
- I disagree. Every release on CSDb has a comment section most commonly used for review-like commentary. But.. there’s also a link to discuss the release in the forum. This thread is titled “Release ——-: Freespin”. Because it’s a thread about the release. Everything about the release. IMO if a discussion is wanted about the technical aspects without interruption from everyone else, that could be a new thread just as easily as Trap’s about whether this is a C64 Demo or not … my 2c, anyway, that’s certainly the way I’ve seen this go on other releases on CSDb…. This is debatable, ofcourse. But with his initial post Krill gave this discussion a clear technical focus, so maybe my mind stuck with it. Otoh, this here is a general release discussion thread, so one can argue that "anything goes" if related to the release.
Quoting RaistlinIf there was a new category for these things, like C64 Misc Demos, then Freespin could he #1 on the “All Demos” chart at least.. perhaps? (If it in fact is - I haven’t checked). I agree! Without doubts Freespin would place above'em all in an "all in" category. And (at least for me) Bromance would be the safe no.1-spot of "vanilla C64 demos", so a top score for everyone;)
Quoting RaistlinFinal point: I wish people would stop caring about who is #1. This is a database site - the voting just gives a little bit of interaction. That'd be awesome if people stopped caring about votes! Why not get rid of this voting crap on csdb? Let's start with not-voting;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Just keep downvoting whoever whines about the votes. Works for me :) |
| |
Raistlin
Registered: Mar 2007
Posts: 552 |
Quote: Just keep downvoting whoever whines about the votes. Works for me :)
Haha :-)
Let me just search my forum history to see whether I've ever complained first ;-) (but, no, seriously, the charts make zero sense to me anyway - soooo many 80s/90s demos missing from the top of the charts that really deserve to be there more than a lot of the modern stuff). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Also dont update entries with new version - create a new entry if you release a bugfix (this entry is for the compo version) :) |
| |
Quiss
Registered: Nov 2016
Posts: 37 |
Quote: Also dont update entries with new version - create a new entry if you release a bugfix (this entry is for the compo version) :)
Quoting Groepaz
Also dont update entries with new version - create a new entry if you release a bugfix (this entry is for the compo version) :)
Interesting. Is it ok to add a new download to an existing entry, naming it something like "{name}-bugfixed.d64", or do people usually create an all-new csdb entry? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
new entry is the norm. updating entries with new files is generally tolerated for minor fixes like a typo in a scrolltext, and only within a very short timeframe |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
You guys are off topic :D |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Groepaznew entry is the norm. updating entries with new files is generally tolerated for minor fixes like a typo in a scrolltext, and only within a very short timeframe Closely related releases like this should be hard-linked and share the same vote/comment history, really. Would give a lot more incentive for people to actually make separate release entries. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Good someone mentions again how it should ideally be but wont happen anyway :=) |
