Finally got around to writing up my porting GCC to the Tektronix 4404. It proved tricky…
Link to article:
Porting GCC to Tektronix 4404 with K&R C compiler from 1979
10 Likes
That’s a really good read, thanks!
It feels worth highlighting your video showing the 4404 selftest (including sound test!) and a demo of Uniflex and then smalltalk, then your own windowing system, and microemacs:
Interesting scrollable 1k x 1k display with a 640x480 visible area!
cd /
rm core
4 Likes
After many many months of work I have MAME running Uniflex too.
Trying to get it to the point where others can easily download and double click to run it all setup and ready.
(Writing some graphics demos at the moment)
4 Likes
What kind of effort was it to add a computer to the MAME framework once you had your head around how Mame worked? You mention, many months of work but can you elaborate? What were the main pain points?
[I still dont fully understand how MAME works! There is a lot template magic used to confiigure drivers and finding the right person that can explain it to you takes time and effort. ]
So. There was a tek4404.cpp when I arrived - sure, it didn’t work but it had some partial memory maps declared and gave a starting point.
Tek4404 has a custom MMU, so figuring out how the hardware worked took time. It also uses the 68010 cpu - there are lots of arcade games that use 68010 - but they dont do virtual memory so dont need to deal with restarting instructions and bus errors etc. This part of MAME 68010 emulation was just broken - I have a PR for the fix but getting those accepted is a grind so I’m not holding my breath it will be merged.
The hard disk controller is a ncr5385. Again, amazing work has been done on emulating this chip but it took months to track down why tek4404 would just hang a second after starting to load the OS. Using Ghidra and single stepping through the Unix operating system boot sequence (!) showed that the IRQs generated by the ncr5385 were happening too fast and the Tek4404 was missing it and hanging. Debugging machine code for a preemptive scheduling operating system was… hard.
Then there were further race conditions with ncr5385 IRQs that would cause a SCSI lockup when the disk was being hit hard. Finally figured sufficient delays added to the interrupt request in ncr5385.cpp to give reliable disk operations.
Tek4404 uses the NatSemi 32081 floating point chip and this has an almost cycle accurate implementation in MAME and was straight forward to integrate.
Network card uses the Lance chip which MAME’s implementation “just worked”.
Had some problems emulating the tek4404 mouse but it was very similar to the Atari ST mouse and the community is pretty good at offering help - if you can get their attention!
So. A really fun (if daunting) project. MAME definitely suffers from the “architecture momentum” that comes with large codebases so everyone I’ve talked with are smart in the community and know somethings aren’t great but its really tough to figure a way of improving stuff without breaking 30,000 drivers! Standard problem really…
Bottom line. If there is a driver that is close to what you want to do, its probably a lot of less brutal than my experience!
2 Likes
Back when I was researching the history of Smalltalk, I found out that Xerox had released three versions of it to three computer manufacturers as a “field test”: Apple Computer, Digital Equipment Corp., and Tektronix. The interesting thing for me about the Apple version is they actually made it available to developers, but they didn’t advertise it. This fact just got around by word of mouth. People had to write in to Apple to get a copy, and they’d ship it to them just for the cost of shipping. You needed what was considered a powerful machine to run it, though. I read that people who ran it typically used a Lisa 2, with 1 MB of memory. I guess a Mac Plus would’ve worked, too.
It was nice seeing the Tektronix version. It reminded me a lot of a demo I saw from Georg Heeg, who ran it on an Atari Mega ST (in emulation). It ran just like this. Since the full screen size didn’t fit in the Atari’s monochrome mode, the screen scrolled around. What astonished me is that a commercial version of Smalltalk-80 was actually sold for the Atari ST by ParcPlace Systems. I thought gosh, if I’d known that at the time, I would’ve bought a copy, since in the early '90s, I was using a Mega STe. I would’ve needed a monochrome monitor to run it, but I would’ve gone through with it. 
That would’ve been thrilling!
4 Likes
You had to be part of Apple’s development program to buy Smalltalk from them. It was very low cost, but a bit more than just the cost of shipping. It came in 7 floppies and there was a little program to join the pieces of the image and sources file once you copied them to a hard disk. There was also a stripped down version which fit those files in a single floppy and could barely run on a 512KB Mac.
I was lucky to know a guy who was in the development program and got him to buy it for me.
5 Likes
You can download the Apple version from the Macintosh Repository site, nowadays.
For compatibility, this page states:
Per pre-release documentation, this will not run on an original Macintosh, the Mactinosh 512K could only run a stripped down version, and the Macintosh XL with 1 MB RAM was required to utilitize the entire program.
3 Likes
Damn that must be a tight squeeze in 1MB! Smalltalk does generate a lot of instances (and garbage) - I believe the received wisdom was virtual memory (VM) was essential to run anything but trivial code in Smalltalk.
Short clip from a longer vid showing Smalltalk-80 running on Tektronix 4404 with 2MB of memory / 8MB virtual memory and hardware scrolling display.
2 Likes
Thanks for the link to the Apple Smalltalk-80! Many years ago Dan Ingalls asked if anyone had a copy since he had lost his. I tried to convert the floppies into something I could send him over the Internet and it was a quite an adventure that didn’t work in the end. I also found out that one of my 7 floppies had gone bad.
3 Likes
I learned in the last year that Kim McCall and Larry Tesler created a very stripped down version of Smalltalk at Xerox that ran on an Intel 8086 computer with 64K of memory! They called it TinyTalk. They said they completely stripped out the graphics library. It was just a command-line interface, but there was space for the incremental compiler, the standard class library, and a source-language debugger. They said in the end, there was 8K of program memory left, really only suitable for students just learning OOP.
2 Likes
Believe the very first versions of Smalltalk were written in BASIC.
Be great to find the source code for that! I imagine it would be quite messy.
The very first version was in Basic, surprisingly enough. The way Alan Kay said it, this was Dan Ingalls’s idea. Ingalls said, “You just do it, and it’s done.” This version ran on a DG Nova minicomputer. It was really a proof of concept. It ran slowly, but “stately,” as they put it. All the other baseline versions were written in microcode on the Alto, or later models, and Nova assembly language, with a small amount of BCPL, I think for boot code. There was also a lot of Smalltalk code in the system, of course.
TinyTalk was a porting effort. Another one was when ST-78 was brought over to the NoteTaker, which ran on 3 Intel processors, and had much more memory than what the TinyTalk project had at its disposal. More had to be handled by the VM, since the processors couldn’t be microcoded. A few system features had to be dropped, or implemented differently, for this reason, as well.
1 Like
Yes, the Data General Nova BASIC implementation of Smalltalk-72 was quickly replaced by an assembly version which was easily ported to the Alto (the sources for that are available). You can run older versions of Smalltalk in your web browser in the Smalltalk Zoo.
2 Likes
Many years ago, Dan Ingalls put ST-72 on the web, and I played around with it. It was a little broken, since it was based off of an original disk image. Some of the keyboard functions didn’t work, but if you put in the effort, you could work through a lot of the examples in the included manual.
A feature he put up was a “trace” tool you could use, so you could look at the disassembled machine code execute as you did stuff, but he called it “NOVA assembly”. I didn’t understand what he was talking about, until I read over more of the history of how Parc progressed with the different Smalltalk versions. Since the Alto was a microcoded architecture, they programmed it to run like a Nova. So, they were able to bring over the Nova machine code, and just run it on the Alto. I’ve heard from Alan that they liked the Nova architecture, anyway. So, why not continue working with it, even on a different machine? Nice.
The Alto had two differences relative to the Nova:
- the i/o instructions were eliminated and their opcodes reused for new Alto instructions (EIR, MUL, DIV, CONVERT, BLT and BLKS).
- addresses were increased from 15 to 16 bits eliminating indirect addressing, but allowing a 128KB memory space.
1 Like