I have moved this info to my DOS Video cards benchmarking sheet, its just one column:
https://docs.zoho.com/sheet/published.do?rid= … 49606de568c62b9

ruthan wrote:

2) How to discover VBIOS size without CheckIT in pure Dos?

Use DEBUG.COM and a hex calculator.
IBM PC standard requires video BIOS to be at seg:off C000:0000. We only need the 1st 3 bytes from C000:0000.
1st and 2nd byte is "55 AA" - option ROM signature.
3rd byte is the size - It tells the size in number of 512-byte pages.

Here's the example:

1C:\>debug
2-dc000:0
3C000:0000  55 AA 4C .. .. .. ..

So the size is 76 * 512 bytes = 38,912 or 38KB.

just seek any hex memory viewer at C000:0000.
vbios is ordinal addon rom. first three bytes is 55 aa xx, where:
55 aa - signature,
xx - one byte of addon rom SIZE, size = xxh * 512 byte (up to 128 KiB).
for sample, byte 68 mean size = D000h = 53248 bytes.
its meanuing, that vbios occupied addresses C0000-CCFFF.

kjliew : Thanks, that is what i needed, the would be nice to write small utility to was show result in KB (do calculation automatically), if someone is capable.

MERCURY127 wrote:

just seek any hex memory viewer at C000:0000.

I know Hex Editors, but not Hex Viewer, can you some free Hex Viewer and how to view specific memory range with it? I already using like Hexit, if it can be used?

- peek.com - resident base memory viewer;

- Norton Disk Editor - can view/edit base memory.
diskedit /g0 (or de /g0). /g0 disable graphic mouse cursor in Norton Utiliities;

- BD/PATCH Release 1.0 - rare, lost in time tool...
patch mem:{BASE|286|386} - view/edit first 1M/16M/4G.

ruthan wrote:

kjliew : Thanks, that is what i needed, the would be nice to write small utility to was show result in KB (do calculation automatically), if someone is capable.

I have just written a one-liner for you that does just the above:

Falcosoft wrote:

[
I have just written a one-liner for you that does just the above:

Nice thanks, i dont even know that such syntax is possible.. but im not expert
writeln('Video Bios size is: ', Longint(Mem[$C000:0002]) shr 1, ' KB');
What does exactly that shr 1 parameter?

ruthan wrote:

Falcosoft wrote:

[
What does exactly that shr 1 parameter?

It is 'shift right by one bit'. It's actually equivalent to a division by 2. Since you get the result in 512 byte units the full calculation is: Results in KB = xx * 512 / 1024 -> xx / 2.
(Shift is much faster than division and not all compilers use it automatically, but in this case speed is totally irrelevant, it's just a bad habit 😀 )

@Edit:
Gigabyte Geforce GTX 960: 58 KB
Inno3D Geforce 6600: 60 KB
Inno3D Geforce 7600 GT: 55 KB
Integrated ATI Radeon Xpress 1150: 64 KB

Thanks for explanation and results, especially G960 looks nice, i expected 72 KB or something like that every KB counts.

BTW does make such optimizations sense for Pascal (at least Borland Turbo 6 or 7 i dunno know), i mean back in day 20+ years ago, i was taught than Pascal is very slow in comparison to C and any serious performance heavy programming should be done in C or ASM:)
I saw lots of modern programming lang. comparisons, but i never actually checked DOS pascal vs. C comparisons. I remember that Pascal had also some 64 KB memory limit or something like that, i guess that there are some workarounds?

ruthan wrote:

Thanks for explanation and results, especially G960 looks nice, i expected 72 KB or something like that every KB counts.

Make sure you do not compare results you got with VBSize vs Bios File (Bios dumps) vs Checkit.
VBSize and debug method report the size of the memory payload. A BIOS file contains headers, paddings, parts that are irrelevant for DOS etc. so it's usually bigger than memory payload. Checkit does not seem to be able to differentiate between Video BIOS Rom and other option ROMs loaded above the Video Bios Rom but reports it as a continuous occupied area. So e.g. if you enable AHCI support Checkit may report a bigger occupied 'Video BIOS' area starting at C000 segment. And if you peek the memory area it reports the Video Bios at the start but it cannot tell where the Video BIOS ends and where other option ROMs start.

BTW does make such optimizations sense for Pascal (at least Borland Turbo 6 or 7 i dunno know), i mean back in day 20+ years ago, i was taught than Pascal is very slow in comparison to C and any serious performance heavy programming should be done in C or ASM:)

If a compiler makes slower code that means hand made optimizations make MORE sense not less 😀
Anyway contemporary Turbo C vs Turbo Pascal executable speed comparison can show that Pascal is somewhat slower but 'very slow' is exaggeration. But why people used Turbo Pascal is because the compiler is much faster than C (since it is a one step compiler that's why it cannot do so much optimizations as a C compiler). Even in case of very big projects in Turbo Pascal IDE Compile and Run counted seconds vs minutes in C.
Also Turbo Pascal IDE had a very good inline assembler so speed critical parts could be written in assembly without an external assembler. That's why you can see so many ASM sections in contemporary Pascal source codes. With hand made optimized assembly routines at key parts a Pascal program's execution speed can be much faster than pure C code.

I saw lots of modern programming lang. comparisons, but i never actually checked DOS pascal vs. C comparisons. I remember that Pascal had also some 64 KB memory limit or something like that, i guess that there are some workarounds?

Here you confuse things. Pascal as a programming language does not/ did not have more memory limit than C.
Memory limits are because of the memory model a compiler use. Real mode 8086 executable written in C also can have many 64 KB limits depending on the used memory model. E.g. executable files created by turbo c that use the tiny memory model can be only 64 KB overall including Code + data + heap + stack. Real mode DOS executable files have limits written in both Pascal and C.
More info:
http://wiki.freepascal.org/DOS#Supported_memory_models
Real mode Trurbo Pascal 6/7 had memory limits described by the large memory model (one of the less restrictive models). Namely: Code <= 1MB, Data <= 64KB, Stack <= 64KB, Heap <= 1MB. So only the data and stack segments had a 64 KB limit. Code and heap usage was only constrained by the memory available in real mode. And yes, there was an additional overlay method to overcome even these limits.
Also Turbo/Borland Pascal 7 supported 286+ 16-bit protected mode DOS target where the limit was 16 MB (you can usually find the Borland DPMI server DPMI16BI.OVL beside these protected mode executable files)
And with Free Pascal compiler you can do 386+ 32-bit protected mode DOS programs that have 4 GB limit (it was also available 2 decades ago).

@Edit:
Just out of curiosity I have made a number crunching Mandelbrot set generator Turbo C vs Turbo Pascal benchmark test suite (source files included):

You should simply start TESTS.BAT to get the results.

All optimizations are set for speed in both compilers, and the Pascal and C sources are line to line equivalents of each other. Also all executables use the same SVGA.BGI driver for displaying graphics. Maximum iterations are set to 1000.
Results at 920 MHz (4 x 230) on AMD Phenom II x4:

Pure C code: 7.3 sec.
Pure Pascal code: 7.5 sec.
Pascal + ASM code: 3.4 sec.

So here pure Pascal code is barely 3% slower than pure C code. But Pascal + assembly optimized code is more than 100% faster than pure C code.

Please remember that for UMB usage with EMM386 there is a 4 KB alignment limit.

That means that you can:
DEVICE=C:\DOS\EMM386.EXE I=CF00-F7FF NOEMS

But you cannot:
DEVICE=C:\DOS\EMM386.EXE I=CED0-F7FF NOEMS
(emm386 will create a page from CE00-CEFF and use it from CED0, but the ROM contents from CE00-CECF are not copied, and in most cases you have font troubles in text mode after typing "mode co80")

So you should increment your #15 Inno3D Geforce 7600 GT: 55 KB reported by FalcoSoft from 55 to 56 KB.

Disruptor wrote:

Please remember that for UMB usage with EMM386 there is a 4 KB alignment limit.

So you should increment your #15 Inno3D Geforce 7600 GT: 55 KB reported by FalcoSoft from 55 to 56 KB.

I do not think reported video bios sizes should be altered because of EMM386 4K alignment. These are 2 completely different things. Yes, you should know that values given to EMM386 in I, X etc. parameters are rounded down to the nearest 4-kilobyte boundary. But it does not mean that a video bios payload size in memory has to be 4k aligned.
Correct me if I'm wrong but but I think the question is the real bios size and not how EMM386 works. E.g. big vga bios sizes are relevant even when you use UMBPCI and not EMM386. But UMBPCI has a completely different alignment limit than EMM386 (that is 16 KB). But I also do not think because of UMBPCI's more strict alignment we should list video bios sizes as 16 KB aligned.
Both alignments can be calculated if you know the real bios size...

Falcosoft wrote:

Make sure you do not compare results you got with VBSize vs Bios File (Bios dumps) vs Checkit.

Ok its more complicated than expected.

Falcosoft wrote:

VBSize and debug method report the size of the memory payload. A BIOS file contains headers, paddings, parts that are irrelevant for DOS etc. so it's usually bigger than memory payload. Checkit does not seem to be able to differentiate between Video BIOS Rom and other option ROMs loaded above the Video Bios Rom but reports it as a continuous occupied area. So e.g. if you enable AHCI support Checkit may report a bigger occupied 'Video BIOS' area starting at C000 segment. And if you peek the memory area it reports the Video Bios at the start but it cannot tell where the Video BIOS ends and where other option ROMs start.

To results in first post i added which tool was used to extract info, at least for now i dont have any Bios dumps, but i would expect that it would be just 1:1 ROM copy.. if understand correctly you are saying that now whole ROM could be used for Vbios bios?
Checkit - it could have some bug, i didnt excepted that.. i will try to compare some CheckIt and VBsize results and we will see. For these who dont know CheckIT output looks like this.. Often there is at least manufactor name in message header.

Pascal / C stuff, sorry for off topic, but it interesting to me.. thanks for info.

Falcosoft wrote:

If a compiler makes slower code that means hand made optimizations make MORE sense not less 😀

It depends on point of view, it could be fight with windmills, waste of energy.. if you know that underlying technology is already slow. It make not sense to tune you running shoes/ style, you are racing with man on bike.. you should switch to bike too.

Falcosoft wrote:

Anyway contemporary Turbo C vs Turbo Pascal executable speed comparison can show that Pascal is somewhat slower but 'very slow' is exaggeration. But why people used Turbo Pascal is because the compiler is much faster than C (since it is a one step compiler that's why it cannot do so much optimizations as a C compiler). Even in case of very big projects in Turbo Pascal IDE Compile and Run counted seconds vs minutes in C.

I used / using info which i got when i was 12 / 13 years old in era before i was used to cross check info on internet, i never had reason to question that (when appears first Quake 1 editors and its sources code, DOS programming at the moment completely died).. and gain it from my a bit older friends, uncle and programming courses for children taught by college students etc. I started with Pascal, after i take a look on Qbasic and in 13 switched to use C, because of these arguments and because most advanced course level was C only.. I was for very long time lock in Borlands world, up to C++ Builder 5, or something like that, in early years lang / compiler and IDE was just package for me.
I never knew that Pascal is much faster for compiling, good to know. I played with idea to write something for DOS, but always was discourage that i would have to return to low level stuff as pointers, because for modern stuff im using mainly C#, but if there is not such big performance penalty of would reconsider use of Pascal.. but afaik for Dos now people using DJGPP or Watcom - C stuff, no Pascal anymore..

Falcosoft wrote:

Also Turbo Pascal IDE had a very good inline assembler so speed critical parts could be written in assembly without an external assembler. That's why you can see so many ASM sections in contemporary Pascal source codes. With hand made optimized assembly routines at key parts a Pascal program's execution speed can be much faster than pure C code.

Its strange that ASM part would be faster in Pascal, its from one company and im not sure if you are comparing Apples to Apples Pascal program's execution speed can be much faster than pure C code. i dont know you mean by pure C code, C supports ASM too.

ruthan wrote:

I saw lots of modern programming lang. comparisons, but i never actually checked DOS Pascal vs. C comparisons. I remember that Pascal had also some 64 KB memory limit or something like that, i guess that there are some workarounds?

Falcosoft wrote:

Here you confuse things. Pascal as a programming language does not/ did not have more memory limit than C.
Memory limits are because of the memory model a compiler use. Real mode 8086 executable written in C also can have many 64 KB limits depending on the used memory model. E.g. executable files created by turbo c that use the tiny memory model can be only 64 KB overall including Code + data + heap + stack. Real mode DOS executable files have limits written in both Pascal and C.

Yeah i meant whole Borland TP package, i know that is wrong, but im used just call it just Pascal.. as DOS for MS-DOS etc.

Falcosoft wrote:

More info: http://wiki.freepascal.org/DOS#Supported_memory_models Real mode Trurbo Pascal 6/7 had memory limits described by the […]
Show full quote

More info:
http://wiki.freepascal.org/DOS#Supported_memory_models
Real mode Trurbo Pascal 6/7 had memory limits described by the large memory model (one of the less restrictive models). Namely: Code <= 1MB, Data <= 64KB, Stack <= 64KB, Heap <= 1MB. So only the data and stack segments had a 64 KB limit. Code and heap usage was only constrained by the memory available in real mode. And yes, there was an additional overlay method to overcome even these limits.
Also Turbo/Borland Pascal 7 supported 286+ 16-bit protected mode DOS target where the limit was 16 MB (you can usually find the Borland DPMI server DPMI16BI.OVL beside these protected mode executable files)
And with Free Pascal compiler you can do 386+ 32-bit protected mode DOS programs that have 4 GB limit (it was also available 2 decades ago).

That is what really wanted to know, i was a bit afraid what there could be artificial design or licensing limit, because other argument what was used is that Pascal was developed for programming learning and never was targeted for heavy stuff..

Falcosoft wrote:

So here pure Pascal code is barely 3% slower than pure C code. But Pascal + assembly optimized code is more than 100% faster than pure C code.

Performance aspect, i always taught that there would be some performance tax for lack of pointers and overall user friendliness, easy to use aspect of Pascal package. As is typical for Java /C# vs C++ comparison, of course not so big, because they are running in their virtual machines... and this is reason why OSes and other performance heavy stuff are written in C, not in Pascal.
Even for modern stuff that there was Delphi, Pascal for Windows, but it died, i though that reason was performance aspect..

I always cared about games, i know because of Runtime errror 200:), that at least some games were written in Pascal, but again we were taught that for best games performance is C only way.. BTW back to Windows as far is known not too much AAA games were written with Delphi.
I know more about modern games and there is C used for 95% + of things as main language for heavy duty core engine stuff, for some gameplay stuff could be used some light scripting lang even slimmers like Python, even Quake 1 has QuakeC virtual machine code, which run i thing at least 10x slower than native stuff, Unreal 3 script is even slower, strange combination was Vampire the Masquerade - C (its Quake engine port)+Java for scripting. There are few expection like Minecraft - original Java based.. but it was know for underwhelming visual aspect and performance problems. I as i know there was lots of Java + OpenGL engine projects back in time, but i also failed, i thing because of lack of performance.

One of biggest games engines today is Unity3D has as everything core in C, otherwise its using C# (there is support for other even slower lang as Javascript, BOO etc..) and its big disadvantages in comparison to Unreal 4 which is whole in C if you want, there are lots of performance problems, which are there for years and really blocking to make some AAA game with it.

ruthan wrote:

To results in first post i added which tool was used to extract info, at least for now i dont have any Bios dumps, but i would expect that it would be just 1:1 ROM copy.. if understand correctly you are saying that now whole ROM could be used for Vbios bios?

If you dump video bios (firmware is a better term) of modern video cards you can see that the size is usually 128 KB+. Geforce GTX 960 full video bios dump file size is 176 KB. There is no such space in C0000 - xxxxx range in real mode to store the copy of full video firmware anymore. Not to mention that a modern card's firmware contains routines that are completely irrelevant under DOS such as dynamic performance modes/power saving features, all 3D acceleration related stuff. And modern 32-bit/64-bit operating systems never use the video bios available in real mode at C0000-xxxxx range but use own drivers.
A proper 'BIOS' dump is the exact copy of a video card's firmware. But the content available at C0000-xxxxx is NOT the exact copy of the whole video firmware anymore, but a stripped down part of it.

@Edit:
Problem with Checkit: As I said in some cases Checkit can report video bios + option ROM together as one continuous occupied area labelled as 'Unknown ROM'.
In this case the real Video bios size is actually less than 64 KB but AHCI option ROM is enabled. Someone can misunderstand this and falsely believe that in this case video bios is 88 KB.

It can be misleading since when you peek at the memory area you can see the sign of a video bios rom (since it's at the start of the address range):

If you disable AHCI in the above case Checkit reports 64 KB 'Unknown ROM' that is still not fully correct for the real video bios size and it still cannot recognize 'Video ROM' . So it seems Checkit has problems properly detecting with video bios sizes bigger than 32KB.

Performance aspect, i always taught that there would be some performance tax for lack of pointers and overall user friendliness, easy to use aspect of Pascal package

I don't know where you got the information from that Pascal does not have pointers. It always has full pointer support even in Turbo Pascal days:
https://www.tutorialspoint.com/pascal/pascal_pointers.htm

Falcosoft wrote:

Also Turbo Pascal IDE had a very good inline assembler so speed critical parts could be written in assembly without an external assembler. That's why you can see so many ASM sections in contemporary Pascal source codes. With hand made optimized assembly routines at key parts a Pascal program's execution speed can be much faster than pure C code.

Its strange that ASM part would be faster in Pascal, its from one company and im not sure if you are comparing Apples to Apples Pascal program's execution speed can be much faster than pure C code. i dont know you mean by pure C code, C supports ASM too.

I don't think you have understood my original sentence: It was "With hand made optimized assembly routines at key parts a Pascal program's execution speed can be much faster than pure C code."
Of course you can use assembly routines in C too. No one said that 'ASM part would be faster in Pascal'. I talked about pure C code. So my argument was that you could get the biggest performance gains when you used hand made assembly optimized routines at key parts of the program and not that you chose C instead of Pascal. You could not save using assembly if you wanted best performance regardless of using Pascal or C.
And Turbo Pascal had no disadvantage at this part.

but afaik for Dos now people using DJGPP or Watcom - C stuff, no Pascal anymore..

And of course there is Free Pascal...

Even for modern stuff that there was Delphi, Pascal for Windows, but it died, i though that reason was performance aspect..

Delphi is still alive (even with 64-bit support) and arguably is still a viable choice for native Win32/Win64 desktop programming.
Delphi's problem is not performance but bad business choices (there is no free/community version, and each version could cost you a fortune twice a year) and real multi platform support. IOS/OSX/Android dialect of Object Pascal is different from Win32/64 dialect and you cannot use the known Win32/64 visual controls (VCL) in mobile development. So the 'write once, compile everywhere' motto of Delphi is not true in reality.

Sorry for not reflecting the other 'modern programming' parts of your post but it's out of context for me.
Personally I have never written (and never will) AAA+ games so I have no experience in this area.
But I have written many performance critical programs/libraries in different Pascal developing environments (of course also using some assembly optimizations at key parts) and all of them have been at least as fast as implementations written in C/C++ environments.
Nowadays at work I'm programming exclusively in environments that use some kind of C dialect languages but I miss Pascal and low-level assembly every day 😀
Also (partly) I'm visiting a retro forum like this because I'm a little bit fed up with modern programming trends. So I'm not the best choice to discuss Java, web development, .Net stuff anyway.

Interesting thread - never really thought about this. Can’t you turn Video bios shadowing off in bios? Or is that referring to copying the entire rom vs payload executed portion?

BinaryDemon wrote:

Interesting thread - never really thought about this. Can’t you turn Video bios shadowing off in bios? Or is that referring to copying the entire rom vs payload executed portion?

If Video Bios Shadow is disabled then the content of ROM is not copied to RAM and read directly from ROM when used, but the size of the content does not change because of shadowing. Also shadowing does not change the address range limit problem. Video Bios shadow enabled or not the content is always available at the same address.

Thanks for clearing that up. I’ll be interested to see if anyone finds a rom smaller than 32kb and who has the most bloated.

Inno3D TNT2 M64 PCI: 44Kb reported by NSSI