Re: Windows Assembly

On Fri, 16 Sep 2005 09:54:48 -0400, f0dder <f0dder_nospam@xxxxxxxxxxxxxxxx> wrote:

Assuming you send stuff that can be batched.

Yeah, so I guess that wouldn't work for UDP packets. (and of course my idea has UDP packets going through several context switches, application => udp layer => IP layer => network driver)

Of course it can be allowed per-process if you set up a TSS
and iopbm for each process, but... humm.


You can also run the user-space driver as ring 0.

Video memory *is* bad and slow - and readback is even slower than writing

Yes, I think my reads were 50 times slower than normal memory, compared to the writes being 20 times slower.

When blitting a sysmem buffer to vidmem, you'll probably want to use
the uncached instructions added with... was it SSE or SSE2?

I don't know about that... It's possible that one day (if that day hasn't already come) that there will be a 64-bit bus connecting the CPU to the video card, in which case you want a little bit of caching in there, so that the CPU can combine two 32-bit writes into a single 64-bit write.

The movsb instruction is optimized that way, you may have said bytes, but if certain conditions are met the CPU does it dwords at a time anyway.

It might be possible to speed this up by adding some "line-changed" or even "tile-changed" logic? 

The kernel does that with framebuffer mode.

Softer, however, uses a real text mode for text mode. (Yep, those eight pixel wide fonts are standard VGA.) Real text mode is a lot faster than using a graphics mode, and so rather than try to optimize things that way, it just writes directly to video memory without using any sort of buffer (except for one to remember what's on the screen when you switch to another console).

Now the kernel's text mode is way faster than Softer's. This is because when the kernel scrolls the screen, rather than move the text, it just changes which line the video card starts drawing from. This makes it go a lot faster since it doesn't have to move anything in video memory.

I remember when I first started using Linux, when booting, the kernel would print out it's 40 or so lines of text before the init scripts took over, and they'd just scroll up the screen instantly, it was quite impressive compared to how quicky DOS is able to scroll things. (plus to think that it was actually doing things between printing all of those lines) Unfortunatly, now Linux takes a bit longer to do all of those things when it starts up, so it's not nearly as impressive anymore. However, if you write a console program that writes 10,000 lines of text, you can run it in a text console in just a second or two, but switch over to framebuffer mode and you'll be sitting there waiting on it for a while.

Softer used to do it's scrolling that way the kernel does in text mode, but eventually I decided I wanted other things that didn't work well with that, so I took that functionality out, but then I also took out those other things, so I suppose it could be put back in. It would be nice. It just looks so wrong to see text scrolling as slowly as it does in Softer.

There is the vm86 system call.  The problem is that the man page for
it only mentions that it exists and that it takes a couple of
structures as parameters, it doesn't detail how to use it.

:-)

I finally got this figured out. (Thus I guess I'm done with Windows now, sure didn't last long.) Here's a copy of what I posted to the Linux-Assembly mailing list, in case someone cares:

http://marc.theaimsgroup.com/?l=linux-assembly&m=112685214217165&w=2

That's so much more informative than that *** man page.
.