Friends,
tu58fs 1.1 now supports oversized TU58 tape images, with capacity up to
32MB instead of 256KB.
This was easy to made for XXDP. Under RT-11 the DD.SYS driver must be
patched and reinstalled, tu58fs now handles this
automatically.
The GITHUB release at https://github.com/j-hoppe/tu58fs/releases
contains 2 new demos:
"demo_xxdp_oversize" packs the whole XXDP25 RL02 disk content onto an
emulated tu58
"demo_rt11_oversize" boots a full RT-11 installation from TU58, and
mounts a 2nd tape full of games.
Docs at http://retrocmp.com/tools/tu58fs were updated.
And I feel pretty empty now ... hope you love it!
Joerg
I know it's a "newer" PC compatible machine, but I was wondering if
anyone had a 20MB PC110 Palmtop and could tell me (or send me pics) of
the 16MB RAM upgrade. I have a non working unit here I can liberate the
4MB module from, and I believe I can replace the RAM ICs with larger ones.
The DRAMs on the board are HM51W16160ATT7, which are 70nS FP DRAM
1Mbx16 I assume there are similar 4Mbx16 DRAMs I could solder in
(A0-A11 Row/Col)
Jim
--
Jim Brain
brain at jbrain.comwww.jbrain.com
Hi,
I recently acquired an old Sun3 with a Fujitsu Eagle disk. This disk has
SunOS 3.5 on it. Parts of the installation were missing, though. I wanted
to build a new kernel with SCSI support and extracted the sys stuff
>from a 3.5EXPORT release tape. My machine however runs plain 3.5.
I can build a new kernel, but some things won?t worked like allowing
logins when a password is set.
Is there anyone out there who could provide me with a tar of /usr/sys
>from a complete working SunOS 3.5 running on sun3?
As a second question: The SunOS boot disk is a Fujitsu Eagle that
often reports errors. I have a second Eagle that I might use as a backup,
but I would have to reformat the second disks. How can I do that with
SunOS 3.5? There is no ?format? command apparently.
thanks,
Dennis
--
Don't suffer from insanity...
Enjoy every minute of it.
> From: Paul Koning
>> When did V7 come out, BTW?
> The files on the SYSGEN tape have a timestamp of 26-Sep-79, so "Fall
> 1979" sounds right.
Ow. I was looking for something a lot earlier than that. I used RSTS-11 in
the '72-'74 timeframe, so it's a version from that era I'd like to have. Any
idea what version that would be - and if it's still extant?
> I've used the V4A kit (DECtapes) to build that ... (There's a V4A
> sysgen manual on Bitsavers too ...)
When was that one?
>> It would be really nice to have sources - are they gone forever?
> Some still exist. I know someone who has a RSTS source kit, not sure
> which version. I have pieces of source.
OK, better than nothing.
> A complication with all of this is the question of licensing. There's a
> hobbyist license for RSTS to build and run it, but whether that carries
> over to making sources available is an interesting question. I'm not
> sure who to ask these days, either.
Hmm. I guess technically HP owns it now?
Noel
> > > Apple is slightly different -- the licence for Mac OS X stipulates
> > > that you're only allowed to run it on Apple-branded hardware. This is
> > > somewhere between rare and unique, though, and it has recently been
> > > relaxed slightly to permit use of hypervisors.
> >
> > EULAs have the same value as toilet paper and should be used for the same
> > purpose.
> >
> > Legally, they can and have been enforced. So their value is not nil
> > when it comes to screwing up someone.
I was always under the impression that EULAs existed, at this point, solely to scare corporate/commercial users into license compliance in order to avoid lengthy and draining court expenses, since they've been shown to be entirely unenforceable on individuals since the 90s. That's why Adobe stopped trying to prevent piracy of Photoshop on a single-user basis long ago, as an example. License compliance is irrelevant for individual users and particularly so for long obsolete software, i.e. anything that might reasonably be emulated. Even emulating a more recent video game system such as the Wii would be impossible to prevent given that the courts have decided that it is acceptable to create backups of software that you own and the original creator cannot prevent you from using that backup on a different platform than originally intended (recent example being ripping a CD you own and listening to it on an mp3 player, or more distant example, creating mixtapes for your personal use).
Not that it would prevent you from having to deal with a court case, but in virtually every case I'm aware of over the last decade or so it's usually just been a cease and desist letter to show the company still intends to maintain copyright, but actually taking someone to court for emulation would be catastrophic for any corporation's public image and virtually guaranteed to be thrown out.
> From: Paul Koning
> I wrote a simple program to strip off those two bytes everywhere, and
> the result was a set of V7 kit tapes that work nicely.
Any chance you could provide those 'ready to run' tape images back to
BitSavers, so other people don't have to replicate what you did?
> Trying to remember how to do a V7 installation with no docs was
> interesting...
Any chance you could write up some notes covering what your rememaber/did, for
anyone else who'd like to try running RSTS-11?
(I'd upload them to the Computer History wiki, if you like - I've, alas, not
had any luck getting in touch with the Webmaster there about getting other
people accounts...)
When did V7 come out, BTW?
And in looking around BitSavers a couple of days ago for RSTS-11 stuff, I
didn't think I found much in the way of sources, just the binaries. Did
I miss any?
It would be really nice to have sources - are they gone forever?
Noel
Gents,
I'm looking at a set of RSTS V7 magtape images (a release kit) which have an odd format that gives SIMH fits.
In the container formats I'm used to, each tape block image is preceded and followed by the data length as a 4-byte value. In SIMH that's rounded up to even, in E11 format it's not, but apart from that this is how things work.
The V7 tape images don't match that format. It looks like each block contains not just the data but also 2 more bytes, and the data length value represents that extra 2 bytes. So the tape label is 16 bytes, not 14, and the data blocks are 514 bytes, not 512.
Does this ring any bells? Where do those extra bytes come from? Can SIMH be told to deal with this or does it require a repair program to fix the format?
paul
(n.b.: Sorry for the "wanted" spam from me. I think this is the last
one for a while!)
I have access to a friend's AT&T 3B2 Model 400 for exploratory and
reverse-engineering work, but I would really like to get a system
of my own.
To that end, if you have an AT&T 3B2 you'd like to part with, please
drop me a line. Happy to pay fair market prices, or consider some
trades if you prefer that (I have a lot of DEC Qbus stuff)
I'm also still looking for more documentation. I especially wish I had
schematics, and any docs related to writing drivers. Anything that
would be useful in documenting the 3B2 internals would be lovely.
Thanks!
-Seth