OSDev.org

lol, all the claims that i saw in the patent required it be Microsoft Windows NT Operating System for it to be that patent, if i read that correctly.

Hi,

CompDever wrote:lol, all the claims that i saw in the patent required it be Microsoft Windows NT Operating System for it to be that patent, if i read that correctly.

Unfortunately patents are rarely restricted to their original "invention". From the second to last paragraph in the patent:

MODIFICATIONS AND VARIATIONS

As will be recognized by those skilled in the art, the innovative concepts described in the present application can be modified and varied over a tremendous range of applications, and accordingly the scope of patented subject matter is not limited by any of the specific exemplary teachings given.

As far as I can tell the patent has a total of 15 seperate claims where you could infringe one or more claims.

This means that if you try to do the same thing with a different OS you'd be infringing on all the claims except for claim 3 and claim 8. That works out to 13 infringments instead of 15 (where one infringement is enough for them to take action).

It also means you can make up your own CPU with a 128-bit mode and an 8-bit mode, and then use their method (described in claim 1) to run 8-bit interrupts from 128-bit mode, and they can still take action because you've infringed claim 1 (even though you didn't infringe most of the other claims).


Cheers,

Brendan

pcmattman wrote: You drop back to real mode or create a virtual mode task so that you can use int 10h.

That's pretty much the only way to get into a mode without writing a video card driver - which is what Kevin McGuire has posted (his is a very portable one, though).

<edit>
Opps. I just read back over what you said and it made more sense. You were saying that _is_ what I did not that writing a driver is just a alternative. My mistake.
</edit>

Actually, the code I posted does not drop into real mode. Dropping into real mode and using the VESA extension should be a better bet, _because_ of the complexity of doing it entirely with port I/O and the fact that my driver code above is buggy. It does not correctly setup some of the CRT registers, and most likely one or two other things.

Then again a even _better_ method would be to use the VESA extensions to change the video mode then dump all the VGA registers and correct my mode lines above _and_ add new ones. That should give you the ability to use VGA and possibly SVGA modes with out using VESA. That sounds good, right?

I think that patent is describing something else than just switching into VM86 mode and calling a BIOS function.

It appears that this will require a modification to a BIOS to be supported.

The preferred method passes the interrupt request to a 32 Bit protected mode driver. The driver will construct the 16 Bit call, change the stack to a 16 Bit stack, and make the 16 Bit protected mode BIOS call. This process is much faster than the previous method. Because there is no mode switch (Thunk) from protected to real and from real back to protected mode, the process of making the ROM call is not noticeable. Also, this process only requires that the BIOS write 16-bit mode code that is capable of running in real or protected mode. This is accomplished by not hard-coding F000h as a data segment/selector. There is no need to re-code BIOS to support 32 Bit calls, which saves space and time.

The only way I know to do this is to create a sixteen bit code and stack segment and perform a jump or interrupt return into it. The problem is you are still using descriptors, right? Is that not what he notes as a requirement for the BIOS?

He specifically says it is a alternative to switching into real mode and back to protected mode. Apparently, he wants to just execute sixteen bit code while still working in protected mode.

Hi,

Kevin McGuire wrote:Then again a even _better_ method would be to use the VESA extensions to change the video mode then dump all the VGA registers and correct my mode lines above _and_ add new ones. That should give you the ability to use VGA and possibly SVGA modes with out using VESA. That sounds good, right?

I've been thinking a little about this...

An even better method might be to use V86 mode to create a complete log of all I/O port accesses that the video card's ROM does, and then use that as a generic tool to help reverse engineer any video card, so that native drivers can be written for SVGA cards with the same functionality as the video card's ROM.

This won't necessarily work for all video cards (for e.g. if the video code memory maps registers to display memory and accesses registers using memory read/write instructions), but I'd guess that most video card ROMs don't do this sort of thing...

BTW a dedicated group of operating system developers could potentially create such a tool, and then build an archive of "video card I/O port access logs", with notes and comments manually inserted into the logs for others - for example "This is looping until bit X becomes set here!"....


Cheers,

Brendan

Kevin McGuire wrote: He specifically says it is a alternative to switching into real mode and back to protected mode. Apparently, he wants to just execute sixteen bit code while still working in protected mode.

That why i put you will be OK, going to and from realmode for BIOS int's .

This is the second time in a week, that i have googled for info and a patent like this as come up .

[EDIT] Sounds like a cool idea Brendan

I suggested that one time for the BCM43xx wireless driver.

A Couple Of Internet Mails wrote: On Sunday 04 February 2007 23:10, Leonard McGuire wrote:
> > Michael Wrote:
>>> > >>If you'd like to compare millions of IO accesses, nobody stops you
> > from comparing them. There is no reverse engineering needed to compare
> > IO accesses.
> >
> > Only so many should be sent to the BCM device, during initialization.
> > I would not think it would be in the millions for the initialization.
> > There is also got to be a way to determine what type of command/write
> > was performed such as a lot of initialization writes/reads should be
> > done to a certain control port for the driver, while many others for
> > normal activity would be done to the DMA and other ports for the bcm
> > device. I guess I am just wondering about the millions part, lol.
> > Even certain writes would have a command prepended right? Mabye we are
> > just sending a different flag somewhere, that might be detected by
> > comparason..

There are lots of "maybe"s in your statement.
How about reading the code? It will answer all your questions.

And yes, I didn't count the MMIO accesses, but it is a _lot_.
If you want to compare them, go for it. Nobody else will, as it's
too much work. This effort is better put into actually reading,
understanding and fixing the code.

-- Greetings Michael.

The common SVGA and VGA graphics card I would imagine should be simpler so maybe it would not be the same situation. It still requires a lot of work.

-- Also it might be interesting just to decode the ROM instructions from sixteen bit to thirty-two bit instructions, almost like some people have done with writing a emulator for sixteen bit code I think?

While we are on the subject of patents... why don't we patent the use of
times 512-($-$$)-2 db 0
dw 0xAA55
at the end of a bootloader? lol! you see, those are the kind of ridiculous things being patented today. We need some good patents, not taking credit for something everybody else already knows about. (p.s. don't actually try to get that patented, if it did happen: that would be about the dumbest thing yet.)

Hi,

Kevin McGuire wrote:I suggested that one time for the BCM43xx wireless driver.

It's not necessarily a new idea...

Kevin McGuire wrote:The common SVGA and VGA graphics card I would imagine should be simpler so maybe it would not be the same situation. It still requires a lot of work.

I'm thinking it wouldn't be that hard.

I'd probably start with something like FreeDOS (file system access without any protection in the way), then write a utility that accepts an interrupt number and register values as command line parameters, initialises protected mode, sets up a V86 interrupt call, logs I/O port accesses to a RAM buffer while the BIOS/ROM does it's thing, then writes the data from the buffer in RAM to a file.

Once you've got the raw data a second utility could parse the data and generate some human readable output. This second utility could be written in something like C, and different people could write their own parsers to generate output in whatever format suits them. With a little work it may even be possible to auto-generate code for initializing the card, doing video mode switches and bank switching. It's easy to find out what most VGA registers are for and generate sane comments and "#define's" to make the code more readable. It also shouldn't be too hard to autodetect some/most loops, so that the resulting code doesn't need as much hand-tuning. For a standard VGA card, I can't think of any reason why it couldn't work perfectly. For old SVGA cards I'd be surprised if it didn't work.

For the more modern video cards you'd have a greater chance of memory mapped I/O being used, and there's another problem with detecting monitor capabilities (some video cards would check if the monitor supports a certain video mode before allowing it to be used). Despite this, even auto-generated code that doesn't work can be a major advantage if you're trying to write a native video card driver - it reduces the (large) amount of work you need to do manually and gives you a good starting point.

Of course once you've got a basic native driver to work you can start adding support for things that VBE doesn't do, like hardware cursors, 2D and 3D acceleration, page flipping, etc - it'd give you something to improve on, and make it easy to go beyond what other techniques (e.g. using real mode or V86 mode) are capable of.

Kevin McGuire wrote:-- Also it might be interesting just to decode the ROM instructions from sixteen bit to thirty-two bit instructions, almost like some people have done with writing a emulator for sixteen bit code I think?

In this case you could just disassemble the 16-bit code, process it, and assemble it as 32-bit code. The problem here is detecting what is useful code and what isn't. For example, you wouldn't know if bytes are useful 16-bit code, 16-bit code that's only used for legacy purposes (e.g. text output functions), font data, or some other type of data. To avoid this you'd need to follow code paths like the CPU would - start at an entry point and emulate calls, branches, jumps, etc. It'd be very hard to get good results (almost like writing a full emulator).


Cheers,

Brendan

@Brendan, I have only ?, how will you log I/O port accesses ? .

well you can load the program in bochs and log the IO accesses there?

for linux well add a hook in the kernel or something?

in your own os well don't allow IO accesses and handle the exception and emulate the IO access or maybe forward on kernel level.

Thanks os64dev, but i was meaning from a using FreeDos on a real PC, point of view.

So are we going to continue discussing thread off-topic material, or the construction of a simple VGA Graphics Interface?

Hi,

Dex wrote:@Brendan, I have only ?, how will you log I/O port accesses ? .

I was thinking of using V86 with IOPL = 3, so that any I/O port accesses cause a general protection fault. The general protection fault handler can emulate the I/O port instructions easily enough - there isn't many of them, most use implied registers, and it'd be simple to log details (which I/O port, the access size and the data read/written) at the same time.

I'd also want to use paging - that way you could make it look the video card's ROM is mapped at 0x000C0000 as "read/write" without messing about with the chipset. That would mean you could execute the ROM's "power-on" initialization code and log it (PCI device ROMs expect the ROM shadow area to be read/write).

As a bonus, with a little messing about with PCI configuration space you'd also be able to handle computers with more than one video card. You'd need to shift the main video card out the way (change it's base I/O port region and display memory mapping using it's BARs, so there's no resource conflicts but it still works as a frame buffer), and then setup paging to make it look like the second, third or fourth video card's ROM is mapped at 0x000C0000.


Cheers,

Brendan

I think this idea sounds interesting, perhaps a joint "research" project should be formed.. lol