[cctalk] Fwd: CG14 and 16bit colour
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.
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 ..]
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
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
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
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
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
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
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
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
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? :-)
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
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
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
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)
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)
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
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?
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
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
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?
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
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
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
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
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?
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?
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)
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?
On 28 March 2018 at 18:17, Ethan via cctalkwrote: > 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?
On Wed, Mar 28, 2018, 06:04 Chuck Guzis via cctalkwrote: > 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)
On 31 January 2018 at 08:21, Dimitris Theodoropouloswrote: > 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)
On 29 January 2018 at 14:22, Dimitris Theodoropoulos via cctalkwrote: > 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...
On 24 January 2018 at 16:33, Jack Harper via cctalkwrote: > > 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
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
On 6 July 2017 at 23:39, Henry Bondwrote: > [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
On 6 July 2017 at 01:19, Henry Bond via cctalkwrote: > 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