Subject: Serial Bootloader -- TRS-80 Model 4P (Technical Reference)
DouglasUT
operation. My Technical Reference Manual is 2,000 miles away
though -- can anyone please tell me:
1. The value of the byte that should be sent to sync? (think it's 55h)
2. The delay between each byte? (can't remember)
Or, is there somewhere on the WWW that outlines this?
I have a 4P, but no boot disk -- I figure I may-as-well have fun and
try to serial boot it; alas, I can't remember the algorithm which allows
the Model 4P to serial boot. Can anyone help me? If so, I will write
and post a serial bootloader for the Model 4P.
Douglas Beattie Jr. http://www2.whidbey.net/~beattidp/
Student
Frank Durda IV
hard to read.
DouglasUT (doug...@aol.com) wrote (blank lines snipped):
: I know that the TRS-80 has a special serial-boot mode of
: operation. My Technical Reference Manual is 2,000 miles away
: though -- can anyone please tell me:
: I have a 4P, but no boot disk -- I figure I may-as-well have fun and
: try to serial boot it; alas, I can't remember the algorithm which allows
: the Model 4P to serial boot. Can anyone help me? If so, I will write
: and post a serial bootloader for the Model 4P.
: 1. The value of the byte that should be sent to sync? (think it's 55h)
: 2. The delay between each byte? (can't remember)
The serial loader was used for burn-in tests during manufacturing. Dozens
of cards were loaded simultaneously with test programs and left to run some
hours. Later a monitor was connected to each card to determine the PASS/FAIL
status of the tests. Subsequently the process isn't very friendly.
Since the units had no keyboard attached, the serial loader was activated
by shorting two pins on the keyboard connector with a jumper clip, then
the board was powered-up. The RIGHT-SHIFT key turned out to be the one
used. You will have to mimic this by turning on the unit and pressing
RIGHT-SHIFT during the first three seconds of operation. The screen
should display "Not Ready" or something similar. Depending on your firmware
version, the messages differ slightly.
Now for the serial steps:
1. Assert CD. "READY" should appear on the screen.
2. Send at least ten bytes of 0x55 at the rate you wish to run at.
The serial loader starts scanning at 19200bps. When the unit
finds the correct baud rate (correctly reading ten 0x55 bytes
with no framing errors), the display should report that a baud
rate has been detected and report a speed code. 19200 is the
highest the UART will run at.
This same string is sent back up the serial pipe. Stop sending
0x55 when you see the string coming back at you and don't sending
anything else until that message completely finishes.
3. When everything has settled down and you receive all of the rate
message, send a single 0xff byte. The 4P will then respond with
"Loading" on the display and send it back up the serial pipe.
Again, you MUST wait until the entire string is received before
you send anything else.
4. Once you get this message, you may send the complete program to
be loaded. No delays of any sort are needed from this point on.
DO NOT SEND NULL BYTES unless they are part of the program being
loaded. The standard 01 and 02 headers are accepted for data being
loaded. Of course, the 02 record must be the last one received.
The manual suggested 2 stop bits at the highest speeds, but I
found this to be unncessary at 9600bps and below. 19200 was always
a bit flakey on that particular UART, regardless of the application.
This is covered in gory detail in the 4P Technical Reference. (I know, I
got it put there.) The file loader format is standard TRSDOS format and is
covered in many places. I vaguely recall that the 4P ROM is smart enough to
ignore 05 records, but don't try sending it anything fancy, such as PDF
records.
For the record, I did NOT write the serial loader (nor did I design the
handshake), but I did have to rewrite it and squeeze it down and merge it into
all the other 4P boot ROM code, which I did write. The serial handshake and
the original 48K memory test (not the full memory test used later) came from
the diagnostic group at the factory, where apparently they never have to
worry about ROM budgets, and when these modules initially arrived on my desk,
they consumed 90% of the 4K ROM budget! I only got 4K in the first place by
agreeing to include these factory functions, so they were something I simply
could not leave out. The original 4P ROM budget was 2K and the original
design did not envision booting directly into Model III mode (you would always
boot TRSDOS 6 first), no international error messages, no hard disk or
network drivers. Getting those features added took a lot of selling,
particularly since it increased the machines manufacturing cost, eg 4K vs 2K
ROM.
Frank Durda IV - only these addresses work:|"How do I know? I wrote the
<uhclem.dec98%nemesis.lonestar.org> | code and a lot of the manual,
| that's how."
This Anti-spam address expires Dec. 31st |
(c) 1998, ask before reprinting.
Jim Korman
> I know that the TRS-80 has a special serial-boot mode of
>
> operation. My Technical Reference Manual is 2,000 miles away
>
> though -- can anyone please tell me:
>
> 1. The value of the byte that should be sent to sync? (think it's 55h)
>
> 2. The delay between each byte? (can't remember)
>
> Or, is there somewhere on the WWW that outlines this?
>
> I have a 4P, but no boot disk -- I figure I may-as-well have fun and
>
> try to serial boot it; alas, I can't remember the algorithm which allows
>
> the Model 4P to serial boot. Can anyone help me? If so, I will write
> and post a serial bootloader for the Model 4P.
>
> Douglas Beattie Jr. http://www2.whidbey.net/~beattidp/
>
> Student
Douglas, hope the following helps, quoted from the M4P Tech Ref Manual
File Loader
The file loader is actually two modules--the actual loader and a set of
routines
to fetch bytes from the file on disk. The loader is invoked via a RST 28H. The
byte fetcher is called by the loader using RST 20H. Since restart vectors can
be
re-directed, the same loader is used by the RS-232 boot. The difference is that
the RST 20H is redirected to point to the RS-232 data receiving routine. The
loader reads standard loader records and acts upon two types:
01 Data Load
1 byte with length of block, including address
1 word with address to load the data
n bytes of data, where n+2 equals the length specified
02 Transfer Address
1 byte with the value of 02
1 word with the address to start execution at.
Any other loader code is treated as a comment block and is ignored. Once an 02
record has been found, the loader stops reading, even if there is additional
data, so be sure to place the 02 record at the end of the file.
Serial Loader
Invoking the serial loader is similar to forcing a boot from hard disk or
floppy. In this case the right shift key must be pressed at some time during
the
first three seconds after reset. The program does not care if the key is
pressed
forever, making it convent to connect pins 8 and 10 of the keyboard with a
shorting plug for bench testing of boards. This assumes that the object program
being loaded does not care about the key closure.
Upon entry, the program first asserts DTR (J4 pin 20) and RTS (J4 pin 4) true.
Next, "Not Ready" is printed on the topmost line of the video display. Modem
status CD (J4 pin 8) is then sampled. The program loops until it finds CD
asserted true. At that time the message "Ready" is displayed. Then the program
sets about determining the baud rate from the host computer.
To determine the baud rate, the program compares data received by the UART to a
test byte equal to '55' hex. The receiver is first set to 19200 baud. If ten
bytes are received which are not equal to the test byte, the baud rate is
reduced. This sequence is repeated until a valid test byte is received. If ten
failures occur at 50 baud, the entire process begins again at 19200 baud. If a
valid test byte is received, the program waits for ten more to arrive before
concluding that it has determined the correct baud rate. If at this time an
improper byte is received or a receiver error (overrun, framing, or parity) is
intercepted, the task begins again at 19200 baud.
In order to get to this point, the host or the modem must assert CD true. The
host must transmit a sequence of test bytes equal to '55' hex with 8 data bits,
odd parity, and 1 or 2 stop bits. The test bytes should be separated by
approximately 0.1 second to avoid overrun errors.
When the program has determined the baud rate, the message:
"Found Baud Rate x"
is displayed on the screen, where "x" is a letter from A to P, meaning
A = 50 baud E = 150 I = 1800 M = 4800
B = 75 F = 300 J = 2000 N = 7200
C = 110 G = 600 K = 2400 O = 9600
D = 134.5 H = 1200 L = 3600 P = 19200
The same message less the character signifying the baud rate is transmitted to
the host, with the same baud rate and protocol. This message is the signal to
the host to stop transmitting test bytes.
After the program has transmitted the baud rate message, it reads from the UART
data register in order to clear any overrun error that may have occurred due
to the test bytes coming in during the transmission of the message. This is
because the receiver must be made ready to receive a sync byte signaling the
beginning of the command file. For this reason, it is important that the host
wait until the entire baud rate message (16 characters) is received before
transmitting the sync byte, which is equal to 'FF' hex.
When the loader receives the sync byte, the message:
"Loading"
is displayed on the screen. Again, the same message is transmitted to the host,
and, again the host must wait for the entire transmission before starting into
the command file.
If the receiver should intercept a receive error while waiting for the sync
byte, the entire operation up to this point is aborted. The video display is
cleared and the message:
"Error,x"
is displayed near the bottom of the screen, where "x" is a letter from B to H,
meaning:
B = parity error
C = framing error
D = parity&framing errors
E = overrun error
F = parity&overrun errors
G = framing&overrun errors
H = parity&framing&overrun errors
The message:
"Error"
is then transmitted to the host. The entire process is then repeated fro the
"Not Ready" message. A six second delay is inserted before reinitialization.
This is longer than the time required to transmit five bytes at 50 baud, so
there is no need to be extra careful here.
If the sync byte is received without error, then the "Loading" message is
transmitted and the program is ready to receive the command file. After
receiving the "Loading" message the host can transmit the file without nulls or
delays between bytes.
(Since the file represents Z80 machine code and all 256 combinations are
meaningful, it would be disastrous to transmit nulls or other ASCII control
codes as fillers, acknowledgement, or start-stop bytes. The only control codes
needed are the standard command file bytes.)
Data can be transmitted to the loader at 19200 baud with no delays inserted.
Two
stop bits are recommended at high baud rates.
See the File Loader description for more information on the file loading.
If a receive error should occur during file loading, the abort procedure above
will take place, so when attempting remote control, it wise to monitor the host
receiver during transmission of the file. When the host is near the object
board as is the case in the factory application, or when more than one board is
being loaded, it may be advantageous or even necessary to ignore the
transmitted
responses of the object board(s) and to manual pace the test byte, sync byte,
and command file phases of the transmission process, using the video display
for
handshaking.
Mark P. Fishman
Do you happen to know if Tandy can supply a replacement disk set fo
Model 4 TRS-80 Pascal (cat # 26-2212)? My disk 2 has become unreadable,
just as I wanted to make a .DSK file out of it.
If you have contact phone numebrs I would appreciate your assistance.
Thanks.
Also, if you only see this in the newsgroup it's because your computer
rejected my mailhost's address. I got the following:
----- The following addresses had permanent fatal errors -----
<uhclem...@nemesis.lonestar.org>
----- Transcript of session follows -----
... while talking to nemesis.lonestar.org.:
>>> HELO ll.mit.edu
<<< 501 EHLO requires a valid host name as operand: 'll.mit.edu'
rejected from
LLMAIL.LL.MIT.EDU[129.55.12.40]: Host name does not match remote
address.
554 <uhclem...@nemesis.lonestar.org>... Service unavailable
I thought you should know. Cheers -- Mark F.
Frank Durda IV wrote:
>
> Frank Durda IV - only these addresses work:|"How do I know? I wrote the
> <uhclem.dec98%nemesis.lonestar.org> | code and a lot of the manual,
> | that's how."
> This Anti-spam address expires Dec. 31st |
> (c) 1998, ask before reprinting.
--
(reply to: mfishman at el el dot em eye tee dot ee dee ewe)
Frank Durda IV
: Also, if you only see this in the newsgroup it's because your computer
: rejected my mailhost's address. I got the following:
: ----- The following addresses had permanent fatal errors -----
: <uhclem...@nemesis.lonestar.org>
: ----- Transcript of session follows -----
: ... while talking to nemesis.lonestar.org.:
: >>> HELO ll.mit.edu
: <<< 501 EHLO requires a valid host name as operand: 'll.mit.edu'
: rejected from
: LLMAIL.LL.MIT.EDU[129.55.12.40]: Host name does not match remote
: address.
: 554 <uhclem...@nemesis.lonestar.org>... Service unavailable
: I thought you should know. Cheers -- Mark F.
This appears to have happened because LL.MIT.EDU (offered in the SMTP
HELO handshake) is not at the IP address the connection came from, which
answers as LLMAIL.LL.MIT.EDU, not LL.MIT.EDU. This violates RFC-822 by
providing a bogus/incorrect domain name in the HELO SMTP handshake. You
might mention this config bug to the people running the MIT.EDU servers.
This HELO security check is active by DEFAULT on SMAIL 3.2 and later and most
recent SENDMAIL mail implementations. It's purpose is to prevent
relaying/spamming from people who claim to be one site in the HELO but are
really on some AOL dialup...
Also, their forward and reverse DNS doesn't match, which doesn't help things.
Frank Durda IV - only these addresses work:|"The Knights who say "LETNi"
<uhclem.dec98%nemesis.lonestar.org> | demand... A SEGMENT REGISTER!!!"
|"A what?"
This Anti-spam address expires Dec. 31st |"LETNi! LETNi! LETNi!" - 1983
Copr. 1998, ask before reprinting.
Frank Durda IV
: Model 4 TRS-80 Pascal (cat # 26-2212)? My disk 2 has become unreadable,
: just as I wanted to make a .DSK file out of it.
Just call your local store and ask if they can get it. If you really get
stuck, I think I have the master disks for Alcor C somewhere, which I think
is the same thing (hey, it's only been 15 years) and fix you up with a
clone of the parts you can no longer read.
Mark P. Fishman
I did call Tandy Software Replacement, and they said that the item is
marked "discontinued, no substitution available". I have managed to copy
all of the files except two: LINKLOAD/CMD and RANDOM/OBJ. I believe that
LINKLOAD is needed only for making standalone executables, and I don't
do much with random numbers.
As you note, these files MIGHT be similar to ones on Alcor C for Model
4. I have that package and the disks are readable, so no need for you
look. Alcor used a pseudo-code system, so possibly I can get away with
that. Of course, the calling conventions are different for Pascal and
C... and Alcor C was version 2.1.0, while the Pascal was version 2.0.0
(at least in the Model I/III version -- no version number on the Model 4
disks I have).
Also, I have found what purports to be at least part of the disk set on
the web, so I'm going to examine it closely to see if I can extract
working files from that.
Thanks for your reply. Cheers -- Mark F.
Frank Durda IV wrote:
> Mark P. Fishman (mfis...@ll.mit.edu) wrote:
> : Model 4 TRS-80 Pascal (cat # 26-2212)? My disk 2 has become unreadable,
> Just call your local store and ask if they can get it. If you really get
> stuck, I think I have the master disks for Alcor C somewhere, which I think
> is the same thing (hey, it's only been 15 years) and fix you up with a
> clone of the parts you can no longer read.
--
Mark P. Fishman
different from mine, anyway. So I still need LINKLOAD and RANDOM. (It
turns out that RANDOM/OBJ contains the functions used for random-access
files, not random numbers.)
I don't think the ones from Alcor C will work -- LINKLOAD seems to be
compiler-specific.
*sigh* Anyone else got a copy of Model 4 TRS-80 Pascal (26-2212)?
Cheers -- Mark F.
Mark P. Fishman wrote:
> I have managed to copy
> all of the files except two: LINKLOAD/CMD and RANDOM/OBJ. I believe that
> LINKLOAD is needed only for making standalone executables, and I don't
> do much with random numbers.
--
Mark P. Fishman
RANDOM/OBJ, so you can all stop looking. :^)
I do appreciate those of you out there with libraries of old software
willing to help out a fellow TRS-80'er.