With great interest, I have seen that there are now scans for the Z23
(perhaps more coming soon :-) ).
But I have to admit that I am so much disappointed of the quality. I mean,
whoever scanned this all, did he have a single look at the output? I do
this, for each of the many scans, may they be only a single or many
hundred pages.
Example:
.../zuse/Z23/Zuse_Z23_Beschreibung_einschlie%c3%9flich_der_Zusazgeräte_Februar_1962.pdf
PDF pages 16/17:
this is a no-go. This must not happen in a document uploaded to bitsavers.
Pages 32-35 (and many others, too):
what the heck happened here??
And there appears to have been some "intelligent" post-processing of the
images that renders them very artificially.
Sorry for the rant, but that is not what I would accept as archiving
material. I'd offer to rescan them (guessing that the origin is from
Germany) reasonably.
Christian
All,
I'm looking for an image of the ROM or companion diskette for the Maxim MAX180 Evaluation Kit (MAX180EVKIT). I've got one that has a custom application ROM in it.
Thanks,
Jonathan
There is a printed version of this printed by Alpha Books, ISBN 1-56761-463-9. I bought it years ago (1998)
. Not sure if it’s 100% the same text, but it has a lot of nice pictures and was issued around the 25th anniversary of Apollo 11. It’s on Amazon right now for $7.12.
Rich
On 3/15/24, 8:14 PM, "Ethan Dicks via cctalk" <cctalk(a)classiccmp.org> wrote:
On Fri, Mar 15, 2024 at 6:49 PM Charles Dickman via cctalk
<cctalk(a)classiccmp.org> wrote:
> Voyager 1 is in the news recently because of communications problems and
> possible solutions. Is there an online source for documentation on the
> Voyager systems, especially the computers and navigation systems?
>
> I have enjoyed reviewing the Apollo systems documentation on the Virtual
> AGS Home Page and wondered if there were similar documents available for
> Voyager.
"NASA Contractor Report 182505 Computers in Spaceflight: The NASA Experience"
More of a top-level tour of a number of platforms, it covers, in quite
some detail, systems from Gemini to the Space Shuttle and mentions the
RCA 1802 numerous times. Samples of some NASA DSLs (HAL/S and GOAL).
Extensive citations and bibilography. Voyager and Galileo are covered
in Chapter 6.
Public domain. PDF link at: https://ntrs.nasa.gov/citations/19880069935
Excellent stuff in there.
-ethan
Voyager 1 is in the news recently because of communications problems and
possible solutions. Is there an online source for documentation on the
Voyager systems, especially the computers and navigation systems?
I have enjoyed reviewing the Apollo systems documentation on the Virtual
AGS Home Page and wondered if there were similar documents available for
Voyager.
-chuck
Hi,
I just wanted to provide a bit of a progress report on the SMD/ESDI
emulator project.
Now that I'm retired I have a bit more time to actually work on it.
Previously I was just doing a bunch of research and writing notes on the
design. I now have a solid design and I'm starting with the implementation.
I'm going to list some of the design goals and then sketch out a few of
the major issues and how they're being addressed.
Goals:
* Emulate any drive geometry
* Emulate a drive's performance characteristics
* Work across different interface types
* Fully built emulator cost below $500
Major Issues:
* SMD/ESDI have head switch times < 10 microseconds (basically the
time it takes for the read amplifiers to settle on a "real" drive).
Solving this issue drives the majority of the design
* Address marks on a "real" drive are implemented by writing a DC
signal on the track and the read circuitry detects that and
generates the address mark signal
When looking at the specifications for SMD and ESDI disks there aren't
really a lot of difference in how the drive behaves. The interfaces
differ in detail but in reality the differences are pretty minor. So
the current design should allow for 95+% code sharing between SMD and
ESDI emulators.
To solve the head switch performance, it is necessary to have an entire
cylinder in some sort of RAM. This allows for very fast head switch
times (e.g. the selected head just addresses a particular portion of the
RAM). However, this means that loading a cylinder (which in some cases
could be as much as 1MB) could take considerable time. It will take
even longer if some of the tracks in the cylinder are "dirty" due to
them having being written to prior to the seek.
Since I want the emulator to be able to faithfully emulate drives in all
respects, the limiting factor is the cylinder-to-cylinder seek time
(e.g. moving from one cylinder to another cylinder that is adjacent).
This is typically in the 4-8ms range. So doing the math, one must move
1MB in 4ms (that turns out to be ~250MB/sec of bandwidth...using 32-bit
transfers, this means over 60M transfers/sec).
The above implies that the cylinder RAM and where the storage holding
the cylinders of the image must be capable of at least 60M transfers/sec
between them. This is going to involve a complex FPGA that is able to
have large internal RAMs and a direct connection to some sort of DRAM to
hold the full image. I've chosen to use a SOM (System-On-Module)
version of the Xilinx Zynq 7020. This has dual 32-bit ARM cores (plus a
whole bunch of peripherals), 32-bit DDR3 memory interface, plus a fairly
large FPGA with enough block RAM to contain the maximum cylinder. The
calculations I've done should allow a new cylinder to be loaded from
DRAM into the cylinder RAM in 4-8ms (I think with a few tricks I can
keep it in the lower range).
I've looked a quite a few Zynq SOMs (and have acquired quite a few for
evaluation purposes). I finally found one that's ~$200 (most of the
others are in the $400-$1000+ range). This SOM brings out most of the
Zynq's I/Os (94 I/Os) in addition to having ethernet, USB, serial, SD
card, etc. as well as 1GB of 32-bit DDR3 DRAM. It also runs Linux which
means that developing the SW is fairly straight forward.
The next issue was how to emulate address marks. The emulated drive
will have a bit clock which is necessary for clocking out the data when
reading (or out when writing). The bit clock is always running (just
like a "real" drive when spinning). That will drive a counter (which
represents which bit is under the emulated "head"), that counter (along
with the head number) will be used to address the block RAM. The
counter is always running, so as to emulate the spinning disk. The
address marks are emulated by having a series of comparators (one for
each possible sector). They compare the bit counter with the value
associated with the comparator, if there's a match then that signals an
address mark. It's bit more complicated because writing address marks
(in the case of soft-sectors) has to be dealt with.
The emulator is composed of 4 major components:
1. Emulator application plus some utilities
I'm currently writing all of this code...since I'd been a SW
engineer for 50+ years, this is all "production" quality code and is
extremely well documented...still a ways to go.
2. Linux device driver which provides the interface between the
emulator application and the emulator HW
I haven't started on the driver yet but it should be fairly straight
forward as it really only provides an interface to the emulator HW
to the emulator application
3. Emulator HW RTL
I haven't started on this other than to do some basic blocks of
what's here. It mainly is the cylinder RAM, serdes (I *may* be able
to finesse this by having 32-bits on the AXI bus and 1 bit on the
interface side...a nice feature of the block RAM), address mark
logic, bit counter and some command decode/handling (it'll handle
the seek command all in the RTL...everything else will be handled by
the application.
4. Interface board
This should be a fairly simple board. It's a carrier for the SOM,
3.3v-to-5v level shifters, interface circuits for SMD or ESDI (they
use different interface ICs) and the interface to the cable.
I'm starting with SMD just to make the board layout easier (I can just
use 0.1" headers for interface cabling). I also have an SMD disk
exerciser that will make it easier to make sure it's working properly.
The idea is that once I have an SMD working reasonably well, I'll start
on ESDI.
Interacting with the emulator application can be any of the following:
* config file: indicates various emulator startup options including
which image (if any) to "mount" initially
* command line: same as the config file
* emulator utilities: these are mainly allow for changing which image
is mounted, changing write protect status, querying state of
emulator, etc. The utilities can be used locally by logging into to
Linux running on the Zynq 7020 or by using "host" versions if the
emulator is connected to a network via ethernet.
One of the key utilities is creating an "empty" (that is all tracks
contain all 0's) image. The image format has been finalized. It allows
for almost any geometry of disk (up to 32 heads and up to 65536
cylinders). The main restriction is the 1GB of DRAM on the Zynq 7020
SOM. I expect in reality that the largest drive that can be emulated
will be ~600-700MB due to DRAM.
I plan on providing some standardized "templates" (e.g. they'll describe
actual drive geometries and seek performance tables) so creating new
images won't be too onerous.
I'll be putting all of the source, RTL and board files on github under a
BSD license once I get further along.
--
TTFN - Guy
I picked up a keyboard for a Wyse terminal at a flea market the other
day. When I tried some of the keys, they couldn't be depressed.
I thought, at first, some dirt or debris had gotten stuck there, but on
closer look I saw something black below the keys that seemed to be
stuck. I pulled a key cap off and found a U shaped piece of black
plastic that was put there on purpose to prevent you from depressing the
key.
The question came to mind; "What sort of application would be so crude
that you would have to prevent the user from depressing certain keys?"
One of the keys was a Break key, which sort of made sense to me, because
it would halt a PDP-11 if that was the host machine.
This was the first time I had ever seen this kind of thing, was this
common long ago?
LINK:
https://www.kennettclassic.com/surplus-sale-starts-3-19/
If you can make it to Kennett Square, PA USA between now and April 19th
2024, stop in and browse our inventory of surplus vintage computing items.
The link above contains answers to questions. If you want to be added to
the mailing list, visit kennettclassic.com and submit a contact form.
Thanks
Bill Degnan
Hi all!
I'm working on a little side project to see why one can't put a better
CPU chip into a Sun 386i. Basically with a real 386 in the socket the
system will at least start to flash the LEDs on the back, but with a
Cyrix chip the LEDs are frozen on.
I can remove the frame buffer, memory cards, even the Timekeeper chip
and I still see this behavior. Running with no CPU or no PROM chip makes
the system flash no lights, pointing to the problem being code in the PROM.
Now, 386 CPUs don't have the CPUID register, but they do have a little
feature where upon reset EDX contains a "3" to show the CPU "type". On a
Cyrix chip it contains a "4".
My guess is the ROM code has at the beginning a check of EDX and if <>3
go to a halt. I'd like to dump the code, find that check, and either
replace the 3 with a 4, or replace the first HALT with a NOOP.
The PROM is an Intel D27010 which is an Intel 128k*8 chip. Unfortunately
I'm not finding much in terms of either datasheets or PROM programmers.
Does anyone know how to/have the tools to dump and reprogram this? I'll
bet the old archives that talk about the "Blue Lightning 386" working
for boot were due to the chip being made under license of Intel thus
being allowed to have that "3" in there.
But since I also have a TI 386/486 chip with 8k of L1 cache, a 486 core
instruction set, faster multiplier, and clock doubling by default I
think it might wind up being.... faster.
C
Does anyone have interest in vintage diskette duplication / duplication
machines? Would this make for an interesting VCF exhibit? Does/did anyone
use these commercially?
Bill
