pouët.net

I think it would need to intercept a lot more. A lot of intros do nasty stuff like just use uninitialized parts of memory, read from the timer port (40h) or the keyboard port (60h), and then there's the VGA/palette stuff to worry about. Is all that legal under Win7?

@ara what you are talking about is just what NTVDM does...

there is a lot more stuff other than 0a000h memory read/write to intercept :
- interrupts (and re-implement some DOS ones)
- port read/write (as preacher said)
- all memory read/writes should be re-located, special ones that are used for hardware access should be emulated in some way

i think its harder than what you think. maybe if you limit yourself to the most basic things 256b use it could be possible without too much pain (only int 10h, keyb esc support and video palette). That's 95% of the intros.

also you're out of luck on 64-bit OSes. x86 processors don't support virtual 8086 mode while they're running in long (64-bit) mode.

but if the executable itself is marked as 32bit...?

i mean i had the same suggestion on irc a few days ago, it didn't seem that bad of an idea to me but the reason i didnt do it is because i have relatively little experience with realtime code-reassambling - it did, however, seem plausible to me.

Isn't that true for all platforms though - you either need hardware, or emulation. (And you don't even need a bare 486, my XP machines run 256b intros just fine.)

what it actually needs to get a 256b working? i still have a old rig here without any os. might boot from my mp3 player and put some tools on it. would that do? not that i want to use that old loud rig. :D

even if the executable is 32 bits, it's still running on a 64-bit system in long mode. 32-bit code on a 64-bit OS runs in compatibility mode, but the actual kernel and drivers are in 64-bit mode; the OS never drops out of it.

and while you're in long mode, you can't use virtual 8086 or real mode. at all. (nor can you run 16-bit protected mode code, i believe).

so you really have to do either interpret or JIT to make 16-bit real/protected mode work on a 64-bit host OS. short of rebooting to a 32-bit OS, that's your only option.

I was musing about something along:
- The player (a 32 bits app eventually running on a 64 bits OS, as Gargaj said) disassembles the intro
- loads the .com as a binary chunk somewhere in its executable memory space
- patches the port read/writes, and the mode 13h setup. I don't expect a tiny intro to do much else. Most of them probably don't even use memory, merely computing a formula per pixel
- patching might mean injecting jumps in place of the original opcodes. Hopefully the smallest opcode to patch still allows for a short jump
- don't really know what to do with the 0a000h access... :/ All the solutions I can think of involve an interpreter, while I wish we could run the intro natively. Unless the OS debugging APIs allow for a fast way to control/intercept memory accesses to the fake video mem

...and the above could just be naive, sorry about that.

Easy (painless) way to get a bootable DOS Stick:
Download:
http://www.chip.de/downloads/USB-DOS_36233249.html
&
http://www.chip.de/downloads/HP-USB-Disk-Storage-Format-Tool_23418669.html
(sorry creepy german page)

Then use the HP-USB-Storage Format Tool to create a DOS STICK from the "USB DOS" thing. Select FAT32 & click the self explaining obvious other things.

@las: an easy way to find MSdos floppy image and prepare grub

I once had some ultra tiny thing that ran on Linux and ran 256b intros through the vm86 syscall, without any real hardware or BIOS/DOS. Since many tiny intros don't do vsync anyway, that thing simply dumped the vm's video memory periodically onto the screen. That worked surprisingly well, I liked showing off that thing using Tube and other at that time recent intros.

I got relatively far with that but stopped working on it when it grew larger and started becoming also a BIOS/DOS emulation (that is, DosBox...) in order to run more and more intros correctly. Especially older intros tend to do more obscure stuff with the hardware and to some extent also with DOS&BIOS than just setting mode 13h and writing stuff to 0xa000.

Back to the video memory access: so I simply dumped the emulated video memory periodically to some SDL window, and that worked great. At some point I think I even had some vertical retrace flag implemented, which was controlled by the part that periodically dumped the video memory, while the vm was happily running in its own thread. Now replace the vm86 syscall running in an own thread with JITed code, and there you go. Or maybe not.

las, when your tiny intro are ready?)

I'd give it a thumb up even without watching :D

@Android Barker: it's done (basically - maybe I'll add some stuff in case I can kill some more bytes). 100% sphere-tracing - no faking. Fucking slow (~5 fps on real DOS on a current machine). Not sure if I will ever release it (And if - then in a 256b compo). But I'm pretty happy with it.

Why wait ? Give yourself a day or two to polish it and release it. By the time comes the next 256b compo, you'll have learned more tricks and will make an even better prod.

I've made my decision.

indeed, why? i have some 256b intros)

Where are you releasing then, las?

he just wont release ;)
his decision was not to publish it at all i guess.

after reading this thread to this point i exactly know why i never tried to do it myself ;) theres that hole_of_knowledge concerning PCs from the beginning until 2005, when i got my first pc ever ;) also theres that hole of having had not even had power, not to think of computers needing power, of about 6 years in my life ;)
i always knew it cant be that easy to just dive into tiny-intro-coding...just having some 68k-asm-background back from 1991-1998 via amiga ;) most of what ryg stated i cant even follow ;) maybe i should completely retire as a coder after this thread ! ;)

sth about yours (xTr1m) statement made me puzzled tho:
it got stated (and is what i thought of tinytros and still think) that under WinXP intros run way faster than under DosBox...and thats ofcoz due to higher MHz going into the thousands getting used to run these intros under XP...which aint the case in Emulators for C64/Amiga/ST/you_name_em (unless you use Warp-Mode (VICE) or sth alike). so this is basically cheating to me, if its like that! if its like 1fps in DosBox (emulating some P2 or whatever cycle-exact unless you WARP it) and runs in 30-xx fps (fluid) under XP its obviously like that to me, and cant count as a real DOS-prod, as its just a slideshow then on original hardware!

i may have got sth wrong here, but as said, i feel like a very weak coder after having read this thread.

about a vm to be able to run tinytros via 64Bit-OSs, go for it, i´d love it using win7 only here by now. Most obviously ryg or BeRo are made for this task, but then again there should be a Warning alike "be aware it could be faster &| a_different_experience than would be on original hardware". ;)

oops, lots of text, me sorry! but maybe this way i can get enlightened a bit more, stupid as i am considering PC-Architecture at/via the dark times of my life (not even a blackScreen, just NoScreen!) ;)

hArDy: Just fuck that hole_of_knowledge ;)

nah, i wont fuck magic ;p

^^

next some1 will throw() the argument of "dos is no architecture, theres no masterplan on what architecture it should get used at all" -> forget about it, i see DOSprods as 386/486-stuff. and thats where i am wrong, correct?! ;)

used on*

I release things when I want to release them - and not when you want me to release them.
And I prefer to release at a party with a proper competition.
Just to make things crystal clear: I don't know whether I'll release anything and where - so that's up to me. No need to speculate.

Also: I don't give a flying fuck about this "uhh it's not the real thing - it's cheating" or whatever "discussion". That thing was about sizecoding - not performance.
And as long it runs with a non emulated DOS on a current machine - you have to deal with the fact that it is a totally valid demoscene related coding platform.