"Never"?

https://web.archive.org/web/20031016102833/http://e-www.motorola.com/files/microcontrollers/doc/eng_bulletin/EB335.pdf

http://www.nxp.com/files/microcontrollers/doc/app_note/AN4367.pdf

There are plenty other examples.

I stand corrected on the Motorola bulletin—I had not seen that one. That said, S19 is an informal term that is not found in the published S-record standard (which I have read countless times over the years).

NXP has no relation to Motorola. NXP is the spun-off semiconductor business of Phillips.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

What is "The published S-record standard"? Is that separate from the appendix of the MC68000 programming manual?

NXP merged with Freescale, which was the spun-off microprocessor division of Motorola. Further, Philips owned Signetics, which was an official second source of the 68000.

Threads that degenerate into pedantry are pointless. I thought this forum was better then this.

Just because someone messed up some minor detail should not automatically generate some valuless reply.

Not aimed at anyone in particular, just getting a bit fed up with a repeating pattern.

_________________
8 bit fun and games: https://www.aslak.net/

Anyway -- I had an interesting discussion with a friend of mine who does lots of embedded stuff and he wanted to know why we couldn't just stream binary directly to the board. I had nothing, except to point out that the monitor is 20 year old code and that probably wasn't what the cool kids were doing at the time. Just what would we want to use in the 21st century instead of S28?

(I'm assuming that at some point we're going to want to create a replacement for the Mensch Monitor that includes stuff like routines for writing bytes to Flash etc., so that would be something to update while we're at it.)

Would ZMODEM transporting raw binary be a good choice? I think most terminal emulators support it. You'd need to start with a load address, perhaps, and maybe end with an execution address. (Srecord is actually a good fit for what's needed.)

My hacker tool does binary XMODEM transfer and will write into the flash area as well as normal RAM on the SXBs.

All we need is a better boot ROM. The question is should it be a better machine code monitor, a Forth environment or a simple operating system?

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

This might sound strange coming from me, but I wonder if a better Monitor might be the best solution because it would provide the most flexibility for people who, say, want to add a version of BASIC. Maybe keep the entry points for the important subroutines such as PUT_CHR for backwards compatibility, but then add XMODEM and code for handling the Flash stuff ... if it fits.

(I'm not sure about the whole tone generator and RTC stuff that is currently included, does anybody really use either? I'd sort of assumed that if you're going to have a RTC, it would probably be something battery-backed in hardware ...)

The other option, though, would in fact be an "Open Firmware" type Forth that makes a point of exposing the basic routines such as PUT_CHR and whatnot at the current jump addresses for backwards compatibility. It wouldn't have to be able to do much, and I'm wondering if this might be a case where a Token Threaded Forth might be the best solution to keep stuff small (256 8-bit tokens, say), because for these mostly interactive admin things you wouldn't care so much about speed anyway. So you'd keep the access to the low-level system libraries, but could do basic Forth things as well.