Forth interpreter?

[Jd Lyons]

Does OB support a forth interpreter?

When I try and load one with the boot command it seems to treat it as a :tbxi and I just get the no valid init file.

\ comment

cr

hex

00000000 encode-int " fcode-rom-offset" property
" scsi" encode-string " device-type" property
" UltraTek133" encode-string " name" property
" UltraTek133" encode-string " compatible" property
" 3.5.0" encode-bytes " Rom#" property
" 3.5.0" encode-string " rom-revision" property	
" UltraTek133"	encode-string " release" property
" PDC20269" encode-string " model" property
" UltraTek Firmware by FirmTek LLC, 2001. You may not alter or reverse engineer this product" \ encode-bytes " Copyright" property
" Authors: Nguyen Kim Chi, Rath Gyoergy." encode-bytes " authors" property
" Szerzoek: Nguyen Kim Chi, Rath Gyoergy." encode-bytes " Szerzoek" \ property
" 10/23/02" encode-string " release-date" property
" 12:33.03" encode-string " release-time" property
0000AD69 encode-int " subsystem-id" property
" SLOT-5" encode-string " AAPL,slot-name” property

The \ comment should trigger the forth interpreter, but that doesn’t seem to work with OpenBios.

Also, how does Openbios handle Fcode ROM’s that use compression?

The FCode probably has some compression and therefore loads itself in two different steps.
The first step is something like this:

Code:
hex
tokenizer[ 0000 ]tokenizer set-rev-level
tokenizer[ 004A ]tokenizer pci-architecture
tokenizer[ 002A ]tokenizer pci-data-structure-start
tokenizer[ 0020 ]tokenizer pci-data-structure-length
tokenizer[ 105A 4D69 018085 ]tokenizer pci-header
tokenizer[ 10000 ]tokenizer rom-size
fcode-version2
\ format:    0x08
\ checksum:  0x72c0 (ok)
\ len:       0xfd1a (64794 bytes)
hex
headerless
variable variable_800															\ (800)
…
variable variable_816															\ (816)
: colon_l!													\ (817)
: colon_l@													\ (818)
: colon_variable_805_l@													\ (819)
: colon_variable_804_l@													\ (81a)
: colon_definition_function_81b													\ (81b)
…
: colon_definition_function_822													\ (822)
: colon_variable_80a_l!													\ (823)
: colon_definition_function_824													\ (824)
…
: colon_definition_function_83f													\ (83f)

" "(…)" \ 252 bytes
encode-bytes

" "(…)" \ 252 bytes
encode-bytes
encode+

…

" "(…)" \ < 252 bytes
encode-bytes
encode+

" driver,FirmTek,MacOS,PowerPC"
property
colon_definition_function_83f													\ (83f)
colon_definition_function_824													\ (824)
['] c@
byte-load
fcode-end
pci-end

" driver,FirmTek,MacOS,PowerPC" is a property that's ≈ 61K bytes. Some stuff is done with this (colon_definition_function_83f), then it calls byte-load on the result which means there's more FCode in the result.

colon_definition_function_83f is like this:
Code:
: colon_definition_function_83f													\ (83f)
    " driver,FirmTek,MacOS,PowerPC"
    colon_definition_function_83e												\ (83e)
    0=
    if																			\ (0x5)
    	2drop
    	exit
    then
    get-package-property
    if																			\ (0x4)
    	exit
    then
    drop
    dup
    colon_l@												\ (818)
    dup
    0
    <>
    if																			\ (0x56)
    	colon_variable_80a_l!											\ (823)
    	4
    	+
    	colon_variable_809_l!											\ (821)
    	" create driver-buffer"
    	evaluate
    	colon_variable_80a_l@											\ (822)
    	allot
    	" driver-buffer"
    	evaluate
    	colon_variable_80b_l!											\ (825)
    	colon_variable_80b_l@											\ (824)
    	0
    	<>
    	if																		\ (0xb)
    		colon_variable_80b_l@										\ (824)
    		colon_variable_80a_l@										\ (822)
    		erase
    		colon_definition_function_83d										\ (83d)
    	then
    else																		\ (0x5)
    	2drop
    then
    " driver,FirmTek,MacOS,PowerPC"
    delete-property
    ;

colon_definition_function_83d is maybe the decompression function.

I have a PC Promise ATA 133 card that by all looks is identical to the one used by Sonnet Tech in the Tempo ATA 133 line, however there exists no tool for flashing the Mac Fcode ROM to the card sans the Sonnet Flashing tool that won’t recognize a PC Card.

I tried using PCI-Passthough to Qemu-System-PPC to load the Fcode ROM from a  file in OpenBios, but the compressed part of the ROM doesn’t seem to work correct in OpenBios.

load hd:,\ppc\fwata3.bin
“  /pci/@e” open-dev to my-self
400004a 1 byte-load

[Mark Cave-Ayland]

On 24/01/2022 06:33, Jd Lyons via OpenBIOS wrote:
> Does OB support a forth interpreter?
>
> When I try and load one with the boot command it seems to treat it as a :tbxi and I 
> just get the no valid init file.
>
> \ comment
>
> cr
>
> hex
>
> 00000000 encode-int " fcode-rom-offset" property
> " scsi" encode-string " device-type" property
> " UltraTek133" encode-string " name" property
> " UltraTek133" encode-string " compatible" property
> " 3.5.0" encode-bytes " Rom#" property
> " 3.5.0" encode-string " rom-revision" property
> " UltraTek133"encode-string " release" property
> " PDC20269" encode-string " model" property
> " UltraTek Firmware by FirmTek LLC, 2001. You may not alter or reverse engineer this 
> product" \ encode-bytes " Copyright" property
> " Authors: Nguyen Kim Chi, Rath Gyoergy." encode-bytes " authors" property
> " Szerzoek: Nguyen Kim Chi, Rath Gyoergy." encode-bytes " Szerzoek" \ property
> " 10/23/02" encode-string " release-date" property
> " 12:33.03" encode-string " release-time" property
> 0000AD69 encode-int " subsystem-id" property
> " SLOT-5" encode-string " AAPL,slot-name” property
>
> The \ comment should trigger the forth interpreter, but that doesn’t seem to work 
> with OpenBios.
>
> Also, how does Openbios handle Fcode ROM’s that use compression?
>
> The FCode probably has some compression and therefore loads itself in two different 
> steps.
> The first step is something like this:
>
> Code:
>
> |hex tokenizer[ 0000 ]tokenizer set-rev-level tokenizer[ 004A ]tokenizer 
> pci-architecture tokenizer[ 002A ]tokenizer pci-data-structure-start tokenizer[ 0020 
> ]tokenizer pci-data-structure-length tokenizer[ 105A 4D69 018085 ]tokenizer 
> pci-header tokenizer[ 10000 ]tokenizer rom-size fcode-version2 \ format: 0x08 \ 
> checksum: 0x72c0 (ok) \ len: 0xfd1a (64794 bytes) hex headerless variable 
> variable_800 \ (800) … variable variable_816 \ (816) : colon_l! \ (817) : colon_l@ \ 
> (818) : colon_variable_805_l@ \ (819) : colon_variable_804_l@ \ (81a) : 
> colon_definition_function_81b \ (81b) … : colon_definition_function_822 \ (822) : 
> colon_variable_80a_l! \ (823) : colon_definition_function_824 \ (824) … : 
> colon_definition_function_83f \ (83f) " "(…)" \ 252 bytes encode-bytes " "(…)" \ 252 
> bytes encode-bytes encode+ … " "(…)" \ < 252 bytes encode-bytes encode+ " 
> driver,FirmTek,MacOS,PowerPC" property colon_definition_function_83f \ (83f) 
> colon_definition_function_824 \ (824) ['] c@ byte-load fcode-end pci-end|
>
> " driver,FirmTek,MacOS,PowerPC" is a property that's ≈ 61K bytes. Some stuff is done 
> with this (colon_definition_function_83f), then it calls byte-load on the result 
> which means there's more FCode in the result.
>
> colon_definition_function_83f is like this:
> Code:
>
> |: colon_definition_function_83f \ (83f) " driver,FirmTek,MacOS,PowerPC" 
> colon_definition_function_83e \ (83e) 0= if \ (0x5) 2drop exit then 
> get-package-property if \ (0x4) exit then drop dup colon_l@ \ (818) dup 0 <> if \ 
> (0x56) colon_variable_80a_l! \ (823) 4 + colon_variable_809_l! \ (821) " create 
> driver-buffer" evaluate colon_variable_80a_l@ \ (822) allot " driver-buffer" evaluate 
> colon_variable_80b_l! \ (825) colon_variable_80b_l@ \ (824) 0 <> if \ (0xb) 
> colon_variable_80b_l@ \ (824) colon_variable_80a_l@ \ (822) erase 
> colon_definition_function_83d \ (83d) then else \ (0x5) 2drop then " 
> driver,FirmTek,MacOS,PowerPC" delete-property ;|
>
> colon_definition_function_83d is maybe the decompression function.
>
> I have a PC Promise ATA 133 card that by all looks is identical to the one used by 
> Sonnet Tech in the Tempo ATA 133 line, however there exists no tool for flashing the 
> Mac Fcode ROM to the card sans the Sonnet Flashing tool that won’t recognize a PC Card.
>
> I tried using PCI-Passthough to Qemu-System-PPC to load the Fcode ROM from a  file in 
> OpenBios, but the compressed part of the ROM doesn’t seem to work correct in OpenBios.
>
> load hd:,\ppc\fwata3.bin
> “  /pci/@e” open-dev to my-self
> 400004a 1 byte-load

The basic pattern of "load ... byte-load" looks correct in order to execute an FCode 
binary. I suspect that boot-command has either size or escaping restrictions which is 
why this approach doesn't work.

When experimenting with Forth code I tend to run QEMU with "-nographic -prom-env 
'auto-boot?=false'" which outputs to a standard terminal and stops at a Forth prompt. 
It is then easy to copy/paste your Forth from a text file as required.

Note there are rumours that Apple invented some of their own FCodes outside of the 
IEEE-1275 specification as part of their Open Firmware implementation so do keep an 
eye out for these too.

ATB,

Mark.

[Segher Boessenkool]

On Mon, Jan 24, 2022 at 08:33:29AM +0000, Mark Cave-Ayland wrote:
> Note there are rumours that Apple invented some of their own FCodes outside 
> of the IEEE-1275 specification as part of their Open Firmware 
> implementation so do keep an eye out for these too.

They aren't rumours.  Most of Apple OF is itself in FCode, btw, which
is why they have those extra codes.

Segher