weirdr.net is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
boosted📢 NetBSD 11.0 release is imminent!
Release is getting a massive upgrade. Community need your help to ensure it runs smoothly on everything from modern servers to vintage workstations.
✨ What to test:
• Improved RISC-V Support
• ZFS & Kernel stability
• Your favorite pkgsrc tools
🔥 The Challenge: #RunOnAnything. Install the Beta on your most interesting hardware and show us the results!
⬇️ Grab the latest NetBSD 11 binaries here:
https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-11/latest
#NetBSD #BSD #OpenSource #Unix #BetaTesting #RetroComputing #RunBSD
Like old Zip disks. What the fuck do I do with these? Still have the old G3 tower but it doesn’t boot up. I have a vague memory of you dealing with this kinda stuff, @jessamyn ?
Today's oddware: The HP Infrared Access Point: NetBeamIR. With this monolith-looking box with a HAL 9000 aperture on the front, you can bridge IrDA devices with Ethernet! Who needs WiFi?! 😁
@lunte161 Oh good - that narrows down the problem area significantly!
There is some special casing to figure out if sector addresses are 16 or 32 bits. Compaq DOS 3.31 was the first to use 32 bits, and of course it's not the same data structure as later versions of DOS. DR DOS was supposed to do something similar but I don't have a technical reference for it.
DR DOS 6 might fix it by adopting the later convention for 32 bit sector addresses.
MS DOS 3.31 fans (specifically the Compaq OEM version) I have failed you! NetDrive should support FAT16B on that version of DOS but I had a "fixme" comment in the code to actually implement it. I have made amends ...
(Compaq MS DOS 3.31 was the first version of DOS to support FAT16B. They broke the 32MB drive letter barrier with it.)
Just another 5 or 6 lines of assembler code did the trick. I'm kicking myself for not doing it earlier.
@wrosecrans @argv_minus_one Yes, the SPUs had their own compiler and instruction set. And a silly number of registers too ... 128 registers, all of them vector capable. (And unified too - floating point and integers in the same register set.)
You basically had eight of these co-processors, each with 256K of RAM and a single PPC core. The PPC core would direct traffic. The SPUs operated independently, but relied on the centralized coordination.
@argv_minus_one The compilers were not bad at handling the threading and some of the special features, but to take full advantage of it you had to use compiler intrinsics. High performance code was basically assembler with a C wrapper around it, with all of the levels of parallelism being exploited.
It was a pain in the rear to program for but it was also incredibly fun.
@argv_minus_one At IBM I used to write code and teach classes on programming the Cell.
There are 4 levels of parallelism to deal with:
Each SPU had 2 pipelines that were statically scheduled; instruction mix and placement mattered.
Each SPU register was a vector register.
You had 8 SPUs per PowerPC core to coordinate.
SPUs used DMA to read and write memory. You had to overlap incoming and outgoing transfers to use the full bandwidth.
It was like 4 dimensional juggling.
I remember complaints about the Cell microprocessor, most notably found in the PlayStation 3, as being very difficult to program.
I wonder why that is? The general description—a PowerPC core packaged with some stream processing units—sounds pretty similar to a modern CPU with integrated graphics.
Was the Cell unusually cumbersome for this now-typical design? Or were programmers simply unfamiliar with a then-new programming model?
ZuluSCSI and BlueSCSI users who have DOS machines - I have an updated packet driver for you! Some variants of those devices have support for the DaynaPORT SCSI Ethernet adapter, and if you have the radio module you can use it for DOS networking. This version is a major rewrite of the original from Retrotech Chris.
https://github.com/mbbrutman/daynaport-dos-packet-driver/
I still need to get my hands on a real DaynaPORT device to see how well it works with this code.
A question in a Discord drove me down the rabbit hole of MS-DOS TXT2COM and TXT2EXE utilities. 😋
Nice selection here:
http://annex.retroarchive.org/cdrom/psl-v2n10//UTILS/DOS/FILEVIEW/index.html
Thanks everybody for chipping on on the SCSI question. Here is what I've gathered or derived:
The good OSes that supported the DaynaPort Ethernet devices were probably doing a read with a long timeout; the SCSI driver can definitely notify/interrupt when that read is satisfied.
The DOS ASPI layer doesn't support setting the timeout for reads. That function was available in Windows ASPI, but not DOS.
Using these under DOS is miserable; I hate the timer interrupt. ;-0
@paulrickards I'm working with a ZuluSCSI now that has the same DaynaPort emulation. I haven't been able to find anything in the emulated code that shows it can signal for attention when a packet arrives asynchronously.
I'm not sure what that mechanism would be, given that SCSI seems to require having an active command for a device to respond. Except for possibly using UNIT ATTENTION (an error condition), I don't know how a device signals it needs attention asynchronously.
@nicolaintini While SCSI host adapters can use interrupts to signal they need attention from the OS, that AI summary doesn't answer the question.
The question is SCSI assumes that the devices are only responding to requests from the host. So if you have a packet that gets received asynchronously, there is no active read command waiting for it. In that case, how does the device get the attention of the host to ask it to do a read command?
Does anybody know how SCSI Ethernet adapters were able to signal the OS that a new packet had arrived and needed to be processed?
With storage devices and scanners the host issues a command first and the SCSI device responds. But Ethernet is different in that packets arrive asynchronously, and not in response to a host command.
Network adapters can use hardware interrupts to handle incoming packets. How did SCSI Ethernet adapters do it? Was polling the only option?
Copying 20-year-old backups onto the RiscPC via vsftpd running on Slackware AArch64 (HoneyComb LX2). Just another step toward getting the StrongARM RiscPC running Slackware again!
I definitely forgot how slow half-duplex 10Mbit Ethernet is…
~250 KB/sec feels like time travel 🐢💾
At this rate I might it might be finished for next week!
A couple of years ago, I posted a bit about "Dexter", my little project to run a Raspberry Pi 1 as a little general purpose, old-school Unix system - as even its extremely low specs were pretty high by, say, 1980s standards.
I decided to pause that until NetBSD 10 released, a thing that I expected would be a lot sooner than it actually was!
Anyway, Dexter is back in the box, and now has a real enough serial port to run with a VT220 terminal as the primary console, no more USB keyboard or HDMI cables hanging off it!
You are bored and don't know how to spend your time #RetroCoding?
Well, now you are lucky, as I'd love some contributions to my #MSDOS #RetroComputing projects!
Feel free to help me out with code, documentation or finally a "real" website for #DOjS, #DOStodon, #jSH, #DosView, #lib16 and more 😊
Because I like torturing my Pentium Pro, I'm mentioning this one here. Just in case it should be of interest to anyone. Beware of the slightly nsfw second post in the thread. It's late, my boss is visiting, I had a few beers. It seemed like a good idea at the time. ;)
News from the #Floppy #Museum!
A friend of mine, fusion[1] from #OS2Warez, has written a tiny wrapper for #BBS #door programs so I can run them without needing a full-blown BBS. Combined with rlfossil, a telnet-to-serial-port emulator for DOS (yes, really!), you can now read and write messages in my little forum!
Just telnet to floppy.museum on port 8023 - I recommend using #SyncTERM or some other client that implements the IBM 437 codepage, or 850 in a pinch. The experience should be fairly period-correct, something akin to a 1200 baud modem based on my testing.
And just a reminder: This is a 286 machine, which also runs a web server, an IRC server, an FTP server and all of the above at the same time. It's not fast, but it gets the job done.
Also: Only one node at the moment. If it's busy, try again later! Consider it an early beta, for the moment! :D
I've updated my binary package repository for PowerPC Mac OS X. New and updated packages for curl, git, python 3.10, apache, nginx, openssh, rsync, yt-dlp, vim, zsh, tmux, and many more.
Ich habe meinen 2000er "enthauptet" um Mal nach dem aktuellen Zustand zu schauen und bin begeistert.
Hier werde ich also demnächst noch etwas Geld versenken ... Die 060iger bekommt noch Mal RAM nach gesteckt.
Und dann muss ich zusehen, ob meine alten SCSI Platten noch anlaufen ...
Hach ... mein guter, alter #Amiga. 🥰
Added the one page cheat sheet by @mbbrutman to my list of #MSDOS #RetroCoding resources
@dec_hl Late, but upgraded!
https://www.brutman.com/Adventures_In_Code/DOS_Programming_Tips_full_page.pdf
(Searchable PDF)
HEY #retrocomputing folks
You know that retro ISP thing me and like, 20 others have been working on for LITERALLY A YEAR?
Compu-Global-Hyper-Mega-Net (CGHMN) is now IN OPEN BETA!
Bring out your Windows, your Macs, your UNIX boxes and let's get them networked and running services and games like it's 1999 again!
Latest update to my #MSDOS #RetroCoding resource list:
Added coding videos by @root42 and @freedosproject