flat assembler
Message board for the users of flat assembler.
Index
> DOS > YAMFAT - yet another my first assembly thread |
Author |
|
DOS386 22 Mar 2007, 07:25
Quote: to implement double buffering example Looks rather like parallel buffering ... Code:
backbuffer equ 09000h
I fail to see a memory allocation Code:
swapBuffers:
I see an attempt to copy, not swap Code: mov cx,64000 rep movsd ; ds:si -> es:di, find a faster way(unroll loop,fpu?) 64000*4 bytes Faster needed ? No idea Is it slow at all ? Code: mov cx,64000 rep stosb ; al -> es:di , es=backbuffer Correct, but slow _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
22 Mar 2007, 07:25 |
|
dvlfrnd 22 Mar 2007, 08:26
yeah it is copying,not swapping
and i just noticed im doing 4 times extra work there with mov cx,64000 rep movsd thanks :0) here's what i was trying to do: the idea was to write pixels on somewhere other than the video memory,A000h, then during vblank,copy everything from that place to video memory.so that nothing shears or tears. if i'm not wrong, a com file is limited to use 64k,so there's no way i can allocate enough memory. in one of the posts,i saw a nice program that utilizes 09000h,i thought it's ok to use it as a base for backbuffer. since my goal was simply about copying 64k from one place to another during vblank,speed matters. at first i tried a loop,incremented the offset and copied from back to front. it flickered a lot,(but less than directly writing to video mem) then i unrolled the loop,in theory it should've been better,but i didn't notice the difference. at last,i went ahead,read the manual,and discovered movsN. at first i tried movsb,still flickered a little,then finally movsd gave the smoothest result. so i said,if a beginner can do this much,i wonder what tricks experienced people have in their pockets thanks |
|||
22 Mar 2007, 08:26 |
|
DOS386 25 Mar 2007, 11:16
Quote: if i'm not wrong, a com file is limited to use 64k,so there's no way i can allocate enough memory. The size of the .COM file is limited to 64 KB, but (I hope ) you can allocate more ... if not just make an .EXE instead of .COM Quote: in one of the posts,i saw a nice program that utilizes 09000h,i thought it's ok to use it as a base for backbuffer DOS program ? Post link _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
25 Mar 2007, 11:16 |
|
dvlfrnd 25 Mar 2007, 15:02
i believe that program was from:
http://home.swipnet.se/~w-44673/ i looked at what i have from that site,but couldn't find which one :/ i think the code i sent above does its job.it becomes obvious if you write different patterns to the screen each time,instead of filling the whole screen with one color. still not sure if it's safe to use 09000h though. |
|||
25 Mar 2007, 15:02 |
|
Goplat 25 Mar 2007, 20:26
If you have EMM386 set up to make upper memory available to DOS, there will be an MCB at segment 9FFF to tell DOS not to use the A000-C7FF (video RAM and ROM) region. So it's not safe to use the last 16 bytes of segment 9000.
It's probably okay in this case since only 64000 bytes are needed for a 320x200 image, but if you need a full 65536 bytes, you could use 8FFF instead. |
|||
25 Mar 2007, 20:26 |
|
Hayden 26 Mar 2007, 02:42
A suffisticated graphics lib would time the WaitRetrace period for a few seconds useing a high resolution timer to measure the time inbetween retraces then use that sampleing rate to time the retrace period instead of useing port i/o. this method gets alot closer to ~70 fps than ~35 fps
_________________ New User.. Hayden McKay. |
|||
26 Mar 2007, 02:42 |
|
Hayden 26 Mar 2007, 02:56
What about porting it to MMX. I think its safe to assume that most CPU's have MMX theese days. Even a P-166.
|
|||
26 Mar 2007, 02:56 |
|
dvlfrnd 26 Mar 2007, 05:19
Goplat:
thanks for the hint,i will keep that in mind. Hayden: is it easy to find the cpu clock rate? if so: Code: *method to return clock rate *use the timer and clock rate,figure out how many cycles it takes for a vblank *loop for that many cycles is this the method? |
|||
26 Mar 2007, 05:19 |
|
Hayden 26 Mar 2007, 06:51
Here is a good article on programming the system timers to measure time intervals ftp://garbo.uwasa.fi/pc/programming/pctim003.zip
Article - Measuring short time intervals I have not done this before but I've read several articles a few years ago that claim's that it works yes... figure out the period until a vblank ( with interrupts dissabled) The method to measure the period is an averaged combination of system timer compared to RTSC intruction so that when timing the retrace you can wait in a RTSC loop instead of a port I/O loop ( with interrupts dissabled ) You also need a fixed point in time ( a time when a retrace occurd ) to use as base for timming intervals ps. I'm tempted to crack open my old achived articles and give it ago ( if I can find them ) |
|||
26 Mar 2007, 06:51 |
|
Hayden 26 Mar 2007, 07:15
Code: ; assuming esi, edi hold the buffer's and ecx has been set move one paragraph at a time. ; if you use a far call to blt the cache lines will be cleared. align 16 ; ensure that the whole routine read into cache blt: mov eax, [ds:esi + 00] ; - v pipe mov ebx, [ds:esi + 04] ; - u pipe mov ecx, [ds:esi + 08] ; - v pipe mov edx, [ds:esi + 12] ; - u pipe mov [ds:edi + 00], eax mov [ds:edi + 04], ebx mov [ds:edi + 08], ecx mov [ds:edi + 12], edx add esi, 16 add edi, 16 nop ; not to sure how much padding needed here loop blt ; loop should be at the end of a 16 byte boundry ret ; 4 or 8 would do ok though ; if you use the MMX registers you could move 4 paragraphs at a time. _________________ New User.. Hayden McKay. |
|||
26 Mar 2007, 07:15 |
|
DOS386 26 Mar 2007, 08:06
Quote: I think its safe to assume And some people assume SSE as well Code: BLA.EXE crashed at sdjhsjfhsd:sdjhdjf with illegal instruction eax=dskfjdlf 84843 34587894 00000 bla bla bla bla ... It's NOT safe, it's a criminal bug. Correct way: 1. Test for >= 80386 2. If OK, test for availability of CPUID 3. If OK, execute CPUID ask for MMX 4. If OK, use MMX Quote: that most CPU's have MMX theese days True, but DOS code should work down to 8086 or 80386 at least. MMX maybe works from RM also, but I would NOT use it. MMX instructions are rather useful in DPMI code. Also, MOVSD based move possibly would run faster from DPMI than from RM, requiring only 80386, rather than MMX. Quote: suffisticated graphics lib would time the WaitRetrace period for a few seconds useing a high resolution timer to measure Don't get it. What is the benefit ?? Quote: good article on programming the system timers YES. Some info about double buffering also. _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
26 Mar 2007, 08:06 |
|
rugxulo 29 Mar 2007, 02:37
Hayden wrote: What about porting it to MMX. I think its safe to assume that most CPU's have MMX theese days. Even a P-166. Not my P166. |
|||
29 Mar 2007, 02:37 |
|
Hayden 30 Mar 2007, 00:28
Quote:
Why? That would be pointless. All DOS programs that I own have some sort of minimum requirement, some require 286, others 486 and so on |
|||
30 Mar 2007, 00:28 |
|
rugxulo 31 Mar 2007, 03:30
Hayden, check out PocketDOS or the 8088 Corruption demo or JetPack ("Jetpack runs great on an 8086! Take that, Quake.") or Paul S. Reid's Invaders.
Requirements are all in the programmer's head. (Also see http://www.256b.com and Hugi Compo. Or is optimizing for size useless too??) |
|||
31 Mar 2007, 03:30 |
|
m 01 Apr 2007, 08:13
Nice blinking colors !
Should'nt I expect more from it ? |
|||
01 Apr 2007, 08:13 |
|
DOS386 02 Apr 2007, 05:53
Quote: Should'nt I expect more from it ? I would expect silent playing ... rather than "No SoundBlaster" |
|||
02 Apr 2007, 05:53 |
|
m 05 Apr 2007, 11:12
NTOSKRNL_VXE wrote:
I have no (not even the cheapest) sound-card myself ! I was expecting to expect some nice demos of double buffering in DOS. I myself have never been able to create a flicker free animation in DOS-VGA And by the way NTOSKRNL_VXE is a horrible ID ! |
|||
05 Apr 2007, 11:12 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.