test-drb January 2008

test-drb@ccmp.vtda.org

221 participants
430 discussions

Automatic virus scan of uploaded files on BBS?

by jrzagar＠gmail.com

Looks like this feature of WWIV will be important in a patent lawsuit by Trend Micro. Trend Micro claims to have a valid 1995 patent for doing virus scanning on email servers, and many of their claims appear to be well-known capabilities that WWIV had well before 1995 For mor information on this please look at this article: http://www.groklaw.net/article.php?story=20080125135544713 -RZ

16 years, 3 months

2.11BSD Patch 445; FPSIM fixed; 211bsd runs on systems without FPP

by W.F.J.Mueller＠gsi.de

A note to all 2.11bsd users: Some time ago I looked into running 2.11bsd on systems without floating point unit. The release notes state that this is untested and unsupported, and indeed it didn't work. Robin Birch some time ago fixed part of the issues, see patch 434, but still the kernel paniced when the very first program was started. I managed to localize and fix the problem in sys/pdp/mch_fpsim.s. Steven Schultz right away issued 2.11BSD patch #445. All patches up to and including 445 are provided by Steven under ftp://sg-1.ims.ideas.gd-ais.com/pub/2.11BSD A patch level 445 system will now boot on simh for example on a set cpu 11/70 nofpp 4m configuration and work just fine, albeit a little slower. It should thus also work on a real 11/70 without FPP. I heard of some 11/70 with non-working FPP's, so this maybe good news for the owners. With best regards, Walter Mueller -- Dr. Walter F.J. M?ller Mail: W.F.J.Mueller at gsi.de GSI, Abteilung KP3 Phone: +49-6159-71-2766 D-64291 Darmstadt FAX: +49-6159-71-3762 URL: http://www-linux.gsi.de/~mueller/

16 years, 3 months

Chip ID and datasheet?..

by bpope＠wordstock.com

All, I am trying to ID a chip from a SFD-1001 motor control board. This is printed on the chip: JAPAN SERVO SA1001 3A It looks like a normal DIP, except for the middle pins which look to be twice as wide. Is this for heat sinking? I have tried searching for this chip but so far have found nothing. The board has this marking; PC-368C JAPAN SERVO TDK-T15V Which also has not turned up anything useful.. The 5 1/4" drive mech this board is connected to was made by Matsushita and its model # is JU-570-2. From reading the SFD-1001 technical manual, the 5 1/4" mech is just listed as a part so it does not have any detailed information for this board. :( Cheers, Bryan

16 years, 3 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Chuck Guzis" <cclist at sydex.com> > Date: Wed, 30 Jan 2008 10:57:15 -0800 > To: cctalk at classiccmp.org > >> From: "Joshua Alexander Dersch": > >> Were there similar problems in the CP/M world? That is, was it >> commonplace for there to be CP/M programs that bypassed CP/M BDOS calls >> and wrote directly to a specific machine's hardware? Seems like CP/M >> developers were more disciplined in this fashion, but maybe it's just >> because in the CP/M arena there were so many different pieces of hardware >> it was the only way to do it? (Whereas with IBM, the PC was seen as more >> of a reference standard, even if it wasn't really that way in the >> beginning?) > >The great thing about CP/M (and I'm talking about the 8-bit version >here) was that it imposed a file system and made disk I/O uniform-- >128 byte sectors, regardless of how the information was actually >formatted onto a drive. CP/M was really primitive when it came to >console I/O, giving only about 3 functions for output and input each. >No cursor positioning or screen control; basic TTY style I/O. And, >while there was an IOBYTE facility to redirect I/O, implementation >was very nonuniform between vendors. Things like Termcap and the lise were not needed. However the console IO was not so good. Try printing a string containing $ using the print string call. The other was passing 8bit data when needed. IObyte was mostly uniform, the problem was often it wasnt even implemented. This was a problem of allowing the BIOS spec to be minimal and it usually was. >As a result, for other than simple command-line utility programs and >compilers/assemblers and the like with minimal I/O requirements, most >productivity and comms programs had to go to the hardware directly >for display and communications. > >And that, I think was the innovation of programs such as WordStar and >SuperCalc, and, to a lesser extent MODEM7 and Kermit--that you were >running on an operating system that was basically designed for TTY >I/O with no connectivity and the majority of systems were using CRTs >and had modems. The problem became then how to make a single program >work for everyone--and that was done with custom patch overlays. > >DRI, for its part, seemed to remain blissfully ignorant of both of >these aspects. Ignorant, I think no, they gave the hooks and basic requirements. It was up to the BIOS developer to do a good job or just enough. I've repeatedly posted that if anything CP/M prevents little and you can do a great deal at the bios level to really deliver a better system. The best way to illustrate this is try a system with basic IO and one with a full interrupt drive IO. The first thing you notice is the ability to type ahead and the system feels more responsive. >Likewise, it wasn't MS-DOS that was the great advance for the IBM PC >platform, but rather the well-documented BIOS and I/O interfaces. >Heck, PC-DOS 1.0 wasn't that different from CP/M-86--you still had to >do your disk I/O through FCBs, just like CP/M. I believe, to this >day, you can still issue your DOS calls by loading (CL) with the >request number and calling TPA:0005. Well it was patterned (so say copied) after CP/M so.. No surpize there. ;) Allison > >Cheers, >Chuck

16 years, 3 months

Has anyone ever written a standalone Commodore disk drive emulator?

by dm561＠torfree.net

Have a look at: http://www.baltissen.org/newhtm/cbmhd.htm Ruud's the main guy behind the 1541 IDE project I mentioned to you, (and is on the CBM hacker's list I also mentioned) but he does have an IEEE <> PC project on his site as well. I've been meaning to look at the IEEE version myself; if you try it out, share your experience (as will I if I get to it first). mike --------------------------------------------------------------------------------------------- Message: 12 Date: Wed, 30 Jan 2008 02:19:23 +0000 From: Ethan Dicks <ethan.dicks at usap.gov> Subject: Has anyone ever written a standalone Commodore disk drive To: cctalk at classiccmp.org Message-ID: <20080130021923.GA7074 at usap.gov> Content-Type: text/plain; charset=us-ascii Hi, Commodore folks, I have just tracked down an ISA IEEE-488 card and was thinking that it might be interesting to use it to build an older PC into a Commodore diskette drive emulator - I recall there are various projects to interface modern hardware to PETs (like the C2N232 I have with me), but the idea in this case is to allow existing apps to work as if there were a real C= drive hanging off the PET's IEEE port. Essentially, the PC would act as closely to, say a 4040, as possible. My thought was that if I had a real IEEE-488 interface, it could handle the physical-layer protocol, and the emulator would only have to handle sending and receiving command strings and data. The virtual diskettes would be, of course, image files. I'm not really as worried about RELative files - more along the lines of "direct access" files where the code running on the PET wants to read and write individual sectors, ignoring the C= DOS filesystem. That is, in fact, the major reason for trying to emulate drives in the first place - if it was just a case of loading and saving streams of data as files, the C2N232 does a fine job of that (and costs on the order of $10 to breadboard). There seem to be a number of ways to emulate C= IEC-bus devices (such as the 1541-III), but not for the IEEE-488. If anyone can point me at any existing projects, even if they are incomplete, it would be a big help. Thanks, -ethan -- Ethan Dicks, A-333-S Current South Pole Weather at 30-Jan-2008 at 02:00 Z South Pole Station PSC 468 Box 400 Temp -34.8 F (-37.1 C) Windchill -57.9 F (-50.0 C) APO AP 96598 Wind 7.9 kts Grid 45 Barometer 674.7 mb (10829 ft) Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html

16 years, 3 months

How compatible were "MS-DOS Compatible" machines?

by cclist＠sydex.com

> Date: Wed, 30 Jan 2008 13:07:48 -0600 > From: Jim Leonard > Was there ever a *vanilla* MS-DOS? Short answer--yes. It was called an "OEM Kit". Basically, you got the binaries and instructions on how and what I/O drivers to write and you linked the whole mess together to form two files, IO.SYS and MSDOS.SYS, though you weren't confined to those names. Many utilities, such as MODE and FORMAT were provided in skeleton form with the vendor filling out the details. This lead to a some interesting variations on MODE. For example, the Grid MS-DOS version of MODE allows one to control the power status of the peripherals and a whole bunch of other things. I may even still have the OEM documentation wandering around somewhere, printed up on fading tractor-feed paper. A key difference between the two OEM arrangements was that you agreed to serialize the copies of DRI products that were sold, while Microsoft didn't require that. I think that MS simply charged you on the basis of the number of systems shipped--I'd have to go back to my files to make sure. When you get that "Synchronization error" message from MOVCPM, it means that MOVCPM has compared the serial number of the copy of CP/M that it contains with the one of the system on which it's running and the two don't match. Easy to patch out, however--but beware if you "fill out" your CP/M disk with another's files. Cheers, Chuck

16 years, 3 months

2.11BSD Patch 445; FPSIM fixed; 211bsd runs on systems without FPP

by glen.slick＠gmail.com

On Jan 30, 2008 11:53 PM, Zane H. Healy <healyzh at aracnet.com> wrote: > > Has anyone ever made an up-to-date install tape that doesn't require > you to apply all the patches? I've got a chicken/egg situation going > on, my PDP-11 uses a Viking QDT SCSI board, which requires one of the > very last patches in order to be supported. > > Zane > I have an MTI QTS-30 (aka CMD CQD-200/Ts) and TTi QTS-1 / QTS-3 SCSI tape controllers which I can use to boot a 2.11BSD install tape, but the install process hangs up while trying to restore the files from the tape to the hard drive. Anyone know for certain if the latest patches might help that with these TMSCP controllers? With the same SCSI tape drive and a CQD-220/TM I can complete the 2.11BSD tape install process to a hard drive attached to the CQD-220/TM, but then it won't cold boot from the hard drive attached to the CQD-220/TM. One of the MSCP boot loader patches is supposed to fix that, but I haven't built and verified myself yet. It's on the to do list.

16 years, 3 months

DEC LA180 printer

by harten＠injectstar.de

I slipped off the belt from the motor pulley. Now the motor can turn without moving the carriage. I tried to turn the motor by hand (power off) and it can be turned easily. On power up the motor starts to turn for about one second and then stopps with the bell continously beeping (till power off). I observed the signals -carry-, -borrow- and -inc- with an oscilloscope. They are there when the motor turns but are the timings o.k.? Regards Axel Harten.

16 years, 3 months

Help needed on a DEC LA180 printer

by harten＠injectstar.de

Hi! I'm a Computer collector from Germany and the last 3 years i spend a lot of time in reconstructing and repairing my PDP11/05 along with its peripheral devices (2x RK05,RX02,BA11ES). Noe that these things are working im trying to repair my LA180-PD printer, that was in no good condition. With a copy of the logic-prints i was able to find some faulty IC's on th logic board- but there must be at least one more. On Power-Up the carriage starts to move back to left edge but stopps before reaching the left end then the bell is turned on permanently. There is no reaction on any button pressed or switched over. Unfortunately i have no Maintenance Manual or Logic description, maybe there is a person out on this list who can help me with a copy of the documents. Regards Axel Harten.

16 years, 3 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by cclist＠sydex.com

> Date: Wed, 30 Jan 2008 15:44:40 +0100 > From: Holger Veit <holger.veit at iais.fraunhofer.de> > MSDOS was much better in abstracting hardware, because it had a loadable > driver concept. Loadable drivers didn't come along until MS/PC DOS 2.0. Before that, adding another device, say an extra disk drive, was a brutal patchwork affair. CP/M 86 was far more advanced (for that matter, CP/M Plus was too) than MS DOS 1.x. As a matter of fact, the DOS 1.1 reference material included information not only on commands, but system table layout, .EXE file structure and system requests. ONE disk buffer for blocking/deblocking. Read and write transferred one record to and from the DTA. Flat file structure; file I/O done with FCBs. As a matter of fact, if you didn't know any better, you'd have sworn that someone took CP/M 2.2 and ported it to the 8086. MS-DOS 2.0 was a huge advance over 1.1; by Microsoft's own admission, the goal was to get closer to Xenix in operability. > Point is there in both cases: the hardware designers did not foresee how > their hardware could or should be used by software, so they basically > implanted the bare chips, not even respecting IRQ and DMA requirements; > the OS developers did not foresee usable and extensible interfaces to > access and abstract various hardware and just hacked something that it > would somehow work; and finally the application designers found the whole > base OS functions where plain unusable and reinvented, each one > differently, the wheel, leaving burnt ground for others that somehow > required similar functions - "thou shall not use the printer port for your > dongle, I have it already." 20-20 hindsight is great, but let's take it from the viewpoint of the times. There were very many CP/M systems around at the time with *no* interrupt or DMA support. Remember that the 5150 made extensive use of peripheral chips that were from the 8-bit world (8237, 8253, 8259, 8255, not to mention the NS8250), so the fact that DMA and an interrupt controller (with 8 interrupt levels yet) and a timer was somewhat remarkable considering the competition. Although the BIOS functions came a long way as the PC evolved, MS-DOS still ran on a 5150, so the added BIOS functionality couldn't be exploited. The parallel port was designed as a printer port; the fact that it was used for other things can hardly be blamed on MS-DOS. The printer port does what it was designed to do extremely well. The fact that a dongle designer was so short-sighted as to not provide printer pass-through functionality can hardly be laid on the designers of the PC. Personally, I'm surprised the light pen interface wasn't used for more things. Cheers, Chuck

16 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
...
43
Older →

Jump to page:

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 January 2008