[OpenBIOS] Loading a PCI Option rom.

[Programmingkid]

> On Dec 17, 2017, at 1:28 PM, Jd Lyons <lyons_dj at yahoo.com> wrote:
> 
> From what I remember, there are a bunch of properties, the most important is the NVDA,BMP that’s where the GPU and Memory Registers get written. There is a Strap, the NVStrap near the beginning of the Rom, and one part of the NVStrap sets up how the NVDA,BMP is read and written. The BMP is common between PC and FCode Option Roms, as is the strap. In the BMP there are a series of tables 0-7 and one offset of the strap determines what table gets loaded. It was a throwback to a program nVidia gave to it board partners. The NVStap Editor, I think it was called, it allowed them to use a reference Bios and plug in some values depending on how they deviated from the reference PCB. The NVStrap has and And/Or mask, So you can append the resistors on the PCB, or just read them as they are, and you can change the last byte of the Device ID.
> 
> So if one of there board partners used some cheap memory they could get a ready supply of, they could just plug the memory specs into the BMP Editor and set the Soft Strap(NVStrap) without the need to make a new Bios in assembly.
> 
> We got lucky, and they used the BMP in the Fcode Rom too, and that allowed us to figure out how to edit it to flash PC cards for use in PPC systems.
> 
> There is a GPU check in the Fcode rom too, so you have to bypass that check, if you want to use a GPU the Rom wasn’t made for. This is how we made the Geforce 6200 Rom from the Apple OEM Geforce 6600 Rom.

Thank you for the info. You know a lot of Nvidia cards. Still there is the exception that we see when executing the card's Fcode. Finding out what is causing the exception would be very helpful. Were there any values in the stack that might mean anything when the exception happened? Did you see any other messages? The serial console may have something printed there. 

I found the definition to byte-load in the forth/device/feval.fs file. This is part of it:

: byte-load ( addr xt -- )
  ?fcode-verbose if
    cr ." byte-load: evaluating fcode at 0x" over . cr
  then

  \ save state
  >r >r fcode-push-state r> r>

  \ set fcode-c@ defer
  dup 1 = if drop ['] c@ then      \ FIXME: uses c@ rather than rb@ for now...
  to fcode-c@
  dup to fcode-stream-start
  to fcode-stream
  1 to fcode-spread
  false to ?fcode-offset16 
  alloc-fcode-table
  false fcode-end !
  
  \ protect against stack overflow/underflow
  0 0 0 0 0 0 depth >r
  
  ['] (feval) catch if
    cr ." byte-load: exception caught!" cr
  then

You see the message "exception caught!" takes place because the (feval) word has a problem with something. 

Looking at the (feval) word I see it has a (debug-feval) word that might be helpful. This word is also located in the feval.fs file. As an experiment could you set the ?fcode-verbose to true when running QEMU? I think this QEMU option would help: -prom-env ?fcode-verbose=true

If this doesn't work, then maybe we should redefine the " word to print out what it finds to the serial console. That might tell us what is wrong.