Atari TT030 and system V

[wbyte]

Regarding MMU support in emulators...

Aranym emulates 040 and its (simpler) MMU.

While latest Hatari can emulate those, it can emulate also 030, its MMU and instruction & data cache.

Once Hatari implements SCSI driver for TT emulation - we'll have an emulator capable to run ASV

[Eero Tamminen]

Thomas added initial read-only SCSI support to Hatari week ago:
https://hg.tuxfamily.org/mercurialroot/ ... a699fbcee8

And option to enable it:
https://hg.tuxfamily.org/mercurialroot/ ... dd1b83f34e

Is read support enough?

I think that like MiNT, ASV needs also (attached) patch to ignore TT SCC regs probing as SCC isn't emulated yet by Hatari.

tt-scc-workaround.patch.txt

[Richard]

So been sorting through some stuff and came across these....

[arf]

So been sorting through some stuff and came across these....

Congrats, nice find!

[mikro]

So been sorting through some stuff and came across these....

Welcome back, Richard! As you can see, thanks to your hard disk image a lot of good stuff has happened. Please image the floppies, too. :)

[tenox]

So been sorting through some stuff and came across these....

Wow this is super cool. Any chance you could image these?

[Richard]

Ok, disks imaged using DD. Only one did not image. These have not been tested, so if someone could do the honours and let me know.

Disk that didn't image:

Atari System V - Rel. 4.0, Vers. 1.1-06 Supplemental Diskette Disk 1/1

Imaged Disks:

ASV1.IMG - Atari System V - Rel. 4.0, Vers. 1.1-06 Boot Diskette Disk 1/1
ASV2.IMG - AIX SysAdmin Specs
ASV3.IMG - Atari System V - Update for GEM->Motif Example TAR Format Disk 1/1 (Hand written notes: 12/20/91 New Master Owner Problem Solved)
ASV4.IMG - Atari System V - Rel. 4.0, Vers. 1.1-06 Supplemental Diskette
ASV5.IMG - Atari System V - Rel. 4.0, Vers. 1.1-06 libXm.Z [Update]
ASV6.IMG - Atari System V - Rel. 4.0, Vers. 1.1-06 Post XDM Update
ASV7.IMG - ASV Update 1.1 Disk 1/3 Feb 25, 92
ASV8.IMG - ASV Update 1.1 Disk 2/3 Feb 25, 92
ASV9.IMG - ASV Update 1.1 Disk 3/3 Feb 25, 92
ASV10.IMG - FuncSpecs SysAdmin 9/28/90
ASV11.IMG - SetBoot Version 1.1 Source Code TOS Version February 18, 1992

Some interesting bits there...

Richard.

[leech]

GEM > Motif? That would have been awesome to see some old GEM programs ported to X11/Motif. Of course these days it would be cooler to do Qt/GTK > GEM.

[tenox]

Thank you!!!!!!!!!! I'm going to upload these to http://www.atariunix.com/

[Richard]

Thank you!!!!!!!!!! I'm going to upload these to http://www.atariunix.com/

No problem.

Was thinking about digging out one of my TTs and plugging the ASV hard disk in, although lugging the huge ecl monitor our of storage might be tricky.

[viking272]

Sounds like a plan Richard!

Tenox, on your AtariLinux site you mention that the build was getting newer versions/updates - is someone looking into this? An interesting project!

[Eero Tamminen]

Thomas added initial read-only SCSI support to Hatari week ago:
https://hg.tuxfamily.org/mercurialroot/ ... a699fbcee8

And option to enable it:
https://hg.tuxfamily.org/mercurialroot/ ... dd1b83f34e

Is read support enough?

I think that like MiNT, ASV needs also (attached) patch to ignore TT SCC regs probing as SCC isn't emulated yet by Hatari.

tt-scc-workaround.patch.txt

And now there's write support:
https://hg.tuxfamily.org/mercurialroot/ ... 09030b595b

[tenox]

No problem.

Was thinking about digging out one of my TTs and plugging the ASV hard disk in, although lugging the huge ecl monitor our of storage might be tricky.

Inventronik now has a cheap ECL2VGA adapter for 25 Euro. I have personally not tested it but it could work on a modern LCD monitor.

[tenox]

Sounds like a plan Richard!

Tenox, on your AtariLinux site you mention that the build was getting newer versions/updates - is someone looking into this? An interesting project!

Yeah I am in spare time. To date what has been done are some basic software ports here: http://www.atariunix.com/sw_ports/

Before more ports are made I also want to consolidate the available ASV disk images in to one combined image with all the software.

[leech]

I need to give this a play. Wonder how hard it would be to add Lightning (hence a USB stack) to it.

[arf]

I need to give this a play. Wonder how hard it would be to add Lightning (hence a USB stack) to it.

Easy! You just need to know how write device drivers for ASV. And a USB stack for ASV. Talking to the Lightning itself is easy, as there’s free code to do so.

[leech]

I need to give this a play. Wonder how hard it would be to add Lightning (hence a USB stack) to it.

Easy! You just need to know how write device drivers for ASV. And a USB stack for ASV. Talking to the Lightning itself is easy, as there’s free code to do so.

Haha, anyone around here write a USB stack? How close is ASV to say a BSD?

[derkom]

How close is ASV to say a BSD?

Well, for starters, it's SysV, not BSD.

[leech]

How close is ASV to say a BSD?

Well, for starters, it's SysV, not BSD.

Yeah, Unix systems are all similar.. but different enough to be annoying. Only thing out there that has so many different variants. One can somewhat jump from one to the other, but there are always weird little things. And the driver APIs are vastly different of course.

My question was simply how close are they in any sort of driver compatibility to ease porting. I know Linux has done so many different things on how it handles devices that it's probably no where near what SYSV should need.

Hell, if someone can fork / port a file system like ZFS from Solaris into *BSD/Linux, taking a USB stack from one of those and putting it into SYSV can't be too hard, right (read 'too hard' as not impossible).

Edit: https://danielmiessler.com/blog/the-dif ... em-v-unix/ kind of a short but sweet useless summary, give us the details!

[mfro]

ASV drivers *can* be written (have done a slip driver for it decades ago). Driver structure is very similar to SCO Unix (that much later became famous for different reasons). Examples can be found somewhere on the net.

What's completely undocumented (and unknown, at least to me) is the structure of the hardware device probe routines that get executed on kernel startup (that trigger kernel reconfiguration/driver inclusion if they find a new or missing device). They look more like firmware than part of an OS.

[derkom]

What's completely undocumented (and unknown, at least to me) is the structure of the hardware device probe routines that get executed on kernel startup

Given that it's a port of UniSoft UNIX, it's probably a moderately safe assumption that it's similar or identical to the approaches used in some of their other contemporary ports. I would suggest looking perhaps at A/UX (their 68k Macintosh SysV port), which became a lot more mature, and is certainly much better documented.

[tenox]

Good news is that ASV is SVR4 which was most widely ported SysV our there. Solaris 2 for which sources are available was SVR4.

[leech]

So it could be possible to implement some new drivers (if we could get coders to do so). Get VME and video support and we could have a cool Unix workstation going. Not sure how useful that would be, definitely would have the cool factor though!

[tenox]

Yeah I think the most important driver would be a non-Riebl NIC driver, for instance RTL8019AS / EtherNEC. Regarding cool unix workstation I tried to use TT in this matter for a while but unfortunately it's just too damn slow.

[leech]

Yeah I think the most important driver would be a non-Riebl NIC driver, for instance RTL8019AS / EtherNEC. Regarding cool unix workstation I tried to use TT in this matter for a while but unfortunately it's just too damn slow.

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.