Bad Apple demos

A place to discuss general QL issues.
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Bad Apple demos

Post by NormanDunbar »

I have to admit, the title of this thread made me think that it was a piss take on some really bad demos for Apple products. Oops! :D

Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Bad Apple demos

Post by Derek_Stewart »

mk79 wrote:And finally, here is Bad Apple for the Sinclair QL in full length and with some music: https://vimeo.com/373787028. Enjoy.
Hi Marcel,

Nice video, just shows the difference between C and assembler.

I like the Digital Oscilloscope in the backgtound.


Regards,

Derek
stephen_usher
Gold Card
Posts: 429
Joined: Tue Mar 11, 2014 8:00 pm
Location: Oxford, UK.
Contact:

Re: Bad Apple demos

Post by stephen_usher »

mk79 wrote:What I mean here is that the original video is exactly synchronised to the music, so scene changes happen at specific notes, etc. I have written video software before, I know how to synchronize video and sound that was already in step in the first place. But the music I got from the net does not necessarily correspond in any way to the video, time wise. Just stretching it out so that it roughly correlates to the length of the video might work, but it could also just sound weird and still not match up with the video. In any case more time would be needed that I currently don't have :(
Sorry, I misunderstood your meaning.

It's tricky. I guess the best way may be to time from the beginning until the point where the band plays as that's a key location with a definite part in the music score. Then work out the difference in timing and adjust the music "clock" appropriately. Hopefully it should scale linearly and be a large enough time to give an accurate (enough) value.


stephen_usher
Gold Card
Posts: 429
Joined: Tue Mar 11, 2014 8:00 pm
Location: Oxford, UK.
Contact:

Re: Bad Apple demos

Post by stephen_usher »

Derek_Stewart wrote:Nice video, just shows the difference between C and assembler.
Not quite, it's more akin to the difference between interpreted code and compiled.

My code was reading what to put into the bytes onto the screen and doing so one at a time. mk79 wrote a program which interpreted the same sort of differencing and translated the changes into a series of 68000 instructions (compiled) which were then loaded from the file and called (I assume) as a subroutine which then acted upon the memory directly. (This is what I gathered from one of his previous posts.)


stephen_usher
Gold Card
Posts: 429
Joined: Tue Mar 11, 2014 8:00 pm
Location: Oxford, UK.
Contact:

Re: Bad Apple demos

Post by stephen_usher »

NormanDunbar wrote:I have to admit, the title of this thread made me think that it was a piss take on some really bad demos for Apple products. Oops! :D

Cheers,
Norm.
Well, the QL and Macintosh were announced within a week of each other.... :-)


User avatar
QLvsJAGUAR
Gold Card
Posts: 455
Joined: Tue Feb 15, 2011 8:42 am
Location: Lucerne, Switzerland
Contact:

Re: Bad Apple demos

Post by QLvsJAGUAR »

mk79 wrote:And finally, here is Bad Apple for the Sinclair QL in full length and with some music: https://vimeo.com/373787028. Enjoy.
Very nice! Well done!


QL forever!
https://www.sinclairql.net/ - Go and get THE DISTRIBUTION & QL/E!
https://www.youtube.com/QLvsJAGUAR/community - Blog
https://www.youtube.com/QLvsJAGUAR - Dedicated QL videos
Sinclair, QL, ATARI, JAGUAR, NUON, APPLE, NeXT, MiST & much more...
Videos, pictures & information
User avatar
QLvsJAGUAR
Gold Card
Posts: 455
Joined: Tue Feb 15, 2011 8:42 am
Location: Lucerne, Switzerland
Contact:

Re: Bad Apple demos

Post by QLvsJAGUAR »

stephen_usher wrote:
Derek_Stewart wrote:Nice video, just shows the difference between C and assembler.
Not quite, it's more akin to the difference between interpreted code and compiled.

My code was reading what to put into the bytes onto the screen and doing so one at a time. mk79 wrote a program which interpreted the same sort of differencing and translated the changes into a series of 68000 instructions (compiled) which were then loaded from the file and called (I assume) as a subroutine which then acted upon the memory directly. (This is what I gathered from one of his previous posts.)
@Stephen, did you continue to work on your project?
@Marcel, will this demo become available? maybe a post on your blog on kilgus.net?

Both work may not only be good for the Bad Apple video, but also as an example of how to get the most out of the QL.


QL forever!
https://www.sinclairql.net/ - Go and get THE DISTRIBUTION & QL/E!
https://www.youtube.com/QLvsJAGUAR/community - Blog
https://www.youtube.com/QLvsJAGUAR - Dedicated QL videos
Sinclair, QL, ATARI, JAGUAR, NUON, APPLE, NeXT, MiST & much more...
Videos, pictures & information
User avatar
QLvsJAGUAR
Gold Card
Posts: 455
Joined: Tue Feb 15, 2011 8:42 am
Location: Lucerne, Switzerland
Contact:

Re: Bad Apple demos

Post by QLvsJAGUAR »

QLvsJAGUAR wrote:Hi folks, summer is over, Urs is back. Image

Had some spare minutes after work, here‘s my little contribution:
https://youtu.be/LMbZZe4UWA0
The other day I spent some time to run a Bad Apple video on the Q68, see the result:
https://youtu.be/d7HPuAyHx5A

The two .QMV video files used with QPC2 and Q68 are available under the QL/E section of the SinclairQL.net website.

QL forever!


QL forever!
https://www.sinclairql.net/ - Go and get THE DISTRIBUTION & QL/E!
https://www.youtube.com/QLvsJAGUAR/community - Blog
https://www.youtube.com/QLvsJAGUAR - Dedicated QL videos
Sinclair, QL, ATARI, JAGUAR, NUON, APPLE, NeXT, MiST & much more...
Videos, pictures & information
Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Bad Apple demos

Post by Derek_Stewart »

QLvsJAGUAR wrote:
QLvsJAGUAR wrote:Hi folks, summer is over, Urs is back. Image

Had some spare minutes after work, here‘s my little contribution:
https://youtu.be/LMbZZe4UWA0
The other day I spent some time to run a Bad Apple video on the Q68, see the result:
https://youtu.be/d7HPuAyHx5A

The two .QMV video files used with QPC2 and Q68 are available under the QL/E section of the SinclairQL.net website.

QL forever!
Hi Urs,

Nice video of the Q68, just shows some of the features that it brings.

I note you have QL/E in DISP_MODE 6 (512x384 Hi-Colour), does suit QL/E better?


Regards,

Derek
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Bad Apple demos

Post by mk79 »

stephen_usher wrote:
Derek_Stewart wrote:Nice video, just shows the difference between C and assembler.
Not quite, it's more akin to the difference between interpreted code and compiled.

My code was reading what to put into the bytes onto the screen and doing so one at a time. mk79 wrote a program which interpreted the same sort of differencing and translated the changes into a series of 68000 instructions (compiled) which were then loaded from the file and called (I assume) as a subroutine which then acted upon the memory directly. (This is what I gathered from one of his previous posts.)
Well, actually when considering the SuperGoldCard which I used in the end for my video I expect the "interpreter" approach might even be faster than my "compiler" approach. The reason being that the compiler approach essentially executes 33MB of code (that has to come through the 8-bit bus bottleneck), rendering the code cache completely useless. The "interpreter" approach needs to execute MORE code, which on one hand is bad, but with a tight decoder loop (< 256 bytes) the code could be executed entirely from cache, freeing memory bandwidth for the data, which is a huge plus.
The equation is entirely different if you do not have a code cache like on GoldCard or unexpanded QL, which is why I tried the compiler approach first. On the unexpanded QL I currently guess that streaming whole frames directly from SD to screen memory might even be the fastest approach overall. I might try this one day as it's also the simplest approach.

One of the huge advantages that I used compared to your C code is that I fetch the data through low level raw sector access, I don't go through the file system layer.


Post Reply