I have a situation at my client office where we must provide testers for
some sophisticated
PCBs. These PCB's have heavy relays, NiMH battery chargers, and
sensor-detection circuits
as well as one or more PICs.
To provide diagnostic information, _one pin_ of the PIC is dedicated to
performing a dump of
PIC register memory, independent of its normal operation. The data is
pumped out at a rate
of one bit every 4mS, slow but very reliable; to pump out 512 registers
it takes just over 2
seconds, using a Manchester scheme, with a 100mS "dead band wait" for
resyncing. I use
just 35 words of PIC code and just ONE register for this valuable
feature, which is
interrupt-driven.
The way I use the data is that I have the operator install a known
sensor into the PCB then
read the diagnostic information to see the internal results. If the
results are within nominal
range, I pronounce that board section good, then go to the next. It
saves the technicians
an immense amount of time, yet doesn't interfere with normal product
function. It also allows
the technician to monitor the PIC itself for internal problems (I have
found a few PIC16F877A
PICs with stuck port bits).
In years past I first used DOS PCs to read the diagnostic information
into the tester software,
written almost always in Borland Pascal 5.5 for DOS. The data is slow
enough that DOS can
extract it without error. I then went to Delphi 5. Of late, Delphi is
not well supported, so I
find myself going back to old DOS machines. The data is read through the
PC's Parallel Port,
and it works on even the OLDEST parallel port (uses the ACK pin).
I am astonished at how reliable old DOS machines are (and were)! Why did
we EVER get
caught up with windows? I needed 3 old DOS systems, and my old resources
of the past
(pawn shops) didn't have any, so to get them, I had to ask friends and
relatives to search
their storage lockers and closets for them. Out of 5 received, I cobbled
together the 3
I needed by shifting hard disks around, parallel port cards, etc,
tossing the broken stuff.
I agree on the reliability of the DOS as a monolitic OS. In fact, I have two
PC104 Pentium boards working 24x7 without any incidence using MSDOS 6.22
What is the big limitation with DOS? Well, multitasking. If you want to run
several programs at a time, it is not different than dealing with a PIC: you
have to make resident programs (a nightmare to debug) and then have these
little programs running driven by interrupts. This is definitely not the
best way to program multitasking.
Furthermore, if you go beyond a x286 computer uC, then you are missing all
the native uC multitasking features, except you load a Protected DOS
enhancer to get a flat 32bit memory space, protected code, etc.
What is the other problem? Reliability of the whole OS is determined by the
reliability of the application you run. In other words, a simple glitch and
the whole OS gets broken. So you need to develop really robust apps to have
a stable DOS environment.
But it is useful for many single-thread things, like the one you expose.
>
> I have a situation at my client office where we must provide testers for
> some sophisticated
> PCBs. These PCB's have heavy relays, NiMH battery chargers, and
> sensor-detection circuits
> as well as one or more PICs.
>
> To provide diagnostic information, _one pin_ of the PIC is dedicated to
> performing a dump of
> PIC register memory, independent of its normal operation. The data is
> pumped out at a rate
> of one bit every 4mS, slow but very reliable; to pump out 512 registers
> it takes just over 2
> seconds, using a Manchester scheme, with a 100mS "dead band wait" for
> resyncing. I use
> just 35 words of PIC code and just ONE register for this valuable
> feature, which is
> interrupt-driven.
>
> The way I use the data is that I have the operator install a known
> sensor into the PCB then
> read the diagnostic information to see the internal results. If the
> results are within nominal
> range, I pronounce that board section good, then go to the next. It
> saves the technicians
> an immense amount of time, yet doesn't interfere with normal product
> function. It also allows
> the technician to monitor the PIC itself for internal problems (I have
> found a few PIC16F877A
> PICs with stuck port bits).
>
> In years past I first used DOS PCs to read the diagnostic information
> into the tester software,
> written almost always in Borland Pascal 5.5 for DOS. The data is slow
> enough that DOS can
> extract it without error. I then went to Delphi 5. Of late, Delphi is
> not well supported, so I
> find myself going back to old DOS machines. The data is read through the
> PC's Parallel Port,
> and it works on even the OLDEST parallel port (uses the ACK pin).
>
> I am astonished at how reliable old DOS machines are (and were)! Why did
> we EVER get
> caught up with windows? I needed 3 old DOS systems, and my old resources
> of the past
> (pawn shops) didn't have any, so to get them, I had to ask friends and
> relatives to search
> their storage lockers and closets for them. Out of 5 received, I cobbled
> together the 3
> I needed by shifting hard disks around, parallel port cards, etc,
> tossing the broken stuff.
>
> FWIW, FreeDOS is the operating system of choice.
>
> --Bob A
> I am astonished at how reliable old DOS machines are (and were)! Why did
> we EVER get caught up with windows? I needed 3 old DOS systems,
> and my old resources of the past (pawn shops) didn't have any, so to get them,
> I had to ask friends and relatives to search
> their storage lockers and closets for them. Out of 5 received, I cobbled
> together the 3 I needed by shifting hard disks around, parallel port cards, etc,
> tossing the broken stuff.
>
> FWIW, FreeDOS is the operating system of choice.
In my last job, there are still quite some testers using old DOS
test software (written in Borland C++ 3.1). The problem is that
the old PCs (many of them Pentium 1 or 486) started to die.
However they can still get industrial PC with Pentium class CPU
to run the software (it is said that some software have problems
with faster PCs). And some of them got migrated to Windows
based software.
> On Nov 30, 2007 7:45 PM, Bob Axtell <engineerKILLspamcotse.net> wrote:
>
>
>> I am astonished at how reliable old DOS machines are (and were)! Why did
>> we EVER get caught up with windows? I needed 3 old DOS systems,
>> and my old resources of the past (pawn shops) didn't have any, so to get them,
>> I had to ask friends and relatives to search
>> their storage lockers and closets for them. Out of 5 received, I cobbled
>> together the 3 I needed by shifting hard disks around, parallel port cards, etc,
>> tossing the broken stuff.
>>
>> FWIW, FreeDOS is the operating system of choice.
>>
>
> In my last job, there are still quite some testers using old DOS
> test software (written in Borland C++ 3.1). The problem is that
> the old PCs (many of them Pentium 1 or 486) started to die.
> However they can still get industrial PC with Pentium class CPU
> to run the software (it is said that some software have problems
> with faster PCs). And some of them got migrated to Windows
> based software.
>
> Xiaofan
>
DOS machines are used in many assembly facilities in Mexico, too.
On Fri, 30 Nov 2007 04:45:57 -0700, Bob Axtell wrote: {Quote hidden}
> I have a situation at my client office where we must provide testers for
> some sophisticated PCBs. These PCB's have heavy relays, NiMH battery
> chargers, and sensor- detection circuits as well as one or more PICs.
>
> To provide diagnostic information, _one pin_ of the PIC is dedicated to
> performing a dump of PIC register memory, independent of its normal
> operation. The data is pumped out at a rate of one bit every 4mS, slow
> but very reliable; to pump out 512 registers it takes just over 2
> seconds, using a Manchester scheme, with a 100mS "dead band wait" for
> resyncing. I use just 35 words of PIC code and just ONE register for this
> valuable feature, which is interrupt-driven.
>
> The way I use the data is that I have the operator install a known sensor
> into the PCB then read the diagnostic information to see the internal
> results. If the results are within nominal range, I pronounce that board
> section good, then go to the next. It saves the technicians an immense
> amount of time, yet doesn't interfere with normal product function. It
> also allows the technician to monitor the PIC itself for internal
> problems (I have found a few PIC16F877A PICs with stuck port bits).
>
> In years past I first used DOS PCs to read the diagnostic information
> into the tester software, written almost always in Borland Pascal 5.5 for
> DOS. The data is slow enough that DOS can extract it without error. I
> then went to Delphi 5. Of late, Delphi is not well supported, so I find
> myself going back to old DOS machines. The data is read through the PC's
> Parallel Port, and it works on even the OLDEST parallel port (uses the
> ACK pin).
>
> I am astonished at how reliable old DOS machines are (and were)! Why did
> we EVER get caught up with windows? I needed 3 old DOS systems, and my
> old resources of the past (pawn shops) didn't have any, so to get them, I
> had to ask friends and relatives to search their storage lockers and
> closets for them. Out of 5 received, I cobbled together the 3 I needed by
> shifting hard disks around, parallel port cards, etc, tossing the broken
> stuff.
>
> FWIW, FreeDOS is the operating system of choice.
Can I make a dumb (smart? obvious?) suggestion?
Why not make a small "bridge" PCB that reads your 1 bit datastream and
converts it to a standard RS232 UART or USB interface? (Or both, that's
what I'd do).
Then you can interface really easily with almost any PC, any flavor, any
language over a standard I/O interface and that pretty much any programming
environment supports.
You already have the IP (software that interprets/converts your manchester
data) so the engineering effort required would be minimal as the RS232
UART/USB side is almost a "no code" solution. I build boards like this all
the time in small quantities for $100-$200 a batch. Once you have them you
can use them for every test application that comes up with this interface
and not have to worry about the test PC environment supporting hardware bit
banging.
I recently convinced a client in the automotive business to have us develop
such a device for them. It happened to be a full duplex device for one
their standard busses but now that they have it the have already found many
more uses for it. In the past they had to cobble up a new interface every
time they had some special production line test or programming they needed.
Now they just plug this device in and do all the software required from the
PC side. The interface box takes care of all the bus data translation and
timing.
> I needed 3 old DOS systems, and my old resources of the past (pawn
> shops) didn't have any, so to get them, I had to ask friends and
> relatives to search their storage lockers and closets for them. Out
> of 5 received, I cobbled together the 3 I needed by shifting hard
> disks around, parallel port cards, etc, tossing the broken stuff.
>
> FWIW, FreeDOS is the operating system of choice.
Won't FreeDOS run on more modern hardware? (although I guess at this
point it's getting hard to find "new hardware" that has a parallel
port.)
I do see assorted single board computers advertised to run DOS. I'm
a little surprised that it's not more common to see embedded systems
running DOS. It might be interesting to see what happens in a couple
years when the original x86 patents have expired. Could be a lot of
x86 SoC chips showing up?
I must disagree ... what DOS offers you is the an environment where
you can build simple applications that are bullet proof in their
simplicity. You don't have to have all that extra baggage just to get
it to run. I have written applications that do their thing that run
under DOS without a glitch for weeks on end that never make a DOS call
beyond the initial load. They own the machine from startup to
whenever. Granted if your code screws up you are screwed, but the
chances of screwing up on some OS subtlety are minimal. I still keep a
copy of MSC 5.1 and a DOS 6.22 on a bootable CDROM in case I have the
need.
On Nov 30, 2007, at 7:03 AM, Ariel Rocholl wrote:
> What is the other problem? Reliability of the whole OS is determined
> by the
> reliability of the application you run. In other words, a simple
> glitch and
> the whole OS gets broken. So you need to develop really robust apps
> to have
> a stable DOS environment.
--
cheers ... 73 de brian riley, n1bq , underhill center, vermont
<http://web.mac.com/brianbr/> Tech Blog
<http://www.wulfden.org/TheShoppe.shtml>
Home of the
K107 Serial LCD Controller Kit FT817 Power Conditioner Kit
Tab Robot Laser Tag Kit MSP430 Chips and Connectors
Propeller Robot Controller SX48 "Tech Board" Kit
PICAXE chips and accessories Freeduino systems
> On Fri, 30 Nov 2007 04:45:57 -0700, Bob Axtell wrote:
>
>> I have a situation at my client office where we must provide testers for
>> some sophisticated PCBs. These PCB's have heavy relays, NiMH battery
>> chargers, and sensor- detection circuits as well as one or more PICs.
>>
>> To provide diagnostic information, _one pin_ of the PIC is dedicated to
>> performing a dump of PIC register memory, independent of its normal
>> operation. The data is pumped out at a rate of one bit every 4mS, slow
>> but very reliable; to pump out 512 registers it takes just over 2
>> seconds, using a Manchester scheme, with a 100mS "dead band wait" for
>> resyncing. I use just 35 words of PIC code and just ONE register for this
>> valuable feature, which is interrupt-driven.
>>
>> The way I use the data is that I have the operator install a known sensor
>> into the PCB then read the diagnostic information to see the internal
>> results. If the results are within nominal range, I pronounce that board
>> section good, then go to the next. It saves the technicians an immense
>> amount of time, yet doesn't interfere with normal product function. It
>> also allows the technician to monitor the PIC itself for internal
>> problems (I have found a few PIC16F877A PICs with stuck port bits).
>>
>> In years past I first used DOS PCs to read the diagnostic information
>> into the tester software, written almost always in Borland Pascal 5.5 for
>> DOS. The data is slow enough that DOS can extract it without error. I
>> then went to Delphi 5. Of late, Delphi is not well supported, so I find
>> myself going back to old DOS machines. The data is read through the PC's
>> Parallel Port, and it works on even the OLDEST parallel port (uses the
>> ACK pin).
>>
>> I am astonished at how reliable old DOS machines are (and were)! Why did
>> we EVER get caught up with windows? I needed 3 old DOS systems, and my
>> old resources of the past (pawn shops) didn't have any, so to get them, I
>> had to ask friends and relatives to search their storage lockers and
>> closets for them. Out of 5 received, I cobbled together the 3 I needed by
>> shifting hard disks around, parallel port cards, etc, tossing the broken
>> stuff.
>>
>> FWIW, FreeDOS is the operating system of choice.
>>
>
> Can I make a dumb (smart? obvious?) suggestion?
>
> Why not make a small "bridge" PCB that reads your 1 bit datastream and
> converts it to a standard RS232 UART or USB interface? (Or both, that's
> what I'd do).
>
> Then you can interface really easily with almost any PC, any flavor, any
> language over a standard I/O interface and that pretty much any programming
> environment supports.
>
> You already have the IP (software that interprets/converts your manchester
> data) so the engineering effort required would be minimal as the RS232
> UART/USB side is almost a "no code" solution. I build boards like this all
> the time in small quantities for $100-$200 a batch. Once you have them you
> can use them for every test application that comes up with this interface
> and not have to worry about the test PC environment supporting hardware bit
> banging.
>
> I recently convinced a client in the automotive business to have us develop
> such a device for them. It happened to be a full duplex device for one
> their standard busses but now that they have it the have already found many
> more uses for it. In the past they had to cobble up a new interface every
> time they had some special production line test or programming they needed.
> Now they just plug this device in and do all the software required from the
> PC side. The interface box takes care of all the bus data translation and
> timing.
>
> Matt Pobursky
> Maximum Performance Systems
>
Well the low cost of DOS is another plus...But your idea is obvious, I
agree! Notice the dent in
my forehead? I'll do it! I'll probably use a PIC12F629, since I know the
input well, and I only need to
bit-bang output at 9600bps or so, piece of cake... I'll make up a layout
and get a few barebones PCBs
from AP Circuits. While I am at it, I will make a software developer
for the PIC12F629/675 series
( matches the PIC12F629 footprint but a PIC16F88 is mounted on a tiny
PCB for developing code)
at the same time...
William "Chops" Westfield wrote:
> On Nov 30, 2007, at 3:45 AM, Bob Axtell wrote:
>
>
>> I needed 3 old DOS systems, and my old resources of the past (pawn
>> shops) didn't have any, so to get them, I had to ask friends and
>> relatives to search their storage lockers and closets for them. Out
>> of 5 received, I cobbled together the 3 I needed by shifting hard
>> disks around, parallel port cards, etc, tossing the broken stuff.
>>
>> FWIW, FreeDOS is the operating system of choice.
>>
>
> Won't FreeDOS run on more modern hardware? (although I guess at this
> point it's getting hard to find "new hardware" that has a parallel
> port.)
>
Actually, almost any desktop can have a parallel port added. Heck, there
are a LOT of neat
stuff that was written primarily for FreeDos.
> I do see assorted single board computers advertised to run DOS. I'm
> a little surprised that it's not more common to see embedded systems
> running DOS. It might be interesting to see what happens in a couple
> years when the original x86 patents have expired. Could be a lot of
> x86 SoC chips showing up?
>
>
I know of a few embedded systems that run DOS, "searchlight dos" I
believe. It was a total rewrite.
FreeDOS looks interesting, I went to download it and it also pointed
me also to JPC the Java PC emulator. I downloaded that too and just
for kicks executed JPC.jar on my MacBookPro running Leopard 10.5.1, It
came up and immediately grabbed the FreeDOS basic boot image which was
in the same download directory and brought FreeDOS up with both feet
churning .. NEAT!
> William "Chops" Westfield wrote:
>> On Nov 30, 2007, at 3:45 AM, Bob Axtell wrote:
>>
>>
>>> I needed 3 old DOS systems, and my old resources of the past (pawn
>>> shops) didn't have any, so to get them, I had to ask friends and
>>> relatives to search their storage lockers and closets for them. Out
>>> of 5 received, I cobbled together the 3 I needed by shifting hard
>>> disks around, parallel port cards, etc, tossing the broken stuff.
>>>
>>> FWIW, FreeDOS is the operating system of choice.
>>>
>>
>> Won't FreeDOS run on more modern hardware? (although I guess at this
>> point it's getting hard to find "new hardware" that has a parallel
>> port.)
>>
> Actually, almost any desktop can have a parallel port added. Heck,
> there
> are a LOT of neat
> stuff that was written primarily for FreeDos.
>> I do see assorted single board computers advertised to run DOS. I'm
>> a little surprised that it's not more common to see embedded systems
>> running DOS. It might be interesting to see what happens in a couple
>> years when the original x86 patents have expired. Could be a lot of
>> x86 SoC chips showing up?
>>
>>
> I know of a few embedded systems that run DOS, "searchlight dos" I
> believe. It was a total rewrite.
>
> --Bob
>
>
>> BillW
>>
>
> I must disagree ... what DOS offers you is the an environment where
> you can build simple applications that are bullet proof in their
> simplicity. You don't have to have all that extra baggage just to get
> it to run.
This is true indeed.
But, if internet had never existed, Windows would probably been as safe,
fast/stable and working as DOS (starting with 95, say :)
Of course, in that case we won't be chatting on this list!
Dario Greggio wrote:
> Brian B. Riley wrote:
>
>> I must disagree ... what DOS offers you is the an environment where
>> you can build simple applications that are bullet proof in their
>> simplicity. You don't have to have all that extra baggage just to get
>> it to run.
>
> This is true indeed.
> But, if internet had never existed, Windows would probably been as safe,
> fast/stable and working as DOS (starting with 95, say :)
>
> Of course, in that case we won't be chatting on this list!
Uhm we did have BBS's and news groups long before the Internet (as
we know it now). I had my home machine on the UUCP network in '88.
>
> Uhm we did have BBS's and news groups long before the Internet (as
> we know it now). I had my home machine on the UUCP network in '88.
>
> Windows was unstable back then also. :-)
>
Windows is stable now? *chuckles*
On a serious note, those were fun days. I ran a BBS with 33.6 dialup.
Anyone remember fidonet? As well as other nets for messages boards.
On Fri, Nov 30, 2007 at 02:48:52PM -0500, Joshua Shriver wrote: {Quote hidden}
> >
> > Uhm we did have BBS's and news groups long before the Internet (as
> > we know it now). I had my home machine on the UUCP network in '88.
> >
> > Windows was unstable back then also. :-)
> >
>
> Windows is stable now? *chuckles*
>
> On a serious note, those were fun days. I ran a BBS with 33.6 dialup.
> Anyone remember fidonet? As well as other nets for messages boards.
Sure do! I was an ILink regular for awhile, I was one of the last real
dial up BBS users left... there's still a core group of them out there
too, keeping it alive.
Joshua Shriver wrote:
>> Uhm we did have BBS's and news groups long before the Internet (as
>> we know it now). I had my home machine on the UUCP network in '88.
>>
>> Windows was unstable back then also. :-)
> Windows is stable now? *chuckles*
I never inferred it was stable. :-) I think the 'also' implies
now and then.
> On a serious note, those were fun days. I ran a BBS with 33.6 dialup.
> Anyone remember fidonet? As well as other nets for messages boards.
We had Fidonet all the way back to 1200 (when it was brand new :-).
I still remember the uucp to Fido and Fido to uucp software.
> Uhm we did have BBS's and news groups long before the Internet
> (as we know it now). I had my home machine on the UUCP network
> in '88
I dipped my toe in the water with BBS about then, using a C=64
and a World Modem chip project. ISTR it was 300 or 2400 baud,
slow as a wet Sunday. Local NZ BBS were not too active, or that
interesting really, and I drifted away for a couple of years
On Dec 1, 2007 3:48 AM, Joshua Shriver <jshriverspam_OUTgmail.com> wrote:
> >
> > Uhm we did have BBS's and news groups long before the Internet (as
> > we know it now). I had my home machine on the UUCP network in '88.
> >
> > Windows was unstable back then also. :-)
> >
>
> Windows is stable now? *chuckles*
>
I will say Windows XP SP2 and Vista will be at least it is much
more stable than DOS. Back in the days I used DOS (3.3),
virus and crash were very often.
On Dec 1, 2007 2:49 AM, Brian B. Riley <@spam@brianbrKILLspammac.com> wrote:
> FreeDOS looks interesting, I went to download it and it also pointed
> me also to JPC the Java PC emulator. I downloaded that too and just
> for kicks executed JPC.jar on my MacBookPro running Leopard 10.5.1, It
> came up and immediately grabbed the FreeDOS basic boot image which was
> in the same download directory and brought FreeDOS up with both feet
> churning .. NEAT!
>
I used to use DOSEMU+FreeDOS (or DRDOS last time). But now I
find DosBox to be easier to use. Last time I actually installed Windows
3.1 on top of DosBox.
On Nov 30, 2007, at 11:02 AM, Dario Greggio wrote:
> But, if internet had never existed...
> :
> Of course, in that case we won't be chatting on this list!
Sure we would. Any number of mailing lists and newsgroups
existed and passed much traffic long before "The Internet as
we now know it" existed. Arguably, the non-web-based file
sharing would have led to similar problems with malware,
especially with such obvious targets as Simtel20...
I think you mean single thread DOS standard programs running alone, were
you run "bullet proof" applications, that owns the machine completely.
So again, for that, I agree your whole computer setup will be as reliable as
the bullet proof application that drives it completely. I admitely agree on
the Bob's setup being fantastic for DOS hw & sw. If your application gets
into an infinite loop, or goes to a reserved OS memory area and writes on
it, the system as a whole will be unavailable. Only option is reboot.
Or try now to have few resident applications working together in upper
memory space, and interfering the less each other and with any other DOS
application you may want to load anytime (say a spreadsheet or a FIDOnet
client or a VGA game). What you get? One of the most unreliable setups the
computer community had to deal for years.
A reliable OS should, no matter how unreliable a particular application is,
keep the system stability at all cost.
>
> I must disagree ... what DOS offers you is the an environment where
> you can build simple applications that are bullet proof in their
> simplicity. You don't have to have all that extra baggage just to get
> it to run. I have written applications that do their thing that run
> under DOS without a glitch for weeks on end that never make a DOS call
> beyond the initial load. They own the machine from startup to
> whenever. Granted if your code screws up you are screwed, but the
> chances of screwing up on some OS subtlety are minimal. I still keep a
> copy of MSC 5.1 and a DOS 6.22 on a bootable CDROM in case I have the
> need.
>
>
> On Nov 30, 2007, at 7:03 AM, Ariel Rocholl wrote:
>
> > What is the other problem? Reliability of the whole OS is determined
> > by the
> > reliability of the application you run. In other words, a simple
> > glitch and
> > the whole OS gets broken. So you need to develop really robust apps
> > to have
> > a stable DOS environment.
>
> --
> cheers ... 73 de brian riley, n1bq , underhill center, vermont
> <http://web.mac.com/brianbr/> Tech Blog
> <http://www.wulfden.org/TheShoppe.shtml>
> Home of the
> K107 Serial LCD Controller Kit FT817 Power Conditioner Kit
> Tab Robot Laser Tag Kit MSP430 Chips and Connectors
> Propeller Robot Controller SX48 "Tech Board" Kit
> PICAXE chips and accessories Freeduino systems
>
>
>
I think you mean single thread DOS standard programs running alone, were
you run "bullet proof" applications, that owns the machine completely.
So again, for that, I agree your whole computer setup will be as reliable as
the bullet proof application that drives it completely. I admitely agree on
the Bob's setup being fantastic for DOS hw & sw. If your application gets
into an infinite loop, or goes to a reserved OS memory area and writes on
it, the system as a whole will be unavailable. Only option is reboot.
Or try now to have few resident applications working together in upper
memory space, and interfering the less each other and with any other DOS
application you may want to load anytime (say a spreadsheet or a FIDOnet
client or a VGA game). What you get? One of the most unreliable setups the
computer community had to deal for years.
A reliable OS should, no matter how unreliable a particular application is,
keep the system stability at all cost.
>
> I must disagree ... what DOS offers you is the an environment where
> you can build simple applications that are bullet proof in their
> simplicity. You don't have to have all that extra baggage just to get
> it to run. I have written applications that do their thing that run
> under DOS without a glitch for weeks on end that never make a DOS call
> beyond the initial load. They own the machine from startup to
> whenever. Granted if your code screws up you are screwed, but the
> chances of screwing up on some OS subtlety are minimal. I still keep a
> copy of MSC 5.1 and a DOS 6.22 on a bootable CDROM in case I have the
> need.
>
>
> On Nov 30, 2007, at 7:03 AM, Ariel Rocholl wrote:
>
> > What is the other problem? Reliability of the whole OS is determined
> > by the
> > reliability of the application you run. In other words, a simple
> > glitch and
> > the whole OS gets broken. So you need to develop really robust apps
> > to have
> > a stable DOS environment.
>
> --
> cheers ... 73 de brian riley, n1bq , underhill center, vermont
> <http://web.mac.com/brianbr/> Tech Blog
> <http://www.wulfden.org/TheShoppe.shtml>
> Home of the
> K107 Serial LCD Controller Kit FT817 Power Conditioner Kit
> Tab Robot Laser Tag Kit MSP430 Chips and Connectors
> Propeller Robot Controller SX48 "Tech Board" Kit
> PICAXE chips and accessories Freeduino systems
>
>
>
> back to old DOS machines. The data is read through the PC's
> Parallel Port, and it works on even the OLDEST parallel port
> (uses the ACK pin).
>
> I am astonished at how reliable old DOS machines are (and
> were)! Why did we EVER get caught up with windows? I needed 3
> old DOS systems, and my old resources of the past (pawn
> shops) didn't have any, so to get them, I had to ask friends
> and relatives to search their storage lockers and closets for
> them. Out of 5 received, I cobbled together the 3 I needed by
> shifting hard disks around, parallel port cards, etc, tossing
> the broken stuff.
>
> FWIW, FreeDOS is the operating system of choice.
If you do need a DOS box (ignoring the fact someone pointed out you don't in
your case :) ), replacing the hard drives with CompactFlash cards works
well.
The interface boards are quite cheap (< $10) as CF is basically IDE anyway,
and if you only need a small drive, the CF cards themselves can be had for
free, just ask a photographer. Cameras often come with small 'starter'
cards (say 4M - 16M), and are pretty useless. A local camera shop gave me a
handful just to stop them taking up space.
Depending on what app the box is running, you can often pull the CF card
out, put it in your Windows etc machine, copy a few files and put it back.
Not that the shutdown/reboot cycle take all that long anyway.
I use these for small CNC machines, usually runing TurboCNC.
On Nov 30, 2007 7:27 PM, William Chops Westfield <TakeThisOuTwestfwEraseMEspam_OUTmac.com> wrote:
>
> On Nov 30, 2007, at 11:02 AM, Dario Greggio wrote:
>
> > But, if internet had never existed...
> > :
> > Of course, in that case we won't be chatting on this list!
>
> Sure we would. Any number of mailing lists and newsgroups
> existed and passed much traffic long before "The Internet as
> we now know it" existed. Arguably, the non-web-based file
> sharing would have led to similar problems with malware,
> especially with such obvious targets as Simtel20...
>
> http://tinyurl.com/2njw72
*PLEASE* provide a description of where tinyurl.com links go. I was
curious, so I clicked the link, only to have google drop one of my
newgroups from my active list because I have not visited a new
newsgroups...
Bill
--
Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org
On Dec 3, 2007 10:54 AM, William Couture <RemoveMEbcoutureTakeThisOuTgmail.com> wrote:
> *PLEASE* provide a description of where tinyurl.com links go. I was
> curious, so I clicked the link, only to have google drop one of my
> newgroups from my active list because I have not visited a new
> newsgroups...
Errr.... make that "I have now visited a new newsgroup"
Bill { typing dyslexically this morning }
--
Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org
William Couture wrote:
> On Nov 30, 2007 7:27 PM, William Chops Westfield <westfwEraseME.....mac.com> wrote:
>> On Nov 30, 2007, at 11:02 AM, Dario Greggio wrote:
>>
>>> But, if internet had never existed...
>>> :
>>> Of course, in that case we won't be chatting on this list!
>> Sure we would. Any number of mailing lists and newsgroups
>> existed and passed much traffic long before "The Internet as
>> we now know it" existed. Arguably, the non-web-based file
>> sharing would have led to similar problems with malware,
>> especially with such obvious targets as Simtel20...
>>
>> http://tinyurl.com/2njw72
>
> *PLEASE* provide a description of where tinyurl.com links go. I was
> curious, so I clicked the link, only to have google drop one of my
> newgroups from my active list because I have not visited a new
> newsgroups...
Real URL's convey some information about where you're going, etc...
that's useful.
Bad sites mishandle URL's and make them too big for broken mail and
other clients, so then tinyURL pops up to "help".
Typical technological "fix" that has unintended bad consequences when
trying to fix a human problem. (Web coders who don't know what they're
doing and create huge URL's.)
>>
>> *PLEASE* provide a description of where tinyurl.com links go.
>> I was curious, so I clicked the link, only to have google drop
>> one of my newgroups from my active list because I have now
>> visited a new newsgroups...
Sorry. I usually include the description. In this case, the
description probably wouldn't have helped, since it would have
been on the order of "an old posting of mine on the info-cpm
mailing list." I wasn't aware that google or anything else
treated the historical usenet archive as "visiting a newsgroup"
or that this would result in pruning of other newgroups from a
subscription list.
I don't know how useful the <> brackets around long URLs are, but it seems
that some clients use this when formatting the message that is to be sent
and don't linebreak what's inside, and maybe some clients are even smart
enough when receiving such broken URLs to join them together.
Does anybody see any difference in the two URLs (with and without <>)
above?
>Does anybody see any difference in the two URLs (with and without <>)
>above?
I see no difference in my Outlook Express, but I have found that enclosing
links in brackets meets with varying success, as in it doesn't guarantee
that the link won't always wrap without breaking. I do not know what the
difference is, but in this case both links occupied three lines, with all
three lines being colour coded as being a link, whereas the OPs link never
did.
>
>> groups.google.com/group/fa.info-cpm/browse_thread/thread/
>> 1826bb3801bfafe3/abaa1b9631e34c0d?lnk=st&q=westfw%
>> 40wharton#abaa1b9631e34c0d
>
> http://groups.google.com/group/fa.info-cpm/browse_thread/thread/
> 1826bb3801bfafe3/abaa1b9631e34c0d?lnk=st&q=westfw%
> 40wharton#abaa1b9631e34c0d
>
> <http://groups.google.com/group/fa.info-cpm/browse_thread/thread/
> 1826bb3801bfafe3/abaa1b9631e34c0d?lnk=st&q=westfw%
> 40wharton#abaa1b9631e34c0d>
>
> I don't know how useful the <> brackets around long URLs are, but
> it seems
> that some clients use this when formatting the message that is to
> be sent
> and don't linebreak what's inside, and maybe some clients are even
> smart
> enough when receiving such broken URLs to join them together.
>
> Does anybody see any difference in the two URLs (with and without <>)
I saw no difference on reception, and I think I've noticed previously
that it's my transmitting client that breaks up long URLs whether they
have the angle-brackets or not. I guess this message will show...
> On Dec 5, 2007, at 4:41 AM, Gerhard Fiedler wrote:
>>> groups.google.com/group/fa.info-cpm/browse_thread/thread/
>>> 1826bb3801bfafe3/abaa1b9631e34c0d?lnk=st&q=westfw%
>>> 40wharton#abaa1b9631e34c0d
>>
>> groups.google.com/group/fa.info-cpm/browse_thread/thread/
>> 1826bb3801bfafe3/abaa1b9631e34c0d?lnk=st&q=westfw%
>> 40wharton#abaa1b9631e34c0d
>>
>> <groups.google.com/group/fa.info-cpm/browse_thread/thread/
>> 1826bb3801bfafe3/abaa1b9631e34c0d?lnk=st&q=westfw%
>> 40wharton#abaa1b9631e34c0d>
>>
>> I don't know how useful the <> brackets around long URLs are, but it
>> seems that some clients use this when formatting the message that is to
>> be sent and don't linebreak what's inside, and maybe some clients are
>> even smart enough when receiving such broken URLs to join them
>> together.
>>
>> Does anybody see any difference in the two URLs (with and without <>)
>
> I saw no difference on reception, and I think I've noticed previously
> that it's my transmitting client that breaks up long URLs whether they
> have the angle-brackets or not. I guess this message will show...
It seems to be the transmitting client.
I think this message of yours didn't show, because you didn't take the
whole link, put it in angle-brackets and re-sent it. As you sent it, it
seemed to have been part of the cited lines.
cotse.net>:
