> -Original Message-
> From: cctalk On Behalf Of Al Kossow via
> cctalk
> Sent: 02 January 2019 19:47
> To: cctalk@classiccmp.org
> Subject: Re: wanted back issues IEEE ANNALS OF THE HISTORY OF
> COMPUTING bound or unbound... dtop us a line off list please.
>
>
>
> On 1/1/19 8:53 AM,
> On Jan 2, 2019, at 4:40 PM, Paul Koning wrote:
>
> I'm pretty sure it was there for a long time. It's under memory layout
> suboptions. When it says "any memory layout changes" say yes, then when it
> asks what, say ODT.
Oh, I see, it's not listed as a valid sub option, but it is accepte
I believe that is the one. Intel tried to say it wasn't an issue until it was
shown that the error was significant when using floating point numbers near
integer values. I suspect that the fellow that forgot to include the mask file
for that ROM got a bad review.
Dwight
> On Jan 2, 2019, at 6:19 PM, Fritz Mueller via cctalk
> wrote:
>
>
>> On Jan 1, 2019, at 5:10 PM, Paul Koning via cctalk
>> wrote:
>>
>> You could load monitor ODT (ODT option in the memory layout settings in
>> DEFAULT) and set a breakpoint at LOG$DK, that's the error logging entry
>>
On Wed, Jan 2, 2019 at 4:12 PM dwight via cctalk
wrote:
> I thought I'd note that the divide problem couldn't have been patched
> with a micro code patch.
If you're talking about the Pentium FDIV bug, present on the early 80501
chips (60 and 66 MHz) and 80502 chips (75, 90, and 100 MHz), they
On 1/2/19 2:26 PM, Mattis Lind via cctalk wrote:
> Does anyone have a clue on how to get a proper link with FPMP-11 for these
> two symbols?
the source paper tapes for fpmp are at
http://bitsavers.org/bits/DEC/pdp11/papertapeimages/20040101/tray07
TRAY07
dec-11-nfpma-a-pr1 8/72; fpmp-11 sing
> On Jan 1, 2019, at 5:10 PM, Paul Koning via cctalk
> wrote:
>
> You could load monitor ODT (ODT option in the memory layout settings in
> DEFAULT) and set a breakpoint at LOG$DK, that's the error logging entry point
> of the driver. Then you could display the RK11 CSRs and we can see if w
I thought I'd note that the divide problem couldn't have been patched with a
micro code patch. It was because one of the ROM arrays used as part of the
divide lookup was missing its data. It would have been much more than a simple
patch to fix. It would have had to go back to a full subroutine
So after some intensive transcribing work I finally got all files into
source files ready for assembling using PAL11-S.
Assembling under PAL11-S rooted out a bunch of errors and then when side by
side comparing the output listing with the PDF I found a bunch of more
errors.
The next step involved
I will certainly follow that one, my twitter is @billdeg btw.
On Wed, Jan 2, 2019 at 3:43 PM Al Kossow via cctalk
wrote:
>
>
> On 1/1/19 8:53 AM, Bill Degnan via cctalk wrote:
> > On the bitsavers website it might be nice to add a
> > section where people can see what docs are available for pick
On Wed, Jan 02, 2019 at 02:37:44PM -0500, Paul Koning via cctalk wrote:
>
>
> > On Jan 2, 2019, at 2:31 PM, Chuck Guzis via cctalk
> > wrote:
> >
> > On 1/2/19 10:44 AM, Guy Sotomayor Jr wrote:
> >
> >> Also, recall that there are different forms of micro-code: horizontal
> >> and vertical.
On 1/1/19 8:53 AM, Bill Degnan via cctalk wrote:
> On the bitsavers website it might be nice to add a
> section where people can see what docs are available for pick up/rescue
> opportunities.
>
I've added a section on the purpose and methodology of bitsavers on the bottom
of
the main bitsave
> On Jan 2, 2019, at 2:31 PM, Chuck Guzis via cctalk
> wrote:
>
> On 1/2/19 10:44 AM, Guy Sotomayor Jr wrote:
>
>> Also, recall that there are different forms of micro-code: horizontal
>> and vertical. I think that IBM (in the S/360, S/370, S/390, z/Series)
>> uses the term micro-code for h
On 1/2/19 10:44 AM, Guy Sotomayor Jr wrote:
> Also, recall that there are different forms of micro-code: horizontal
> and vertical. I think that IBM (in the S/360, S/370, S/390, z/Series)
> uses the term micro-code for horizontal micro-code and millicode
> for vertical microcode.
On the CDC STAR
> On Jan 2, 2019, at 10:22 AM, Chuck Guzis via cctalk
> wrote:
>
> On 1/2/19 8:02 AM, Jon Elson via cctalk wrote:
>
>> Random logic instruction decode was a REAL issue in about 1960 - 1965,
>> when computers were built with discrete transistors. The IBM 7092, for
>> instance, had 55,000 tra
On 1/2/19 8:02 AM, Jon Elson via cctalk wrote:
> Random logic instruction decode was a REAL issue in about 1960 - 1965,
> when computers were built with discrete transistors. The IBM 7092, for
> instance, had 55,000 transistors on 11,000 circuit boards. I don't know
> how much of that was instru
A friend and I went in on an Amiga 4000T haul last weekend, and with it
were some nice hard binder and box Microware OS-9 68x00 books. I want to
say there are two sets of two, and then some binders with photocopied
style paperwork for BASIC.
Is there any Microware fans that might want these
On 01/02/2019 02:31 AM, Paul Birkel via cctalk wrote:
I'm curious as to why you make this claim that microcode is no-go in "modern"
designs. Could you please elaborate on this point? I don't see why the alternative
random control logic would be a better proposition.
Random logic instructi
On 2019-01-02 7:22 AM, Steve Malikoff via cctalk wrote:
> I timed myself how long it would take to clean up Mattis' supplied image so
> it might
> be able to be OCR'd more accurately. Using Paint.NET it took me 23 minutes to
> get to
> the following:
> http://web.aanet.com.au/~malikoff/pdp11/dvY9
Finally got around to imaging the +/- 80 floppies that came with my ACI-90
Pascal Microengine system.
Disks of general interest can be downloaded on
ftp://ftp.dreesen.ch/WD9000/MicroEngine.zip
These are mostly variants of the OS and a set of system selftests.
Image SYSTEM/OS_F0_SingleDensi
> On Jan 1, 2019, at 10:17 PM, Jim Manley via cctalk
> wrote:
>
> RISC was never just about compiler and hardware simplification for improved
> performance of the most frequently-executed instructions. It's also been
> front-and-center in low-power (e.g., mobile) and embedded (now including
I timed myself how long it would take to clean up Mattis' supplied image so it
might
be able to be OCR'd more accurately. Using Paint.NET it took me 23 minutes to
get to
the following:
http://web.aanet.com.au/~malikoff/pdp11/dvY973s_cleaned.png
There are still a few little bits I missed, but hap
The only way I've been able to get any type of readable ASCII TEXT
from the .tif's is to do the following for each tif:
convert -density 1200 -resize 40% xaaa.tif -density 1 xaaa120040.tif
Then, OCR it with Irfanview with the KADMOS Plugin Installed.
For the first Page I get the following ASCII:
>-Original Message-
>From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Carlo Pisani
>via cctalk
>Sent: Tuesday, January 01, 2019 5:35 PM
>To: ben; General Discussion: On-Topic and Off-Topic Posts
>Subject: Re: Motorola M88K books & user manuals (looking for)
>
>> I was never
24 matches
Mail list logo
