OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 2:58 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: More faster putpixel than 0ch?
PostPosted: Sat Jan 28, 2017 7:47 am 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 723
Location: Tallinn, Estonia
Use rectangular blits, instead of individual putpixel - this will be a huge advancement by itself.

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: More faster putpixel than 0ch?
PostPosted: Sat Jan 28, 2017 7:56 am 
Offline
Member
Member

Joined: Wed Jan 25, 2017 3:37 pm
Posts: 71
dchapiesky wrote:
well then - from wikipedia --

Quote:
Several versions of Turbo Pascal, including the latest version 7, include a CRT unit used by many fullscreen text mode applications. This unit contains code in its initialization section to determine the CPU speed and calibrate delay loops. This code fails on processors with a speed greater than about 200 MHz and aborts immediately with a "Runtime error 200" message.[25] (the error code 200 had nothing to do with the CPU speed 200 MHz). This is caused because a loop runs to count the number of times it can iterate in a fixed time, as measured by the real-time clock. When Turbo Pascal was developed it ran on machines with CPUs running at 1 to 8 MHz, and little thought was given to the possibility of vastly higher speeds, so from about 200 MHz enough iterations can be run to overflow the 16-bit counter.[26] A patch was produced when machines became too fast for the original method, but failed as processor speeds increased yet further, and was superseded by others.

No, i'm not using crt or graph.

I'm myself implement part of modern ObjPas sysutils and some bios interrupts.


Top
 Profile  
 
 Post subject: Re: More faster putpixel than 0ch?
PostPosted: Sat Jan 28, 2017 7:59 am 
Offline
Member
Member

Joined: Wed Jan 25, 2017 3:37 pm
Posts: 71
Brendan wrote:
Hi,

alexfru wrote:
Brendan wrote:
* Then it does a write to the frame buffer. This is the only part that actually matters, and is probably faster than every single step of pure pointless bloat that occurred before and after.


You may find that in planar 16-color modes (e.g. the VGA 640x480x16 mode) the entire screen can be updated no faster than ~30 times per second using the most optimal code. On a 1GHz+ CPU. Which is like 3K+ CPU clocks/pixel. Ouch. I'm not sure which part of the video hardware is to blame (non-planar VGA and SVGA modes don't have this problem). I never looked into it. Slow port I/O for switching planes and setting pixel masks? Some weird compatibility feature?


For this case I pre-arrange it all as "buffer per plane" in RAM; then do "switch to plane 0; blit everything for plane 0; switch to plane 1; blit everything for plane 1; ..." (and I set the pixel mask and write mode once when setting the mode). I've never had any kind of performance problem.


Cheers,

Brendan


No, no.

I'm not writing directly to vram.

I'm using bios interrupt.

And my screen not updates every 30 frames.


Top
 Profile  
 
 Post subject: Re: More faster putpixel than 0ch?
PostPosted: Sat Jan 28, 2017 8:51 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

monobogdan wrote:
No, no.

I'm not writing directly to vram.

I'm using bios interrupt.

And my screen not updates every 30 frames.


Erm.

At this point; I'm more interested/curious in finding out why you didn't expect "using BIOS" to be excruciatingly bad before you wrote the code. Is someone giving you very bad advice? Did nobody warn you? Is there something that can be done to reduce the risk of other people falling into the same tar-pit of doom?


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: More faster putpixel than 0ch?
PostPosted: Sat Jan 28, 2017 1:19 pm 
Offline
Member
Member

Joined: Wed Jun 17, 2015 9:40 am
Posts: 501
Location: Athens, Greece
Hi,


monobogdan wrote:
I'm not writing directly to vram.

I'm using bios interrupt.
Which is, just like Brendan explained, 100 times worse than simply writing directly to VRAM. Also, don't use putpixel in a loop - this adds too much overhead and performance degradation will be noticeable even if your screen doesn't update 30 times a second.

To illustrate the point, writing to VRAM is slow already. It however becomes needlessly much slower when obfuscated around a loop that uses putpixel that uses a totally inefficient BIOS call that shall not be used by anyone... ever.


Regards,
glauxosdever


Top
 Profile  
 
 Post subject: Re: More faster putpixel than 0ch?
PostPosted: Sun Jan 29, 2017 2:43 am 
Offline
Member
Member

Joined: Sun Feb 01, 2009 6:11 am
Posts: 1070
Location: Germany
monobogdan wrote:
No, no.

I'm not writing directly to vram.

That's exactly the point. You're not writing directly to it, but if you want at least some performance, that's what you should do.

Also, are you sure that using a 16 bit closed-source (= not portable to your OS) DOS compiler for your project is the right tool? There are special cases where it actually might be the right tool, but these are cases where I'd expect the developer to be more advanced. Did you consider making a 32 bit OS with FreePascal as your compiler?

_________________
Developer of tyndur - community OS of Lowlevel (German)


Top
 Profile  
 
 Post subject: Re: More faster putpixel than 0ch?
PostPosted: Mon Jan 30, 2017 2:28 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Just out of curiosity, when you say your target is i486, do you mean that you are targeting x86 with only the instructions that existing prior to the Pentium, or do you mean you are testing on actual 486 PC hardware? I am guessing the former, as the majority of 486 systems have long since ceased working, and were never as common as later system would be.

Also, are intending for your final system to run in real mode, or is the use of Turbo Pascal primarily related to your intended bootloader compiler? Turbo Pascal for DOS 7 (which dates from 1992 - I recall using it at the time - and was the last TP release before they renamed it to Delphi in 1995) does not produce 32-bit code, AFAIK, though I may be wrong about that. Conversely, the Windows version, called Borland Pascal for Windows, doesn't produce either 16-bit real mode or 32-bit protected mode - it was exclusively 16-bit protected mode for Windows, as the majority of systems at the time were 286 systems, and Win32S hadn't been released yet. To the best of my knowledge, none of the versions of Turbo Pascal/Borland Pascal/Delphi that generate 32-bit code can generate stand-alone executables - there are Mac and Linux versions of some of the later Delphi compilers, but they aren't going to work for OS dev.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: More faster putpixel than 0ch?
PostPosted: Mon Jan 30, 2017 2:35 pm 
Offline
Member
Member

Joined: Wed Jan 25, 2017 3:37 pm
Posts: 71
Schol-R-LEA wrote:
Just out of curiosity, when you say your target is i486, do you mean that you are targeting x86 with only the instructions that existing prior to the Pentium, or do you mean you are testing on actual 486 PC hardware? I am guessing the former, as the majority of 486 systems have long since ceased working, and were never as common as later system would be.

Also, are intending for your final system to run in real mode, or is the use of Turbo Pascal primarily related to your intended bootloader compiler? Turbo Pascal for DOS 7 (which dates from 1992 - I recall using it at the time - and was the last TP release before they renamed it to Delphi in 1995) does not produce 32-bit code, AFAIK, though I may be wrong about that. Conversely, the Windows version, called Borland Pascal for Windows, doesn't produce either 16-bit real mode or 32-bit protected mode - it was exclusively 16-bit protected mode for Windows, as the majority of systems at the time were 286 systems, and Win32S hadn't been released yet. To the best of my knowledge, none of the versions of Turbo Pascal/Borland Pascal/Delphi that generate 32-bit code can generate stand-alone executables - there are Mac and Linux versions of some of the later Delphi compilers, but they aren't going to work for OS dev.


It's blink. So, i'm remember GDI.

Double buffering is my friend?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 23 guests


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group