magazine logo
Welcome to the official Attitude website - Europe's #1 C64 scene disk magazine
Coding: Escos
by Puterman/Civitas

Back in the good old days, when most people thought of disk drives as an unnecessary luxury, when all code was written in monitors and demos were something new, opening the side border was still regarded as impossible. Until 1001 Crew did it, of course. They weren't content with scrolling a text through the side border, though, they wanted something more. They released a demo called "In the Border We Trust", where the whole screen was filled, including top, bottom and side borders, with 8x7 expanded sprites. Okay, all sprites used the same sprite data, but that was just a detail...

And soon they unleashed ESCOS to the poor, unsuspecting world. A full-screen picture. And we're not talking about some lame shit with the borders closed, but a full-screen picture, including the borders, in three colours. The ESCOS demo should be available on some of the usual FTP sites, if you want to check it out. ESCOS pictures were also used in both the 2nd and 3rd place demos at the recent LCP party in Sweden, in Active's "O-Tech People II" and Civitas' "Clown". And if you want to see the ultimate ESCOS effect, check out the great ESCOS mover in Booze Design's "Totally Stoned II".

Now, if you want to display an ESCOS picture, what do you do? An ESCOS picture consists of 8x7 X and Y expanded sprites, yielding a picture that covers 384x294 pixels. As the sprites are expanded, though, the picture really only consists of 192x147 pixels, and as all ESCOS pictures I've seen are in three colours, the actual horizontal resolution is only 96 pixels. There's nothing stopping you from making a one-colour ESCOS picture of course...

So, basically, all that needs to be done is to set the Y coordinates of all sprites to 4 (or something like that) and the X coordinates to $00, $30, $60 etc., and then change the Y coordinates and the sprite pointers as you progress down the screen, while you bash $d016 on every line to open the side border. If you, like me, are a bit unexperienced in this kind of exactly timed coding, you might get some trouble getting it to work, but that only makes it more fun when you actually get to see the whole picture!

Before I move on to some implementation details, I'll discuss the small matter of creating graphics data, ie. ESCOS picture data. I don't know of any editor, and the only conversion program I know about is written by 1001 Crew. What I did was to write my own conversion program. This program takes a normal lores bitmap and just grabs the 192x147 pixels on the top left and converts them to sprite data. (The program is written in C under Unix, and if you're interested in it, send me an email.) Another possibility, if you just want something to use while debugging, is to rip the graphics. In the 1001 Crew demos, the ESCOS pictures are located at $6000, and if you've done your maths, you should understand that you should save the data from $6000 through $6e00.

Time to get into some dirty details on implementation. The way I did it was to use a big, unrolled loop, that covers 42 raster lines. On each line I do an FLD (to push away the bad lines), open the side border and set the Y coordinate of one sprite. The code (for one
line) looks something like this:

lda $d012 ; FLD
adc #$04
and #$07
ora #$18
sta $d011
nop ; timing
nop
dec $d016 ; open border
inc $d016
lda y,x ; y coord
bit $ea ; timing
sta $d005 ; y sprite 2
nop ; timing
bit $ea

This might look a bit clumsy, but I had to kludge about a bit to get the border opening to sync well. One problem you get when you have loads of sprites turned on is that memory accesses will sometimes be delayed by the sprite data fetch, and the result is that you can't seem to get the delays to work as they should. On the other hand, you get a stable raster without any work at all. (For a more detailed account on sprite fetches, delays and timing, see "Missing Cycles" in
C=Hacking, issue 3.)

What happens at the beginning or end of this unrolled loop is the only thing that differs from all the other lines, which look pretty much like the one above (just change $d005 to some other sprite y coordinate register). Here you need to change the sprite pointers. This can be done in two different ways. Either you do it manually, ie. get some value and poke it into screenmem+$03f8, get another value and poke it into screenmem+$03f9, etc., or you just switch to another screen memory, with another set of sprite pointers, by using $d018. The second alternative is faster, which might be nice if you're doing something more on each raster line. As you can see in the code snippet above, there's some raster time (12 cycles) left for doing other stuff, eg. changing $d021 (forget $d020, with all borders open you can't see it) or the sprite multicolour registers. And of course, you can save some cycles on the FLD routine too.

Before ending this short article, I'll just have to warn you about moving around sprites in the side borders. If you've seen my demo "Clown", you've noticed that the ESCOS pictures come scrolling in from the right end of the screen. In the first version of that code, I simply moved the whole picture. But then I noticed that sprite 0 behaved badly in the right border. The reason is that this is where the sprite data is fetched from RAM. So I had to rewrite the code, so that sprite 0 was never in the right border. After a short exchange of emails with an expert, I also knew that sprite 1 also behaved badly, as did sprite 2, but I couldn't see this on my TV, which doesn't display the whole border. And in the save way, sprites 6 and 7 might look bad in the left side-border. So the code that scrolls the ESCOS picture onto the screen doesn't move the sprite X coordinates more than $2f pixels, then the sprite pointers are changed.

I hope that someone has found this article interesting, and that I've given you one or two ideas. If you have any questions, feel free to send me an email.

PUTERMAN/CIVITAS

   Add/view comments on this article (comments: 0)

SCENE GROUPS
 
OPINION POLL
Do you believe we are
able to cope with
releasing "Attitude"
on a regular basis?

yes no

 YES: 279 (70.45%)
NO:117 (29.55%) 

NEWS COMMENTS

ART COMMENTS

STATISTICS
all visits:

visits today:


website started:
23/09/2004
 
Official Webpage
of Attitude
Copyright 2004-2018
 
DJ Gruby/TRIAD