flat assembler
Message board for the users of flat assembler.

Index > OS Construction > OS-like game in development, FASM MBR examples appreciated

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
keantoken



Joined: 19 Mar 2008
Posts: 69
keantoken
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.
Post 20 Mar 2008, 17:10
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
welcome.

programming boot video games with fasm.

the boot is not the harder step as i use a simple .com loader for my tests.
i code for real mode dos. then, if it works in pure dos, i adapt to pmode and vesa.

the drawline function is very simple todo, just need to know how.
i let you find by yourself. but for MBR with fasm look there:

http://board.flatassembler.net/topic.php?t=7747
http://board.flatassembler.net/topic.php?t=7833
http://board.flatassembler.net/topic.php?t=7915
http://board.flatassembler.net/topic.php?p=73646#73646
Post 20 Mar 2008, 18:23
View user's profile Send private message Visit poster's website Reply with quote
keantoken



Joined: 19 Mar 2008
Posts: 69
keantoken
Thank you for the links, I already know how to code line drawing, you just have to work Bresenham's magic.

I have some older incomplete code, I have no idea whatsoever whether it works or not, Anyone is welcome to tell me how good or bad it is. I also remember that when I used my mind as the emulator, I found a problem where under certain conditions the line would chop off halfway, though I think it was possible to avoid if the input was kept within certain bounds. And at any rate, what I wanted was the fastest algo possible, and adding compatibility would just slow it down.

Code:

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


What I did here was interesting, though I'm not sure if it would have worked:
Since this was basically going to be running in my own environment, I took some liberties. Mainly, everything is run in real mode, so I can switch stack segments at will. This speeds things up because I don't have to preserve the contents of the stack every time I want to change tasks. As you might notice, the code is incomplete, but the basic concept is there.

You'll also notice that I commented on nearly every line. Hehe.

So, I'm guessing that you need to have org 7C00h at the beginning to null offsets, you have to make sure the file is exactly 512 bytes long, by using 'times 512-2-($-$$) db 90h'.

And then, naturally you have to write the boot signature, dw 0AA55h.

I've seen 055AAh being used as well, though, in existing working bootsector codes. Do they both work?

Also, I need links on how to get input from the mouse straight from the port and how to understand it. For this linedraw application I need to be able to use the mouse.

Thank you for your time.

- keantoken
Post 20 Mar 2008, 20:22
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
ouch, is it a line drawing?
does it works?
what is the link with OS construcion?
Post 20 Mar 2008, 20:40
View user's profile Send private message Visit poster's website Reply with quote
keantoken



Joined: 19 Mar 2008
Posts: 69
keantoken
Well, I decided this was the most suitable forum because this game will essentially be an OS. Right now I'm starting at the basics: I will write up my line-drawing algorithm (I'm working on a newer one right now) and then I'll attach it to the mouse input and test it out in Bochs. I have never tested it, so I don't know if it works or not, not to mention it's not complete enough to test out yet.

I'm thinking since the code is so small I will just write it all to the boot code and test it that way.

- keantoken
Post 20 Mar 2008, 21:08
View user's profile Send private message Reply with quote
keantoken



Joined: 19 Mar 2008
Posts: 69
keantoken
Well, I'm going to bed. This is as far as I have gotten on my linedraw file. Hopefully I'll get more done tomorrow (or whatever time I wake up).

Code:
;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...
            


I believe sp changes the point at which data is extracted from the stack, for a while I though it was sb, but that's the base...

- keantoken
Post 20 Mar 2008, 21:38
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
you are crazy.

building an application with sp as a pointer is illness.
the stack pointer shall not be used as this. it is very hard to code like this.

how to manage large amount of data with only the sp?
sp is for current stack , to save context for applications, during calls, ints, etc...
if you want to play with stack, use BP as a Base Pointer and syscall coventions.
SP is the Stack Pointer, not a data pointer.
Post 20 Mar 2008, 21:49
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17667
Location: In your JS exploiting you and your system
revolution
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.
Post 20 Mar 2008, 21:56
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17667
Location: In your JS exploiting you and your system
revolution
edfed wrote:
you are crazy.
I didn't quite want to say that in my post above but I find it hard to disagree with you there.
Post 20 Mar 2008, 21:58
View user's profile Send private message Visit poster's website Reply with quote
keantoken



Joined: 19 Mar 2008
Posts: 69
keantoken
Quote:
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.


Well, here it is.

[quote=ASMComunity WIKI Book]There can be many stacks present at a time in memory, but there's only one current stack. Each stack is located in memory in its own segment to avoid overwriting other parts of memory. This current stack segment is pointed to by the stack segment (SS) register. The offset address to the most recently allocated stack location, called the top of the stack (TOS), is held in another register called the stack pointer (SP). The 16-bit SP register is used only in the 16-bit environment; in a 32-bit environment, the 32-bit extended stack pointer (ESP) register is used to point to the TOS. A pointer called the stack base (SB) points to the first entry that you put into the stack.

Adding an entry into the stack fills the next allocatable location (lower memory address) and changes (decrements) the stack pointer (SP) to point to the that location. Removing an entry empties the current location and changes (increments) the stack pointer to point to the previous allocated location (higher memory address).

* Each entry pushed into the stack makes the allocated section of the stack grow downward (toward lower memory addresses) and decreases SP by unit size.

* Each entry popped out shortens the allocated section of the stack upward (toward higher memory addresses) and increments SP by unit size (4 bytes for 32-bit; 2 for 16-bit; 1 for 8-bit).[/quote]

Yay for the WIKI. My basic plan is to switch stack segments via SS, for each different process in my environment. I suppose I do need to look up how interrupts work, but I don't see a page related to that on the WIKI. WIKIBooks doesn't give much info. I'm not sure why everyone is calling me crazy, this all seem to make sense to me.

I know that interrupts stop the current process and then execute a handler, but about how it effects the stack, I have no idea. Any links?

Oh, and in case anyone is interested, these are the notes I have compiled during the time I have been learning about assembly:

Code:
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    


Thank you for your time.

- keantoken[/quote]


Last edited by keantoken on 21 Mar 2008, 12:48; edited 2 times in total
Post 21 Mar 2008, 12:44
View user's profile Send private message Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
Is your bootable game to run in realmode or pmode ? and your best start by writing a simple com or exe file to run on Dos or other such OS before moving to your bootloader, to test your functons.
Also bootprog would make a good bootloader as it can load a com or mz exe from floppy or hdd.
See here: http://alexfru.chat.ru/epm.html#bootprog

Ps: I have a bootable game demo if you interested.
Post 21 Mar 2008, 12:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17667
Location: In your JS exploiting you and your system
revolution
keantoken wrote:
... <some stuff about SS> ...
Yeah, so. SS is the segment. You still have the ugly SP adjustments that will not help your cause towards faster routines.
Post 21 Mar 2008, 12:48
View user's profile Send private message Visit poster's website Reply with quote
keantoken



Joined: 19 Mar 2008
Posts: 69
keantoken
I'll get the ugly SP stuff sorted out, I think I got kinda mixed up on which registers do which. But I have the WIKI now, so everything should be fine.

Thank you Dex, I'm looking a Bootprog now and yes, I would definitely be interested in the bootable demo.

Thank you for your time.

- keantoken
Post 21 Mar 2008, 12:53
View user's profile Send private message Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
Here you go (see bottom of post), its a tasm game, add to MiniDos, a small 2k dos clone i coded.
The game is set to auto load on booting, you can get MiniDos code here:
http://board.flatassembler.net/topic.php?t=5275&start=0
and the game code is in the zip, along with a floppy image which you can use in a emulator or use something like winimage to put it onto a floppy.


Description: Abootable space invaders game
Download
Filename: GameBoot.zip
Filesize: 47.64 KB
Downloaded: 124 Time(s)

Post 21 Mar 2008, 16:37
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
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).

BTW, here's a link to Tomasz's TetrOS floppy boot sector game.
Post 24 Mar 2008, 03:50
View user's profile Send private message Visit poster's website Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
rugxulo wrote:
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).
Thanks rugxulo, i did not know about this ver, i will use it from now on.
Post 24 Mar 2008, 13:41
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
EDIT: Forum bug doesn't allow apostrophes ' in attachment text.


Last edited by rugxulo on 24 Mar 2008, 21:17; edited 2 times in total
Post 24 Mar 2008, 21:15
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
WHATSNEW.DOC wrote:

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.


EDIT: invadr11.zip


Last edited by rugxulo on 12 Oct 2016, 00:17; edited 1 time in total
Post 24 Mar 2008, 21:16
View user's profile Send private message Visit poster's website Reply with quote
itsnobody



Joined: 01 Feb 2008
Posts: 93
Location: Silver Spring, MD
itsnobody
keantoken wrote:
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.


Probably a lot less than 256MB, I mean look at the old Playstation 1:
MIPS R3000A-compatible (R3051) 32bit RISC chip running at 33.8688 MHz
Main RAM: 2 MB
Video RAM: 1 MB
Sound RAM: 512 KB
CD-ROM Buffer: 32 KB
Operating System ROM: 512 KB

I doubt you'll need 256MB for any Game, and the 33MHz 3.5MB RAM Playstation ran 3D Games with sounds, etc..

What kind of game are you making? You might not even need 32-bit mode...
Post 26 Mar 2008, 13:58
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
video ram = 1MB ==> if pixels are 32 bits leng, then, up to 256K pixels, then, 256*1000, it's more than the PS resolution, so, you can memorise more than one screen. to increase the speed. triple buffer???

sound ram = 512KB if the sound is CD quality, then, it will contain up to 6 seconds of sounds.

then, see the MEGADRIVE spec, the CPU runs at 19 MHZ, the GPU is very hard to progamm cause of the sprite model, only sprites are allowed, and see the result, sonic & knuckles 3, the better game on this console.

now, we have machines with 1GHz CPU, 512MB ram, and it's very slow... why??? ask it to the LAYERS constructors, as SUN, M$, BORLAND, ADOBE etc...
all these layers slow down the machines.

then, only one abstraction layer and directlly the asm layer will improve the performances of current machines.
Post 26 Mar 2008, 18:51
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< 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 GitHub, YouTube, Twitter.

Website powered by rwasa.