Nice. But if I remember correctly, Mode X was a special VGA mode to squeeze a bit more performance (due to planes and full graphics memory addressing), not the "normal" MCGA 320x200x256 (13h)
If you're interested, I also implemented a few effects like lens[0] and Jare's fire[1] along with some other amusements[2]
Thanks for sharing the link! I remember the lense demos, and I remember downloading one or two of them from a BBS that had NSFW pictures rendered in the background.
wvh 4 hours ago [-]
That's one way to stimulate memory...
I was so into this in the mid-90s. I tried some assembly but I wish I would have been better at the maths part back then.
ryan42 27 minutes ago [-]
I always liked this one. it is really impressive and I used it as a screensaver for many years.
Thanks for sharing, I do not believe that I was familiar with that term at the time.
dr_dshiv 8 hours ago [-]
Thanks for putting this together!
I’ve been thinking a lot about demoscene in a Vibecoding era. Demoscene was often very close to the metal; Vibecoding is often completely abstracted from it.
To explore this tension, I’m cohosting an 8bit game design workshop (pico8) in Amsterdam this summer. Just for fun.
Working with intense constraints can bring a lot of creativity. I really want to see how AI affects the workshop vibe.
elpocko 7 hours ago [-]
>very close to the metal
>(pico8)
But PICO-8 with its integrated tools and Lua programming is super high level, pretty far removed from "8bit". It's only 8 bit in aesthetics, entirely artificial and forced. Why not write games for the 2600, the C64 or the NES to experience real constraints of an actual 8 bit platform, the actual "metal."
dr_dshiv 5 hours ago [-]
I know, tell me about it, we’ve been debating this, tbh. We landed on pico8 to introduce the ideas of creativity within constraints as there is a very active community and nice tooling. We’ve done NES workshops before, but always with CS students and eproms. 6502 assembly isn’t that complicated, but can be scary.
elpocko 5 hours ago [-]
I've been thinking about making a fantasy computer/console that uses an emulated 65C02 CPU, maybe a bit simplified -- every instruction only taking 1 cycle, for example. You could use all existing tools for the 6502, like the amazing 64tass, and there's an interesting high level language called prog8 (https://github.com/irmen/prog8) that's relatively easy to use. Not sure if there's any interest for something like that.
Lerc 44 minutes ago [-]
I was working on something using AVR assembly as a fantasy console.
I never quite completed it, but I managed a emulator/assembler IDE in the browser. Making my own assembler let me play around with some ideas for macros.
Reflecting on it now, I think one feature that could help a assembler on devices like this is the ability to inline compile assignment expressions that use values of only one type. It would be easy enough to emit a stream of instructions for
x=32+(x*(y+2))
or even
r15=32+(r15*(y+2))
using registers as expression values.
The result would usually be what an assembler writer would write themselves.
I think a macro assembler that did that would ease a lot of the tedium of assembly while maintaining the near absolute control over memory use and IO that you need for low level coding.
ceronman 5 hours ago [-]
Hi! That sounds very interesting, where can I find information about this workshop? I am interested in participating.
imiric 5 hours ago [-]
Vibecoding is entirely antithetical to demos.
Demos aren't just pretty visuals. Their entire purpose is to showcase the skills of the programmer in accomplishing something remarkable within a constrained environment, or within artificially imposed constraints. Using exorbitant amounts of resources to run a machine learning model to generate a muddy mixture of existing demos goes completely against this spirit. The idea of the two together is, frankly, repulsive.
dr_dshiv 5 hours ago [-]
Be repulsed then! We are doing the workshop specifically to explore this tension. I’m well aware that times are weird.
This workshop is actually a forerunner to a workshop on demos with quantum computers, where the constraints are very real and creative participation is very lacking.
gneissguise 7 hours ago [-]
It was my pleasure to work on and share, glad you liked it!
kookamamie 8 hours ago [-]
Nice. Except that Mode X was not usually called 13h. The former would be 320x240 and the latter 320x200. Technically X would be a variant of the 13h, though.
ale42 7 hours ago [-]
And actually, INT 13h is the BIOS interrupt to access block-based disk I/O functions (like sector read, track format, etc.). The INT used for mode-setting is 10h (with AH=00h and AL=13h as mode for 320x200 at 256 colors).
gneissguise 7 hours ago [-]
Thank you both for the corrections, I was a teen in the 90s so I could have had it wrong or misremembered.
I just looked up the 13h interrupt and you are absolutely right!
kookamamie 2 hours ago [-]
An awesome contribution nevertheless!
juhanakristian 8 hours ago [-]
Well done! These look very authentic. I remember creating the fire and plasma effects when I was first learning how to code in the late 90s.
gneissguise 7 hours ago [-]
Oh yes, I have similar memories mixing asm and pascal together in Turbo Pascal to get interesting results!!
TrackerFF 5 hours ago [-]
The vector one is still alive and kicking. I've lost count how many current websites have that one on their landing page.
gneissguise 5 hours ago [-]
Yep it has totally made a resurgence with the background animation trend showing up in modern web UI.. except without the pixelated appearance and the green phosphor color.
gneissguise 5 hours ago [-]
If anyone is interested in doing algorithmic art while learning Clojure/ClojureScript then I highly recommend checking out the Quil library:
Just lean into the declarative lisp style and immutable data and make some beautiful art to share with others!
TuringNYC 3 hours ago [-]
Great nostalgia! You should also do the multi-colored rolling pipes, that was a staple!
layer8 36 minutes ago [-]
Already in the 80s, though.
rollulus 6 hours ago [-]
Good job. Looks authentic. But you forgot the rotozoom!
gneissguise 6 hours ago [-]
D'oh! Now that I'm in my mid 40s there's so much I've forgotten!
Thank you for the reminder
p1dda 5 hours ago [-]
Thanks! So great to watch these demos in 80-90's of the wizards creating these spectacular visuals.
gneissguise 5 hours ago [-]
Heck yeah you're welcome! It was a blast to put together
rareitem 7 hours ago [-]
Amazing, I was not born in that era but it makes me feel nostalgic too. How does on go on to learn to make animations like this?
gneissguise 7 hours ago [-]
Start off small, you gotta know your underlying API. For this demo it's JavaScript and the HTML5 canvas API (which is MUCH easier to learn than the languages of the 90s except for BASIC)
From there, you'll need a good understanding of loops, control flow, data structures like arrays to store the pixels, lines, shapes, and colors, wiping and redrawing the screen between "ticks" (a single pass of the main loop), and refresh timing to control the speed of the animations.
On a side note there's actually a refresh bug in my plasma demo I just noticed a moment ago... if you leave it open for too long on plasma it starts redrawing faster and faster until it looks like glitch-art!
stuaxo 6 hours ago [-]
Wonderful. Did you simulate through weird bitplains of VGA?
I found them hard to get my head round, still do.
gneissguise 5 hours ago [-]
Excellent question. This is more a modern chunky pixel framebuffer, not planar.
The spirit of the project, however, was to emulate the tricks that bitplanes made famous. The plasma and flag effects, for example, don't move any pixels; they just cycle the color palette's offset against a static pattern, which is a direct software simulation of that classic Amiga hardware hack.
stuaxo 4 hours ago [-]
Would like to see an old school vowel landscape.
lofaszvanitt 1 hours ago [-]
Second Reality waaa
layer8 37 minutes ago [-]
Has anyone ported it to JS yet?
7 hours ago [-]
abrookewood 7 hours ago [-]
Thank you - takes me back :)
gneissguise 7 hours ago [-]
You're welcome, it's my pleasure to share with ya!
QuiCasseRien 7 hours ago [-]
thank for make me back to 25 years ago with the star windows screensaver ^^
gneissguise 7 hours ago [-]
Anytime! I was also trying to add a Star Wars like hyperspace feature to the starfield demo but I failed miserably at implementing it!
pengaru 8 hours ago [-]
Neat, but beyond the 320x240 resolution I don't have the impression you're really emulating anything uniquely mode-X here (not that it would really make sense to do so)
gneissguise 7 hours ago [-]
You would be correct, it's more the appearance of the demoscene than the actual underlying mechanism.
A true in browser mode-x API would take me much longer than a weekend to implement.. But it does sound like a neat challenge!
guiambros 9 hours ago [-]
wow, well done! Pretty solid implementation, genuinely Future Crew-worthy :)
gneissguise 7 hours ago [-]
w00t! Greetz!!!1
bhouston 1 hours ago [-]
good job!
leptons 6 hours ago [-]
You should check out dwitter.net if you have not already.
gneissguise 5 hours ago [-]
Just took a look, very cool algorithmic art! Thanks for sharing!
KingOfCoders 8 hours ago [-]
More like 80s Amiga effects :-)
gneissguise 7 hours ago [-]
I could see that too.
I didn't own an Amiga but a friend of mine from school did. We had a blast playing Gobliiins!
KingOfCoders 28 minutes ago [-]
I think starfield was the first effect I wrote as a demo coder in the 80s. Then a Copper wobbling picture I think (Like the Star frontier intro) - or copper bars, then a sin scroller. Nearly joined TRSA because one coder in our group was a genius (not me!) but deal fell through :-(
If you're interested, I also implemented a few effects like lens[0] and Jare's fire[1] along with some other amusements[2]
[0] https://toys.luismedel.com/lens/index.html
[1] https://toys.luismedel.com/fire/index.html
[2] https://github.com/luismedel/js-toys
320x240 (square pixels) with 256 colours
Full details:
https://en.wikipedia.org/wiki/Mode_X
I was so into this in the mid-90s. I tried some assembly but I wish I would have been better at the maths part back then.
https://www.pouet.net/prod.php?which=53816
Off topic: we always referred to mode-x variants as MCGA, TIL that's more of a colloquial term than a technically accurate one [1]
[1]: https://en.m.wikipedia.org/wiki/Multi-Color_Graphics_Array
I’ve been thinking a lot about demoscene in a Vibecoding era. Demoscene was often very close to the metal; Vibecoding is often completely abstracted from it.
To explore this tension, I’m cohosting an 8bit game design workshop (pico8) in Amsterdam this summer. Just for fun.
Working with intense constraints can bring a lot of creativity. I really want to see how AI affects the workshop vibe.
>(pico8)
But PICO-8 with its integrated tools and Lua programming is super high level, pretty far removed from "8bit". It's only 8 bit in aesthetics, entirely artificial and forced. Why not write games for the 2600, the C64 or the NES to experience real constraints of an actual 8 bit platform, the actual "metal."
I never quite completed it, but I managed a emulator/assembler IDE in the browser. Making my own assembler let me play around with some ideas for macros.
It could even load programs from gists.
https://k8.fingswotidun.com/static/ide/?gist=ad96329670965dc...
Reflecting on it now, I think one feature that could help a assembler on devices like this is the ability to inline compile assignment expressions that use values of only one type. It would be easy enough to emit a stream of instructions for
or even using registers as expression values.The result would usually be what an assembler writer would write themselves.
I think a macro assembler that did that would ease a lot of the tedium of assembly while maintaining the near absolute control over memory use and IO that you need for low level coding.
Demos aren't just pretty visuals. Their entire purpose is to showcase the skills of the programmer in accomplishing something remarkable within a constrained environment, or within artificially imposed constraints. Using exorbitant amounts of resources to run a machine learning model to generate a muddy mixture of existing demos goes completely against this spirit. The idea of the two together is, frankly, repulsive.
This workshop is actually a forerunner to a workshop on demos with quantum computers, where the constraints are very real and creative participation is very lacking.
I just looked up the 13h interrupt and you are absolutely right!
https://landofquil.clojureverse.org/
http://quil.info/
https://github.com/quil/quil
Just lean into the declarative lisp style and immutable data and make some beautiful art to share with others!
Thank you for the reminder
https://www.freecodecamp.org/news/drawing-on-a-canvas-elemen...
From there, you'll need a good understanding of loops, control flow, data structures like arrays to store the pixels, lines, shapes, and colors, wiping and redrawing the screen between "ticks" (a single pass of the main loop), and refresh timing to control the speed of the animations.
On a side note there's actually a refresh bug in my plasma demo I just noticed a moment ago... if you leave it open for too long on plasma it starts redrawing faster and faster until it looks like glitch-art!
I found them hard to get my head round, still do.
The spirit of the project, however, was to emulate the tricks that bitplanes made famous. The plasma and flag effects, for example, don't move any pixels; they just cycle the color palette's offset against a static pattern, which is a direct software simulation of that classic Amiga hardware hack.
A true in browser mode-x API would take me much longer than a weekend to implement.. But it does sound like a neat challenge!
I didn't own an Amiga but a friend of mine from school did. We had a blast playing Gobliiins!