In the mid eighties two giants of the home computer were fighting for domination: Commodore with the Amiga range of computers, and Atari with the ST family.
Both machines had similar type of software products, ranging from home accounting to video games, from desktop publishing to audio-visual demonstrations.
This is that last type of software I'm going to focus on in this article.
DemosComputer demos have always been kind of hard to explain to people.
Try to convince people that there's any value in something that requires an incredible amount of skill, time, and basically is worthless and does not make any money. Good luck!
It's a bit like convincing people that there's value in traditional art, except here you don't generally even make money from it.
Anyway, making computer demos is an interesting activity for people who start doing it, mostly because it's kind of the intersecting point of many disciplines, each one requiring a high level of execution in order for the whole to be any good at all:
You need state of the art skills in programming, visual art, audio, design, plus a small something that makes your own thing stand out with this hard to define wow factor.
I myself entered this little universe around 1987, teaching myself assembler by reading articles in magazines, disassembling other people's games and intros, and then of course by practicing again and again.
By 1989 I had joined a group called NeXT, and we were busy working on some ambitious games and demos.
STNICCC 19901 produced by Richard Karsmakers and Stefan Posthuma.
It will be remembered as one of these parties where the top of the cream of the Atari demoscene attended.
I was not there, because I caught the flu few days before and was busy being miserable in my bed instead of of having the time of my life out there at the ST News International Christmas Coding Convention.
As some say, "Life sucks, and then you die" :)
STNICCC 2000But everything was not lost, there was still room for repentance!
In April 1999 I received the following email2:
I would like to ask you to point your browser to
http://www.fortysecond.net/stniccc2000 and consider yourself invited to
the ST News International Christmas Coding Convention 2000. Please check
out what will happen and when it will happen on the Organisation and
Info site, and get back to me if you'd like to come. Please tell me
whether you will come "certain!", "almost certain!" or "probably"!
For sake of completeness, supply your coding name, your real name and
the name of the group you're in.
Some of you were not at the original event, but you have been included
because the party would not be complete without some of people who have
left their marks on the ST/Falcon scene since 1990...
Thanks for your time, and I hope to see you there!
\= Richard Karsmakers - r######@###########.### - ICQ #******** =/
| "ST NEWS" disk mag; "W3M3" magazine; "Twilight World" magazine |
|Disk Magazine WebRing; Shred Guitar WebRing; Atari Scene Reunion|
| Plantiac Adoration Shrine; GWAR FAQ; Fear of God/FOG home page |
| http://www.fortysecond.net |
/===--- P.O. Box 67, NL-3500 AB, Utrecht - The Netherlands ---===\
I immediately headed up to the indicated website and looked at the competitions categories, and decided to try my chance at two of them:
- C64 TIMES REVISITED COMPETITION4
- ST NEWS LOGO IN THE STRANGEST PLACE
I originally planned to make an Atari demo, but a combination of brain rustiness, uncooperative hardware, and lack of confidence made me choose to enter the compo with an Oric intro instead.
It was a bit rushed, did not have any sound, but it was the first practical application of my new "pseudo true color" video mode, my first bitmap tunnel, and my first rotozoom as well.
I ended-up winning in both categories, while Leonard from Oxygen won the main Atari demo category with his jaw dropping polygon streaming engine.
The jury was specially impressed by my ST NEW LOGO IN THE STRANGEST PLACE entry: They did not know it, but they already had my entry in their possession!
As a tool programmer at Eden Game I was in charge of all the data building tools, and instead of writing spaces in the padding areas I had written a custom message:
// 256 bytes of filling stuff for padding datas...
"-ORIC AND ATARI-"
"-ORIC AND ATARI-"
"-ORIC AND ATARI-"
"-ORIC AND ATARI-"
That was entertaining to say the least!
STNICCC 2015Fast forward 15 years.
At the end of the previous edition we were joking about making a new one in 15 years, but reasonably we were not sure we would had anything to do at all with Atari things, but two or three years ago people started to ask on IRC and various forums if that was actually going to happen.
Then finally things fell into place, and we were back in business :)
After few months of work I had something ready for the party, and then it was already December with all my good old demoscene friends.
I managed to win the first place in the C128 times revisited category despite the display being totally broken during the compo presentation and starting without any sound!
Here is how it was supposed to look and sound like (filmed directly from my monitor)
And in the Main Atari demo competition it's again Oxygen that won with their "We were @" mammoth fullscreen effort.
It's indeed a repeat of the 2000 edition results!
Ultimately it all ended up nice and tidy, but the way there was not without screams and tears...
FrustrationMy last big Atari demo was Save The Earth in 2009.
It was written 100% with Devpac using Steem in Fast Forward mode to assemble the code.
It kind of worked, but compared to my Oric setup it was a bit clumsy.
With the OSDK I can do 100% of the work with efficient tools and modern compilers and assemblers instead of having to rely on a slow emulated CPU.
This time I tried to use VASM: That was a terrible, terrible error.
VASM is not a bad assembler, but it's one of these gigantic portable/retargetable things that try to do it all and end up not being optimal on anything. It's basically a collection of modules that handle the generic syntax plus some extensions for the specific platforms or compatibility layer with specific assemblers.
The end result is that the bugs are hard to catch, you need to use exactly the right set of badly documented flags, and the concept of regression testing does not seem to exist so you can end up with a more recent version that has broken support for some stuff that apparently worked few versions before.
Ultimately, when a crash happened I was never sure if it was my code being buggy or the assembler being broken.
A simple example:
The obvious error is that the .loop label is defined twice, but instead of reporting an error the assembler generated code that jumped to the first .loop label, effectively leading to an unfinitely looping program.
nop ; $5806e
dbra d0,.loop ; dbf d0,$5806e
nop ; $58076
dbra d0,.loop ; dbf d0,$5806e
The most serious issue I encountered were:
- Not reporting duplicate symbols, resulting in loops and jumps doing unexpected things
- Many error messages not reporting in which file or line the problem happened
- Devpac commands are mostly supported, but sometimes behaved differently (ex: _rs meta variables)
- Reporting is not as good as Devpac, getting a list of sections with symbols and their size was a hassle
Hopefully GGN's version of Atari's Madmac will be more usable.
For STNICCC 2015 I wanted to try something I had not done before, so I decided to build the best possible demo I could do running on an Atari SC1224 monochrome monitor.
I spent few months trying to see what was actually doable.
I was able to do a number of nifty effects, including top and bottom overscan, but I did not manage to get anything stable that would run fine on most machines.
The main issue is that the timings in monochrome are so much tighter than they would be in color mode!
A standard 50hz FullScreen routine has frequency switches that involve two instructions running just one after the other, without any delay in between.
In monochrome mode, the vertical frequency reaches 71.2Hz - which is already quite a lot faster than the default 50hz -, but you also have to take into consideration that there are twice as many scanlines, which means we only have half of that time remaining. That makes it all but impossible to have a generic routine that works on every machine.
I suspect that given some time, it should be possible to write a routine that detects the particular timings of a specific machine, and then generate optimal code to handle this machine, but I had no more time to spend on this.
Finally, the biggest technical challenge was probably to make it all fit in 128k, considering that I had quite a lot of high resolution graphics, and also some sampled music.
Looking backward, it's probably not the demo I thought I would have normally done, but it's kind of nice from time to time to drop the pure "design" demo and just go for pure violent hardware register smashing :)
I hope you liked it!
See you all at the STNICCC 2032, after all, I will only be 62 years old :D
1. Some form of interactive software news delivered on floppy disks.↩
2. Yes, I do have the email in my mail box :p↩
3. As long as it's not skid marks in the office toilets↩
4. (The only rule was that the executable of the demo should not exceed 38912 bytes, the number of bytes free on a Commodore 64)↩
5. Generated by a special version of PictConv generating two complementary dithered pictures to swap out fast at runtime↩