Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Discussion about old graphics cards, monitors and video related things.

Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby ruthan » 2018-7-29 @ 23:41

Hello,
in my pure Dos project i often face Dos not enough conventional memory problem.. this could be caused also by big videocard roms.

So i want to make some list of card names and video bios sizes.. I tried to search for it, here but i didnt find such thread.

How to discover VBIOS size:
a) Just run VBSIZE utility from FalcoSoft, it reports size in KB
b) Use Navratil software (NSSI), its more stable in Realmode and without sound drivers - Details -> Video -> Video Details - there is Video Bios size item, on first Detail->Video you could often find cards manufacturer / vendor.
c) Run these commands: // Thanks to kjliew
d) In past we recommendaed to Use CheckIT program - SystemInfo->Memory Map -> find Videp rom and read the size, you can press Enter on to check Videocard ROM vendor info.. but FalcoSoft found that sometimes is report size wrong too big..
e) C:\>debug
-dc000:0

It outputs something like this: C000:0000 55 AA 4C .. .. .. ..
User hex number after 55 AA, in this example 4C, use Windows calculator in programmers mode input number in HEX and look at value in DEC (at least Win10 calculater is showing it automatically) and after that multiply DEC value with 512 to get results in bytes. For out example 4C(hex) is 76 in DEC * 512 = 38 912 bytes, for kilobytes divite results by 1024 like this 38 912/1024= 38 KB.

List:
  1. ATI Mach 64 1 MB OEM - 32KB - Navratil
  2. Nvida Geforce 6600 GT AGP - Gigabyte GV-N66T128VP- 60 KB - Navratil
  3. Nvidia Geforce 6200 AGP - vendor ?? - 59 KB VBsize / Navratil
  4. 3DFX Vooodoo 3 2000 OEM (Elpida) PCI -bough as bulk - 32KB - VBsize / Navratil SI (NSSI)
  5. Nvidia Geforce 220 PCI-E - 56 KB - VBsize / Navratil is showing not primary Videocard info
  6. ATI X800 XL - Gigabyte GV-RX801256V - 64KB Navratil
  7. ATI X600 128MB -unknown vendor - 52 KB - Navratil
  8. S3 Virge - 32 KB - Navratil
  9. Matrox 1064SG (4MB Mystic) - 32 KB - Navratil
  10. Intel HD 4000 in CPU - 63 KB - VBSize. Navratil is not working for iGPUs
  11. MSI Geforce 1030 passively cooled MSI (MS-8C98) - 56 KB - Navratil
  12. MSI Geforce 7900 GT Microstar - MS-663- 56 KB - Navratil
  13. Gigabyte Geforce GTX 960: 58 KB reported by FalcoSoft, VBsize
  14. Inno3D Geforce 6600: 60 KB reported by FalcoSoft, VBsize
  15. Inno3D Geforce 7600 GT: 55 KB reported by FalcoSoft, VBsize
  16. Integrated ATI Radeon Xpress 1150: 64 KB reported by FalcoSoft, VBsize
  17. Inno3D TNT2 M64 PCI: 44Kb reported by NSSI
  18. Radeon X800 PCI-E 256 MB V/D/VO (i think that it is Sapphire) - 57 KB reported by VBsize
  19. Cardex Tseng ET4000AX ISA: 32Kb reported by NSSI
  20. S3 Vision 864 PCI: 32Kb reported by NSSI
  21. Tseng labs ET3000AX ISA - 24 KB - smallest so far, NSSI / VBsize
  22. Radeon HD 3450 PCI-E Sapphire - 62 KB Navratil
  23. Radeon X600 Pro Xpression - 64 KB Navratil
  24. Geforce 4 MX AGP Microstar - 59 KB Navratil
  25. Geforce 7600 GT PCI-E Microstar MS-8951 - 59 Navratil/ VBsize
  26. InnoVision TNT2 M64 AGP -64 KB reported by NSI
  27. Geforce 730 GDDR3 55KB - reported by Navratil
  28. Radeon X1300 PCI-E 60 KB - reported by Navratil
  29. Geforce 6600 PCIE- 60 KB Gigabyte - reported by Navratil
  30. Radeon X300 PCI-E 52 KB - reported by Navratil
  31. Geforce 8400 GS PCI-E Gigabyte 56KB - reported by Navratil
  32. Radeon X800 PCI-E, Gigabyte one - 64 KB, Navratil
  33. Geforce 730 GDDR5 58KB - reported VBSize
  34. Radeon X600 PCI-E OEM with DMS-59 only (my guess is that is DELL / HP) - 44 KB only reported by NSSI
  35. Radeon X1300 Pro PCI-E Gigabyte - 64 KB reported by Navratil
  36. Geforce 7950 GT MS-663 - 56 KB Navratil
  37. Geforce 970 MSI MS-3160 - 58 KB Navratil
  38. Nvidia Geforce 7800GS AGP: 58KB reported by VBsize reported by Baoran
  39. Tseng ET4000/W32P VLB: 32Kb reported by VBsize reported by Baoran
  40. ATI Radeon ( First ever radeon model from year 2000 before they used any numbers) 64MB DDR AGP: 44Kb reported by VBsize, reported by Baoran
    --- Cards bellow are reported by Elianda--- if you interested about all copyrights info check its original post, i had to do some cutting
  41. AccelGraphics Eclipse with CL-GD5436/46 PCI VGA BIOS Version 1.25 32 kB
  42. Alliance ProMotion AT3D PhoenixVIEW/DT(TM) VGA-Compatible BIOS Version Ref, ( Version are internal value, shown only when code is run) -32 kB
  43. ATI VGA Improved Performace (ViP) 761295520 21SCM 1987/12/11 12:28 ATI VIP Bios, Version 1.03 - 32 kB
  44. TSENG ET3000 Copyright(c)1988 Tseng Laboratories, Inc. 07/24/89 V8.00X -24 kB
  45. TSENG ET3000 Copyright(c)1988 Tseng Laboratories, Inc. 08/10/90 V8.01X -24 kB
  46. Genoa SUPEREGA HIRES+ (C) copyright GENOA Systems Corp.05/19/87Version 3.10 CDS EXTMOD -16 kB
  47. ATI Mach64 CT 761295520 3? 0 î 1995/09/26 10:20 ATI264-CT PCI BIOS P/N 113-32102-105 , 1988-95,BK3.7.0/2.004MACH64CTPCIU - 32 kB
  48. ATI Mach64 GX 761295520 31 î 1994/11/11 15:23 ATI MACH64, PCI BIOS P/N 113-25406-102 ,1988-94, .BK3.4/0.026MACH64GXPCIUN -32 kB
  49. ATI Mach64 VT2 761295520 3? @ ú 1996/09/27 12:06 ATI-264VT PCI BIOS P/N 113-34004-104 ,1988-96. BK3.8.0/3.008 vtppd.ati 5 MACH64VTPCIU -32 kB
  50. Oak OTI32C Copyright 1989, OTI VGA BIOS ECv2.13-35%Wed Jan 03 08:42:10 1990 - 32 kB
  51. DSystems Papilio G1-2 12/20/94 Papilio G1 - 2 Version 1.46 WEITEK P9100, PhoenixVIEW(TM)VGA-Compatible BIOS, 1991-1994 WEITEK Corp. - 32 kB
  52. DSystems Papilio G1-4 12/20/94 Papilio G1 - 4 Version 1.46 WEITEK P9100, 1984-1991 Phoenix Technologies Ltd. , 1991-1994 WEITEK Corp. -32 kB
  53. ATI Rage II 761295520 1996/12/04 15:49 ATI MACH64 GTB BIOS P/N 113-38204-102, (C) 1988-96, /3.033 -32 kB
  54. ATI Rage II+DVD 761295520 1997/08/29 10:08 ATI MACH64 BIOS P/N 113-38806-100 ,(C) 1988-97,/3.048 gthc1k.a1 6 MACH64GUPCIMTHPU - 32 kB
  55. ATI Rage Pro Turbo (SGRAM version) 761295520 1998/10/27 17:29 ATI MACH64 BIOS, (C) 1988-97, BK3.9.3/3.089 gtgpmc.c 6 - 32 kB
  56. ATI Rage XL 761295520 2000/01/20 10:26 ATI MACH64 SDRAM BIOS P/N GM-xls3p.hu-4.326, (C) 1988-1999, BK4.3.02/4.326 - 38 kB
  57. Number Nine Revolution IV -1998 -Version 3.06.00 , PCI AGP -66 RAM -8 -16 on 08/21/98 Number Nine Visual Technology Revolution IV T2R4 BIOS -32 kB
  58. ATI Rage 128 GL 761295520 1999/03/24 17:31 RAGE128 GL AGP P/N 113-61303-100,(C) 1988-98, BK1.0.12 VR001.001.001.012- 44 kB
  59. ATI Rage Pro Turbo AGP SGRAM 761295520 1998/06/03 11:16 ATI MACH64 BIOS P/N 113-40214-102 , (C) 1988-97, BK3.9.2/3.086 -32 kB
  60. SIS 6326 BIOS Ver 1.26 02/02/1999-09:35:03 SiS 6326 AGP True Color Graphics+Video Accelerator SiS 6326 PCI - 6 MB VRAM, BIOS Version 1.26 -32 kB
  61. Trident 8800CS 07/05/89 D4-129 000ë= MODE, 1988, 1989 TRIDENT MICROSYSTEMS INC. U3, 32 kB
  62. SPEA/V7 Vega Video Seven BIOS Code, Version 1.12 (C) Copyright 1987 Video Seven Inc., Updated: 03/26/88 ,BIOS Code- Version 1.12 - 32 kB
  63. SPEA/V7 Vega Video V7-VEGA VIDEO Bios Version 5.10 Copyright 1995, SPEA / VideoSeven,91-95, Avance & Quadtel Corp., 10/13/9009/13/95 -32 kB
  64. SPEA/V2 VEGA VGA Video Seven BIOS Code, Version 1.78 (C) 1987, Updated: 05/09/89 Video Seven BIOS Code, Version 1.78, 32 kB
  65. ATI VGA Wonder XL 761295520 1991/9/24 11:54 ATI VGAWONDER XL, BIOS P/N 11201122030, (C) 1988-91, ATI Technologies Inc., 32 kB
  66. S3 Virge GX ACER OPEN PT75 Video BIOS. Version 2.01.13B Copyright 1996 S3 Incorporated. 08/12/9709/15/97- 32 kB
  67. S3 Incorporated. ViRGE /DX /GX S3 Incorporated. ViRGE /DX /GX Rev B -32 kB
  68. S3 Virge VX miroCRYSTAL VR 4000 PCI Rev.2.00 10/01/96 -32 kB
    ----end of Elianda stuff---
  69. Radeon 3450 AGP 512M DDR2 Sapphire - 62 KB - reported by VBsize
  70. Geforce 6100 onboard - OEM ECS MB - 59 KB - Navratil
  71. Trident PCI 9440 1 MB - 32 KB - Navratil
  72. Radeon 4850 Asus - 64 KB - VBsize
  73. Geforce 6200 Turbocache - MSI - 59 KB VBsize
  74. Geforce 5600 AGP - 62 VBsize
Disruptor : Please remember that for UMB usage with EMM386 there is a 4 KB alignment, so 54/55 KB means 56 KB, 57/58/59+ Kb->60KB is reality etc.

Pleas report your cards and its Bios ROM sizes,vendor and exact name could matters too.

Todo /Question?:
1) Its possible to check DOS VBIOS size / Vendor / Cardname, in Windows and Linux? If yes how? I know that you can make dump, but its i hope there is cleaner way..
Elianda: Some video cards drivers replace the BIOS you have in Windows. So if you dump from Windows you get a different image. e.g. the driver for the DSystems Papilio G1-x cards does it. In Windows you have a BIOS that is fully VBE3.0 capable.
3) Its possible to show more Video card info in pure DOS, its somewhere in ROM? / PCI registers, i tried HWinfo etc.. but information are usually useless / wrong etc.. I interesting, in VRAM size, memory / clock speed, card chip, brand etc? => Navratil is able to do it for some cards, far some ideal, but its nice too.

There ismy Dos videocards performance thread, if care about it.

Too keep thread with reasonable # of posts, i would be nice: Post report - I will added card to my link creditcs include and delete report post, if is not contain other important info..
Last edited by ruthan on 2019-3-17 @ 14:03, edited 80 times in total.
Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough HW.
User avatar
ruthan
Oldbie
 
Posts: 1094
Joined: 2013-3-07 @ 04:01
Location: Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby ruthan » 2018-10-30 @ 04:09

I have moved this info to my DOS Video cards benchmarking sheet, its just one column:
https://docs.zoho.com/sheet/published.d ... de568c62b9
Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough HW.
User avatar
ruthan
Oldbie
 
Posts: 1094
Joined: 2013-3-07 @ 04:01
Location: Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby kjliew » 2018-10-30 @ 06:37

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:
Code: Select all
C:\>debug
-dc000:0
C000:0000  55 AA 4C .. .. .. ..

So the size is 76 * 512 bytes = 38,912 or 38KB.
kjliew
Member
 
Posts: 479
Joined: 2004-1-08 @ 03:03

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby MERCURY127 » 2018-10-30 @ 06:42

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.
MERCURY127
Member
 
Posts: 113
Joined: 2017-2-19 @ 16:38
Location: Russia

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby ruthan » 2018-10-30 @ 17:53

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?
Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough HW.
User avatar
ruthan
Oldbie
 
Posts: 1094
Joined: 2013-3-07 @ 04:01
Location: Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby MERCURY127 » 2018-10-31 @ 06:46

- 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.
MERCURY127
Member
 
Posts: 113
Joined: 2017-2-19 @ 16:38
Location: Russia

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby Falcosoft » 2018-10-31 @ 19:28

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:
VBSIZE.zip
(2.5 KiB) Downloaded 43 times
User avatar
Falcosoft
Oldbie
 
Posts: 906
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby ruthan » 2018-10-31 @ 20:11

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?
Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough HW.
User avatar
ruthan
Oldbie
 
Posts: 1094
Joined: 2013-3-07 @ 04:01
Location: Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby Falcosoft » 2018-10-31 @ 20:44

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
User avatar
Falcosoft
Oldbie
 
Posts: 906
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby ruthan » 2018-11-01 @ 04:12

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?
Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough HW.
User avatar
ruthan
Oldbie
 
Posts: 1094
Joined: 2013-3-07 @ 04:01
Location: Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby Falcosoft » 2018-11-01 @ 07:21

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):
MANDTEST.zip
(67.84 KiB) Downloaded 6 times

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.
User avatar
Falcosoft
Oldbie
 
Posts: 906
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby Disruptor » 2018-11-01 @ 20:26

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
Newbie
 
Posts: 83
Joined: 2018-3-22 @ 18:31

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby Falcosoft » 2018-11-01 @ 21:24

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...
User avatar
Falcosoft
Oldbie
 
Posts: 906
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby ruthan » 2018-11-02 @ 01:57

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.
CheckIt.jpg
Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough HW.
User avatar
ruthan
Oldbie
 
Posts: 1094
Joined: 2013-3-07 @ 04:01
Location: Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby ruthan » 2018-11-02 @ 03:00

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 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.
Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough HW.
User avatar
ruthan
Oldbie
 
Posts: 1094
Joined: 2013-3-07 @ 04:01
Location: Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby Falcosoft » 2018-11-02 @ 09:26

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.
checkit.jpg


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):
checkit2.jpg


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/p ... inters.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.
Last edited by Falcosoft on 2018-11-02 @ 14:14, edited 6 times in total.
User avatar
Falcosoft
Oldbie
 
Posts: 906
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby BinaryDemon » 2018-11-02 @ 10:35

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?
Check out DOSBox Distro:

https://sites.google.com/site/dosboxdistro/ [*]

a lightweight Linux distro (tinycore) which boots off a usb flash drive and goes straight to DOSBox.

Make your dos retrogaming experience portable!
BinaryDemon
Member
 
Posts: 377
Joined: 2018-1-17 @ 00:35

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby Falcosoft » 2018-11-02 @ 11:46

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.
User avatar
Falcosoft
Oldbie
 
Posts: 906
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby BinaryDemon » 2018-11-02 @ 12:45

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.
Check out DOSBox Distro:

https://sites.google.com/site/dosboxdistro/ [*]

a lightweight Linux distro (tinycore) which boots off a usb flash drive and goes straight to DOSBox.

Make your dos retrogaming experience portable!
BinaryDemon
Member
 
Posts: 377
Joined: 2018-1-17 @ 00:35

Re: Video bios(vBIOS) rom size research project for pure DOS, because there is smaller better.. Add our info.

Postby Baoran » 2018-11-02 @ 22:46

Inno3D TNT2 M64 PCI: 44Kb reported by NSSI
Baoran
Oldbie
 
Posts: 1466
Joined: 2017-4-01 @ 08:39
Location: Finland

Next

Return to Video

Who is online

Users browsing this forum: Caluser2000, xjas and 5 guests