Hello. I followed the question about writing or not bios for ELKS's target machines but to me this appear like a Reinventing-the-wheel job. Why don't left this work only for strange HardWare like s.b.c. or some sort of old computers? i think that could be enough, for this kind of hardware, to write a kind of miniBIOS, a reduced BIOS set containing only effectively used functions leaving all the remaining stuff apart because this work must be done by the manufacturer of the hardware or someone that know very well the HW. Hope this could help. Alessio Morale [EMAIL PROTECTED]
---------- > Van: Dan Olson <[EMAIL PROTECTED]> > Aan: Diversia <[EMAIL PROTECTED]> > CC: Linux 8086 Mailinglist <[EMAIL PROTECTED]> > Onderwerp: Re: NanoX version 0.3 released (Pretty much off-topic) > Datum: vrijdag 14 mei 1999 1:54 > > > > I don't think you understand, the whole point of having a BIOS file is > > > because different systems *aren't* the same, instead of having to > > re-write > > > or re-compile the OS for each system, a BIOS file is used instead which > > > has the correct information for that given system. Like you said, all > > > C128s were the same, so there was one BIOS for them, but they are > > > different from the TRS-80 model IV, which has a different BIOS, which is > > > different from a Kaypro, which has a different BIOS, etc. I suspect that > > > with ELKs, a macine with a ROM BIOS could somehow have a file that made > > > use of that BIOS instead of starting from scratch. I would also think > > > that any machine that's hardware compatable with an IBM could more or > > less > > > use the same BIOS file, I believe the issue is simple what hardware > > > addresses to use for different things, right? > > > > > > Dan > > > > > > > I think I DO understand. A BIOS is writting specificly for one and only one > > chipset type. > > I thought you mis-understood me as saying that one identical BIOS was used > by all machines, where that's not the case. > > > So using a bios for a chipset XXX on a chipset YYY system would seriously > > damage your whole system (if it would even boot(what it won't do)). > > I don't know if it would damage hardware, but you're right in that it'd be > a bad idea and probably wouldn't even boot. > > And you > > don't have to re-write/compile ELKs to run on different systems. My > > bootfloppy works on my system (a commodore 286) and my friends a Tulip > > XT-III. > > I think it's safe to assume that it boots on these different systems > because a) they are 100% IBM compatable, b) Elks is using the bios instead > of direct hardware access on the machines, or probably c) a combination of > both. The origional message was regarding accessing video driectly > instead of using a driver, which may cause a problem on a machine which is > not truly IBM compatable, and especially if that machine has no BIOS (ie > embeded). You said you were new to the list, right? If so, you probably > missed messages that were here a while ago stating that ELKs won't > correctly run on the IBM PCjr and Tandy 1000, because they aren't > compatable with the IBM PC and I believe that video memory was getting > trashed...if I remember right. My whole point in suggesting the BIOS as a > file was simply to allow ELKs to run on any machine that was 8088 > compatable, regardless of IBM compatability, and regardless of a ROM BIOS > being present. Maybe that's not the best answer, but it's just a > suggestion to think about. > > Dan I'm on this list since 25 May, I guess those messages where before that date. I'm pretty sure that a rom bios file is not THE answers to let ELKs run on IBM PCjr, Tandy 1000 because those systems, even though they aren't IBM Compatible, still use chipsets and stuff. And AFAIK a BIOS, like I said before, is specific for one and only one chipset. And I think the answer is writing a video driver for every different type of system. You could make a tiny framebuffer like thingie in the kernel and than every program who want's to make use of it send an IOCTL to the kernel that other programs will not be allowed for now. Then the kernel could make the transistion from framebuffer to the current video type in the system (Tandy, PCjr, VGA, EGA, etc). Than you wouldn't have to write a complete INT 10 driver in the NanoX program, but only in the kernel and it would be pretty universal because everybody would be so generous to write their own driver for their kind of videocard. At least, I would (try). Erik Smit
