Atari TT030 and system V

[arf]

Though one would think part of that might be due to memory swapping? Back when I first started using Linux, I think I had 32mb of RAM and it swapped a lot once I started up a few applications, which of course slows everything to a crawl.

It is not the swapping. The ~5 MIPS of a TT isn’t a huge amount of computing power.

I’ve got a 68040/33 (about 20-30 MIPS) with 128 MB RAM running with A/UX 3. The A/UX itself is quick & fast, but don’t even think of opening a X11 session to a modern computer and run something more advanced than xbiff, xclock and xeyes over X11 on that remote computer. Again, the computing is done on the modern machine, the 68040 only needs to the X11 drawing locally. 'nedit' is okay, but LibreOffice? Firefox? Chromium? Opera? Forget it. Painfully slow.

Why? It seems these modern software doesn’t really use X11 drawing primitives, but essentially implement their own drawing and then bitblt. Which means, the 680x0 receives near-full screen size huuuge bitmaps for every scroll line. Yaaawn.

Even faster MIPS-based X11 hardware accelerated terminals (HP Envizex II and similar) are basically unusable for such modern software.

But as tenox said, using a 680x0 as a 'modern' UNIX workstation is some (power of n) too small. Heck, Firefox is painfully slow on a Pentium II/300. And that CPU crushes the 68060 easily.

You may run what was up-to-date back then, and that’s incredible cool. Mathematica, Framemaker, gnuplot, LaTeX, dot/graphviz, elm, pine, tr, tin, all that.

[leech]

I wasn't thinking anything much beyond some terminals, bash and maybe python. Though I should learn Go at somepoint. Let's port Cowsay! I pointed that out to a coworker during a video conference much to the detriment of his concentration toward what people were saying. Ha!

[tenox]

Yeah, that was kind of what I was thinking. Though one would think part of that might be due to memory swapping? Back when I first started using Linux, I think I had 32mb of RAM and it swapped a lot once I started up a few applications, which of course slows everything to a crawl.

I think RAM and swap is least of an issue. My TT has 256MB RAM. Slow SCSI may have something to do with it, but mostly it's just slow CPU. We are used to snappy software written in assembly or low level C on TOS. Generic Unix is not that optimized unfortunately. It's usable but doesn't make a nice workstation in modern day terms.

[Noth]

So Tenox, what did those floppies from Richard yield as far as system updates to the OS? Nice to see there's a libXm floppy for Motif, since that's missing on both Mark & Richard's HDD images for some reason. Since various m68k System 4 Release 5 ports are binary compatible ( AMIX and Atari Unix CLI binaries are interchangeable so long as the libs are present)

For people fantasising about using a browser in ASV, as pointed out earlier the only usuable solution is to have Web Render Proxy running on an another machine that acts as a proxy and renders webpages to GIF which is fast to render on old systems. No need for remote X11 sessions or the like (even if they do work usually).

[RalfItzehoe]

About using a browser in ASV: that is no fantasy,

I have done that ca. 1993 / 1994, when Mosaic came out. I already had the (at that time) complete GNU toolchain ported to ASV (including emacs). Based on that, porting Mosaic was possible, although laborious, because, at that time, there was nothing like autoconf .

[Eero Tamminen]

I have done that ca. 1993 / 1994, when Mosaic came out. I already had the (at that time) complete GNU toolchain ported to ASV (including emacs). Based on that, porting Mosaic was possible, although laborious, because, at that time, there was nothing like autoconf .

Yes, you could view pages from early 1990, but not much anything recent, which is kind of a point of a browser.

Pages nowadays need JavaScript & CSS, and many things don't anymore support plain HTTP, so one often needs also SSL / crypto support (which is slow without special instructions in modern CPUs). All that, and the images on the pages require tens or hundred(s) of MBs of RAM too, not just lot of performance.

Any page you would want to view, would need to be designed specifically for low end machines and old browsers (HTML v2 etc). Or a special web proxy on faster machine that does suitable conversions.

[RalfItzehoe]

Yes, you could view pages from early 1990, but not much anything recent, which is kind of a point of a browser.

This is a philosophical question.

Why do we recreate / reactivate historical computers, operating systems and applications? There are lots of possible and legitimate answers, and we should try to be clear about which we adhere to in any given situation:

• An old application is still used after decades. Yes, this happens, and not only in atomic power plants. The primary goal will be to keep the application running in its context, sometimes adding memory, storage or CPU power, as needed. Practical example from 2018: a UNIX workstation from 1999 needs a hard disk replacement; the installed domain-specific CAD-software is still used.
• A museum-like presentation is intended. As much as possible of the original look-and-feel should be preserved; original hardware is preferred over virtualization. Memory, storage and CPU should be similar to the original situation. Practical example: demonstrate the internet environment, including the Mosaic browser, as it was in 1993/4.
• Sometimes, we like to do experiments based on old hard- or software. This is a little bit like Steampunk for computers. For example, how fast will an emulated C64 run on my hardware? Practical example: do an experimental installation of the GNU toolchain of 2018, starting with the software delivered with HPUX in 199x. Then install applications depending on the toolchain.

Concerning the browser, a museum installation would definitely present Mosaic, a textmode browser, but also FTP, NEWS, Mail, and Gopher. Not to forget X-Terminals. Part of the museum activity would be to identify matching servers which use old protocols and formats, or to recreate such servers.

It's just the Steampunk-option, where intermingling with 201x-technology becomes interesting. This is fun - and always motivating. But just a small part of possible motivations for computer archeaology.

Happy new year!
(each new year, ASV gets older and more precious!)

Ralf

[tenox]

Actually this is not true about browsers. I written a rendering web proxy that allows old web browsers to be used on modern web. Pages are rendered in an imagemap on the proxy and presented as a gif image + clicable map to the browser. I use Mosaic on ASV quite often. In fact here is an older screenshot:



You can read little more about it here:
http://virtuallyfun.superglobalmegacorp ... xy-update/

and here:
http://virtuallyfun.superglobalmegacorp ... -browsers/

the proxy is available here:
https://github.com/tenox7/wrp

[tenox]

Also it seems that Hatari developers have added SCSI HDD and MMU support, so this may be a reality soon.

asv-hatari.png

Unfortunately it crashes shortly after, but this should be debugable and fixable.

[leech]

Very nice tenox! I have seen a few proxies like that, there was one for Amiga.org at some point. My concern with them have always been that there is no encryption going on. Then again for our old systems, that is one of many points where web browsing fails, https.

[tenox]

I'm working on a new one with encryption. Obviously there would be no encryption between legacy browser and proxy, but provided that the proxy runs close to it (eg at your home) there should be no problem.

[Eero Tamminen]

Also it seems that Hatari developers have added SCSI HDD and MMU support, so this may be a reality soon.

Unfortunately it crashes shortly after, but this should be debugable and fixable.

Second MFP and some SCC improvements are still needed, and there are few missing items from SCSI emulation.

TT SCU & VME emulation is also completely missing, but Hatari doesn't produce bus errors for SCU.

To get Linux booting with TT-emulation, I had to do following change for src/ioMemTabTT.c:

Code: Select all

+//	{ 0xff8e01, 1, IoMem_ReadWithoutInterception, IoMem_WriteWithoutInterception },         /* SCU system interrupt mask */
+	{ 0xff8e01, 1, IoMem_BusErrorOddReadAccess, IoMem_BusErrorOddWriteAccess },         /* SCU system interrupt mask */