>Today I was looking for something (A Cipher 525 tape drive) that I bought
>NOS years ago and left in its original box. I thought I'd found it, opened
>the box and discovered a Sinclair ZX80 with the "A Course in BASIC
>Programming" book. The problem is that I don't remember getting this
>thing--I'm sure I didn't buy it. Maybe Dave McGlone tossed it in when we
>were swapping junk years ago. (P.S. I did find the Cipher and discovered
>that I bought two of them).
>
>I don't know if it works, since I don't know the polarity of the 9vdc
>adapter. Either way, is this just common trash or is this actually worth
>something?. My wife suggested that I throw it out; she figures that if I
>didn't even know that I had it after all these years, that I certainly
>don't need it now.
The ZX80 is the immediate predecessor of the ZX81/Timex-1000, which are
VERY common. The ZX80 isn't quite so common, but I think there should
be lots around - although I've not stumbled on another one lately.
I'm pretty sure the adapter is the same as the ZX81/T1000 - and if you
take a look inside it's just a series linear regulator (7805) and it
should be pretty easy to figure out the polarity - if you want, I can
dig mine out and measure it.
Don't toss it - Mines in sad shape (previous owner drilled holes to
mount switches, broke the corner off the cabinet and lost the original
integer ROM after upgrading to the FP rom) - I've been keeping a
lookout for a better specimen, however as noted above I haven't run
across one yet. I'd be happy to give it a better home than the dustbin.
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
At work I have an SE30, LC, IIci, and a 603 variety mac just... lying around.
Are these things as common as dirt, or should I snag them?
I ask because I'm reminded of the "x86 dead zone" -- a zone where a machine
isn't old enough to be compatible with older software, but isn't new enough to
be useful (a Pentium 133 falls into this category -- can't run old stuff, can't
run new stuff, so toss it in the garbage).
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Want to help an ambitious games project? http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
I have acquired a KSR 43 and am looking for a manual. I've looked in the usual online archives (and printed-manual resellers too) Can anyone help?
Also I'm looking for a tape punch and the complete top cover assembly for an ASR 33.
thanks
Charles
Greetings folks;
So last night during the tornado watch in Iowa I was muddling about in my
basement with my wife (Seated listening to the radio) and rediscovering
the treasure trove of Good Stuff I have stored down there.
I came across a Vector Graphics machine that I've had for a few years now
and not even poked a serious look at.
This Vector Graphics machine is not an all-in-one like the ones I seem to
have found online, but in two desktop style chassis', one containing the
S100 cardcage and cards, and the other a rather large MFM hard disk.
I am totally unfamaliar with this machine, and google seems to be
providing me with few well descriptive pages on what the machine is and
about the Vector Graphics company.
What I do know: The machine is Z80 based on a "ZCB" single board computer
which sits in the S100 bus. It also has a hard disk/floppy drive
controller board, what appear to be three memory boards and three
"FlashWriter II"s which, all share one wire in common with a memory board
(A big question mark over that one).
Alas some philistine couldn't be bothered unplugging the unit from
whatever it once hooked to, and snipped both the ribbon cables to the
drive chassis as well as a ribbon cable that lead to an unknown device
(possibly a specialised graphics display).
Replacing the cabling isn't a problem, of course, but whatever the blue
ribbon cable goes to definitely did not come included.
All information greatfully received;
Pictures of the poor thing (and copious asian beetles) here:
http://www.kiwigeek.com/misc/VectorGraphics-front.jpghttp://www.kiwigeek.com/misc/VectorGraphics-hdd.jpghttp://www.kiwigeek.com/misc/VectorGraphics-top.jpg
My thanks;
JP
I just rescued a complete IBM RT PC. It includes all the documentation.
AIX 2.x software, extra keyboards, extra cards, extra HDD;s and extra
tape drives. It also has an extra ESDI hard drive labeled Reno 4.3.
Was there a port of 4.x BSD to the ROMP processor? I thought that it was
tried but not completed.
There is also a backup tape labeled AOS?
The whole system looks like its in pretty good condition. And maybe
after consuming mass quantities of turkey tomorrow, I'll see if it boots up.
Cheers
Tom
Hi All,
I am not sure if there is still sufficient interest, however, I have
encountered a rather bizarre timing situation when a specific
subroutine is executed on my PDP-11/73.
Background: I want to calculate the reciprocal (inverse) of a
number between 1 and 65535 to an accuracy of 256 bits after
the binary (or decimal) point. This result will then be used to
calculate the logarithm of that value which in turn will be used
to calculate li(x) for values of x up to 10**38. The code is in
FORTRAN 77 (could also be in FORTRAN IV) which calls
MACRO-11 code to do the really low level stuff such as
repeated addition of many words with MANY Adc instructions
following each addition (99.9% of the time the Adc instructions
are never used).
Preliminary Details: The subroutine first converts the INTEGER * 4
to a REAL * 8 to produce:
R8ARG = I2ARG
R8RCP = 1.0D0 / R8ARG
as the initial 56 bit accurate estimate.
The subroutine then continues: I must then convert R8RCP to a:
REAL * 64 = INTEGER * 32 / FRACTION * 32
which is actually quite simple since the R8RCP value already
contains the value EXP ** 2 which is the number of bits to
be shifted right after the R8RCP fraction of 56 bits is unpacked.
Next the unpacked 56 bits are moved by a whole number of
words for each multiple of 16 bits to be right shifted. Completion
is done by shifting right a group of 5 words when the last portion
of the total shift is less than 16 bits of shifting.
Unpacking uses the instructions:
Mov (R0)+,-(R1)
Word shifts use the following pair of instructions four times:
Mov (R0),-(R1)
Clr (R0)+
The final shifting (if needed) uses five instructions of:
Ror -(R0)
as many times as are required (1 to 15 times)
The problem is as follows: When the destination argument
address is in PAR0 (address is less than 17600), there is
no problem. When I use an argument address in PAR1
(address is above 21000), there is a substantial speed reduction
in the subroutine. It takes an average of 1611 microseconds
for each of the 65535 cases when the destination address is
in PAR0 (specifically 15236) while it takes an average of 6055
microseconds for each if the 65535 cases when the destination
address is in PAR1 (specifically 21000) or about 3.75 times as
long.
What is EXTREMELY interesting is that the above timing is also
repeated under E11, although everything is over TWENTY times
as fast. Under E11, it takes 65 microseconds using PAR0 and
230 microseconds using PAR1 with the same identical program.
I run using RT-11 with RT11XM for all testing, although I did
check with RT11FB under E11 with almost the same timing results.
I could also check with RT11FB on the real DEC PDP-11/73
if anyone thinks it might be worthwhile.
-----------------------------------------------------------------
HOT FROM THE COMPUTER - A BIT MORE DETAIL!
At first I was most suspicious of the Mov / Clr pairs since they
are the code that is extra. HOWEVER, if I eliminate the last loop
with the five Ror instructions, then (although the answer is incorrect -
up to 2 ** 15 too large without the final shifts) the timing is the same
for both PAR0 and PAR1 arguments. But this result contradicts the
earlier version of the code which uses ONLY Ror instructions (a total
of 16 Ror instructions are needed to span the 32 bytes in question) to
accomplish all the shifting. Because the timing for the earlier version
of the code (which is still present, just not used when the branch is
taken to the "faster??" version) can now be compared by changing
the branch instruction to use the less efficient code, I am still able to
compare the timing for both versions - and the timing for the original
less efficient version (which still includes the four unpack instructions
and many more Ror instructions) is still the same as before for both
PAR0 and PAR1 destinations arguments and equal to each other.
SO I AM STUMPED!! Even when I turn the five Ror instructions
loop into five Nop instructions (as opposed to not doing the loop
even when there are more shifts needed - the code checks the remaining
shift count, so pretending the remaining shift count is always zero to
stop using the last five Ror instruction loop was easy), the timing test
with a PAR1 destination argument takes longer even though NOTHING
is being done! In fact using a PAR1 destination argument with a five Nop
instructions loop still takes more than half of the extra timing (i.e. much
more time than for the PAR0 destination argument which still uses the
five Ror instructions loop).
----------------------------------------------------------------------
HOTTER FROM THE COMPUTER - STILL MORE DETAILS!
To my surprise, there is considerable variation even when different PAR0
destination addresses are used. Since the portion of the code up to the
final right shifting within 5 words is all that can be different, I am even
more mystified. However, after running 3 different code versions at
3 different addresses (2 in PAR0 and 1 in PAR1) on both a real DEC
PDP-11/73 and under E11 on a Pentium III 750 (at over 20 times the
speed of the PDP-11/73), the results are consistent. When I gradually
increase the PAR0 destination argument address right up to the end of
PAR0, the timing gradually decreases. When the address is in PAR1
(all or none - the field is 64 bytes long, so the last example in PAR0
is 17600), the average time suddenly jumps, but only for the "more
efficient" code version.
Since the results of all calculations are correct (verified against a
version
which uses the less efficient code), I am now totally mystified. I have
never seen this occur before in all of the 45 years I have been using
computers.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
Disclaimer: all of this is based on what I heard/found out while looking at getting one
Not a bad machine, as long as you want to run OS/400 and (generally) program in RPG. IBM never released any information about programming the actual hardware, just the software middle-layer (can't remember what it's called just now). The new machines could possibly be inferred, as they use PowerPC/ RS64 chips, but that may or may not help you because the other logic is undocumented.
CISC AS/400s are an interesting architecture, no hardware memory protection, it's all taken care of in software.
BIG GOTCHA- you need to make sure your machine comes with not only the OS, but also the mashine-specific intermediate layer software. Unless you have a friend at IBM, they may be happy to give you a replacement in return for much cash, or they may do the snooty Maitre d' thing . . . and OS/400 is rumored to lock itself after a certain period of inactivity as well.
In short, it sounded to me like a 50/50 chance of having something cool or a nightmare, so I let the opporitunity slide.
I was just given an IBM AS400/9040 at the computer refurb/recycling shop I operate. Is there anything legitimate that it could be used for, or should I scrap it? I know nothing about it other than that it's big and heavy, and it seems to IPL according to the front-panel display. I'm going to try to hook a terminal to it, but I'm not sure how quite yet.
The 800k format is very proprietary, I'd be surprised if there was any way that stock IBM hardware could write it, no matter what the programming tricks were. More data was packed on the outer tracks than the inner tracks (done so that they didn't have to change the Lisa ROMs (expecting 400k single-sided) according to rumor). The 1.44s can be done on any machine that has DD or RAWRITE or anything similar, provided that it also has a 1.44 MB mechanism. All '030+ macs have SuperDrives, as do SE-FDHD, LC, and "upgraded" IIs with the IIx ROMs (fair number of upgrades were sold by Apple).
For an OS, I'd use either 6.0.8 (very fast, can turn MultiFinder off, "classic" look but won't do Virtual Memory or 32-bit addressing (max memory=8MB, everything else is ignored)) or 7.1 PRO (fastish, and you can patch in much of the stuff that's nice in 7.5/7.6). If you're running 7, be sure to get Mode32, available free+legal. ROMs from the pre-IIci era aren't fully 32-bit, so they have problems if you turn on 32-bit addressing. A/UX also runs on the SE/30, it's the only compact Mac that can run it. For these old beasts, assuming that you aren't going to be a heavy Photoshop/PageMaker user, 16-20 MB of RAM works just fine with 7.1. System 6 won't see anything over 8. Remember to get your long-blade Torx-15 and case cracker, and to unplug SCSI, power, etc. before trying to slide out the logic board.
Scott Quinn (SE(6.0.8), II (6.0.8), IIci (7.1), Quadra 950 (pegasys, A/UX 3.1), Quadra 700 (7.6)).
P.S. The LC is weird because of several things: 020 but no PMMU option, 16-bit data bus, only will run up to 10MB RAM and 1/3 ht HDD, funky nonstandard video that doesn't run on all monitors. The only excuse I can think of for Apple was that they didn't want to eclipse the II in power. The 24-bit addressing bug in ROM I can find no excuse for- the 68000 was designed with a 32-bit outside address bus successor in mind (full internal 32-bit registers)- they must have just been lazy.
