> > > We're not going to add a microcontroller to the board. Do
> > > you expect BIOS code to take over and present a configuration tool via
> > > serial?
> >
> > I was thinking the configuration tool would be a Unix utility?
>
> Oh! Are you saying that you want to fully boot into the OS without a
> working console,
No.
> and have the serial port on the card act as a system
> console?
Yes.
I am hoping that the OGC card can route messages from the mainboard
firmware to the OGC card's rs-232 port. That way you have a working
console, which is useful for booting an OS (which device to boot from,
what file to boot, what flags to add). From what I've been reading,
the LinuxBIOS people would find this useful as well.
> Is this just to cater to systems that cannot function with no graphics card?
That is the main reason, but the port would have other uses as well.
I listed some of the uses an rs-232 port would have a day or two ago.
> And let's say the graphics card boots with an unusable video mode.
> Why is our serial port any better than the one built into the host
> computer? That can be a console as well.
BSD and Linux can use a builtin rs-232 port as the console. But if the
mainboard firmware does not use a builtin rs-232 port as the console,
then it would be very difficult to get that OS booted. Even if the
mainboard firmware does allow using a builtin rs-232 port as the console,
some do not default to sending messages there. Blindly typing things
is very dangerous. You have to find out exactly what to type, and that
might vary with firmware revision. How do you know what firmware revision
you have if you can't see the messages from the firmware? If a key bounces
you could get into a menu for overclocking and create a doorstop.
> > But you don't have to have a terminal with a rs-232 port. You could
> > have a laptop with a native rs-232 port, or a USB port and a USB to
> > rs-232 adapter and a terminal emulator program, typically called
> > cu or tip.
>
> While it's not unreasonable to expect someone to have a laptop, what's
> more likely they'll have lying around? A VGA monitor or a laptop?
People that have fixed freq monitors are more likely to have a laptop,
or a terminal with a rs-232 port, or some other device that can talk
to rs-232 than they are to have a multisync monitor.
> I'm not trying to be argumentative.
And for the record neither am I. And, once again, I'm trying to think
of what is best overall, not merely what is most convienant for me.
> I'm just saying that for every
> instance, we're requiring the user to have SOME sort of extra piece of
> equipment.
Yes. As I said yesterday, the jumper/switch solution is very nice because
the end-user can set the video mode without any extra hardware. Some
end-users will not have a multisync monitor. Some end-users will not have
anything that can talk to rs-232. Some end-users will not have a tv.
Another nice feature of the jumper/switch solution is that you can look
at the board and know what mode it will power up into.
Does anyone know where there is a complete list of video modes? If we had
a complete list, I suspect that the number of jumpers needed would be
reasonable. The problem is that if we don't have a complete list, *and*
if we decide that we want to allow setting every possible mode via jumpers,
then the number of jumpers required is pretty high, even with an efficient
encoding. Which uses up a fair amount of board real estate, and makes you
go blind counting pins when you set the jumpers. The hex-digit SCSI-ID
switches would be more user-friendly, but I suspect they cost more.
Here is a list of solutions, have I missed any?
jumpers, dip-switches, hex (SCSI-ID) switches
rs-232
multisync monitor
tv
bootable program that sets mode
a second computer with an open PCI slot
pins/connector with some low level hardware interface plus a
custom daughter board with jumpers/switches/PROM/whatever
Note that the multisync monitor is not really a complete solution. Once
you program the OGC board for a fixed-freq monitor, if that monitor then
dies, the multisync monitor might not handle that mode. And might die
if you drive it with that mode. (Yes, I have seen this happen.)
So maybe we need a jumper to select between multi-sync and the mode
programmed in nvram.
The custom daughter board would be fine for a company developing a
lottery ticket kiosk, but not for an end-user. I suspect that a
company developing a lottery ticket kiosk will have some way to
program a nvram/prom device, so they might not need the custom
daughter board.
The bootable program is appealing, but probably impractical.
Adding a new type of board to a working computer is not without
risks. You can hit an obscure firmware bug and very very bad things
can result. Even on a system with firmware that is very high quality.
(Yes, I have seen this happen.)
If we allow rs-232 and tv and multisync monitor and second computer,
together that should be sufficient.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
