Hi,
I have an old Grundy Newbrain AD computer which doesn't work. The
machine powers up with random chars in the built in anode display, but
doesn't respond to keypresses. I used the machine some 20 years ago, and
when I put it away at that time it was ok.
I've checked the voltages at the 4116 RAM's and they are ok (+5, +12 and
-5 volts). The ripple is also within reasonable limits.
I don't have the schema for the machine so right new I'm pretty lost.
Is anyone able to help me out? If so, please answer directly at my email
address.
Regards,
Torben Ring
DENMARK
All the relevant information is below. Reply to the original sender.
Reply-to: <cacannon(a)albrightmail.alief.isd.tenet.edu>
---------- Forwarded message ----------
Date: Tue, 14 Jan 2003 09:47:24 -0600
From: "Cannon, Cynthia" <cacannon(a)albrightmail.alief.isd.tenet.edu>
To: "'bounty(a)vintagetech.com'" <bounty(a)vintagetech.com>
Subject: Apple II e
I have an Apple II e, dual disk drive, monitor, original packing boxes,
manuals, some software, etc. Many of the ancillary manuals are still sealed
in their plastic wrap. I am interested in selling them. Are you interested?
Cynthia Cannon
7203 Triola Lane
Houston, Texas 77074
713-271-4203
cyndi324(a)aol.com
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
> > > Yes. Use maketape from the 2.11BSD distribution.
> > I strongly advise against this approach.
> Well, I had to use some programm to write the tapes, dd(1),
> maketape, or somthing else.
Indeed.
There is *nothing* magical about making tapes from selected files.
What you have to keep in mind are:
- select the correct tape boot blocks
(MT, TK etc)
- grab the correct kernel and/or RAM disk image
- use the right blocksize for the above "file" (usually 512bytes)
For the remaining files on the tape, blocksizes vary between OSes,
and can be anywhere between 512 (old systems) and 10K (UNIX tar
files). The key issue is to generate a magtape file marker between
the individual files, so the tape handling software knows where a
file ends.
The block size and tape marker generation are done correctly by the
Maketape program. If you want to do it manually:
- grab the first ("bootable") file for the tape, and dd it to the
tape:
dd if=bootfile.img of=/dev/ntape bs=512
this copies "bootfile.img" to the tape, using a block size of 512
bytes, and when done, it will write a tape mark and **NOT** rewind
the tape ("ntape" - can be /dev/nrst0, /dev/nrmt0h, /dev/ntk0, etc.)
- copy the other files to the tape:
dd if=nextfile.foo of=/dev/ntape bs=10240
which copies "nextfile.foo" to the tape, using a block size of 10240
bytes (common for UNIX tar files) and when done, writes the tape mark,
and NOT rewind.
- when done, write a tape mark and rewind the tape:
mt -f /dev/ntape weof
mt -f /dev/ntape rewind
where the first command (Write EOF) is optional, as most UNIX systems
do this automatically when rewinding a tape in write mode.
This creates a magtape in the right format for booting. Tools like the
Maketape program do this as well, based on a small description file which
tells it what goes where and such.
> > dd if=stand of=/dev/nrmt0h bs=512
> I learnd that the bs= parameter of dd doesn't set the block
> size of the tape with an ioctl, it is only the buffersize
> parameter that is used in the write(2) syscall.
Correct. The 'dd' program **does not** set the physical block
size of the tape device, as it is a generic block/deblock tool,
and has no knowledge of devices whatsoever.
It sets the block buffer size(s), on which the READ(2) and WRITE(2)
system calls are based, which in turn tell the tape device driver
what the block size is to be. This only works in the "raw" mode of
tape devices, by the way- always use the 'r' device file of a tape
unit when doing the above.
Cheers,
Fred
Jochen Kunz <jkunz(a)unixag-kl.fh-kl.de> wrote:
> Yes. Use maketape from the 2.11BSD distribution.
I strongly advise against this approach. I will not provide any help or support
to any user attempting to bootstrap 4.3BSD-Quasijarus from tapes written by
this method. 4.3BSD-Quasijarus isn't 2.11BSD, and one cannot expect the tools
>from some random foreign OS to produce correct distribution tapes for 4.3BSD-
Quasijarus.
> You have to observe the
> correct block sizes, that you can't do with dd.
Yes you can. dd bs=blocksize. Here is the sequence of commands to write a
4.3BSD-Quasijarus 1600 BPI distribution:
(mount the first reel)
dd if=stand of=/dev/nrmt0h bs=512
dd if=miniroot of=/dev/nrmt0h bs=20b
dd if=rootdump of=/dev/nrmt0h bs=20b
dd if=usr.tar of=/dev/nrmt0h bs=20b
mt rew
(first reel done)
(mount the second reel)
dd if=srcsys.tar.Z of=/dev/nrmt0h bs=20b
dd if=src.tar.Z of=/dev/nrmt0h bs=20b
(second reel done)
MS
Hi all,
It seems like I am going to end up tading for cash :) This will make it
easier on everybody and it seems like nobody wants to get rid of their
interesting items.
I will be putting pictures on my serve this week end anyone interested in
welcome to ask me for the address. I will be listing the documentation that
I have and any original floppy (if any).
Interested parties should contact me before the end of the day sunday (+/- 1
earth revolution :)
Funny people with a $5 offer will be actively ignored :)
Thank you.
Francois
>If you mean me, my AXPpci33 upgrade was successful (but just in case
>I've missed something, what version did you find?) If you mean someone
>else, then I'll just go back to minding my own business.
It might have been you...
Anyway, the image I produced is bootable from the SRM console and
delivers a V4.something, if I remember correctly, which is the last
version of the console firmware for the AXPpci33... it came from a
V6 (or later) CD...
Megan
Kelly Leavitt <kelly(a)catcorner.org> wrote:
> Used sun (since
> compress essentially compiled out of the tarball). Used dd with the
> different bs settings.
>
> [...]
>
> I hope these work for John Willis, but
> I'm not making any promises either.
This should work just fine.
MS
And I'm not even using 2.11 or any type of BSD. Sun, Sco, Windows or Dos
based is all I can read and write 9 track tapes with. Used sun (since
compress essentially compiled out of the tarball). Used dd with the
different bs settings. Don't blame Michael for his stance though. There are
only so many things he can support. I hope these work for John Willis, but
I'm not making any promises either. Just trying to help out when and where I
can. I've got a 9-track drive and a bunch of tapes to recycle.
If it doesn't work, John will have to see if someone else can create the
tapes he needs. Either way, working or not, he's more than welcome to try.
Keep the tapes and pass em around until you get a working copy if what I did
doesn't work.
For what it's worth, I read and convert different _DATA_ tapes almost daily.
Labelled, unlabelled, ascii, ebcdic, variable length, fixed length, etc. I
essentially treated these as unlabled data tapes. I did read the tar files
back off onto sco and DOS and was able to "untar" them. diff showed the
write files and read files to be the same on both platforms.
Hope it all works.
-----Original Message-----
From: Fred N. van Kempen [mailto:Fred.van.Kempen@microwalt.nl]
Sent: Friday, January 24, 2003 7:13 PM
To: cctalk(a)classiccmp.org
Subject: RE: Quasijarus 4.3BSD on 1600bpi magtape
> > Yes. Use maketape from the 2.11BSD distribution.
>
> I strongly advise against this approach.
This is bullshit, Michael. "maketape" does exactly the same, namely,
creating tape files with a certain blocksize, separated by tape marks.
C'mon.
--fred
Well currently there's a nice HP 2100A system with no bids, starting at $600
I believe.. I know I'd pay that, if I could.. plus $400 for an HP 3030 tape
drive.. *drool*
Will J
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
