DOS ain't dead

Graphic Vision File Manager 2.65 | "A"-bug (Announce)

posted by jaybur  , UK, 22.12.2007, 21:18

> > And this kernel contains a bug fix for 21h/29xx - Parse Filename into FCB
> > means that GVFM no longer thinks that every drive up to LASTDRIVE is valid
>
> Confirm



> > New video memory write speed test added to the "Change Video Mode" dialog.
>
> Funny colourful garbage

Oh! Well it does do some timings, then just paints a load of colourful filled rectangles on the screen to (essentially) test the video memory write speed. Did it complete and give you a summary in a dialogue box?

> but I have no clue why you test the bankswitch time for the LFB - is it
> related to your 16-bit DPMI?

Yes, it's a pseudo bank-switch. Since GVFM can only access 64k in one chunk, An LFB mode maps as many 64k selectors to the video memory as is required for that mode, then a "bank-switch" is simply a case of working out which selector is required (either from a cartesian co-ordinate or from a linear 32-bit offset).

> > VESAMTRR can improve graphics throughput by as much as 50 times
>
> Should be 5 only ?

Nope. GVFM can write to my AMD6400X2/nVidia 7600 GT at over 2.6GB/s using an LFB mode, but only at about 52MB/s with the same mode, but using banked access!

> > MACHINES WITH PENTIUM 1 OR OLDER PROCESSORS DO NOT NEED AND SHOULD NOT
> > USE IT.
>
> No big danger, NO NEED FOR ALL UPPERCASE - maybe "VESAMTRR (or any
> other product with same goal) won't work with Pentium 1 or older
> processors.

Ok.

> Complaining again - I've not yet seen a DPMI host that would be
> that evil to run itself outside of Ring0

True.

> - maybe "VESAMTRR is a 32-bit DPMI application and needs access to Ring0 via
> an IDT gate, and requires an appropriate DPMI host like HDPMI32 to run."

Fair enough.

> > \DOS\DRIVERS\VIDEO\VESAMTRR -c=A000-BFFF
>
> Your path ?

No, just a suggestion.

> maybe "VESAMTRR is not a TSR and so will not take up any memory once it
> has done its thing (change special resisters inside the CPU)."

Hmm, 6-of-1, half a dozen of the other.

> add "replacing "FASTVID" product distributed with GVFM in the past." ?
>

FastVid and GVFM is history that'll soon be forgotten or not known.

> The "A"-bug persists with new GVFM and new kernel. Anyway, I got
> additionally a "Runtime error 216 at C7:969D" followed by a GPF in Ring0



RTE 216 is a GPF, but C7:969D is not a valid GVFM address (C7 is way too high).

> It's pretty random whether the floppy access gives up silently after some
> time, complains about "Drive A is not ready" (it's still on the ban list,
> BTW), or aborts with error 216 and boom.

Okay. Test version and full source coming your way soon...

Complete thread:

• Graphic Vision File Manager 2.65 - jaybur, 22.12.2007, 19:21 (Announce)
  • Graphic Vision File Manager 2.65 | "A"-bug - DOS386, 22.12.2007, 20:52
    • Graphic Vision File Manager 2.65 | "A"-bug - jaybur, 22.12.2007, 21:18
      • Graphic Vision File Manager 2.65 | "A"-bug - DOS386, 22.12.2007, 21:41
        • Graphic Vision File Manager 2.65 | "A"-bug - jaybur, 22.12.2007, 21:56
    • Graphic Vision File Manager 2.65 | "A"-bug - Steve, 23.12.2007, 04:58
    • GVFM 2.65 | "A"-bug | FreeDOS "Sep. 15" kernel - Rugxulo, 24.12.2007, 14:32
      • GVFM 2.65 | "A"-bug | FreeDOS "Sep. 15" kernel - jaybur, 26.12.2007, 17:16
  • GVFM 2.66 beta /"Drive A" bug - jaybur, 26.12.2007, 17:42
    • GVFM 2.66 beta / "Drive A" bug / DEC CX LOOP @b - DOS386, 26.12.2007, 22:36
    • GVFM 2.66 beta /"Drive A" bug - Laaca, 27.12.2007, 23:04
      • GVFM 2.66 beta /"Drive A" bug - jaybur, 28.12.2007, 03:47
      • GVFM 2.66 beta /"Drive A" bug - jaybur, 28.12.2007, 05:27
        • GVFM 2.66 beta /"Drive A" bug - Laaca, 28.12.2007, 17:15
          • GVFM 2.66 beta /"Drive A" bug - jaybur, 28.12.2007, 18:56