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.
AFAIK, MCGA has nothing to do with Mode-X. Mode-X was 320x240, and was achieved by manipulating VGA settings. MCGA supported Mode 13h, but I see no evidence that it could be manipulated to output 320x240 or that it supported planar memory, which is generally considered synonymous with Mode-X. In fact, from what I can tell, MCGA didn't have enough memory to support planar mode.
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.
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 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.
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.
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.
thanks! my contact info is in my bio. Drop me a line -- the website might be up later today... or next week haha. But several friends flying into Amsterdam to make this a reality.
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.
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.
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.
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).
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.
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!
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.
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)
You're the second person to mention dwitter.net, now I feel like I have to... Got a busy week coming up but when I have more downtime I'll join and share!
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 :-(
Oh man that would have been so cool! Sorry that it fell through..
I remember making infinite ASCII mazes by alternating forward and backward slashes in the late 80s early 90s. That would have been the grade school computer lab days for me and I didn't have the to do anything better so it was mazes or controlling the turtle in LOGO
I love how I never get any accolades for my other engineering work, but this demoscene recreation was a smash hit! Not complaining at all, I'll take any recognition I can get.
I've been recovering from major burnout earlier this year, and this has lifted my spirits exponentially.
I appreciate your comment and all the kind words others have shared.
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.
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://www.pouet.net/prod.php?which=53816
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.
I can offer what little I know to help.
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!
I remember making infinite ASCII mazes by alternating forward and backward slashes in the late 80s early 90s. That would have been the grade school computer lab days for me and I didn't have the to do anything better so it was mazes or controlling the turtle in LOGO
I love how I never get any accolades for my other engineering work, but this demoscene recreation was a smash hit! Not complaining at all, I'll take any recognition I can get.
I've been recovering from major burnout earlier this year, and this has lifted my spirits exponentially.
I appreciate your comment and all the kind words others have shared.
https://github.com/bhouston/2DBumpMapDemo1996
https://github.com/bhouston/3DMaskDemo1997