Searching \ for '[PIC]: PIC data via PC parallel port to screen' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=data
Search entire site for: 'PIC data via PC parallel port to screen'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: PIC data via PC parallel port to screen'
2000\12\27@002623 by David Pearson (SKYTRONICS)

picon face
Hi,
       To all the PC programming experts a couple of questions.
I'm transferring data from a CCD image sensor for display on a PC via the
parallel port.  Works fine, 8 bit gray scale. 400 x 280 pixels.  I'm using a
F877 to transfer data to the PC using the parallel port in Bi-directional
mode.  On the PC end, I'm using Delphi 5 with my own Assembly Portin,
Portout, Porttest routines.  Plotting pixels using the Plotxy functions.

The problem, it's very slow.  It takes ~12 seconds to plot a frame on a
Pentium 120.  From what I've read, the maximum toggle rate I can expect on
the parallel port is 500 nsec to 2 usecs, depending on what you read.  Even
so, I'm seeing times between setting a bit on the parallel port by the F877
to the time the PC recognizes the signal of about 15 usecs.  Also,  the
plotting routine itself is slow, about 6 seconds to plot the 400 X 280 frame
when plotting a test grayscale pattern, no port IO, just incrementing the
plot value.

Does anyone have any ideas on how to speed things up?  I need a Windoze
95/98 environment using either Delphi or VB.
Any ideas on how to speed up the data transfer?  Faster portIO?  Faster
Plotting in Delphi?
It seems crazy to me that my $5.00 PIC has to wait for a 120 MHz machine to
do data transfers.  Is the Windoze environment that inefficient?

Any ideas and help is appreciated and may be useful to other group members.

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2000\12\27@041445 by Roman Black

flavicon
face
{Quote hidden}

1. "Is windows that inefficient" = YES
2. "any ideas and help" = May be difficult! :o)

I use the parallel port for data input all the time, not
having access to ICE and other expensive goodies I do it
the hard way by attaching most of my PIC projects into
the par port and this gives benefits over the ICE anyway
with the ability to chart waveforms and do sophisticated
measurement.

Firstly, I have only played with Delphi for a short while,
as I don't like Pascal that much. It does seem to me that
Delphi is very much a "idiot language". This almost always
means; easy to make pretty screens but performs like shite.

I get data from the par port using Turbo C (dos) and I
program in C-- with smidges of 8086 asm thrown in. You
can get a byte from the par port with something like a
thebyte=inportb(port_id)
which compiles down to a one-word cpu instruction and
on a 486 or pentium is virtually instantaneous.

Now I'm imagining (guessing) that Delphi has to beg
Bill for a chance to peek at the par port, and like most
windows programs will run very low performance.

I don't really have a solution for you, other than to
start programming for a high performance environment
(I am still making dos apps that run fabulously under
Win 95) OR, try finding a windows programming expert
who knows how to beg/force etc windows to give you
better access to the port.

Having done many years of fast hardware/software
interfacing with dos apps to the real world it never
ceases to amaze me just how PATHETIC windows is at
controlling anything more than a word processor.
:o)
-Roman

PS. Many people don't realise the par port has
more than 8 pins, you can get 12 bits input +
another bit for clk with no problems. This alone
will give you 1.5x the transfer rate.

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2000\12\27@050538 by Octavio P Nogueira

flavicon
face
Hi David, look below for a very FAST routine
to draw on your picture box.
Your problem is with thr PlotXY function.
Try this routine and you will see how
fast it is.
Put the value you want to lot in pixelval
And Roman, yes, you can do very fast port
read in Windows with Delphi!

------- begin --------------------
var
line: PByteArray;
j,line: integer;
Bmp: Tbitmap;
begin
   Bmp:=Image1.Picture.bitmap;
   Bmp.PixelFormat:=pf8bit;
   Bmp.width:=400;
   Bmp.height:=280;
   for line:=0 to 279
   begin
       line:=PByteArray(Bmp.Scanline[line]);
       for j:=0 to 399 do
       begin
           line[j]:=pixelval;
       end;
   end;
-------------- end ---------------
Friendly Regards

Octavio Nogueira
===================================================
.....nogueiraKILLspamspam.....propic2.com                  ICQ# 19841898
ProPic tools - low cost PIC programmer and emulator
http://www.propic2.com
===================================================

{Original Message removed}

2000\12\27@052238 by dr. Imre Bartfai

flavicon
face
On Wed, 27 Dec 2000, David Pearson (SKYTRONICS) wrote:

{Quote hidden}

Yes, it is. I would try it (I does is anyway) using pure DOS. No
hassle. Unfortunately, Delphi can be forgotten, but there is e. g. TP 5.5
(for free), or FreePascal. Did you ever consider interrupt-driven I/O?

Regards,
Imre

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2000\12\27@072455 by Bob Ammerman

picon face
Parallel port:

Are you just polling the parallel port in a tight Delphi loop? What does
that code look like?

Image display:

I am guessing that you are just drawing the pixels one-by-one on the PC.
That is far from efficient. You need to build up an in-memory image, called
a DIB, then blast the entire image to the screen in one operation. Much
faster!

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2000\12\27@073904 by Bob Ammerman

picon face
----- Original Message -----
From: Roman Black <@spam@fastvidKILLspamspamEZY.NET.AU>
To: <KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Wednesday, December 27, 2000 4:12 AM
Subject: [PIC]: PIC data via PC parallel port to screen


> > Subject: [PIC]: PIC data via PC parallel port to screen
> > Date: Wed, 27 Dec 2000 00:17:47 -0500
> > From: "David Pearson (SKYTRONICS)" <RemoveMEskytronTakeThisOuTspamHOME.COM>
> >
> > Hi,
> >         To all the PC programming experts a couple of questions.
> > I'm transferring data from a CCD image sensor for display on a PC via
the
> > parallel port.  Works fine, 8 bit gray scale. 400 x 280 pixels.  I'm
using a
> > F877 to transfer data to the PC using the parallel port in
Bi-directional
> > mode.  On the PC end, I'm using Delphi 5 with my own Assembly Portin,
> > Portout, Porttest routines.  Plotting pixels using the Plotxy functions.
> >
> > The problem, it's very slow.  It takes ~12 seconds to plot a frame on a
> > Pentium 120.  From what I've read, the maximum toggle rate I can expect
on
> > the parallel port is 500 nsec to 2 usecs, depending on what you read.
Even
> > so, I'm seeing times between setting a bit on the parallel port by the
F877
> > to the time the PC recognizes the signal of about 15 usecs.  Also,  the
> > plotting routine itself is slow, about 6 seconds to plot the 400 X 280
frame
> > when plotting a test grayscale pattern, no port IO, just incrementing
the
> > plot value.
> >
> > Does anyone have any ideas on how to speed things up?  I need a Windoze
> > 95/98 environment using either Delphi or VB.
> > Any ideas on how to speed up the data transfer?  Faster portIO?  Faster
> > Plotting in Delphi?
> > It seems crazy to me that my $5.00 PIC has to wait for a 120 MHz machine
to
> > do data transfers.  Is the Windoze environment that inefficient?
> >
> > Any ideas and help is appreciated and may be useful to other group
members.
{Quote hidden}

I take offense at this. 32bit Delphi uses the same code generator as
Borlands C++ Builder. If correctly written it can be as efficient as C++.

{Quote hidden}

The problem is that Win95, tho' it doesn't _prohibit_ port access, does
_virtualize_ it. The trick is probably to write a device driver for the
low-level I/O. The app could then call the driver to get a whole bunch of
pixels at once.

{Quote hidden}

Although Windows is far from RealTime (by most reasonable definitions
thereof), it really isn't too bad on efficiency: most of the raw CPU time is
availalble to your code, and properly written graphics operations can be
darned fast (take a look at Quake III Arena, for example).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2000\12\27@115406 by Herbert Graf

flavicon
face
> Does anyone have any ideas on how to speed things up?  I need a Windoze
> 95/98 environment using either Delphi or VB.
> Any ideas on how to speed up the data transfer?  Faster portIO?  Faster
> Plotting in Delphi?

    Hmm, I think the "trick" is to not plot to screen, plot to memory or a
file and then display the memory or file, I think the technique is called
paging.

> It seems crazy to me that my $5.00 PIC has to wait for a 120 MHz
> machine to
> do data transfers.  Is the Windoze environment that inefficient?

       Yes, Windows can be surprisingly inefficient if you don't use tricks to
make it more efficient. TTYL

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2000\12\27@133332 by Nigel Goodwin

flavicon
face
In message <RemoveME3A49B270.7DE1spamTakeThisOuTezy.net.au>, Roman Black <fastvidEraseMEspam.....EZY.NET.AU>
writes
>Firstly, I have only played with Delphi for a short while,
>as I don't like Pascal that much. It does seem to me that
>Delphi is very much a "idiot language". This almost always
>means; easy to make pretty screens but performs like shite.

Delphi is basically Turbo Pascal For Windows - with a pretty interface,
rather like a grown-up Visual Basic. It's pretty fast, although not
usually quite as fast as C - but it compiles much faster!.

{Quote hidden}

Any version of Delphi later than 1.0 (that is, any 32 bit version)
doesn't allow you to access the hardware directly (version 1.0 had the
Port() procedure) - so in order to do so you have to write a small piece
of in-line assembler code - this is freely available on the net, and
consists of a handful of op-codes. This then reads the port directly,
and doesn't wait for Windows to give permission - which is why it's not
included in 32 bit Delphi.

>I don't really have a solution for you, other than to
>start programming for a high performance environment
>(I am still making dos apps that run fabulously under
>Win 95) OR, try finding a windows programming expert
>who knows how to beg/force etc windows to give you
>better access to the port.

As he's already almost certainly accessing the port directly it seems
more likely it's a problem with his code - rather than a Windows
problem?.

>Having done many years of fast hardware/software
>interfacing with dos apps to the real world it never
>ceases to amaze me just how PATHETIC windows is at
>controlling anything more than a word processor.

It's not that fast as a word processor :-).
--

Nigel.

       /--------------------------------------------------------------\
       | Nigel Goodwin   | Internet : EraseMEnigelgspamlpilsley.co.uk           |
       | Lower Pilsley   | Web Page : http://www.lpilsley.co.uk       |
       | Chesterfield    | Official site for Shin Ki and New Spirit   |
       | England         |                 Ju Jitsu                   |
       \--------------------------------------------------------------/

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu


2000\12\27@150321 by Olin Lathrop

face picon face
> Any version of Delphi later than 1.0 (that is, any 32 bit version)
> doesn't allow you to access the hardware directly (version 1.0 had the
> Port() procedure) - so in order to do so you have to write a small piece
> of in-line assembler code - this is freely available on the net, and
> consists of a handful of op-codes. This then reads the port directly,
> and doesn't wait for Windows to give permission - which is why it's not
> included in 32 bit Delphi.

This won't work on all versions of Win32, and is very hardware specific.
The Win98 virtual machine might trap the reference and eventually do it for
you, but addressing protected memory on NT simply won't work.

The right way to do this is to write a parallel port device driver that
performs the operations you want, then call it thru the official CreateFile,
ReadFile, WriteFile, etc, interface.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinspam_OUTspamKILLspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu


2000\12\27@150633 by Wojciech Zabolotny

flavicon
picon face
On Wed, Dec 27, 2000 at 06:33:35PM +0000, Nigel Goodwin wrote:
>
> Any version of Delphi later than 1.0 (that is, any 32 bit version)
> doesn't allow you to access the hardware directly (version 1.0 had the
> Port() procedure) - so in order to do so you have to write a small piece
> of in-line assembler code - this is freely available on the net, and
> consists of a handful of op-codes. This then reads the port directly,
> and doesn't wait for Windows to give permission - which is why it's not
> included in 32 bit Delphi.
>
No way !!! The IO-permission mechanism in Windows uses the CPU hardware, so
it does not depend on the language (ASM vs Pascal). When the user (not "ring
0") program executes the "in" or "out" operation, an exception occures, the
kernel check wether this port is "virtualized" and either performs the
standard in/out or executes the dedicated procedure provided by the
appropriate VxD driver...
The only way to avoid this time consuming overhead is to write the device
driver, which is a piece of code which executes in the "ring 0" (like the
kernel).
This is true not only for Windows but for all "true" operating systems like
Uni*es (including Linux). However in Linux one may write the standard
program executing with root privileges, which can perform direct I/O without
loss of performance.
--
               HTH
               Wojciech Zabolotny
               EraseMEwzabspamspamspamBeGoneise.pw.edu.pl

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2000\12\27@160326 by David Pearson (SKYTRONICS)

picon face
Hi,
       I thought something like that was happening.  The question now is, how do I
write the device driver, in what language, using what tools?

 Any info on that is appreciated.
 Many thanks to all who have replied.
I've speeded up the plotting function using the SCANLINE command, even
though the image is compressed horizontally.  I'm still trying to figure
that out.

Again, Thanks

{Original Message removed}

2000\12\27@182424 by Olin Lathrop

face picon face
> No way !!! The IO-permission mechanism in Windows uses the CPU hardware,
so
> it does not depend on the language (ASM vs Pascal). When the user (not
"ring
> 0") program executes the "in" or "out" operation, an exception occures,
the
> kernel check wether this port is "virtualized" and either performs the
> standard in/out or executes the dedicated procedure provided by the
> appropriate VxD driver...

That works to some extent on Win95 and Win98.  NT and Win2000 (really NT 5)
will just crap your program if you try to access protected memory.  As you
mentioned, this is the way most "real" operating systems that have to deal
with security work.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinSTOPspamspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspamspamEraseMEmitvma.mit.edu


2000\12\27@182428 by Olin Lathrop

face picon face
>         I thought something like that was happening.  The question now is,
how do I
> write the device driver, in what language, using what tools?

This is not a simple task, but at least the Microsoft documentation is
reasonably good.  They pretty much force you to use their C/C++ compiler.

You might also get a generic driver that surfaces the interface to app
level.  I know there was a company providing something like that for the
parallel port.  I don't remember the name because I looked some of their
stuff a few years back.  They did have Win9x and NT drivers.

>  I've speeded up the plotting function using the SCANLINE command, even
> though the image is compressed horizontally.  I'm still trying to figure
> that out.

It still sounds like the graphics may be eating up most of the cycles.  Have
you tried calling the GDI layer directly?  Perhaps Delphi is doing something
strange in between.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, KILLspamolinspamBeGonespamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamEraseMEmitvma.mit.edu


2000\12\27@213137 by Bob Ammerman

picon face
> Any version of Delphi later than 1.0 (that is, any 32 bit version)
> doesn't allow you to access the hardware directly (version 1.0 had the
> Port() procedure) - so in order to do so you have to write a small piece
> of in-line assembler code - this is freely available on the net, and
> consists of a handful of op-codes. This then reads the port directly,
> and doesn't wait for Windows to give permission - which is why it's not
> included in 32 bit Delphi.

This is, unfortunately, not quite true. Although you can freely intersperse
direct I/O instructions in a Win32 executable on Win95/Win98/WinMe, those
instructions result in a trap the the 'virtual machine monitor' in Windows,
which virtualizes access to the hardware ports. This results in a
significant slowdown.

To get _real_ direct access to the ports you must use a device driver, even
in Win95/Win98/WinMe.

A device driver is required for any direct port access in WinNT/Win2000.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu


2000\12\27@213548 by Bob Ammerman

picon face
Windows device drivers are typically written in "C" or ASM. There are
toolkits available from third parties, or you can just go with the Microsoft
DDK.

Not easy, not fun, but a great feeling of satisfaction when it works.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2000\12\27@223448 by CrowKiller

flavicon
face
Bob Ammerman wrote :

> Windows device drivers are typically written in "C" or ASM. There are
> toolkits available from third parties, or you can just go with the Microsoft
> DDK.
>
> Not easy, not fun, but a great feeling of satisfaction when it works.
>
> Bob Ammerman
> RAm Systems
> (contract development of high performance, high function, low-level
> software)

Hi!

A friend of mine used the WinIo lib with great sucess!
he didn't have to write any device drivers,
Get it at
http://www.internals.com
(should work on win 95/98/NT/2000)

CrowKiller

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspam_OUTspammitvma.mit.edu


2000\12\27@234642 by Bob Ammerman

picon face
> A friend of mine used the WinIo lib with great sucess!
> he didn't have to write any device drivers,
> Get it at
> http://www.internals.com
> (should work on win 95/98/NT/2000)
>

I took a look at this. It looks great for low-rate access to the ports.
Unfortunately, it won't do too well for major whacking -- path lengths are
too long.

However, this is an excellent skeleton which you can extend.

The existing code performs a transition to ring 0 (Win9x/Me) or calls a
device driver (WinNT/2000) for every port I/O. You could add additional
options to the ring 0 code / device driver to perform much more processing
on one call. For example, you could read an entire scan line in one call,
staying in ring 0 / the device driver until the whole scan line (or N bytes)
has been read.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu


2000\12\28@002612 by Herbert Graf

flavicon
face
{Quote hidden}

    Can anybody point out how I would integrate this sort of thing into
Borland C Builder? I have no idea where even to start. Thanks, TTYL

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@012658 by Ray Gardiner

flavicon
face
>
>     Can anybody point out how I would integrate this sort of thing into
>Borland C Builder? I have no idea where even to start. Thanks, TTYL
>

Hmm, I would start with a VCL component that accesses the parallel port
and modify that to do what you want.

If you search the 'delphi32' type component sites on the net I expect that
there are a number of freeware port drivers with source you could use.

I think a good approach would be to have the component generate an event
when it had a chunk of data for you to handle, then you could write this
to a canvas in the foreground application.

Ray Gardiner TakeThisOuTrayKILLspamspamspamdsp.com.au
mail from: dsp systems

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@024826 by Nigel Goodwin

flavicon
face
In message <.....20001227205505.A1199spamRemoveMEwzab.nasz.dom>, Wojciech Zabolotny
<RemoveMEwzabspamspamBeGoneISE.PW.EDU.PL> writes
>No way !!! The IO-permission mechanism in Windows uses the CPU hardware, so
>it does not depend on the language (ASM vs Pascal). When the user (not "ring
>0") program executes the "in" or "out" operation, an exception occures, the
>kernel check wether this port is "virtualized" and either performs the
>standard in/out or executes the dedicated procedure provided by the
>appropriate VxD driver...
>The only way to avoid this time consuming overhead is to write the device
>driver, which is a piece of code which executes in the "ring 0" (like the
>kernel).
>This is true not only for Windows but for all "true" operating systems like
>Uni*es (including Linux). However in Linux one may write the standard
>program executing with root privileges, which can perform direct I/O without
>loss of performance.

You're talking about Windows NT, it works fine under 95, 98, and ME,
considering NT is very much a minority operating system only a small
percentage of user would have a problem with this. My 32 bit PIC
programmer uses a driver DLL so it works with NT, otherwise I would use
direct access just like the 16 bit version.
--

Nigel.

       /--------------------------------------------------------------\
       | Nigel Goodwin   | Internet : spamBeGonenigelg@spam@spamspam_OUTlpilsley.co.uk           |
       | Lower Pilsley   | Web Page : http://www.lpilsley.co.uk       |
       | Chesterfield    | Official site for Shin Ki and New Spirit   |
       | England         |                 Ju Jitsu                   |
       \--------------------------------------------------------------/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@024842 by Nigel Goodwin

flavicon
face
In message <TakeThisOuTNEBBKCNNOLLFJAHNBHJIOECCCBAA.skytronspamspamhome.com>, David
Pearson (SKYTRONICS) <skytronEraseMEspamHOME.COM> writes
>Hi,
>        I thought something like that was happening.  The question now is, how
>do I
>write the device driver, in what language, using what tools?

Just download a freeware one (assuming you are using Windows NT), bear
in mind it will be slower than direct access if you are not using NT!.
There's a link on my website to download the driver I use, it comes
complete with examples in C and Visual Basic.
--

Nigel.

       /--------------------------------------------------------------\
       | Nigel Goodwin   | Internet : RemoveMEnigelgEraseMEspamspam_OUTlpilsley.co.uk           |
       | Lower Pilsley   | Web Page : http://www.lpilsley.co.uk       |
       | Chesterfield    | Official site for Shin Ki and New Spirit   |
       | England         |                 Ju Jitsu                   |
       \--------------------------------------------------------------/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@025129 by Nigel Goodwin

flavicon
face
In message <001101c0703c$70393580$260bf6cd@pc>, Olin Lathrop
<@spam@olin_piclistRemoveMEspamEraseMEEMBEDINC.COM> writes
>> Any version of Delphi later than 1.0 (that is, any 32 bit version)
>> doesn't allow you to access the hardware directly (version 1.0 had the
>> Port() procedure) - so in order to do so you have to write a small piece
>> of in-line assembler code - this is freely available on the net, and
>> consists of a handful of op-codes. This then reads the port directly,
>> and doesn't wait for Windows to give permission - which is why it's not
>> included in 32 bit Delphi.
>
>This won't work on all versions of Win32, and is very hardware specific.
>The Win98 virtual machine might trap the reference and eventually do it for
>you, but addressing protected memory on NT simply won't work.

Yes, it won't work on NT, you must use a driver (I use DLPortIO.DLL),
but it works fine under 95, 98, and ME.

>The right way to do this is to write a parallel port device driver that
>performs the operations you want, then call it thru the official CreateFile,
>ReadFile, WriteFile, etc, interface.

But that slows everything done massively, this thread was about reading
data via the parallel port being slow!.
--

Nigel.

       /--------------------------------------------------------------\
       | Nigel Goodwin   | Internet : EraseMEnigelgspam@spam@lpilsley.co.uk           |
       | Lower Pilsley   | Web Page : http://www.lpilsley.co.uk       |
       | Chesterfield    | Official site for Shin Ki and New Spirit   |
       | England         |                 Ju Jitsu                   |
       \--------------------------------------------------------------/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@040141 by Bill Westfield

face picon face
   Just download a freeware one (assuming you are using Windows NT), bear
   in mind it will be slower than direct access if you are not using NT!.

Just how much slower ARE the virtualized drivers, anyway?  Half the people
are talking like they'll slow your whole application to a crawl, while I'd
think that as long as the execution times are smaller than the typical time
of an event, it wouldn't matter much.  (Someone's application WAS slowed to
a crawl - I'd more likely suspect the graphic output as other have
suggested.  My MAC Netscape will hang up my system if it encounters a web
page that has a one-pixel image specified as a background, as it draws each
pixel individually painfully and sloooooowly...)

BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@064426 by Bob Ammerman

picon face
>      Can anybody point out how I would integrate this sort of thing into
> Borland C Builder? I have no idea where even to start. Thanks, TTYL

The device driver component, which as far as I can tell is only used in the
NT/2000 case, requires Microsoft's DDK and would probably be difficult to
build with any compiler other than VC.

The DLL component could probably be relatively easily built using BC
Builder. In fact, the code that is in the DLL could even just be included
directly into a BC Builder project (probably with some minor modifications),
eliminating the need for a separate DLL.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@065048 by Bob Ammerman

picon face
> In message <@spam@20001227205505.A1199spam_OUTspam.....wzab.nasz.dom>, Wojciech Zabolotny
> <spamBeGonewzabEraseMEspamISE.PW.EDU.PL> writes
> >No way !!! The IO-permission mechanism in Windows uses the CPU hardware,
so
> >it does not depend on the language (ASM vs Pascal). When the user (not
"ring
> >0") program executes the "in" or "out" operation, an exception occures,
the
> >kernel check wether this port is "virtualized" and either performs the
> >standard in/out or executes the dedicated procedure provided by the
> >appropriate VxD driver...
> >The only way to avoid this time consuming overhead is to write the device
> >driver, which is a piece of code which executes in the "ring 0" (like the
> >kernel).
> >This is true not only for Windows but for all "true" operating systems
like
> >Uni*es (including Linux). However in Linux one may write the standard
> >program executing with root privileges, which can perform direct I/O
without
> >loss of performance.

> You're talking about Windows NT, it works fine under 95, 98, and ME,
> considering NT is very much a minority operating system only a small
> percentage of user would have a problem with this. My 32 bit PIC
> programmer uses a driver DLL so it works with NT, otherwise I would use
> direct access just like the 16 bit version.

NOT TRUE! Win95/Win98/WinMe _DO_ trap port I/O for virtualization. It is
just that for many cases (ie: parallel port) they simulate the I/O and allow
it to complete. This is _SLOW_.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@065259 by Bob Ammerman

picon face
----- Original Message -----
From: Nigel Goodwin <nigelgspamBeGonespamLPILSLEY.CO.UK>
To: <RemoveMEPICLIST@spam@spamspamBeGoneMITVMA.MIT.EDU>
Sent: Thursday, December 28, 2000 2:42 AM
Subject: Re: [PIC]: PIC data via PC parallel port to screen


> In message <001101c0703c$70393580$260bf6cd@pc>, Olin Lathrop
> <.....olin_piclist@spam@spamEraseMEEMBEDINC.COM> writes
> >> Any version of Delphi later than 1.0 (that is, any 32 bit version)
> >> doesn't allow you to access the hardware directly (version 1.0 had the
> >> Port() procedure) - so in order to do so you have to write a small
piece
> >> of in-line assembler code - this is freely available on the net, and
> >> consists of a handful of op-codes. This then reads the port directly,
> >> and doesn't wait for Windows to give permission - which is why it's not
> >> included in 32 bit Delphi.
> >
> >This won't work on all versions of Win32, and is very hardware specific.
> >The Win98 virtual machine might trap the reference and eventually do it
for
> >you, but addressing protected memory on NT simply won't work.
>
> Yes, it won't work on NT, you must use a driver (I use DLPortIO.DLL),
> but it works fine under 95, 98, and ME.
>
> >The right way to do this is to write a parallel port device driver that
> >performs the operations you want, then call it thru the official
CreateFile,
> >ReadFile, WriteFile, etc, interface.
>
> But that slows everything done massively, this thread was about reading
> data via the parallel port being slow!.

It won't be slow if the driver does more than a single port access per call
to the driver. You need to write your own custom driver to do this.

I did hear of a driver that would interpret a byte-code program that could
be sent from the application, but I don't know if it really exists or what
it is called.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@090531 by Olin Lathrop

face picon face
> >The right way to do this is to write a parallel port device driver that
> >performs the operations you want, then call it thru the official
CreateFile,
> >ReadFile, WriteFile, etc, interface.
>
> But that slows everything done massively, this thread was about reading
> data via the parallel port being slow!.

There is no reason it needs to be slow.  I wouldn't want to pass individual
bytes with separate calls, but the app probably doesn't need that anyway.
The device driver should be able to deal with a buffer full of bytes at a
time.

Of course, if you really want to go fast you should:

1  -  Get a separate parallel port card that can do DMA.  This allows a
properly written device driver to maximize the speed with minimal CPU
overhead.

2  -  Don't use a parallel port.  I don't remember how many bytes/second the
original problem needed, but parallel ports can only go so fast.  After that
you could look into SCSI perhaps, althoug it's a lot more complicated.

A few years back a customer needed to get raw data in/out of an NT system to
a custom device.  We ended up using DR11W.  It's rather ugly, but that
didn't matter since it was all encapsulated from the end user's point of
view.  DR11W is very easy to interface to, and we got several MBytes/sec.  I
did have to write an NT kernel mode device driver for the card, but this
also proves that these things don't need to be slow.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinRemoveMEspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@122739 by David Pearson (SKYTRONICS)

picon face
Hi,
       Let me clarify the application a bit.  The PIC based unit is transmitting
video from a CCD (a CCD for a astronomical camera) to computers that someone
may already have, a printer port or USB.  The transfer time must be
minimized to get as fast a frame rate as possible.  The only viable
alternative to the parallel ports is a full speed USB interface.  I've been
looking at the new PIC micro with USB, but it seems to be a low speed USB
interface suitable for a mouse or keyboard.  The second generation unit will
most likely be full speed USB.  As the project stands now, I'm getting a 4
second transfer via the parallel port.  With the current hardware, A/D
converter, signal conditioning, the best rate I could expect is about 15usec
per pixel.  Right now I'm getting a little less than 30 usec.  The delays
are now in the bit toggling and reading by the PC from the parallel port.
The frame transfer time of 4 seconds vs 2 seconds is not really important
when capturing the imaged frame ( an extra 2 seconds after a image
integration time of 10 minutes doesn't matter much), but it is important
when in the focusing mode.  While focusing you need to see the image quickly
as you turn the focus knob.

Again, thanks to you all for your help and suggestions.

Regards,
Dave

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@124815 by severson

flavicon
face
David,

I'd pass on the USB PIC solution and go with a full speed device
(http://usbsimm.home.att.net) for USB. What is your desired data rate in
bits/sec? Are you trying to make a transfer of video in a closed format to a
custom application, or "regular" video that windows understands?

-Robert Severson
http://usbsimm.home.att.net
http://www.jged.com
http://www.annatechnology.com

> {Original Message removed}

2000\12\28@143938 by Nigel Goodwin

flavicon
face
In message <.....NEBBKCNNOLLFJAHNBHJIMEDHCBAA.skytronSTOPspamspam@spam@home.com>, David
Pearson (SKYTRONICS) <skytronEraseMEspam@spam@HOME.COM> writes
>Hi,
>        Let me clarify the application a bit.  The PIC based unit is
>transmitting
>video from a CCD (a CCD for a astronomical camera) to computers that someone
>may already have, a printer port or USB.  The transfer time must be
>minimized to get as fast a frame rate as possible.  The only viable
>alternative to the parallel ports is a full speed USB interface.  I've been
>looking at the new PIC micro with USB, but it seems to be a low speed USB
>interface suitable for a mouse or keyboard.  The second generation unit will
>most likely be full speed USB.  As the project stands now, I'm getting a 4
>second transfer via the parallel port.  With the current hardware, A/D
>converter, signal conditioning, the best rate I could expect is about 15usec
>per pixel.  Right now I'm getting a little less than 30 usec.  The delays
>are now in the bit toggling and reading by the PC from the parallel port.
>The frame transfer time of 4 seconds vs 2 seconds is not really important
>when capturing the imaged frame ( an extra 2 seconds after a image
>integration time of 10 minutes doesn't matter much), but it is important
>when in the focusing mode.  While focusing you need to see the image quickly
>as you turn the focus knob.

I've just tried how fast I can read from my parallel port under Windows
98 SE using a driver DLL, I managed 100,000 reads in 120mS - however,
this was just sequential reads, no handshaking or waiting for data to
become valid. My machine is a Celeron 667 overclocked at 720MHz using
EasyTune III.
--

Nigel.

       /--------------------------------------------------------------\
       | Nigel Goodwin   | Internet : RemoveMEnigelgspamspamBeGonelpilsley.co.uk           |
       | Lower Pilsley   | Web Page : http://www.lpilsley.co.uk       |
       | Chesterfield    | Official site for Shin Ki and New Spirit   |
       | England         |                 Ju Jitsu                   |
       \--------------------------------------------------------------/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@190103 by Peter L. Peres

picon face
>Hi,
>        To all the PC programming experts a couple of questions.
>I'm transferring data from a CCD image sensor for display on a PC via the
>parallel port.  Works fine, 8 bit gray scale. 400 x 280 pixels.  I'm using

400*280 = 112E3

you need at least two IO operations to get the data from IO assuming
no hardware handshake == 224E3 operations. A picture should come through
in one second, at most.

>speed up software

Cut your aquisition and display routines up, into parts. Use a tight loop
to read data (preferrably written in assembly and linked into your
project) into an array and then display it later. I don't know about
Delphi but for high speed aquisition and display usually one investigates
the exact nature of the visual window (the image displayed) and converts
the array of data on the fly (by manipulating the aquisition code) to
that, then displays it using native functions, as a stored image (not
plotting). This is the very rough idea of it. And then you use a profiler
to profile your code until it is not worth profiling anymore.

Plotting is almost always expensive unless you are using a fast plotting
library that uses integer arithmetic and evil shortcuts (like Bresenham
algorythms) to plot directly into the frame store buffer. This requires
direct access to the frame buffer in the first place (like using DirectX
functions under Windows for example, or DGX and other things under X11).

good luck,

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\28@190131 by Peter L. Peres

picon face
>what tools, what language

On Windows, get a book about VxD drivers (I don't remember the exact
title. There are two, one for NT and one for normal Windows I think).
Language is almost invariably C or C++ (using only the C subset for direct
IO related parts) with some assembly sometimes needed (inline assembly
handled by the C compiler for you normally). The book and experience are
essential imho because VxD development invariably means restarting the
machine after every compile/build and that crashes will be bad. The best
configuration is a networked machine with a bare bones Windows
installation that is used for testing only. Development is done somewhere
else.

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\29@084201 by Olin Lathrop

face picon face
> Plotting is almost always expensive unless you are using a fast plotting
> library that uses integer arithmetic and evil shortcuts (like Bresenham
> algorythms) to plot directly into the frame store buffer. This requires
> direct access to the frame buffer in the first place (like using DirectX
> functions under Windows for example, or DGX and other things under X11).

You don't need to use DirectX to get high speed vector drawing.  Vector
generation is always done in hardware nowadays (and has been for mid range
systems for 15 years).  The basic GDI layer will do a plenty good enough job
of driving the hardware to draw vectors for you.

However, the problem is blasting pixels to the display, not vectors.  With
the generic GDI interface, you do this by setting up a software bitmap, then
you copy pixels from the software bitmap to the display with a single call.
There is some overhead in setting up the hardware to receive pixels from the
processor, so you don't want to do this every pixel.  Every scan line or
every 8 or 16 scan lines will be fine.  I suggest reading 8 scan lines at a
time from the device and copying them to the display at one time.  At that
level, it will take a small fraction of a second for the pixel copies for
the entire image.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spamBeGoneolinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\29@093602 by Bob Ammerman

picon face
> However, the problem is blasting pixels to the display, not vectors.  With
> the generic GDI interface, you do this by setting up a software bitmap,
then
> you copy pixels from the software bitmap to the display with a single
call.
> There is some overhead in setting up the hardware to receive pixels from
the
> processor, so you don't want to do this every pixel.  Every scan line or
> every 8 or 16 scan lines will be fine.  I suggest reading 8 scan lines at
a
> time from the device and copying them to the display at one time.  At that
> level, it will take a small fraction of a second for the pixel copies for
> the entire image.

In the windows world, a lot of the delay is just going thruough all the
layers of the system to get to the video card device driver. Just think
about it:

- You issue a GDI call SetPixel(hdc,x,y,color)

- The generic GDI code gets control

- It has to figure out if your x,y values are in the current clipping region

- It has to figure out how to represent your color in the current
environment (maybe finding a palette entry if you are not in a high/true
color device).

- If has to map your x,y value from 'world' to 'device' coordinates.

- It has to find the correct driver for your video and pass it the SetPixel
arguments.

- The driver has to make sure the x,y values are valid

- The driver has to map the x,y values to the correct screen location

- The driver has to set up the hardware to draw the pixel

- The driver has to stash in the pixel

That's an awful lot of processing behind an 'innocent' SetPixel() call!

Much of this can be amortized over many pixels if you first build an image
in memory and then blast it to the driver in one call.

Even one scan line at a time will reduce the overhead by a factor of N,
where N is the number of pixels in the scan line.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\29@120837 by Olin Lathrop

face picon face
> On Windows, get a book about VxD drivers (I don't remember the exact
> title. There are two, one for NT and one for normal Windows I think).

VxD drivers are only for Win9x.  For NT you need to write a kernel mode
device driver.  The two are very different.  The newer versions of Win9x
have facilities for drivers that are similar to the NT model.

As far as books, there is nothing like the definative source, which is the
Microsoft DDK.  Most of the books I've seen on this subjet are just
regurgitated versions of the DDK with more hand holding.  Sorta like "Device
drivers for dummies".  Frankly, if your at that level you shouldn't be
trying to write a device driver.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinspam_OUTspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\29@185621 by Peter L. Peres

picon face
>I've just tried how fast I can read from my parallel port under Windows
>98 SE using a driver DLL, I managed 100,000 reads in 120mS - however,
>this was just sequential reads, no handshaking or waiting for data to
>become valid. My machine is a Celeron 667 overclocked at 720MHz using
>EasyTune III.

Owww... I remember my XT8088 clone did 200,000/sec and 486 with DOS6.x
600,000.

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\29@191643 by Dan Michaels

flavicon
face
At 07:03 PM 12/29/00 +0200, you wrote:
>>I've just tried how fast I can read from my parallel port under Windows
>>98 SE using a driver DLL, I managed 100,000 reads in 120mS - however,
>>this was just sequential reads, no handshaking or waiting for data to
>>become valid. My machine is a Celeron 667 overclocked at 720MHz using
>>EasyTune III.
>
>Owww... I remember my XT8088 clone did 200,000/sec and 486 with DOS6.x
>600,000.
>

About 4 years ago, I wrote an assembly program under DOS that could
transfer 300,000 nybbles/sec over the parallel port. It assembled
3 nybbles into 12-bit data on the fly, no handshaking, but did poll
data_valid bit. 486DX-33 [dark ages of clock speed].

Let's see 100,000/.12sec = 833,000/sec
720mhz/33 = 21.8 faster
21.8 * 2[speedup fudge factor] = 43.6
300,000/sec*43.6 = 13,080,000/sec

13,080,000/Win98 = 833,000/sec - yep, sounds about right.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\29@203033 by Mark S.

flavicon
face
What driver DLL did you use?

Mark

At 07:16 PM 12/29/00 -0500, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\29@214426 by Bill Westfield

face picon face
   >I've just tried how fast I can read from my parallel port under Windows
   >98 SE using a driver DLL, I managed 100,000 reads in 120mS - however,
   >this was just sequential reads, no handshaking or waiting for data to
   >become valid. My machine is a Celeron 667 overclocked at 720MHz using
   >EasyTune III.

   Owww... I remember my XT8088 clone did 200,000/sec and 486 with DOS6.x
   600,000.

Um.  It DOESN'T MATTER.  Unless the events that you're polling for occur on
a timescale smaller than 10 microseconds or so, the difference between a
theoretical 1E6 reads/sec in "raw" mode vs 800,000 reads/second virtualized
is completely irrelevant - you'll just do fewer "read" instructions in your
spin loop, and of course it will all be completely dwarfed by the timescales
involved if your windows process gets suspended in favor of some other
process...

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\29@215908 by Dan Michaels

flavicon
face
No DLLs with DOS, just coded assembler code for specific app.
Point is, back in the days of DOS, you could actually control
your machine without Windows getting in the way. Course, some
do like it the new way, too.
=======


At 06:19 PM 12/29/00 -0700, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\29@235922 by Bill Westfield

face picon face
Let's see 100,000/.12sec = 833,000/sec
   720mhz/33 = 21.8 faster
   21.8 * 2[speedup fudge factor] = 43.6
   300,000/sec*43.6 = 13,080,000/sec

   13,080,000/Win98 = 833,000/sec - yep, sounds about right.

Oh come on.  You KNOW that the multi-MHz processors only have a hope of
running at that speed when they're able to keep their pipeline full, which
means executing direct from cache using only internal (to CPU/cache/etc)
variables.  Explicitly touch ANYTHING external (like an IO port) and you're
immediately slowed down to AT LEAST the bus clock speed (66 to 100 MHz for
an overclocked celeron, probably.)  Since the parallel IO port is out on
a "distant" (ISA, after all) chip far from the fast busses (ie memory bus,
agp bus), it's probably considerably slower than 15ns (66MHz.)

Now, back in the days of 486s, you didn't get such a clearly painted picture
of the memory or IO bus speeds in a computer (since the memory bus wasn't
synchronous), but I seem to recall that 33MHz systems typically used 60nS
memory, which makes a modern memory bus only "about" 4 times faster than
the old systems (neglecting that 60ns dram didn't cycle in 60ns any more
than 66MHz memory gives you data in 15ns all the time...)

CPUs have been IO limitted by their bus speeds (rather than clock speeds)
since LONG before the 33MHz 486s.  An early TCP/IP performance study on
SUN3s noticed that a LOT of time was being wasted by the DMA controller in
the AMD LANCE taking a relative eternity (6 cycles at 10MHz - 600ns?) to do
memory accesses on the (shared) memory bus.  That was the same timeframe as
Intel 286's.  (router vendors subsequently went to some trouble to make the
memory bus someone less evenly "shared.")

(incidentally, this is one of the big advantages of microCONTROLLERS.  Since
data and program memory are on-chip, they are very fast, and usually NOT the
limitting factor for overall performance.)

(I think it's time to move this thread to [EE] ?)

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\30@013134 by Dan Michaels

flavicon
face
BillW wrote:
>Let's see 100,000/.12sec = 833,000/sec
>    720mhz/33 = 21.8 faster
>    21.8 * 2[speedup fudge factor] = 43.6
>    300,000/sec*43.6 = 13,080,000/sec
>
>    13,080,000/Win98 = 833,000/sec - yep, sounds about right.
>
.......
Since the parallel IO port is out on
>a "distant" (ISA, after all) chip far from the fast busses (ie memory bus,
>agp bus), it's probably considerably slower than 15ns (66MHz.)
>

Yeah, I know, but the numbers still look good anyway. I think
that's a good equation - take "anything", divide it by Win98,
and realize a 15:1 slowdown.

Next go around, DOS will cease to exist anyways, and Roman
will have to retire. Me, I'm moving to the Palm - just think
of it like the PC before Windows.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\30@015039 by Nigel Goodwin

flavicon
face
In message <spamBeGone1.5.4.16.20001229171323.2bafeb70@spam@spampop.dnvr.uswest.net>, Dan
Michaels <RemoveMEoricomEraseMEspamKILLspamUSWEST.NET> writes
>About 4 years ago, I wrote an assembly program under DOS that could
>transfer 300,000 nybbles/sec over the parallel port. It assembled
>3 nybbles into 12-bit data on the fly, no handshaking, but did poll
>data_valid bit. 486DX-33 [dark ages of clock speed].
>
>Let's see 100,000/.12sec = 833,000/sec
>720mhz/33 = 21.8 faster
>21.8 * 2[speedup fudge factor] = 43.6
>300,000/sec*43.6 = 13,080,000/sec
>
>13,080,000/Win98 = 833,000/sec - yep, sounds about right.

Yep :-).

I was in a computer shop a few weeks ago, I was amused to see they still
ran their stock database under DOS - undoubtedly many times faster than
a Windows database, and doesn't keep crashing either!.
--

Nigel.

       /--------------------------------------------------------------\
       | Nigel Goodwin   | Internet : spamBeGonenigelgspam_OUTspamRemoveMElpilsley.co.uk           |
       | Lower Pilsley   | Web Page : http://www.lpilsley.co.uk       |
       | Chesterfield    | Official site for Shin Ki and New Spirit   |
       | England         |                 Ju Jitsu                   |
       \--------------------------------------------------------------/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\30@015724 by Nigel Goodwin

flavicon
face
In message <200012291819532.SM00122@markdesk>, Mark S.
<.....markslspamRemoveMEUSWEST.NET> writes
>What driver DLL did you use?
>
>Mark
>
>At 07:16 PM 12/29/00 -0500, you wrote:
>>At 07:03 PM 12/29/00 +0200, you wrote:
>>>>I've just tried how fast I can read from my parallel port under Windows
>>>>98 SE using a driver DLL, I managed 100,000 reads in 120mS - however,
>>>>this was just sequential reads, no handshaking or waiting for data to
>>>>become valid. My machine is a Celeron 667 overclocked at 720MHz using
>>>>EasyTune III.

DLPortIO, there's a link to download it from my website.
--

Nigel.

       /--------------------------------------------------------------\
       | Nigel Goodwin   | Internet : nigelgspam@spam@lpilsley.co.uk           |
       | Lower Pilsley   | Web Page : http://www.lpilsley.co.uk       |
       | Chesterfield    | Official site for Shin Ki and New Spirit   |
       | England         |                 Ju Jitsu                   |
       \--------------------------------------------------------------/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\30@055736 by Roman Black

flavicon
face
Nigel Goodwin wrote:

> I was in a computer shop a few weeks ago, I was amused to see they still
> ran their stock database under DOS - undoubtedly many times faster than
> a Windows database, and doesn't keep crashing either!.


Ditto, I was in a branch of a large video rental chain,
they use dos based database system for the movies, when I
commented on it the young guy told me "yep, it's nice
to click on anything and it happens instantly"!
They won't even allow Windows on their machines, and no
they never crash either. Good software doesn't crash!
-Roman

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\30@115602 by Dan Michaels

flavicon
face
At 06:19 PM 12/29/00 -0700, you wrote:
>What driver DLL did you use?
>

You might find a usable LPT driver here:

http://solo.abac.com/dllarchive/
http://www.dllsearch.com/
http://dllstar.hypermart.net/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\30@120149 by Peter L. Peres

picon face
>Frankly, if your at that level you shouldn't be
>trying to write a device driver.

Thank you for the advice, but it is too late. ;-)

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\30@120204 by Peter L. Peres

picon face
>fast IO on PC in general

My older idea of building a custom breakout SIMM to be plugged into a free
SIMM socket and addressed as a single writable RAM location becomes more
and more interesting... Let's see, 4 x 74S573 and a simple decode logic to
pulse CLK when (each) /WE*/CAS is asserted. Hmmm. For read-in 4 x 74S573
with /OEs pulsed when (each) /CASE*//WE. I think that the byte select
signals need some more thinking but that should be it. If done in SMD it
would fit any PC.

A 2*32 + plenty of ground wire connection run to a connector mounted on
the PC casing.

Any objections ?

Does anyone know if it is possible to make a chipset recognize and map
memory that is not there ? (I am not assuming Windows OS - just in
general)

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\30@121819 by Olin Lathrop

face picon face
> My older idea of building a custom breakout SIMM to be plugged into a free
> SIMM socket and addressed as a single writable RAM location becomes more
> and more interesting... Let's see, 4 x 74S573 and a simple decode logic to
> pulse CLK when (each) /WE*/CAS is asserted. Hmmm. For read-in 4 x 74S573
> with /OEs pulsed when (each) /CASE*//WE. I think that the byte select
> signals need some more thinking but that should be it. If done in SMD it
> would fit any PC.
>
> A 2*32 + plenty of ground wire connection run to a connector mounted on
> the PC casing.
>
> Any objections ?

Sounds theoritically doable, but a number of problems come to mind:

1  -  You need to make sure that your "memory" doesn't respond in such a way
that the system thinks there is real memory out there.  I don't know what
procedure the system uses to determine this.  It may even vary from bios to
bios to OS to OS.

2  -  If you get past #1, then accessing it will still be tricky.  Since the
system won't think there is memory there, it won't build page table entries.
This means your memory will be inaccessible when paging is enable.  A device
driver at high priveledge level would need to disable virtual memory, access
the physical location, then re-enable virtual memory.  It probably needs to
disable interrupts while doing this because the system interrupt code
probably assume virtual memory is enabled.

3  -  Make sure the dynamic RAM refreshes don't get you.  I've never looked
into the details of the PC memory architecture, but there has to be some
mechanism to refresh the dynamic RAMs normally.  This is probably not done
autonomously on the SIMMs.  Whatever mechanism this is, it may not limit
itself to the address range of whatever the system thinks the extent of real
memory is.  If all this is true (I don't know, just speculating), then you
have to make sure to detect refresh versus other access in order to ignore
the refresh.

I'd like to hear how this stuff really works when you find out.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, EraseMEolinRemoveMEspamSTOPspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\30@173721 by Bill Westfield

face picon face
>>  fast IO on PC in general
>
>    My older idea of building a custom breakout SIMM to be plugged into a free
>    SIMM socket and addressed as a single writable RAM location becomes more
>    and more interesting.

Well, the remaining problem is at the sort of frequencies present in a RAM
subsystem, or even at the frequencies currently POSSIBLE on a normal IO port
(even virtualized IO ports), you have to start DESIGNING the WIRES you
connect to them if you don't want to become a radio designer rather than a
digitial designer...  I figure I trust normal wires up to about 100khz, so
sampling much faster than that has little value.  If you really need to go
much faster than that, it's time to start looking at actual io designs where
someone else has done all the hard and annoying work (USB, Ethernet, V.35,
RS423, SCSI, firewire, etc...)  (Unfortunately, many of these lack existing
chip designs that are easy to connect to the average embedded processor, or
most embedded processors lack embedded peripherals of this speed range, but
that seems to be changing...)

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\31@143218 by Peter L. Peres

picon face
Hi Olin,

1. The BIOS necessarily checks the memory by doing a
read-and-write-and-read test. This may output garbage on my output port
but I can deal with this (using a magic key or a timer). It will not
likely recognize the area as ram (the output port will not be
back-readable).

2. The system does not think, the BIOS thinks. I have a Linux driver in
view, and only for chipsets with published datasheets. This means, that I
do not care what the BIOS thinks, as I will do the thinking later, when
loading the driver module, and fudge the chipset paging registers as
required to map the port somewhere. I have done this before with strangely
mapped FLASH ROM (dockable) so I know the ropes a little bit.

3. Dynamic refresh is usually RAS-only refresh. Since I decode CAS and WE
for triggering on output and input, I do not need to be afraid of it. It
will upset the timing but that is a small price to pay for what I can
gain.

4. There is a problem with burst accessed RAM and cached reads. My driver
will have to explicitly flush the cache before and after each access to
the IO-SIMM (see, it has a name already). This can be a problem, but it is
still minor (latency in the low hundreds of nanoseconds probably).

I will keep the list posted but do not hold your breath ;-) So many toys,
so little time...

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservKILLspamspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2000\12\31@150817 by Peter L. Peres

picon face
>wires that require broadcast licenses

I know 2 or 3 things about those ;-). The idea is to put all the fast
hardware on the SIMM as SMD and run a SCSI flatcable to other devices that
are to be attached. I do not expect the frequency to go over 50MHz in ANY
case on this external bus and I plan to use terminated lines over
flatcable (common ground) and line buffer/drivers meant for 100MHz.

The first experiment will be done with 'old' SIMMs in a 386 system so
speed will be less of a problem, and I will get a feel of the real
problems (I hope).

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body



'[PIC]: PIC data via PC parallel port to screen'
2001\01\01@170610 by Bob Ammerman
picon face
----- Original Message -----
From: Olin Lathrop <RemoveMEolin_piclistspam_OUTspamEMBEDINC.COM>
To: <PICLISTspamspamMITVMA.MIT.EDU>
Sent: Saturday, December 30, 2000 12:20 PM
Subject: Re: [PIC]: PIC data via PC parallel port to screen


> > My older idea of building a custom breakout SIMM to be plugged into a
free
> > SIMM socket and addressed as a single writable RAM location becomes more
> > and more interesting... Let's see, 4 x 74S573 and a simple decode logic
to
{Quote hidden}

way
> that the system thinks there is real memory out there.  I don't know what
> procedure the system uses to determine this.  It may even vary from bios
to
> bios to OS to OS.

This will certainly vary from system to system, but I imagine it wouldn't be
do difficult to come up with an implementation that is misdetected.

More difficult is getting the chipset to map the socket into some physical
address range. Normally the BIOS detects the memory complement at boot and
programs the chipset accordingly. You'd have to tweak the chipset config
post boot, which may or may not be possible, and is certainly difficult and
certainly different for every chipset.

> 2  -  If you get past #1, then accessing it will still be tricky.  Since
the
> system won't think there is memory there, it won't build page table
entries.
> This means your memory will be inaccessible when paging is enable.  A
device
> driver at high priveledge level would need to disable virtual memory,
access
> the physical location, then re-enable virtual memory.  It probably needs
to
> disable interrupts while doing this because the system interrupt code
> probably assume virtual memory is enabled.

This is actually pretty easy. Most (if not all) virtual memory OS's allow
you to create a mapping to an arbitrary phyiscal address, if you have a high
enough priviledge level. The OS will build the needed page table entries in
response to your request to map the physical address.

> 3  -  Make sure the dynamic RAM refreshes don't get you.  I've never
looked
> into the details of the PC memory architecture, but there has to be some
> mechanism to refresh the dynamic RAMs normally.  This is probably not done
> autonomously on the SIMMs.  Whatever mechanism this is, it may not limit
> itself to the address range of whatever the system thinks the extent of
real
> memory is.  If all this is true (I don't know, just speculating), then you
> have to make sure to detect refresh versus other access in order to ignore
> the refresh.

I think modern PC memory is at least 'semi-autonomous' on refresh, but does
use a certain sequencing of control signals. This SIMM/DIMM wouls have to be
aware of that.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestspam_OUTspamspam_OUTmitvma.mit.edu


2001\01\02@082156 by Alan B. Pearce

face picon face
There is a driver available on the net to access hardware direct on windows
machines when running 32 bit op systems, even winNT. I believe it is based on an
article written in Dr Dobbs journal a few years ago on how to access the
hardware direct by allowing a window to be set in the hardware access bits that
the processor uses to stop the access. It is called "PortNT" or "Port95" if I
remember correctly.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...