greatest achievement on limited machines (?)
category: general [glöplog]
Which was the greatest achievement in term of limitation breaking on old computers? I mean, is there an hack on some computer that counts as the most groundbreaking?
Yes.
Which one?
I'd also like to know what the best demo is. If someone could help me that would be great, thanks.
WHY ARE YOU NOT AT MAIN
well, i've been too lazy to renew my passport, for starters.
(chriz: English is a fucked up language. Terms such as 'Best' are highly subjective, but the language doens't indicate that whatsoever. An Amiga scener might feel that Glenz Vectors are the greatest thing ever, meanwhile, a Speccy scener may suggest that the effect isn't even worthy of the term 'effect.'
So your answer is: Phoenix has leading.
Even if he can't tell the difference between a Vic20 demo and a BITS demo. Which he should be completely ashamed of.
And you should both be at MAIN.)
So your answer is: Phoenix has leading.
Even if he can't tell the difference between a Vic20 demo and a BITS demo. Which he should be completely ashamed of.
And you should both be at MAIN.)
not best in term of anything other than "this can't be done with this specs". I'm not talking aesthetics..
Some great computer hacks.
Mmm,. sorry for the pouetization. I just can't handle it. Whenever I hear the words "computer" and "hacking" together, this is what comes in my mind literally.
Actually your thread could be interesting, one of those "what are those 8bit effects that have blown your mind away" I always like to read about. Although they are not very popular here (also look http://www.pouet.net/topic.php?which=2108). Except if the question gets more specific and opens a more interesting coding porn thread.
Actually your thread could be interesting, one of those "what are those 8bit effects that have blown your mind away" I always like to read about. Although they are not very popular here (also look http://www.pouet.net/topic.php?which=2108). Except if the question gets more specific and opens a more interesting coding porn thread.
Also, if you'd ask me this would be the distorted/zooming bitmap in Parts by Oxyron. I know there might be bigger and better zoomers these days on the C64 but I am thinking about the very first moment something ever impressed me so much. Nowadays because as a coder in the scene someone knows how most of the "impossible" things happen anymore, the magic is lost for old farts. I would like to see something that really brings again that "But how is it done? I think I am dreaming.." feeling.
To follow the topic,
I think that syncscrolling on the ST should be at the top when it comes to groundbreaking hacks.
I think that syncscrolling on the ST should be at the top when it comes to groundbreaking hacks.
What about the tape based hardware vsync hack from Fabrice Frances on the Oric :) ?
Just to post ON topic:
I think this was quite an achievement:
http://www.pouet.net/prod.php?which=53505
I think this was quite an achievement:
http://www.pouet.net/prod.php?which=53505
The INVENTION OF AMIGA.
i've not witnessed this era, but this french text did give me a glimpse of what it has been:
http://www.codercorner.com/DemosEtMerveilles.htm
it mentions the absolute, incredible, mindblowing awesomeness of seeing the atari ST doing "overscan" fullscreen in 448*274 in place of normal 320*200, and then managing to do something like a hardware scrolling on that.
The machine was never designed to do it, anf the hack used many lowlevel tricks and cycle-accurate and electron-beam-accurate routines.
i guess that is what evil mentioned some posts ago.
http://www.codercorner.com/DemosEtMerveilles.htm
it mentions the absolute, incredible, mindblowing awesomeness of seeing the atari ST doing "overscan" fullscreen in 448*274 in place of normal 320*200, and then managing to do something like a hardware scrolling on that.
The machine was never designed to do it, anf the hack used many lowlevel tricks and cycle-accurate and electron-beam-accurate routines.
i guess that is what evil mentioned some posts ago.
The achievements dont ghet much greater than pouet, and the limitations do not come much more restrictive than as in the demoscene
So Pouet for the demoscene is THE greatest achivement on THE most limited artistic platform.
So Pouet for the demoscene is THE greatest achivement on THE most limited artistic platform.
I am wondering how hard the atarist overscan is. Is it harder than on CPC? How does it work? (The website was only in french)
Optimus: It is quite tricky.
1. Top border, this is quite easy. Normally you setup an interupt to trigger before the line to open it at. At the interupt, wait for HBL, wait N cycles more, zap the screen to 60Hz, wait N cycles, zap back to 50 Hz. This is not done 100% cycle accurate, there can be some 4-8cycles pending or so. Anyway this give you 29 scanlines more in the top border.
2. Perfect sync, the madness begin here. Now the CPU must be exactly synchronized with the raster beam, you do this by a bit of magic code that reads the content of the video addres counter and use the result as N for a shift instruction (shifts uses more cpu the more steps it goes). This way you get perfectly synchronized, you will keep this sync for the entire vbl (or or as many scanlines you will open borders on).
3. Left border. 24 cycles into the scanline, you zap the screen into 71Hz. Then back to 50Hz. This needs repeating every scanline that has the left border open.
4. Right border. 102 cycles into the scanline you zap the screen into 60Hz. Then back to 50Hz. This needs repeating every scanline that has the right border open.
5. Lower border. This is the easy one, but combined with left/right overscan it becomes a bit tight. Anyway in addition to the left border code, you add another 50/60Hz switch which will take care of the lower border. Only needs to be done on scanline 229 once.
6. Stabilizer. As if the above isn't hard enough, it will produce graphics errors. So some wizheads made a stabilizer that corrects the problem. It's a 71/50Hz switch again far out in the right border.
Now, this gives you 416x273 useable resolution. The first scanline is used for the hard-sync and will be lost (if you only open the top border and not left/right, the 274'th line can be used as well). The linewidth is 230 bytes (which is eneven by the ST's 8byte interleave) which made some people think they had 448 pixels visible (224 bytes) but in reality the visible PAL output is only 416 pixels.
Then you want to add a demo effect to this. Welcome and add your code 100% synchronized between the border frequency switches :-)
Perhaps this can add a little more respect for ST fullscreen coding? It's really a different world from traditional "non fullscreen" coding.
Next in line: Syncscroller.
The ST have no way to hardware scroll the screen. The video address pointer needs to be even by 256 bytes, which means it can only scroll eight 160 byte scanlines in a go, a bit too fast for any real usage - but with several screen buffers it can be made slower.
Anyway no way to scroll sideways at all.
Now think how the overscan above is made, by doing frequency switches to open borders. If you open borders in different ways, you will get different linewidths. By mixing a bunch of different overscan routines with different linewidth in N number of scanlines at the top of the screen, you offset the display pointer. Doing enough combinations you actually come down to 8 byte offset resolution - voila! 16px sideways "hardware" scrolling! This is what's called syncscrolling. At the start the syncscrollers needed some 12-16 scanlines of different linewidth combinations, effectivly using 12-16 scanlines CPU. Today the better routines are down to 4-5 scanlines. Also worth to mention is ST Connexions nibble-syncscroll which actually manage of offset the screen by 4 pixels, which I quite don't understand :-) However, this does not work on STe video shifters, only plain ST. But as the STe features hardware scrolling one can use two codepaths there.
Okay, I probably have some details wrong here and there (writing this off my head..) so correct the bad bits. And I now, Pouet is not for serious talk, but I thought it was worth a try as the subject interests me.
1. Top border, this is quite easy. Normally you setup an interupt to trigger before the line to open it at. At the interupt, wait for HBL, wait N cycles more, zap the screen to 60Hz, wait N cycles, zap back to 50 Hz. This is not done 100% cycle accurate, there can be some 4-8cycles pending or so. Anyway this give you 29 scanlines more in the top border.
2. Perfect sync, the madness begin here. Now the CPU must be exactly synchronized with the raster beam, you do this by a bit of magic code that reads the content of the video addres counter and use the result as N for a shift instruction (shifts uses more cpu the more steps it goes). This way you get perfectly synchronized, you will keep this sync for the entire vbl (or or as many scanlines you will open borders on).
3. Left border. 24 cycles into the scanline, you zap the screen into 71Hz. Then back to 50Hz. This needs repeating every scanline that has the left border open.
4. Right border. 102 cycles into the scanline you zap the screen into 60Hz. Then back to 50Hz. This needs repeating every scanline that has the right border open.
5. Lower border. This is the easy one, but combined with left/right overscan it becomes a bit tight. Anyway in addition to the left border code, you add another 50/60Hz switch which will take care of the lower border. Only needs to be done on scanline 229 once.
6. Stabilizer. As if the above isn't hard enough, it will produce graphics errors. So some wizheads made a stabilizer that corrects the problem. It's a 71/50Hz switch again far out in the right border.
Now, this gives you 416x273 useable resolution. The first scanline is used for the hard-sync and will be lost (if you only open the top border and not left/right, the 274'th line can be used as well). The linewidth is 230 bytes (which is eneven by the ST's 8byte interleave) which made some people think they had 448 pixels visible (224 bytes) but in reality the visible PAL output is only 416 pixels.
Then you want to add a demo effect to this. Welcome and add your code 100% synchronized between the border frequency switches :-)
Perhaps this can add a little more respect for ST fullscreen coding? It's really a different world from traditional "non fullscreen" coding.
Next in line: Syncscroller.
The ST have no way to hardware scroll the screen. The video address pointer needs to be even by 256 bytes, which means it can only scroll eight 160 byte scanlines in a go, a bit too fast for any real usage - but with several screen buffers it can be made slower.
Anyway no way to scroll sideways at all.
Now think how the overscan above is made, by doing frequency switches to open borders. If you open borders in different ways, you will get different linewidths. By mixing a bunch of different overscan routines with different linewidth in N number of scanlines at the top of the screen, you offset the display pointer. Doing enough combinations you actually come down to 8 byte offset resolution - voila! 16px sideways "hardware" scrolling! This is what's called syncscrolling. At the start the syncscrollers needed some 12-16 scanlines of different linewidth combinations, effectivly using 12-16 scanlines CPU. Today the better routines are down to 4-5 scanlines. Also worth to mention is ST Connexions nibble-syncscroll which actually manage of offset the screen by 4 pixels, which I quite don't understand :-) However, this does not work on STe video shifters, only plain ST. But as the STe features hardware scrolling one can use two codepaths there.
Okay, I probably have some details wrong here and there (writing this off my head..) so correct the bad bits. And I now, Pouet is not for serious talk, but I thought it was worth a try as the subject interests me.
Just about anything by Crest's coders for the C64 and Viznut's work on the Vic-20
Overscan/syncscroll are pure madness, truly groundbreaking imho.
thanks for the insight, evil.
it really seems to be a pain in the ass to code it though.
it really seems to be a pain in the ass to code it though.
chuncky-to-planar routine on the Amiga. it single-handedly changed the style of demos on the Amiga for ever.
As someone sat outside of the Amiga scene (a bit), can someone explain c2p to me please?
