TUHS

tuhs@tuhs.org

47 participants
6502 discussions

by Jason Stevens

You might find this interesting https://twitter.com/i/status/1320767372853190659 <https://twitter.com/i/status/1320767372853190659> It's a pi (arm) running Musashi a 68000 core, but using voltage buffers it's plugged into the 68000 socket of an Amiga! You can find more info on their github: https://github.com/captain-amygdala/pistorm <https://github.com/captain-amygdala/pistorm> Maybe we are at the point where numerous cheap CPU's can eliminate FPGA's? -----Original Message----- From: Michael Parson [SMTP:mparson@bl.org] Sent: Friday, February 05, 2021 10:43 PM To: The Eunuchs Hysterical Society Subject: Re: [TUHS] 68k prototypes & microcode On 2021-02-04 16:47, Henry Bent wrote: > On Thu, Feb 4, 2021, 17:40 Adam Thornton <athornton(a)gmail.com> wrote: > >> I'm probably Stockholm Syndrommed about 6502. It's what I grew up on, >> and >> I still like it a great deal. Admittedly register-starved (well, >> unless >> you consider the zero page a whole page of registers), but...simple, >> easy >> to fit in your head, kinda wonderful. >> >> I'd love a 64-bit 6502-alike (but I'd probably give it more than three >> registers). I mean given how little silicon (or how few FPGA gates) a >> reasonable version of that would take, might as well include 65C02 and >> 65816 cores in there too with some sort of mode-switching instruction. >> Wouldn't a 6502ish with 64-bit wordsize and a 64-bit address bus be >> fun? >> Throw in an onboard MMU and FPU too, I suppose, and then you could >> have a >> real system on it. >> >> > Sounds like a perfect project for an FPGA. If there's already a 6502 > implementation out there, converting to 64 bit should be fairly easy. There are FPGA implementations of the 6502 out there. If you've not seen it, check out the MiSTer[0] project, FPGA implementations of a LOT of computers, going back as far as the EDSAC, PDP-1, a LOT of 8, 16, and 32 bit systems from the 70s and 80s along with gaming consoles from the 70s and 80s. Keeping this semi-TUHS related, one guy[1] has even implemented a Sparc 32m[2] (I think maybe an SS10), which boots SunOS 4, 5, Linux, NetBSD, and even the Sparc version of NeXTSTEP, but it's not part of the "official" MiSTer bits (yet?). -- Michael Parson Pflugerville, TX KF5LGQ [0] https://github.com/MiSTer-devel/Main_MiSTer/wiki [1] https://temlib.org/site/ [2] https://temlib.org/pub/mister/SS/

4 years, 3 months

The UNIX Command Language (1976)

by Joachim

Apologies if this has already been linked here. "The UNIX Command Languageis the first-ever paper published on the Unix shell. It was written by Ken Thompson in 1976." https://github.com/susam/tucl Joachim

4 years, 3 months

Re: [TUHS] troff was not so widely usable

by Nelson H. F. Beebe

Recent discussions on this list are about the problem getting fonts for typesetting before there was an industry to provide them. Noted font designer Chuck Bigelow has written about the subject here: Notes on typeface protection TUGboat 7(3) 146--151 October 1986 https://tug.org/TUGboat/tb07-3/tb16bigelow.pdf Other TUGboat papers by him and his design partner, Kris Holmes, might be of reader interest: Lucida and {\TeX}: lessons of logic and history https://tug.org/TUGboat/tb15-3/tb44bigelow.pdf About the DK versions of Lucida https://tug.org/TUGboat/tb36-3/tb114bigelow.pdf A short history of the Lucida math fonts https://tug.org/TUGboat/tb37-2/tb116bigelow-lucidamath.pdf Science and history behind the design of Lucida https://tug.org/TUGboat/tb39-3/tb123bigelow-lucida.pdf ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

4 years, 3 months

Re: [TUHS] Macs and future unix derivatives

by M Douglas McIlroy

> Do they *really* want something which is just V7 Unix, with nothing else? > No TCP/IP, no hot-plug USB support? No web browsing? > Oh, you wanted more than that? Feature bloat! Feature bloat! > Feature bloat! Shame! Shame! Shame! % ls /usr/share/man/man2|wc 495 495 7230 % ls /bin|wc 2809 2809 30468 How many of roughly 500 system calls (to say nothing of uncounted ioctl's) do you think are necessary for writing those few crucial capabilities that distinguish Linux from v7? There is undeniably bloat, but only a sliver of it contributes to the distinctive utility of today's systems. Or consider this. Unix grew by about 39 system calls in its first decade, but an average of 40 per decade ever since. Is this accelerated growth more symptomatic of maturity or of cancer? Doug

4 years, 3 months

nothing to do with unix, everything to do with history

by ron minnich

There's so much experience here, I thought someone might know: "Our goal is to develop an emulator for the Burroughs B6700 system. We need help to find a complete release of MCP software for the Burroughs B6700. If you have old magnetic tapes (magtapes) in any format, or computer printer listings of software or micro-fiche, micro-film, punched-card decks for any Burroughs B6000 or Burroughs B7000 systems we would like to hear from you. Email nw(a)retroComputingTasmania.com"

4 years, 3 months

Typing tutors

by Will Senn

Hi all, On a completely different note... I’ve been delving into typing tutor programs of late. Quite a mishmash of approaches out there. Not at all like what I remember from junior high - The quick brown fox jumps over the lazy dog, kinda stuff. Best of breed may be Mavis Beacon Teaches Typing on the gui front, and I hate to admit it, gnu typist, on the console front. I’m wondering if there are some well considered unix programs, historically, for learning typing? Or did everyone spring into the unix world accomplished typists straight outta school? I did see mention a while back about a TOPS-10 typing tutor, not unix, but in the spirit - surely there's some unix history around typing tutors. Thanks, Will

4 years, 3 months

Re: [TUHS] Macs and future unix derivatives

by M Douglas McIlroy

> Or consider this. Unix grew by about 39 system calls in its first > decade, but an average of 40 > > per decade ever since. Is this accelerated growth more symptomatic of > maturity or of cancer? Looks like I need a typing tutor. 39 should be 30. And a math tutor, too. 40 should be 100. Doug

4 years, 3 months

Re: [TUHS] Macs and future unix derivatives

by Bakul Shah

$ k-2.9t K 2.9t 2001-02-14 Copyright (C) 1993-2001 Kx Systems Evaluation. Not for commercial use. \ for help. \\ to exit. This is a *linux* x86 binary from almost exactly 20 years ago running on FreeBSD built from last Wednesday’s sources. $ uname -rom FreeBSD 13.0-ALPHA3 amd64 Generally compatibility support for previous versions of FreeBSDs has been decent when I have tried. Though the future for x86 support doesn’t look bright. > On Feb 8, 2021, at 10:56 PM, John Gilmore <gnu(a)toad.com> wrote: > > (I'm not up on what the BSD releases are doing.)

4 years, 3 months

Re: [TUHS] [TUHS} Typing Tutor [and tuhs archive]

by M Douglas McIlroy

This topic is evocative, even though I really have nothing to say about it. Mike Lesk started, and I believe Brian contributed to, "learn", a program for interactive tutorials about Unix. It was never pushed very far--almost certainly not into typing. But the mention of typing brings to mind the inimitable Fred Grampp--he who pioneered massive white-hat computer cracking. Fred's exploits justified the opening sentence I wrote for Bell Labs' first computer-security task force report, "It is easy and not very risky to pilfer data from Bell Laboratories computers." Among Fred's many distinctive and endearing quirks was the fact that he was a confirmed two-finger typist--proof that typing technique is an insignificant factor in programmer productivity. I thought this would be an excuse to tell another ftg story, but I don't want to repeat myself and a search for "Grampp" in the tuhs archives misses many that have already been told. Have the entries been lost or is the index defective? Doug

4 years, 3 months

Re: [TUHS] Origins of globbing

by jnc＠mercury.lcs.mit.edu

> From: John Cowan > Unfortunately, glob never got its own man page Errr: https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/glob.8 Not the most comprehensive document, but that plus the source would be complete. Noel

4 years, 3 months

Tiny VT100 running 2.11BSD

by Mary Ann Horton

This is fun to watch! https://hackaday.com/2021/01/18/a-miniature-vt102-running-a-miniature-pdp11/ Mary Ann

4 years, 3 months

reviving a bit of WWB

by Doug McIlroy

I would like to revive Lorinda Cherry's "parts". Implicit in "revival" is dispelling the hundreds of warnings from gcc -Wpedantic -Wall -Wextra. Has anybody done this already? Doug

4 years, 3 months

2^n-bit operands (Was reviving a bit of WWB)

by M Douglas McIlroy

> Does anyone know why the computer industry wound up standardising on 8-bit bytes? I give the credit to the IBM Stretch, aka 7030, and the Harvest attachment they made for NSA. For autocorrelation on bit streams--a fundamental need in codebreaking--the hardware was bit-addressable. But that was overkill for other supercomputing needs, so there was coarse-grained addressability too. Address conversion among various operand sizes made power of two a natural, lest address conversion entail division. The Stretch project also coined the felicitous word "byte" for the operand size suitable for character sets of the era. With the 360 series, IBM fully committed to multiple operand sizes. DEC followed suit and C naturalized the idea into programmers' working vocabulary. The power-of-2 word length had the side effect of making the smallest reasonable size for floating-point be 32 bits. Someone on the Apollo project once noted that the 36-bit word on previous IBM equipment was just adequate for planning moon orbits; they'd have had to use double-precision if the 700-series machines had been 32-bit. And double-precision took 10 times as long. That observation turned out to be prescient: double has become the norm. Doug

4 years, 3 months

GBACA

by Mary Ann Horton

The topic of GBACA (Get Back At Corporate America), the video game for the BLIT/5620, has come up on a Facebook group. Does anyone happen to have any details about it, source code, author, screen shots, ...? Thanks, Mary Ann

4 years, 3 months

Re: [TUHS] for now [COFF] to follow up - why a byte is 8-bits

by Clem Cole

I will ask Warren's indulgence here - as this probably should be continued in COFF, which I have CC'ed but since was asked in TUHS I will answer On Wed, Feb 3, 2021 at 6:28 AM Peter Jeremy via TUHS <tuhs(a)minnie.tuhs.org> wrote: > I'm not sure that 16 (or any other 2^n) bits is that obvious up front. > Does anyone know why the computer industry wound up standardising on > 8-bit bytes? > Well, 'standardizing' is a little strong. Check out my QUORA answer: How many bits are there in a byte <https://www.quora.com/How-many-bits-are-there-in-a-byte/answer/Clem-Cole> and What is a bit? Why are 8 bits considered as 1 byte? Why not 7 bit or 9 bit? <https://www.quora.com/What-is-a-bit-Why-are-8-bits-considered-as-1-byte-Why…> for my details but the 8-bit part of the tail is here (cribbed from those posts): The Industry followed IBM with the S/360.The story of why a byte is 8- bits for the S/360 is one of my favorites since the number of bits in a byte is defined for each computer architecture. Simply put, Fred Brooks (who lead the IBM System 360 project) overruled the chief hardware designer, Gene Amdahl, and told him to make things power of two to make it easier on the SW writers. Amdahl famously thought it was a waste of hardware, but Brooks had the final authority. My friend Russ Robeleon, who was the lead HW guy on the 360/50 and later the ASP (*a.k.a.* project X) who was in the room as it were, tells his yarn this way: You need to remember that the 360 was designed to be IBM's first *ASCII machine*, (not EBCDIC as it ended up - a different story)[1] Amdahl was planning for a word size to be 24-bits and the byte size to be 7-bits for cost reasons. Fred kept throwing him out of his office and told him not to come back “until a byte and word are powers of two, as we just don’t know how to program it otherwise.” Brooks would eventually relent on the original pointer on the Systems 360 became 24-bits, as long as it was stored in a 32-bit “word”.[2] As a result, (and to answer your original question) a byte first widely became 8-bit with the IBM’s Systems 360. It should be noted, that it still took some time before an 8-bit byte occurred more widely and in almost all systems as we see it today. Many systems like the DEC PDP-6/10 systems used 5, 7-bit bytes packed into a 36-bit word (with a single bit leftover) for a long time. I believe that the real widespread use of the 8-bit byte did not really occur until the rise of the minis such as the PDP-11 and the DG Nova in the late 1960s/early 1970s and eventually the mid-1970s’ microprocessors such as 8080/Z80/6502. Clem [1] While IBM did lead the effort to create ASCII, and System 360 actually supported ASCII in hardware, but because the software was so late, IBM marketing decided not the switch from BCD and instead used EBCDIC (their own code). Most IBM software was released using that code for the System 360/370 over the years. It was not until IBM released their Series 1 <https://en.wikipedia.org/wiki/IBM_Series/1>minicomputer in the late 1970s that IBM finally supported an ASCII-based system as the natural code for the software, although it had a lot of support for EBCDIC as they were selling them to interface to their ‘Mainframe’ products. [2] Gordon Bell would later observe that those two choices (32-bit word and 8-bit byte) were what made the IBM System 360 architecture last in the market, as neither would have been ‘fixable’ later.

4 years, 3 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> From: Greg A. Woods > There's a "v6net" directory in this repository. > ... > I wonder if it is from either of the two ports you mention. No; the NOSC system is an NCP system, not TCP; and this one has mbufs (which the BBN v6 one did not have), so it's _probably_ a Berkleyism of some sort (or did the BBN VAX code have mbuf's too; I don't recall - yes, it did: https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP see bbnnet/mbuf.c). It might also be totally new code which just chose to re-use that meme. I don't have time to look closely to see if I see any obvious descent. > Too many broken half-baked MUAs seem to still be widely used. I'm one of the offendors! Hey, this is a vintage computing list, so what's the problem with vintage mail readers? :-) Noel PS: I'm just about done collecting up the MIT PWB1 TCP system; I only have the Server FTP left to go. (Alas, it was a joint project between a student and a staffer, who left just at the end, so half the source in one's personal area, and the other half's in the other's. So I have to find all the pieces, and put them in the system's source area.) Once that's done, I'll get it to WKT to add to the repositoey. (Getting it to _actually run_ will take a while, and will happen later: I have to write a device driver for it, the code uses a rare, long-extinct board.)

4 years, 3 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by Paul Ruizendaal

> V6, as distributed, had no networking at all. There are two V6 systems with > networking in TUHS: > > https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC <https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC> > https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6 <https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6> > > The first is an 'NCP' Unix (unless unless you have an ARPANet); the second is > a fairly early TCP/IP from BBN (ditto, out of the box; although one could write > an Ethernet driver for it). I’ve also done a port of the BBN VAX stack to V6 (running on a TI990 clone), using a serial PPP interface to connect. Experimental, but may have the OP's interest: https://www.jslite.net/cgi-bin/9995/dir?ci=tip > There's also a fairly nice Internet-capable V6 (well, PWB1, actually) from MIT > which I keep meaning to upload; it includes SMTP, FTP, etc, etc. I also have > visions of porting an ARP I wrote to it, and bringing up an Ethernet driver > for the DEQNA/DELQA, but I've yet to get to any of that. I’d love to have a look at that and compare and contrast the approaches. I’m finding that BBN’s original design, with a separate kernel thread for the network stack, is elegant but difficult to tune: too much priority and it crowds out user processes, too little and the slow PPP line is not kept busy. I think I’m beginning to understand why CSRG (and later also BBN) moved to the interrupt driven structure of 4.2BSD: perhaps it was also difficult to tune for a VAX with ethernet.

4 years, 3 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley > In the bootable images archive, there's the "Unknown V6" RL02 > image. I've tried that on SimH configured as an 11/23+ with 256kB of RAM > and it seems to work fine. Sorry, where's this archive? Somewhere in: https://www.tuhs.org/Archive/Distributions/Research/ I assume? From the description, that might be from the 'Shoppa disks'; didn't realize that was a /23 on those. > I would assume that Ethernet boards are available, but not supported on > V6. V6, as distributed, had no networking at all. There are two V6 systems with networking in TUHS: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6 The first is an 'NCP' Unix (unless unless you have an ARPANet); the second is a fairly early TCP/IP from BBN (ditto, out of the box; although one could write an Ethernet driver for it). There's also a fairly nice Internet-capable V6 (well, PWB1, actually) from MIT which I keep meaning to upload; it includes SMTP, FTP, etc, etc. I also have visions of porting an ARP I wrote to it, and bringing up an Ethernet driver for the DEQNA/DELQA, but I've yet to get to any of that. > it's hard to glean that wisdom from reading the manual. Yeah, DEC manuals went through a phase-change around about the time of the /23. Old DEC manuals are wonderful; stuffed to the gills with deep technical details. Suitable for engineers... Later, they turned into manuals for 'ordinary people' - 'plug cable C1 into plug P1'. Semi-useless; although one can often glean a few useful morsels if you trawl through the entire thing. That's why I've been doing PDP-11 pages on the CHWiki which attempt to cover a lot of technical detail, in a high technical content/size way. If you need something that's not there, let me know, and I'll get to adding it. Noel

4 years, 3 months

reboot(2) system call

by Warner Losh

I've done some research for a friend about when the reboot() system call was added, and how it related to the sync, sync, sync dance. https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html may be of interest. Please do let me know if I've gotten something wrong... Warner

4 years, 3 months

QED archive READMEs updated

by Arnold Robbins

Hello All. I have updated various READMEs in the QED archive I set up a while back: https://github.com/arnoldrobbins/qed-archive. Now included is a link to Leah's blog, mention that the SDS files came from Al Kossow, and Doug's link to the Multics QED cheat sheet. Thanks, Arnold

4 years, 3 months

[TUHS} Qed vs ed

by M Douglas McIlroy

> fairly early in PDP-11 development ed gained three features: & in the > rhs of substitutions plus k and t commands. (I'm not sure about & .... Oh, and backreferencing, which took regular expressions way up the complexity hierarchy--into NP-complete territory were it not for the limit of 9 backreferenced substrings. (Proof hint: reduce the knapsack problem to an ed regex.) Also g and s were generalized to allow escaped newlines. I was indeed wrong about &. It was in v1. Doug

4 years, 3 months

More archeology

by Jon Steinhart

Another stack of old notebooks. I can scan these in if anyone is interested and if they're not available elsewhere. In addition to what's below, I have a fat notebook with the BRL CAD package docs. These are V/W papers from Stanford - Lantz/Cheriton et. al. Multi-process Structuring of User Interface Software Refernce Models, Window Systems, and Concurrency An Experiment in Integrated Multimedia Conferencing An Architecture for Configurable User Interfaces An Empirical Study of Distributed Application Performance Third Generation Graphics for Distributed Systems Virtual Terminal Management In A Multiple Process environment Distributed Process Groups in the V Kernel The Distributed V Kernel and its Performance for Diskless Workstations Effective Use of Large RAM Memories on Diskless Workstations with the V Virtual Memory System Evaluating Hardware Support for Superconcurrency with the V Kernel Fault-tolerant Transaction Management in a Workstation Cluster File Access Performance of Diskless Workstations An Introduction to the V System The Multi-Satellite Star: Structuring Parallel Computations for a Workstation Cluster UIO: A Uniform I/O System Interface for Distributed Systems The V Kernel: A Software Base for Distributed Systems Other random stuff Bitmap Graphics (SIGGRAPH '84 Course Notes, Pike et. al.) A Window Manager with a Moduler User Interface (Whitechapel?) IRIS-4D Superworkstation and Visual Computing IRIS GT Graphics Architecture Position Paper on the Importance and Application of Video Mixing Display Architectures (Jack Grimes) A Data-Flow Manager for an Interactive Programming Environment (Paul Haeberli) Multiple Programs in One UNIX Process (Don Libes - from ;login:) Lightweight Processes for UNIX Implementation and Applications (Jonathan Kepecs) A Capability Based Hierarchic Architecture for UNIX Window Management (R. D. Trammell) MEX - A Window Manager for the IRIS (Rocky Rhodes et. al.) Windows for UNIX at Lucasfilm (Hawley, Leffler) Next-Generation Hardware for Windowed Displays (McGeady) Problems Implementing Window Systems in UNIX (Gettys) Mach: A New Kernel Foundation For UNIX Development (Accetta et. al.) Uwm: A User Interface for X Windows (Ganearz) Programming with Windows on the Major Workstations or Through a Glass Darkly (Daniel, Rogers) PIX, the latest NeWS (Leler) Ace: a syntax-driven C preprocessor Overview (Gosling) Attribute Considerations in Raster Graphics (Bresenham) Ten Years of Window Systems - A Retrospective View (Teitelman) W User's Manual (Asente) The WA Beyond Traditional Window Systems (An Overviw of The Workstation Agent (Lantz et. al., draft, marked not to to be redistributed) Performance Measurements of the WA (Islam) STDWIN: A Standard Window System Interface (Rossum) Summary of Current Research (Lantz et. al. at Olivetti) User Interfaces in Window Systems: Architechure and Implementation (Farrell, Schwartz; SIGCHI) Introduction to the GMW Window System (Hagiya) UNIX Window Management Systems Client-Server Interface Specification (Williams et. al., Rutherford Apleton Laboaratory) Curves Made Trivial (Gosling) Smart Code, Stupid Memory: A Fast X Server for a Dumb Color Frame Buffer (McCormack) Jon

4 years, 3 months

[TUHS} Qed vs ed

by M Douglas McIlroy

I used Ken's qed in pre-Unix days. I understand its big departure from the original was regular expressions. Unix ed was the same, with multi-file capability dropped. Evidently the lost function was not much missed, for it it didn't come back when machines got bigger. I remember that fairly early in PDP-11 development ed gained three features: & in the rhs of substitutions plus k and t commands. (I'm not sure about &--that was 50 years ago.). With hindsight it's surprising that a "minimalist" design had m but not t, for m can be built from t but not vice versa. A cheat sheet for multics qed is at h <http://www.bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condens…> ttp:// www.bitsavers.org/pdf//honeywell/multics/swenson/6906.multics-condensed-gui…. It had two commands I don't remember: sort(!) and transform, which I assume is like y in sed. Doug

4 years, 3 months

Qed vs ed

by Will Senn

Hi all, So. On a lighter note. I was tooling around the web and came across a discussion of QED, the editor. It’s been resurrected in no small part based on discussions on this list (and members like Rob Pike). Anyhow, there’s a version that compiles in modern systems and that handles wide characters. My question for the group is this how different is QED from ed? I’ve read Dennis’ paper on the history of QED and it’s fascinating, but all I really got out of the discussion related to ed, was that QED was a precursor. I’m curious about functional parity or lack thereof, more than technical differences. In full disclosure, and at the risk of drawing fire from lovers of other editors, I have to confess a love of the original ed (and it’s decendent ed’s and vi). Cheers, Will Sent from my iPhone

4 years, 3 months

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by jnc＠mercury.lcs.mit.edu

> From: Jim Geist > When did mmap(2) come about? Pretty sure it's a Berserkleyism. I think it came in with the VM stuff that DARPA mandated for VAX Unix (for the research project they funded). Noel

4 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS