• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Trying to find the creator of the NCU 57600 Baud patch

So, I recently came across a patch for Newton Connection Utilities to allow a 57600 baud connection to the Newton/Einstein emulator. I've been trying to make similar edits for 115200 & 230400 baud speeds. I keep getting errors though.

I was able to track down the original author to their old website:
https://web.archive.org/web/20011203100331/http://newted.dyndns.org/users/bsmith/NCUHack.htm
https://web.archive.org/web/20071213010825/http://newted.dyndns.org/users/bsmith/NCUHack.htm

Might anyone have current contact information for them? The email address that was listed on their site, bradley@smith.net, is now inactive/invalid.

Thanks!
 
Does the Newton use the same kind of serial controller chip as a Mac?
The 115200 and 230400 baud rates need to bypass the baud rate generator.
This requires changing a byte in the SCC initialization routine.

For Open Firmware 1.0.5 on a Power Mac 7500/8500/9500/8600/9600 etc.:
Code:
Serial Port Device arguments:

- You can set the default baud rate by setting the output device to this:

ttya:57600

57600 is the max baud rate. To get 115200 and 230400 do the below:



Serial Port Open Firmware mods:

dev ttya
44 ' open c4 - l!
0 ' open ec - l!

The first line selects the device that will have it's init routine modified by the next 2 lines.

The second line changes the init routine so that it will set the number of stop bits to 1. The
default (using 4C hex) is two stop bits even though technote 1061 says to set the number
of stop bits to 1 in the communications app that you are using.

The third line changes the init routine so that it will select the RTxC pin (3.8MHz) for the
receive and transmit clocks. The default (50 hex) selects the Baud Rate Generator. The RTxC
pin is used to get 230400 bps. Change the value in line 1 from 44 to 84 to halve the baud
rate (with line 2, that gives 115200 bps).
 
This requires changing a byte in the SCC initialization routine.

I understand that the newer serial driver also supports control codes to select the faster baud rates: "The SerialDMA driver supports two new csCodes, 115 and 230, by which its Control routine"

See the attached tech note.
 

Attachments

Does the Newton use the same kind of serial controller chip as a Mac?
The 115200 and 230400 baud rates need to bypass the baud rate generator.
This requires changing a byte in the SCC initialization routine.

For Open Firmware 1.0.5 on a Power Mac 7500/8500/9500/8600/9600 etc.:
Code:
Serial Port Device arguments:

- You can set the default baud rate by setting the output device to this:

ttya:57600

57600 is the max baud rate. To get 115200 and 230400 do the below:



Serial Port Open Firmware mods:

dev ttya
44 ' open c4 - l!
0 ' open ec - l!

The first line selects the device that will have it's init routine modified by the next 2 lines.

The second line changes the init routine so that it will set the number of stop bits to 1. The
default (using 4C hex) is two stop bits even though technote 1061 says to set the number
of stop bits to 1 in the communications app that you are using.

The third line changes the init routine so that it will select the RTxC pin (3.8MHz) for the
receive and transmit clocks. The default (50 hex) selects the Baud Rate Generator. The RTxC
pin is used to get 230400 bps. Change the value in line 1 from 44 to 84 to halve the baud
rate (with line 2, that gives 115200 bps).
Ah dang, I guess I can't use this then. I'm using Basilisk II with a Serial port mod, and the NewtonDev setup, to connect to Einstein. Is there a way to patch an Old World rom, mainly the "1995-04 - 064DC91D - LC, Performa 580 & Performa 588.ROM" file instead? Thanks :)
 
Ah dang, I guess I can't use this then. I'm using Basilisk II with a Serial port mod, and the NewtonDev setup, to connect to Einstein. Is there a way to patch an Old World rom, mainly the "1995-04 - 064DC91D - LC, Performa 580 & Performa 588.ROM" file instead? Thanks :)

Newton

https://newtonresearch.org/connection/ link appears to have a package Ser115200.newtonpkg that allows a Newton to use 115.2 kbps.

Maybe that Ser115200.newtonpkg package can be patched to allow 230400 bps. I don't know how to take apart, modify, and rebuild a package. The post at https://newtontalk.newtontalk.narkive.com/Bem61qQB/help-serial-connection-pc-to-newton-suddenly-dead has a Ser230400.pkg but I don't know if that's patching the same thing or why doesn't NCX have a 23400 package?


68K/PowerPC Mac

If the Mac doesn't have the csCodes 115 and 230, then the serial controller chip needs to be programmed manually to obtain those baud rates.
#38 #29
The baud rate needs to be overridden every time it's set by the communications software. You might need to patch the communications software or patch the serial driver.


Serial ports for modern Mac/PC

You can get USB to serial adapters that support 115.2 kbps and 230.4 kbps. I have a Keyspan USA-28 and a Keyspan USA-28X that works with my Intel Mac running macOS Monterey using Serial.app's built-in drivers. Outside of Serial.app, I have to use the Keyspan drivers (Copyright © 2000-2009 Keyspan (August 12, 2009))


Emulation

You want to connect an emulated Newton to an emulated Mac? Maybe you can describe the connection you want to make, and what hardware/software you are using for the guest and host machines.

If they're both emulated, then serial port speed can be unlimited if they're running on the same host and they ignore baud rate (i.e. they don't try to limit bandwidth so a byte is transmitted instantly instead of waiting for baud period x 10 bits).

I don't know how the serial ports on Basilisk II or Einstein are created or setup. For DingusPPC, the serial port can be a unix domain socket. The `socat` command can be used to connect the socket to the terminal, a serial device, or another unix domain socket. Only the first has been tested using Open Firmware on the guest machine. That required some text pacing in DingusPPC to allow unlimited pasting of text into the terminal window. Text pacing means not always returning a character when Open Firmware reads the serial port because Open Firmware reads the serial port more often than it can buffer the characters which is strange - why read the serial port if you're not going to keep the character? Open Firmware has a `dl` (download) command which has it's own serial port reading loop which gets around that problem.

DingusPPC only emulates PowerPC Macs. That means System 7.1.2 or later. It's serial emulation doesn't support DMA yet.

I suppose the serial port emulation of DingusPPC will need the option of directly using a serial device so that it can pass different serial port options (baud rate, etc.) directly from the guest OS to a real serial port. If this is what Basilisk II is doing, then the 68K/PowerPC Mac notes above apply.
 
For Basilisk II, the serial ports can also be Unix sockets. I don't know about Einstein, unfortunately. I also don't know what the buffer limitations are, but I do seem to remember with BII having issues where I wasn't able to clear the buffer quickly enough during some experiments I did years ago.

If you want more accurate serial timing on 68K emulation, you may be better off going with QEMU or MAME. I do know that Basilisk II doesn't support an external clock on the serial line (probably not an issue in this instance where both emulators would be running on the same hardware).
 
I just realized something, selecting the higher baud speeds in Einstein, when connecting to NCU in Basilisk II, may not make any difference at all :unsure: :oops: 🤯 😬 I've been preoccupied with prepping for a move and didn't even think about that 🤣 I have no way to actually confirm if the higher baud speeds actually do anything at all 🤣
 
Is there no serial terminal app for Newton? You can time how long it takes to transmit a file to determine if the baud rate has any effect.

The baud rate in DingusPPC has no effect because it's using a unix domain socket and data is transmitted as bytes instead of bits and I guess the data sent to the socket is buffered. The receiving app (`socat` running in Terminal.app) can receive the bytes as fast as they are transmitted. This makes the Open Firmware command line really snappy (the baud rate set in Open Firmware is ignored so Open Firmware commands like dump-device-tree output really fast).

Transmitting to Open Firmware is another matter. DingusPPC needs to slow down the receive rate for the Open Firmware command line because Open Firmware will try to read from the SCC even when it is not able to buffer the character. DingusPPC serial port receive from socket passes a byte from the socket only for 15 out of 800 reads from the SCC (this means reading from the SCC indicates no characters available most of the time so that the Open Firmware buffer does not overrun). This text pacing feature in DingusPPC needs to be modified so that it goes away after Open Firmware has quit.
 
Back
Top