As folks probably know the Serial monitor console (
http://www.asterontech.com/Asterontech/NeXT_68040_Serial_Console.html) is only available if you've specifically set the PRAM setting to enable it first. This is a catch-22 if you haven't a working monitor and keyboard/mouse for your system.
Attached is a modified version of the commonly available V66 ROM (non-turbo) which will always enable the serial console if no monitor is attached.
This was a nice and simple modification as the ROM binary still mostly lines up with the ROM source floating around.
km.c:
/* switch console to SCC if monitor is not responding */
if ((km_send (MON_KM_USRREQ, KM_SET_ADRS(0)) & MON_NO_RESP) &&
mg->mg_nvram.ni_alt_cons) {
mg->mg_console_i = CONS_I_SCC_A;
mg->mg_console_o = CONS_O_SCC_A;
return (0);
}
Disassembly:
(prior to this is the call to km_send and checking of the monitor no response bit)
ROM:000082BE btst #3,$16(a2) ; check bit 3 (ni_alt_cons) of struct nvram_info in struct mon_global
ROM:000082C4 beq.s loc_82D6 ; do not enter if block when not set
Offset 82C4 needs to become 4E 71 (NOP) so we don't ever skip the if block.
After this is performed the checksum at offset 26 (decimal) must be updated. Attached is the original NeXT CRC algorithm as a Retro68 function. It was easiest to just run this on a 68k machine, so I did just that with a Macintosh SE/30.
Below is some quick code to use the CRC function where ROMTOCHECK is a byte array of the ROM file.
#pragma parameter __D0 calculateCRC(__A1,__D3)
uint32_t calculateCRC(uint8_t *addr, uint32_t count);
// offsets into the ROM header
#define MONCRC 26
#define ENETCRC 22
#define ROMLEN 0x20000
void verify() {
uint8_t* start;
uint32_t len, result, expect;
expect = *((uint32_t*)(&ROMTOCHECK[MONCRC]));
labelhexl("MonCRC expect",expect);
start = &ROMTOCHECK[MONCRC + 4]; // skip monitor CRC
len = ROMLEN - MONCRC - 4;
result = calculateCRC(start,len);
labelhexl("MonCRC",result);
puts(result == expect ? "CRC is OK\n" :"Bad CRC\n");
expect = *((uint32_t*)(&ROMTOCHECK[ENETCRC]));
labelhexl("ENETCRC expect",expect);
start = &ROMTOCHECK[0]; // from start of rom to enet crc
len = ENETCRC;
result = calculateCRC(start,len);
labelhexl("ENETCRC",result);
puts(result == expect ? "CRC is OK\n" :"Bad CRC\n");
}
Write it to an AT27C010 or similar DIP-32 ROM to use. Hopefully this helps someone.
Ah, just replied to your question on the accelerator thread.
I see how you did it. Nicely done
Quote from: ramalhais on May 28, 2025, 05:40:53 PMAh, just replied to your question on the accelerator thread.
I see how you did it. Nicely done
Unfortunately, this turned out to not be as useful as I might have hoped. It needs to clear the bootcmd as well so it drops into a monitor prompt.
Quote from: zigzagjoe on May 28, 2025, 08:09:54 PMUnfortunately, this turned out to not be as useful as I might have hoped. It needs to clear the bootcmd as well so it drops into a monitor prompt.
Maybe the code i used to do it may be useful for you:
https://github.com/ramalhais/linux/blob/linux-6.9.y-NeXT/arch/m68k/next/rtc.c#L154struct nvram_settings:
https://github.com/ramalhais/linux/blob/linux-6.9.y-NeXT/arch/m68k/include/asm/nexthw.h#L204
Quote from: ramalhais on May 28, 2025, 09:14:16 PMMaybe the code i used to do it may be useful for you:
https://github.com/ramalhais/linux/blob/linux-6.9.y-NeXT/arch/m68k/next/rtc.c#L154
struct nvram_settings:
https://github.com/ramalhais/linux/blob/linux-6.9.y-NeXT/arch/m68k/include/asm/nexthw.h#L204
Yeah, that jives with what I got out of the monitor sources. I specifically was trying to add null terminating the boot command at the same point the console switches to serial, but that didn't do anything productive. Should have been after the NVRAM was read and checksum'd, so not sure why it didn't work.
A little question on this topic:
I'd like to implement the serial console into Previous and am suffering an early issue: It seems that after testing the SCC during power-on test everything is screwed up (loopback mode is stuck). Is this something you also experience on real hardware? Do we have to disable power-on test to work on the serial console?
Quote from: andreas_g on May 29, 2025, 02:31:28 AMA little question on this topic:
I'd like to implement the serial console into Previous and am suffering an early issue: It seems that after testing the SCC during power-on test everything is screwed up (loopback mode is stuck). Is this something you also experience on real hardware? Do we have to disable power-on test to work on the serial console?
It seems like the SCC test screws up things temporarily but afterwards it's fine. I don't recall if I checked this on Turbo hardware also, but at least the two non-turbo stations I've been working with do this.
Early boot messages are also OK but afterwards I find once root is mounted (I think?) and the timestamp is displayed, it's always corrupt. Bits of sense can be seen but certain characters are always bad.
If you bind the serial console to the *step console it seems to continue be problematic. If you edit stty to use the serial port directly, it seems OK but then fights the serial console if that's set. I've found putting it on the second serial port seems to work reliably to log in however.
Example log attached.
Thank you for testing! This is what I get from Previous:
CPU MC68040 25 MHz, memory 100 nS
Backplane slot #0
Ethernet address: 0:0:f:0:f3:2
Memory size 32MB
Testing the FPU, SCCBoot command: en-s
boot en(0,0,0)-s
Requesting BOOTP information. [OK]
Booting /private/tftpboot/boot from nfs
..................................................................................................
blk0 boot: en()
Requesting BOOTP information. [OK]
Booting /private/tftpboot/mach from nfs
...init arg: -sx
Remote debugging enabled
NeXT ROM Monitor 2.5 v66
NeXT Mach 2.2: Mon Feb 3 09:00:33 PST 1992; /ph1_sources/projects/mk-108.28/RELEASE
FPU version 0x40
physical memory = 32.00 megabytes.
available memory = 30.81 megabytes.
using 16 buffers containing 0.12 megabytes of memory
fc0 at 0x2114100
SCSI 53C90A Controller, Target 7, as sc0 at 0x2114000
Generic SCSI Device as sg0 at sc0 target 7 lun 7
en0 at 0x2106000
en0: Ethernet address 00:00:0f:00:f3:02
IP protocol enabled for interface en0, type "10MB Ethernet"
dsp0 at 0x2108000
np0 at 0x200f000
sound0 at 0x200e000
root on en0
master cpu at slot 0.
primary network interface: en0 [10.0.2.15]
hostname: previous
whoami: no domain name
Thu May 29 16:17:11 MET DST 2025
Singleuser boot -- fsck not done
Faking root mount entries
Configuring ethernet interface to -AUTOMATIC-
Using default broadcast address.
en0: address automatically set to 10.0.2.15
en0: setting netmask to ffffff00, received from 10.0.2.2
Configuring local interface
Configuring hostname to -AUTOMATIC-
nfs returned new hostname: previous
erase ^? intr ^C kill ^U
#
As you can see it stops after testing SCC and then recovers when handling control from ROM to the boot program. So it seems this feature is quite buggy. Probably not worth implementing onto Previous.
Quote from: andreas_g on May 29, 2025, 09:27:03 AMThank you for testing! This is what I get from Previous:
CPU MC68040 25 MHz, memory 100 nS
Backplane slot #0
Ethernet address: 0:0:f:0:f3:2
Memory size 32MB
Testing the FPU, SCCBoot command: en-s
boot en(0,0,0)-s
Requesting BOOTP information. [OK]
Booting /private/tftpboot/boot from nfs
..................................................................................................
blk0 boot: en()
Requesting BOOTP information. [OK]
Booting /private/tftpboot/mach from nfs
...init arg: -sx
Remote debugging enabled
NeXT ROM Monitor 2.5 v66
NeXT Mach 2.2: Mon Feb 3 09:00:33 PST 1992; /ph1_sources/projects/mk-108.28/RELEASE
FPU version 0x40
physical memory = 32.00 megabytes.
available memory = 30.81 megabytes.
using 16 buffers containing 0.12 megabytes of memory
fc0 at 0x2114100
SCSI 53C90A Controller, Target 7, as sc0 at 0x2114000
Generic SCSI Device as sg0 at sc0 target 7 lun 7
en0 at 0x2106000
en0: Ethernet address 00:00:0f:00:f3:02
IP protocol enabled for interface en0, type "10MB Ethernet"
dsp0 at 0x2108000
np0 at 0x200f000
sound0 at 0x200e000
root on en0
master cpu at slot 0.
primary network interface: en0 [10.0.2.15]
hostname: previous
whoami: no domain name
Thu May 29 16:17:11 MET DST 2025
Singleuser boot -- fsck not done
Faking root mount entries
Configuring ethernet interface to -AUTOMATIC-
Using default broadcast address.
en0: address automatically set to 10.0.2.15
en0: setting netmask to ffffff00, received from 10.0.2.2
Configuring local interface
Configuring hostname to -AUTOMATIC-
nfs returned new hostname: previous
erase ^? intr ^C kill ^U
#
As you can see it stops after testing SCC and then recovers when handling control from ROM to the boot program. So it seems this feature is quite buggy. Probably not worth implementing onto Previous.
That period of glitchiness you post I notice lines up closely with my log. It recovers around the time the ROM tries its boot method. I would be curious if it continues working further in the boot process as I find that glitchiness starts happening again (regardless of the setting of the POT).
Serial console could be useful to have in a rudimentary form (just dump to a text file, or stdin/stdout) to facilitate tinkering. But not a priority feature for sure.