Hi all,
I just noticed that images of a full RX50 floppy set for Ultrix-32m 1.2 was
posted on Bitsavers (
http://bitsavers.trailing-edge.com/bits/DEC/vax/ultrix/1.2/ULTRIX-32M_V1.2_…
). I am having difficulty parsing these images into a usable raw format
for SIMH.
As a reference, TUHS has a set of 1.0 floppies (
https://www.tuhs.org/Archive/Distributions/DEC/Ultrix-32M/ ) that are
usable for installation purposes. (You can ignore the 1.2 floppies in that
archive, they aren't actually a full set). The first disk of that
installer, 32m-1.0-bin/01, has a bootloader that starts at byte zero as we
would expect. This should be approximately equivalent to disk 1 in the
Bitsavers set. Oddly though, in the "raw" dump the bootloader doesn't
start until 0x1400, and a number of the other disks I looked at appear to
have odd holes/zeroes in them. IMD format dumps of the 1.2 disks are
provided but when I converted the IMD format to a raw image I got the same
issue.
I'm almost thoroughly unfamiliar with IMD - is there some obvious
extraction/conversion option that I am missing here? Were these disks
actually imaged correctly? I would appreciate any suggestions.
-Henry
OK. I have about 500 DEC Ranibow floppy images that I've ripped over the
years.
I also have a number of .td0 images as well as other oddballs.
Other than Lotus 123 needing to have funky sectors on one of its bigger
tracks for copy protection, I think having the raw images suffice.
I have some disks that I have multiple copies of (MS-DOS, CP/M, Winchester
Utilities, DEC Rainbow diagnostics etc).I have a few copies of some
software packages. I have a few disks that are clearly personal. And some
of the variations of MS-DOS have different patches applied by various
install programs (or debug scripts published in different trade rags of the
time). And at least one has a special driver installed that overwrites the
DEC Winchester for things like Univation).
So, what I'd like to do is to is somehow organize all this. I wrote some
software to extract files from the filesystem.So I'd like to have a
separate copy of the expanded files.
Lots of moving parts for 40-year-old floppies. I'm struggling with how to
organize all this, how to keep track of this, and how to allow others to
contribute their disk images and allow things to be studied and run. I'd
like to keep the raw images (to mine them for drivers like the univation
one I discovered). I'd like to keep the busted apart files to access them
more easily, etc.
Is there some book, website, paper, etc that I can use to to help me
organize all this so I can share it with others? Is this even the right
place to ask? There's got to be several people that have solved this issue
before....
Warner
Seen on the GCC bugzilla:
"actually, there are 10 types of people: those who understand ternary, those who dont, and those who thought this was going to be a binary joke"
:-)
paul
Really long shot, and I have asked here before without much luck, but anyone
have a copy of the Compaq System Manager Facility 1.10 or 1.11 (or any
version for that matter). This would have been released in 1994/95 time
frame and is necessary for the use of the Compaq Server Manager/R EISA
board. This is a very early EISA RILO board for the System Pro and Proliant
line of servers. Please note this is not the same as the System Management
Agents nor the Insight Manager. TIA!
-Ali
Hi everyone,
I recently dug out my V880 and all seems to be working brilliantly. I've always liked these machines and it would be nice to upgrade this to the V880z spec, ie by adding the mighty
XVR-4000 graphics module.
I know the XVR-4000 is a bit of a mixed bag, but would be fun to play around with this and also who can not be impressed with the shear size of the module. Must be one of the biggest Sun graphics 'cards'?
Does anyone have one of these boards they would be willing to part with. Happy to pay a reasonable amount as I know these are not easy to find.
PM me if you have anything.
Ian.
Over the past couple of months I have been working on my FPGA
implementation of the IBM 1410 1960's era pre System/360 system again.
I am pleased to share that the CPU now passes a significant diagnostic,
CU01, which tests almost all of the instructions, and also tests I/O
with overlap and the priority feature (interrupts). Also, it runs at
generally the same speed as the original machine (comparing the IBM
estimates for 1000 passes), using the same logic as the original machine
(though no doubt optimized by the process of taking in VHDL logic
statements and turning combinatorial logic into lookup tables (LUTs),
and some additions of "D" flip flops to avoid race conditions in latches
and logic loops.)
(The speed is the same because its "oscillator" - crystal controlled in
the original - is now a clock divider/counter off of the FPGA chip clock.)
For more details, see
https://www.computercollection.net/index.php/ibm-1410-fpga-implementation/
Mostly the ALD (Automated Logic Diagram) data capture seems to have been
very accurate. I really only had to do four things this year to get it
to this point:
- Make the necessary logic gate deletions / changes for configuration
option S40/$40 - 40K of core
- Add the ability to transfer a core image from the PC support program
to the FPGA.
- Fix some issues in the Assembly Channel because while almost all of
the ALDs are for a 1410 with the Accelerator feature, several pages of
the very important Assembly channel were for the base 1410 model.
- Deal with a race condition during overlapped I/O
These are generally discussed in individual blog posts off the above link.
I really was quite happily surprised that when capturing the data on
over two hundred ALDs with over 10,000 logic gates, over 4,200
individual unique signals, more than 12,000 signal names on individual
ALDs, and more than 32,000 interconnections that there were not a lot
more problems than these. (I may run into some as yet undiscovered
errors involving the channels as I add I/O devices, though).
I suppose that there were not more problems because for most of the
individual sheets and in many cases groups of sheets I wrote VHDL test
benches using the Intermediate Logic Diagrams (ILDs) as a guide, and of
course took considerable care during the data entry process from the
ALDs, checking connection counts on each logic block, for example.
The last post ("Off to the Races") on the aforementioned web page also
discusses the next expected steps: some more work on the PC/Console
support program, more diagnostic tests, other support program
enhancements, and figuring out how to go about I/O, especially since I
don't have ALDs for the 1414 I/O Synchronizers.
But I no longer have any doubts about the viability of this process, so
long as the FPGA logic clock is somewhere around 10x the logic clock of
the simulated machine. (I expect to try and "push it" by speeding up
the 1410 logic clock to see at what ratio of the FPGA clock to the CPU
clock things break down, as well).
JRJ
I have a PDP-11/53 and have just started playing with an AAV11-C D/A
board. It is a 4 channel D/A convertor with 12 bit resolution.
Can it be used to play an audio bit stream?
Here is simple code used to see if the thing was actually working:
.title AAV11 D/A test
;
.asect
dbr0 = 170440
.=1000
start:
mov #7777,r0 4096 value to R0
mov #dbr0,r1 first D/A buffer out
loop: mov r0,(r1) transfer value in r0 to D/A out
dec r0 subtract 1 from D/A value
bne loop
br start loop back to start
I was surprised to see that it took ~34 ms to run through all the
numbers from 0-7777, that is about 34 Hz. The manual says the 'settling
time' is 6 microseconds. Is this fast enough for audio?
How would you convert a modern audio file into 12 bit integers?
Doug
A friend suggested that some in this group may have an interest in this.
ruos stands for Retro Useless Operating System
ruos is an OS for the long-obsolete PDP11/70 from Digital Equipment Corporation. ruos runs on the simh simulator for that machine. It was written completely from scratch in C and assembler. On a modern machine, the kernel and user code builds in a few seconds.
Overview:
It can run something less than 64 processes simultaneously with one user on the console and others on other serial ports. Equal priority CPU-bound tasks share the CPU.
The user program API includes a number of stdio-like C functions
ruos was built using the gcc toolchain for the PDP11 (Thanks for those toolchain bug fixes Paul Koning!)
Each user process is given exactly 64kB for code, data, heap, and stack and is (mostly) isolated from other processes
Users access the OS using a very simple unix-like shell for command execution with pipes allowed
It does not have its own file system but uses a proxy for file IO. The proxy code (Python 3) is included.
Communication between the OS and the proxy is via UDP/IPv4/Ethernet.
Familiar user binaries include: cat, ps, echo, grep. Device status is provided by ds
If a user tries to run a program that is not native to ruos, an attempt is made to run it on the proxy. Using this mechanism, users can edit files or build new programs (assuming the gcc toolchain is installed on the proxy and the proxy is on the same machine as simh).
It is accessible here:
https://ajco...@bitbucket.org/ajcorbeil/ruos.git <https://ajcorbeil@bitbucket.org/ajcorbeil/ruos.git>
Regards,
Alan Kirby
Just got the following message in the account that I use to receive
cctalk email:
----------------------------------------------------------------------
Hello cclist,
The passwогd to your mailbox (cclist(a)sydex.com) expires in 24 hrs time.
Following this prompt, your webmail will log you out and generate a new
passwогd.
Alternatively, you can retain and continue using your cuггent passwогd,
by using the user secured button below;
Keep Cuггent Passwогd (link goes to cloudflare-ipfs.com)
This email is generated by sydex.com's mail server for cclist(a)sydex.com.
------------------------------------------------------------------------
FYI
Chuck
