Sun 150 and semi-dead nvram

Well, it happened to me: while Sun blade said some reasonable Mac and SystemID, they did not match.
The following helped:
Take Ultra 10 (you own Ultra 10, don't you?), power it up, then hotswap nvram chip and use mkp with system id 0x83.
It will complain "nvram is wrong", but auto-boot. Then put the chip back to SB100.
The problem came when I plugged VGA display to SB, improperly grounded.
UPD: the nvram died permanently. So I had to break the chip and install CR2032 to feed it.

Installing Slackware 14.2 on Toshiba ac 100 with mainline kernel

The tasks:

• - switch to GPT partitioning and partition the EMMC
• - compile kernel, make it bootable
• - take slackware root

Before starting, keep at mind that internal EMMC is reffered as /dev/mmcblk0p, but if you plug SD card before loading... well, too early, it will became /dev/mmcblk0p, not 1p, as you can expect. This makes AC100 to boot at least root fs from SD card.
First, follow ARCH linux installation guide. The easiest way to compile kernel is to do it on some other ARM computer - saying, on Orange PI (Banana or Raspberry, if you prefer). Stop following this guide until you have only /boot (and /lib with kernel modules, and /etc/ with fstab) on your's EMMC card.
Then take Slackware arm root from here and copy it to EMMC (without boot and preserving /etc/fstab and /lib/kernel modules). Check twice you have a correct fstab (first, root fs and after you boot it - tmpfs and udev)
Next, take a full slackware-arm to sd card, boot the system, plug sd card, mount it, check you have udev running and.. you know what to do with slackware.

GammuTK - very basic TK gui for sending SMSes via GAMMU

Well, that does exactly what it does, and nothing more: it provides simple TCL/TK gui for sending [long][i18n] SMSes. It takes CSV file with phones, lets you edit the SMS and sends to selected numbers. Nothing more. Grab it here.

GNU screen on Mac OS X 10.4 & HP/UX 11.11

I love GNU Screen. But their maintainers are insane or lazy. Because they does not fix a bug which exists for a long long time. It affects at least Mac OS X 10.4 and HP/UX 11.11.
It compiles quite good. On Mac OS X you have to patch utmp.c changing makeuser() this way:

  (void)time(&now);
// DtZ   u->ut_tv.tv_sec = now;
  u->ut_time = now;

But when you start screen, it says "Abort trap". The problem in realpath() called in tty.c.: real = realpath(tty, NULL); On the systems mentioned, it does not work with NULL as the second argument, it wants char * resolved_path there.
So at least for Mac OS X this helps (and the code for HP/UX is very similar):

int
CheckTtyname (tty) 
char *tty;
{
  struct stat st;
//  char * real;
  int rc;
  char real[PATH_MAX]; // DtZ
 
  if (!realpath(tty,real)) return -1;
 
//  real = realpath(tty, NULL);
 
//  if (!real)
//    return -1;

UPD: In screen 4.4.0 looks like they fixed it! Great! So on HP/UX 11.11 the only thing to convince it to compile is to create empty file /usr/include/sys/select.h (because in the other case it says "Unable to use fifos and sockets" or like that)

68kavr ver 2560/0.00.02 is out

If anyone cares, I've updated my 68kavr firmware and BIOS. Lots of changes, but I'm lazy to build a normal release (because of summer) so this release is incremental. And, it is numbered 0.00.02!

8Mhz "On Semiconductors" 68008 runs at 12.5Mhz

From several sources I know that Motorola MC68k parts do not like to run on higher freqs then nominal.
At least that's not true for "On Semiconductors" parts.

Mathew Brandt's c68 and CP/M 68

While looking for C compiler for CP/M 68 looks I've found something that looks quite fine.
As for version "5.1 (beta)/25 Apr 2002" c68 taken from http://homepage.ntlworld.com/itimpi/compsrc.htm has
-cpm68 option and it somehow work. It even claims that it generates AS68compatible source.
There are a lot of versions of this compiler on the net, but this one is surely the best I've tried (but as I understand it's unable to compile itself, what a pity)
The way it does not work is writing hex as 0xXX, not as $XX, so here is a fix:
out68k_c.c:

PRIVATE void put_byte P1 (UVAL,val)
{        
    put_header (bytegen, alignment_of_type (tp_char));
    oprintf ("$%lx", (unsigned long) (val & OxffUL));
/*DtZ     oprintf ("0x%lx", (unsigned long) (val & OxffUL)); */
    outcol += 4; /* or  should be changed to +3 ? */
}

PRIVATE void put_word P1 (UVAL, val)
{
   put_header (wordgen, alignment_of_type (tp_short));
/*DtZ     oprintf ("0x%lx", (unsigned long) (val & OxffffUL)); */
    oprintf ("$%lx", (unsigned long) (val & OxffffUL));
    outcol += 6; /* or should be changed to +7? */
} 

Next, AS68 does not need/want "\t.sect", it accepts .data and .text directly.
out68k_c.c:

static void seg P3 (enum e_sg, segtype, const char *, segname, SIZE, al)
{
 nl();
 if (curseg != segtype) {                                                                                     
/*DtZ   oprintf ("\t.sect\t%s%s", segname, newline);*/                                                        
        oprintf ("\t%s * Segment %s", segname, newline);                                                       

And you should edit config.h the way it can generate for 68000 and to check the compiler binary you get can do -cpm68k and -int=16.
Next, remember that's just compiler, not even preprocessor: so on unix side I had to do
cc -E -I/home/dtz/8BIT/68K/CPM1.3/DISK4 main.c > p_main.c
./cc68 -int=16 -cpm68k -v p_main.c > main.s
Also, note that standard CP/M 68's headers lacks most of the C functions; so I had to copy them from "C language programming manual" (do not forget to add link link there!)
On CP/M system, assemble the file with AS68 -U file.o, and then link it with CLINK.SUB
UPD: More, the code it generates can be feed to jas assembler mentioned some time ago.
UPDD: Looks like optimization code is faulty.
UPDDD: 201607 Mirrored Here