Much as I enjoy writing new software for old computers, I do find the slowness of compilers etc a real drag.
The number of System calls + C runtime isn’t huge so I’m wondering whether I just write a wrapper around Darwin/BSD so I can edit-compile-run on my Mac. I could wrap the trivial graphics API (basically BitBlit) on the Tek4404 in a few hundred lines of code.
Like all my projects, I’m in the How hard can it be? phase. 
Any advice / thoughts from this forum?
Adam
In the early days of Raspberry Pi, I had a 35K line (of C) program I wanted to run on the Pi - it already ran on other Linux/Unix systems but while compiling on my desktop was a second or 2, it was 1.5 minutes on the Pi for a full compile, so I’d do lots of editing, compiling (or at least syntax checking) on my desktop before rsyncing the changed files over to the Pi for compiling and testing. That worked well enough for me.
But a well made Makefile and many smaller files also made a huge difference - only compiling files that actually changed and writing to a RAM disk too was a boon…
Of-course, I don’t know if this is available to you on that old system… And thinking of the Tek4404 - is there a classic Xterm for the Mac? That emulates Tek graphics terminals from what I recall…
As for speed - I have this “retronew” system that runs BCPL and while I can edit and compile directly on it, when a project gets over a few 100 lines of code it does start to become a bit slow, so cross comping on the desktop and copying the binary over is a thing for me, for now…
-Gordon
Blame the lack of ram for slow compilers, not the compiler on old machines. Compliers need a zippy file system, and OS’s never had ample ram for that, but virtual something best suited for 8k ram and BASIC for the monkeys… err students pounding on the TTY’s.
Punched cards have Monkeys .
As for modern machines, they need to write better code.
Not SD cards but Compact Flash is really needed for the Tiny machines.
Ben.
An interesting project for sure - something a little like WINE perhaps (which is Not an Emulator) - and perhaps something you could tackle step by step, with just a few system calls at first.
Surprisingly, this Tek machine is new enough to show up as a product announcement (or clarification) on Usenet in 1984:
Tektronix 4404 (Pegasus) correct information by Allen Wirfs-Brock, Software Project Leader, Tek 4404
Since there has been a fair amount of both correct and incorrect information concerning the Tek 4404 Artificial Intelligence System on the net, the time has come to set the record straight.
The Tektronix 4404 is a personal, desktop computer system oriented towards the development and delivery of AI oriented applications. It is a fully supported Tek product, backed by the Tektronix sales and service organization. The basic system is priced at $14,950.
The basic 4404 hardware includes:
- 10mhz (no wait states) 68010 processor
- 1 megabyte of RAM
- Virtual memory support hardware (max 8MB per process)
- Floating-point co-processor (National 32081)
- Monochrome bitmap display (1024x1024 “virtual display” over which a 640x480 viewport may be smoothly panned using the mouse.)
- The 128k frame buffer is directly addressable and is independent of the 1MB system RAM.
- The above mentioned mouse (3 button)
- 40 megabyte hard-disk (a recent change, it was originally announced with 20 MB)
- A 327KB (formatted) 5-1/4 inch floppy.
- RS-232, Centronics printer interface, keyboard, clock, sound, etc.
Standard software includes:
The Smalltalk-80 System. This is the full Smalltalk-80 system as developed at Xerox PARC with many enhancements and fixes by Tektronix. It is implemented via Tek’s proprietary Smalltalk-80 language interpreter. Benchmarks indicate that the performance of this implementation is approximately 2.5 times faster than the standard implementation on the Xerox 1100 (Dolphin).
The 4404 OS. This is a single user, multi-tasking OS with virtual memory support. The OS might be most accurately described as a “Unix act-a-like” i.e. it has a process model, file system, system calls, etc. which are generally equivalent to their corresponding Unix features. It is, however, not AT&T Unix. It is implemented in assembly language and is highly optimized for the 68000 family. The OS overhead, excluding network support, but including everything else in the kernel (buffers, VM support, etc.) is about 100K bytes. In addition it is FAST!
System 5 compatible C compiler and library. As well as an assembler, linker, and debugger.
ANSI 3.64 (i.e. VT-100) terminal emulator. This means both that a program running locally may view the keyboard and display as a ANSI standard terminal and that the entire system may be used as an ANSI terminal to a remote host.
Yeah, at least in the 90s I do remember (back when you compiled yourself everything) when compiling X11 that one needed to have the right libraries and headers to compile the Tek support, and there were some applications (CAD) that actually used the support, to show blueprints and such. Don’t know if the X11Rwhatever still has the support.
Cool project! But no, what I’m implementing is a compile time shim. For example, Uniflex creates a pseudoterminal pair with function:
create_pty(int pfd[2])
which I map to a call like this:
openpty(&ptfd[1], &ptfd[0], NULL, NULL, NULL);
So, simple stuff but I’ve got my telnetd for Tek4404 working (Woot!) and my window manager is coming along nicely. And before anyone says it, not a chance of getting X11 compiled on this K&R compiler!
Well I have Tek4404 Graphics libs implemented (enough) using SDL. Means my simple desktop window system now works. I can run emacs/vi in a window and compile too. Each instance of Window forks a shell running through a pseudo terminal and implements a complete-ish vt100 emulator inside the window display.
The display is 640x480 but is pans to the full 1024x1024 framebuffer just like the real thing.
