I thought I'd throw this one out to those who know more than I about the
PDP 11/40
I am working with DaveR on vcfed.org/forum who asked me to run the
following program as a test from the front panel:
20 - 220 ; IOT trap vector (New PC)
22 - 340 ; IOT trap vector (New PSW)
200 - 012706 ; MOV #600,SP
202 - 600
204 - 240 ; NOP
206 - 0 ; HALT
210 - 4 ; IOT
212 - 240 ; NOP
214 - 0 ; HALT
216 - 0 ; HALT
220 - 0 ; HALT
222 - 0 ; HALT
START the program running from address 200.
----------------------
Problem is - The IOT step is bombing (?) and loops through the addresses:
204
206
210
200
204
206
210
200
endlessly.
Anyone care to speculate which CPU card is the culprit?
--
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg <https://twitter.com/billdeg>
Youtube: @billdeg <https://www.youtube.com/user/billdeg>
Unauthorized Bio <http://www.vintagecomputer.net/readme.cfm>
On Jun 30, 2016 1:19 AM, "Fritz Mueller" <fritzm at fritzm.org> wrote:
>
> Hey Bill,
>
> Do you have a KM11 maintenance card? Guy Sotomayor here sells kits
and/or assembled boards at
http://www.shiresoft.com/products/km11/KM11%20Replica.html. I built one up
myself based on a layout by Tom Uban at
http://www.ubanproductions.com/museum.html
>
> The easiest way to get to the bottom of this since you have a nice,
short, repro case would be to step through the microcode with a KM11 and
see where it goes awry. From that point, its fairly easy to come of up a
list of boards to swap and/or chips to check.
>
> If you want to go to the chip checking stage, you'll need some board
extenders and a logic probe, they are pretty cheap. Or you can grab a
surplus logic analyzer and some DIP clips off eBay if you want to get posh!
>
> I just went through this process with my 11/45, it was pretty educational.
>
> --FritzM.
Fritz,
It turns out that I was missing the KJ11 my cpu cards were wired to
expect. On the 11/40 this module is the little M7237 card for space E of
slot 3.
The machine in question did not come with this card, I assumed it was not
needed until I checked the cpu jumpers and discovered my error. Should
have done this 1st!
It was impossible to run the CQKC diagnostic for 11/40 or 11/45 -
http://www.vintagecomputer.net/temp/disassembly.txt
Instructions using IOT in particular.
Bill Degnan
twitter: billdeg
vintagecomputer.net
Looking for a Tandy TRS-80 Model 2000 compute monitor. Wikipedia description here:
https://en.wikipedia.org/wiki/Tandy_2000 <https://en.wikipedia.org/wiki/Tandy_2000>
The monochrome is model VM-1 Monitor, the colour is CM-1 Monitor.
Many thanks
Brendan
--------------//----------------
brendan at mcneill.co.nz
+64 21 881 883
And here is Ken's new post in the series
http://www.righto.com/2016/06/restoring-y-combinators-xerox-alto-day.html
Marc
> On Jun 21, 2016, at 10:59 PM, CuriousMarc <curiousmarc3 at gmail.com> wrote:
>
> The restoration is physically happening at my place. As noted below we have
> a small and quite knowledgeable group of people contributing, including
> actual hardware when we are missing a part (thanks Al !). A few of us are
> chronicling this on our favorite media from our favorite angle.
> I like to make short videos trying to convey the inside story of the
> restoration, on my YouTube channel:
> https://www.youtube.com/curiousmarc
> It's interspersed with all the other restorations, but two videos so far:
> https://youtu.be/YupOC_6bfMI
> https://youtu.be/xPyqQXFC2yw
> Ed Thelen likes to collect every bit of raw information floating around,
> including some of the team emails and throw them into equally raw site, as
> he does for the IBM 1401 restoration effort at CHM:
> http://ed-thelen.org/RestoreAlto/index.html
> Carl Claunch methodically recounts everything he does every day (and he does
> a lot), so when he works on the Alto, you'll know every detail:
> http://rescue1130.blogspot.com/
> Ken Shirriff makes deeply researched, superlative detailed posts on his
> blog. These are reference pieces, I admire them a lot:
> http://www.righto.com/2016/06/y-combinators-xerox-alto-restoring.html
> And it gets discussed on the Y-combinator (the owners of the machine) and
> hopefully here too.
> Seeing the interest, I will make an effort to post new links when they
> become available, unless of course Master Al beats me to it.
>
> Marc
>
> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Al Kossow
> Sent: Monday, June 20, 2016 8:54 AM
> To: cctalk at classiccmp.org
> Subject: Re: Y Combinator is restoring one of Alan Kay's Xerox Alto machines
>
> http://www.righto.com/2016/06/y-combinators-xerox-alto-restoring.html
> https://news.ycombinator.com/item?id=11929396
> http://ed-thelen.org/RestoreAlto/index.html
>
>> On 6/20/16 8:51 AM, Al Kossow wrote:
>> I post just went up on Saturday. It's nice that both CHM and LCM folks
>> are helping with this.
>>
>>
>>> On 6/20/16 8:41 AM, Liam Proven wrote:
>>> http://www.righto.com/2016/06/y-combinators-xerox-alto-restoring.html
>>>
>>> Found via:
>>>
>>> http://www.osnews.com/story/29261/Xerox_Alto_restoring_the_legendary_
>>> 1970s_GUI_computer
>>>
>>> There are 2 videos up so far, with disassemblies that may interest
>>> CCmpers.
>>>
>>> Some people from the list are involved, including Al Kossow, but I
>>> haven't seen the link posted.
>>>
>>
>
Hi
I collect vintage IBM laptops, have just joined the community, and wonder if anyone can help with the following:
1. Can write a Teledisk image of concurrent CP/M for Displaywriter to two 8 inch floppy disks which I can supply?
2. Can solder a cable fie me which will interface an ibm 6360 8 inch floppy to a PC. I am unable to do this myself.
3. I have an external 5.25 floppy adapter/a inside an ibm ps/2 p70 and wonder if the external 37 pin connector is pin compatible with the 37 pin connector of the ibm 6360 8 inch floppy drive?
I thought about connecting two out of the 3 cables from this drive to an IBM displaywriter (supplying the correct voltages etc) and the 37 pin connector to my external 5.25 adapter/a card?
Thanks for your help.
David
It's that time of year when a young man starts to take stock of
reality (for better or for worse) and decides that his load must be
lightened. This time the machine with on the block is an MAI Basic
Four deskside minicomputer. I'm not sure of the exact model but it
can be seen in the first three pictures in this gallery:
https://picasaweb.google.com/102190732096693814506/HaulOf10315?noredirect=1
Note: nothing else in that gallery is on offer at this time - maybe
later. However other random hardware may be thrown at you during the
transfer.
I have not powered it up. I was told it was working when taken out of
service many years ago, but we all know how that goes.
I have some documentation for it that I will be scanning (some of
which is not already on Bitsavers) but I will send it along to whoever
takes the machine afterwards. I do not have any disk or tape media
for it.
I'm not looking to get a lot for it - trades would be fine, preferably
for something that I can lift myself, however I am also looking for a
working DEC RX02 drive or a later IBM terminal controller (3174 or
similar) with Ethernet that I can use to run IBM real terminals on
Hercules.
Preference goes to:
1) someone local who can haul it away. I am not presently equipped
to deal with shipping anything this large.
2) someone will will get it sooner rather than later
3) someone who will make it sing again.
If you're coming to VCFMW in September, the storage unit holding the
MAI is just a few miles away from the hotel and we can do the loud-out
then. If you're here sooner, even better.
-j
Some people might have noticed that Mim.Update.UU.SE have not been
reachable the last week. This is because the University have decided to
put all systems behind firewalls, which hurt the Update computer club
pretty bad.
For people who would still like to get access to Mim, I have now setup
telnet to listen to a second port in addition to port 23. Mim is now
accessible by telnet on port 10023 as well, which is not blocked by an
firewall.
In addition, I also added ftp on port 10021 in addition to port 21, so
people who would like to get to files on Mim by ftp can do so again.
This also prompted me to make a couple of improvements to BQTCP/IP for
RSX. The changes are that the telnet daemon can now be set to listen to
an alternative port, and can also listen to several ports.
I also added the capability to the ftp client to specify which port to
connect to.
The TCP/IP package can be found at ftp://mim.update.uu.se:10021/
However, if you have the previous version of TCP/IP for RSX, you cannot
access this address, as the previous version ftp client did not accept a
port argument. So it's a bit of a chicken and egg thing. But using some
intermediate system, you can get the disk image to the machine, and
install the new version, after which things will be possible to use more
or less as before.
One more thing: NEMA, my very tiny EMACS clone for RSX, have gotten a
lot of work done lately, and if anyone is interested in this tool, I
really recommend that you fetch the latest version. A port to VMS is
also included with the files now, courtesy of Erik Olufsen.
NEMA is available at ftp://nema at mim.update.uu.se:10021/
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Just in case anyone is interested, I have just posted a video on YouTube of
my Rainbow 100+ (not the one I am selling) running in a dual head
configuration. The quality of the video isn't great, but it might interest a
few people.
You can find it here: https://youtu.be/y4p9plwjRio
Regards
Rob
> From: Fritz Mueller
> So far I haven't seen any place in PDP11GUI to set anything other than
> port and baud rate
You might have to use native OS tools to do that. On Unix, that will be
'stty'; on Windows, you'd have to use native Windows tools to do that; if you
go to the Device Manager, select your serial port, and click on 'Properties',
it has a tab ('Port Settings') for that (or, should I say, it used to - not
sure about the most recent versions, they're making it all smart-phone like
for brain-dead lusers).
> From: Don North
> Mostly PDP11GUI does not care, either 7b or 8b.
I'm kind of surprised to hear that; I assumed that PDP11GUI can download
binaries, and for that, 8-bit is kind of necessary?
Side-story: when I started bringing up my -11's, the first one I did was an
-11/23. So I needed a way for my Windoze box to talk to the -11's console
line, for ODT. I was too lazy to figure out how to use some existing
software, so I decided to write some. I wanted to be able to use it (later)
to talk to one -11 from another, and I didn't know how to do complex terminal
hacking under Windoze anyway, so I decided to write it under Unix. V6, to be
exact (I consider all later versions to be unholy perversions - well, V7
isn't too bad, I guess), running on Ersatz11 on the Windoze box.
Later, I wanted to be able to load .LDA files, which are 8-bit binary. One
problem. Native Unix V6 doesn't have the ability to output 8-bit binary over
a serial line (or input it, for that matter). When I first started using V6
at MIT, the DSSR people had already totally re-written the TTY driver, and
added that capability, so I never ran into this problem before. Also, the
native V6 stty() call isn't very flexible, and there are no spare mode bits.
So they'd added a new system call, ttymod() (sort of like ioctl(), but done
before it), to control all their wonderful extensions.
I decided not to replicate that, but rolled my own upwardly compatible
extension to stty(), which adds all that extended semantics. From there, it
wasn't too much work to get sending the absolute loader down the serial line
in its original binary form (which means all the old console bootstraps work,
too), and using that to load .LDA files.
Noel
(My original message to cctech has yet to appear. I thought I might try the
cctalk list).
While Motorola never shipped the MC6839 [1] the binary is available [2]
and I've been playing around with it [3]. While it's not producing the
exact same results as I get on a more modern machine, it appears to be
"close enough" for me to be happy with it. But I am having one issue that I
can't figure out.
The documentation for the FMOV operation says:
FMOV Move (or convert) arg1 -> arg2. This function is useful for
changing precisions (e.g. single to double) with full
exception processing for possible overflow and underflow.
Okay. And to call it [4]:
------------------------------------------------------------------------------
|Function|Opcode| Register entry conditions | Stack entry conditions
------------------------------------------------------------------------------
| FMOV | $1A | U = precision parameter word| push arg
| | | Y -> argument | push precision param word
| | | D -> fpcb | push ptr to fpcb
| | | X -> result | call FPO9
| | | | pull result
------------------------------------------------------------------------------
For moves, U contains a parameter word describing the size of the
source and destination arguments. The bits are as follows, where
the size is as defined in the fpcb control byte
Bits 0-2 : Destination size
Bits 3-7 : unused
Bits 8-10 : Source size
Bits 11-15: unused
And the size bits are defined as:
111 = reserved
110 = reserved
101 = reserved
100 = extended - round result to double
011 = extended - round result to single
010 = extended - no forced rounding
001 = double
000 = single
It appears that to convert from single to double, I would set U to $0001,
but the results are *so* far out of whack it's not even funny. I've tried
setting U to point to the value $0001 and that doesn't work. I've tried
shifting the bits (because in the FPCB they're the upper three bits) and
that doesn't work. I've tried reversing the registers and that doesn't
work. Does anyone have the actual source code [4]? Or know what I might be
doing wrong?
-spc
[1] A ROM with position independent 6809 object code that conforms (to
what I can find) with IEEE 754 Draft 8.
[2] Available in the file fpo9.lzh here
https://ftplike.com/browser/os9archive.rtsi.com/OS9/OS9_6X09/PROG/
[3] Using a 6809 emulator library I wrote: https://github.com/spc476/mc6809
Not much documentation I'm afraid.
[4] Register entry: ROM base address + $003D
Stack entry: ROM base address + $003F
[5] I'm lead to believe that Motorola release the code into the public
domain.