[cctalk] Fwd: CG14 and 16bit colour

[David Brownlee via cctalk]

In case anyone is interested in poking their cg14/sx in new and
exciting ways :-p

-- Forwarded message -
From: Michael 
Date: Tue, 23 Apr 2024 at 07:55
Subject: CG14 and 16bit colour
To: 


Hello,

I did a lot of work on the cgfourteen, sx and xf86-video-suncg14
drivers, one thing I didn't expect was people asking for 8bit
acceleration in X, mostly because with a 4MB cg14 you're limited to
1152x900 in 24bit colour, in 8bit you could go all the way to
1920x1200. So I wrote code for that.
Looking at the headers files, it looks like at least the DAC supports
16bit colour as well, which would allow 1600x1200 in more than 8bit
colour.
Getting SX to deal with 16bit quantities is not difficult, at least for
basic stuff like copy, fill and ROP operations. Xrender would be more
difficult since there is no easy way to separate / re-unite the colour
channels of a 16bit pixel. For 32bit it's trivial, SX has instructions
to split 32bit accesses to four registers, even lets you pick which
byte to take. So we wouldn't get xrender acceleration.
Then again, we don't have that in 8bit either.

The DAC is an Analog Devices ADV7152, and I just found the datasheet -
in 16bit mode we get R5G5B5, nothing unusual here.
That said, cg14 seems to use the DAC only for gamma correction, we
don't mess with it at all even when switching to 8bit, so who knows
what exactly cg14 feeds it when we set pixel mode to 16bit.
Shouldn't be difficult to figure out though.

I guess what I'm getting at is - does anyone particularly care about
this? I don't mind doing this as yet another Just Because I Can(tm)
project but if anyone cares I'd welcome their input.

have fun
Michael

[cctalk] Re: Z80 vs other microprocessors of the time.

[David Brownlee via cctalk]

On Wed, 24 Apr 2024 at 01:18, Bill Gunshannon via cctalk
 wrote:
>
> On 4/23/2024 8:06 PM, Fred Cisin via cctalk wrote:
> > Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502?
> >
>
> What about the Tandy 16 and 6000.  M68K and Z80.

If we're talking about machines with a Z80 and 6502, it would be
remiss not to link back to the machine mentioned in the original
message - the BBC micro, with its onboard 6502 and "Tube" interface
which could take a second processor option, including
- Z80
- 65C02 / 65C102
- NS 16032 (ahem 32016)
- 8088 (Torch) / 80186, 80286 (last developed but never released)
- ARM1 (Original ARM development board. Rare as hens teeth :) / ARM7
(someone having a laugh in later years)

Typically the second processor would run as primary, using the
original 6502 to handle input, display and I/O (and on 32016 you
*really* wanted someone else to deal with anything time critical like
interrupts :)

David

[cctalk] Re: ZFS, was [... GreaseWeazle ..]

[David Brownlee via cctalk]

On Thu, 2 Feb 2023 at 11:54, emanuel stiebler via cctalk
 wrote:
>
> On 2023-02-02 04:38, David Brownlee wrote:
>
>  > That reminds me (looks at 43.5T of zfs pool that has not had a scrub
>  > since 2021).
>  >
>  > It can be nice to have a filesystem which handles redundancy and also
>  > the option to occasionally read all the data, check end to end
>  > checksums (in the unlikely case a device returns a successful read
>  > with bad data), and fixup everything. Does not eliminate the need for
>  > remote copies, but gives a little extra confidence that the master
>  > copy is still what it should be :)
>
> So, what else do you guys use, to make sure your data is safe for the
> years to come?

Code which can be public in github, code which cannot be public in
free gitlab account, (code which evokes Cthulhuian mindworms on
reading and should never be shared with others is kept with other
locally backed up files).

The sata on the main machine is held on 6 disks in ZFS raidz2 (takes 3
disks to fail to lose data). Synced to two remote machines (ZFS in
simple config to give integrity but without local redundancy).

Sync is via syncthing with staggered file versioning (keeps 365 days
of changes for any given file). Most data is pushed only from the main
machine, with remotes also able to sync between them, but some folders
are set to sync between all.

Biggest vulnerability would be an exploit in syncthing, or some common
OS level exploit, as all data is online. ("A backup is not a backup
when its online, it's just a copy")

David

[cctalk] Re: HP 41-CX

[David Brownlee via cctalk]

I had some idea of trying to get money for an HP 41-CX a while back,
but on balance I think it's best to just go to someone who might be
interested in fixing it up and valuing it for what it is.

So - FTGH, just the cost of shipping (photo link below still valid)

David

On Sun, 19 Apr 2020 at 17:55, David Brownlee  wrote:
>
> I've come into possession of an HP 41-CX calculator - unfortunately it
> appears to have had batteries left in it which have left corrosion on
> the internal contacts.
>
> (some pics: https://photos.app.goo.gl/48bE7WJZP8R4PF9a9 )
>
> My classic hardware tendencies tend to run more towards the "can run
> *nix" end, and while I could just clean it up and throw it on eBay I
> wondered if anyone here has a 41C shaped soft spot and would be
> interested? (happy to trade/part trade for something they already have
> for which they are less fond if that works :)
>
> David

[cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man

[David Brownlee via cctalk]

On Wed, 1 Feb 2023 at 17:13, emanuel stiebler via cctalk
 wrote:
>
> On 2023-02-01 10:56, Warner Losh wrote:
> >
> > On Wed, Feb 1, 2023 at 1:41 AM emanuel stiebler via cctalk
> > mailto:cctalk@classiccmp.org>> wrote:
>
> > retension in case of power off.
> > If the power is applied all the time, the internal controller "can"
> > check the quality of the cells automatically (but this really
> > depends on
> > the controller, controller version, and the OS has to chose the right
> > strategy. And the controllers improved a lot lately)
> >
> >
> > The OS might not have a choice. All the SSDs that I've used in the
> > past decade at $WORK have not exposed any of this to the host, not
> > even enough stats to know when it's going on in real time... let alone
> > the ability to pause these operations for a little while until we're off
> > peak for the day...
>
> But you should be able to choose (at least on controllers I know) if you
> like to go for automatic or manual refresh.
>
> If you go for the automatic, it could happen that the drive decides to
> scan the drive, when your're busy and going nuts waiting for the drive
> (you can also define on newer drives how many block to check per run)
>
> If you're going for the manual refresh, just make sure you really run it
> one day. But, you should be the one who knows, when your computer isn't
> busy ...

That reminds me (looks at 43.5T of zfs pool that has not had a scrub
since 2021).

It can be nice to have a filesystem which handles redundancy and also
the option to occasionally read all the data, check end to end
checksums (in the unlikely case a device returns a successful read
with bad data), and fixup everything. Does not eliminate the need for
remote copies, but gives a little extra confidence that the master
copy is still what it should be :)

Its currently all on spinning rust, but I imagine zfs scrub should map
nicely onto refreshing SSDs with "read everything you care about,
write only on fixing up data" (in the unlikely event I can ever afford
sufficient SSD storage)

David

[cctalk] Re: Whitechapel Computer Works

[David Brownlee via cctalk]

On Fri, 4 Nov 2022 at 17:47, Jonathan Katz via cctalk
 wrote:
>
> Hi everyone!
>
> I'm curious; other than Wikipedia what do we know about Whitechapel
> workstations? Do any of us have some working in our collections, with
> software, disk dumps, etc?

I had quite a few back in the 90s when City University was
transitioning to Suns. Complete with 42nix and GENIX disks.

My last ones made it to Iain A F Fleming back at the end of the last
century, but I've no idea what happened after :/

David

Re: testing

[David Brownlee via cctalk]

FIN

On Thu, 10 Mar 2022 at 22:30, William Sudbrink via cctalk
 wrote:
>
> ACK
>
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of jwest---
> via cctalk
> Sent: Thursday, March 10, 2022 5:29 PM
> To: 'General Discussion: On-Topic and Off-Topic Posts'
> 
> Subject: testing
>
> Test test
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

Re: VAX9000 unearthed

[David Brownlee via cctalk]

On Sun, 20 Feb 2022 at 21:20, Bill Gunshannon via cctalk
 wrote:
>
> On 2/20/22 15:31, Chuck Guzis via cctalk wrote:
> > On 2/20/22 10:10, Mark Kahrs via cctalk wrote:
> >> I heard Butler Lampson once exclaim that ECL design was in some ways easier
> >> than TTL.  If you terminated every line, you get controlled impedances with
> >> controlled edges.  This was the design philosophy for the Dorado.
> >
> > Indeed--ECL WW prototype boards usually had a 3rd row for SIP
> > termination resistors alongside the DIP sockets.  One nice thing about
> > ECL is that there are many fewer problems with power rail spikes.  On
> > the other hand, the constant power consumption needs beefier power supplies.
> >
> > I recall that Honeywell redid one of their mainframe designs in ECL,
> > with somewhat disappointing performance results.  I don't recall the
> > details offhand.
>
> It's long enough ago that my mind is fuzzy, but I think Primes were
> ECL.
>

Gould made a set of realtime and (via a board swap) unix systems - we
had a few PowerNode 6040s and one 9080 at university. One of the
6040's was mostly consumed by providing NFS to the other machines. I
remember at the time being impressed that the ffs had on disk padding
for 64 bit timestamps.

When the university stopped using them the CS department just left
their 6040 running unmonitored over the summer, and came in to find
the aircon had partially flooded the room then failed, and the machine
was happily still running in a shallow pool of slightly steamy water
(it was, shall we say, not in a purpose built room)

I also heard a possibly apocryphal story that the royal navy was
tendering for an onboard computer for a sub: various suppliers found
that their sample machines kept crashing, and the gould was the only
one able to run reliably - turned out the installation location was
quite close to "power generation equipment" and had been selected as
the ambient temperature was too high to put anything else there

David

Re: OT: looking for help remembering name/info about security bug

[David Brownlee via cctalk]

On Tue, 11 Jan 2022 at 06:04, Stan Sieler via cctalk
 wrote:
>
> Hi,
>
> I'm trying to remember the name (and some information about) a past
> security bug, for an article.
>
> Somewhere between 4 and 6 years ago (I think), there was a fairly major
> security bug reported (probably in Linux, or in SSH code, but
> something widely used).
>
> IIRC, the bug was a single line that called a function (possibly along the
> lines of CredentialsCheck), and may have involved a bit-wise or (or and)
> instead of a logical one.
>
> It may have been that either the routine wasn't getting called when it
> should, or that the programmer misinterpreted what the return value meant.
>
> Ring any bells?

Just on the offchangce the bell might be named "Apple" (it's a goto
fail rather than a bit-wise issue)

https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/

David

Re: Terminal Emulator for Android

[David Brownlee via cctalk]

On Sun, 31 Oct 2021, 20:37 Chuck Guzis via cctalk,
 wrote:
>
> On 10/31/21 1:06 PM, Douglas Taylor via cctalk wrote:
> > I would like to use my tablet, Samsung Tab E model SM-T560NU, to connect
> > to my VAX and Linux computers.  There seem to be a large number of
> > 'Apps' out there.  What is a good one to use?
> >
> > The VAX doesn't have SSH only insecure TELNET.  Another can of worms,
> > SSH on the Vax?
>
> You might do what I do--isolate your vintage/old machines on their own
> sub-net with no connection to the outside.  It's not as if you'll do web
> browsing on the VAX, after all.

Was always a fan of links for web browsing on my VAXstation 90, I
think I never got anything bigger than dillo or netsurf to run
natively. Of course it also made a workable X display for Firefox from
a bigger machine :-p. (this was not under VMS tho')

As others have said JuiceSSH supports telnet which should be fine for
VMS and ssh or even mosh for Linux or other 'nixes

Re: Linux and the 'clssic' computing world

[David Brownlee via cctalk]

On Mon, 25 Oct 2021 at 11:39, Peter Corlett via cctalk
 wrote:
>
> On Mon, Oct 25, 2021 at 10:18:51AM +0200, Sijmen J. Mulder via cctalk wrote:
> [...]
> > It's especially frustrating when, after having put in the work, projects
> > refuse even trivial patches for Solaris and derrivatives or sometimes even
> > BSDs because 'who uses that anyway'. (I include the patches in pkgsrc
> > instead.)
>
> Solaris is owned by Oracle, a bunch of litigious bastards who readily
> freeload off Linux and other Open Source projects but are rather reluctant
> to give back much beyond gateway drugs to their closed-source offerings. I
> note the existence of CDDL which appears deliberately designed to clash with
> the GPL. That sort of thing can leave a nasty taste in the mouth.
>
> The specific details differ, but this basically also applies to Microsoft
> and Windows.

I think "Solaris and derivatives" was a easier way than saying
SmartOS, Illumos and OpenIndiana as well as any poor souls running
Solaris (some of which may be running older versions on Sparc kit)

> Anyway, this hypothetical patch submitter has apparently put in minimal
> effort ("trivial patches") and now implicitly expects the project maintainer
> to integrate it immediately, and then do the thankless task of maintaining
> and testing it indefinitely on (multiple releases of) a closed-source
> platform which is actively hostile to their work. For free, presumably.

I'm... pretty sure SmartOS/Illumos are actively friendly to open
source work - last I checked Joyent provided pkgsrc config to build
around 20,000 packages and had a policy of trying to feed back changes
upstream https://pkgsrc.joyent.com/install-on-illumos/

> To a rough approximation, nobody uses Solaris. It's not a good use of any
> developer's time to support it unless they're being paid to do so.

You could easily s/Solaris/Solaris,BSD,non(x86,arm,riscv),etc/

Its obviously entirely up to the members of a project to decide on
what to spend their time, and specifically what they are interested in
supporting, though if there is an active policy to not want to support
certain platforms it would help to have a specific statement in the
README to avoid other people wasting their time and annoying project
members by sending in unwanted patches and then complaining that the
patches are being ignored.

If its a matter of the patches needing more work, then that's always a
perennial problem, for just about all platforms and projects. Maybe
submitters of patches orm some platforms need to do more work, so they
should be told that

tl;dr if there are hoops to jump through for some platform patches,
indicate the hoops. If the path is closed, make it clear up front..

David

First new vax in ...30 years? :-)

[David Brownlee via cctalk]

In case anyone was interested in an FPGA VAX implementation
http://mail-index.netbsd.org/port-vax/2021/07/03/msg003899.html

And/or thoughts on 64bit/FP & multiprocessor enhancements :-p
http://mail-index.netbsd.org/port-vax/2021/07/03/msg003903.html

David

Re: VT340 Emulation

[David Brownlee via cctalk]

On Mon, 28 Jun 2021 at 14:11, Paul Koning  wrote:
> > On Jun 28, 2021, at 4:23 AM, David Brownlee via cctalk 
> >  wrote:
> >
> > ...
> > I noticed this the other day, just in case it's of interest to anyone
> > on this thread.
> >
> > | https://www.tindie.com/products/nsayer/ftdi-be-gone/
> > | FTDI-be-gone is a USB-to-serial adapter. ... Rather than use a
> > proprietary device
> > | driver to implement the serial port in the host, it relies on CDC
> > class drivers supplied by the
> > | OS.
>
> Which OS requires special FTDI drivers?  Mac OS certainly does not.

I think he's probably referring to the hugely overinflated BIOS &
firmware updating software that most x86 hardware ships with.

I've never had the need to connect an FTDI based device to anything
other than NetBSD, but I remember reading the horror stories a while
back about FTDI Windows drivers trying to brick knock off clone
hardware.

David

Re: VT340 Emulation

[David Brownlee via cctalk]

On Sat, 26 Jun 2021 at 18:15, Paul Koning via cctalk
 wrote:
> > On Jun 26, 2021, at 11:31 AM, Tapley, Mark B. via cctalk 
> >  wrote:
> >
> > At one point FTDI had a reasonably good reputation, and I own one of those 
> > devices based on that reputation. I have used it with no obvious problems 
> > connecting a TRS Color Computer 3 to an iMac G3 for a floppy-drive emulator 
> > (DriveWire on the iMac), but I think only for that application so far.
> >
> > Are there any particular pitfalls I should watch out for with the FTDI 
> > device, when/if I can get back to working with it?
>
> I once bought a USB serial port device with a DE-9 connector on it, Belkin I 
> think.  It worked somewhat.  Might have needed its own driver, which on a Mac 
> is highly unusual.  It gave me enough trouble I set it aside.
>
> Since then I've bought several different flavors of the FTDI USB serial 
> device, one RS-232, one 5 volt logic, one 3.3 volt logic (the latter two with 
> 6-pin connectors to fit onto pin headers such as are found on the BeagleBone 
> Black).  They have always worked flawlessly (on my Mac), at a number of data 
> rates: 4800, 9600, 19.2k, 115k.  I'll admit I haven't needed stranger cases 
> like 5 or 6 bit data, or exotic slow speeds.  As I mentioned, if that need 
> arises and FTDI isn't good enough I'll have the RPico to do the job.

I noticed this the other day, just in case it's of interest to anyone
on this thread.

| https://www.tindie.com/products/nsayer/ftdi-be-gone/
| FTDI-be-gone is a USB-to-serial adapter. The RS-232 variant has a
DB9M connector on one
| end and a micro-B USB connector on the other. The TTL variant has a
6 pin SIP header on the
| end opposite the USB connector. Both have two LEDs - a red one to
indicate transmitted data
| and a green one to indicate received data.
| The USB-UART chip is a Cypress Semi CY7C65213. Rather than use a
proprietary device
| driver to implement the serial port in the host, it relies on CDC
class drivers supplied by the
| OS.

Unrelated - if you know someone who works with clocks, or in other
ways has a natural affinity to even per second ticks,
https://www.tindie.com/products/nsayer/crazy-clock/ could be quite a
horrible/good present to get them depending on their sense of humour
(just bought one for a clock repairing geek friend :-p)

David

VAX rom patches - VAXstation 2000 SCSI boot, KA420 > 1GB boot

[David Brownlee via cctalk]

I had some extra A4 pages with a VAXstation 2000 manual which covered
a preview PK2K kit for VMS, bootloader and ROM to allow use of the
VAXstation 2000 SCSI controller for more than just tapes.

Rough scan at http://sync.absd.org/vax/VAX-PK2K-preview-kit.pdf (the
originals will be sent to someone who can do a better job)

The pages led me to http://ftp.gwdg.de/pub/vms/ which includes some goodies:
- http://ftp.gwdg.de/pub/vms/pk2k - uVAX-2k SCSI patches with source
for boot roms, VMB & VMS
- http://ftp.gwdg.de/pub/vms/ka420 - ROM patches for KA420/KA430 boot
from >1GB disks
- http://ftp.gwdg.de/pub/vms/dk-552/ - VMS 5.2 patch to allow to
accept more SCSI disk devices

(Starting a new thread in case there is (slightly) more general
interest for anyone interested in using the onboard uVAX-2K SCSI
controller more more than tapes (OK, OK, for anyone not running NetBSD
on their uVAX-2K interested in etc etc) - have cross posted to cctalk
& port-vax - hopefully not violating any conventions there)

David

Re: VAXstation 2000 network & hardware guides (English & German)

[David Brownlee via cctalk]

Hi Rob

I forgot to mention I'm in the UK :)

I had another email in from someone in Germany who has access to a book
scanner - if you're setup to scan and upload EK-NETAA-UG-001 VAXstation &
EK-VAXAB-IN-002 I'm happy to part them out to you as you emailed first -
let me know

David

On Sun, 14 Mar 2021 at 19:25, Rob Jarratt 
wrote:

> I would be interested in EK-NETAA-UG-001 VAXstation 2000, MicroVAX 2000
> and VAXmate Network Guide and the EK-VAXAB-IN-002 VAXstation 2000 Hardware
> Installation Guide would be nice if you get no takers. You don't say where
> you are located. I suspect shipping from the USA to the UK would be too
> expensive, or is this in Germany?
>
> Regards
>
> Rob
>
> > -Original Message-----
> > From: cctalk  On Behalf Of David Brownlee
> > via cctalk
> > Sent: 14 March 2021 18:08
> > To: General Discussion: On-Topic and Off-Topic Posts
> > 
> > Subject: VAXstation 2000 network & hardware guides (English & German)
> >
> > I have acquired a tiny slice of Orange Wall, and wondered if anyone
> would be
> > interested - preference for anyone who is setup to scan and upload the
> > missing bits to bitsavers or similar :)
> >
> > These seem to already be generally available online
> > EK-NETAB-UG-002 Workstations and MicroVAX 2000 Network Guide
> > EK-VAXAB-OM-002 VAXstation 2000 Owner's Manual (Covers how to replace
> > your mouse balls, and details exciting options such as LN03, LN03 PLUS,
> > LPS40, LA210, LA100, LA75, LA50. LGC01, LVP16, DF224, DF124, DF112,
> VSXXX-
> > AB :-p)
> >
> > These I cannot immediately find
> > EK-NETAA-UG-001 VAXstation 2000, MicroVAX 2000 and VAXmate Network
> > Guide
> > EK-VAXAB-IN-002 VAXstation 2000 Hardware Installation Guide
> >
> > Likewise these German versions
> > EK-NETGA-UG-001 VAXstation 2000, MicroVAX 2000 und VAXmate
> > Netzwerk-Anleitung EK-A0305-IN 001 VR160 Installations-und
> > Bedienungsanleitung
> > EK-A0355-OG-001 Grafikkoprozessor (8 Bildebenen) fur die VAXstation 2000
> > Installations- und Bedienungsanleitung
> >
> > Thanks
> >
> > David
>
>

VAXstation 2000 network & hardware guides (English & German)

[David Brownlee via cctalk]

I have acquired a tiny slice of Orange Wall, and wondered if anyone would
be interested - preference for anyone who is setup to scan and upload the
missing bits to bitsavers or similar :)

These seem to already be generally available online
EK-NETAB-UG-002 Workstations and MicroVAX 2000 Network Guide
EK-VAXAB-OM-002 VAXstation 2000 Owner's Manual (Covers how to replace your
mouse balls, and details exciting options such as LN03, LN03 PLUS, LPS40,
LA210, LA100, LA75, LA50. LGC01, LVP16, DF224, DF124, DF112, VSXXX-AB :-p)

These I cannot immediately find
EK-NETAA-UG-001 VAXstation 2000, MicroVAX 2000 and VAXmate Network Guide
EK-VAXAB-IN-002 VAXstation 2000 Hardware Installation Guide

Likewise these German versions
EK-NETGA-UG-001 VAXstation 2000, MicroVAX 2000 und VAXmate
Netzwerk-Anleitung
EK-A0305-IN 001 VR160 Installations-und Bedienungsanleitung
EK-A0355-OG-001 Grafikkoprozessor (8 Bildebenen) fur die VAXstation 2000
Installations- und Bedienungsanleitung

Thanks

David

MOP boot files

[David Brownlee via cctalk]

I've been helping dreamlayers with his cleanup of the NetBSD/Linux
mopd, ( https://github.com/dreamlayers/netbsd-mopd ) and we were
looking at how it handled different a.out MOP files, specifically
where the files may be little endian

For non MID zero files its easy enough, but little endian MID 0 files
are potentially more complicated.
https://github.com/abs0/netbsd-mopd/commit/6ab8555817f3dff23c506464d302d1a40bca6214#r43682334

It can netboot Ultrix and the vast panoply of NetBSD MOP boot files in
the various a.out and ELF incarnations http://mop.absd.org/netbsd/
(those that are not broken that is :/ )

I was wondering if anyone had links to hand for any other good sources
of MOP files?

Thanks

David

Re: Sun SPARCstation LX boot from CDROM?

[David Brownlee via cctalk]

On Fri, 28 Aug 2020 at 17:43, Tom Hunter via cctalk
 wrote:
>
> About 20 years ago I rescued a fully working Sun SPARCstation LX with CDROM
> and QIC-150 tape drive - all 3 in lunchbox format - plus monitor when we
> moved office and management decided they no longer wanted/needed it.
>
> Shortly after I have installed an early version of NetBSD (1.3.3) from the
> CDROM drive. I played with it for a few days and then stored the entire
> system in a museum grade glass display cabinet. This is indoors with
> minimal dust and benign temperatures between 18 degrees C to about 28
> degrees C (typical room temperatures here in Perth in Western Australia
> unless you run the air conditioner).
>
> Now retired I took the stack of "lunch-boxes" and the CRT monitor out of
> the display cabinet and powered it up. After 20 years no smoke came out but
> the system didn't boot but reported trouble with the NVRAM setting. I still
> could start NetBSD using a "boot disk" command. I googled the problem and
> bought and installed a replacement TIMEKEEPER chip (M48T08-100). After
> defaulting the settings and setting the MAC address and machine ID it was
> happy and booted from disk without intervention. In NetBSD I then set the
> date and time and all was good.
>
> Then I decided to upgrade to the latest version of the SPARC version of
> NetBSD 9.0. I downloaded and burned the ISO image to CD. Dropped it into a
> CD caddy and inserted it into the CDROM drive (SUN Model 411 - really a
> Sony CDU-8012 3.1e). I did a "probe-scsi-all" and it found both the hard
> drive and the CDROM (target 6 unit 0).

I have nothing useful to add on the CDROM, but regarding upgrading
NetBSD, one option would be to setup a netboot server and upgrade that
way. Once setup it also provides an easy way to boot any sparc box
with a working network interface (handy for when a Quantum 105 has a
sticktion day :).

David

Re: 1U VAX, was: Re: Computer stores

[David Brownlee via cctalk]

On Tue, 25 Aug 2020 at 19:46, John Klos via cctalk
 wrote:
>
> > I was going to comment that the only way I could see a 1U VAX was if
> > someone rack mounted a 4000/VLC.  Is that the stock VLC power supply?
> > My cluster doesn?t even have that much space.
> >
> > What do you use to go from SATA to SCSI (SCSI-1 even)?
>
> It's a standard 1U power supply with a custom adapter. You can see it
> better here:
>
> https://twitter.com/AnachronistJohn/status/1294725819038752768
>
> I use a SATA to IDE adapter, then an IDE to UW-SCSI adapter, then an
> UW-SCSI cable and terminator, then finally a 68 to 50 pin adapter.
>
> The previous drive was a Samsung SSD, but I think that constant, non-stop
> swap use wore it out. This was the smallest new spinning rust drive I
> could find.
>
> SCSI2SD would work for a while, but, again, swap usage would wear out an
> SD card in no time, I'm sure.

Wow, I'm surprised the VLC could generate enough traffic to wear out
an SSD - compared to a modern box running heavy compiles and suchlike.

Very cool box :)

Thinking about SCSI devices for my collection of older boxes - I
wonder if rascsi set to use the pi's RAM rather than an SD card to
provide a swap device would work out.
Actually, could be interesting to run a modern *nix box with the right
type of scsi adapter in target mode and have it "export" devices and
or ramdrives to older boxes...

David

Re: Sun Ultra 10 - openBSD 6.7+Creator3D+sunffb: Xorg and xenocara freeze the system

[David Brownlee via cctalk]

On Sun, 16 Aug 2020 at 17:50, Vasile Buruiana via cctalk
 wrote:
>
> Greetings.
>
> I would like to solve a mistery regarding graphical user interface on a Sun
> Ultra 10+ Creator3D UPA graphics card, running OpenBSD 6.7/sparc64.
> Everything works fine with Solaris 10. Did anybody manage to get X running
> on openBSD?  Sparc64 support is somehow bogus so I feel that if I talk to
> them, there will be no answer.

sparc framebuffer support in NetBSD is pretty good - possibly someone
could port some of the changes across? (I'm assuming your setup should
Just Work - may be worth test booting a NetBSD image to make sure)

David

Re: Amiga Vendors?

[David Brownlee via cctalk]

On Thu, 11 Jun 2020 at 11:58, Liam Proven via cctalk
 wrote:
> There was also a 3rd party multiprocessor board, the Hydra from
> Simtech, but the appearance of the DEC-designed StrongARM killed that
> off -- one 200MHz StrongARM was performance competitive with half a
> dozen ~25MHz ARM710 processors.
>
> http://chrisacorns.computinghistory.org.uk/32bit_UpgradesH2Z/Simtec_Hydra.html

The big issue with the Hydra was its lack of cache coherency between
processors, which made conventional SMP somewhat... challenging. You
could do very cool multiprocessor stuff with it, just not in a
conventional SMP capable OS (I remember talking to someone trying to
use it under NetBSD at the time :)

David

Re: Restarting Old Amiga's

[David Brownlee via cctalk]

On Tue, 9 Jun 2020 at 19:23, Zane Healy  wrote:
>
> My main A3000 has a Picasso IV+, and a 10Mbit 10Base-2 card, this would be a 
> seriously tempting update.  I never got around to adding USB, and would like 
> a better Network card.
>
> Do you have one of these?  I’m afraid I haven’t been on the Amiga email 
> lists, or boards for a *VERY* long time.

I'm on the other side of the fence with a TT030, but I understand the
experience with them has been mixed from "everything that is supposed
to work does", to "some bits work but others don't, but the dev
releases updates which make more bits work".

I do like that they open source the FPGA logic
https://github.com/mntmn/zz9000-fw and that it just works in a
standard Zorro slot...

David

Re: Restarting Old Amiga's

[David Brownlee via cctalk]

On Mon, 8 Jun 2020 at 21:24, Ethan O'Toole via cctalk
 wrote:
>
> There are some killer upgrades for the A500 that give it ~40mhz, 8MB of
> RAM and hard drive via SD or CF cards. These upgrades might run $150-$200,
> not bad compared to the flash cards that cost $120 for many systems or
> say, the CF disk only for the Apple II @ $120ish.

Maybe worth mentioning one of the more extreme non CPU Amiga upgrades
- the zz9000, which is expensive at €349.00, but has quite an
impressive set of features. List from
https://shop.mntmn.com/products/zz9000-for-amiga-preorder for those
who just prefer to read the damn text rather than bother with links :)

* RTG: Up to 1920x1080 FHD screen resolution at 8bit 256-colors
"Chunky", 16bit or 32bit color depths. (1920x1080 at 16 bit, all other
resolutions up to 32 bit).
* Enhanced VA2000CX Amiga native video passthrough functionality with
AGA support (scandoubler with interlace flicker-fixer)
* Dual 666MHz ARM Cortex A9 coprocessors to offload computing tasks
like JPEG, MP3 decoding and graphics acceleration
* 1GB DDR3 RAM
* Ethernet interface: Get your Amiga online
* USB port supports USB mass storage devices. The driver allows you to
access USB sticks from workbench.
* SD Card interface (for firmware updates, not currently usable from AmigaOS)
* For Amiga 500, 2000, 3000 and 4000 (Zorro 2 and 3 compatible)
* Drivers, firmware and schematics are open sourced:
https://source.mntmn.com/MNT
* Includes ZZ9000CX video slot capture card with cable
* Includes metal slot bracket
* Includes a minimal SDK with C examples for running ARM code from AmigaOS
* Important: To use ZZ9000 with Amiga 500, you need a Zorro II adapter
like Rob Cranley's Z-500 or the Checkmate 1500 Zorro adapter.

(Also has support for other operating systems for those that swing that way :)

David

Updating the VAX GCC backend from cc0 to MODE_CC

[David Brownlee via cctalk]

The gcc VAX backend is in danger of being dropped if it doesn't get
converted from the older cc0 to the newer MODE_CC implementation.

John Paul Adrian Glaubitz  has started a
bountysource entry
https://www.bountysource.com/issues/91495157-vax-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
and asked for people to post it anywhere it might be found
interesting, in case anyone would like to add to the bounty, or
collect it :)

(I find it quite amusing to it mixed in between entries like "Optimize
NumPy SIMD algorithms for Power VSX")

You could easily argue that modern gcc is too big to be practical to
run on a VAX anyway, but making practical a requirement for
classiccmp.org would rule out _so_ much fun stuff :)

Thanks

David

HP 41-CX

[David Brownlee via cctalk]

I've come into possession of an HP 41-CX calculator - unfortunately it
appears to have had batteries left in it which have left corrosion on
the internal contacts.

(some pics: https://photos.app.goo.gl/48bE7WJZP8R4PF9a9 )

My classic hardware tendencies tend to run more towards the "can run
*nix" end, and while I could just clean it up and throw it on eBay I
wondered if anyone here has a 41C shaped soft spot and would be
interested? (happy to trade/part trade for something they already have
for which they are less fond if that works :)

David

Re: Anyone interested in ARCNET, Token Ring, FDDI, HIPPI, Strip network code?

[David Brownlee via cctalk]

On Tue, 14 Jan 2020 at 19:34, Al Kossow via cctalk
 wrote:
>
> On 1/14/20 9:47 AM, David Brownlee via cctalk wrote:
>
> > The code is quite old and the drivers are not MP safe, so its being
> > proposed that the code be dropped
>
> Goose step to the monocuture
>
> netBSD, we USED to run on everything..

A monoculture in this context would be for everyone to switch to Linux :)

Older versions of NetBSD are not going away, but in the interest of
there being something other than *just* older versions, people
continue to develop. To effectively run on current hardware it needs
to be able to use multiple processors, including NUMA and big/little
topologies. So it comes down to remaining portable only for a wide set
of older hardware, including some combinations for which literally no
users exist, or balancing older hardware with new.

A good example of the latter is a current thread on how to get
jemalloc to work correctly across the various m68k platforms which
have different page sizes, without switching to a dynamic page size
and the concurrent overhead, plus recent changes to the audio mixer
subsystem to ensure it is fast enough to play on those same m68k
systems.

I like being able to run NetBSD on my work laptop, run xen (likely to
switch to nvmm soon) to virtualise a bunch of Linux test boxes for
work, and use ZFS on my home server, with syncthing for data
redundancy to multiple remote locations. Losing that ability to rely
on it day to day in order to keep support for older hardware for which
no-one has stood up and offered to write code or even test changes...
seems a bad trade.

On that final point - on the NetBSD list it appears that several
people have spoken up regarding an interest to keep using ARCNET on
NetBSD, in some cases they just have hardware and a willingness to
test, which is the difference between "we need to update the code, but
have no users", and "someone finds this useful"

NetBSD is pretty reluctant to drop actual hardware platforms - to my
recollection it has effectively dropped three
- da30, a custom wire wrap board of which possibly only one ever existed,
- pc532, a home-brew NS32532 board which was dropped when gcc dropped
processor support
- acorn26, the original 26bit address space ARM2 based machines

We live in an imperfect world, but NetBSD is pretty much the only *nix
still actively trying to keep a modern OS running on older hardware,
and they're doing it by focussing on machine independent subsystems
and drivers rather than "fork another copy and hack for each case".

Thanks

David

Anyone interested in ARCNET, Token Ring, FDDI, HIPPI, Strip network code?

[David Brownlee via cctalk]

NetBSD still has code for various interesting^W older network
protocols such as ARCNET, Token Ring, FDDI, HIPPI, and Strip.

The code is quite old and the drivers are not MP safe, so its being
proposed that the code be dropped, with the understanding that if
anyone wanted to step forward to update any of the drivers that would
also be fine.

Just in case anyone has the right kit and some itchy coding fingers :-p

https://mail-index.netbsd.org/tech-net/2020/01/date1.html

David

Anyone want an irman (Infrared to serial dongles)

[David Brownlee via cctalk]

While tidying up I've found a few Irman infrared to serial dongles

https://web.archive.org/web/20060314052558/http://www.evation.com/irman/index.html

they connect via a 9 pin serial plug and then convert any consumer
remote IR signals they receive into serial.

No additional power required, good wide angle reception, open source
driver still available

https://sourceforge.net/projects/libirman/

Could make an interesting project for anyone who wants to control
their VAX / S-100 / homebrew retro board with a serial port via a
remote :)

The company making them went away about a decade ago, so I'm counting
that as in retro territory.

I have four for the price of shipping if anyone is interested, based
in London/UK.

(Around 2000 we had an office music system based around a DNARD/Shark
running mserv & irman where everyone had a random remote at their desk
and could use it to rate/skip/queue something they liked, and the
system generally trid to pick from music which most of the people
currently connected liked... ahh, fun days :)

David

Re: RAID? Was: PATA hard disks, anyone?

[David Brownlee via cctalk]

On 28 March 2018 at 18:17, Ethan via cctalk  wrote:

> I know of no RAID setup that can save me >from stupid.
>>
>
> I use rsync. I manually rsync the working disks to the backup disks every
> week or two. Working disks have the shares to other hosts. If something
> happens to that data, deleted by accident or encrypted by malware. Meh.
>
> Hardware like netapp and maybe filesystems in open source have those
> awesome snapshot systems with there is directory tree that has past time
> version of data. A directory of 15 minutes ago, one of 6 hours ago, etc is
> what we had setup at a prior gig.
>

Possible helpful note on the off chance anyone wasn't already aware
(apologies for those who already know)

A step up from rsync can be dirvish - it uses rsync, but before each backup
it creates a hardlink tree of the previous backup, then rsyncs over it. The
net effect is you only pay the block cost of one copy of unchanged files,
plus an inode per copy. Can be very handy :)

David

Re: PATA hard disks, anyone?

[David Brownlee via cctalk]

On Wed, Mar 28, 2018, 06:04 Chuck Guzis via cctalk 
wrote:

> On 03/27/2018 08:27 PM, dwight wrote:
> > I recall at one company we used Micropolous ( SP? ) drives. We had
> > almost 100% failure in less than 6 months. It did our company a lot of
> > damage.
>
> A lot of outfits (e.g. Sun, HP) used Micropolis drives.  Generally, they
> were good, but expensive.
>
> Maybe you're thinking of Miniscribe.
>

Micropolis quality dropped way down towards the end - at Dreamworks we used
to refer to it as  "Micropolis - for all your data loss needs"

Re: X11 expertise on ancient HW sought... (4-plane visual (overlay) via X-server on MS-WIndows)

[David Brownlee via cctalk]

On 31 January 2018 at 08:21, Dimitris Theodoropoulos
 wrote:
> I believe that my case is identical to the original message of the list and
> 24-bit is required.
> The problematic visual (the one which is not provided by the external
> X-server) is the following (I cite an extract from xdpyinfo on the original
> system):
>
>   visual:
> visual id:0x36
> class:PseudoColor
> depth:4 planes
> available colormap entries:16
> red, green, blue masks:0x0, 0x0, 0x0
> significant bits in color specification:4 bits
>
> At another part of xdpyinfo, I also get the following info:
>
> screen #0:
>   dimensions:1280x1024 pixels (342x274 millimeters)
>   resolution:95x95 dots per inch
>   depths (4):8, 12, 24, 4
>
> Please forgive my technical ineptitude, in case I did not answer your
> question, but I am not experienced in this domain.

OK, so it looks like it might be looking for a PseudoColor display,
which I'm not sure is supported by current X11 (*), check if your
MacOS server is supporting PseudoColor - I think Apple dropped it
around a decade or so ago.

You *might* be able to run Xephyr to present a sub XServer which can
run 8 bit PseudoColor (its freely available under (*nix), not sure
about Windows.

(*) Current X11 on x86 looks to have dropped PseudoColor, though there
may be some odd VESA or other target drivers. Current X11 on non x86
hardware still supports 8bit, 4bit and other crazy historical
bitdepths, which is awesome in its own right, but probably not
directly useful in this context.

So if it is PseudoColor and your target display is Windows, some
increasingly crazy options:

Native Windows X servers
- Look for a Windows Xephyr port and run under MobaXterm or similar
- Find a really ancient (read, probably crashes a lot and may not work
on recent Windows) Windows X server which support PseudoColor
- Fire up a Linux VM and run Xephyr in there with the display set to MobaXterm

Run your actual other OS image on a really fast PC in an emulator
which simulates the actual display hardware it needs

Using some other OS in a VM full screen as an X server
- Check to see if there is some way to get the Linux VM to use a VESA
or some other driver which comes in 8 bit
- Fire up an ancient Linux (or similar) with X11 PseudoColor support in a VM
- Fire up a modern (or even older) *nix for hardware which is native 8
or 4 bpp in qemu (I said increasingly crazy)

Re: X11 expertise on ancient HW sought... (4-plane visual (overlay) via X-server on MS-WIndows)

[David Brownlee via cctalk]

On 29 January 2018 at 14:22, Dimitris Theodoropoulos via cctalk
 wrote:
> Sorry for undiggind this subject so many years later, but have you found a
> solution to your problem? I am facing exactly the same issue, and i have
> tried all possible windows X server options without success. The only
> possibility I am working with is with a Mac OS X server, which reports a
> 5-bit visual.

What bit-depth do you require on the X-server?

David

Re: SCSI Controller Hanging...

[David Brownlee via cctalk]

On 24 January 2018 at 16:33, Jack Harper via cctalk
 wrote:
>
> Hello Plamen -
>
> I use the SCSI controller that is built into the MVME177 transition module.
>
> No, when I RESET the system, I just press the RESET button on the processor
> board - usually when it is hung with my software.  On this system, I only
> code in 68K assembly and so I do see the "occasional" hang :)
>
> Is the "SCSI reset option" part of the 68K/BUG RESET command?
>
> In my documentation - and I easily may not have the latest documentation - I
> only see RESET options to force a COLD or WARM start on hardware RESET.
>
> The documentation that I have also cautions: "...may cause the disk
> controller to be out of phase with respect to the disk configuration tables
> in memory", which certainly makes sense.
>
> However, I do not modify any of those tables from system default.
>
> I appreciate your input.
>

Do you have any other software you can use to test the hardware - if
it experiences the same issues then you know its hardware related.

I think NetBSD supports the MVME177 board (
http://www.netbsd.org/ports/mvme68k/boards.html#MVME177%20family ) I'm
sure there are others.

You also mention you have multiple VME boards in the cage and multiple
SCSI drives. Does the issue occur when you strip everything down to a
single board set and drive?

(*) Theoretically other CPU boards may not be able to affect the SCSI,
but a near first rule of hardware strangeness is to pull everything
thats not needed so you can be sure :)

David

Re: Vaxstation 4000 m60 and NetBSD

[David Brownlee via cctalk]

On 2 January 2018 at 21:02, Maciej W. Rozycki via cctalk <
cctalk@classiccmp.org> wrote:

> On Tue, 19 Dec 2017, Charles Dickman via cctalk wrote:
>
> > > Hardware support say no support for LCG Graphics :-(
> >
> > There are a few people willing to work on graphics for old
> > vaxstations, but there is no documentation.
> >
> > If anyone has documentation, the netbsd vax port mailing list would be
> > very interested.
>
>  The RAMDAC is standard, so as long as frame buffer memory is mapped into
> the CDAL address space writing a dumb device driver should be pretty
> straightforward with little reverse engineering effort.  And CDAL address
> decoding is I believe documented in the KA46 board specification.
>
>  And all else failing you can always resort to TURBOchannel graphics wired
> via a TURBOchannel adapter.  While not supported by the console monitor,
> it can be handled by the OS just fine, and several TURBOchannel graphics
> drivers are already available for other ports, so it's just a matter of a
> suitable kernel configuration (with minor patching possibly, depending on
> how cleanly written the respective drivers are).
>
>  I was able to get OS console output using at least the HX and one of the
> HX+ options with my m90 and the (still very crippled and long neglected)
> VAX/Linux port several years ago.  The MX, CX and TX options should be
> easily supportable too.  Only accelerators (PixelStamp and PixelVision
> architecture implementations) might cause trouble for one reason or
> another (such as using DMA or requiring a TURBOchannel extender, which are
> scarcer than hen's teeth).
>

I've been chatting to the NetBSD dev who wrote support for most of the
sparc framebuffers (up to and including accelerated antialiased font
console support where relevant), and if anyone has a spare VAXstation with
a framebuffer they would be willing to part with (*) he would be very
interested in writing driver support.

(*) I'm happy to pay a reasonable amount to help find a beloved charge a
caring new home involving active exercise with exciting new code :-p

David

Re: db9 requirements

[David Brownlee via cctalk]

On 6 July 2017 at 23:39, Henry Bond  wrote:



> [image of back of sparc]
> I believe I have a graphics output device, preliminary ebay searches find
> the sun video to vga-dsub hard to come by, at least for the UK. Maybe an
> original monitor? Happy to take suggestions :)
>

Ahh yes. I'm going to guess cg3 (basic 8 bit framebuffer) from that angle :)

Looks like Sun 13W3 to VGA adaptors are around £20 inc shipping from the
states, though obviously suns are very nice on serial console if you don't
have the space for random monitors.


> Also hard drives appear to be a rare commedity that have the appropriate
> connections and are internal and in a functional state.
>

Wow, they really have gone up (just looked at eBay). Other options include
a 50pin to modern SCSI adaptor or even something like
http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD

Of course Sun's work really well netbooted if you have some other random
box to provide rarp, dhcp & nfs (add in bootparams for older OSs). A very
long time ago I was running a public access cluster and happened to be on a
different continent for a couple of years. Some of the suns had rather
dodgy disks which would crap out and need a reformat to get back. It was
quite nice to be able to netboot, then run a script to reformat, install
and reboot back into service from nine timezones away :)

David

Re: db9 requirements

[David Brownlee via cctalk]

On 6 July 2017 at 01:19, Henry Bond via cctalk  wrote:
> Good Evening all, hope your week is going well.
>
> I received a sparcstation 10 today and wondered if anyone knew which db25
> cable to get to connect to my DEC vt, null modem, cross over, etc, etc.
>
> Also if anyone has experience with this machine I would be happy to take OS
> recommendations.~

Nice sun4m box :) Do you have a framebuffer with it? NetBSD has pretty
good support for most sbus framebuffers (including antialiased fonts
on the console IIRC - if you're going to be blitting character bitmaps
around they may as well be pleasing :)

David