test-drb December 2005

test-drb@ccmp.vtda.org

235 participants
580 discussions

by ken＠seefried.com

From: "Robert Armstrong" <bob at jfcl.com> > Yes, you could solve the problem with VPNs. It's late and I'm tired, but isn't moving things like DECnet around what something like GRE tunnels can solve? Build logical networks over the Internet and have your DECnet world. Lot's of things can do GRE these days (Linux, for example). > Probably there > just aren't many hackers out there who know enough about DECnet to worry > about, and they have better targets for their efforts. True (as I deal with this for a living). The things that hackers are interested in using hacked machines for has changed. It's not about defacement any more, and if it's not high bandwidth and/or large storage, it's not worth the time. Not that you shouldn't be careful, though...:-) Ken

20 years

Z-Star 433VL

by tolik_trek＠mail.ru

Hello! I am from Russia. I have Z - Star 433 VL too... Without adapter. Have you found something about this adapter? I want to make it from another adapter, but i don`t know anything about it power plug. Do you know something about? Thanks, good bye!

20 years

"Market" for old macs?

by trag＠io.com

>Date: Wed, 30 Nov 2005 18:19:05 -0500 >From: Scott Stevens <chenmel at earthlink.net> >On Tue, 29 Nov 2005 23:59:42 -0500 >"James Fogg" <James at jdfogg.com> wrote: > >> > James Fogg wrote: >> > > My interests stop at the "classic" Macs, of which the SE30 is the >> > > height of engineering achievement (in my opinion). >> > >> > Why? I know a bit of the classic Mac engineering history >> > thanks to Andy's retro website/book, but I know nothing of the SE30. >> >> OK, neither do I (it's too late to argue). It is the last of the classic >> Macs and has the greatest number of features and capabilities. >> > >Actually it isn't the last of the Classic Macs in a certain sense. Apple > produced several other inferior compact Mac machines that aren't nearly > as expandable as the SE/30. The Macintosh Classic is an example of this, if > I'm not mistaken. The Classic can't sport anywhere near as much RAM as > the SE/30. The SE/30 is essentially the IIcx with the NuBus slots sawn off and a little (very little) video RAM and video circuitry added. It was a nice machine. 16 MHz 68030 with fully 32 bit wide data and address paths. Maximum RAM is 128 MB with eight 16MB 30 pin SIMMs. Color capability is in the ROM, but requires one of the somewhat rare video cards (SE/30 PDS slot) and goes to an external monitor. The follow up models which had similar form factors were far inferior. The Mac Classic really ought to be compared to the Mac Plus or Mac SE (somewhat superior to the former and inferior to the latter). The only thing the Classic had going for it is that Mac OS 6.03 is in the ROM, so you can boot with no available disk. It *should* have had the Mac Portable memory map, so that it could address 8 MB of RAM instead of only 4MB (24 bit address space) and a speed bump from 8 to 16 MHz, but Apple didn't do that. The Classic II was meant to be a follow up to the SE/30 but while it has a 16MHz 68030 its maximum RAM is 10 MB and its data path is only 16 bits wide. Bleah. The Color Classic has the same problem, though it does have a color screen. The Color Classic II was better with 33MHz 68030 and 32 bit data path. The Max RAM was still limited to only 36MB. However, that's a 72 pin SIMM socket with 4MB on the motherboard and Apple never acknowledged that any of their 72 pin RAM machines would address better than 32 MB per slot. Nevertheless many of their machines will work with 64MB or even 128 MB 72 pin SIMMs, so the CCII may have a much higher max RAM than reported by Apple. If that's the case, then the CCII was a worthy successor to the SE/30. Jeff Walther

20 years

A Hobbyist DECnet Network

by ajp166＠bellatlantic.net

> >Subject: RE: A Hobbyist DECnet Network > From: "Robert Armstrong" <bob at jfcl.com> > Date: Thu, 08 Dec 2005 16:27:16 -0800 > To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at classiccmp.org> > > >> Yeah, as soon as I get my TK50 or one of my 9 tracks working >> I'm going to load DECnet/E, and then hopefully put my >> 11/23plus up on HECnet. > > How were you going to connect physically with HECnet? Set up some other >box as a gateway? > >Bob He can use a DEQNA/DELQA or similar for the Ubus. The laternate is a SYNC card (DPV-11 or whatever) to VAX or other DDCMP host. The real problem is he'll be running DECnet Phase-III however a small uVAX can do routing for that. Allison

20 years

Legacy apps in Windows/OS X was Re: Old MS-DOS & Win Software

by ajp166＠bellatlantic.net

> >Subject: Re: Legacy apps in Windows/OS X was Re: Old MS-DOS & Win Software > From: "Dwight K. Elvey" <dwight.elvey at amd.com> > Date: Thu, 08 Dec 2005 16:17:10 -0800 (PST) > To: cctalk at classiccmp.org > >Hi > I still don't fully understand the decimal fuctions >of the 4004. It has similar problems with addition and >subtraction. It, of course, doesn't have to deal with >a half carry, being only 4 bits. >Dwight The 4004 is as they say a "whole nother animal". The decimal arithmetic is actually familiar theme amoung the 4bit(datapath) class of machines TMS1000, NEC uCOM4 and uCOM75, and others dealing with decimal quantities is both easier (no conversions) and allows the data areas in memory to be organized or thought of as long registers of decimal digits. Of course the Carry has to reflect numeric overflows greater than 9d instead of Fh. Allison

20 years

Cap reformation question

by dwight.elvey＠amd.com

Hi There is a government spec on reforming capacitors that have been in storage for military specs. I don't recall if I saw this on this list or maybe one of the news groups. Dwight

20 years

Legacy apps in Windows/OS X was Re: Old MS-DOS & Win Software

by ajp166＠bellatlantic.net

> >Subject: Re: Legacy apps in Windows/OS X was Re: Old MS-DOS & Win Software > From: Jim Leonard <trixter at oldskool.org> > Date: Thu, 08 Dec 2005 16:26:18 -0600 > To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> > >Allison wrote: >> You lived a shelterd life. > >I lived a young life. I first became of programming age in late 1970s so my >first CPUs were 6502, Z80, 68000, and 808x. > >I'm in my 30s, it's not like I was born in 1985 or anything :) >-- Ah but, what I said didn't reflect on age only experience. ;) Then again kid... ;) Allison

20 years

Legacy apps in Windows/OS X was Re: Old MS-DOS & Win Software

by pete＠dunnington.plus.com

On Dec 8 2005, 16:26, Jim Leonard wrote: > Allison wrote: > > You lived a shelterd life. > > I lived a young life. I first became of programming age in late 1970s so my > first CPUs were 6502, Z80, 68000, and 808x. Whether it's called a Half Carry or an Auxiliary Carry seems to depend somewhat on whose data book you read. I've seen both used for the Z80 for example, indifferent manuals. ...in a 6800, it's called the Auxiliary Carry; in a 6809 it's called a Half Carry. It's bit 5 of the status register in both. ...in a Z80 and 8086 it's called the Auxiliary Carry; it's bit 4 in the Flags register in these and 8080/8085. ...it's bit 5 in 8048 and 8051 series micrcontrollers. There's no (visible) equivalent in a 6502 because of the way its special Decimal Mode for BCD arithmetic works. Ditto for a 68000. There isn't one in an ARM either. -- Pete Peter Turnbull Network Manager University of York

20 years

Timing of PDP-11 Instructions

by jhfinexgs2＠compsys.to

Hi All, I am not sure if there is still sufficient interest, however, I have encountered a rather bizarre timing situation when a specific subroutine is executed on my PDP-11/73. Background: I want to calculate the reciprocal (inverse) of a number between 1 and 65535 to an accuracy of 256 bits after the binary (or decimal) point. This result will then be used to calculate the logarithm of that value which in turn will be used to calculate li(x) for values of x up to 10**38. The code is in FORTRAN 77 (could also be in FORTRAN IV) which calls MACRO-11 code to do the really low level stuff such as repeated addition of many words with MANY Adc instructions following each addition (99.9% of the time the Adc instructions are never used). Preliminary Details: The subroutine first converts the INTEGER * 4 to a REAL * 8 to produce: R8ARG = I2ARG R8RCP = 1.0D0 / R8ARG as the initial 56 bit accurate estimate. The subroutine then continues: I must then convert R8RCP to a: REAL * 64 = INTEGER * 32 / FRACTION * 32 which is actually quite simple since the R8RCP value already contains the value EXP ** 2 which is the number of bits to be shifted right after the R8RCP fraction of 56 bits is unpacked. Next the unpacked 56 bits are moved by a whole number of words for each multiple of 16 bits to be right shifted. Completion is done by shifting right a group of 5 words when the last portion of the total shift is less than 16 bits of shifting. Unpacking uses the instructions: Mov (R0)+,-(R1) Word shifts use the following pair of instructions four times: Mov (R0),-(R1) Clr (R0)+ The final shifting (if needed) uses five instructions of: Ror -(R0) as many times as are required (1 to 15 times) The problem is as follows: When the destination argument address is in PAR0 (address is less than 17600), there is no problem. When I use an argument address in PAR1 (address is above 21000), there is a substantial speed reduction in the subroutine. It takes an average of 1611 microseconds for each of the 65535 cases when the destination address is in PAR0 (specifically 15236) while it takes an average of 6055 microseconds for each if the 65535 cases when the destination address is in PAR1 (specifically 21000) or about 3.75 times as long. What is EXTREMELY interesting is that the above timing is also repeated under E11, although everything is over TWENTY times as fast. Under E11, it takes 65 microseconds using PAR0 and 230 microseconds using PAR1 with the same identical program. I run using RT-11 with RT11XM for all testing, although I did check with RT11FB under E11 with almost the same timing results. I could also check with RT11FB on the real DEC PDP-11/73 if anyone thinks it might be worthwhile. ----------------------------------------------------------------- HOT FROM THE COMPUTER - A BIT MORE DETAIL! At first I was most suspicious of the Mov / Clr pairs since they are the code that is extra. HOWEVER, if I eliminate the last loop with the five Ror instructions, then (although the answer is incorrect - up to 2 ** 15 too large without the final shifts) the timing is the same for both PAR0 and PAR1 arguments. But this result contradicts the earlier version of the code which uses ONLY Ror instructions (a total of 16 Ror instructions are needed to span the 32 bytes in question) to accomplish all the shifting. Because the timing for the earlier version of the code (which is still present, just not used when the branch is taken to the "faster??" version) can now be compared by changing the branch instruction to use the less efficient code, I am still able to compare the timing for both versions - and the timing for the original less efficient version (which still includes the four unpack instructions and many more Ror instructions) is still the same as before for both PAR0 and PAR1 destinations arguments and equal to each other. SO I AM STUMPED!! Even when I turn the five Ror instructions loop into five Nop instructions (as opposed to not doing the loop even when there are more shifts needed - the code checks the remaining shift count, so pretending the remaining shift count is always zero to stop using the last five Ror instruction loop was easy), the timing test with a PAR1 destination argument takes longer even though NOTHING is being done! In fact using a PAR1 destination argument with a five Nop instructions loop still takes more than half of the extra timing (i.e. much more time than for the PAR0 destination argument which still uses the five Ror instructions loop). ---------------------------------------------------------------------- HOTTER FROM THE COMPUTER - STILL MORE DETAILS! To my surprise, there is considerable variation even when different PAR0 destination addresses are used. Since the portion of the code up to the final right shifting within 5 words is all that can be different, I am even more mystified. However, after running 3 different code versions at 3 different addresses (2 in PAR0 and 1 in PAR1) on both a real DEC PDP-11/73 and under E11 on a Pentium III 750 (at over 20 times the speed of the PDP-11/73), the results are consistent. When I gradually increase the PAR0 destination argument address right up to the end of PAR0, the timing gradually decreases. When the address is in PAR1 (all or none - the field is 64 bytes long, so the last example in PAR0 is 17600), the average time suddenly jumps, but only for the "more efficient" code version. Since the results of all calculations are correct (verified against a version which uses the less efficient code), I am now totally mystified. I have never seen this occur before in all of the 45 years I have been using computers. Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.

20 years

A Hobbyist DECnet Network

by ajp166＠bellatlantic.net

> >Subject: Re: A Hobbyist DECnet Network > From: Dennis Boone <drb at msu.edu> > Date: Thu, 08 Dec 2005 19:03:52 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > > > I'm interested in setting up a network of hobbyist DEC machines linked > > together in a DECnet phase IV network. Why? I suppose there's no > > really good reason, but it seems like it would be fun to be able to > > do "SHOW NET" or "NCP SHOW ACTIVE NODES" and see a whole long list > > of machines that aren't mine :-) Besides, it would be a good way to > > share access to real, non-simulated, VMS/RSX/RSTS and even, maybe, > > TOPS-10 or 20, machines. > >That actually sounds interesting. Among other things, it would >give folks like me who are newish to decnet a way to test against >known-working systems. > >How would you protect these older systems against abuse from the random >crackers? VMS is probably tolerably safe in current versions, if >properly managed, but I'm betting there are problems with other OSes. >You could do vpns, I suppose. VMS if not put up sloppy is fairly tight. The was a minor bug in 5.x that was fixed by 5.4. It's put 5.4 or later up against anything current. Allison

20 years

← Newer
1
...
41
42
43
44
45
46
47
...
58
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb December 2005