;Code written by keantoken from the FASM forums.

;This include file uses the VBE 3.0 standard to draw objects on the screen.

;Since this include file uses the stack as a data transfer medium, to avoid complicating your coding, try switching the current stack by changing the ss (stack segment) register.



;Include 'Math.inc'



INI_Draw:      ;This initializes the draw include depending on different options specified by stack values.

    ;Options Format: the following values should be pushed into the stack in this order: Line Antialiasing (value=amount) (can be used as blur), Bit Depth (0=4, 1=8, 2=16, 3=24, 4=32),



;-------------------------------------------------------------------------------------------------------------------------

Draw_Line:     ;The draws a line from one place on the screen to the next. x1,y1,x2,y2,x3,y3... are loaded into the stack NOT in reverse order so that the stack order should be from bottom (most recent) to top, ...y3,x3,y2,x2,y1,x1.

      pop eax                                                         ;eax=y3

 mov esi, eax                                                    ;esi=eax=y3. This helps us in the end to know where to stop drawing our line. Watch when the esi register is used next.

 sub esp, 2                                                      ;decrement the stack pointer by two in order to pop y2

  pop ecx                                                         ;ecx=y2

                                                                 ;NOTE: stack now looks like x3,x2,y1,x1 and esp is pointing at x2

   sub eax, edx                                                    ;y3-y2=eax

      ;---------------------- Done with Y calculation for the moment. Now on to X:

        mov esp, 0                                                      ;put the stack pointer back where it belongs.

   pop edx                                                         ;edx=x3

 sub esi, edx                                                    ;esi-edx=esi OR y3-x3=esi. In the end, esi will be used to determine when to stop drawing pixels.

       pop ebx                                                         ;ebx=x2

 ;NOTE: stack now looks like y1,x1 and esp is still pointing at 0. Later, y2 and x2 will be pushed back into the stack so that they can be used to draw the next line. you will see that through all of this mathematical technoblab, their initial values are preserved.

    sub edx, ebx                                                    ;x3-x2=edx

      ;---------------------- Done with X calculation for the moment. Now calculating the slope of x3,y3,x2,y2.

                                                                       ;eax=y3-y2,

                                                                     ;edx=x3-x2,

                                                                     ;esi=y3-x3

      div edx                                                         ;(eax/edx=eax)=((y3-y2)/(x3-x2)=eax) Remainder=edx. This means that for every step in y, there are eax steps in x.

      ;Note that ecx and ebx (y2 and x2) remain unchanged. This is our starting position. This means that the line is drawn from x2,y2 to x3,y3 - NOT from x3,y3 to x2,y2.

Line_Loop:

      inc ss   ;switch to new stack segment for loading variable data into for calls so that the original stack data is unchanged.

    push ebx ;push X coordinate into the stack.

     push ecx ;push Y coordinate into the stack.

     jmp Draw_Pixel   ;Draws a pixel on the screen: X and Y coordinates are pushed into the stack NOT in reverse order so that the stack should look like this from bottom (most recent) to top: Y,X.

        sub ebx, eax     ;ebx-eax=ebx. Remember that eax was the answer from the previous division operation.

   sub ecx, edx     ;ecx-edx=ecx. Remember that edx is the remainder from the previous division operation.

 ;---------------------- The code above this line computes the coordinates of the pixels and then draws them. Now, we have to compute when to stop drawing pixels! Note: The placements MUST be exact or it will never stop drawing the line since the end of the line coordinates must match a value calulated before the comparison.

       add esi, ebx     ;Remember: esi=y3-x3. So, we add the current X value and if the values match up, then we've met the end of the line.

      cmp esi, ecx     ;We compare esi with our current Y value, and if the values match up, then we've met the end of our line.

     sub esi, ebx     ;Return esi to original state. Problem: I'm not sure if the [cmp] instruction needs to be placed just before the [jmp] instruction, but if it does, this won't work!

     jne Line_Loop    ;If esi and the current Y value are not equal, then we need to draw the next pixel. So we loop.

        ;I'll have to fill in this part when I have the time.



  dec ss           ;Switch back to original stack segment.

        push ebx         ;Put x2 back where it belongs. This could also be done at the beginning of Line_Loop before the [inc ss] instruction, since the

        push ecx         ;Put y2 back where it belongs.

 re sb, esp       ;Return if sb=esp. Returns to the main process if all stack data hasd been cleared. This goes at the end of the program. Before this the [dec ss] instruction is used to switch back to the original stack segment.

    jmp Draw_Line    ;Loop and draw next line if all stack contents have not been cleared.

;-------------------------------------------------------------------------------------------------------------------------

Draw_Pixel:          ;Draws a pixel on the screen: X and Y coordinates are pushed into the stack NOT in reverse order so that the stack should look like this from bottom (most recent) to top: Y3,X3,Y2,X2,Y1,X1. Each coordinate pair draws its own pixel. This way, multiple pixels can be drawn with just one calling.

  pop eax          ;eax=Y coordinate

      pop ecx          ;ecx=X coordinate

      mov bx, ax       ;lower bit part (decimal part) of eax is transferred into bx

   mov dx, cx       ;lower bit part (decimal part) of edx is transferred into cx

   shr eax, 16      ;moves the upper bit part (integer part) of eax to the lower bit part so that the integer is correct.

  shr ecx, 16      ;moves the upper bit part (integer part) of ecx to the lower bit part so that the integer is correct.

  ;NOTE: eax=integer part of Y coordinate, ecx=integer part of X coordinate, bx=decimal part of the Y coordinate, dx=decimal part of the X coordinate.

Draw_Pixel_Main:

    inc ss           ;switch to new stack segment so as to not obliterate the original stack.    

;Linedraw code written by keantoken from FASM forums.

use32

        start:       ;starts main process
        Setup_Display ;initializes display via VESA 3.0
        Get_Input     ;Gets input. Stack values are as shown: nLines, y1, x1, y2, x2, y3, x3...
        -------------------------------------------------------------------------------------------
        mov sp, 2     ;moves stack pointer up to x1... stack: ___1__ _2_ _3_ _4_ _5_ _6_ _7_ _8_  <- these correspond to sp numbers.
        pop eax       ;x1 to eax...                    stack: nLines, y1, sb, y2, x2, y3, x3...
        push eax      ;puts x1 back in                 stack: nLines, y1, sb, x1, y2, x2, y3, x3...
        mov sp, 4     ;move stack pointer up to x2...  stack: nLines, y1, x1, y2, sb, x2, y3, x3...
        pop ebx       ;x2 to ebx... eAx=x1 eBx=x2      stack: nLines, y1, x1, y2, y3, x3...
        sub eax, ebx  ;x1-x2=edx, eax-ebx=eax...
            

you are crazy.

You might want to consider setting the stack pointer in multiples of 4 bytes. For three reasons 1) There is a performance hit when you push/pop 32bit values to a non-32bit-aligned stack, 2) Your push/pop are using 32bit registers so you probably overwrite upper 16bit values, and the most serious 3) It is just plain ugly and difficult to follow and WON'T give you the best performance you are trying to achieve.

You have mixed 16bit and 32bit code which is also going to create a performance overhead.

I wouldn't ever recommend the sort of direct manipulation of SP like you have above. It dictates too much about what direction your future code will take. I would imagine you will have many many rewrites and large headaches trying to get that type of coding style to a point of just working let alone giving good performance.

BTW: When you manipulate the stack pointer in the fashion above, you have to either use protected mode ring-3 code or disable interrupts else your stack will be corrupted when the first interrupt arrives.

These notes have been compiled by keantoken from the FASM forums, do with thenm what you want.

Operator Bits Bytes

byte     8    1

word     16   2

dword    32   4

fword    48   6

pword    48   6

qword    64   8

tbyte    80   10

tword    80   10

dqword   128  16



------------------------------------------------------

________ _____

Type    |Bits |

--------|     |

        |8    |al   cl   dl   bl   ah   ch   dh   bh

General |16   |ax   cx   dx   bx   sp   bp   si   di

        |32   |eax  ecx  edx  ebx  esp  ebp  esi  edi

________|     |

Segment |16   |es   cs   ss   ds   fs   gs

________|     |

Control |32   |cr0       cr2  cr3  cr4

________|     |

Debug   |32   |dr0  dr1  dr2  dr3            dr6  dr7

________|     |

FPU     |80   |st0  st1  st2  st3  st4  st5  st6  st7

________|     |

MMX     |64   |mm0  mm1  mm2  mm3  mm4  mm5  mm6  mm7

________|     |

SSE     |128  |xmm0 xmm1 xmm2 xmm3 xmm4 xmm5 xmm6 xmm7



NOTES: ss, sp and esp are stack pointers:. ss switches stack segment.

EAX is loaded for use with WIN32 syscalls:.

eax, ecx, edx, and ebx are general-purpose registers. They

are just for storing values. esi and edi are index 

registers, ususally used for pointers, but can be used as 

general registers. 

------------------------------------------------------



Memory Addresses



Address 0  1  2  3  4  5      6  7

Memory  2A 45 B8 20 8F CD-ROM 12 2E



------------------------------------------------------



Instrucions:



mov <dest.>,<source> ;Both operands cannot be memory

add <dest.>,<source> ;(dest.)=(dest.)+source

sub <dest.>,<source> ;(dest.)=(dest.)-source

mul <source>         ;eax=(source)*eax (unsigned)

imul <source>        ;eax=(source)*eax (signed)

div <source>         ;eax=eax/(source) remainder=edx (unsigned)

idiv <source>        ;eax=eax/(source) remainder=edx (signed)

inc <dest.>          ;(dest.)=(dest.)+1

dec <dest.>          ;(dest.)=(dest.)-1

push <source>        ;source->stack

pop  <source>        ;source<-stack





------------------------------------------------------



Conditions:



Mnemonic Condition tested      Description



o        OF = 1                overflow

no       OF = 0                not overflow

c                              carry

b        CF = 1                below

nae                            not above nor equal

nc                             not carry    

... <some stuff about SS> ...

Dex, that source is to the old 1.0 version, there's actually a newer 1.1 version download (which I had always assumed you used since I "ported" it to FASM).

9K SPACE INVADERS VERSION 1.1
September 17, 1995
CHRONOLOGICAL RELEASE NOTES


Version 1.0 - August 17, 1995
-----------------------------------------------------------------------------

- Initial release - No known bugs

Version 1.1 - September 17, 1995
-----------------------------------------------------------------------------

- Invaders would stop shooting on the higher levels - FIXED.

- I discovered this one during a paricularily good game at school during
class [snicker].

A number is picked at random, and if it is 2, one of the invaders is
selected to fire. The number picked is the shot frequency, which is
decreased every level. Eventually, it reaches 2, which is the maximum
frequency (the random number 2 shows up every time, and the invaders
fire constantly).

Unfortunately, the number gets decreased below this value to 0, selecting
a random number between 0 and 0, thus 2 never shows up, and the invaders
stop shooting. It was a simple fix.

- Time reset to midnight during game play - FIXED.

- I can't believe I didn't notice this! Dumb dumb dumb!
Thanks to Patrick A Springman for mentioning this one to me.

The game uses the real time clock for simple timing of the title
screen delays, printing delays, etc. When the game uses this timer,
it reset the timer to 0, then watched it until it reached a particular
value. The problem is, resetting this timer to 0 also resets the clock
to midnight.

The time change wasn't a permanent change. Once the machine was rebooted,
the timer is reinitialized with the CMOS clock value, and everything
returns to normal, but it was annoying anyway.

The game no longer adjusts the timer, rather it reads the current time
into a variable, adds the delay value to that variable, then watches
the timer until it reaches this calculated time.

It's better, but does cause some time inconsistancies. Mostly with the
amount of delay the title screens are displayed for - It doesn't seems to
affect the game play timing (as expected).

- Added high score functions, and rearranged title screens so score is always
visible.

Hello.

I am currently interested in developing a standalone PC game (with its own boot loader and everything). I decided I had better first focus on the boot loader. Since the documentation would take me hours to sift through, I would appreciate it if I could get some links or otherwise to MBR code written in FASM.

The game isn't going to be huge, only enough space is needed for a 2D game like those found on the PS1, plus a simple physics engine and perhaps a bunch of WAVs if I can't get more MIDI-like sound formats to work. Mainly I was thinking about using the PxTone format once Pixel releases documentation. No, I don't speak japanese. But I'll find a way, don't worry.

At any rate, due to the small amount of space needed, I was thinking the whole thing would run off of RAM. I imagine all that would be needed would be 256Mb IF I didn't manage to implement PxTone music format.

Then again, all the requirements of this project are mainly speculation, I have never really attempted something of this sort.

So the agenda for the MBR would basically be to take the information from the disk, write it to the RAM, and start things spinning (though doesn't the CPU already write everything to the RAM when it executes code?). I will be testing this with the Bochs emu on my Ubuntu Studio Linux partition. My first line of order will be to produce working line-drawing code, then circle-drawing, and gradually get more advanced until I have working include file with all the needed functions for graphical display.

Please bear with me, I'm new to programming in general, no you can't dissuade me from starting out in assembly.