OSDev.org

Use rectangular blits, instead of individual putpixel - this will be a huge advancement by itself.

dchapiesky wrote:well then - from wikipedia --

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.

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.

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

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

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?

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.

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?