Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #36417 > unrolled thread

FT800 bindings in ANS Forth

Back to article view | Back to comp.lang.forth

Contents

  FT800 bindings in ANS Forth James Bowman <bowmanator@gmail.com> - 2015-02-09 17:43 -0800
    Re: FT800 bindings in ANS Forth rickman <gnuarm@gmail.com> - 2015-02-09 21:59 -0500
      Re: FT800 bindings in ANS Forth James Bowman <bowmanator@gmail.com> - 2015-02-09 20:00 -0800
        Re: FT800 bindings in ANS Forth rickman <gnuarm@gmail.com> - 2015-02-10 13:36 -0500
          Re: FT800 bindings in ANS Forth visualforth@rocketmail.com - 2015-02-10 13:47 -0800
            Re: FT800 bindings in ANS Forth rickman <gnuarm@gmail.com> - 2015-02-10 17:03 -0500
              Re: FT800 bindings in ANS Forth visualforth@rocketmail.com - 2015-02-10 14:22 -0800
                Re: FT800 bindings in ANS Forth rickman <gnuarm@gmail.com> - 2015-02-10 21:34 -0500
                  Re: FT800 bindings in ANS Forth Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-02-11 01:07 -0800
                    Re: FT800 bindings in ANS Forth rickman <gnuarm@gmail.com> - 2015-02-11 11:26 -0500
                Re: FT800 bindings in ANS Forth hughaguilar96@gmail.com - 2015-02-10 19:44 -0800
                  Re: FT800 bindings in ANS Forth hughaguilar96@gmail.com - 2015-02-10 22:29 -0800
                    Re: FT800 bindings in ANS Forth rickman <gnuarm@gmail.com> - 2015-02-11 11:29 -0500
                      Re: FT800 bindings in ANS Forth Mark Wills <markwills1970@gmail.com> - 2015-02-11 11:19 -0800
                        Re: FT800 bindings in ANS Forth rickman <gnuarm@gmail.com> - 2015-02-12 03:28 -0500
                      Re: FT800 bindings in ANS Forth hughaguilar96@gmail.com - 2015-02-11 21:34 -0800
    Re: FT800 bindings in ANS Forth Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-02-16 12:07 +0100
      Re: FT800 bindings in ANS Forth Mark Wills <markwills1970@gmail.com> - 2015-02-16 03:12 -0800

#36417 — FT800 bindings in ANS Forth

Just released: complete Forth driver for the FT800 embedded graphics/touch-screen/audio controller, together with a few demos:

https://github.com/jamesbowman/forth-ft800

It is meant to be portable to any 32-bit ANS Forth, and so far is running fine on a couple of embedded Forths.

The project is open-source (BSD license). Patches/contributions/bug reports welcome.

Thanks.

J.

[toc] | [next] | [standalone]

#36418

On 2/9/2015 8:43 PM, James Bowman wrote:
> Just released: complete Forth driver for the FT800 embedded graphics/touch-screen/audio controller, together with a few demos:
>
> https://github.com/jamesbowman/forth-ft800
>
> It is meant to be portable to any 32-bit ANS Forth, and so far is running fine on a couple of embedded Forths.
>
> The project is open-source (BSD license). Patches/contributions/bug reports welcome.

Is this part basically what was called a video controller many years 
ago?  The only graphics feature I see mention of in the web page for the 
FT800 is "widgets".  Is this otherwise just a device to manage the 
memory interface and control the display timing?  Not counting the touch 
screen and audio interfaces of course.

Not trying to criticize, just trying to get a better feel for the device.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#36420

On Tuesday, February 10, 2015 at 10:59:40 AM UTC+8, rickman wrote:

> Is this part basically what was called a video controller many years 
> ago?  The only graphics feature I see mention of in the web page for the 
> FT800 is "widgets".  Is this otherwise just a device to manage the 
> memory interface and control the display timing?  Not counting the touch 
> screen and audio interfaces of course.
> 
> Not trying to criticize, just trying to get a better feel for the device.
> 

The FT800 does handle the display and memory of course. But it also supports graphics drawing - points, lines, rectangles, bitmaps - and supports some higher-level operations like drawing widgets, loading JPEGs.

It frees up the MCU from having to deal with pixels at all. The driver (in Forth or C) is really just sending these high-level commands to the FT800.

[toc] | [prev] | [next] | [standalone]

#36436

On 2/9/2015 11:00 PM, James Bowman wrote:
> On Tuesday, February 10, 2015 at 10:59:40 AM UTC+8, rickman wrote:
>
>> Is this part basically what was called a video controller many years
>> ago?  The only graphics feature I see mention of in the web page for the
>> FT800 is "widgets".  Is this otherwise just a device to manage the
>> memory interface and control the display timing?  Not counting the touch
>> screen and audio interfaces of course.
>>
>> Not trying to criticize, just trying to get a better feel for the device.
>>
>
> The FT800 does handle the display and memory of course. But it also supports graphics drawing - points, lines, rectangles, bitmaps - and supports some higher-level operations like drawing widgets, loading JPEGs.
>
> It frees up the MCU from having to deal with pixels at all. The driver (in Forth or C) is really just sending these high-level commands to the FT800.

Yeah, I finally looked at the data sheet.  Pretty cool for some low 
level devices.  But I wonder how it compares to something like the rPi 
or BeagleBone?  What was your application that you liked this better 
than a higher end CPU with GPU internal?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#36439

On Tuesday, February 10, 2015 at 1:36:08 PM UTC-5, rickman wrote:
> On 2/9/2015 11:00 PM, James Bowman wrote:
> > On Tuesday, February 10, 2015 at 10:59:40 AM UTC+8, rickman wrote:
> >
> >> Is this part basically what was called a video controller many years
> >> ago?  The only graphics feature I see mention of in the web page for the
> >> FT800 is "widgets".  Is this otherwise just a device to manage the
> >> memory interface and control the display timing?  Not counting the touch
> >> screen and audio interfaces of course.
> >>
> >> Not trying to criticize, just trying to get a better feel for the device.
> >>
> >
> > The FT800 does handle the display and memory of course. But it also supports graphics drawing - points, lines, rectangles, bitmaps - and supports some higher-level operations like drawing widgets, loading JPEGs.
> >
> > It frees up the MCU from having to deal with pixels at all. The driver (in Forth or C) is really just sending these high-level commands to the FT800.
> 
> Yeah, I finally looked at the data sheet.  Pretty cool for some low 
> level devices.  But I wonder how it compares to something like the rPi 
> or BeagleBone?  What was your application that you liked this better 
> than a higher end CPU with GPU internal?
> 
> -- 
> 
> Rick

The FT800 is just the right display for microcontrollers running Forth:
There is no need for dual memory access, no need to address memory with address- and data-lines anyway. The color LCD and all the hardware to control the color LCD is on the FT800 board. It's the work of a genius! 

Just simply connect the three SPI wires (DI, DO, CLK) which nearly every microcontroller has, plus GND and power supply.

Connect the FT800 board to your microcontroller with James' Forth tool, and start doing graphics the easy way - the Forth way!

I have such a board in my drawer since over a year and now I have the chance to get it running - my plan is to get it work with 4e4th and the 4E4th-IDE.
Thanks, James! I had so much other work to do, and I am really happy that James got this task finished.

James did a presentation on one of the recent SVFIG meetings in Stanford.

[toc] | [prev] | [next] | [standalone]

#36440

On 2/10/2015 4:47 PM, visualforth@rocketmail.com wrote:
> On Tuesday, February 10, 2015 at 1:36:08 PM UTC-5, rickman wrote:
>> On 2/9/2015 11:00 PM, James Bowman wrote:
>>> On Tuesday, February 10, 2015 at 10:59:40 AM UTC+8, rickman wrote:
>>>
>>>> Is this part basically what was called a video controller many years
>>>> ago?  The only graphics feature I see mention of in the web page for the
>>>> FT800 is "widgets".  Is this otherwise just a device to manage the
>>>> memory interface and control the display timing?  Not counting the touch
>>>> screen and audio interfaces of course.
>>>>
>>>> Not trying to criticize, just trying to get a better feel for the device.
>>>>
>>>
>>> The FT800 does handle the display and memory of course. But it also supports graphics drawing - points, lines, rectangles, bitmaps - and supports some higher-level operations like drawing widgets, loading JPEGs.
>>>
>>> It frees up the MCU from having to deal with pixels at all. The driver (in Forth or C) is really just sending these high-level commands to the FT800.
>>
>> Yeah, I finally looked at the data sheet.  Pretty cool for some low
>> level devices.  But I wonder how it compares to something like the rPi
>> or BeagleBone?  What was your application that you liked this better
>> than a higher end CPU with GPU internal?
>>
>> --
>>
>> Rick
>
> The FT800 is just the right display for microcontrollers running Forth:
> There is no need for dual memory access, no need to address memory with address- and data-lines anyway. The color LCD and all the hardware to control the color LCD is on the FT800 board. It's the work of a genius!
>
> Just simply connect the three SPI wires (DI, DO, CLK) which nearly every microcontroller has, plus GND and power supply.
>
> Connect the FT800 board to your microcontroller with James' Forth tool, and start doing graphics the easy way - the Forth way!
>
> I have such a board in my drawer since over a year and now I have the chance to get it running - my plan is to get it work with 4e4th and the 4E4th-IDE.
> Thanks, James! I had so much other work to do, and I am really happy that James got this task finished.
>
> James did a presentation on one of the recent SVFIG meetings in Stanford.

I'm not sure I follow.  The FT800 is a chip that has to be added to an 
MCU to provide RGB video with Hsync and Vsync along with mono audio and 
a touch screen interface.  I think none of these interfaces will connect 
directly to a video device without more circuitry.   Once you are 
talking about a board level product I would think there are lots of 
other options.  That is what I was asking about.  Rather than use 
something like a separate MCU and graphics controller, why not use 
something like the rPi where it is all more integrated?  I see the 
"ConnectEVE" for $69 which is twice what you will pay for the rPi and 
you still need to add the MCU board.  I suppose the rPi or Beagle Bone 
don't include a touch screen interface, but that can be added very 
easily if required.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#36442

On Tuesday, February 10, 2015 at 5:03:04 PM UTC-5, rickman wrote:
> On 2/10/2015 4:47 PM, visualforth.com wrote:
> > On Tuesday, February 10, 2015 at 1:36:08 PM UTC-5, rickman wrote:
> >> On 2/9/2015 11:00 PM, James Bowman wrote:
> >>> On Tuesday, February 10, 2015 at 10:59:40 AM UTC+8, rickman wrote:
> >>>
> >>>> Is this part basically what was called a video controller many years
> >>>> ago?  The only graphics feature I see mention of in the web page for the
> >>>> FT800 is "widgets".  Is this otherwise just a device to manage the
> >>>> memory interface and control the display timing?  Not counting the touch
> >>>> screen and audio interfaces of course.
> >>>>
> >>>> Not trying to criticize, just trying to get a better feel for the device.
> >>>>
> >>>
> >>> The FT800 does handle the display and memory of course. But it also supports graphics drawing - points, lines, rectangles, bitmaps - and supports some higher-level operations like drawing widgets, loading JPEGs.
> >>>
> >>> It frees up the MCU from having to deal with pixels at all. The driver (in Forth or C) is really just sending these high-level commands to the FT800.
> >>
> >> Yeah, I finally looked at the data sheet.  Pretty cool for some low
> >> level devices.  But I wonder how it compares to something like the rPi
> >> or BeagleBone?  What was your application that you liked this better
> >> than a higher end CPU with GPU internal?
> >>
> >> --
> >>
> >> Rick
> >
> > The FT800 is just the right display for microcontrollers running Forth:
> > There is no need for dual memory access, no need to address memory with address- and data-lines anyway. The color LCD and all the hardware to control the color LCD is on the FT800 board. It's the work of a genius!
> >
> > Just simply connect the three SPI wires (DI, DO, CLK) which nearly every microcontroller has, plus GND and power supply.
> >
> > Connect the FT800 board to your microcontroller with James' Forth tool, and start doing graphics the easy way - the Forth way!
> >
> > I have such a board in my drawer since over a year and now I have the chance to get it running - my plan is to get it work with 4e4th and the 4E4th-IDE.
> > Thanks, James! I had so much other work to do, and I am really happy that James got this task finished.
> >
> > James did a presentation on one of the recent SVFIG meetings in Stanford.
> 
> I'm not sure I follow.  The FT800 is a chip that has to be added to an 
> MCU to provide RGB video with Hsync and Vsync along with mono audio and 
> a touch screen interface.  I think none of these interfaces will connect 
> directly to a video device without more circuitry.   Once you are 
> talking about a board level product I would think there are lots of 
> other options.  That is what I was asking about.  Rather than use 
> something like a separate MCU and graphics controller, why not use 
> something like the rPi where it is all more integrated?  I see the 
> "ConnectEVE" for $69 which is twice what you will pay for the rPi and 
> you still need to add the MCU board.  I suppose the rPi or Beagle Bone 
> don't include a touch screen interface, but that can be added very 
> easily if required.
> 
> -- 
> 
> Rick

Of course I was writing about the complete board with display, sorry for the confusion.

What I mean is that it is the idea of a genius to have a chip with only a few lines to control a display and a few lines to control this chip.

In former times you needed a lot of address- and data-lines to connect to a display-controller, which is now obsolete with the FT800.

I was waiting for this simple solution for decades.
Because this solution is so simple, it is Forth-like: as simple as possible, but not simpler!

[toc] | [prev] | [next] | [standalone]

#36456

On 2/10/2015 5:22 PM, visualforth@rocketmail.com wrote:
> On Tuesday, February 10, 2015 at 5:03:04 PM UTC-5, rickman wrote:
>> On 2/10/2015 4:47 PM, visualforth.com wrote:
>>> On Tuesday, February 10, 2015 at 1:36:08 PM UTC-5, rickman wrote:
>>>> On 2/9/2015 11:00 PM, James Bowman wrote:
>>>>> On Tuesday, February 10, 2015 at 10:59:40 AM UTC+8, rickman wrote:
>>>>>
>>>>>> Is this part basically what was called a video controller many years
>>>>>> ago?  The only graphics feature I see mention of in the web page for the
>>>>>> FT800 is "widgets".  Is this otherwise just a device to manage the
>>>>>> memory interface and control the display timing?  Not counting the touch
>>>>>> screen and audio interfaces of course.
>>>>>>
>>>>>> Not trying to criticize, just trying to get a better feel for the device.
>>>>>>
>>>>>
>>>>> The FT800 does handle the display and memory of course. But it also supports graphics drawing - points, lines, rectangles, bitmaps - and supports some higher-level operations like drawing widgets, loading JPEGs.
>>>>>
>>>>> It frees up the MCU from having to deal with pixels at all. The driver (in Forth or C) is really just sending these high-level commands to the FT800.
>>>>
>>>> Yeah, I finally looked at the data sheet.  Pretty cool for some low
>>>> level devices.  But I wonder how it compares to something like the rPi
>>>> or BeagleBone?  What was your application that you liked this better
>>>> than a higher end CPU with GPU internal?
>>>>
>>>> --
>>>>
>>>> Rick
>>>
>>> The FT800 is just the right display for microcontrollers running Forth:
>>> There is no need for dual memory access, no need to address memory with address- and data-lines anyway. The color LCD and all the hardware to control the color LCD is on the FT800 board. It's the work of a genius!
>>>
>>> Just simply connect the three SPI wires (DI, DO, CLK) which nearly every microcontroller has, plus GND and power supply.
>>>
>>> Connect the FT800 board to your microcontroller with James' Forth tool, and start doing graphics the easy way - the Forth way!
>>>
>>> I have such a board in my drawer since over a year and now I have the chance to get it running - my plan is to get it work with 4e4th and the 4E4th-IDE.
>>> Thanks, James! I had so much other work to do, and I am really happy that James got this task finished.
>>>
>>> James did a presentation on one of the recent SVFIG meetings in Stanford.
>>
>> I'm not sure I follow.  The FT800 is a chip that has to be added to an
>> MCU to provide RGB video with Hsync and Vsync along with mono audio and
>> a touch screen interface.  I think none of these interfaces will connect
>> directly to a video device without more circuitry.   Once you are
>> talking about a board level product I would think there are lots of
>> other options.  That is what I was asking about.  Rather than use
>> something like a separate MCU and graphics controller, why not use
>> something like the rPi where it is all more integrated?  I see the
>> "ConnectEVE" for $69 which is twice what you will pay for the rPi and
>> you still need to add the MCU board.  I suppose the rPi or Beagle Bone
>> don't include a touch screen interface, but that can be added very
>> easily if required.
>>
>> --
>>
>> Rick
>
> Of course I was writing about the complete board with display, sorry for the confusion.
>
> What I mean is that it is the idea of a genius to have a chip with only a few lines to control a display and a few lines to control this chip.
>
> In former times you needed a lot of address- and data-lines to connect to a display-controller, which is now obsolete with the FT800.
>
> I was waiting for this simple solution for decades.
> Because this solution is so simple, it is Forth-like: as simple as possible, but not simpler!

Yes, I understand.  But isn't it even simpler to have the graphics 
capability built in to the CPU?  Take a look at the Beagle Bone Black. 
There are add on cards for that which provide the flat screen, etc, 
making use of the capabilities built into the CPU chip.

I guess I just don't see anything magical about the FT800.  It's not 
really simple, there are still driver electronics needed to control an 
LCD.  It's a bit obsolete really.  I recall a few months ago someone was 
posting about a floating point chip that could be added to CPU/MCUs with 
some simple interface.  Similarly there are tons of CPU/MCU chips 
available that support floating point without an add on.  So this sort 
of floating point chip is also pretty obsolete.

I suppose if you had an existing system with a code base and you needed 
to add graphics but didn't want to update the CPU this chip might have 
some advantage.  Otherwise, why not just pick the right CPU for the job?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#36465

> 
> I suppose if you had an existing system with a code base and you needed 
> to add graphics but didn't want to update the CPU this chip might have 
> some advantage.  Otherwise, why not just pick the right CPU for the job?
> 
You mix things here, updating a CPU has nothing to do with SBCs like rPi or BBB. Also, a real custom made FT800 board is hardly more than $10 for a given QVGA or WQVGA tft screen.
Let me give you a real world example: I have a board with an ATmega1280 microcontroller (AVR8). Besides many other things it does, it has a connection with a monochrome (but graphic) lcd screen 128x128 pixels. The firmware is quite elaborate, and has been developed and updated during almost 5 years.
Now, the client is asking of an improvement: he wants to change the lcd and the membrane keyboard of the device with a single color tft with touchscreen. What should you do? Put a beaglebone inside? or rPI? Begin programming in Linux?
There are two solutions: change the board completely, with a new chip and an external SRAM or SDRAM, let say a LPC4000 series. These chips have an internal lcd controller, but they need external ram for it. Also, the touch screen support is not there, you need at least an "emulated" one by two analog pins and two digitals, and a firmware driver based on lot of interrupts. Or an external TS controller chip... And all of this will not free you of needing an aditional board for the TFT screen itself, containg at least the connectors and maybe some power supplies.
The second solution is a tft board with the FT800. This will almost have no impact on the current base board, except maybe changing the connectors. Also, the firmware will only have to be modified for the graphics, and that will be also more easy to do because the FT chip already has the primitives inside...
And I'm not talking about any audio output, because the application doesn't need any.

My only complaint about the FT800 is that it is limited to 480 x 272 resolution. I have applications with 800 x 480 which are impossible with FT800. I do them with LPC4000 chips, but only the graphics eats almost 50% of the cpu processing time, at 120MHz, most of the time. I whish I could have a FT800 for those applications...

[toc] | [prev] | [next] | [standalone]

#36475

On 2/11/2015 4:07 AM, Raimond Dragomir wrote:
>>
>> I suppose if you had an existing system with a code base and you needed
>> to add graphics but didn't want to update the CPU this chip might have
>> some advantage.  Otherwise, why not just pick the right CPU for the job?
>>
> You mix things here, updating a CPU has nothing to do with SBCs like rPi or BBB.

I'm not talking about updating a chip.  I'm talking about a design that 
is in place and you don't want to toss out your code and start over with 
a different system.

So you are making my case for me.

> Also, a real custom made FT800 board is hardly more than $10 for a given QVGA or WQVGA tft screen.
> Let me give you a real world example: I have a board with an ATmega1280 microcontroller (AVR8). Besides many other things it does, it has a connection with a monochrome (but graphic) lcd screen 128x128 pixels. The firmware is quite elaborate, and has been developed and updated during almost 5 years.
> Now, the client is asking of an improvement: he wants to change the lcd and the membrane keyboard of the device with a single color tft with touchscreen. What should you do? Put a beaglebone inside? or rPI? Begin programming in Linux?
> There are two solutions: change the board completely, with a new chip and an external SRAM or SDRAM, let say a LPC4000 series. These chips have an internal lcd controller, but they need external ram for it. Also, the touch screen support is not there, you need at least an "emulated" one by two analog pins and two digitals, and a firmware driver based on lot of interrupts. Or an external TS controller chip... And all of this will not free you of needing an aditional board for the TFT screen itself, containg at least the connectors and maybe some power supplies.
> The second solution is a tft board with the FT800. This will almost have no impact on the current base board, except maybe changing the connectors. Also, the firmware will only have to be modified for the graphics, and that will be also more easy to do because the FT chip already has the primitives inside...
> And I'm not talking about any audio output, because the application doesn't need any.
>
> My only complaint about the FT800 is that it is limited to 480 x 272 resolution. I have applications with 800 x 480 which are impossible with FT800. I do them with LPC4000 chips, but only the graphics eats almost 50% of the cpu processing time, at 120MHz, most of the time. I whish I could have a FT800 for those applications...
>


-- 

Rick

[toc] | [prev] | [next] | [standalone]

#36460

On Tuesday, February 10, 2015 at 3:22:24 PM UTC-7, visua...@rocketmail.com wrote:
> Of course I was writing about the complete board with display, sorry for the confusion.
> 
> What I mean is that it is the idea of a genius to have a chip with only a few lines to control a display and a few lines to control this chip.
> 
> In former times you needed a lot of address- and data-lines to connect to a display-controller, which is now obsolete with the FT800.
> 
> I was waiting for this simple solution for decades.
> Because this solution is so simple, it is Forth-like: as simple as possible, but not simpler!

My understanding of Dirk's comments, is that he likes the idea of adding layers of abstraction to the hardware, rather than have a monolithic system --- it seems like a good idea to me too, as the upper-layer of hardware has less complexity to deal with, and the upper-layer is where most of the people involved are working.

Adding layers of abstraction is pretty much the standard way to simplify complex systems of all kinds --- it can be overdone though, and it doesn't fix stupid (abstraction clarifies a person's thinking, but if a person isn't thinking, adding layers of abstraction won't help) --- for the most part though, abstraction is a good idea (abstraction is what makes us human, according to Temple Grandin).

[toc] | [prev] | [next] | [standalone]

#36461

On Tuesday, February 10, 2015 at 8:45:00 PM UTC-7, hughag...@gmail.com wrote:
> ... (abstraction is what makes us human, according to Temple Grandin).

Thinking about Temple Grandin led me to go look at her website:
http://www.templegrandin.com/

Here is a quote:
"I like the really logical way that I think. I'm totally logical. In fact, it kind of blows my mind how irrational human beings are," she said. "If you totally got rid of autism, you'd have nobody to fix your computer in the future."

Actually, I don't think she knows anything about computers --- she doesn't know how much abstraction is involved --- she does have a good point, that people tend to over-abstractify, but her analogy was over-reached.

[toc] | [prev] | [next] | [standalone]

#36476

On 2/11/2015 1:29 AM, hughaguilar96@gmail.com wrote:
> On Tuesday, February 10, 2015 at 8:45:00 PM UTC-7, hughag...@gmail.com wrote:
>> ... (abstraction is what makes us human, according to Temple Grandin).
>
> Thinking about Temple Grandin led me to go look at her website:
> http://www.templegrandin.com/
>
> Here is a quote:
> "I like the really logical way that I think. I'm totally logical. In fact, it kind of blows my mind how irrational human beings are," she said. "If you totally got rid of autism, you'd have nobody to fix your computer in the future."
>
> Actually, I don't think she knows anything about computers --- she doesn't know how much abstraction is involved --- she does have a good point, that people tend to over-abstractify, but her analogy was over-reached.

She is also very wrong.  *No one* is purely logical.  Even when we are 
being logical, we have tied our emotions to logic and then follow the 
emotions.  We are inherently emotional people and there is nothing we 
can do about it.

Try this.  Next time you see something that is illogical, think about 
how it makes you feel.  You will find that it is the uncomfortable 
feeling it gives you that makes you want to change it or make it 
logical.  Emotions... not pure logic.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#36482

I think she was being tongue-in-cheek.

[toc] | [prev] | [next] | [standalone]

#36495

On 2/11/2015 2:19 PM, Mark Wills wrote:
> I think she was being tongue-in-cheek.
>

I don't think so.  I think the idea of logical thinking is superficial 
and a lot of people, including myself at one time, believe that they can 
be purely logical and not emotional.  But there are just so many 
examples of people who spend much of their lives training and working in 
research or technology only to find they have deep biases and in fact 
can be lead astray by their "unlogic".

One very notable example of this is the very person who is saying I know 
nothing.  He has formed amazingly complex, but irrational ideas because 
of some abnormality in his emotions.

I will admit that I may not understand the author his is talking about. 
  I was only responding to what I thought he was saying.  But many of 
his other posts indicate he thinks he is thinking logically when he in 
fact is following his emotions to the point of absurdity.

However, he is not alone.  We all do it...

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#36493

On Wednesday, February 11, 2015 at 9:29:39 AM UTC-7, rickman wrote:
> On 2/11/2015 1:29 AM, hughaguilar96@gmail.com wrote:
> > On Tuesday, February 10, 2015 at 8:45:00 PM UTC-7, hughag...@gmail.com wrote:
> >> ... (abstraction is what makes us human, according to Temple Grandin).
> >
> > Thinking about Temple Grandin led me to go look at her website:
> > http://www.templegrandin.com/
> >
> > Here is a quote:
> > "I like the really logical way that I think. I'm totally logical. In fact, it kind of blows my mind how irrational human beings are," she said. "If you totally got rid of autism, you'd have nobody to fix your computer in the future."
> >
> > Actually, I don't think she knows anything about computers --- she doesn't know how much abstraction is involved --- she does have a good point, that people tend to over-abstractify, but her analogy was over-reached.
 
> She is also very wrong.  *No one* is purely logical.  Even when we are 
> being logical, we have tied our emotions to logic and then follow the 
> emotions.  We are inherently emotional people and there is nothing we 
> can do about it.
> 
> Try this.  Next time you see something that is illogical, think about 
> how it makes you feel.  You will find that it is the uncomfortable 
> feeling it gives you that makes you want to change it or make it 
> logical.  Emotions... not pure logic.

Rickman doesn't know what he's talking about --- her use of the word "logical" was not intended to imply the antithesis of "emotional" --- she doesn't talk about emotions at all in her books ("irrational" is not a synonym for "emotional"). Rickman is a troll; he denounces Temple Grandin as "very wrong" --- then he completely misinterprets what she is talking about.

I've read most of Temple Grandin's books. She believes that what separates people from animals, is that people abstractify more. To use programming terminology --- animals are working with raw data, and people are working with cooked data. She also thinks that autistic people are similar to animals in that they aren't abstractifying as much as normal people. The irony is that it is often said that autistic people are "living in their own world" --- the exact opposite is true, as normal people are living in their own world of abstract concepts, and autistic people are living in the real world of raw information.

Most of Temple Grandin's success in designing animal-handling facilities, was due to the fact that she saw the facility the way that the animals saw it --- she didn't abstractify away the details --- she saw the details that the animals saw, but which most people didn't see, and so she knew what would upset the animals. An example would be a dangling chain --- people don't see this (if you interrogate them afterward as to what they saw, they don't remember seeing any chain) --- cows see the chain and it distracts them terribly, which is why they balked at walking past it.

The good thing about abstractifying is that this frees your mind from dealing with a lot of detail --- you get to think about high-level concepts --- people couldn't have advanced past the animals without abstractifying.

The bad thing about abstractifying is that you can only see things that you are expecting --- if you don't already have an abstract concept for something however, then you won't be able to see it or think about it.

The common example given of how abstractifying prevents seeing new things, is how the Polynesians couldn't see a sailing ship because they had no abstract concept in their minds for a sailing ship, and so it was invisible to them --- if you can't wrap your mind around something, then your mind tells you that there is nothing there. Captain Cook had to take the people out to the ship in a boat so they could see it --- when they got up close, they could see it, and if they kept their eyes on it as they retreated back to the shore they could continue seeing it --- in some cases, they didn't see the ship until they were so close that they could touch it with their hands, at which time it suddenly became visible to them.

Another example was told by a guy who went to Borneo. He had a camera and took some pictures. The people there could not see the images in the photographs though. If he took a picture of a guy standing beside his hut, people would look at the photograph and not see this. They would squint at the photograph in the same way that they would squint at some small object to make out the tiny details, but they couldn't wrap their mind around the idea that a small object like a photograph could contain an image of a big object like a man standing beside his hut. They would report that suddenly the image would appear to them, but they could only see it for a few seconds, then it would disappear again and all they saw were blurry colors --- with practice however, they could see the images in the photographs for several seconds at a time --- after a while, they got the hang of it and could see images in photographs as easily as we can.

The fact that primitive people were not able to see something like a sailing ship that was right in front of them, makes use wonder if we are primitive in our own way and are not able to see something that is right in front of us --- how can we know what we aren't seeing? --- we would need somebody to point it out to us, and there isn't anybody.

[toc] | [prev] | [next] | [standalone]

#36598

I had a nice time working together with James Bowman and the fresh Mecrisp-Stellaris 2.0.8 package includes a slightly adapted FT800/Gameduino2 driver.

Matthias


> Just released: complete Forth driver for the FT800 embedded graphics/touch-screen/audio controller, together with a few demos:
> 
> https://github.com/jamesbowman/forth-ft800
> 
> It is meant to be portable to any 32-bit ANS Forth, and so far is running fine on a couple of embedded Forths.
> 
> The project is open-source (BSD license). Patches/contributions/bug reports welcome.
> 
> Thanks.
> 
> J.

[toc] | [prev] | [next] | [standalone]

#36599

On Monday, 16 February 2015 11:07:18 UTC, Matthias Koch  wrote:
> I had a nice time working together with James Bowman and the fresh Mecrisp-Stellaris 2.0.8 package includes a slightly adapted FT800/Gameduino2 driver.
> 
> Matthias
> 
> 
> > Just released: complete Forth driver for the FT800 embedded graphics/touch-screen/audio controller, together with a few demos:
> > 
> > https://github.com/jamesbowman/forth-ft800
> > 
> > It is meant to be portable to any 32-bit ANS Forth, and so far is running fine on a couple of embedded Forths.
> > 
> > The project is open-source (BSD license). Patches/contributions/bug reports welcome.
> > 
> > Thanks.
> > 
> > J.

Wow! Nice job Matthias! Thumbs up :-)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web