flat assembler
Message board for the users of flat assembler.

Index > DOS > YAMFAT - yet another my first assembly thread

Author
Thread Post new topic Reply to topic
dvlfrnd



Joined: 09 Mar 2007
Posts: 15
dvlfrnd
thanks to the patient people of this forum who took their time to answer my questions,
i went ahead and tried to implement double buffering example as my first program.
all the reading i did paid off,i didn't have much trouble,it compiles to 84 bytes,
i'm not concerned about its size,i'm more concerned about doing things right at the moment.
so i'd appreciate it if you could point out what i did right or wrong,or what could be better etc..
Code:
frontbuffer equ 0A000h
backbuffer equ 09000h
macro exitDos {
        setmode 0003h
        mov ax,4C00h
        int 21h
}
macro setmode n {
        push ax
        mov ax,n
        int 10h
        pop ax
}
macro clrscr color {
        mov al,color
        call clearscreen
        call swapBuffers
}
macro checkKey { 
        mov ah,11h
        int 16h
}

use16
org 100h

setmode 0013h

mov bl,0
start:
clrscr bl
inc bl
checkKey
jz start

exitDos

swapBuffers:
        mov cx,16000 ; fixed
        mov di,backbuffer
        mov si,frontbuffer
        mov ds,di ; push/pop better?
        mov es,si
        xor di,di
        xor si,si
        vBlankBegin:    ; wait for vertical retrace
                mov dx,03DAh
                v1:
                in al,dx
                and al,08h      ; 00001000b
                jnz v1                  ; bit8 == 1,still in vertical blank 
                v2:
                in al,dx
                and al,08h
                jz v2                   ; bit8 == 0,out of vertical blank,wait for this to finish
        vBlankEnd:              ; entered v.blank again,start to copy
        rep movsd               ; ds:si -> es:di, find a faster way(unroll loop,fpu?)
        ret
clearscreen:
        mov di,backbuffer
        mov es,di
        xor di,di
        mov cx,64000
        rep stosb ; al -> es:di , es=backbuffer
        ret

;backbuffer dw 09000h
;frontbuffer dw 0A000h
    


Last edited by dvlfrnd on 22 Mar 2007, 08:29; edited 1 time in total
Post 22 Mar 2007, 07:01
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Quote:
to implement double buffering example


Looks rather like parallel buffering ... Confused

Code:
backbuffer equ 09000h
    


I fail to see a memory allocation Confused

Code:
swapBuffers:
    


I see an attempt to copy, not swap Confused

Code:
        mov cx,64000
        rep movsd               ; ds:si -> es:di, find a faster way(unroll loop,fpu?)
    


64000*4 bytes Confused

Faster needed ? No idea Sad Is it slow at all ?

Code:
        mov cx,64000
        rep stosb ; al -> es:di , es=backbuffer
    


Correct, but slow Confused

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 22 Mar 2007, 07:25
View user's profile Send private message Reply with quote
dvlfrnd



Joined: 09 Mar 2007
Posts: 15
dvlfrnd
yeah it is copying,not swapping Smile
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 Smile
thanks
Post 22 Mar 2007, 08:26
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
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 Wink ) 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 Wink

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 25 Mar 2007, 11:16
View user's profile Send private message Reply with quote
dvlfrnd



Joined: 09 Mar 2007
Posts: 15
dvlfrnd
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.
Post 25 Mar 2007, 15:02
View user's profile Send private message Reply with quote
Goplat



Joined: 15 Sep 2006
Posts: 181
Goplat
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.
Post 25 Mar 2007, 20:26
View user's profile Send private message Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden
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.
Post 26 Mar 2007, 02:42
View user's profile Send private message Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden
What about porting it to MMX. I think its safe to assume that most CPU's have MMX theese days. Even a P-166.
Post 26 Mar 2007, 02:56
View user's profile Send private message Reply with quote
dvlfrnd



Joined: 09 Mar 2007
Posts: 15
dvlfrnd
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?
Post 26 Mar 2007, 05:19
View user's profile Send private message Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden
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 )
Post 26 Mar 2007, 06:51
View user's profile Send private message Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden
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.
Post 26 Mar 2007, 07:15
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Quote:
I think its safe to assume


And some people assume SSE as well Sad

Code:
BLA.EXE crashed at sdjhsjfhsd:sdjhdjf with illegal instruction 
eax=dskfjdlf 84843 34587894 00000 bla bla bla bla ...
    


Sad

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. Smile

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 26 Mar 2007, 08:06
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
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. Laughing
Post 29 Mar 2007, 02:37
View user's profile Send private message Visit poster's website Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden
Quote:

but DOS code should work down to 8086 or 80386 at least.

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
Post 30 Mar 2007, 00:28
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
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??)
Post 31 Mar 2007, 03:30
View user's profile Send private message Visit poster's website Reply with quote
m



Joined: 28 Dec 2006
Posts: 304
Location: in
m
Nice blinking colors !
Should'nt I expect more from it ?
Post 01 Apr 2007, 08:13
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Quote:
Should'nt I expect more from it ?


I would expect silent playing ... rather than "No SoundBlaster" Sad
Post 02 Apr 2007, 05:53
View user's profile Send private message Reply with quote
m



Joined: 28 Dec 2006
Posts: 304
Location: in
m
NTOSKRNL_VXE wrote:

I would expect silent playing ... rather than "No SoundBlaster"

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 Sad
And by the way NTOSKRNL_VXE is a horrible ID !
Post 05 Apr 2007, 11:12
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.