Scene Demos and uIEC devices

[SparkyNZ]

Hi. Do any of you have any tips for getting demos to work with a uIEC card?

I have a stack of demos that I can't get to work on my real PAL Vic.

Take the "Out of Beer" demo http://www.dekadence64.org/outbeer.zip.

This loads the "Loader" and then it just sits there. I run it in VICE and it works fine. My uIEC device is mapped to device 8. I did this thinking that it would eliminate compatability problems with programs that expect device 8 to be a disk drive but no.. I still have problems.

Is this just the nature of demos or is there some sort of compatability mode setting for the uIEC that I'm missing?

Orb's OMD demo multiloads fine..

[Mike]

Many demos use an own fastloader. For this to work, these fastloaders install their own bus routines as program within the drive, which then is executed by the 6502 CPU of the drive. This is not emulated with SD2IEC devices.

In many cases though, the sd2iec firmware detects, when a fastloader is going to be installed (checksumming incoming data), and then the fast protocol is re-implemented within the controller. However, this mainly applies to C64 fastloaders.

The JiffyDOS protocol is implemented though, and when a program uses kernal calls to access the drive, it is speeded up on both C64 and VIC-20 (for example, with SJLOAD).

As a rough guide, when a program runs fine in VICE with TDE (true drive emulation) switched OFF, then it should also run fine with a SD2IEC device.

Greetings,

Michael

[eslapion]

Hi. Do any of you have any tips for getting demos to work with a uIEC card?

Don't use the uIEC card...

I have a stack of demos that I can't get to work on my real PAL Vic.

Blame the coders...

Take the "Out of Beer" demo http://www.dekadence64.org/outbeer.zip.

This loads the "Loader" and then it just sits there. I run it in VICE and it works fine.

VICE emulates a computer and drives which use 6502 processors. The uIEC is a spinoff of SD2IEC which uses an Atmel processor.

It will never "understand" the ML code the special loaders try to have it run.

That's why europeans are so hectic about emulating 1541 drives with devices such as the 1541 Ultimate and the Chameleon.

I know only of demos that use these special loaders because coders hate any form of expansion or alteration to the "original" system. Even Robotic Libertation has a nice message indicating "fuckings to all who suggested I should use RAM expansion"... nevermind the fact that just about every VIC user also used RAM expansion because of the very small amount of ram that came by default. Yet, back then, far more people had ram expansions on the VIC than 1541 drives... complete nonsense.

Don't you ever try to have these people give you a different version that doesn't have the special loader and would work with JiffyDOS or other drives. The typical answer is :"nobody is going to tell me what to do or not with my computer".

Do you know, on the VIC-20, anything at all that's from the original era of the VIC-20 (1981-1985) that used any form of special loader for a 1541 drive? I sure don't.

There were special loaders for tape software. If demo coders are so purist then why don't they make a special demo that uses an unexpanded VIC and runs from tape? Also, why is it that just about none of them run on "original" NTSC machines.

That's because just about all of them are people from the european C64 community where the 1541 is the norm for storage and NTSC just doesn't exist. Most euro demos for the 64 don't run on the NTSC 64 for the same reason.

[SparkyNZ]

Even Robotic Libertation has a nice message indicating "fuckings to all who suggested I should use RAM expansion"... nevermind the fact that just about every VIC user also used RAM expansion because of the very small amount of ram that came by default. Yet, back then, far more people had ram expansions on the VIC than 1541 drives... complete nonsense.

You seem to have strong feelings on the matter. I agree with you about the expansion though. I never had a disk drive when I had my Vic. I had my Vixen 16k expansion and that was all. I owned heaps of tape games in the end and I think the one and only game I owned that had a turbo loader was Shamus - it used to go about 10 numbers on the C2N and that was all. Pretty impressive back then.

A lot of the demoscene programmers love to prove what they can do with puny resources though. I remember running some Amiga demo years back called Cubeo or something -just after I'd saved up and bought a 50Mh 68030 accelerator card and it had some text saying how slooowwww my Amiga was. I have to admit that really got up my nose but I guess in the demo world its a non-censored form of art, freedom of speech, expressing etc so anything goes. But thats an example of the opposite really isn't it.

Do you know, on the VIC-20, anything at all that's from the original era of the VIC-20 (1981-1985) that used any form of special loader for a 1541 drive? I sure don't.

Why on earth would you even want a special loader? The 1541 is pretty fast for a 3k load really. You'd never be waiting 15-20 mins for a 1541 load with the Vic thats for sure.

By the way Elapsion, that avatar of yours caused me to seek out that Shatner documentary. It was very entertaining! I have the rather unique perspective in that his looks and mannerisms are just like my uncle's in the UK.. but I digress and should go to bed before I start counting RAM chops (or did I mean lamb chips?) Yeah.. time for bed..

[Mike]

Why on earth would you even want a special loader?

The problematic demos in question quite often come in the form of 'trackmos', i.e. they don't show a part, then load the next one, etc., but show the animation and play music uninterrupted as new data is streamed from disk.

This is not possible with the standard kernal load routines, and also not with 'standard' fast loaders like JiffyDOS. Rather these loaders use special protocols that can be interrupted at any point. The loaders are then either configured to load a few bytes each time during the vertical blank period, or - another method - all loads proceed completely in the foreground, and all effects + music are done the interrupt (which then doesn't disturb the load, as stated above).

Regarding viznut's fuckings: he eventually got some 'nice' replies from other people, who wanted to see the demo also with SD devices, and there *is* a version of Robotic Liberation available, which is single filed and runs on a +16K expanded VIC-20. So he got the message.

I'd hold no big hopes though to see the demo on NTSC. There are many cycle exact raster effects involved, and porting them from PAL to NTSC most probably requires a complete rewrite.

Michael

[SparkyNZ]

The problematic demos in question quite often come in the form of 'trackmos', i.e. they don't show a part, then load the next one, etc., but show the animation and play music uninterrupted as new data is streamed from disk

That makes sense. So these special loaders can't just use the normal kernel read/write functions during their interrupt (VBL) time?

Hmm. Well revisiting the days of the 1541 is something I have no intention of doing (unless emulated on VICE). My 1541 experience was pretty bad as a kid. The only thing worse for a kid on Xmas day than receiving a cool toy without batteries - is receiving a 1541 that goes out of alignment. At least I do have a PAL machine now, Mike.

On the subject of expansion, Mike.. thats another hack I've undertaken (get a piggyback a couple of 6264 chips etc). I think I'm just trying to see how much I can do to one of my Vics before killing it - a bit like stacking playing cards!

One thing I'd like to do is knock up a demo using the plain Vic character graphics. I used to love making pictures out of them as a kid. Some kind of story.. I dunno.. I liked the Wizard & the Princess for the CBM character drawn screens.

[Mike]

That makes sense. So these special loaders can't just use the normal kernel read/write functions during their interrupt (VBL) time?

No they cannot sensibly do so. Even if the transfer rate of the standard kernal routines averages out to a ~400 bytes/second throughput, there is no guarantee, that even a single byte fetch will return to the main program within the vertical blank period: just take a new sector that needs to be loaded from disk, which also is located on another track, and you end up with a wait of possibly >200 ms (a whole revolution of the disk + sector data read-in + GCR decoding)!

The first variant of speed loaders I described in my preceding post in that case simply return to the main program, indicating they couldn't fetch any data just at the moment, please try again later.

The second variant of loaders (as foreground, non-interrupt processes) idle in that case, yet the graphics effect and music in the interrupt continue, and the non-standard bus protocol is not disturbed by the (relatively long) execution times of the interrupt routines.

In any case, I'd like to point out, that the demo coders did not introduce the speed loaders because they just could, or wanted to 'sabotage' non-CBM DOS disk drives, or anything like that, but because they focussed on a certain design which required a seamless integration of demo effects and fetching new data from storage. Especially 'Veni Vidi VIC!' and 'Robotic Liberation' were written with that design decision in mind long before SD2IEC devices became widespread in use.

[Kananga]

Yet, back then, far more people had ram expansions on the VIC than 1541 drives... complete nonsense.

Just to add one more opinion:
I also never had a disk drive back then, but of course 8K (first one was quite expensive) and 16K switchable later. So for true VIC-20 experience don't use a disk drive but load your (unexpanded) demo from tape, for heavens sake!

[eslapion]

Regarding viznut's fuckings: he eventually got some 'nice' replies from other people, who wanted to see the demo also with SD devices, and there *is* a version of Robotic Liberation available, which is single filed and runs on a +16K expanded VIC-20. So he got the message.

Kewl! At least one got the message.

I'd hold no big hopes though to see the demo on NTSC. There are many cycle exact raster effects involved, and porting them from PAL to NTSC most probably requires a complete rewrite.

I'm one of the lucky few in north america who has a PAL VIC-20.

Would you have a link to that single filer?

[Mike]

Would you have a link to that single filer?

http://www.pelulamu.net/pwp/vic20/rl-16k.prg

[SparkyNZ]

Would you have a link to that single filer?

http://www.pelulamu.net/pwp/vic20/rl-16k.prg

Time to go and make me a 16k expansion now I think.. It would be cool to see a few more 16k demos.

I'm still quite blown away with some of the Vic sounds in the Orb Megademo. There's one track (3rd or 4th??) that has drums that sounds similar to what you'd hear on the C64. Very impressive. I hope to see (hear!) more!!

[eslapion]

@Mike:
Hey thanks!

[SparkyNZ]

Would you have a link to that single filer?

http://www.pelulamu.net/pwp/vic20/rl-16k.prg

I don't suppose you know of any other demos that have been squashed into a 16k version?

[Mike]

I couldn't recall any other at the moment. There are demos which require 16K yet also run from SD2IEC, like 'Going Lowres' and 'Yes VIC can'.

A trackmo can easily span a whole disk side (i.e. 170K, or more). So, unless one employs something like FE3 + Kananga's RAM Disk, you can only single file those trackmos, whose data files span less than the main memory of the VIC-20 which standard RAM expansions.