Bad Apple demos

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

Re: Bad Apple demos

Postby NormanDunbar » Tue Nov 19, 2019 9:02 pm

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 - https://www.amazon.co.uk/Arduino-Softwa ... 1484257898, https://www.apress.com/gb/book/9781484257890
Derek_Stewart
QL Wafer Drive
Posts: 1924
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Bad Apple demos

Postby Derek_Stewart » Tue Nov 19, 2019 10:51 pm

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
Trump Card
Posts: 249
Joined: Tue Mar 11, 2014 8:00 pm

Re: Bad Apple demos

Postby stephen_usher » Tue Nov 19, 2019 11:22 pm

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
Trump Card
Posts: 249
Joined: Tue Mar 11, 2014 8:00 pm

Re: Bad Apple demos

Postby stephen_usher » Tue Nov 19, 2019 11:28 pm

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
Trump Card
Posts: 249
Joined: Tue Mar 11, 2014 8:00 pm

Re: Bad Apple demos

Postby stephen_usher » Tue Nov 19, 2019 11:30 pm

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: 346
Joined: Tue Feb 15, 2011 8:42 am
Location: Lucerne, Switzerland
Contact:

Re: Bad Apple demos

Postby QLvsJAGUAR » Wed Nov 20, 2019 6:00 am

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!
http://www.sinclairql.net/ - Go and get THE DISTRIBUTION & QL/E!
https://www.youtube.com/QLvsJAGUAR
Sinclair, QL, ATARI, JAGUAR, NUON, APPLE, NeXT, MiST & much more...
Videos, pictures & information[/i]
User avatar
QLvsJAGUAR
Gold Card
Posts: 346
Joined: Tue Feb 15, 2011 8:42 am
Location: Lucerne, Switzerland
Contact:

Re: Bad Apple demos

Postby QLvsJAGUAR » Wed Nov 20, 2019 6:16 am

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!
http://www.sinclairql.net/ - Go and get THE DISTRIBUTION & QL/E!
https://www.youtube.com/QLvsJAGUAR
Sinclair, QL, ATARI, JAGUAR, NUON, APPLE, NeXT, MiST & much more...
Videos, pictures & information[/i]
User avatar
QLvsJAGUAR
Gold Card
Posts: 346
Joined: Tue Feb 15, 2011 8:42 am
Location: Lucerne, Switzerland
Contact:

Re: Bad Apple demos

Postby QLvsJAGUAR » Wed Nov 20, 2019 6:25 am

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

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!
http://www.sinclairql.net/ - Go and get THE DISTRIBUTION & QL/E!
https://www.youtube.com/QLvsJAGUAR
Sinclair, QL, ATARI, JAGUAR, NUON, APPLE, NeXT, MiST & much more...
Videos, pictures & information[/i]
Derek_Stewart
QL Wafer Drive
Posts: 1924
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Bad Apple demos

Postby Derek_Stewart » Wed Nov 20, 2019 8:49 am

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

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
Super Gold Card
Posts: 644
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Bad Apple demos

Postby mk79 » Wed Nov 20, 2019 12:22 pm

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.



Who is online

Users browsing this forum: No registered users and 5 guests