Running VF on a Mac using gforth

[awegel]

I wrote a minimal wrapper to use VF on a (PowerPC) Mac.
The simulator seems to work just fine, the hardware access probably
wont work (untested, probably different device-paths than linux), but
is implemented. I don't know about the exact commandline arguments VF
interprets - so this is not inside too.
The INTELLASYS environment variable gets used, though.
After saving the text given below to a file named "t18x.fs" inside th
vf source directory, the following shell command will (should) create
a gforth image file "vf", which can then be used like any executable:

gforthmi vf t18x.fs

Alternatively, "t18x.fs" can simply be passed on the commandline,
before the vf code, for example, from inside the VentureForth
directory:

gforth vf/t18x.fs projects/sim3s40boots/3boots.vf

This is just a first hack at it, so any bug/improvement idea is
welcome :-)

Have fun,
Alex

Here's the contents of "t18x.fs":

#! /usr/local/bin/gforth-fast
\ Definitions needed in order to compile vf using gforth (on a G5
Mac).
\ Needs gcc to compile system calls
\ Uses environment variable VFDIR to override compiled-in search path

\c #include <unistd.h>
c-function syscall_nna syscall n n n a -- n
c-function syscall_ann syscall n a n n -- n
c-function syscall_n syscall n n -- n
: swap4 swap 2swap swap ;
: sys_open ( m f a - fd) 5 swap4 syscall_ann ;
: sys_close ( fd - ?) 6 swap syscall_n ;
: sys_ioctl ( a n fd) $36 swap4 syscall_nna ;

create >intellasys-dir 0 c, 255 chars allot

: $+ ( a1 u1 a2 u2 -- a3 u3 ) >r >r 2dup + r> swap r@ move r> + ;
: >pad pad place pad count ;
: intellasys-dir >intellasys-dir count >pad ;
: v.VF intellasys-dir s" /VentureForth/vf/" $+ ;
: init-env
s" INTELLASYS" getenv dup 0= if
2drop
s" /usr/local"
then >intellasys-dir place ;
init-env
:noname Defers 'cold init-env ; IS 'cold

: -? ; \ i assume this is for ignoring a redefinition?
5 8 + constant HostForth
s" HostConfig.f" required \ load all of vf

\ end of file

[Dennis Ruffer]

Very good start Alex! While I worked there, I made sure that T18
worked on gforth. So the basics are in place.

As you suspected, your FORTHdrive interface isn't working, unless of
course, it finds the drive for you.

It doesn't for me and I'm way over my head trying to make something
work.

I can detect that the drive is there, but I don't think OS X supports
those ioctl calls, and I'm not even really sure what they are
supposed to be doing.

Any help deciphering what those calls are trying to do would be
appreciated. ;)

DaR

[awegel]

Hi

> Very good start Alex! 

Thanks.

> While I worked there, I made sure that T18  
> worked on gforth.

Ah - that was you - thanks again.

>  So the basics are in place.

"basics" in the sense of "almost everything" ;-)

> As you suspected, your FORTHdrive interface isn't working, unless of  
> course, it finds the drive for you.

Which will be hard, because it would have to cross the ocean, get the
drive, and bring it back here :-(

(And after finding it, it would still have to pay for it - that's even
harder to implement.)

> I can detect that the drive is there, but I don't think OS X supports  
> those ioctl calls, and I'm not even really sure what they are  
> supposed to be doing.

I looked them up at the linux documentation project (glad i remembered
this one): They are a rather obscure interface to scsi calls: Unknown
ioctl function codes "trickle" through to the scsi layer. See for
yourself at

http://tldp.org/HOWTO/SCSI-Generic-HOWTO/ioctl.html

..and on the following page about "SG_IO", which is the op actually
being used in the vf "scsi>" word.

I'm sure this doesn't exist on mac os - so i think i have to use the
iokit to reimplement the scsi call (or even libusb?).
Let's see how far i get without having the hardware.
I'm also not sure yet whether i need docs about the onspec usb chip
used, or if it needs a driver. Chances are, that the information in
the source is almost sufficient.

I would appreciate if you could look how the forthdrive appears in
the /dev directory (with what name), and/or maybe more important,
its usb device info - vid, pid, class (i fathom i'll have to use the
usb interface at least for finding the device).

Cheers,
Alex

[forther]

On Dec 3, 9:34 am, awegel <awe...@arcor.de> wrote:
> Hi
>
> > Very good start Alex! 
>
> Thanks.
>
> > While I worked there, I made sure that T18  
> > worked on gforth.
>
> Ah - that was you - thanks again.
>

ANS and gforth compatibility was meant from the very beginning (long
before Dennis joined Intellasys). So the credits should go some other
ways.

> >  So the basics are in place.
>
> "basics" in the sense of "almost everything" ;-)
>
> > As you suspected, your FORTHdrive interface isn't working, unless of  
> > course, it finds the drive for you.
>
> Which will be hard, because it would have to cross the ocean, get the
> drive, and bring it back here :-(
>

Contact Intellasys. I'm sure they will send you one.

Thanks,
Forther

[Jason Damisch]

Alex,

I'm sure that Intellasys will send you a forth drive, because you are actually writing some code, and it would not be just for a souvenir. When I was at Forth Day, they told me that there were still some Forth Drives available.

Jason

[awegel]

Hello

forther wrote:

> ANS and gforth compatibility was meant from the very beginning (long
> before Dennis joined Intellasys). So the credits should go some other
> ways.

Yes, maybe my clumsy expression made it sound like i thought it was
exclusively Dennis.

I only wonder why the gforth support was dropped, though.

> > > As you suspected, your FORTHdrive interface isn't working, unless of �
> > > course, it finds the drive for you.
> >
> > Which will be hard, because it would have to cross the ocean, get the
> > drive, and bring it back here :-(
>
> Contact Intellasys. I'm sure they will send you one.

OK. I'll try. (So maybe the interface might actually find&bring the
chip. :)

Cheers,
Alex

[Dennis Ruffer]

On Dec 3, 2008, at 11:34 AM, awegel wrote:

While I worked there, I made sure that T18  

worked on gforth.

Ah - that was you - thanks again.

As pointed out, I was not alone.

<snip>

I can detect that the drive is there, but I don't think OS X supports  

those ioctl calls, and I'm not even really sure what they are  

supposed to be doing.

I looked them up at the linux documentation project (glad i remembered

this one): They are a rather obscure interface to scsi calls: Unknown

ioctl function codes "trickle" through to the scsi layer. See for

yourself at

http://tldp.org/HOWTO/SCSI-Generic-HOWTO/ioctl.html

..and on the following page about "SG_IO", which is the op actually

being used in the vf "scsi>" word.

I'm sure this doesn't exist on mac os - so i think i have to use the

iokit to reimplement the scsi call (or even libusb?).

Let's see how far i get without having the hardware.

I'll take a look, but I suspect that the scsi route is a dead end.

I'm also not sure yet whether i need docs about the onspec usb chip

used, or if it needs a driver. Chances are, that the information in

the source is almost sufficient.

I've managed to get some documentation, which makes no mention of a scsi interface.

I would appreciate if you could look how the forthdrive appears in

the /dev directory (with what name), and/or maybe more important,

its usb device info - vid, pid, class (i fathom i'll have to use the

usb interface at least for finding the device).

Here is the IORegistryExplorer's Inspector output:

{

    "Bus Power Available" = 250; 

    "Device Speed" = 2; 

    IOCFPlugInTypes = {

        "9dc7b780-9ec0-11d4-a54f-000a27052861" = "IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"; 

    }; 

    IOGeneralInterest = "IOCommand is not serializable"; 

    IOUserClientClass = IOUSBDeviceUserClient; 

    PortNum = 1; 

    "USB Address" = 2; 

    "USB Product Name" = "SEAforth24A-TD     "; 

    "USB Serial Number" = 010908000039; 

    "USB Vendor Name" = "IntellaSys "; 

    bDeviceClass = 0; 

    bDeviceProtocol = 0; 

    bDeviceSubClass = 0; 

    bMaxPacketSize0 = 64; 

    bNumConfigurations = 1; 

    bcdDevice = 260; 

    iManufacturer = 1; 

    iProduct = 2; 

    iSerialNumber = 3; 

    idProduct = 11056; 

    idVendor = 21930; 

    locationID = 1427111936; 

    sessionID = 146306282570; 

    uid = "USB:55AA2B30010908000039"; 

}

DaR

[Stephen Pelc]

Dennis said:

> > ..and on the following page about "SG_IO", which is the op actually
> > being used in the vf "scsi>" word.
> >
> > I'm sure this doesn't exist on mac os - so i think i have to use the
> > iokit to reimplement the scsi call (or even libusb?).
> > Let's see how far i get without having the hardware.
>
> I'll take a look, but I suspect that the scsi route is a dead end.
>
> > I'm also not sure yet whether i need docs about the onspec usb chip
> > used, or if it needs a driver. Chances are, that the information in
> > the source is almost sufficient.
>
> I've managed to get some documentation, which makes no mention of a
> scsi interface.

I wrote the original Windows code that accessed the Forth drive,
and learned more than I wanted to know about ioctl() and
friends, USB and memory sticks. Since then, we've done several
USB device implementations.

The ForthDrive is a USB memory stick (Mass Storage Class) that
uses vendor specific commands to access the SEAforth chip. All
USB sticks use MSC, which is why you don't need host drivers for
them. Most sensible memory sticks use Bulk Only Transport (BOT)
which uses SCSI commands with USB as the transport. The
nightmare is all documented at http://www.usb.org.

The SEAforth interface is achieved by using vendor-specific SCSI
commands, so you must get to the correct interface on the host
system. The original Windows code was released by IntellaSys and
was very heavily documented. This documentation disappeared in
the ports to other operating systems. If only people documented
their code, life would be so much easier for others. The old
idea "if it was hard to write, it should be hard to read" is
rubbish!

Stephen
--
Stephen Pelc, ste...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Dennis Ruffer]

Ah, that may be the missing piece to this puzzle. I don't know if
you wrote the SwiftForth implementation that is included with the
VentureForth 1.3.5 26-Sep-2008 release, but it is missing the BOT
clue. I too am learning more than I wanted to know, but this might
give me something to search for among the OS X documentation.

Thanks for speaking up!

DaR

[Peter Sovietov]

Leon Wagner wrote the USB code for VentureForth(Windows). It is
excellent documented. Linux-version refers on it, except of the Linux
sg driver call. So if you have any questions about the Linux port,
make sure that you have read this: http://tldp.org/HOWTO/SCSI-Generic-HOWTO/.

On 4 дек, 13:48, "Stephen Pelc" <step...@mpeforth.com> wrote:
> Dennis said:
>
> > > ..and on the following page about "SG_IO", which is the op actually
> > > being used in the vf "scsi>" word.
>
> > > I'm sure this doesn't exist on mac os - so i think i have to use the
> > > iokit to reimplement the scsi call (or even libusb?).
> > > Let's see how far i get without having the hardware.
>
> > I'll take a look, but I suspect that the scsi route is a dead end.
>
> > > I'm also not sure yet whether i need docs about the onspec usb chip
> > > used, or if it needs a driver. Chances are, that the information in
> > > the source is almost sufficient.
>
> > I've managed to get some documentation, which makes no mention of a  
> > scsi interface.
>
> I wrote the original Windows code that accessed the Forth drive,
> and learned more than I wanted to know about ioctl() and
> friends, USB and memory sticks. Since then, we've done several
> USB device implementations.
>
> The ForthDrive is a USB memory stick (Mass Storage Class) that
> uses vendor specific commands to access the SEAforth chip. All
> USB sticks use MSC, which is why you don't need host drivers for
> them. Most sensible memory sticks use Bulk Only Transport (BOT)
> which uses SCSI commands with USB as the transport. The

> nightmare is all documented athttp://www.usb.org.

>
> The SEAforth interface is achieved by using vendor-specific SCSI
> commands, so you must get to the correct interface on the host
> system. The original Windows code was released by IntellaSys and
> was very heavily documented. This documentation disappeared in
> the ports to other operating systems. If only people documented
> their code, life would be so much easier for others. The old
> idea "if it was hard to write, it should be hard to read" is
> rubbish!
>
> Stephen
> --

> Stephen Pelc, step...@mpeforth.com

[awegel]

Dennis Ruffer wrote:

> Here is the IORegistryExplorer's Inspector output:

Thanks. i'm not sure, but this looks like the device is not recognized
as a mass storage device at all.
Unfortunately the IORegistryExplorer does not show relevant
descriptors of the device (i.e. interface descriptors) - would you
please post "USB Prober"'s output for this device, which is more
exhaustive?

As i see it, either it's possible to use the SCSITask interface (which
depends on the device class), or an IOKit driver must be written
(=subclassed), or there's still an easier way...

Alex

[Dennis Ruffer]

Here it is. I hope the formatting doesn't mess it up to bad.

High Speed device @ 2
(0x55100000): .............................................
Composite device: "SEAforth24A-TD "
Device Descriptor
Descriptor Version Number: 0x0200
Device Class: 0 (Composite)
Device Subclass: 0
Device Protocol: 0
Device MaxPacketSize: 64
Device VendorID/ProductID: 0x55AA/0x2B30 (OnSpec
Electronic Inc.)
Device Version Number: 0x0104
Number of Configurations: 1
Manufacturer String: 1 "IntellaSys "
Product String: 2 "SEAforth24A-TD "
Serial Number String: 3 "010908000039"
Configuration Descriptor
Length (and contents): 32
Raw Descriptor (hex) 0000: 09 02 00 20 01 01 00 80
64 09 04 00 00 02 08 06
Raw Descriptor (hex) 0010: 50 00 07 05 01 02 00 02
00 07 05 82 02 00 02 00
Unknown Descriptor 0020:
Number of Interfaces: 1
Configuration Value: 1
Attributes: 0x80 (bus-powered)
MaxPower: 200 ma
Interface #0 - Mass Storage/SCSI
Alternate Setting 0
Number of Endpoints 2
Interface Class: 8 (Mass Storage)
Interface Subclass; 6 (SCSI)
Interface Protocol: 80
Endpoint 0x01 - Bulk Output
Address: 0x01 (OUT)
Attributes: 0x02 (Bulk no synchronization data
endpoint)
Max Packet Size: 512
Polling Interval: 0 ( Endpoint never NAKs)
Endpoint 0x82 - Bulk Input
Address: 0x82 (IN)
Attributes: 0x02 (Bulk no synchronization data
endpoint)
Max Packet Size: 512
Polling Interval: 0 ( Endpoint never NAKs)
Device Qualifier Descriptor
Descriptor Version Number: 0x0200
Device Class 0 (Composite)
Device Subclass 0
Device Protocol 0
Device MaxPacketSize: 64
Number of Configurations: 1
bReserved: 0
Other Speed Configuration Descriptor
Length (and contents): 18
Raw Descriptor (hex) 0000: 09 07 00 12 01 01 00 80
64 09 04 00 00 00 00 00
Raw Descriptor (hex) 0010: 00 00
Number of Interfaces: 1
Configuration Value: 1
Attributes: 0x80 (bus-powered)
MaxPower: 200 ma
Interface #0 - Unknown
Alternate Setting 0
Number of Endpoints 0
Interface Class: 0 (Unknown)
Interface Subclass; 0
Interface Protocol: 0

DaR

[awegel]

Hi

Thanks again. Now it makes more sense :-)

In the meantime i've been looking up the OnSpec chip used on the
board, and while i couldn't find a really comprehensive reference, i
found out that OnSpec use the same Apple sample-code for their driver
that i was planning to base my effort on (VendorSpecificType00). In
fact, i already set up the project, and changed some properties to
match the forthdrive.

And hey - i'm gonna get one! :-)))

cheers,
Alex

[Dennis Ruffer]

Yea! It sounds like you have a clue about how to do it, which I'm
certainly lacking, and they have spare drives.

You must have also gotten through the OnSpec website, which I still
can't do, and some sample code.

If you could send me the driver at dru...@worldnet.att.net, I'd love
to see it and figure out what I've been missing.

However, I'm glad to hear you are on the right track to getting this
done.

DaR