I think such a project would valuable, and perhaps even more valuable if it
aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a
KDF9, say. Perhaps even a Stretch.
KDF9 had about 20K transistors, a few K logic transformers, and a comparable
number of diodes; less than 50K devices in total. I imagine this would be
easily accommodated on a modern FPGA. The big question would be whether to
go for functional equivalence, or whether to try to replicate the original
internal structures.
Documentation would be the main challenge for the latter.
--
Bill Findlay
<surname><forename> chez blueyonder.co.uk
There are several such projects, eg. this Atari ST clone:
http://www.experiment-s.de/en/
so most systems from the 8-bit era should be no problem at all.
cu
Michael
John Kent has done a lot of work using Xilinx chips and synthesizing a
6809 version of the SWTPC onto a chip.
See his webpage here
http://members.optusnet.com.au/jekent/system09/
There is also a yahoo group that is centered around the Tandy CoCO3 on
a Digilent Spartan 3 starter board with the XC3S1000 chip option. The
yahoo group is known as CoCo3fpga I think.
james
I haven't done it yet, but I am interested. I have a Digilent
Spartan3E board for that purpose. I think it is big enough for
the whole system for many of those machines.
-- glen
There have recently been some discussions along these lines in the
comp.lang.modula2 newsgroup regarding different ways of re-implementing a
Lilith.
Also MiniMig is an Amiga 500 re-implemented using an FPGA.
http://en.wikipedia.org/wiki/Minimig
--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/modula2
I did. Some 8 years ago.
http://alexfreed.com/FPGApple/
And then a few other vintage computers.
-Alex.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Looking at the PDP8 picture brings back bad memories of me helping to clear out
the computer lab at my old University which was full of PDP8 and PDP11, it all
went into the skip......;-(
Hans
www.ht-lab.com
>
>
> -- Mike Treseler
Like Alex Freed this person made an Apple 2 on FPGA
http://www.cs.columbia.edu/~sedwards/apple2fpga/
An amazing project however one looks at it. The power consumption
figures are interesting.
James
It's the answer to a different question of course,
but a National Semiconducter subsidiary once tried to
emulate an IBM 3033 at full speed using Fairchild 100k parts.
... the reason for failure is interesting ...
James Dow Allen
Many people already did that.
http://www.hat.hi-ho.ne.jp/tujikawa/esepld/esemsx2/
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
>http://www.grc.com/pdp-8/pdp-8.htm
Wow, thanks for that wonderful link, and thanks to
the wonderful but certifiably deranged people who
put together all those resources. I cut my teeth
on PDP8s in various forms; FOCAL was my first
programming language; a PDP8/a (yes, I know, not
a real classic but a nice Classic nonetheless) was
the first computer whose guts I got to mess with.
That one was mostly 74-TTL, with quite a lot of
small bipolar PROMs for its state machines.
(For the youngsters: "small" here means 256 byte
or thereabouts. Byte, not kilobyte, please note.)
And I totally agree with all the hagiography on
that site celebrating the 8's superb economy of
design, in the days when that desperately mattered.
It spilt over into programming too. OS/8 required
you to write device drivers in only 256 12-bit
words; I managed to do one of those myself.
DEC got the entire FORTRAN runtime library into
only 4K of (self-modifying!!) code.
Sorry, I'm rambling. I'm still on a nostalgia high
after a visit to the fabulous collection of old
computer equipment in the Deutsches Museum in
Munich a couple of weeks ago. Strangely, though,
they had no DEC equipment at all!
--
Jonathan Bromley
I would be interested in what the reason for failure was.
I assume it wasn't the obvious chip-chip delays using commodity
ICs.
in the early 80s los gatos did custom hardware for chip logic simulation
(LSM ... "losgatos state machine" ... then "logic simulation machine"
for publication) ... dozen plus rack boxes ... ran 50,000 times faster
faster than logic simulation in software on 3033
this mentions putting 4.5 meter dish in back parking lot of los gatos
lab (and on east coast in field near yorkton research).
http://www.garlic.com/~lynn/2010c.html#57 watches
a dish also went into austin ... and austin credits the link and access
to hardware logic simulation (relatively high bandwidth for the period
... for transmission of chip design files) with helping bring in the
RIOS chipset 12 months early ... recent reference to six chipset RIOS
(aka POWER, used in rs/6000).
http://www.garlic.com/~lynn/2010c.html#20 Processes' memory
later hardware logic simulators assumed synchronous clock ... but the
LSM had clock support ... allowed simulation of digital chips with
analog circuits ... (the then) new generation of thin-film disk heads
and chips with non-globally synchronous circuit.
however, the 3033 in bldg. 15 (disk product test lab) was used for air
bearing software simulation (shape for floating disk heads) ... misc.
past posts getting to play disk engineer in bldgs. 14&15
http://www.garlic.com/~lynn/subtopic.html#disk
misc. past posts mentioning LSM
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002g.html#77 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#82 Future architecture
http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
http://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
http://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
http://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#33 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2006q.html#42 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
http://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
http://www.garlic.com/~lynn/2007l.html#53 Drums: Memory or Peripheral?
http://www.garlic.com/~lynn/2007m.html#58 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007m.html#61 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007n.html#22 What if phone company had developed Internet?
http://www.garlic.com/~lynn/2007o.html#67 1401 simulator for OS/360
http://www.garlic.com/~lynn/2007o.html#68 CA to IBM TCP Conversion
http://www.garlic.com/~lynn/2008c.html#68 Toyota Beats GM in Global Production
http://www.garlic.com/~lynn/2009k.html#75 Disksize history question
http://www.garlic.com/~lynn/2009m.html#63 What happened to computer architecture (and comp.arch?)
--
42yrs virtualization experience (since Jan68), online at home since Mar1970
Heck, on an iCore 2 you might be able to run that under Spice! You
could probably even provide a graphical display of any front panel
lights!
Rick
http://www.merlintec.com:8080/hardware/31
-- Jecel
I remember when I first started working with computers I had a
book from our library about ECAP, IBM's Electronic Circuit
Analysis Program. I never saw or used the actual program,
and haven't heard about it since. I wonder where it went...
-- glen
Also various Forth fpga-based computers, see:
http://www.ultratechnology.com/chips.htm
http://www.pdf-search-engine.com/forth-fpga-pdf.html
--
Cheers,
Stan Barr plan.b .at. dsl .dot. pipex .dot. com
The future was never like this!
re:
http://www.garlic.com/~lynn/2010c.html#71 using an FPGA to emulate a vintage computer
no direct knowledge and web search is rather sparse ... a couple IEEE
citations:
http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F23%2F4335780%2F04335910.pdf%3Farnumber%3D4335910&authDecision=-203
http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F6%2F5218140%2F05218152.pdf%3Farnumber%3D5218152&authDecision=-203
in the aftermath of the troubles of the early 90s ... there was push to
move to industry standard tools ... part of which involved transfer of
internal tools to chip tool vendors (and some number of the internal
chip tools people spending a lot of time with these vendors ... and then
some number leaving and joining external vendor).
I've mentioned recently porting nearly 60k statement pascal program
(that did circuit layout) to other platforms, as part of such a tool
transfer.
http://www.garlic.com/~lynn/2010b.html#74 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010c.html#29 search engine history, was Happy DEC-10 Day
in the mid-80s ... internally, there was big push to expand a lot of
mainframe manufacturing capacity anticipating the market would double in
size by the early 90s. Not particularly "career enhancing" ... I made
some observation that computer hardware was becoming increasingly
commoditized ... resulting in thinner margins & profits ... which would
at least require significantly cutting the number of related employees
to stay out of the red. misc. past posts mentioning various (non)
"career enhancing":
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
http://www.garlic.com/~lynn/2007f.html#30 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007r.html#6 The history of Structure capabilities
http://www.garlic.com/~lynn/2008l.html#23 Memories of ACC, IBM Channels and Mainframe Internet Devices
http://www.garlic.com/~lynn/2009c.html#54 THE runs in DOS box?
http://www.garlic.com/~lynn/2009p.html#34 big iron mainframe vs. x86 servers
http://www.garlic.com/~lynn/2009r.html#49 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#50 "Portable" data centers
http://www.garlic.com/~lynn/2009s.html#4 While watching Biography about Bill Gates on CNBC last Night
I think you mean that chip-chip delays would be too obvious
to be interesting. :-)
The commodity high-speed ECL chips were almost in the
same ballpark as IBM's chips for speed and density, but
IBM's packaging was better in various ways. The one
difference I found "interesting" and which seemed to be
a significant factor in the slowdown was that IBM used
smaller circuit boards. Each signal was therefore
closer to the backplane, so closer to more chips total;
in other words the smaller circuit boards allowed IBM's
wiring to take better advantage, in some sense, of
the 3rd dimension!
I think there were other important factors in that
project's failure, but there's no need to start
any anti-NatSemi flamefest. :-)
James Dow Allen
You can add to that list:
http://www.abc80.org/~hpa/fpga/
-hpa
A KDF9, maybe, but Stretch? You'd have to be seriously masochistic, or
downright insane :-)
Cheers, Mike.
---------------------------------------------------------------
Mike Hore mike_h...@OVE.invalid.aapt.net.au
---------------------------------------------------------------
If you want funtional equivalence to the KDF-9 instruction set,
then get yourself a copy of the Forth language.
You can add those too :
http://torlus.com/index.php?2007/12/05/208-oric-in-a-fpga-continued
http://torlus.com/index.php?2007/03/19/200-thomson-mo5-in-a-fpga
http://torlus.com/index.php?2007/01/31/198-hector-hrx-in-a-fpga
Someday, I will set up a dedicated page for all these projects :)
> (see below) wrote:
>> On 05/02/2010 18:19, in article
>> badc12c3-cb2b-4ce9...@o8g2000vbm.googlegroups.com, "Eric
>> Chomko" <pne.c...@comcast.net> wrote:
>>
>>> Has anyone created a copy machine of an old system using an FPGA? I
>>> was wondering if it would be possible to take an entire SWTPC 6800 and
>>> compile the schematics and have it run on an FPGA board.? Wouldn't
>>> even have to be the latest Xylinx product, I suspect.
>>
>> I think such a project would valuable, and perhaps even more valuable if it
>> aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a
>> KDF9, say. Perhaps even a Stretch.
>
> A KDF9, maybe, but Stretch? You'd have to be seriously masochistic, or
> downright insane :-)
Very possibly. 8-)
While there are strong similarities between KDF9's Usercode assembly
language and FORTH, they are by no means functionally equivalent.
As it happens, I already have a prototype KDF9 running in my laptop -- but
implemented in software, not an FPGA. See:
<http://www.findlayw.plus.com/KDF9>
Thanks! This is doubly wonderful since not only do I love FPGA based
retrocomputing but am also very interested in the history of computing
of countries outside the better known US/UK stuff.
-- Jecel
Great! This subject really needs a whole wiki to itself rather than
just a page at a hard to remember address. This is on my "to do" list,
but it will be a while before I get to it.
-- Jecel
While I'd love to see an Atlas, I rather doubt any of the software survives.
Reviving early computing dinosaurs from the surviving DNA is difficult.
I would be interested in hearing if any Atlas software survives. Sadly, it appears that
the Titan software has been lost as well. The Computer History Musuem has paper copies of
Stretch diagnostics, which someone had been working on OCRing, but I've not heard anything
about that effort for over a year. 7090/94 is in better shape, and there are copies of software
for it, including FORTRAN, running in simulation.
Personally, I'm very interested in seeing B5500 running again. I'm hoping the MCP tapes we have
in the CHM archives are recoverable. I have scanned most of the software listings CHM has in the
archives and put them up on bitsavers.
There is also someone working on an implementation of the CDC 6600 derived from the original
engineering drawings.
Hans Pufal was working on microcode level simulation of the 360/30, working from reverese-engineered
microcode from the Field Engineering documents.
I have a SWTPC 6809. I will look into John Kent's project. Looks like
lots of fun.
Eric
Yep, that is the idea. I run a small Vintage Computer Club near
Greenbelt/College Park, MD and one of the gusy suggested we do such a
thing, so we are trying to get ideas. This thread is really good stuff
for that purpose.
Eric
Ouch! Heck even the govt. facility's excess warehouse where I work
saved back the remaining PDP-11s knowing they had collector value. I
believe that they have all been sold off as of about 5 years ago.
Very cool.
Eric
Yes, no doubt. I want to do it too, along with others in my Vintage
Computer Club. Perhaps we'll pick something that hasn't been done yet.
Eric
Thanks, for the link.
Eric
I often wonder if anyone has done an emulator for the Russian ternary
computers, or even if there's any documentation in English. Back to
Google again...
http://en.wikipedia.org/wiki/Setun
http://www.computer-museum.ru/english/setun.htm
and http://en.trinary.ru/projects/setunws
also:
http://www.forth.org.ru/~dssp/msdos_e/papers/daf.txt
Most interesting to an old Forth-er like me!
The B5500 was the first computer I did any programming on, when
I was about nine. Not so much later, it was sold. I then
rediscovered programming some years later, first on an HP 9810A,
and then OS/360 Fortran.
It would be nice to try the B5500 again, though software emulation
(instead of FPGA emulation) would probably be just fine.
(snip)
> Hans Pufal was working on microcode level simulation of the 360/30,
> working from reverese-engineered microcode from the Field
> Engineering documents.
I thought someone had copies of the microcode, but then again
maybe that is what they meant. Are there no copies of the
actual ROS available in museums?
-- glen
That's a line that deserves to be put above the entrance to a computer
museum.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
Typo, this was what I actually meant to say
"Reanimating early computing dinosaurs from surviving DNA is difficult."
From the sound of the projects being done, it sounds like it's a
challenge to use FPGA to emulate even simple instruction sets, no?
If not, you'd have to cob up some Algol compiler to cross-compile ESPOL,
and then bootstrap MCP, Algol, and ESPOL using that. Difficult, but
do-able, once the code gets OCR'd (or, having looked at the listings,
more likely re-keyed.)
In the same sense that emulating them in TTL chips is a challenge --
it's a comparable task, but done by writing VHDL or Veriolog instead of
by using a wire-wrap gun.
If you really want to embed a simple computing core in an FPGA project,
they're available off-the-shelf in libraries and can just be stuck in as
needed. But that's not the goal of these projects.
|In comp.arch.fpga Eric Chomko <pne.c...@comcast.net> wrote:
|> Has anyone created a copy machine of an old system using an FPGA? I
|> was wondering if it would be possible to take an entire SWTPC 6800 and
|> compile the schematics and have it run on an FPGA board.? Wouldn't
|> even have to be the latest Xylinx product, I suspect.
|
|I haven't done it yet, but I am interested. I have a Digilent
|Spartan3E board for that purpose. I think it is big enough for
|the whole system for many of those machines.
|
|-- glen
|==============
Glenn
The XC3S500e is big enough to do most if not all.
james
Well, I have thought as far as the Sparcstation 1.
That might require a bigger FPGA.
Sun has released verilog code for more recent SPARC processors.
It is likely that those, along with the rest of an actual system,
would be too big for even the larger XC3S devices. Maybe the
Spartan 6 is bigger.
Another one to consider is the Macintosh Plus or SE. That is,
68000 based Mac. Also, 68010 or 68020 based Sun systems.
-- glen
> Al Kossow <a...@bitsavers.org> writes:
>
>> Reviving early computing dinosaurs from the surviving DNA is
>> difficult.
>
> That's a line that deserves to be put above the entrance to a
> computer museum.
"It's a Unix system! I know this!" -- Jurassic Park
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Are you thinking what I'm thinking?
Ancient processors evolving into more terrifying CPUs?
Perhaps some things man wasn't meant to tamper with.
I used ECAP at Penn State in the late 70's. By then, Berkley SPICE
was looking like the better tool.
Rob.
The commodore 64 clone "C-one" which is in your list is interesting.
It has been implemented in an ASIC and has been sold as a commercial
product.
http://en.wikipedia.org/wiki/C64_Direct-to-TV
/BAH
But no front panel yet. Just a CPU with BRAM memory and teletype. Passed the CPU maindecs.
--
---
http://pdp8.hachti.de
This may be the time to mention Spare Time Gizmos again, another run
is being contemplated if enough interest is shown. I have no
connection with the project other than wishing I had the money and
time to build one!
http://www.grc.com/pdp-8/yourown-sbc.htm
At a PPoE, I knew a Russian who worked there... that had a PDP-11
manual written in Russian. He would *not* be talked out of it,
though. :-(
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
"I have discovered a truly wonderful proof of this, but the margin
is too narrow to hold it." -- Pierre de Fermat
http://www.youtube.com/watch?v=dFUlAQZB9Ng
> Jecel wrote:
> > On Feb 8, 7:05 am, Gregory Estrade wrote:
> >> You can add those too :
> >> http://torlus.com/index.php?2007/12/05/208-oric-in-a-fpga-continued
> >> http://torlus.com/index.php?2007/03/19/200-thomson-mo5-in-a-fpga
> >> http://torlus.com/index.php?2007/01/31/198-hector-hrx-in-a-fpga
> >>
> >> Someday, I will set up a dedicated page for all these projects :)
> >
> > Great! This subject really needs a whole wiki to itself rather than
> > just a page at a hard to remember address. This is on my "to do" list,
> > but it will be a while before I get to it.
> >
> > -- Jecel
>
> "I have discovered a truly wonderful proof of this, but the margin
> is too narrow to hold it." -- Pierre de Fermat
If only someone had provided him with some butter.
--
A computer without Microsoft is like a chocolate cake without mustard.
When I was visiting a friend of mine in St. Peterburg, I was practicing
reading names written in Cyrillic by going down his bookshelf and
pronouncing all the authors names. I came across "Kapps and Stafford"
... He had a Russian translation of the VAX Assembly textbook. Like
your cow orker, he could not be convinced to part with it.
--L
> This may be the time to mention Spare Time Gizmos again, another run
> is being contemplated if enough interest is shown.
The build is happening, and Bob is fronting the money to do it.
http://www.sparetimegizmos.com/Hardware/SBC6120_GroupBuy_2010.htm
There was some discussion at a over dinner last night of some people
that were thinking of buying the kits to find people who wanted to buy
the CPU board and just using the front panel with an FPGA-based redesign.
There are loads of such projects out there, even a commercial one called
C-One "the reconfigurable computer", here:
http://www.c64upgra.de/c-one/
/BAH
If only I didn't already have a bench covered in half-finished radio
projects :-(
It is a great effort but last time I checked it was a bit pricey ~$300
for a basic system.
Just my opinion but some of the other ways of doing it will be more
successful if volume is the sole criteria. For instance all those
MP3/4 type players seem to use some variation of Rockchip or Sunplus
'System on a Chip.' In the Sunplus case it has ~160 mHz ARM processor
as the core. Currently they only emulate NES or GB, type of old system
but they certainly have the processing power and enough I/O sans
keyboard to do most 8 bit and 16 bit computers. Build quality is a
problem of course but you can pick a 4 gig system with LCD screen for
about $50.
Rick
Par-Kay???
But the neat thing about the C-One is that it has support for what, 10
systems in total and at the least 4 of them really good.
There is also some support for connecting to older hardware and more on
the way I gather, but frankly it is more of a hobbyist unit than what
you are describing
/BAH
|It is a great effort but last time I checked it was a bit pricey ~$300
|for a basic system.
|
|===================
Try 333 euros now. $453 US. That includes the Cyclone 3 FPGA extender
board.
james
|===========
Kids today have little concept of what is too much.
For what the board does it is a good price even now at 333 euros. The
boards are no longer shipping at the 269 euros anymore. The increase
price now reflects that the system ships with the FPGA extender card.
Also the main board uses two older FPGAs, EP1K30 and EP1K100.
You also need a SVGA monitor, a keyboard, memory, a PS2 style mouse,
floppy drives, hard drive, ATX case and ATX power supply. So to get a
system up and minimally running is going to cost you at least another
$200 additionally unless you have all those components lieing around
in your juck box.
It is a great effort on the team's part. It can be very flexible
system now with the Cyclone 3 extender board.
james
59. Directed at Olafur too, it isn't a question of value for goods
delivered. Having recently priced getting some prototype boards made,
I think they are priced appropriately.
I have a pretty good idea of ratio of shall we say sophisticated users
to the Plebs. An analogy would be a Porsche is more expensive then
riding a bus. The Plebs aren't concerned with file I/O, clock
frequency, or storage. If they look back at all it is just to play a
game of Pac Man or Bard's Tale. An emulator or SoC is fine and suited
to their needs. This reduces the potiential market to hard core users.
Rick
Ah, OK.
>
> I have a pretty good idea of ratio of shall we say sophisticated users
> to the Plebs. An analogy would be a Porsche is more expensive then
> riding a bus. The Plebs aren't concerned with file I/O, clock
> frequency, or storage. If they look back at all it is just to play a
> game of Pac Man or Bard's Tale. An emulator or SoC is fine and suited
> to their needs. This reduces the potiential market to hard core users.
If you had been a youngster, I would have poked a little bit more
to try to find out what kinds of things would interest you ;-).
I'm hearing rumors that the current young generation are interested
in learning about how all the insides work.
/BAH
> On 2010-02-09, Charles Richmond <fri...@tx.rr.com> wrote:
>
>> Charlie Gibbs wrote:
>>
>>> In article <1bd40ft...@snowball.wb.pfeifferfamily.net>,
>>> pfei...@cs.nmsu.edu (Joe Pfeiffer) writes:
>>>
>>>> Al Kossow <a...@bitsavers.org> writes:
>>>>
>>>>> Reviving early computing dinosaurs from the surviving DNA is
>>>>> difficult.
>>>>
>>>> That's a line that deserves to be put above the entrance to a
>>>> computer museum.
>>>
>>> "It's a Unix system! I know this!" -- Jurassic Park
>>
>> http://www.youtube.com/watch?v=dFUlAQZB9Ng
>
> Another terrible moment in a deeply terrible movie.
>
> I wanted the dinosaurs to kill them all. And quickly.
You're as much of a curmudgeon as I am. At the end of
"The Perfect Storm" (one of two movies for which I feel
thoroughly ripped off for the price of admission), my only
thought was: "Good riddance to those stupid people."
(Unfortunately, the screenwriters survived.)
At least in _Jurassic Park_ you could root for the dinosaurs. _The
Matrix_ (my candidate for Most Overrated Movie Ever) didn't even have
that.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Yes, the Hugo Weaving character was as obnoxious as Neo and the
others...
Ugh. My take on _The Matrix_:
- The theme is a half-baked mishmash of tired cliches from solipsism,
postmodernism (mostly misunderstood Baudrillard), and
self-actualization nonsense from the likes of Landmark Education.
- The conclusion is a nasty bit of proto-fascist self-aggrandizement:
regular people can't handle the truth, so I'll just use my magic
powers to guide them in their delusions.
- The SF is simply stupid. Oh, the computers keep us around because
they use our brains to generate electricity. Apparently someone
accidentally loaded the "really inefficient engineering" software
before the revolution. Something unspecified was done to the
atmosphere, and now the planet is all cold (was the atmosphere made
really reflective?), "except near the core" - has tectonic action
ceased? How fuckin' far in the future is this supposed to be?
- The milieu is inconsistent and nonsensical. The Matrix is a virtual
world, but you can die there (an agonizingly awful cliche). To get
out, you have to find a "land line", which corresponds to a real
telephone line in the real world somehow - even though the Matrix is
virtual. You can do anything you can imagine, except, apparently, you
can't (or the main characters have really piss-poor powers of
imagination). The villains are software constructs, but for some
reason they have all the foibles of humans, like petty emotions and
disliking certain odors.
- The action scenes are dreadful. The martial-arts choreography, by
Yuen Wo Ping, was decent, but there was far too little of it, and (as
is almost always the case with US movies) it was filmed very poorly,
with far too many close-ups and cuts. (This is partly because the
actors weren't up to doing any of the real stuff, of course.) The gun
battles are just noisy exercises with tons of squibs going off,
utterly devoid of artistry or interest.
- Some of the effects were novel at the time, but they weren't used in
any very interesting or cohesive way. (Contrast _Star Wars_, where
visual effects are seamlessly integrated into the plot, not thrown on
screen to stand on their own.)
- Pretty much everything _The Matrix_ did had already been done better
in another film. Proyas' _Dark City_, for example, is a far superior
treatment of the imaginary-world-and-superman motif. Lots of Asian
films did the action material better in pretty much every respect.
> On 2010-02-12, Michael Wojcik <mwo...@newsguy.com> wrote:
> > Huge wrote:
> >>
> >> Another terrible moment in a deeply terrible movie.
> >>
> >> I wanted the dinosaurs to kill them all. And quickly.
> >
> > At least in _Jurassic Park_ you could root for the dinosaurs. _The
> > Matrix_ (my candidate for Most Overrated Movie Ever) didn't even have
> > that.
>
> I like(d) The Matrix.
>
> The sequels were pointless and boring.
The original was a very poor imitation of "Gray Matters".
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Let me add my re-implementation of a New England Digital Able, the first
commercial single-instruction processor.
<http://sites.google.com/site/macthenaief/Home/retro/able>
<http://sites.google.com/site/macthenaief/Home/retro/fab>
Absolutely. There a number of them. This guy has done a PDP-4
and PDP-8,
http://homepage.mac.com/dgcx/pdp4x/
http://homepage.mac.com/dgcx/pdp4x/
I am in the process of doing a PDP-1. My background is high
performance computers so it is a high performance design.
Todays FPGAs and CAD allow a much more agressive implementation
than the original designers could afford and with far less
effort. The original PDP-1s sold for about $100K in early
1960s' dollars. Mine will cost only a few hundred dollars to
build.
Those interested in the subject might also be interested in the
simh group,
http://simh.trailing-edge.com/
which does simulators for legacy computers.
Gary
Do you pipeline it? Any issues?
>Todays FPGAs and CAD allow a much more agressive implementation
>than the original designers could afford and with far less
>effort. The original PDP-1s sold for about $100K in early
>1960s' dollars. Mine will cost only a few hundred dollars to
>build.
A PDP1 is cool. Please tell when you have a production run. If
I have the money, I may shell out for a kit suitable for an
economist to assemble.
But a PDP6, or a '10 with a modern performance design would
be ultracool.
>Those interested in the subject might also be interested in the
>simh group,
>
> http://simh.trailing-edge.com/
>
>which does simulators for legacy computers.
I have used several of these emulators for years. Thank you
for your excellent work.
-- mrr
The current design is not pipelined. Ultimately, I expect it
will be pipelined and latched.
> A PDP1 is cool. Please tell when you have a production run. If
> I have the money, I may shell out for a kit suitable for an
> economist to assemble.
I can make the board and chip design available.
> But a PDP6, or a '10 with a modern performance design would
> be ultracool.
That would be a group effort. I have an emotional attachment to
PDP-1s. I spent many happy hours playing Spacewar on a PDP-1
and learned to program on it as well.
Gary
Re your background is high performance, what do you like best
about the PDP-1? (Or haven't you got that far?)
/BAH
The best (and worst) is the PDP-1's simplicity. It is easy to
implement. For the most part conditionals are decoupled from
arithmetic operations. That helps branches, which are always a
bottleneck.
The single arithmetic register is a bottleneck. Out of order
execution, for example, is difficult when almost every
instruction accesses the same register. Other the other hand,
if you treat memory as registers, which is feasible (there are
only 4K words), you can do interesting things with out-of-order.
RISC computers, such as ALPHA and MIPS, have compilers that help
the hardware by ordering instructions. With legacy software,
you cannot do that.
For comparison, when I was a DECie, I did the instruction fetch
and processing unit for a data flow VAX (never produced,
unfortunately). The number and complexity of instructions and
the weirdness of a few made high performace difficult. That was
one of the reasons DEC developed ALPHA.
Gary
In Circuit Cellar's 2009 issue is the article, "Retrocomputing on an
FPGA: Reconstructing an '80s-Era Home Computer with Programmable
Logic". The author describes his experience of designing a Apple II+
compatiable project.
Another project I know of is mentioned at:
http://vector-graphic.info/vg_links.aspx
This whole website is dedicated to Vector Graphic S-100 computers. The
link half way down the page is wrong but the project can be found at:
http://opencores.org/project,vg_z80_sbc
At this web is 8086 core:
http://www.ht-lab.com/freecores/cpu8086/cpu86.html
I believe the sample project with the core would be equivalent of a
8086 SBC running DOS.
Derek
NOT a FPGA but certainly a design I would like to see executed in FPGA
and very vintage
http://laughtonelectronics.com/arcana/BrideOfSonPg1.html
He used a 65C02 and a KIM as his starting point. The 65C02 was chosen
because all
of its unimplemented instructions became NOPs. If I have it right, he
then intercepts
the unused op codes and uses them for his own purposes like extending
the memory
addressing. It is an interesting design in that when you move the
microcode off the
main processor you can optimize the system for very specific tasks. In
his case he
used it for running Forth.
I guess the argument could be just do the entire thing in VDHL or use
the right processor
for the job.<grin> Instruction set problems seem to come up fairly
often. I *think* some
C implementations could use a separate hardware stack for instance.
Rick
If you can track down a copy of _Mechasm_ by John Sladek, you could try
it. Quite funny. World infested by self-replicating robots. Humanity
enslaved. Apparently written when a Vegas one-armed bandit actually
had one arm, which you had to pull. Greater message that evolutionary
solutions are not absolutely required to be efficient, beyond what it
takes to keep running.
Mel.
This sounds like a story I once read, which I've always wanted to find
again. I remember a world being busily disassembled by robots looking
for raw materials with which to build more robots. Someone came across
a robot busily filing a gear out of a piece of scrap metal. The person
kicked the robot, which fell to pieces - it was poorly built, there
being not many raw materials left by then - and immediately a swarm
of robots ran out of the woods and grabbed the pieces, running off
with them to build more robots.
It was a delightful story. And after a bit of googling for John Sladek,
it sounds as if he's either the author of the story I remember, or worth
reading in his own right. Thanks for the tip.
A hardware stack for C is a bit of a problem. C tends to need a
rather large stack because of the stack frames used. A language like
Forth, on the other hand, can get by with a very small hardware stack
because the stack usage tends to be minimal and subroutine nesting
does not automatically add to the data stack depth. Instead, often
parameters that are passed into one routine are also passed onto the
next without duplication until they are consumed by the calculations
that need them. In c every call copies every piece of data needed for
the lower level code creating stack "bloat" if you will.
There are any number of Forth CPU designs, many of which use a
hardware dedicated stack for data and another for addresses.
Rick
It depends, somewhat, on the programmer. In K&R C, you couldn't
pass a struct, but instead a pointer to a struct. That kept
the stack a little smaller, at least. With C89, as with K&R,
arrays (including automatic, allocated on the stack) had a
constant dimension. If I remember right, C99 added the ability
to dimension local automatic (stack) arrays with variables.
(Previously, a pointer on the stack and malloc() would have
been used, along with the requirement to remember free().)
> A language like
> Forth, on the other hand, can get by with a very small hardware stack
> because the stack usage tends to be minimal and subroutine nesting
> does not automatically add to the data stack depth. Instead, often
> parameters that are passed into one routine are also passed onto the
> next without duplication until they are consumed by the calculations
> that need them. In c every call copies every piece of data needed for
> the lower level code creating stack "bloat" if you will.
If you only pass pointers, it isn't so bad...
-- glen
I'm pretty sure ALGOL and PL/I are far worse WRT to stack bloat than
is C.
But yes, nothing would beat FORTH unless you used assembly and only
architectures with HW stacks. Two being better than one (i.e. 6809 vs
6800).
> There are any number of Forth CPU designs, many of which use a
> hardware dedicated stack for data and another for addresses.
Years ago I worked as a research assistant with a professor doing High-
Level
Architectures. I suggested Forth and he sort of poo-pooed the idea
mostly
because his grant was from the Air Force and they were all about using
JOVIAL
at that time. This was pre-RISC days and the whole computer
architecture idea
based upon a high-level language never really took off. Nor did the
use of a medium
level language like Forth as far as I can tell.
Eric
ALGOL, PL/I, and C pretty much require local variables to
be automatic. (PL/I procedures without the RECURSIVE attribute
might get away with static allocation.)
Fortran up through Fortran 77 allowed local variables to be
statically allocated. Without the RECURSIVE attribute, it
probably still does.
Other than passing of arguments, it depends on how you allocate
your variables. PL/I has the STATIC attribute which will keep
variables off the stack, as does C. Be careful with recursion, though.
For ALGOL, maybe you need internal procedures using variables from
outside, and to minimize actual local variables. PL/I can easily
generate temporary variables, including arrays.
> But yes, nothing would beat FORTH unless you used assembly and only
> architectures with HW stacks. Two being better than one (i.e. 6809 vs
> 6800).
-- glen
And even though structs *can* be passed to and returned from
functions, a programmer is *not* forced to do that. One can still
pass the pointers to structs. One can still use "malloc()" and
"free()" to allocate variable-size arrays. If you are an "old
time" C programmer, this probably fits better in your way of
thinking. In any case, if it is important to conserve stack space,
the "good ole ways" can still be used.
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
PL/I can be, but doesn't have to be. If the arguments of a procedure
match the parameters, only the argument address (and possibly a
descriptor address for strings structures, and arrays) is passed. If
the argument doesn't match, the compiler nicely copies it to a "dummy
argument" that does. As usual, the programmer needs to have some idea
what's going on.
Some C implementations supported alloca() which would allocate
on the stack (and would be automatically free'd on return).
A minimal C stack frame is the return instruction pointer, with
arguments passed in registers.
scott
> A hardware stack for C is a bit of a problem. C tends to need a
> rather large stack because of the stack frames used.
What could happen, though, on a computer with a small hardware stack
is that the compiler would use a software stack for things like
subroutine calls (which must always work, no matter how deeply they
are nested) and use the hardware stack for things it can control -
such as the layers of parentheses in assignment statements.
That, for example, is presumably how one would go about writing a C
compiler for a KDF 9.
John Savard
The way the Algol 60 compilers on KDF9 worked is well documented.
The Whetstone compiler generated its own Algol-oriented byte code, which is
very similar to the slightly later B6500 machine code.
The Kidsgrove and EGDON compilers generated KDF9 machine code.
Managing the hardware stacks difficult, as it would have needed global data
flow and control flow analyses. The Kidsgrove compiler made a basic but not
very successful attempt at this.
See <http://sw.ccs.bcs.org/KidsgroveAlgol/INDEX.HTM>.
--
Bill Findlay
<surname><forename> chez blueyonder.co.uk
The thing about ALGOL parameter passing was that there was four ways
to do it according to the ALGOL 60 spec. As I recall from my Comp Sci
days at U of MD, ALGOL used call by value, call by reference, call by
value/result, and call by name. I'll tell you I still didn't
understand why more than call by value and call by reference are
needed. Anyway...
Speaking of ALGOL parameter passing, what's a "thunk"? Anyone get that
and they get a gold star for the day. Suffice to say, my prof back in
the day (Dr. John Gannon, may he RIP), was the sort of guy that knew
everything about everything thing when it came to computer language
translation, even the trivia!
Eric