test-drb July 2014

test-drb@ccmp.vtda.org

181 participants
190 discussions

by elson＠pico-systems.com

On Thu, Jul 24, 2014 at 10:22 PM, Eric Smith <spacewar at gmail.com> wrote: >> >... >> >The VAX-11/780 introduced the concept of patchable control store, >> >where most of the control store was PROM but there was a small amount >> >of patch RAM. Costs of high speed RAM declined quickly enough that >> >most later non-microprocessor VAXen used entirely RAM control store. >> >With the advent of VAX microprocessors, the larger die area required >> >for RAM vs ROM shifted the economics shifted back to favor ROM with a >> >small RAM patch area. >> > > The 370/145 had entirely writable control store, loaded from a floppy every time the machine was powered on. I'm pretty sure the 370/15x and 370/16x also had at least partially writable control store that could also be loaded from floppy, for diagnostic purposes, and to have firmware emulation of older machines. Some models of the 360 family had alterable control store in the form of patterned cards. The 360/30 had mylar cards that could actually be punched on a keypunch to create custom microcode. These cards had one plate of a capacitor plus the dielectric material, and by punching out the plate, you made a zero at that location. The 360/50 and 360/65 had a scheme where there was a word line board and a bit line board with traces at right angles, and a solid mylar sheet between them. The bit line board traces had wide flags on either a 1 line or a zero line, depending on what the bit at that position was to be. So, the board etch pattern was changed to alter the firmware. I think most modern, high performance CPUs do not use microcode, as the two-stage instruction execution would be slower than just doing the decode in pure logic. Also, modern CPUs are so massively pipelined, and most microcode implementations are pretty much uniprocessor-like, I don't know how you'd handle all the pipelining with microcode. They may use some microcoded functions to handle special cases, though. My main point to respond to was that alterable microcode predates the VAX 11/780 by quite a bit. I'm pretty sure Burroughs also had machines with writable control store earlier. Jon

9 years, 9 months

microcode store (was Re: Looking to get into a Mini Computer...)

by spacewar＠gmail.com

On Fri, Jul 25, 2014 at 7:38 PM, jwsmobile <jws at jwsss.com> wrote: > Also, the NSA is likely to just sign a contract with Intel to get the > patches and pay for them. I think that's unlikely. They don't want their to be a paper trail that people could find. They're more likely to steal the necessary technical information and private key. There are a lot of ways that they could do that, depending on how many Intel employees they're willing to have "in the know" about it. > I don't believe they could or would bother trying > to crack the encryption. It's 2048-bit RSA, which is probably beyond their ability to crack. They'd steal it. > The surprise is that people are shocked this is going on. Agreed!

9 years, 9 months

Malicious microcode patches (was Re: microcode store)

by spacewar＠gmail.com

On Fri, Jul 25, 2014 at 11:24 AM, Rob Doyle <radioengr at gmail.com> wrote: > It has been widely speculated (and supported by the Snowden documents) that > the NSA can defeat the Intel random number generator - and therefore any > crypto based on that RNG) with a microcode patch. Based on what's been leaked so far, the NSA seems to prefer to modify products after they leave the manufacturer's control, rather that have the manufacturer complicit, presumably in order to reduce the number of people who are aware of the alteration. It's certainly possible that the NSA installs custom microcode updates in the BIOS of machines they modify. In the case of x86 CPUs, they might have sufficient motivation to get their modifications into the standard vendor microcode update releases. I would expect that if they do that at all, they put in modifications far beyond just compromising the RNG. A huge percentage of x86 CPUs are used to run a relatively limited number of NT, MacOS, or RHEL kernels, so it seems possible that malicious microcode could recognize certain kernel addresses or instruction sequences and introduce exploitable bugs that can never be found in the kernel source code or even by disassembly of the object code. This might be a point in favor of RISC processors, which typically don't have any microcode, let alone a microcode patch area. It's not impossible that such a back door might be present in a RISC processor, but it would have to be designed in from the outset, not installed after manufacture. I'm going to go put on my tin foil hat [*] now, and watch the new Weird Al video "FOIL" again. Eric * I have it on good authority that only true tin foil is usable to block the mind control rays, and that's why you can't buy actual tin foil at the supermarket, only aluminum foil.

9 years, 9 months

microcode store (was Re: Looking to get into a Mini Computer...)

by rickb＠bensene.com

A similar ROM was used in Wang Laboratories' 700-series calculators (as well as later 500 and 600-series) as the microcode store. Also, quite a bit earlier, another electronic calculator, the Wanderer Werke Conti calculator (designed by Nixdorf) used a wire rope ROM as a microsequencer store. Rick Bensene The Old Calculator Museum http://oldcalculatormuseum.com -----Original Message----- From: Eric Smith [spacewar at gmail.com] Received: Friday, 25 Jul 2014, 10:45AM To: General Discussion: On-Topic and Off-Topic Posts [cctalk at classiccmp.org] Subject: Re: microcode store (was Re: Looking to get into a Mini Computer...) On Fri, Jul 25, 2014 at 6:04 AM, Michael Thompson <michael.99.thompson at gmail.com> wrote: > The PDP-9 uses transformers to store it's microcode. > You can change the microcode by changing the routing of the wires > through the transformers. DEC also made that available as one of the building blocks of the PDP-16 family. The technology is commonly known as "core rope memory" or "wire braid memory". It is also used for the control store of the Apollo Guidance Computer (AGC) and one level of the control store of the HP-9100 desktop programmable calculator (the other level being an inductively-coupled PC board memory). It can be viewed as a smaller-scale, simplified version of IBM Transformer Read-Only Store (TROS), as used in the System/360 Models 20 and 40 and the 2841 DASD (disk) control unit. TROS was designed for better manufacturability.

9 years, 9 months

microcode store (was Re: Looking to get into a Mini Computer...)

by seefriek＠gmail.com

> > From: Paul Birkel <pbirkel at gmail.com> > > Intel started supporting a RAM patch area, I believe, after the Pentium bug > so that they could field-update during the low-level boot process to > (quietly!) overcome any similar problem in the future. Does anyone have > more specifics on this feature, and does this capability currently exist in > any of their more modern CPU architectures? > Intel still has the microcode patch functionality in (at least) their mainline processors (Celeron, Pentium, Core, i-series and Xeon) and Atom. The process is documented in section 9.11 of the Intel 64 and IA-32 Architectures Developer's Manual, Vol. 3A. Tl;dr: The patch can be loaded at boot time by the BIOS, or later by the operating system, via writing the updates virtual address to a privileged MSR called IA32_UCODE_WRITE. BTW...as I recall (it's been a while), the big problem with the Pentium DIV bug was that the error was in the hard-wired logic and couldn't be patched by a microcode update. KJ

9 years, 9 months

microcode store (was Re: Looking to get into a Mini Computer...)

by michael.99.thompson＠gmail.com

> From: Eric Smith <spacewar at gmail.com> > Date: Thu, 24 Jul 2014 20:22:30 -0600 > Subject: microcode store (was Re: Looking to get into a Mini Computer...) > > Early on, it was very expensive to use fast RAM chips for a microcode > store, so DEC used bipolar PROMs except on relatively high-priced > machines (e.g., KL10 and KS10), and if serious bugs were found, the > microcode PROMs had to be replaced. The PDP-9 uses transformers to store it's microcode. You can change the microcode by changing the routing of the wires through the transformers. http://www.ricomputermuseum.org/Home/equipment/dec-pdp-9/pdp-9-restoration/… -- Michael Thompson

9 years, 9 months

ZoomFloppy and HPIB Interfacing

by fozztexx＠fozztexx.com

I just got one of the ZoomFloppy USB converters with the HPIB interface included. I decided to get that one because of all the open source USB to HPIB converters, it was the cheapest. However so far I can't find any information that anyone has used one to talk to anything except Commodore GPIB devices. Right now I'd like to see if it's possible to use the ZoomFloppy to read from my old HP 9133. After that it would be nice to see if I can use it to diagnose the 7958 where the fault light comes on. My ultimate goal is to be able to use the ZoomFloppy to emulate an HPIB disk drive, either with the HPDrive project or something else. I don't have the time at the moment to try to write any software and I'm hoping someone else has tried it and can give me some pointers. If there's really nothing out there I will probably try to write my own software, but I don't know how soon I can get to it.

9 years, 9 months

cctalk Digest, Vol 131, Issue 39

by jonsmg＠gmail.com

I actually have one of those Alpha Micros with the WD16. My dad bought it new to run his accounting firm off of, then retired it several years later when the hard drive died, and it turned out to be rather expensive to replace. It's stored in an attic right now, and hasn't been fired up since the 80s. Guess it's time to bring it down. Jon > Date: Thu, 24 Jul 2014 20:22:30 -0600 > From: Eric Smith <spacewar at gmail.com> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Subject: microcode store (was Re: Looking to get into a Mini > Computer...) > Message-ID: > < > CAFrGgTRxyPb6QG+c0WtQM2M5018WkOwK1Cq-0azN8Nert0J9WQ at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Jul 24, 2014 at 4:21 PM, Tony Duell <ard at p850ug1.demon.co.uk> > wrote: > > [1] The VAX11/730 also loads the CPU microcode at power-up, but from what > > I rememebr, ther eare some hardware features that optimise it for the VAX > > instruction set. While it is possible to give it a differnet instruciton > > set, I think it wopuld be a lot less efficient. > > All of the microcoded processors DEC designed, whether they had > loadable microcode or only ROM, had hardware that was substantially > oriented toward the normal DEC macroinstruction set(s), and would have > been very inefficient at implementing other instruction sets. The > VAX-11/7xx series hardware was designed for efficient execution of > both VAX and PDP-11 instruction sets, but the other machines were > designed for a single instruction set only. Even the machines that > officially supported user-written microcode (PDP-11/03, PDP-11/60, > some VAXen) were generally unsuited to implementing entirely different > instruction sets, and user-added instructions were expected to have > similar structure to standard instructions. The Western Digital chip > set used in the PDP-11/03 was used for at least two other instruction > sets, the WD16 used by Alpha Micro, which was very similar to the > PDP-11, and the Pascal Microengine, which executed UCSD p-System > p-code. The latter was not a very efficient use of the > microarchitecture, and consequently the Pascal Microengine was not > much faster than the UCSD p-System running on the fastest > general-purpose microprocessors available at its introduction. Since > general-purpose microprocessors were evolving quickly, soon it was too > slow to be taken seriously. > > Early on, it was very expensive to use fast RAM chips for a microcode > store, so DEC used bipolar PROMs except on relatively high-priced > machines (e.g., KL10 and KS10), and if serious bugs were found, the > microcode PROMs had to be replaced. > > For the KS10, it was considered that the RAM chips used in the control > store were unreliable, so they did parity checking on the control > store, and if there was an error, the CPU would halt and the console > processor would reload the control store. They patented that: > http://www.google.co.in/patents/US4231089 > > The VAX-11/780 introduced the concept of patchable control store, > where most of the control store was PROM but there was a small amount > of patch RAM. Costs of high speed RAM declined quickly enough that > most later non-microprocessor VAXen used entirely RAM control store. > With the advent of VAX microprocessors, the larger die area required > for RAM vs ROM shifted the economics shifted back to favor ROM with a > small RAM patch area. > > >

9 years, 9 months

PDP-11/34 & RL01 slide rail release

by iamvirtual＠gmail.com

Does anyone have a reference to how to release the slide rails on an RL01 drive that is in a DECSystem corporate cabinet? At the same time, I also need to remove the PDP-11/34 from the rack as well. I am trying to remove the entire drive from the rack. I can extend the drive all of the way out to the maintenance position, but I just cannot figure out what I need to do to release the slide so that I can remove the drive entirely out of the rack. I need to move the system into my basement, so I want to remove the drives to make the move manageable. Thanks! --barrym

9 years, 9 months

IBM 5170 : BIOS question

by enrico.lazzerini＠email.it

Thanks to Jim, a world was opened for me. Using the original BIOS of my IBM AT type1 motherboard that consists of 2 PROM each with 32KB I used BIOSUTIL to add the geometry of my hard disk to position 15 (the 1st free position) by recalculating the checksum with BIOSUTIL (this time understanding how it works) . The difference between the original BIOS and the BIOS modified compared with WinHex is as follows: Offsets: hexadec.    E4F1:       00        68        0368h=872cylinders  E4F2:       00        03  E4F3:       00        10        Head=16  E4F6:       00        FF  E4F7:       00        FF  E4FD:       00        68        0368h=872landing zone  E4FE:       00        03  E4FF:       00        24        36 sector/track  FFFF:       AD      A5   9 difference (s) found.   The table with the disk’s descriptions begins with disk 1 from E400 ending with the disc 47 to E6EF while from E4F1 to E4FF were inserted the values of the new Hard Disk. BIOSUTIL has taken steps to change just only the byte FFFF from AD (1010 0101) to A5 (1010 1101) so that the checksum of the file with the modified bios is identical  (?) to the contents of the original file of the PROM.     All to means: BIOSUTUL works fine with original IBM BIOS bun NOT with AMI BIOS.   The problem seems to be solved for the table discs, but as with the original BIOS to power had always the same datas: date, time, type drive A, 512KB DRAM, now all these values vary at each switch on (eg, the base memory is to 0KB instead 512KB).     How can I insert data into the BIOS for to have the correct ones stable for final configuration of the machine that I have?   Enrico -- Z-Light e Z-Pro: servizi zimbra per caselle con dominio email.it, per tutti i dettagli Clicca qui http://posta.email.it/caselle-di-posta-email-it/?utm_campaign=email_Zlight_… Sponsor: Idee regalo classiche o alternative? Trova l'offerta migliore in un click Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=13327&d=23-7

9 years, 9 months

← Newer
1
...
4
5
6
7
8
9
10
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb July 2014