Summary: ASCII mode file transfers work!
OK folks, just did a BIOS flash without a modem connection.
No sz, no rz, no qcp, just raw-ass ASCII from /dev/modem to
the file.
Ingredients: Two cooperative modems, one virgin IO, one PC,
and a DOS communications program. (Heck, my "PC" was a second
IO running DOS from the SanDisk 
The IO's modems are capable
of talking to each other by connecting a piece of phone cord
between them. No "battery" is required to fake a "talk voltage"
on the line in this configuration.
Disclaimer: As always, YMMV. This procedure involves the transfer
of material that, if corrupt, can turn your IO into a doorstop. It
transfers that material using a communications protocol with no
meaningful error correction. If that doesn't scare you, it should.
If you're feeling lucky, read on.
1) PC: I'm using Telix 3.10, a DOS-based comm program.
Alt-O -> Configure Options
-> "A"scii transfers
My ASCII transfer parameters were as follows. Critical
parameters are denoted with an asterisk. Parameters "F"
and "G" are minimum values. (Actually, lower values may
work too, but the higher the delay, the less chance of the
modems getting confused.)
A * Strip high bit - off
B - Remote abort char - 0
C - Local echo - off
D * Expand blank lines - off
E * Pace character - 0
F * Line pacing - 1 (1/10 sec)
G * Character pacing - 100 (msec)
H * CR translation - none
I * LF translation - none
You should be able to type AT commands to the PC and modem. If not,
use Alt-P to tweak your comm port parameters accordingly. I had them
set for 9600-8N1; the modems connected at 33600 anyways.
2) PC: Have the following files ready:
qnxflash.tgz - contains qnxflash exectuable and readme file.
oldbios.tgz - make it yourself by by using "tar" to create a .tar
file of both your old bios and some random padding
junk like a z_readme.txt at the end. Then use gzip
to compress it.
You want the "padding junk" because you *know* you can get the
first part of the file through intact. You're not 100% sure you
can get the last bit intact. (Actually, you're 99.99% sure, but
why take chances?)
DOS executables for tar and gzip are available at www.simtel.net
and many other places. UNIX folks have these built-in.
3) IO: Boot and Home-4 your way to a root shell.
Crank up qtalk: /dbin/qtalk -m /dev/dmoem
Disable dialtone detect: AT#CWT6
4) PC: You should be talking to the modem from step 1.
Disable dialtone detect: AT#CWT6
Disable dialtone detect: ATX1
Dial dummy number: ATDT 1
5) IO: Answer the phone.
ATA
Wait a bit. The modems should connect. If not, use the battery
trick. (Umm, I'm assuming you've connected the two modem ports
with a phone cable!)
6) PC and IO: Mash some keys.
What you type on the PC should appear on the IO, and vice versa.
7) IO: Snarf data straight from serial port.
This is the *new* step:
Qtalk command mode: CTRL-A
X-it qtalk without hanging up: x
You're now at a shell prompt. The modem is still connected,
whether the modem light is on or not. Telix will show you a
"NO CARRIER" if the modem ever hangs up.
cat /dev/modem > /app/ztest/rawfile.tgz
At this point, everything the PC sends - unaltered - goes to the
file.
8) PC: ASCII upload from Telix.
Ascii-Upload: Page-Up, "A"scii, enter C:\path\to\OLDBIOS.TGZ
The PC will start shovelling data to the IO. You'll see the
"Lines:" indicator on the lower-left-hand side of the screen
change as each line is sent.
Wait until it's done.
9) IO: Stop tranfer.
Stop the IO's download: Ctrl-C.
Examine the file: ls -l /app/ztest/rawfile.tgz
The file should be at least as long as (probably one byte longer
than) the original on your machine.
10) IO: Decompress and extract.
If there's an extra character in the .tgz file, gzip -d rawfile.tgz
may not work. A pipe will work. By using gzip, you ensure that
any severe corruption in the file will result in failure to create
the .tar file.
cat rawfile.tgz | gzip -d > rawfile.tar
tar -xvf rawfile.tar
You should now have the contents of the .tar file in your
/app/ztest. They should be _exactly_ the same length as the
original .tar file on your DOS box.
If you have to chmod 755 qnxflash first to make it executable,
do so now.
11) Victory!
You should have a version of qnxflash that will run. You should
also have your old BIOS file that you're gonna flash.
Test qnxflash by reading your March 23 BIOS. You *must* test it
first because hey, you still can't trust this ASCII transfer crap
as far as you can throw it
If you can read out your March 23 BIOS, you can then use qnxflash
to flash the new BIOS image. After flashing, you should use the
verify option to ensure that the new BIOS image in flash matches
the new BIOS image you extracted from the .tgz file.
Astute readers will note that I had two .tgz files; one for
qnxflash and one for the BIOS image. I sent the small one
for qnxflash first to see if it would work and repeated the
entire process for the large BIOS image file. You can just
as easily do it all in one by creating a single .tar file with
qnxflash, your old-school BIOS, and a trailing junk readme file.
12) Figure out what a case of good beer costs. Send that much money
and/or a few bucks more to the FSF on behalf of the qnxflash crew.
For additional safety, you can use the ASCII transfer (upload a gzipped
tar file containing the exectutable file) technique to send binaries of
"sz" and "rz" to your IO, and do the rest of the file transfers with
Zmodem.
I did it the unsafe way, doing all file transfers in raw ASCII. I had
no errors when doing this between a virgin March 23 vintage IO and an
IO modded to run DOS off the SanDisk.
I had errors when using the "log" option in qtalk, but the errors
were all coming from qtalk; I had *no* errors when I switched to the
"exit-qtalk-without-hangup" and "cat /dev/modem > file" procedure.
I would not be surprised to find that that you could probably do this
without qtalk. Qtalk's only purpose is to send the AT commands to the
modem. If "echo ata > /dev/modem" works, you don't need qtalk at all.
Qtalk is more a convenience than a necessity.
