BartC <bc@freeuk.com> wrote:
> "David Brown" <david@westcontrol.removethisbit.com> wrote in message 
> news:GfednVgK54qnxVnMnZ2dnUVZ8i2dnZ2d@lyse.net...
> > On 21/06/13 14:43, BartC wrote:
> 
> >> That partly worked, until it came to the
> >> terminal and keyboard capabilities I needed for my editor, but Linux
> >> terminal/keyboard handling was too crude.
> >>
> >
> > Linux terminal/keyboard handling was "too crude" ?  I haven't heard that
> > one before.  Hands up those that can type "Anton?n Dvo??k" on a Windows
> > keyboard without using "character map".  I can't see many reasons why
> > you want want something more than ASCII for programming, but there you go.
> 
> You want to end up with ASCII *character* codes for source code. But editors 
> rely on *key* code and modifier (shift, ctrl and alt) combinations in order 
> to get there!

Well behaved text mode Linux editor _does not_ depend on key codes.
They depend on translations done by kernel.  The translations
are setable and allow user lot of customizaton.  But if you want
you want to dig into key codes, it is possible: /dev/input/event*
device file give you access to low level information.
 
> Linux, using console mode, tries to return such combinations as a stream of 
> ASCII characters. That means complex multi-character sequences for 
> non-printable keys, but only some combinations are allowed, and half of 
> those have pre-existing special uses. The codes are also all over the place 
> with many inconsistencies, with sequences of different lengths too. It's a 
> mess. (I don't know what it's like using 'X', but I'm not attempting 
> graphics at the moment).

This is comples, but if handled properly allows user input/output
on wide range of devices.  The tivial example is using serial
port for full screen operation (useful for debugging).

> There is a library called 'ncurses', but I've tried it and it doesn't really 
> help, and it's also intrusive.

It take some time to find out how things are done.  There are
some capabilites that terminal have (or does not have).
'ncurses' allows you to test which capabilities terminal
has and to use them.  'ncurses' is written with abstract
view of terminals (which apparently you dislike) but
otherwise is not intrusive: 'ncurses' offers you several
functions which go beyond basics and assume specific way
of termianl handling, but you are free to ignore them
and just stay with basics.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:GfednVgK54qnxVnMnZ2dnUVZ8i2dnZ2d@lyse.net...
> On 21/06/13 14:43, BartC wrote:

>> That partly worked, until it came to the
>> terminal and keyboard capabilities I needed for my editor, but Linux
>> terminal/keyboard handling was too crude.
>>
>
> Linux terminal/keyboard handling was "too crude" ?  I haven't heard that
> one before.  Hands up those that can type "Anton&iacute;n Dvo&#345;&aacute;k" on a Windows
> keyboard without using "character map".  I can't see many reasons why
> you want want something more than ASCII for programming, but there you go.

You want to end up with ASCII *character* codes for source code. But editors 
rely on *key* code and modifier (shift, ctrl and alt) combinations in order 
to get there!

Linux, using console mode, tries to return such combinations as a stream of 
ASCII characters. That means complex multi-character sequences for 
non-printable keys, but only some combinations are allowed, and half of 
those have pre-existing special uses. The codes are also all over the place 
with many inconsistencies, with sequences of different lengths too. It's a 
mess. (I don't know what it's like using 'X', but I'm not attempting 
graphics at the moment).

There is a library called 'ncurses', but I've tried it and it doesn't really 
help, and it's also intrusive.

(I've spent the last week or so trying again with Linux, on three different 
systems, and getting nowhere with problem after problem, mostly trying to 
get the OS to work properly, and that's even before I get to my own 
problems!)

-- 
Bartc 

Just in case you are open to using something a bit faster, here is one 
of the type of devices I was referring to.  I haven't tried this, but I 
am pretty sure it will do a lot better than 100 bytes/sec.

It uses an FTDI USB chip to interface to a Microchip MCU.  The MCU is 
pre-programmed to let you twiddle bits on a number of pins to output or 
input and even has an 8 bit bus you can control.  It uses FTDI drivers 
and if you don't want to mess with interfacing to their DLL you can talk 
to it as if it were a serial port.

How much simpler can it be?

Here is a link to the Digikey page for it.

http://www.digikey.com/product-detail/en/DLP-2232PB-G/813-1002-ND/1894334

Rick



On 6/22/2013 7:12 PM, BartC wrote:
> "Hans-Bernhard Br&#4294967295;ker" <HBBroeker@t-online.de> wrote in message
> news:51C61A47.5080805@t-online.de...
>> On 22.06.2013 01:11, BartC wrote:
>>
>>>
>>> You might be right. With the solution I will probably go with first (an
>>> experimental USB i/o board), I can get a throughput of 100 bytes/second.
>>
>> Then you must have picked the worst USB I/O board on the planet.
>
> Possibly! This is a K8055, a 'USB experiment interface board', which I'd
> dismissed in the past as being too slow. However it has some qualities
> which I can now appreciate: it's simple, it's easy to interface to my
> language, and it works! (Because I do have my own languages, getting
> them to work with other systems always requires special effort. But the
> code I used to test out the K8055 is shown below. It needs only a 350KB
> DLL file.)
>
>> COTS, 5$ USB-to-RS323 adapters do 115k2 Baud out of the box, i.e.
>> about a factor 100 faster than that.
>
> I've used RS232 quite a lot in the past, but never liked it. Always
> something that will not work, and customers always had problems with it
> too. In the current context, a serial link will also need some gubbins
> at the other end to re-assemble the data.
>
> (Talking to the K8055 and writing bytes 0 .. 255 one after the other to
> the output pins (which conveniently have LEDs attached to see what's
> happening):)
>
> from k8055d:
> clang function OpenDevice (int)int
> clang proc CloseDevice
> clang proc WriteAllDigital (int)
>
> if opendevice(0)=-1 then
> println "Can't open USB card"
> stop
> fi
>
> for i:=0 to 255 do
> writealldigital(i)
> od
>
> closedevice()
>


-- 

Rick

Am 21.06.2013 11:13, schrieb BartC:
> Suppose I have an x86-based PC running Windows 7; I have a couple of simple
> tasks:
>
> o Write a single bit to a pin somewhere (perhaps connected to an LED)
> o Read a single bit from a pin (perhaps connected to a push-button)

RTS, CTS, DCD, DTR of a serial port?


Gunther

"Hans-Bernhard Br&#4294967295;ker" <HBBroeker@t-online.de> wrote in message 
news:51C61A47.5080805@t-online.de...
> On 22.06.2013 01:11, BartC wrote:
>
>>
>> You might be right. With the solution I will probably go with first (an
>> experimental USB i/o board), I can get a throughput of 100 bytes/second.
>
> Then you must have picked the worst USB I/O board on the planet.

Possibly! This is a K8055, a 'USB experiment interface board', which I'd 
dismissed in the past as being too slow. However it has some qualities which 
I can now appreciate: it's simple, it's easy to interface to my language, 
and it works! (Because I do have my own languages, getting them to work with 
other systems always requires special effort. But the code I used to test 
out the K8055 is shown below. It needs only a 350KB DLL file.)

>  COTS, 5$ USB-to-RS323 adapters do 115k2 Baud out of the box, i.e. about a 
> factor 100 faster than that.

I've used RS232 quite a lot in the past, but never liked it. Always 
something that will not work, and customers always had problems with it too. 
In the current context, a serial link will also need some gubbins at the 
other end to re-assemble the data.

(Talking to the K8055 and writing bytes 0 .. 255 one after the other to the 
output pins (which conveniently have LEDs attached to see what's 
happening):)

from k8055d:
clang function OpenDevice             (int)int
clang proc     CloseDevice
clang proc     WriteAllDigital        (int)

if opendevice(0)=-1 then
  println "Can't open USB card"
  stop
fi

for i:=0 to 255 do
  writealldigital(i)
od

closedevice()

-- 
Bartc 

BartC <bc@freeuk.com> wrote:
> "Waldek Hebisch" <hebisch@math.uni.wroc.pl> wrote in message 
> news:kq2pdr$oep$1@z-news.wcss.wroc.pl...
> > BartC <bc@freeuk.com> wrote:
> 
> >> That would be a stumbling block even if I replaced all the other steps. 
> >> The
> >> interface is USB, with apparently a COM port superimposed, but I've no 
> >> idea
> >> what protocols are needed to rewrite the flash memory and restart the
> >> processor.
> 
> > In particular, it is hard to get data from
> > CPU to external world and back faster than in 100ns.
> > Desktop processor can do about 1000 instructions during
> > that time.  So it should be pretty clear that bit-banging
> > is extremally inefficient in modern machines.
> 
> Accessing RAM is also inefficient. And then you have disk drives which are 
> magnitudes slower than that. And presumably a PC will have numerous devices 
> with registers to read and write that are also inefficient to access 
> compared with a normal instruction stream.
> 
> But these are necessary to access from time to time, so allowance is made. 
> It's not as though this 'bit-banging' is continuous. But if that was what is 
> needed sometimes, so what? My PC spends most of its time waiting for me to 
> press a key. It's not a mainframe computer where I'm paying for CPU time by 
> the second!
> 

Efficiency is important for PC.  First, when doing something
you want to do computations as fast as possible and limit
waste of processor time on other activites.  Second, when
system is almost idle you do not want to drain battery in
a laptop so interrupts are better than busy loops.  And
typical system is for long time connected to network, so
you have some asynchronous activity going on.

Closer to your original problem: when bit-banging speed
will be limited by latency.  To get low latency you
need to put device on PCI bus, but design (and manufacturing
in small quantities) of such device is expensive.  Most
applications can tolerate much larger latencies, so
that is provided by cheaper solutions.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

On 22.06.2013 01:11, BartC wrote:

>
> You might be right. With the solution I will probably go with first (an
> experimental USB i/o board), I can get a throughput of 100 bytes/second.

Then you must have picked the worst USB I/O board on the planet.  COTS, 
5$ USB-to-RS323 adapters do 115k2 Baud out of the box, i.e. about a 
factor 100 faster than that.  But bytes/second, i.e. bandwidth, is not 
the problem with using a PC for this kind of thing anyway: latency is. 
You won't be reacting to outside stimuli within milliseconds using a 
Windows PC.

The pipes in a current PC are almost certainly wider than code of the 
type you're hinting at would know what do with.  But they're also 
_long_, with lots of twists and turns to be maneuvered..

> Thirty years ago, with a Z80 computer a thousand times slower than my
> PC, it would probably have managed 100,000 bytes/second! I wonder what
> went wrong?

Nothing --- if you use the right tools for the job.  A PC is not.

On 6/22/2013 6:24 AM, BartC wrote:
> "Waldek Hebisch" <hebisch@math.uni.wroc.pl> wrote in message
> news:kq2pdr$oep$1@z-news.wcss.wroc.pl...
>> BartC <bc@freeuk.com> wrote:
>
>>> That would be a stumbling block even if I replaced all the other
>>> steps. The
>>> interface is USB, with apparently a COM port superimposed, but I've
>>> no idea
>>> what protocols are needed to rewrite the flash memory and restart the
>>> processor.
>
>> In particular, it is hard to get data from
>> CPU to external world and back faster than in 100ns.
>> Desktop processor can do about 1000 instructions during
>> that time. So it should be pretty clear that bit-banging
>> is extremally inefficient in modern machines.
>
> Accessing RAM is also inefficient. And then you have disk drives which
> are magnitudes slower than that. And presumably a PC will have numerous
> devices with registers to read and write that are also inefficient to
> access compared with a normal instruction stream.
>
> But these are necessary to access from time to time, so allowance is
> made. It's not as though this 'bit-banging' is continuous. But if that
> was what is needed sometimes, so what? My PC spends most of its time
> waiting for me to press a key. It's not a mainframe computer where I'm
> paying for CPU time by the second!

I guess I don't understand your point.  You want to program something 
using techniques that worked under MS-DOS.  The problem with today's 
computers is not the hardware, but the OS.  So just run MS-DOS.  I think 
there are some functional equivalents to that you can find but I don't 
remember the names.

The problem you have asking for advice here is that you want to get to 
Baltimore and are asking how to cure your horse of colic.  There aren't 
many here who can give you good advice on that because none of the 
reasonable ways to get to Baltimore include using a horse!

I would suggest that you look into using one of the Forth distributions 
to access one of the USB devices that look like a serial port, but give 
you pins you can control.  The USB device will give you the hardware you 
wish to control and Forth will let you control a serial port with a 
minimum imposition from the OS.  I am using Forth right now to control 
hardware I built and it is working quite well.

-- 

Rick

On Saturday, June 22, 2013 10:03:37 PM UTC+12, BartC wrote:
> My Z80 estimate was based on a loop like this:
> loop:
>   ld al,(hl)
>   inc hl
>   out (n),al   ; or ld (nn),al
>   djnz loop
> At 4MHz, 100,000 iterations per second is quite possible. 

 You can still get this granularity, just not from your X86 CPU, talking to an IO pin.

 If you want assembler-level granularity, then just put a small uC at the end of the wire, it will likely cost less than the cable anyway.  
( eg 65c for 44 pin AT89LP52, under 2c/io pin)

 USB access constrains PC granularity to the order of ~1ms in Full speed, and maybe 4x faster in High Speed, but if you can arrange in packets, you can get quite high data flows. 

 It is not a brick wall, just a slightly different approach is needed.

On Sat, 22 Jun 2013 00:25:40 +0000 (UTC), Waldek Hebisch
<hebisch@math.uni.wroc.pl> wrote:

>Note that actually getting 1_000_000 bytes per second at reasonable
>distance is not that easy due to electical charactristics.  You
>can get it via USB or ethernet if you use block tranfers.  If
>you want single byte transfers, than it is likely that your
>Z80 would have trouble with 100_000 bytes per second.  AFAIK
>in early PC era parallel printers freqently peaked at
>few kilobytes per second.   Modern interfaces can do much
>more (there are cheap gadgets that transfer tens of megabytes
>per second), but using block transfers and at the cost of
>complexity.

1 MB/s or 10 Mbit/s is not that hard, unless you use TTL or RS-232 :-)
Profibus DP, which is essentially RS-485 runs at 12 Mb/s for about 100
m, but requires some impedance matching tricks. At 1.5 Mbit/s
practically any barbed wire will do. 

CANbus at 1 Mb/s can handle tens of meters and it uses bitwise
arbitration, so the two way propagation delay limits the distance.

In any half duplex system, the line turnaround delay will quite
effectively kill the throughput.

Even if the Z80 could send 100 KB/s or 1 Mb/s in burst mode, every
node on the network must also be able to receive at that rate, i.e.
the receiving station interrupt service times must be compatible,
which finally limits the system throughput.

Some old PLC protocol even used such bizarre system
* Station A requests to transmit by sending a single byte.
* Station B sends a single byte Ack and enters receiver loop.
* Station A sends message in a loop and Station B receives by polling
* Station A responds with Ack/Nak depending on check sum check.

In such a protocol both Station A and Station B can use loops without
interrupts. However, the "Request to transmit" to "OK to transmit"
delay (often 10-300 ms) will drop the actual throughput considerably.