home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!seismo!darwin.sura.net!gatech!rpi!batcomputer!munnari.oz.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!news.adelaide.edu.au!jeremy
- From: jeremy@cs.adelaide.edu.au (Jeremy Webber)
- Newsgroups: comp.sys.transputer
- Subject: Re: Format of .btl files
- Message-ID: <JEREMY.93Jan27092443@chook.adelaide.edu.au>
- Date: 27 Jan 93 14:24:43 GMT
- References: <1993Jan22.114632.24686@dcs.warwick.ac.uk>
- <1993Jan26.034907.9697@ohm.york.ac.uk>
- Organization: Digital Arts Film and Television
- Lines: 22
- NNTP-Posting-Host: chook.cs.adelaide.edu.au
- In-reply-to: don@ohm.york.ac.uk's message of 26 Jan 93 03:49:07 GMT
-
- In article <1993Jan26.034907.9697@ohm.york.ac.uk> don@ohm.york.ac.uk (Don Goodeve) writes:
-
- The bootable file has encoded into it all the configuration and
- booting info as well as the executable text. The btl file is an
- unstructured binary file from the point of view of iserver. The
- iserver just sends the file down the link. The file is structured
- into packets (as I understand it) by bootstrap code as it passes
- into the network and is fanned out. All control lies with the
- code in the bootable. The iserver does not have a clue.
-
- Further, there is a very good reason for doing it this way. Many
- (most?) transputers run in an embedded environment where there is no
- Iserver. Having all the bootstrap code in the .btl file means that the
- same .btl file can be loaded into ROM to start such a system.
-
- -jeremy
- --
- --
- Jeremy Webber Internet: jeremy@cs.adelaide.edu.au
- Digital Arts Film and Television, jeremy@chook.ua.oz.au
- 1 Ledger Rd, Beverley, SA 5009, Phone: +61 8 347 4691
- Australia FAX: +61 8 347 4692
-