did i kill my 'puter

The Atmel part number is 34C02-10.

TYPO^^

That's what I meant to type, but I see so many 24xxx series I didn't notice the error. I have a copy of that data sheet in my archives.

Does not apply to my Sun workstations. Instead, the "eeprom" command (from a booted system) or the "printenv" command (from the boot ROM) will list what I have in the equivalent:

====================================================================== # eeprom test-args: data not available. diag-passes=1 enclosure-type=540-3256-15 banner-name=Sun Blade 2000/1000 energystar-enabled?=true pcia-probe-list=4,1 pcib-probe-list=5,6,1,2,3,4 local-mac-address?=false fcode-debug?=false silent-mode?=false scsi-initiator-id=7 oem-logo: data not available. oem-logo?=false oem-banner: data not available. oem-banner?=false ansi-terminal?=true screen-#columns=80 screen-#rows=34 ttyb-rts-dtr-off=false ttyb-ignore-cd=true ttya-rts-dtr-off=false ttya-ignore-cd=true ttyb-mode=9600,8,n,1,- ttya-mode=9600,8,n,1,- output-device=screen:r1920x1080x60d input-device=keyboard load-base=16384 auto-boot?=true boot-command=boot diag-file: data not available. diag-device=disk:f boot-file: data not available. boot-device=disk use-nvramrc?=true nvramrc=devalias cdrom1 /pc1@8,700000/scsi@2,1/disk@6,0:f security-mode=none security-password: data not available. security-#badlogins=0 #power-cycles=89 diag-script=none diag-level=min diag-switch?=false error-reset-recovery=boot ======================================================================

A totally different set of options with a different CPU. I don't use much of the Intel-based machines.

Again -- something specific to the Intel based machines designed to run Windows. Not even present on the Intel-based Mac Mini, since it is not intended to run Windows as the primary OS. If I want to interrupt a boot attempt (because of a bad or missing hard disk), I hit "STOP-A" (the "STOP" key in the left hand set of function keys, and holding it down, hit 'A' as well), and that gets me into the boot ROM, where I can say something like "boot cdrom" -- or run diagnostics from the boot ROM itself. One of the settings in the example above is a "nvramrc" command which allows me to say "boot cdrom1" to boot from a second CD-ROM drive plugged into an external SCSI bus.

Enjoy, DoN.

Even the 6800 allowed limited relative jumps ("branch" they called it -- with an 8-bit signed offset, so it would allow +) The 6809 not only could branch relative to anywhere in memory (with various sized instructions, depending on the distance, including a single-byte instruction which had a three bit offset built in), but also could access data using the program counter as an index register, so it made totally position-independent programs easy to write. OS-9 took advantage of this to make a unix-like OS which did not need memory mapping hardware and swap space. A program would run where-ever there was space to put it.

And, the CoCo also had a version of OS-9 available for it. I had a CoCo and ran that for a while -- just to see how good OS-9 was on such a limited bit of hardware -- even using a bit-banger interface for the serial port -- but you could log in through that with no problems, other than it taking a bit more CPU time per byte read in or sent out. :-)

Aha! My first experience with dynamic memory was at work on the PC clones, and later at home with the CoCo. My previous machines used static memory instead, which was much simpler to design for. :-)

Oh yes -- my COSMOS CMS-16/UNX (a 68000 based machine running v7 unix did have dynamic memory -- complete with ECC built in. And one of the boards went non-compos-mentis after a while, and I finally tracked the problem down to a delay line module (in a 14-pin DIP) which had failed. It was used to generate the RAS and CAS pulses for the dynamic RAM, and was my first experience with troubleshooting it.

Nice! Any idea how long the EPROMS would hold their data with that system? I've still got some 1702s in my Altair 680b which are about 38 years old by now, and which still have their data last I checked (about a year ago, IIRC). They were programmed using the ProLog programmer. I've also got a Data-I/O programmer -- but no module capable of programming the 1702, which wsa an offensively complex one to program. I remember an article in (I think) Popular Electronics, making a programmer for the 1702 which elicited serious and loud complaints about it using EML (Electro-Magnetic-Logic -- relays) to switch the lines.

Sure. The longer you wait, the more likely you will encounter lost bits, of course. :-) There are always some bits with a faster leakage rate than the rest.

Enjoy, DoN.

Hmm ... what about a Pink Perl for the task? probably less likely to generate static zaps.

Enjoy, DoN.

Still banned on the production floor.

Thanks for the heads up!

Gunner

The methodology of the left has always been:

1. Lie
2. Repeat the lie as many times as possible
3. Have as many people repeat the lie as often as possible
4. Eventually, the uninformed believe the lie
5. The lie will then be made into some form oflaw
6. Then everyone must conform to the lie

You're welcome, as always. There are a lot of non-obvious things in electronics manufacturing & repair.

I don't see /dev/hda0 or /sda0 enumerated on that list. jsw

By the time the 6809 came out I had written an editor and assembler for my 8080 machine and definitely appreciated the 6809's advantages, like getting a DRO after years of counting dial turns (which I still do at home). The closest I came to using it was writing an A/D converter device driver for the 68000 Macintosh, in LabVIEW-generated machine language of all things! jsw

No. you wouldn't. The first looks like a linux device name, and the second is sort of close to the name for the old BSD based Suns. /dev/sd0a would be it there.

The names under solaris are like this:

/dev/dsk/c1t0d0s1, which expand to something similar to the cdrom1 one inside the OS. The format of that is as follows:

c1 Controller -- this system (a Sun Blade 2000) has built-in SCSI for the CDROM and an optional tape drive and an external SCSI. The controller names are allocated in order in which they are first used, and since you normally boot from the cdrom, its SCSI controller becomes c0, and c1 is the Fibre Channel which handles the internal two disks and up to about 252 external ones on a loop.

t1 -- The SCSI ID on the bus of the device, ranges from 0 to 7 on old narrow SCSI, and 0-15 on the wide SCSI used these days (and up to 254 for the Fibre Channel drives, with t1 and t2 being the internal ones in a Sun Blade 2000, and t0 and t1 being the internal ones in a Sun Fire 280r, which uses the same system board (motherboard in PC terms).

d0 -- Device number -- old SCSI systems used MFM or esdi disks on an adaptor which made them look like SCSI, and you could have up to eight disks on a single SCSI ID, depending on the adaptor. Pretty much always d0 these days.

s1 -- "slice" (partition), what would be the 'a' through 'h' on old systems like SunOs 4.1.4, and through 'o' on OpenBSD, and likely NetBSD as well, though I don't have experience with that.

But the boot devices are listed in the devalias, which is only accessible from the boot ROM. The second remaining quoted entry is what allocates a second CD-ROM to the list, so you can type "boot cdrom1" to boot from it.

The "boot-device" entry from the eeprom listing (first quoted entry) is the default device -- which can be a list of drives, and actually on this system, there is a mirrored pair of disks using zfs so it can boot from either -- even if the other is dead. Instead of using the "disk" alias you can type in a long string to force a disk of your own choice -- whether it is in the system box or external on SCSI, FC, or USB.

If you don't have a devalias, you can type that long complicated string:

boot /pc1@8,700000/scsi@2,1/disk@6,0:f

but the chances of an error are high, so it is better to use a devalias, and to have the eeprom install it on power-up.

Enjoy, DoN.

Well ... that would be faster than any compiler output of that period. And the 68000 had an amazing set of instructions, boosted with the later ones in the family. By the time of the 68020 or 68030, there was a single instruction which would look up an entry in a two-dimensional array of a fixed size -- all specified in registers. When compared to the code generated by the c compiler in the COSMOS CMS-16/UNX (plain 68000), which treated the 68000 as a PDP-11/LSI-11, ignoring any instructions other than the LNK and ULINK (create and destroy stack frames on entry to and exit from subroutines in c), the savings is amazing. (I wound up wondering why an 8 MHz 68000 was so much slower than a 10 MHz 68010 (AT&T Unix-PC), so I investigated the assembly language intermediate code from the compilers -- the AT&T one was much more efficient. (The 68000 one was a port of v7 unix by Unisoft, IIRC. :-) Hmm ... the company name is still around, but in Oz these days, and not making OS ports. :-)

Enjoy, DoN.