trolling through some old mit backups...
I found a copy of "advent" fortran source from 1979. Is that interesting
to anyone? It looks more complex than the Crowther sources but I have
no idea.
I also found a file with PDP-6 Space war sources. Anyone interested?
It mentions a "340" display. It's an ITS "ar" file which I think would
be easy to pull apart back into ascii files.
-brad
> Date: Tue, 25 Mar 2008 23:53:38 -0500
> From: Randy Dawson
> come on stop it guys
> its a standard 24, 28 pin thing
> everybody made these ROMS, we did not have otp and the cheap no window
> package untill - 87 I think. reading it out is the mystery and the fun
> inside
Well, it's this comment from Andrew:
> The date code in BIOS indicates about 1994 vintage or so...
that makes me think it's probably flash/EEPROM. By 1994, almost
nobody was putting BIOS code in ROMs for PeeCees. Maybe you know of
someone, but I'm drawing a blank. And it might be an OTP also.
Regardless, given the capacity, if it's a user-programmable ROM of
any sort, there's bound to be manufacturer's information.
Now, had Andrew said "1984", then I'd say you had a point; but even
then, the size (512Kbit) would have been very unusual.
Hey Andrew, if you can read the BIOS out, get the Award version
number information too--the host system can often be identified from
it, as there's a vendor ID in it.
Cheers,
Chuck
> From: "pichotjm" <pichotjm at free.fr>
>
> ECN: Engineering change notice. Indicates revision of PCB.
Thanks, I did not realise you had already translated it to English.
>
> The ODP-505 is a pure binary machine, not designed for arithmetics,
> statistical purposes or BCD computations.It is a real time (!!!)
> computer.
> Get some datas (voltages, frequencies, switch states, motor speed,
> temperature...) compare to thresholds or values, and speed up /
> slow down
> motor, or move a cadmium bar (?) in a nuclear reactor...
I see. The Elliott machines were the same (but not the ICT1301),
keeping the gun of a tank level and aimed in the right direction,
accepting data from gyros and inertial sensors and tracking the
position and orientation of an aircraft or ship, cross checking with
compasses and other navigational systems, analysing sonar data and
tracking enemy submarines etc. By the time of the 920ATC we even used
a special real time programming language called Coral66, based on
Algol60 syntax but with cut down semantics to give highly efficient
run times. Before that everything was done in assembler (called
S.I.R.) or machine code.
>> | The architecture of your machine reminds me of the first machine I
>> | was allowed to operate. It was an 18 bit binary machine, it had
>> 8k of
>> | memory built in, expandable with external modules and was made
>> by the
>> | Airborne Computing Division (ACD) of Elliotts, it was an Elliott
>> 920B
>> | and was a compact, flyable version of the commercial Elliott 903.
>> | There had been an earlier model 920A which I think would have been
>> | Germanium and was roughly the size and shape of a carpenters work
>> | bench. This may have been contemporary with your earlier machine I
>> | think. Unfortunately I never saw one in the flesh, but there was a
>> | bench in the computer room which I found out later, was the empty
>> | chassis of a 920A. Behind the bench was a large panel full of
>> | electrical 'chocolate strip' connectors where the analogue and
>> | digital input and output signals of the 920A could be connected up.
>> | Apparently some of the analogue outputs had been connected up to an
>> | oscilloscope to provide a visual display unit, though it used a
>> fair
>> | bit of processor time to keep it refreshed, even with the long
>> | persistence phosphor of an oscilloscope. The panel had been covered
>> | with board with pegs to hold mylar paper tapes and until the day it
>> | was scrapped I had not seen what was behind it.
> Very interesting!There are some video connector in the earlier
> machine and
> the Serel companywas specialized in high tech video solutions.
Possible application for computers in video back then were
superimposing images and standards conversion and just possibly
titling and graphics.
> I have read
> somewhere in docs, thatthis computer have a screen output...
If it has two or preferably three digital to analogue converters then
a vector display is fairly easy, but maybe it was more complex than
that, and you only need one digital to analogue converter for a
raster display, provided you have enough CPU power to both drive the
display in real time and do any processing required as well.
I should explain what I said about two or three A/D converter, you
have one to drive the X plate and one for the Y, ideally one for the
brightness (Z), but with a fast enough converter, you can deflect the
beam so fast so it will not mark the screen significantly and so no
need to turn the beam off before moving to the next item to be
displayed.
> I have found,
> last week a small notice describing microprogramming on
> ODP-505.http://pichotjm.free.fr/Serel/ODP505/MicroProgrammation/
> MicroProgrammation.html(doc
> found in photomultiplier doc!)I have found commercial document
> describing
> displays and analog memories...I don't know the date... (1970?) I
> have to
> study these documents...
I had a look but my understanding of French is terrible, and
technical details in French are even more difficult.
>> I have a
>> earlier machine from the same company SEREL, named OA-1001. Built in
>> 1959/1960.I need to restore it. It lays on the floor (horizontal
>> position)... The blue one
>> here:http://pichotjm.free.fr/Serel/Photos/Photos.htmlI will start
>> restoring
>> next month (with the Sun!)
>
> | What is involved in the restoration? Do you intend to make it work,
> | this would be very hard without the schematics.
> As you know, i am alone,
> here. I want to make an esthetic restoration:Photos and notes,
> dismantle,
> photos and notes, wash, dry, fix the rust, protect with Rustol,
> photos an
> reassemble. I hope to be capable to do that... may be one year, may be
> two...
As I understand it, that is what the big museums call preservation.
There has been a lot of discussion of the relative merits of
preservation and restoration. Restoration is what they call it when
we return a computer to running condition, preferably so it can be
demonstrated. There is some truth that restoring a computer always
destroys some of the original and that preservation is, to the
purist, a better thing to do. As I have two 1301s, I have the luxury
of being able to restore one and preserve the other, but restoration
is a lot more enjoyable to me.
The other thing of course is simulation. This can be done at various
levels, simple simulation of the instruction set, more complex
simulation at gate level and in theory the ultimate would be to have
a 3D model of the computer you could walk around and inspect the
inside of, and attach a virtual oscilloscope to and watch the
analogue signal levels and be able to do hardware patches and have
simulated hardware faults and diagnose and repair them whilst the
lights and switches all worked like the real thing and the sounds and
3D models of the peripherals would also be like the real thing. Maybe
I'd leave out the sound of a card deck being mangled and thrown into
the air by the card reader though.
>
> May be some reverse engineering to get 2 or 3 schematics. (need one
> week for
> a board! I have 2 boards in process...)JM Pichot
Good, are you able to identify the function of each type of board
(such as 'And' gate, Flip-Flop etc)
If not I could perhaps compare with my 1301 schematics and see if
they have any similarities. How difficult is it to identify the power
supply connections?
Are you planning on doing schematics for the board interconnections?
I imagine this would be very difficult, so probably best not to try.
>
> 'Ordinosaure' is a beautiful new word composed with
> 'Ordinateur' (computer)
> and Dinosaure.
> We could translate it by 'computosaure'.
I don't think we need the final 'e', alternatively how about
dinoputer or jurassiputer?
> It has about the same definition as in this group: older than 10
> years. (I
> would prefer more than 20 or 30 years, to minimise the use of the
> word...)
> In 56000 messages, you will find a lot without interest!
Well, to be fair, the same thing applies to cctalk. We all have our
own interests and specialities within the broad range of machines and
years of the 'computer age' and we have little interest in other
models and periods.
A few years back Roger Merchberger was kind enough to make available copies
of the Microsoft BASIC "capsule" for the Matsushita/Panasonic/Quasar HHC.
I haven't checked any of his actual MCM68764 EPROMs, but I found an error in
the binary image he provided. The last byte of the EPROM, at offset 0x1fff,
is 0xff, but should be 0xc8, an INY instruction.
The HHC inverts address line A12 to the ROMs, so the two halves of the
EPROM are logically swapped. The EPROM resides in the HHC address map
at 0x4000..0x5fff, so the incorrect byte is at address 0x4fff. If you
look at the source code for Microsoft 6502 BASIC (which few people have),
this byte is the first of three INY instructions generated by a REPEAT
directive shortly after the label STOMLT:
STOMLT: STX CURTOL
LDA COUNT
REPEAT 3,<INY>
STADY LOWTR ;SAVE NUMBER OF DIMENSIONS.
LOPPTA: LDXI 11 ;DEFAULT SIZE.
This is the (corrected) disassembled code:
4ffb 86 f1 stomlt: STX curtol
4ffd a5 44 LDA count
4fff c8 INY
5000 c8 INY
5001 c8 INY
5002 91 ee STA (lowtr),Y
This is part of the array indexing code. The incorrect byte 0xff is an
invalid opcode, so it probably will result in array indexing being
done wrong, and could cause memory corruption.
I found this error only because I was able to compare a disassembly
of the image to the Microsoft source code. It's remotely possible that
there could be other errors in the image. I now have an original
Microsoft BASIC ROM for the HHC, so I'll try to verify the image against
it.
The ROM image ends with some credits (presumably for the HHC port):
001ff0 4e 45 49 4c 20 4b 20 26 20 48 45 4e 52 59 20 4c >NEIL K & HENRY L<
"Neil K" is almost certainly Neil Konzen. Does anyone know who "Henry L"
is?
Eric
I'm seeking to acquire a functional Mac IIfx for a project.
Does anyone have one they'd like to sell? If so, please contact me
directly.
Thanks!
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
>
>Subject: Re: Loading an OS onto a real PDP-11 - not an emulator
> From: Dave McGuire <mcguire at neurotica.com>
> Date: Sun, 23 Mar 2008 13:40:14 -0400
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
I don't write all that...!
>On Mar 23, 2008, at 7:49 AM, Allison wrote:
>>> Following the wonderful advice so for, My shiny PDP 11/04 has now been
>>> upgraded to a 11/34, and I have a temporary terminator pack for my
>>> RL01
>>> disk drive.
>>>
>>> I suspect that I have a system that is capable of booting. - Wo Hoo.
>>> (read - the disks spin, and the fault light stays off.....)
>>>
>>> My final problem (Dont hold me to that though) is that I while I have
>>> a
>>> number of disk packs, I don't believe that I have anything to boot!!
>>> The packs are not really usefully labeled.
>>>
>>> Having trawled the list, I can find many many messages about archiving
>>> data off RL disk packs, and onto archival systems (such as emulators,
>>> etc) - bit I cant find anything about how to take a disk image, and
>>> put
>>> it onto an real RL01 attached to real PDP11 where there is no other
>>> media... I suspect that I have to load in a serial receiver program,
>>> and dump an image - but the details are so far, sparse....
>>>
>>> If somebody could provide some pointers - that would be awesome.....
>>> In
>>> an ideal world, I would be able to get RSTS onto this system (I have
>>> dual RL01's - so that may not work) - Alternately, just being able to
>>> boot RT11 to load a Forth interpreter would also work. [Yes, this is
>>> where I admit to being a Forth person - I hope people will still want
>>> to
>>> talk to me having admitted that]
>>
I did write this.
>> Two ways I know of and they are essentailly the same. Create a pack
>> on a
>> working system or bring up a pack from a working sytems. Other options
>> are a floppy based bring up (RT11 fits on floppy) or maybe loading core
>> via serial line with a bottable image. Last option is emulateted Tu58
>> where the PC acts as a TU58 with RT11 and you use a serial line to boot
>> and run fromt hat to create a RL pack. IN any case I don't think
>> anyone
>> has come up with a way to write a RL from a PC directly. Generally
>> every
>> one has at least one other media (RX01/2 or RX50 OR TK50, TUxx) for
>> portability.
>>
>> It's look at the option where someone creates a pack for you or loans
>> a pack or the emulated TU58 option.
This works!
> Using vtserver is a good option here. Though I'm currently having
>trouble with it with an 11/23 I'm trying to load with RSTS/E, I've had
>good luck with it in the past with RSTS/E and 2.11BSD on an 11/83. I
>think my 11/23's console SLU is somehow flakey and screwing with data
>transfer.
Slow the data rate. Stay under 4800 as you may be getting buffer overflows.
Allison
> -Dave
>
>--
>Dave McGuire
>Port Charlotte, FL
>
>Subject: Re: Loading an OS onto a real PDP-11 - not an emulator
> From: Doc Shipley <doc at mdrconsult.com>
> Date: Wed, 26 Mar 2008 06:59:15 -0500
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>Dave McGuire wrote:
>> On Mar 23, 2008, at 3:38 PM, Allison wrote:
>>>> Using vtserver is a good option here. Though I'm currently having
>>>> trouble with it with an 11/23 I'm trying to load with RSTS/E, I've had
>>>> good luck with it in the past with RSTS/E and 2.11BSD on an 11/83. I
>>>> think my 11/23's console SLU is somehow flakey and screwing with data
>>>> transfer.
I didn't write ^^^^.
I wrote vvvv.
>>> Slow the data rate. Stay under 4800 as you may be getting buffer
>>> overflows.
Someone else wrote vvvv.
>> I'll see about trying that tomorrow. I don't really mind if it takes
>> days to copy (I'm moving a 300+MB image) as long as it's error-free.
>
> That won't fly. VTserver v2.x has a 32MB file-size limit. :(
Use Vtserver to install an OS and use that to do the heavy lifting...
HOWEVER: RT11 has a 32mb limit (per file device) as well so use an
OS that can handle that size files. Maybe UnixV6 is a possible choice.
Allison
>
> Doc
A long time ago, I had a couple of GatorBoxes, and I remember that you
could run the code memory test to wipe all the settings -- and hence
recover from a locked box or lost password.
What I can't remember is the procedure to then re-install the Gatorshare
software. I seem to recall it needs a Mac. Can anyone remind me?
Someone I know has ended up with this problem.
--
Pete Peter Turnbull
Network Manager
University of York
> Date: Mon, 24 Mar 2008 20:23:52 +0000
> From: Julian
> I found it on www.datasheets.org.uk - it's listed as an equivalent to a
> 6264 static ram, which sounds plausible...
Not if it already contains a copy of a BIOS. If you take a closer
look, you'll see that the referencing page is merely a search list,
not a pointer to equivalents.
Had me fooled too.
Cheers,
Chuck