Re: Reproduction micros
On 20 July 2016 at 21:29, Paul Koning wrote: > I don't remember the earlier ARM designs, but it was my impression that DEC's > StrongARM was the one that made really large strides in low power (especially > power per MHz of clock speed). Interestingly enough, StrongARM was one of > the few (and the first?) independent designs; it used the ARM architecture > specification but not the actual logic design as others did. Hmm. That wasn't my impression at the time, no. The big deal with StrongARM was that it had a dramatically increased speed -- whereas Acorn ARMs ran from 8MHz in my original Archimedes A305 to 12MHz for the first SoC ones (A3010 with ARM 250) to 25MHz for the ARM3-powered A5000, Digital's first StrongARM ran at 100-200MHz. To keep the core fed with data at this ridiculous speed, it had onboard L1 instruction & data caches. http://www.zdnet.com/pictures/decs-40-years-of-innovation/10/ https://www.netogram.com/strongarmprocessor.htm Original PR: http://www.cpushack.com/CIC/embed/announce/DigitalStrongARMIntro.html Self-modifying code could write back to and thus run from the cache before it was propagated to the main RAM, which meant that some RISC OS code had to be rewritten. E.g. http://www.riscos.com/ftp_space/370/index.htm The "Kinetic" StrongARM upgrade for the RISC PC therefore had RAM on the CPU daughterboard, as the motherboard RAM was not even close to fast enough. http://www.riscos.info/index.php/Kinetic So at least in the marketing to the Acorn user community, no, power draw wasn't even mentioned. It never came up. The original ARMs were low-power, and so was StrongARM. StrongARM wasn't a big win for the Newton, inasmuch as the Original MessagePad (OMP) had an ARM610 in it. The Newton 2000 was the first model with a StrongARM but it was merely an upgraded CPU for the newer hardware. -- Liam Proven • Profile: http://lproven.livejournal.com/profile Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
RE: LASERS!
While fascinating... it's not on topic. Lets wrap up this thread :) J
Re: Reproduction micros
On 21/07/2016 13:38, Liam Proven wrote: On 20 July 2016 at 21:29, Paul Koning wrote: I don't remember the earlier ARM designs, but it was my impression that DEC's StrongARM was the one that made really large strides in low power Hmm. That wasn't my impression at the time, no. The big deal with StrongARM was that it had a dramatically increased speed -- whereas Acorn ARMs ran from 8MHz in my original Archimedes A305 to 12MHz for the first SoC ones (A3010 with ARM 250) to 25MHz for the ARM3-powered A5000, Digital's first StrongARM ran at 100-200MHz. To keep the core fed with data at this ridiculous speed, it had onboard L1 instruction & data caches. So at least in the marketing to the Acorn user community, no, power draw wasn't even mentioned. It never came up. The original ARMs were low-power, and so was StrongARM. Yes and no. StrongARM was even lower power as well as faster. If you're suggesting that that's just evolution due to things like reduced process size, I possibly agree. But a StrongARM has many times as many transistors as an ARM3 (for example) let alone an ARM2, and initially ran 3 times as fast (100MHz vs 33MHz - the earliest ARM3s were 20MHz, but production runs were 25MHz and later 33MHz, and eventually SA-110 ran to over 200MHz) yet uses less power. I don't have the data sheets for ARM6 and ARM7 so I can't compare, though. As for the marketing, I recently came across an Acorn press release announcing ARM, in which Sam Wauchope (CEO) was quoted saying it delivered 100MIPS per watt, so power was indeed a selling point. I worked for Sam at the time[1], so I remember that. OK that's for one of the Acorn ARM chips, not StrongARM, but the point is still made. Not all the marketing was directed at the Acorn community. [1] and I still have my Archimedes A310 Serial No. 002 (and the box with all the bits and pieces :-)) as well as my A410 and R260, both from the first batches. I wish I'd kept an A500, though. All I have now is the podule to connect it to a Beeb. Anybody got the machine to put it in? -- Pete Pete Turnbull
Re: Reproduction micros
On 21 July 2016 at 15:24, Pete Turnbull wrote: > > Yes and no. StrongARM was even lower power as well as faster. If you're > suggesting that that's just evolution due to things like reduced process > size, I possibly agree. But a StrongARM has many times as many transistors > as an ARM3 (for example) let alone an ARM2, and initially ran 3 times as > fast (100MHz vs 33MHz - the earliest ARM3s were 20MHz, but production runs > were 25MHz and later 33MHz, and eventually SA-110 ran to over 200MHz) yet > uses less power. I don't have the data sheets for ARM6 and ARM7 so I can't > compare, though. OK. I think the first announced StrongARM, the SA110, was announced as running at 100, 133 and 200, mind you. But the point about transistor count is well made. For the casual, it was displayed by the packaging. The SA110 came in a plastic QFP, and it came from the same company and around the same time as the Alpha, with threaded shanks on the packaging for screwing a heatsink into place. Spoke volumes. :-) > As for the marketing, I recently came across an Acorn press release > announcing ARM, in which Sam Wauchope (CEO) was quoted saying it delivered > 100MIPS per watt, so power was indeed a selling point. I worked for Sam at > the time[1], so I remember that. OK that's for one of the Acorn ARM chips, > not StrongARM, but the point is still made. Not all the marketing was > directed at the Acorn community. Fair dos! > [1] and I still have my Archimedes A310 Serial No. 002 (and the box with > all the bits and pieces :-)) as well as my A410 and R260, both from the > first batches. I wish I'd kept an A500, though. All I have now is the > podule to connect it to a Beeb. Anybody got the machine to put it in? I have an A5000, near-new in box. But it's not been removed for about 15y and I've no idea what working condition it's in. I could post it to you when I'm next in the UK -- probably early next month. If you're interested, make drop me a line off-list. It's in my storage unit in South Wimbledon, where I have no power or anything, so I can't plausibly get it out and test it. I am planning to move the rest of my stuff here to Czechia next month, mainly for cost reasons due to the falling GBP. If you wished you could come and meet me and inspect it in person? -- Liam Proven • Profile: http://lproven.livejournal.com/profile Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
Re: Reproduction micros
> On Jul 21, 2016, at 8:38 AM, Liam Proven wrote: > > On 20 July 2016 at 21:29, Paul Koning wrote: >> I don't remember the earlier ARM designs, but it was my impression that >> DEC's StrongARM was the one that made really large strides in low power >> (especially power per MHz of clock speed). Interestingly enough, StrongARM >> was one of the few (and the first?) independent designs; it used the ARM >> architecture specification but not the actual logic design as others did. > > Hmm. That wasn't my impression at the time, no. > > ... > So at least in the marketing to the Acorn user community, no, power > draw wasn't even mentioned. It never came up. The original ARMs were > low-power, and so was StrongARM. Remember that the marketing in question was DEC marketing, well known for its utter ineptitude. That had its origin in Ken Olsen's belief that marketing wasn't really needed (and, for that matter, that sales people didn't need to be paid commission). I very definitely remember discussions at the time about the unprecedented power/bandwidth value delivered by the SA110. "One mW per MIPS" is one phrase that I remember from that time. paul
Re: Reproduction micros
Peter Corlett writes: > IMO, it's the predicated instructions that is ARM's special sauce and > the real innovation that gives it a performance boost. Without those, > it'd be just a 32 bit wide 6502 knockoff. I have both the ARM and the 6502 instruction sets very fresh in my mind right now. I don't see how the ARM could be a 6502 knockoff, even without that sauce. Care to explain in more detail?
MS11-P FMPS missing page
So the online set of MS11-P Field Maintainence prints is missing page 3 of the prints (data drivers page). Does anyone have an original hard-copy, and can supply a scan of the missing page? Thanks (in advance, and hopefully :-). Noel
Re: Reproduction micros
On 21 July 2016 at 16:45, Lars Brinkhoff wrote: > I have both the ARM and the 6502 instruction sets very fresh in my mind > right now. I don't see how the ARM could be a 6502 knockoff, even > without that sauce. Care to explain in more detail? This is a matter of historical record, AIUI. http://forum.6502.org/viewtopic.php?t=1892 There's a little more here: http://www.theregister.co.uk/2012/05/03/unsung_heroes_of_tech_arm_creators_sophie_wilson_and_steve_furber/ In essence, Wilson designed it and Furber implemented it. Wilson knew 6502 inside-out and had been designing 6502 systems while still a student, before Acorn existed, so it inspired the ARM ISA, rather than ARM actually being based on it. 6502 is widely held as being, if not actually RISC, then at least RISC-like, or as Brits put it, RISCy. http://everything2.com/title/6502 https://news.ycombinator.com/item?id=11703717 -- Liam Proven • Profile: http://lproven.livejournal.com/profile Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
Re: MS11-P FMPS missing page
I should have access to an original (somewhere..) There are also some scans that have come in over the past couple of months I can check On 7/21/16 8:08 AM, Noel Chiappa wrote: > So the online set of MS11-P Field Maintainence prints is missing page 3 of the > prints (data drivers page). Does anyone have an original hard-copy, and can > supply a scan of the missing page? Thanks (in advance, and hopefully :-). >
KT-24 and/or -11/24 backplane info
So I'm trying to work out how the PDP-11/24 memory works - in particular, how the memory slots in the backplane can also support SPC devices. Chapter 5 of the -11/24 Technical Manual does not help - irritatingly! It spends a lot of time talking about the CPU's memory mapping (well documented elsewhere), and little on these blasted busses! Alas, there seems to be no KT-24 prints online (although the tech manual makes reference to various pages in it); prints of the backplane would also be really useful, but again, don't seem to be in what is online. Does anyone have either one? Failing that, I guess it will require getting ahold of a backplane, and seeing what I can find out with an ohm-meter. In general, I am not absolutely positive about how the UNIBUS and the Extended UNIBUS manage to co-exist on the backplane (although I think I have worked it out - see below). The tech manual acts as if the KT-24 acts as an intermediary between the two... which is fine, except that how are the both carried on the backplane, separately, but at the same time? When there _is_ a KT-24 (the system can work without one - more below on this), how is the EUB (which is just the UNIBUS plus a couple of extra address lines) separated from the UB? The way the UNIBUS mapping registers work, the EUB address for any given cycle can vary from the UB address by an arbitrary amount, so lower address bits can't be shared between the two busses. (Because address bit X might have to simultaneously be '0' for one bus, and '1' for the other.) I.e. the two busses can't somehow mostly share the same pins, through some kludge... It appears likely that somehow the UNIBUS is on connectors C-F (i.e. where it normally is on SPC slots), and the EUB is on the A-B connectors (as in MUD slots) - and the two are not connected together. (Note that on the 11/24 backplane, 4 slots are marked "SPC/Mem", and two "SPC/MUD", which supports this theory; the 4 slots would have the EUB and the UB not connected together - as they would be in a normal MUD/SPC slot.) Looking at the CPU prints (which _are_ available), it appears to confirm this theory; the 22-bit EUB address bus is carried on the MUD/EUB address lines (connectors A/B), and the 18-bit UNIBUS addresses are carried on the SPC address pins (connector E). Dollars to donuts those pins are carried across slots 1-6, and not intereconnected vertically (I have yet to verify that, either with the backplane prints, or with an ohm-meter, but I would put a very large bet on it.) Oddly enough, the CPU uses the UNIBUS SPC data pins (connector C), instead of the MUD ones (connector A). The thing is that EUB memory boards (e.g. MM11-M - the relevant page of the MS11-P prints are missing from the online set, alas) pick up the MUD pins for data. So the backplane must connect together the SPC data pins and the MUD data pins. The system can apparently also work _without_ a KT-24! Which raises the question 'how do DMA devices get to the memory when there's no KT-24'? >From looking at the CPU prints, (pg. K11) it _looks_ like the UNIBUS is automagically mapped through to the EUB when there's no KT24 (there's a pin which is apparently pulled low by the KT-24); the low (256-8=248) KB of UNIBUS address space is mapped straight across to low address space on the EUB memory bus. With no KT24 in, a standard EUB memory can go in 2. Slot 2 is special, though; the KT24 needs not just the UNIBUS lines, and EUB address lines (to map from one to the other); it also has some special interconnects with the CPU, e.g. that 'UNIBUS adapter present' line. Guess I should document all this in the Computer History Wiki, but those prints (KT-24, and -11/24 backplane) would still be useful. Noel
RE: KT-24 and/or -11/24 backplane info
> So I'm trying to work out how the PDP-11/24 memory works - in particular, how > the memory slots in the backplane can also support SPC devices. > > Chapter 5 of the -11/24 Technical Manual does not help - irritatingly! It > spends a lot of time talking about the CPU's memory mapping (well documented > elsewhere), and little on these blasted busses! If it's anything like the 11/44 (which I have, and which also has 22 bit memory addressing), the memory bus is carried on the A and B connectors, the peripheral bus on the C,D,E,F connectors. -tony
Re: MS11-P FMPS missing page
On 7/21/16 9:28 AM, Al Kossow wrote: > There are also some scans that have come in over the past couple of months I > can check > It's there, I'll upload it now and the mirrors should have it in two hours
Re: MS11-P FMPS missing page
> From: Al Kossow > It's there, I'll upload it now Great; thanks! Noel
Re: LASERS! && Freemont Street LED array (was Re: Cray J932SE (was Re: Straight 8 up on Ebay just now))
The only ones worth using that I'm aware of are Scream Tracker and Impulse Tracker and neither was around in the 16 bit ISA days pre-386, IIRC. I doubt Scream Tracker would be able to function on a 286 anyhow. It puts a 486DX2/66 at about 50% CPU load, from my recollection. The Amiga trackers were more efficient, but you got fewer channels, too. OctaMED was 8-channel and that seemed massive until it wasn't. IT was VGA but I think Scream Tracker was a 50 line text mode or something. I guess it depends if Scream Tracker used protected mode. Hmm intarnet says 386s were out during 1990 which was the year the more popular Scream Tracker was released. I swear my friend was playing coma.s3m on his Northgate 286-16 via PC Speaker Several made it there over the years. I can't remember which ones, but I do remember one day I was listening to Nectarine Radio and heard one of my own Protracker MODs. That was awesome. Awesome! Ahhh, those air-car-mounted-on-hydraulics "ride" thingys? Huh. Laser disc was always a cool thing, too. Remember "Time Traveler" ? That "holographic" (it wasn't really but it looked damn cool) game were the characters appeared in front of some kind of curved mirror volumetric display uhm, thingamabob? It used a Laserdisc too. Of course I loved Space Ace and Dragons Lair along with every other self-respecting geek, too. Also, my favorite was called "Thayer's Quest" in which you were a wizard's apprentice. Yes. There is an arcade in Chicago called Galloping Ghost which has both of the Sega holographic machines, and some of the laserdisc games like Space Ace and Dragons Lair. In the arcade world, due to the unreliability of the laserdisc players often used in games like Dragons Lair (it uses a real HeNe laser tube!) it's okay for people to move them to the MS-DOS Daphne replacement system and such. Normally MAME/emulation is frowned upon by collectors but the LD games get an okay. The way they work is amusing, the game board drives the LED score and just watches for joystick directions and sends the chapter skip commands via RS-232 or RS-422 to the serial port equipped commercial LD player in the cabinet. Pretty simple but legendary. Most commercial real estate weasels think you are the next "sucker" coming through the door. They seem to believe that some old crufty warehouse that's been empty for a decade is actually worth the ridiculous rents they charge. You'd think it'd be better to have the buildings occupied and someone giving you a bit or two to cover the property taxes, but they still don't seem to see their clients as anything more than walking cash registers. It's definitely a hard slog to find a screaming deal on space. All the hacker-spaces here in big-D have lots of folks pitching in to make ends meet. The first one here with an Ethan-style laser arcade will definitely get my membership dues. Hah awesome! Then there is the problem that nobody but old dudes remember how fun/cool arcades could be, back in a time when they looked a lot more like nightclubs. I remember them so crowded you had to go out for some fresh air. Flynn's Arcade may never live again, but it's still a paradigm of cool in my mind. Then again, I'm probably too old now to adjudicate "cool" for anyone. If you do open an laser-illuminated LED-walled arcade, let us all know so we can put you on the cctalk road-trip map. We'll rent a bus in Seattle, and drive to your place (or visa versa). I nominate Fred to run the logistics. I'll drive. :-P I help with an event each year called MAGFest which is currently in the DC area. We had 278 arcade cabinets in the arcade room and a decent deployment of classic computers in the museum. The attendance is 20,000 people or so -- it's a large event. Much of it is video game music related, and there is a ton of history and classic computer tie ins there. All the synth chips all the machines. The event is an insane amount of work though, I think it was 14 26' penske trucks some of which made 3 trips full of arcade cabinets, and the computer museum stuff occupied 2/3rds of a truck and was all owned by 3 people (just their personal stash.) No big metal mostly plastic micros but it's all hands on. There is a big arcade event in Seattle / Tacoma that has 450+ games, and there is CAX in California which just happened that has a large collection. They have a lot more people with lower numbers of games from what I understand where MAGFest has a handful of collectors with very large collections. There is definitely interest in the retro computer stuff growing outside of the age group the reminisces about it. There is also some cross over I think between the arcade and classic computer (plastic micro) crowd. -- Ethan O'Toole
Re: KT-24 and/or -11/24 backplane info
> From: Tony Duell > If it's anything like the 11/44 ... the memory bus is carried on the A > and B connectors, the peripheral bus on the C,D,E,F connectors. I have yet to totally grok the -11/44, but the documentation indicates the slots for memory are memory only (i.e. EUB on the A/B connectors). Are you saying they are also SPC on the C/F connectors? (If so, ever tried plugging an SPC device into a 'memory' slot? :-) If so, that would make it very similar to the -11/24, then - although does it also have the thing where the data lines are connected from the EUB (connector A) to the SPC UNIBUS (connector C)? The CPU prints show data from the CPU going to connector A, unlike the -11/24, which sends data to C - although if the backplane has the EUB and SPC data busses connected, it would all be the same in the end. Noel
RE: KT-24 and/or -11/24 backplane info
>> If it's anything like the 11/44 ... the memory bus is carried on the A >> and B connectors, the peripheral bus on the C,D,E,F connectors. > I have yet to totally grok the -11/44, but the documentation indicates the > slots for memory are memory only (i.e. EUB on the A/B connectors). Are you > saying they are also SPC on the C/F connectors? (If so, ever tried plugging an > SPC device into a 'memory' slot? :-) I thought there were the SPC signals on at least some of the memory slots, but I can't find the module allocation diagram right now. > If so, that would make it very similar to the -11/24, then - although does it > also have the thing where the data lines are connected from the EUB (connector > A) to the SPC UNIBUS (connector C)? The CPU prints show data from the CPU I would think so. The memory management circuitry and Unibus Map affect the address lines. There is one 16 bit data bus for memory and peripherals in these machines I think. -tony
Re: KT-24 and/or -11/24 backplane info
On Thu, Jul 21, 2016 at 12:27 PM, Noel Chiappa wrote: > Alas, there seems to be no KT-24 prints online I have an 11/24 with KT-24. I bought the KT-24 and maybe some RAM from Terry Kennedy long, long ago (1986?) so I could stuff more than 256K in my machine and run 2BSD on it. I was successful more or less, but lack of disks over 10MB (RL02) made things less than pleasant. It is very likely I have the prints for the KT-24. I might have even see it this month. I will be back over there next week and will look in that stack. It sounds like the sort of thing that ought to be widely available. -ethan
Re: KT-24 and/or -11/24 backplane info
I'm ul'ing it now On 7/21/16 9:27 AM, Noel Chiappa wrote: > Alas, there seems to be no KT-24 prints online
Re: Reproduction micros
On Wed, Jul 20, 2016 at 09:02:41PM +0200, Liam Proven wrote: > On 19 July 2016 at 17:04, Peter Corlett wrote: [...] >> RISC implies a load-store architecture, so that claim is redundant. > Could you expand on that, please? I think that IKWYM but I'm not sure. A load-store architecture is one where the ALU only operates on registers. The name comes from having separate instructions to load registers from memory, and store them to memory. The converse is register-memory, where ALU instructions can work directly on memory. However, this means that the instructions have to do quite a lot of work because now data has to be brought in from memory to an anonymous register to be worked on and then stored back to the same location. This also results in a proliferation of instruction and addressing mode combinations. Sounds rather CISCy, doesn't it? Meanwhile, a load-store architecture would have to decompose that into simpler independent load, operate, store instructions. Hey presto, RISC! [...] >> IMO, it's the predicated instructions that is ARM's special sauce and the >> real innovation that gives it a performance boost. Without those, it'd be >> just a 32 bit wide 6502 knockoff. > Do tell...? You've already answered the "6502 knockoff" elsethread, so I assume you're asking about the predicated instructions. A predicated instruction is one that does or does not execute based on some condition. CISC machines generally use condition codes (aka flags), and only have predicated branch instructions. Branch-not-equal, that kind of things. In ARM, *all* instructions can be predicated. Because instructions are 32 bits wide, it has the luxury of allocating four bits to select from one of 16 possible predicates based on the CPU flags. One predicate is "always" so one can also unconditionally execute instructions. An occasionally forgotten feature is that ALU operations also have a S-bit to indicate whether they should update the flags based on the result, or leave them alone. Between these, a conditional branch over a handful of instructions can be replaced by making those instructions predicated, and the S bit set to not update the flags. Not only has the conditional branch been deleted completely from the instruction stream which makes code noticably more compact, but there's now no branch-induced pipeline stall. Specila sauce. Unsurprisingly, x86 eventually noticed this sort of thing is useful and pinched the idea, but did it in the usual half-arsed fashion that it is famous for.
Re: Reproduction micros
In ARM, *all* instructions can be predicated. Until recently.
Re: Reproduction micros
> On Jul 21, 2016, at 4:22 PM, Peter Corlett wrote: > > On Wed, Jul 20, 2016 at 09:02:41PM +0200, Liam Proven wrote: >> On 19 July 2016 at 17:04, Peter Corlett wrote: > [...] >>> RISC implies a load-store architecture, so that claim is redundant. >> Could you expand on that, please? I think that IKWYM but I'm not sure. > > A load-store architecture is one where the ALU only operates on registers. The > name comes from having separate instructions to load registers from memory, > and > store them to memory. > > The converse is register-memory, where ALU instructions can work directly on > memory. However, this means that the instructions have to do quite a lot of > work because now data has to be brought in from memory to an anonymous > register > to be worked on and then stored back to the same location. This also results > in > a proliferation of instruction and addressing mode combinations. Sounds rather > CISCy, doesn't it? > > Meanwhile, a load-store architecture would have to decompose that into simpler > independent load, operate, store instructions. Hey presto, RISC! I would point out that RISC is not a goal in itself. Instead, the reason RISC is interesting is that -- at least at some point in the evolution of technology -- it was an architecture approach that results in more cost effective computers. That is, faster for the same money or less expensive for a given speed. It's easy to be led to the equivalence "register-memory instructions" == "complex instructions". If you're most familiar with Intel x86, or even saner architectures like VAX (which have memory to memory instructions, with a pile of addressing modes), that seems plausible. But, for example, the PDP-8 has register-memory instructions but it has a very simple instruction set and can be implemented in a tiny amount of logic. Similarly, register-memory instruction sets were used in many older architectures, and clearly were easy to do -- if your logic is tubes, you're not likely to implement large execution units! Even machines like the CDC 6000 peripheral processors, which have a pile of extra logic for controlling the CPU and surprising features like a barrel shifter, take only a few thousand gates. paul
Re: Reproduction micros
> On Jul 21, 2016, at 4:22 PM, Peter Corlett wrote: > > ... > A predicated instruction is one that does or does not execute based on some > condition. CISC machines generally use condition codes (aka flags), and only > have predicated branch instructions. Branch-not-equal, that kind of things. > > In ARM, *all* instructions can be predicated. Because instructions are 32 bits > wide, it has the luxury of allocating four bits to select from one of 16 > possible predicates based on the CPU flags. One predicate is "always" so one > can also unconditionally execute instructions. > > An occasionally forgotten feature is that ALU operations also have a S-bit to > indicate whether they should update the flags based on the result, or leave > them alone. I didn't realize that. This feature makes it more like the Electrologica machines, which invented this approach back in 1958. paul
Re: Reproduction micros
Liam Proven writes: > On 21 July 2016 at 16:45, Lars Brinkhoff wrote: >> I have both the ARM and the 6502 instruction sets very fresh in my mind >> right now. I don't see how the ARM could be a 6502 knockoff, even >> without that sauce. Care to explain in more detail? > > This is a matter of historical record, AIUI. > http://forum.6502.org/viewtopic.php?t=1892 I know it's a widely circulated claim, but I haven't seen much evidence for it. The link you posted above says "Sophie maintains that "inspired by" isn't the right choice of words." In which case I suppose "knockoff" is even less right. I'm just genuinely curious exactly which features of the 6502 and ARM instruction sets people think are so alike? Please, name specific details!
Possibly rarest Apple 1 ever for auction
Possibly the rarest Apple 1 ever is up for auction. The seller is working through CharityBuzz, which will display the computer at VCF West next month. CB's auction site: http://apple1.charitybuzz.com/ MacRumors covered it: http://www.macrumors.com/2016/07/21/charitybuzz-auctioning-unique-celebration-apple-1/
Re: Reproduction micros
On 21/07/2016 15:12, Liam Proven wrote: On 21 July 2016 at 15:24, Pete Turnbull wrote: But a StrongARM [ ... ] initially ran 3 times as fast [ ... ] and eventually SA-110 ran to over 200MHz) yet uses less power. OK. I think the first announced StrongARM, the SA110, was announced as running at 100, 133 and 200, mind you. Um, isn't that pretty much what I wrote? I'm pretty sure the first batch(es) weren't rated for the full 200. But the point about transistor count is well made. For the casual, it was displayed by the packaging. The SA110 came in a plastic QFP, and it came from the same company and around the same time as the Alpha, with threaded shanks on the packaging for screwing a heatsink into place. Spoke volumes. :-) Hmm. Never seen one like that. None of the ones I've seen in real life are PQFPs, and none have a heatsink. They're all plastic pin grid array packages. No heatsink at all. Nor does the datasheet for the PQFP show anything related to a heatsink. It also shows a PLCC version; no heatsink there either, and again I've never seen one. Maybe that's just because I normally only saw them in Acorn machines, of course. I wish I'd kept an A500, though. All I have now is the podule to connect it to a Beeb. Anybody got the machine to put it in? I have an A5000, near-new in box. But it's not been removed for about 15y and I've no idea what working condition it's in. I could post it to you when I'm next in the UK -- probably early next month. If you're interested, make drop me a line off-list. It's in my storage unit in South Wimbledon, where I have no power or anything, so I can't plausibly get it out and test it. I am planning to move the rest of my stuff here to Czechia next month, mainly for cost reasons due to the falling GBP. If you wished you could come and meet me and inspect it in person? There's a thought. I'd be up for that, though it's not actually an A5000 I meant; the A500 was the development system - looks rather like an A310 but without the fancy front bezel, and painted blue/grey. There were only a few made. They were used internally during development - hence the podule to connect it to a Beeb, which provided the I/O early on - and in the later stages before the Archimedes launch in 1987, several were loaned to software developers. -- Pete
Re: Reproduction micros
On Thu, 2016-07-21 at 17:20 +0200, Liam Proven wrote:
> On 21 July 2016 at 16:45, Lars Brinkhoff wrote:
> > I have both the ARM and the 6502 instruction sets very fresh in my mind
> > right now. I don't see how the ARM could be a 6502 knockoff, even
> > without that sauce. Care to explain in more detail?
> This is a matter of historical record, AIUI.
It's certainly an often-repeated claim but I don't think that
necessarily makes it true. Clearly yes, Acorn had done a lot of work
with the 6502 previously, the original ARM architects were obviously
familiar with its instruction set, and there are some similarities in
terminology and conventional assembler mnemonics/syntax between the two.
But in terms of the actual structure of the instruction set it's hard to
see all that much that they really have in common.
6502 is a three-register machine with variable-length instructions that
require varying numbers of cycles to complete, complex and not entirely
orthogonal addressing modes (indirect addressing works differently for X
and Y), arithmetic instructions that operate on memory directly (INC
&1234), global flags which change the behaviour of instructions
("decimal" mode), dedicated instructions for stack manipulation, no
direct ALU access to the program counter or stack pointer, and no
predication other than on branches.
ARM was, in its original incarnation at least, a 16-register machine (of
which 2 registers are architecturally special) with fixed-length
instructions, almost-entirely orthogonal addressing modes, memory access
restricted to dedicated load/store instructions, support for direct ALU
operation on the program counter (albeit with slightly weird semantics
due to early implementation decisions), no specific
architecturally-defined stack, and explicit predication on every
instruction, again orthogonal to the operation itself (even to the point
of reserving 268 million of the possible instruction patterns for "never
execute" instructions that were effectively NOPs).
So it's certainly not a trivial derivative or imitation of the 6502 in
the way that "knockoff" might imply, and even without the predication
the architectures would still be quite different. Obviously though the
ARM architecture has evolved somewhat over the past three decades and
not all the points above are still true of the latest versions.
FWIW there are now at least a few 32-bit CPU designs floating around
that really are stretched 6502s, usually including binary compatibility
with old 8-bit programs, and could legitimately be called "knock-offs".
p.
Re: Reproduction micros
On 21 July 2016 at 22:22, Peter Corlett wrote: > On Wed, Jul 20, 2016 at 09:02:41PM +0200, Liam Proven wrote: >> On 19 July 2016 at 17:04, Peter Corlett wrote: > [...] >>> RISC implies a load-store architecture, so that claim is redundant. >> Could you expand on that, please? I think that IKWYM but I'm not sure. > > A load-store architecture is one where the ALU only operates on registers. The > name comes from having separate instructions to load registers from memory, > and > store them to memory. > > The converse is register-memory, where ALU instructions can work directly on > memory. However, this means that the instructions have to do quite a lot of > work because now data has to be brought in from memory to an anonymous > register > to be worked on and then stored back to the same location. This also results > in > a proliferation of instruction and addressing mode combinations. Sounds rather > CISCy, doesn't it? > > Meanwhile, a load-store architecture would have to decompose that into simpler > independent load, operate, store instructions. Hey presto, RISC! Thanks for that. It confirms, in a considerably clearer way, what I had a dim apprehension of. But load/store automatically RISC? Aren't there non-RISC load/store processors, and indeed, RISC non-load/store ones? > [...] >>> IMO, it's the predicated instructions that is ARM's special sauce and the >>> real innovation that gives it a performance boost. Without those, it'd be >>> just a 32 bit wide 6502 knockoff. >> Do tell...? > > You've already answered the "6502 knockoff" elsethread, so I assume you're > asking about the predicated instructions. > > A predicated instruction is one that does or does not execute based on some > condition. CISC machines generally use condition codes (aka flags), and only > have predicated branch instructions. Branch-not-equal, that kind of things. > > In ARM, *all* instructions can be predicated. Because instructions are 32 bits > wide, it has the luxury of allocating four bits to select from one of 16 > possible predicates based on the CPU flags. One predicate is "always" so one > can also unconditionally execute instructions. Aha. Interesting. This I did not know. If I understand it correctly, this caused considerable problems for the RISC OS people later. The original Acorn ARM machines used 26 bits of the program counter as the PC, and the rest as flags. Later ARM chips do not support this mode, and the OS had to be partially rewritten for ARMs with a true 32-bit PC -- breaking binary compatibility with 26-bit code. I'm not sure this is the same phenomenon you're describing. -- Liam Proven • Profile: http://lproven.livejournal.com/profile Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
Re: Reproduction micros
On 21 July 2016 at 23:26, Pete Turnbull wrote: > Um, isn't that pretty much what I wrote? I'm pretty sure the first > batch(es) weren't rated for the full 200. I don't know; I'm basing this comment mainly on Wikipedia. > > Hmm. Never seen one like that. None of the ones I've seen in real life are > PQFPs, and none have a heatsink. Perhaps you misread my message. My point was that DEC's own Alpha RISC CPU was so dependent on good cooling that the actual chip package included bolts to screw a heatsink on. In comparison, StrongARM, a DEC chip based on a licensed-in ISA, needed so little cooling it shipped in a plastic package. No need for ceramics here. > They're all plastic pin grid array > packages. No heatsink at all. Nor does the datasheet for the PQFP show > anything related to a heatsink. It also shows a PLCC version; no heatsink > there either, and again I've never seen one. Maybe that's just because I > normally only saw them in Acorn machines, of course. You seem to misunderstand my remark about heatsinks. It is also possible that I am misusing the term "PQFP" but I have attempted to confirm it with Google image searches and I think it's what I meant. PQFP: https://www.google.com/search?q=pqfp&safe=off&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjSy5jp04XOAhUCsxQKHdGLBZIQ_AUICCgB&biw=1650&bih=985 StrongARM SA110: https://www.google.com/search?q=strongarm+sa110&safe=off&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiT-Mbv04XOAhXB1hQKHUb4CxQQ_AUICSgC&biw=1650&bih=985 Is that not a PQFP chip? A flat plastic package with pins on all 4 sides? >>> I wish I'd kept an A500, though. All I have now is the >>> podule to connect it to a Beeb. Anybody got the machine to put it in? >> >> >> I have an A5000, near-new in box. But it's not been removed for about >> 15y and I've no idea what working condition it's in. I could post it >> to you when I'm next in the UK -- probably early next month. If you're >> interested, make drop me a line off-list. It's in my storage unit in >> South Wimbledon, where I have no power or anything, so I can't >> plausibly get it out and test it. >> >> I am planning to move the rest of my stuff here to Czechia next month, >> mainly for cost reasons due to the falling GBP. If you wished you >> could come and meet me and inspect it in person? > > > There's a thought. I'd be up for that, though it's not actually an A5000 I > meant; the A500 was the development system - looks rather like an A310 but > without the fancy front bezel, and painted blue/grey. Ah, sorry, that was my mistake! > There were only a few > made. They were used internally during development - hence the podule to > connect it to a Beeb, which provided the I/O early on - and in the later > stages before the Archimedes launch in 1987, several were loaned to software > developers. This is the machine Dick Pountain reviewed, I think. -- Liam Proven • Profile: http://lproven.livejournal.com/profile Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
Re: Reproduction micros
On 22/07/2016 00:07, "Liam Proven" wrote: >> There were only a few >> made. They were used internally during development - hence the podule to >> connect it to a Beeb, which provided the I/O early on - and in the later >> stages before the Archimedes launch in 1987, several were loaned to software >> developers. > > This is the machine Dick Pountain reviewed, I think. Pretty sure I've got 2 of those, the keyboards are made of Dark Matter. I've never dared power one up though. -- Adrian/Witchy Binary Dinosaurs creator/curator Www.binarydinosaurs.co.uk - the UK's biggest private home computer collection?
Re: Reproduction micros
> On Jul 21, 2016, at 7:07 PM, Liam Proven wrote: > > ... >> They're all plastic pin grid array >> packages. No heatsink at all. Nor does the datasheet for the PQFP show >> anything related to a heatsink. It also shows a PLCC version; no heatsink >> there either, and again I've never seen one. Maybe that's just because I >> normally only saw them in Acorn machines, of course. > > You seem to misunderstand my remark about heatsinks. > > It is also possible that I am misusing the term "PQFP" but I have > attempted to confirm it with Google image searches and I think it's > what I meant. > ... > Is that not a PQFP chip? A flat plastic package with pins on all 4 sides? PLCC and PQFP both are plastic packages with leads on all 4 sides. But PLCC specifically means a package with J-leads: the legs come out the package side, go straight down, and tuck under the package in a J-shaped curve. PQFP (and variations with similar acronyms) have "gull wing" leads: out the side, down to near the board, and then outward resting on the board. SA110 is definitely PQFP. Here's a PLCC for comparison: http://www.batronix.com/images/products/chips/PLCC32-500-330.jpg PLCCs have fairly limited lead counts; they were common for 44 lead packages, and perhaps a bit more. PQFP goes well over 100, especially in the "fine pitch" ones with lead pitch under 1 mm. (Pain in the *** to solder...) Beyond what those can do, or for extra small packaging, we get BGA -- ball grid array. paul
Re: Reproduction micros
On 07/21/2016 04:56 PM, Paul Koning wrote: > PLCCs have fairly limited lead counts; they were common for 44 lead > packages, and perhaps a bit more. I"ve probably got more 68 pin PLCCs than anything else; I've got various ICs in 84 pin PLCC, including a some CPLDs and CPUs (e.g., 80C188EB). The convenient part is that sockets are available to provide a convenient 0.010" pin spacing by translating one row of pins to two and removal/insertion is simple. Probing for signals is likewise straightforward. After that you have to go to QFP/BGA (not terribly socket-able) or PGA. High pin-count packages are pretty large, however. --Chuck
Re: Possibly rarest Apple 1 ever for auction
On 7/21/2016 3:42 PM, Evan Koblentz wrote: Possibly the rarest Apple 1 ever is up for auction. The seller is working through CharityBuzz, which will display the computer at VCF West next month. CB's auction site: http://apple1.charitybuzz.com/ MacRumors covered it: http://www.macrumors.com/2016/07/21/charitybuzz-auctioning-unique-celebration-apple-1/ The article doesn't appear to say, but does anyone know where this Apple came from? - J.
Re: Reproduction micros
On 7/20/2016 10:42 AM, Pete Turnbull wrote: On 20/07/2016 16:44, Paul Koning wrote: It is true that a few RISC architectures are not very scrutable. Itanium is a notorious example, as are some VLIW machines. But many RISC machines are much more sane. MIPS and ARM certainly are no problem for any competent assembly language programmer. Indeed. I've written a modest amount of assembly language code for MIPS, and a bit more for ARM, and I didn't find either at all inscrutable. Yes, be aware of pipelining and branches and so on, but it's not hard. But alas , they seem to change cache and pipeline with every cpu starting with 386. How can one write effective programs for large data memory access, with out this knowlage? Ben.
Re: Possibly rarest Apple 1 ever for auction
The article doesn't appear to say, but does anyone know where this Apple came from? Go to http://apple1.charitybuzz.com/ and click "provenance".
Re: Possibly rarest Apple 1 ever for auction
"Original owner believed to be an early Apple employee ". You have the current owner who has a receipt from the previous owner who had said he got it from "maybe" an Apple employee back in 1977. -Original Message- From: Evan Koblentz Sent: Thursday, July 21, 2016 10:26 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Possibly rarest Apple 1 ever for auction The article doesn't appear to say, but does anyone know where this Apple came from? Go to http://apple1.charitybuzz.com/ and click "provenance". --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Multiflow Trace 14/300 close to being scrapped in Texas
I see that someone has picked it up via Buy It Now. No, it wasn't me. mcl
Re: Reproduction micros
> On Jul 21, 2016, at 6:53 PM, ben wrote: > > On 7/20/2016 10:42 AM, Pete Turnbull wrote: >> On 20/07/2016 16:44, Paul Koning wrote: >> >>> It is true that a few RISC architectures are not very scrutable. >>> Itanium is a notorious example, as are some VLIW machines. But many >>> RISC machines are much more sane. MIPS and ARM certainly are no >>> problem for any competent assembly language programmer. >> >> Indeed. I've written a modest amount of assembly language code for >> MIPS, and a bit more for ARM, and I didn't find either at all >> inscrutable. Yes, be aware of pipelining and branches and so on, but >> it's not hard. > > But alas , they seem to change cache and pipeline with every cpu > starting with 386. How can one write effective programs for large > data memory access, with out this knowledge? You read the Intel Optimization Guide. http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html TTFN - Guy
Re: Reproduction micros
On 7/21/2016 9:34 PM, Guy Sotomayor Jr wrote: On Jul 21, 2016, at 6:53 PM, ben wrote: On 7/20/2016 10:42 AM, Pete Turnbull wrote: On 20/07/2016 16:44, Paul Koning wrote: It is true that a few RISC architectures are not very scrutable. Itanium is a notorious example, as are some VLIW machines. But many RISC machines are much more sane. MIPS and ARM certainly are no problem for any competent assembly language programmer. Indeed. I've written a modest amount of assembly language code for MIPS, and a bit more for ARM, and I didn't find either at all inscrutable. Yes, be aware of pipelining and branches and so on, but it's not hard. But alas , they seem to change cache and pipeline with every cpu starting with 386. How can one write effective programs for large data memory access, with out this knowledge? You read the Intel Optimization Guide. http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html TTFN - Guy A read and cuss item I see. Thank you, but it seems it is still big $$$ for good compiler to follow the ever changing rules. Ben.
Re: Reproduction micros
> On Jul 21, 2016, at 8:55 PM, ben wrote: > > On 7/21/2016 9:34 PM, Guy Sotomayor Jr wrote: >> >>> On Jul 21, 2016, at 6:53 PM, ben wrote: >>> >>> On 7/20/2016 10:42 AM, Pete Turnbull wrote: On 20/07/2016 16:44, Paul Koning wrote: > It is true that a few RISC architectures are not very scrutable. > Itanium is a notorious example, as are some VLIW machines. But many > RISC machines are much more sane. MIPS and ARM certainly are no > problem for any competent assembly language programmer. Indeed. I've written a modest amount of assembly language code for MIPS, and a bit more for ARM, and I didn't find either at all inscrutable. Yes, be aware of pipelining and branches and so on, but it's not hard. >>> >>> But alas , they seem to change cache and pipeline with every cpu >>> starting with 386. How can one write effective programs for large >>> data memory access, with out this knowledge? >> >> You read the Intel Optimization Guide. >> >> http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html >> >> TTFN - Guy > > A read and cuss item I see. Thank you, but it seems it is still big $$$ > for good compiler to follow the ever changing rules. And yet they do. Processors are getting more and more complex in order to deliver power/performance improvements. Larger caches with more ways, deeper/wider pipes, more execution slots, number of rename registers, etc. What do you expect? TNSTAAFL if you want to extract every last cycle of performance out of a particular uArch. The good news is that most of the time the uArch improvements work reasonably well with relatively non-specific optimizations. TTFN - Guy
OT: Scanner discussion board(s)
I need to find a place to ask questions about scanners (scanner in the sense of an Epson Perfection 1260 flatbed scanner, not in the sense of radios). Several searches have yielded only radio-type scanner sites (or dead links). Does anyone here know of newsgroups or discussion boards for scanners? Thanks, Kurt
Re: OT: Scanner discussion board(s)
On 07/21/2016 09:29 PM, hollan...@ccountry.net wrote: > Does anyone here know of newsgroups or discussion boards for > scanners? One that I have in my bookmarks is the DIY book scanner forum: http://diybookscanner.org/forum/ But if you search using the phrase "document scanner", you'll probably get a lot more relevant hits. --Chuck
Re: OT: Scanner discussion board(s)
On 7/21/2016 9:44 PM, Chuck Guzis wrote: On 07/21/2016 09:29 PM, hollan...@ccountry.net wrote: Does anyone here know of newsgroups or discussion boards for scanners? One that I have in my bookmarks is the DIY book scanner forum: http://diybookscanner.org/forum/ But if you search using the phrase "document scanner", you'll probably get a lot more relevant hits. Never hurts to throw in the name of the scanner you are looking for. If you get no hits with that plus Chuck's suggestion, drop off info (start with Epson Perfection xxx and a topic) and drop off bits. --Chuck
Nova 3 front panel
Is there anyone with documents on the Nova 3 front panel, and what drives it? It has some number of custom DG chips, which hopefully are good if I want to try to fire it up to play, but am interested in that on good authority there are 28v incandescent lamps. A friend has an Eclipse front panel with nearly identical bezel, which has LED's and a number of differences in the logic (different connector to the system, for instance). So it is probably all run on 5v. I have not had time to figure out the driver circuit for any of the lamps to see what that may turn up, and wanted to know whether it was 28v lamps before I buy 40 of them. (the thing has only 2 out of a lot of lamps). Thanks Jim
Re: Reproduction micros
> An occasionally forgotten feature is that ALU operations also have a S-bit to > indicate whether they should update the flags based on the result, or leave > them alone. Power ISA also has this feature (the so-called "dot" instructions). It also has special forms of instructions for setting the overflow and carry flags, when appropriate. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- "Garbage in -- gospel out" -
Re: Reproduction micros
Liam Proven writes: > Peter Corlett wrote: >> In ARM, *all* instructions can be predicated. Because instructions >> are 32 bits wide, it has the luxury of allocating four bits to select >> from one of 16 possible predicates based on the CPU flags. > > If I understand it correctly, this caused considerable problems for > the RISC OS people later. The original Acorn ARM machines used 26 bits > of the program counter as the PC, and the rest as flags. > > I'm not sure this is the same phenomenon you're describing. It's not. Peter is talking about a four-bit field in the instructions. You're talking about a six-bit field in the program counter.
