Motorola S?

[yzoer]

Hi all,

While I"m pretty far away from implementing this (working on the hardware), I'm considering using motorola-s as my 'standard' for encoding. Yes, it's larger but it does have some nice properties. The one thing I couldn't find anywhere is how error-control is done. I know every string has a check-sum but there doesn't seem to be an agreed-upon behavior as to what happens when that check-sum is wrong, due to whatever reason.

So my question is, does the whole thing just fail or is there some sort of response code for requesting the same string again

Thanks!

Yvo

[GARTHWILSON]

Do you anticipate errors? I've been using Intel Hex for over 30 years, and have never, ever had a single error. I expect it would be the same with Mot S.

[Klaus2m5]

yzoer wrote:

So my question is, does the whole thing just fail or is there some sort of response code for requesting the same string again

There is no protocol associated with recovering checksum errors for all of these formats (hex ascii coded binaries). So the loader will simply fail with a checksum error message. As Garth said nowadays checksum errors are rare.

Back then when these binary load methods were invented the interfaces used were much less reliable, reading from paper tape with mechanical sense switches or fsk coded audio tape for example. At the same time it is obvious that you needed to rewind before a record could be read again. Therefore there is no automatic recovery.

[yzoer]

Not expecting errors but in case there would be one, I was wondering if there was anything 'official' out there such as a nack and re-send or something. Thanks for the Intel Hex link.

FWIW, anyone know another protocol that also allows for reads/writes/custom commands to be send? Motorola-S seems to be fine for just loading data into memory but at some point I'd like my boot-rom to be able to send stuff back..

Cheers,
Yvo

[MichaelM]

At the most fundamental level what you are asking about would be considered the BIOS or monitor for your project. AFAIK, there's no standard for that interface.

At a level above the BIOS/Monitor, you may consider implementing SLIP (Serial Line Interface Protocol) and adding some IP (Internet Protocol) modules such as Telnet, etc.

There was a great book on doing this type of interface for a PIC processor:

TCP/IP Lean: Web Servers for Embedded Systems

I have not implemented a web server as Jeremy Bentham described, but I certainly have used some of his concepts in my work. If you are looking for a standard approach that can take advantage of a lot open source resources, it might be something to consider. A 6502/65C02/65816 processor is a far more capable processor than a PIC, so an embedded system as he describes in the book should be quite feasible. Just a suggestion.

[BigEd]

I've seen checksum errors when using a serial line with dubious flow control - it's much better for a load to fail than to start running a corrupted program and then trying to debug it!

[BigDumbDinosaur]

yzoer wrote:

While I"m pretty far away from implementing this (working on the hardware), I'm considering using motorola-s as my 'standard' for encoding...The one thing I couldn't find anywhere is how error-control is done. I know every string has a check-sum but there doesn't seem to be an agreed-upon behavior as to what happens when that check-sum is wrong, due to whatever reason.

My POC units implement Motorola S-record transfers in the BIOS. As each record comes in its checksum is calculated and compared to the checksum that was embedded in the S-record. In the current implementation, a checksum mismatch causes the entire transfer to be aborted and a diagnostic to be printed on the console.

Something I may try out in POC V2's more capacious ROM space is to set up a simple protocol to gracefully handle an error. In such arrangement, the sending computer would transmit an S-record and then wait. Once the POC unit has verified the record it will send an ASCII <ACK> ("acknowledge," $06) to indicate the record was received error-free. That would be the sender's cue to transmit the next S-record.

On the other hand, if the received S-record's computed checksum is wrong, POC will send a ASCII <NAK> ("negative acknowledge," $15), telling the sender to re-transmit that S-record. POC would keep track of how many times a record has to be resent and if it is more than three times, will send ASCII <CAN> ("cancel," $18), telling the sender to abort. That would prevent getting stuck in a loop if a gross interface error were to occur.

In practice, I have never had an interface error prematurely terminate an S-record transfer, even though the link between POC and my Linux development box runs at 115.2 Kbps. As Ed noted above, errors are likely to creep in due to improper flow control. In some cases, running the serial interface over too long a cable can cause a variety of errors. Hardware can also cause trouble if, for example, the line drivers (e.g., MAX-232) are not producing the proper voltage levels. On a reasonably short interface with proper hardware flow control you shouldn't have to worry about data link errors.

[whartung]

BigDumbDinosaur wrote:

My POC units implement Motorola S-record transfers in the BIOS. As each record comes in its checksum is calculated and compared to the checksum that was embedded in the S-record. In the current implementation, a checksum mismatch causes the entire transfer to be aborted and a diagnostic to be printed on the console.

Not much more you can do here, a checksum isn't the same thing as error correction.

Quote:

Something I may try out in POC V2's more capacious ROM space is to set up a simple protocol to gracefully handle an error. In such arrangement, the sending computer would transmit an S-record and then wait. Once the POC unit has verified the record it will send an ASCII <ACK> ("acknowledge," $06) to indicate the record was received error-free. That would be the sender's cue to transmit the next S-record.

On the other hand, if the received S-record's computed checksum is wrong, POC will send a ASCII <NAK> ("negative acknowledge," $15), telling the sender to re-transmit that S-record. POC would keep track of how many times a record has to be resent and if it is more than three times, will send ASCII <CAN> ("cancel," $18), telling the sender to abort. That would prevent getting stuck in a loop if a gross interface error were to occur.

You might want to at least take a glance at the Kermit protocol, since that's essentially what they do (arguably, its what they all do), but by looking it, it may answer questions you may not have thought to ask. They have versions of the protocol for, well, most everything -- including 6502 (well, Apple ][). If you look at their archive, they have several different drivers for a variety of Apple serial cards and, of all things, they even include an assembler written in C.

While the protocol CAN be sophisticated, the base version is quite simple. So, if you go so far as to implement the base level of the protocol, an off the shelf Kermit program will work fine on the host.

They even have a simple version written in BASIC with the intent that you fire that up, and use it to bootstrap sending over a better version.

[BigDumbDinosaur]

whartung wrote:

BigDumbDinosaur wrote:

My POC units implement Motorola S-record transfers in the BIOS. As each record comes in its checksum is calculated and compared to the checksum that was embedded in the S-record. In the current implementation, a checksum mismatch causes the entire transfer to be aborted and a diagnostic to be printed on the console.

Not much more you can do here, a checksum isn't the same thing as error correction.

Quote:

Something I may try out in POC V2's more capacious ROM space is to set up a simple protocol to gracefully handle an error. In such arrangement, the sending computer would transmit an S-record and then wait. Once the POC unit has verified the record it will send an ASCII <ACK> ("acknowledge," $06) to indicate the record was received error-free. That would be the sender's cue to transmit the next S-record.

On the other hand, if the received S-record's computed checksum is wrong, POC will send a ASCII <NAK> ("negative acknowledge," $15), telling the sender to re-transmit that S-record. POC would keep track of how many times a record has to be resent and if it is more than three times, will send ASCII <CAN> ("cancel," $18), telling the sender to abort. That would prevent getting stuck in a loop if a gross interface error were to occur.

You might want to at least take a glance at the Kermit protocol, since that's essentially what they do (arguably, its what they all do), but by looking it, it may answer questions you may not have thought to ask. They have versions of the protocol for, well, most everything -- including 6502 (well, Apple ][). If you look at their archive, they have several different drivers for a variety of Apple serial cards and, of all things, they even include an assembler written in C.

While the protocol CAN be sophisticated, the base version is quite simple. So, if you go so far as to implement the base level of the protocol, an off the shelf Kermit program will work fine on the host.

They even have a simple version written in BASIC with the intent that you fire that up, and use it to bootstrap sending over a better version.

I think your suggestion would be akin to sending out abattleship to sink a rowboat. In a short-distance, hardwired link operating at TIA-232 speeds, the likelihood of an error occurring is very small, assuming the use of hardware flow control. The checksum of a Motorola S-record is sufficient to detect an error in such a link. Adding a full error-correcting protocol such as Kermit, or even the much older Xmodem is gross overkill, in my opinion.

Now, if we were talking through modems and a phone line...

[Aslak3]

MichaelM wrote:

There was a great book on doing this type of interface for a PIC processor:

TCP/IP Lean: Web Servers for Embedded Systems

Book ordered. It bugs me that I first encountered "TCP/IP" over 20 years ago but have never fully grasped it enough to implement it myself. IP and UDP are readily understandable but TCP... This book is hopefully approachable enough that I can apply it to my retro project and implement SLIP, IP, UDP and maybe even TCP...

Thanks for the href!

[BigDumbDinosaur]

Aslak3 wrote:

MichaelM wrote:

There was a great book on doing this type of interface for a PIC processor:

TCP/IP Lean: Web Servers for Embedded Systems

Book ordered. It bugs me that I first encountered "TCP/IP" over 20 years ago but have never fully grasped it enough to implement it myself. IP and UDP are readily understandable but TCP... This book is hopefully approachable enough that I can apply it to my retro project and implement SLIP, IP, UDP and maybe even TCP...

Thanks for the href!

TCP isn't difficult to understand once you know that it performs a number of important functions that are not implemented in UDP:

1. Error-checking and correction. IP neither guarantees that datagrams will arrive, or that they will arrive intact. TCP includes a mechanism to verify that all datagrams are received intact. If a datagram is missing or is corrupted retransmission will be requested.
2. Flow control. No explanation should be needed for this function.
3. Orderly delivery of datagrams. Although the transmitting station will number and send datagrams in a defined order, routing and propagation delays may cause datagrams to arrive out of order at the receiving station. TCP at the receiving end will rearrange datagrams so they are presented to higher-level functions in the order intended.

Other functions are also encapsulated into TCP, such as QoS. However, understanding the above three will go a long way toward reaching your goals.

Incidentally, there are TCP/IP stacks in existence for use on 6502 hardware. I can't vouch for how well they work.

[BigEd]

BigDumbDinosaur wrote:

...
[*]Flow control. No explanation should be needed for this function.
...

And yet, as it turns out, here be dragons. There are some interesting problems and some interesting solutions, and it's a topic of much current research:

Quote:

Saturated (“congested”) links are *normal* operation in the Internet, not abnormal. And indeed, improved congestion avoidance algorithms such as BBR and mark/drop algorithms such as CoDel and PIE are part of the solution to bufferbloat.

And since TCP is innately “unfair” to flows with different RTT’s, and we have both nearby (~10ms) or (inter)continental distant (~75-200ms) services, no TCP only solution can possibly provide good service.

...

We must look to solve all of these problems at once, not just individual aspects of the bufferbloat elephant. Flow Queuing CoDel (FQ_CoDel) is the first, but will not be the last such algorithm. And we must attack bufferbloat however it appears.

...

Gamers, stock traders, musicians, and anyone wanting decent telephone or video calls take note. Insist your ISP fix bufferbloat in its network. Linux and RFC 8290 prove you can have your cake and eat it too. Stop suffering.

Insist on up to date flow queuing queue management in devices you buy and use, and insist that bufferbloat be fixed everywhere.

[DavidL]

BigDumbDinosaur wrote:

TCP isn't difficult to understand once you know that it performs a number of important functions that are not implemented in UDP:

1. Error-checking and correction. IP neither guarantees that datagrams will arrive, or that they will arrive intact. TCP includes a mechanism to verify that all datagrams are received intact. If a datagram is missing or is corrupted retransmission will be requested.
2. Flow control. No explanation should be needed for this function.
3. Orderly delivery of datagrams. Although the transmitting station will number and send datagrams in a defined order, routing and propagation delays may cause datagrams to arrive out of order at the receiving station. TCP at the receiving end will rearrange datagrams so they are presented to higher-level functions in the order intended.

Other functions are also encapsulated into TCP, such as QoS. However, understanding the above three will go a long way toward reaching your goals.

Incidentally, there are TCP/IP stacks in existence for use on 6502 hardware. I can't vouch for how well they work.

Mostly correct except TCP is a byte-stream protocol that happens to ride on IP packets. UDP is the datagram protocol in the IP stack. SCTP blends functionality of TCP to provide in-order, reliable datagrams with flow control.

[BigDumbDinosaur]

DavidL wrote:

BigDumbDinosaur wrote:

TCP isn't difficult to understand once you know that it performs a number of important functions that are not implemented in UDP:

1. Error-checking and correction. IP neither guarantees that datagrams will arrive, or that they will arrive intact. TCP includes a mechanism to verify that all datagrams are received intact. If a datagram is missing or is corrupted retransmission will be requested.
2. Flow control. No explanation should be needed for this function.
3. Orderly delivery of datagrams. Although the transmitting station will number and send datagrams in a defined order, routing and propagation delays may cause datagrams to arrive out of order at the receiving station. TCP at the receiving end will rearrange datagrams so they are presented to higher-level functions in the order intended.

Other functions are also encapsulated into TCP, such as QoS. However, understanding the above three will go a long way toward reaching your goals.

Incidentally, there are TCP/IP stacks in existence for use on 6502 hardware. I can't vouch for how well they work.

Mostly correct except TCP is a byte-stream protocol that happens to ride on IP packets. UDP is the datagram protocol in the IP stack. SCTP blends functionality of TCP to provide in-order, reliable datagrams with flow control.

Actually, in the above I should have used "packet" instead of "datagram" to be consistent with TCP terminology.