On Sun, Jan 09, 2011 at 02:10:51PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Sat, Jan 08, 2011 at 01:48:00PM +0100, Sebastian Herbszt wrote:
> >>Kevin O'Connor wrote:
> >>>On Thu, Jan 06, 2011 at 04:24:13PM +0200, Gleb Natapov wrote:
> >>>>On Thu, Jan 06, 2011 at 09:00:00AM -0500, Kevin O'Connor wrote:
> >>>>> On Thu, Jan 06, 2011 at 03:53:57PM +0200, Gleb Natapov wrote:
> >>>>> > On Thu, Jan 06, 2011 at 08:41:11AM -0500, Kevin O'Connor wrote:
> >>>>> > > On Thu, Jan 06, 2011 at 07:09:27AM +0200, Gleb Natapov wrote:
> >>>>> > > > On Wed, Jan 05, 2011 at 09:32:33PM -0500, Kevin O'Connor wrote:
> >>>>> > > > > > - SET_INT13DPT(regs, host_bus[3], 0);
> >>>>> > > > > > + SET_INT13DPT(regs, host_bus[3], ' ');
> >>>>> > > > > > > > > > What if we're not in t13 mode? Should this
> >>>>be:
> >>>>> > > > > u8 fillchar = t13 ? ' ' : 0;
> >>>>> > > > > SET_INT13DPT(regs, host_bus[3], fillchar);
> >>>>> > > > > > > > > Phoenix does not specify padding. Are you sure
> >>>>phoenix has to have zero
> >>>>> > > > padding?
> >>>>> > > > > > I think RBIL documented 0s. It may not be
> >>>>important.
> >>>>> > > > > What is RBIL?
> >>>>> > Sorry - Ralph Brown's interrupt list:
> >>>>> > http://www.cs.cmu.edu/~ralf/files.html
> >>>>> Ah, I have it, just didn't know it is called RBIL :).
> >>>>
> >>>>Do you want me to resend with fillchar = t13 ? ' ' : 0; or space should
> >>>>be good enough?
> >>>
> >>>I just tested winxp, and it doesn't seem to call 1348 with a size
> >>>bigger than 26 bytes. So, thinking about it further, I'm not sure it
> >>>matters - the spec isn't clear and I don't know of anything that would
> >>>care. (To be clear, I think we should support the 66 byte buffer
> >>>size, however I'm not sure the padding matters.)
> >>>
> >>>Sebastian - do you know of anything that calls 1348 with a buffer size
> >>>that could observe the difference?
> >>
> >>I think syslinux and FreeDOS call 1348 - will check their buffers later.
> >>
> >>I have tested 1348 on VMware Player 3.0.0 build-203739. It runs
> >>PhoenixBIOS 4.0 Release 6.0, VMware BIOS build 314. Results:
> >>Input Buffer length -> Output Buffer length
> >>1a -> 1a
> >>1e -> 1e
> >>42 -> 1e (looks like it doesn't support 42!)
> >>4a -> 4a (wrong output buffer length, should be 1e; uses space padding)
> >>
> >>Will do more tests later.
> >>
> >RBIL mention that: Dell machines using PhoenixBIOS 4.0 Release 6.0
> >fail to correctly
> >handle this function if the flag word at DS:[SI+2] is not 0000h on
> >entry
> >Make sure to have it set to zero in you testing. May be VMware's
> >build has the same problem.
>
> I cleared the buffer on each test. Here are the resulting buffers:
>
> 1a
> 00: 1a 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00
> 10: 00 00 40 01 00 00 00 00 - 00 02 -- -- -- -- -- --
>
> 1e
> 00: 1e 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00
> 10: 00 00 40 01 00 00 00 00 - 00 02 c6 00 40 00 -- --
>
> 42
> 00: 1e 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00
> 10: 00 00 40 01 00 00 00 00 - 00 02 c6 00 40 00 -- --
>
> 4a
> 00: 4a 00 01 00 ff 3f 00 00 - 0f 00 00 00 3f 00 00 00
> 10: 00 00 40 01 00 00 00 00 - 00 02 c6 00 40 00 dd be
> 20: 2c 00 00 00 50 43 49 20 - 41 54 41 20 20 20 20 20
> 30: 00 07 01 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> 40: 00 00 00 00 00 00 00 00 - 00 bf -- -- -- -- -- --
>
So what about making Seabios to pad with spaces too?
--
Gleb.
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
