Platform for 256bytes intro
category: offtopic [glöplog]
which one u prefer? why?
MS-DOS. Just because.
any :)
It really depends on what your goal is.
i find linux (framebuffer, oss) somewhat underexplored.
w23: Isn't Linux pretty hindered by ELF? DOS has a much smaller executeable format.
The ELF file can be ripped down to some 52(32-bit arch)/64(64-bit arch)? bytes and the rest is for code. SDL+the rest would eat up pretty much all the leftover <200 bytes or so though.. BUT there are devices which give(to my undestanding!) direct framebuffer access via /dev/fb0, such as gp32 and gp2x. On those, perhaps 256 byte intros would not be "impossible". :)
Oh well.. or just write a kernel module intro to get the direct fb access... :(
Oh well.. or just write a kernel module intro to get the direct fb access... :(
Someone ought to compile a kernel with easy access to the framebuffer and using a simpler executable format than ELF.
The distro stali actually considered using something other than ELF.
The distro stali actually considered using something other than ELF.
well, seems like using library(SDL+) doesn't make any sence..
Platform without floating point, otherwise it is cheating!
(more seriously, read xeron's answer and have fun!)
(more seriously, read xeron's answer and have fun!)
I am mainly loving Ms-dos 256b intros atm even if there are better platforms for size optimization I think. In X86 you have mul/div for free, FPU, easy Mode13h videomode and all that stuff. However there are some things that are more appealing in oldschool 8bit platforms.
If CPC smallest filesize would be less than 1kb then I would consider it too. I am more familiar with z80 and would prefer it for size coding, while my x86 turns out messy and unoptimized in size cause regs are too few, segment offset to write memory takes two regs, sizes of most commands are more than one byte, etc.
I don't know how good (or not) is size coding for C64. It has 256b smallest filesize, however most memory commands would take 3 bytes I guess. The 256b on C64 must take quite an effort. I should try it oneday.
I think z80 would be ideal, if you load your addresses in 16bit regs beforhand and regs are enough for what you want to do, you could have inner loops with a lot of 1 byte sized opcodes for reading/writting mem, arithmetic between regs, etc. I think Zx Spectrum file size can be less than 256b? Should try that too..
If CPC smallest filesize would be less than 1kb then I would consider it too. I am more familiar with z80 and would prefer it for size coding, while my x86 turns out messy and unoptimized in size cause regs are too few, segment offset to write memory takes two regs, sizes of most commands are more than one byte, etc.
I don't know how good (or not) is size coding for C64. It has 256b smallest filesize, however most memory commands would take 3 bytes I guess. The 256b on C64 must take quite an effort. I should try it oneday.
I think z80 would be ideal, if you load your addresses in 16bit regs beforhand and regs are enough for what you want to do, you could have inner loops with a lot of 1 byte sized opcodes for reading/writting mem, arithmetic between regs, etc. I think Zx Spectrum file size can be less than 256b? Should try that too..
well, why 256b intro compo is not so popular?
too painhardcoreinyourass considering the final result?
@knl what do you mean?
Hard work, not so cool results :)
On some computers with 1K people manage to get music or multiple effects in, which allows for a much more impressive result.
Anyway, feel free to try on any platform. Each of them has its own set of constraints.
@Optimus: do your 256b on CPC with ùCPM launcher, this way there's no need for a file header :)
On some computers with 1K people manage to get music or multiple effects in, which allows for a much more impressive result.
Anyway, feel free to try on any platform. Each of them has its own set of constraints.
@Optimus: do your 256b on CPC with ùCPM launcher, this way there's no need for a file header :)
@paldepind
ELF can be ripped down to 45 bytes and still make sense (teh linkage: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html)
@r-A
no libraries are possible -- you need a lot of friends (like PT_INTERP section with some lengthy string) to make it happen, so file size instantly goes up to ~300 bytes just for dynamic linking support.
but you actually need no libraries at all, as you have /dev/fb%d. it is obviously possible to access it with pure syscalls (open, ioctl and all that), and there you go, you have spent around 100 bytes for a pointer to some videomemory!
there obviously are issues, like
(a) setup does take a lot of space, so it'll feel more like 128b intro.
(b) you're pretty much stuck with whatever resolution kernel set at startup (and it is not pretty to query it in runtime when you have only some ~150 bytes left after fb setup);
(c) big resolutions are SLOW
(d) user'll need to switch to console to watch the intro
(e) there are no size-efficient way to check for ESC (^C to the rescue!)
...
you also can write to /dev/oss for sound output, but it's a bitch to set oss up on contemporary systems.
so, it is totally possible to make a pure 256b intro for linux.
nobody seems to care, though.
ELF can be ripped down to 45 bytes and still make sense (teh linkage: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html)
@r-A
no libraries are possible -- you need a lot of friends (like PT_INTERP section with some lengthy string) to make it happen, so file size instantly goes up to ~300 bytes just for dynamic linking support.
but you actually need no libraries at all, as you have /dev/fb%d. it is obviously possible to access it with pure syscalls (open, ioctl and all that), and there you go, you have spent around 100 bytes for a pointer to some videomemory!
there obviously are issues, like
(a) setup does take a lot of space, so it'll feel more like 128b intro.
(b) you're pretty much stuck with whatever resolution kernel set at startup (and it is not pretty to query it in runtime when you have only some ~150 bytes left after fb setup);
(c) big resolutions are SLOW
(d) user'll need to switch to console to watch the intro
(e) there are no size-efficient way to check for ESC (^C to the rescue!)
...
you also can write to /dev/oss for sound output, but it's a bitch to set oss up on contemporary systems.
so, it is totally possible to make a pure 256b intro for linux.
nobody seems to care, though.
Pardon my ignorance but.. Is /dev/fb%d device accessible on every linux platform(PC, mind you)? Why would one need to switch to console?
To me it seems that IF one is at the mercy of "whatever resolution kernel set at startup", then it is more or less in vain to even attempt anything of that kind; compatibility issues will be so vast that even though the prod works for you today, it most probably wont work for others years afterwards.
Somehow I am geared towards viznut's approach of using raw kernel syscalls to create socket and communicate with X to gain a window + framebuffer access and work that way up. His experimental stub from over a decade ago was some 300 bytes if I remember correctly... Perhaps the man himself could shed some light on this? Has there been any kind of similar experiments using the same approach by anyone out there? Probably such approach won't be compact enough for 256b prods but... Never say never! Oh and.. Since /dev/dsp is directly accessible with open and write, I would suspect the traditional 8-bit 8 KHz PCM(?) should become a "standard" for extremely tiny Linux intros.
There's very much competely unexplored "land" in Linux extreme sizecoding that I am fairly certain there ARE ways to make things work for sub 256b prods... Someone just has to be the first one and the rest will follow. Until then, we can only speculate.
Though, even still, in the vein of this topic Linux will probably never be the most inviting 256b platform out there, even if we disregard the need for libraries. IBNIZ seems interesting but at least for me it seems WAY too experimental, using non-deterministic methodologies to find whatever the creator wishes to express... Although, I am admittedly a newcomer to the whole deal with it(and demoscene itself, when it comes to creating something) that I can only wish to be nothing but wrong in this regard. :)
To me it seems that IF one is at the mercy of "whatever resolution kernel set at startup", then it is more or less in vain to even attempt anything of that kind; compatibility issues will be so vast that even though the prod works for you today, it most probably wont work for others years afterwards.
Somehow I am geared towards viznut's approach of using raw kernel syscalls to create socket and communicate with X to gain a window + framebuffer access and work that way up. His experimental stub from over a decade ago was some 300 bytes if I remember correctly... Perhaps the man himself could shed some light on this? Has there been any kind of similar experiments using the same approach by anyone out there? Probably such approach won't be compact enough for 256b prods but... Never say never! Oh and.. Since /dev/dsp is directly accessible with open and write, I would suspect the traditional 8-bit 8 KHz PCM(?) should become a "standard" for extremely tiny Linux intros.
There's very much competely unexplored "land" in Linux extreme sizecoding that I am fairly certain there ARE ways to make things work for sub 256b prods... Someone just has to be the first one and the rest will follow. Until then, we can only speculate.
Though, even still, in the vein of this topic Linux will probably never be the most inviting 256b platform out there, even if we disregard the need for libraries. IBNIZ seems interesting but at least for me it seems WAY too experimental, using non-deterministic methodologies to find whatever the creator wishes to express... Although, I am admittedly a newcomer to the whole deal with it(and demoscene itself, when it comes to creating something) that I can only wish to be nothing but wrong in this regard. :)
You need to switch to console because otherwise X11 will get in your way. /dev/fb* tends to be available nowadays because of KMS, but before KMS became common, you had to set up a framebuffer console yourself for /dev/fb* to exist.
The resolution problem with /dev/fb* unfortunately doesn't seem to be easily solvable.
You can just use /dev/dsp and alsa users can run your demo with aoss.
The resolution problem with /dev/fb* unfortunately doesn't seem to be easily solvable.
You can just use /dev/dsp and alsa users can run your demo with aoss.
Quote:
Hard work, not so cool results :)
That's what I meant.
r-A: it's wonderfully useful if you adapt to the current screenmode, can read the current width/height/depth from somewhere ;)
On Amiga it's about as costly to open a screen as to get the current one or hardware-start your own, haven't looked but around 80b inc file header maybe. And 68k only has only word/longword instructions, so it might be the worst 256b platform except for "ARM without Thumb".
8080-derivate CPUs like Z80, agree they would be pretty darn good for 256b, of course not as much for free as DOS, but still Speccy etc has screenbuffers in fixed places and no direct "OS" to think of (well, turn off) is always a plus in this context :)
On Amiga it's about as costly to open a screen as to get the current one or hardware-start your own, haven't looked but around 80b inc file header maybe. And 68k only has only word/longword instructions, so it might be the worst 256b platform except for "ARM without Thumb".
8080-derivate CPUs like Z80, agree they would be pretty darn good for 256b, of course not as much for free as DOS, but still Speccy etc has screenbuffers in fixed places and no direct "OS" to think of (well, turn off) is always a plus in this context :)
The 6809 also seems rather good at keeping the size small. And using a Vectrex avoids all the framebuffer problems, right ?
@r-A
I've made this linux-256b proof-of-concept a couple of months ago (nothing fancy, though, I suck at making nice things; also, sorry for self-linking): http://www.pouet.net/prod.php?which=57976
@FreeFull
The solution for multiple resolutions problem that I could come up with is simple: provide as many different executables for every common resolution as you have patience for. I've even thought about making a shell-script that would check current resolution and make a binary for it, but in the end I turned out to be too lazy to implement it. And then there are different color depths (i've seen 16, 24 unaligned, 24 aligned), and supporting all of them in one tiny binary IS painful.
Also, aoss won't work because it (as far as I know) relies on LD_PRELOAD'ing libc functions, which won't work on binaries that don't dynamic-link with anything and use bare syscalls. So it is a must to have proper kernel-space /dev/dsp device. http://osspd.sourceforge.net/ works relatively well.
As for other compatibility issues, I think there aren't any more ones, as framebuffer api is considered being pretty stable. So as log as you don't do any elf-header-overlap-trickery, you're safe.
I've made this linux-256b proof-of-concept a couple of months ago (nothing fancy, though, I suck at making nice things; also, sorry for self-linking): http://www.pouet.net/prod.php?which=57976
@FreeFull
The solution for multiple resolutions problem that I could come up with is simple: provide as many different executables for every common resolution as you have patience for. I've even thought about making a shell-script that would check current resolution and make a binary for it, but in the end I turned out to be too lazy to implement it. And then there are different color depths (i've seen 16, 24 unaligned, 24 aligned), and supporting all of them in one tiny binary IS painful.
Also, aoss won't work because it (as far as I know) relies on LD_PRELOAD'ing libc functions, which won't work on binaries that don't dynamic-link with anything and use bare syscalls. So it is a must to have proper kernel-space /dev/dsp device. http://osspd.sourceforge.net/ works relatively well.
As for other compatibility issues, I think there aren't any more ones, as framebuffer api is considered being pretty stable. So as log as you don't do any elf-header-overlap-trickery, you're safe.
@r-A
As for viznut's 300-bytes direct talk to X11, I find it interesting, but it is more 1k-4k stuff, rather than 256b. I also wonder whether it'll work properly with Xauthority. I think I need to get more familiar with raw X11 proto.
As for viznut's 300-bytes direct talk to X11, I find it interesting, but it is more 1k-4k stuff, rather than 256b. I also wonder whether it'll work properly with Xauthority. I think I need to get more familiar with raw X11 proto.
http://pouet.net/prod.php?which=58364