Misc Expansion, OS's, development and project proposals.

[Steve]

I would like to put some ideas out to increase minimal instruction set
computer processors usefulness, and open them for discussion.  I am
doing my own commercial projects, but can see a few things that can
help the development community in this segment.  If anybody would like
these projects please come, or know people that might be interested
please let them know.

The ideas open up new areas of product development, and are largely
sequential, meant to be developed one after the other, one step at a
time.

The ideas below also would work best with a 32 bit version of misc,
but are still workable if at least a single 18 bit+ address space
available for control programs.



A simpler OS:
------------------

I have mentioned an idea, for a simple open OS in the $1 (cost)
computer thread, to drive community development, that simply allows
programs to access open standards like Open GL, Open Media, Open CL
etc.  The importance of this is revealed below.  But this opens up
more possibilities, of using the full standard function set of Java,
Android, Linux or Windows.   As Java, Android and Linux are open
standards, it allows the free creation of Misc devices using these on
cheap Arm or other processors to provide the extra functionality
without transferring the open API's to Misc code.   The system can be
based around misc, with a simple processor add on to run the Open
API's and other OS, or a conventional system, with a misc processor
add on.   Of course, the current Misc processor design is awkward for
this, but the 32 bit design should before suitable.

The OS would have little more functionality past this, to run programs
across the processors, and main control program, to communicate to the
API's.  Even if the API'S are misc based, or refer to Misc side
hardware, open drivers behind the API's can hide that. The OS is
basically a simple firmware control and routing layer with drivers.
In effect, Misc programs remain simple and control on chip resources
in a similar fashion, but with some extra features to take advantage
of. Anybody can expand this with functionality if they like. It
might be doable in 256-512 words including data space. With a large
space for control programs, both the misc array and ports, and the
API's, can be accessed and used for processing. It is simple and
takes away one layer of hassle.


Open interface drivers and hardware interface circuits for OS or
custom:
--------------------------------------------------------------------------------------------------

For development on the simple OS above, or for custom hardware without
the OS: USB, IR, Ethernet, flash cards and memory, Bluetooth, wifi,
Sata,  PCIe and Thunderbolt, audio, microphone, display, camera.  I
know that GA will have code for half of these already.


Co-processing ability:
-----------------------------

The importance of this coprocessing ability mentioned above is covered
below:

I remember an article with a Nvidia manager on their Tegra chip
design.  Unfortunately after hours of searching I can't find it.  But
basically it was telling how Nvidia was starting to tap out their chip
process's ability to reduce power consumption due to leakage.   This
means that even though decreased process sizes will increase speed, it
will also increase power consumption and heat envelope.  The problem
in embedded mobile equipment is that they already need more processing
and battery performance, and are dealing with too much heat at the top
end.  Interestingly, the article points to Nvidia using a asynchronous
like processing scheme to only turn on and off processing elements as
they use them, so only some processors are used at any one time
otherwise the chip would fuse from the heat.   The only solution is
advancement in processes or chip architecture.

Misc is a viable architectural solution to advance processing ability
and power usage, due to its excellently low transistor count
increasing processing densities.  With minor adjustments, additional
processing segments can be accommodated.


Co-processing continued.  Processor replacements:
---------------------------------------------------------------------

This is the interesting thing I mentioned in the new Misc forum
thread.  That like back in the 80's and 90's high and low powered
versions of processors were made based on Risc designs.  With a
topping out of decreases in power consumption from chip process
shrinkage, as described above, normal processors will hit limits in
their heat envelopes to how much processing performance they can
deliver.  Misc, like the Risc architecture of old above, allows a
simpler way to emulate these architectures, but unlike them, due to
its low power nature that is yet to reach a descent process to deliver
maximum ability, it has a lead in processing density beyond what
conventional consumer processors can achieve.  This should either lead
to higher processing power versions, or simple low energy versions.

The Russians are already trying to emulate x86 with ARM's:
http://armservers.com/2012/10/03/here-comes-the-emulators-ee-times-article/

Misc is inevitably suitable to run emulation of the x86 architecture
or the Arm architecture.   In the Arm case, this could include
emulation of the Arm Eco system, or use of Arm co-processors with a
Misc asic cell version of Arm.

Products: x86 coprocessing card or chip on Android and Apple systems,
to run pc and pc Linux programs with higher efficiency.  Low end x86
compatible processor.  Low end, or high end Arm compatible chip.

Such processing ability allows a Misc system to run the Open API's,
Linux, Java, Android etc code directly on the Misc processor rather
than rewrite it.

The x86 system would be an ideal low energy embedded industrial
product.

Apart from the process potential of Misc, normally one would doubt the
ability to out perform an x86 processor and especially an Arm, but
there is something that enables this, the architecture of a misc array
should be adaptable to emulating complex processors in particular and
particularly in multitasking.   The Misc array can be treated as a
pipeline.


OS's:
------

A finale benefit would be to have Android, Java or Linux for Misc. 
Java maybe more irrelevant now, but Android and Linux are consumer and
industrial standards that have drivers for hardware as well as
functionality and a code base.   Interfacing or emulating a processor
will give you the same benefits faster, than transferring these OS`s,
but such a finale solution will perform quicker.


Emulating FPGA designs:
---------------------------------

Does anybody know if there are any fpga's out there at all that are
suitable to be emulated on Misc, to run circuits designs made for
them? To offer misc as a design replacement for a suitable FPGA.


Open hardware using the projects above:
--------------------------------------------------------

In the $1 computer thread ($1 cost, $10+ price)  I suggested something
simple, an embedded platform that could fit in a ring.  One interface,
maybe Bluetooth/wifi/video wifi standard, maybe an IR, maybe a touch
sensor, no display, but a piezo speaker that can act as a microphone. 
Much like Java ring of old, you could also get it to id people.  It
could be based on the simple open OS above.  The consumer wireless
makes it complex otherwise a cheap simple embedded wireless interface
could be use.   Manufacturers could pick it up for free to
manufacture, and make their own exclusive versions.

A range of things could be made. They could be done with the simple
OS, or without the OS on custom hardware.

Please note, on Green Array's pages, they are saying they will be
developing an all in one self running development system. If they
decide to release it as a reference design, it will help develope new
designs derived from it.

http://www.greenarraychips.com/home/documents/roadmap.html



All these solutions require at least a large executable address space
that can be directly executed by one processor node, and preferably a
32 bit version of misc array (though still workable on 18 bit with
direct execution space).

[rickman]

Whoops! There it is. The longer subject than you mentioned in the
other thread made me miss it.

On 4/29/2013 5:31 AM, Steve wrote:
...

--

Rick

[rickman]

On 4/29/2013 5:31 AM, Steve wrote:
>

> Please note, on Green Array's pages, they are saying they will be
> developing an all in one self running development system. If they
> decide to release it as a reference design, it will help develope new
> designs derived from it.
>
> http://www.greenarraychips.com/home/documents/roadmap.html

Interesting. I haven't been there in a while. I see they are tweaking
the F18 design. I don't see any mention that they are considering
adding multi-voltage I/O support. They are improving the ESD
resistance, the temperature voltage envelope and the details of I/O
operation.

I don't see the hosting of the development system on the eval board as
being a great leap forward. I think this is actually a step backwards
in many respects. Often users like hosting the development system on
the target system as it provides certain advantages. But running on the
eval board will still be a host and tethered target because they are
using two chips on the eval board, one as the true target and one as a
eval board controller. So moving the development system into the
controller chip really just isolates the development system from the
rest of the world. Just look at how Chuck documents his code with
photos taken by a camera posted to a web site.

Rather I would like to see them add a *real* USB or Ethernet interface
to the eval board eliminating the need for "far faster and more intimate
communications". I have a laptop which is basically a screen and
keyboard. How much smaller can you make the development system
usefully? I guess I just don't see the purpose of a lot of what they
do. I still have to have the PC to use as a terminal anyway.

I guess GA sees a very different set of needs compared to what I see.

--

Rick

[Brad Eckert]

On Monday, April 29, 2013 2:31:57 AM UTC-7, Steve wrote:
>
> A finale benefit would be to have Android, Java or Linux for Misc. 
> Java maybe more irrelevant now, but Android and Linux are consumer and
> industrial standards that have drivers for hardware as well as
> functionality and a code base.

Think about what you're saying. A fantastically bloated and complexified OS running on a MISC chip. You're talking an elephant on roller skates. Maybe MISC could be used for peripherals, but MIPS isn't processing power.

[Steve]

rickman wrote:
> On 4/29/2013 5:31 AM, Steve wrote:
> >
> > Please note, on Green Array's pages, they are saying they will be
> > developing an all in one self running development system. If they
> > decide to release it as a reference design, it will help develope new
> > designs derived from it.
> >
> > http://www.greenarraychips.com/home/documents/roadmap.html

> I don't see the hosting of the development system on the eval board as
> being a great leap forward. I think this is actually a step backwards

> I guess GA sees a very different set of needs compared to what I see.
>
> --
>
> Rick

I think it might be possible they want to sell an andreno like device,
which would be great if they take advantage of one of the expansion
board systems out there. I would be interested in something like
that.

Steve

[Steve]

Yes, but that is where the market is Brad. I leave it down the end
because it is such a great effort and can wait till other successes.
I said the 18 bit needs to be modified for thsee things at least, but
that the 32 bit is needed in preference. What we have is basically a
microcode alternative, so very flexible. Maybe what is really needed
for a first edition is a code translator to forth, to misc, or just a
android virtual engine. Code fragments can be translated to native
misc required progressively afterwards. When we think of it, is a
virtual engine going to be any harder than emulating a processor, but
gives you the code base instantly. I should have put that old one
between this and the previous one. It is all compromise.

The room is full of elephants on rolling skates Brad, unfortunately,
it depends on if this one can do a better job.

[Steve]

Rick, about the title, sorry, I thought I put "Misc Expansion.." to
indicate that was only part of the title.

My apologies.

Steve.

[rickman]

I understand why they don't make hobbyist type boards, they don't want
to support onesy twosy stuff. They only have time for large customers.
That is pretty clear when your company is so small and running in
startup mode.

--

Rick

[Steve]

But how much money has Mr Moore gotten from the settlement, and what
contracts have they landed? Everything is a bit quite, and there is
likely a logical reason for it. If they have a big order then chips
will be cheap, and with a few insiders to run support forums, then
maybe. Some of the interest from seaforth days should be carrying
over to orders at GA, like the BMW interest. Now GA might have funds
to establish their development agenda, and rights, some orders might
come through. I personally hope for large address space 18 and 32
bit designs to run large code fast. Even 18 bit is great for my
purposes.

I would like to open the discussion up a bit further Rick. Is there
any high speed embedded bus serial peripheral interfaces? All this
bit banging really restricts speed, and the serial interfaces I have
found are rather slow. Pity there is no embedded usb go 2 or 3 like
standard to bring a wealth of easy interface periphials and memory.
Even just a high speed memory interface you could use for code or
data.

Steve.

[the_gavino_himself]

On Monday, April 29, 2013 2:31:57 AM UTC-7, Steve wrote:

avoid java

oracle must die

[Steve]

I have had some developments in thought in the last few days on these
projects. So I am posting an update here of recent posts discussing
this.


/$1 computer

Thanks to Roberto again.


rfduino? See:
> http://www.kickstarter.com/projects/1608192864/rfduino-iphone-bluetoo...
> --
> Roberto Waltman

Yeah, that is the sort of thing, but maybe a little smaller. Nice.
Love the stackable expansion, being wanting to try something like
that
for decades. Wasn't mmc/sd card originally meant to be stackable
IO?
If only wireless usb had succeeded, wireless use would be more
expansive. BT is supposed to get a speed boost, wifi has no wide
peripheral standards. BT could be implemented as one of the
industrial derivatives to reduce complexity.

I am thinking, that such a device could be implemented in this size,
like it is here, but with wireless etc on the back of the board.


Just a commodity consumer interface, if wifi can be done simpler,
than
that is great too. The industrial light derivatives are
interesting,
but lower speed.


/Android and Linux on Misc, simpler: code translators and a virtual
engine might be as simple as a processor emulation.

What we have is basically a
microcode alternative, so very flexible. Maybe what is really
needed
for a first edition is a code translator to forth, to misc, or just
a
android virtual engine. Code fragments can be translated to native
misc required progressively afterwards. When we think of it, is a
virtual engine going to be any harder than emulating a processor,
but
gives you the code base instantly. I should have put that old one
between this and the previous one. It is all compromise.

/High speed serial onboard memory and peripheral interfaces.

I personally hope for large address space 18 and 32 bit designs to run
large code fast. Even 18 bit is great for my purposes.

I would like to open the discussion up a bit further ..... Is there

any high speed embedded bus serial peripheral interfaces? All this
bit banging really restricts speed, and the serial interfaces I have
found are rather slow. Pity there is no embedded usb go 2 or 3 like
standard to bring a wealth of easy interface periphials and memory.
Even just a high speed memory interface you could use for code or
data.

/ Simpler Firmware OS and thread.

Pretty excited about it, the more I think about it, the more I
realise
I could do some of this stuff sooner rather than latter. But the
schedule is to do other things. This thread represents years of
experience and planning out there for the communities benefit, if
they
choose it, I certainly couldn't afford to fund it myself any time
soon. Nobody is putting their hands up, or enthused yet. When I
was
writing up the description of the OS, I thought, hmm this is pretty
significant functionality. and something I could do. Of course the
interfacing is where it can go obscure for being an easier job, and
without it is not so significant in functionality. Remote API
interfacing is basically writing different drivers. Mr Moore sees
things in terms of what was done, part experience, but what if it
can
be done differently. What if we can get 90% of the true embedded
programming benefits of an simple OS in basically what is an
extension
to firmware, a Firmware OS, in 256-512 words. I think that is
something he would love very much...


/The $1 computer ring again

....The ring thing is starting to look
to me like when a drunk sees a pretty woman. If I am allowed to
carry
over the GA engineering, instantly I have much of the non ring
basics
for free. It must be in delusion, it can't be that simple (still a
tall order). A first edition can drop any more complex interface,
to
proof it. The issue, where the external ram and flash memory, maybe
there is a combo chip that has most of what is wanted, maybe stick
it
on that small RFduino mentioned in the $1 computer thread, as an
expansion board, maybe get the cheapest arm all in one combination
chip and put it on one side and misc on the other, or underneath.
Yes, that is probably the easiest solution, interface a low low end
all in one to a misc chip, as long as you can pull data off the
chips
address bus to form a external memory for the misc chip, it will
probably be cheaper to use That part than to buy and use external
memory and wireless parts, and to write all drivers and interface
them. What do you think....?

[Albert van der Horst]

In article <5b7ef426-ba15-4684...@gh3g2000pbd.googlegroups.com>,

Chuck Moore was up against a ruthless lawyer who has channeled 300
million dollar to friends and bribes all over the world, not to
mention his own pockets. He should be happy to escape with his shirt,
and he is. The only reason Lecrone lets him go on with is hobby, is
that it doesn't bother him for now.

Don't expect any funds available at GA. Expect the legal game to start
again as soon as GA makes some inroads to largish customers.

>
>I would like to open the discussion up a bit further Rick. Is there
>any high speed embedded bus serial peripheral interfaces? All this
>bit banging really restricts speed, and the serial interfaces I have
>found are rather slow. Pity there is no embedded usb go 2 or 3 like
>standard to bring a wealth of easy interface periphials and memory.
>Even just a high speed memory interface you could use for code or
>data.
>
>Steve.

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Brad Eckert]

On Wednesday, May 1, 2013 8:14:24 AM UTC-7, Steve wrote:
> What we have is basically a
> microcode alternative, so very flexible. Maybe what is really needed
> for a first edition is a code translator to forth, to misc, or just a
> android virtual engine. Code fragments can be translated to native
> misc required progressively afterwards.

Android apps are JIT-compiled from Davlik bytecode (a register oriented VM) to native at installation time. A 1 GHz ARM9 can't be replaced by a 1 GHz MISC, and even if it could, the GA cores run on their own chip. How would Samsung put an array of async cores on their SoC, for example?

I'll admit, though, that I hate Android because of its power consumption. It turns on apps I don't need and leaves them on, draining the battery. It's like living with kids who can't be bothered to turn off lights. And then the automatic updates replace old quirks with new quirks and find new and creative ways to waste power.

I understand, one can't just sell "snakes and sparklers" (scene from Joe Dirt), but supporting a large OS isn't a MISC sea-of-processors thing.

[Steve]

> Groetjes Albert
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Pity, to settle for so little, I thought it was Mr Moore on his back.

He should get himself subpoenaed the next time Congress enquires about
the state of the sector in such things. Maybe a good man can get the
laws changed in relation in such things. Would make a great film, Mr
Moore goes to Washington. Are there extensive biographies on him? In
a way, this is the makings of a block buster film. Are there writuos
about these things. Not like Mr Jobs, Mr Moore has more substance.
Moore, that is a good working title, throw in meetings or parralel
histories, or references, of the other two or three famous Moore's in
the computer industry as a sideline. In the end Mr Moore's techniques
might be the answer to keeping Moore's law until we shift out of
silicon. Just random structured thoughts.

[Jason Damisch]

On Wednesday, May 1, 2013 9:54:56 AM UTC-7, the_gavino_himself wrote:

> oracle must die

LOL

[Steve]

Brad Eckert wrote:
> On Wednesday, May 1, 2013 8:14:24 AM UTC-7, Steve wrote:
> > What we have is basically a
> > microcode alternative, so very flexible. Maybe what is really needed
> > for a first edition is a code translator to forth, to misc, or just a
> > android virtual engine. Code fragments can be translated to native
> > misc required progressively afterwards.
> Android apps are JIT-compiled from Davlik bytecode (a register oriented VM) to native at installation time. A 1 GHz ARM9 can't be replaced by a 1 GHz MISC, and even if it could, the GA cores run on their own chip. How would Samsung put an array of async cores on their SoC, for example?
>
> I'll admit, though, that I hate Android because of its power consumption. It turns on apps I don't need and leaves them on, draining the battery. It's like living with kids who can't be bothered to turn off lights. And then the automatic updates replace old quirks with new quirks and find new and creative ways to waste power.

Brad, I have similar regrets about Android, but I am happy to hear
they have gone VM machine independent, that frees up the ability to to
do Android on Misc a bit. Brad, the jit, is that the expected
standard (writing a purely interpreted version is not supported).
Also, most importantly, is the complete standard OS, api's, module,
divers etc code base for a complete os implementation all in bytecode,
and able to be jit? Going one more step, is the byte code relatively
simple with no outside code use as part of its internal standard VM
standard (API's etc as part of the byte code). If so, then that would
help.

About the 1ghz arm to misc thing Brad. Remember I'm only saying very
little for present misc, so you might look at some advantage at some
low end performance range. If there were Just in Time Android
embedded standard,that might be good for that. But I am saying that
it needs ernhancements to do more. So, present x18 might be useful,
with unamed enhancements more use full in the low end alternative.
One named is a wide execution space, but that has debatable size og
benefit. But we would really need 32 bit with unamed enhancements to
get in to the high end stuff, such 1ghz+ arm 9+. even 64 bit for Arm
64 bit. High end x86 could be achieved on lesser hardware performance
first due to increased disparity in permformance density and energy
consumption per mw compared Arm. The other interesting thing is that
we only need so many cores to emulate, which means that space to
space, many more emulated x86's and Arms could fit in. So you see my
reasoning, the Misc does not have to emulate at full speed but ever if
they can achieve only an emuated density yo match the original Ghz
performance, the other potential is the fine granduality of of sync
processing allowing power savings.

The finale piont, is that I did say it has not been tried out on a
descent process, which will be many many times smaller than what they
have released, anfpd faster and lower powered per performance. As I
am talking about a few years of progression up the market, with
success before you use those processes. Even with an leading process
today, such as Intel's one, are you really saying a 10ghz Misc array
with basic enhancements, can not match even a 1ghz Arm, even ten of
them? What is happening is not the reality of what is possible
today. But Misc has no power and finance to reach this by now. I
know the 10ghz is a bit forced rather tan true lowest power speed.

About Samsung using it, it is a new alternative buying decision.
Unless you pack it in a pin compatible chip, when propkr commit they
face similar board decign process as to using an arm of x86 instead.
So, in that case, not such a bigger deal to what they would have
done. Program wise, it is as an original arm, or enhanced.


Thanks Brad, but there is a solution.


Steve.


Here is some of what I said originally:
(I did delete a couple of sections before posting the original thread,
to conserve some solution IP I'm interested in myself.)

[Steve]

Brad, I forgot to add, about my questions, I'm an Android user, not an
Android or Java programmer, so am only partly familiar with its
system. It is just that is where the people and market is at. I'd
rather our own system myself, but even then there is no apps for
people to by.

I also forgot one other vital argument. with native code support,
people could program misc code directly and native misc products could
be built selling as Android machines.

[Steve]

Sorry for an update so soon, but a significant decision to go ahead
has come up. (Because this is a significant update, I'll follow up
with the original post and more recent update with newer information
down the end for context. Just igore what you have Reader.):
------------------------------------------------------

As there seems little interest so far (though it is still early and
likely will give it a couple of months to see if enough people are
interested) I might consider completing my commercial open source
license, opening a website by end of the year and bring forwards a few
projects and do the simpler versions here, rather than the more
complex original versions. It would be too much to do the original
versions at the moment, but the simpler versions would be easier and
have enough of a bang per buck to be worth it. As such I'm going to
have to base the base design branching, on my more complex designs, to
make it suitable to be used as part of them in future, and therefore
need to cover it with the commercial open license.

I'm interested in the simple Open OS, the firmware os, and the ring,
new nickname, also as a fun thing to annoy late coming competitors, is
Ring of Power (unfortunately Steve J is gone, he would at least
thought it ironically amusing). That will require a few drivers, and
I probably need help of more experienced people than me to do these
well. The JIT Android or Java is just going to be too much to do.
I'm still interested in finding out about the suitability of a cut
down versions of these. I do have two other more major priority
projects, to do and maybe kickstarter like funding from one of them.

Anybody is welcome to come and help. businesses and all, or even start
a public domain alternative instead, but a heads up before I start
would be appreciated. We will see in the future.

Hopefully we can expand the Misc eco system a bit more.

I will followup with some questions for suggestions on which parts
would be best, as a few people around here get to see a lot of parts.
It will break down to components for wireless, memory, storage, other
IO, speaker/mic, battery, touch, in that order of need. Open api's
and interfacing to open api's. But very important questions would be
chips that integrate most of the components and interfaces, or basic
all in one processor chips that integrate all these that could be used
as a slave, preference on cheap. Even a 66mhz Java/Android capable
chip is great. That are basically the range of questions I'm looking
at. There is a sea of components but a few really good ones hit the
enginnering press people may have noticed. Anybody have any ideas?


The Ring of Power is now the likely $10+ cost ring to allow for all in
one use. If it can still be $1 cost, fine.


Steve.

[Steve]

Original post, update. and newer information down the bottom.
*************************************************
Original

http://armservers.com/2012/10/03/here-comes-the-emulators-ee-times-ar...

*********************************************
Update

I have had some developments in thought in the last few days on these
projects. So I am posting an update here of recent posts discussing
this.

// $1 computer

Thanks to Roberto again.

rfduino? See:
> http://www.kickstarter.com/projects/1608192864/rfduino-iphone-bluetoo...
> --
> Roberto Waltman

Yeah, that is the sort of thing, but maybe a little smaller. Nice.
Love the stackable expansion, being wanting to try something like
that
for decades. Wasn't mmc/sd card originally meant to be stackable
IO?
If only wireless usb had succeeded, wireless use would be more
expansive. BT is supposed to get a speed boost, wifi has no wide
peripheral standards. BT could be implemented as one of the
industrial derivatives to reduce complexity.

I am thinking, that such a device could be implemented in this size,
like it is here, but with wireless etc on the back of the board.

Just a commodity consumer interface, if wifi can be done simpler,
than
that is great too. The industrial light derivatives are
interesting,
but lower speed.

// Android and Linux on Misc, simpler: code translators and a virtual

engine might be as simple as a processor emulation.

What we have is basically a
microcode alternative, so very flexible. Maybe what is really
needed
for a first edition is a code translator to forth, to misc, or just
a
android virtual engine. Code fragments can be translated to native

misc required progressively afterwards. When we think of it, is a
virtual engine going to be any harder than emulating a processor,
but
gives you the code base instantly. I should have put that old one
between this and the previous one. It is all compromise.

// High speed serial onboard memory and peripheral interfaces.

I personally hope for large address space 18 and 32 bit designs to
run
large code fast. Even 18 bit is great for my purposes.

I would like to open the discussion up a bit further ..... Is there

any high speed embedded bus serial peripheral interfaces? All this
bit banging really restricts speed, and the serial interfaces I have
found are rather slow. Pity there is no embedded usb go 2 or 3 like
standard to bring a wealth of easy interface periphials and memory.
Even just a high speed memory interface you could use for code or
data.

// Simpler Firmware OS and thread.

Pretty excited about it, the more I think about it, the more I
realise
I could do some of this stuff sooner rather than latter. But the
schedule is to do other things. This thread represents years of
experience and planning out there for the communities benefit, if
they
choose it, I certainly couldn't afford to fund it myself any time
soon. Nobody is putting their hands up, or enthused yet. When I
was
writing up the description of the OS, I thought, hmm this is pretty
significant functionality. and something I could do. Of course the
interfacing is where it can go obscure for being an easier job, and
without it is not so significant in functionality. Remote API
interfacing is basically writing different drivers. Mr Moore sees
things in terms of what was done, part experience, but what if it
can
be done differently. What if we can get 90% of the true embedded
programming benefits of an simple OS in basically what is an
extension
to firmware, a Firmware OS, in 256-512 words. I think that is
something he would love very much...

// The $1 computer ring again

....The ring thing is starting to look
to me like when a drunk sees a pretty woman. If I am allowed to
carry
over the GA engineering, instantly I have much of the non ring
basics
for free. It must be in delusion, it can't be that simple (still a
tall order). A first edition can drop any more complex interface,
to
proof it. The issue, where the external ram and flash memory,
maybe
there is a combo chip that has most of what is wanted, maybe stick
it
on that small RFduino mentioned in the $1 computer thread, as an
expansion board, maybe get the cheapest arm all in one combination
chip and put it on one side and misc on the other, or underneath.
Yes, that is probably the easiest solution, interface a low low end
all in one to a misc chip, as long as you can pull data off the
chips
address bus to form a external memory for the misc chip, it will
probably be cheaper to use That part than to buy and use external
memory and wireless parts, and to write all drivers and interface
them. What do you think....?

***************************************
Recent


JIT
...VM machine independent, that frees up the ability to to
do Android on Misc a bit...

About the 1ghz arm to misc thing ..... Remember I'm only saying very

Thanks .....

_____________________________________________

[Albert van der Horst]

In article <1feed152-5fbb-4c46...@li6g2000pbb.googlegroups.com>,
Steve <nosp...@gmail.com> wrote:
<SNIP>

>
>
>The Ring of Power is now the likely $10+ cost ring to allow for all in
>one use. If it can still be $1 cost, fine.

You realize that the processor of the Launchpad is $1.10 in sufficient
quantities, right now? The cost of the Launchpad is in the USB.

So mounting the Launchpad on a bed of nails, could provide you with
$1.20 thingie, almost there. And


>Steve.

[Steve]

Albert van der Horst wrote:

> In article <1feed152-5fbb-4c46...@li6g2000pbb.googlegroups.com>,
> Steve <nosp...@gmail.com> wrote:

> >The Ring of Power is now the likely $10+ cost ring to allow for all in
> >one use. If it can still be $1 cost, fine.
>
> You realize that the processor of the Launchpad is $1.10 in sufficient
> quantities, right now? The cost of the Launchpad is in the USB.
>
> So mounting the Launchpad on a bed of nails, could provide you with
> $1.20 thingie, almost there. And

Thanks Albert, I don't know in which way you are meaning this.
"Nails...$1.20 thingie. almost there. And"

We are talking about a sub postage stamp sized reference platform that
can go in a lot of places and devices, not just rings. So parts have
to fit the size. All components would have to fit in 10-15mm squared
(less preferred). I know how important it is to get an optimum
solution. You could sell an arm version like others, but you can
sell a misc version at a premium. All serious, the only hobby is
doing it, no need to poke fun.

To put it simply, it doesn't matter which integrated processor to add
ultra
low cost co-functionality. If a integrated 8052 could do it, it could
get on the list. On the more expensive $10+ budget, Arm might be the
preference. But ultimately you have to think pricing components in
lots of 100k to 10m realistically for a successful high volume product
reference design. So misc pricing goes down too. A low volume hobby
product might cost $100+.


Thanks


Steve.

[Steve]

Was talking to Gavino elsewhere about him doing a forth web browser,
and talking about JIT Android and Java here, and it occurred to me
they expanded the functionality of JavaScript recently. I was
wondering, just how significant is javascript out there, is there any
real code base at all, or is it just half useful online development?


Thanks


Steve.

[Steve]

**Andoid & Java

I spent over 10 hours again going through pages on these subjects.
Thanks be to God for Wikipedia. Once you find out the first thing,
Wikipedia gives links, and links to competitors, but finding out where
to start is the issue.

Android seems to better for use than Java, but for us it is a mess.
Does not seem anybody had the thought to rewrite the Linux code to
Dalvik code for simple cross platform portability, but not only that
code can be written in c assembler etc, and apps are not restricted to
the Dalvik run time environment (which like the Java run time
environment, I can not find a simple summary layout description of to
guage complexity). They do not even have a simple portability
interface methird to quickly transfer Android onto of the
manufacturers linux and hardware drivers choice and their interface
front end chioces, taking months for manufacturers to update to new
versions, instead of plug and play and weeks of refunement. It is
also a mix of licensed software. So, to transfer the environment is
a big effort.

But I did find an alternative commercial Dalvik Alien to run apps on
other OS's. that maybe would imply many apps can run through Dalvik
without Android itself, so that is a viable option to make something
like that. On top of this I found a free software Android clone,
Replicant. that could form the basis of such a thing (with code
translation).

Even if c++ to forth is not available, c++ to c should which can
translate to forth. Better still, there are Dalvik to c ? translation/
compiling, and probably the opposite way around. So, once the Dalvik
engine is in, and the non dalvik code put in forth, you could just use
the engine to translate the rest into forth/misc code. So, if apps
are mostly Dalvik dependent there might be little coding past the
engine and interfacing. If anybody is wanting to do this, I would
advise them to go to the Replicant people with the idea of them making
a pure Dalvik version that can be easily transferred to new platforms,
and volunteer to do a misc version with it. Once GA gets the
independent development environment out, you have the start of a
reference platform.

However, apps have directories for various Arm, x86 and Mipd code. I
do not know if they require alternative Dalvik code for all these
incase of incompatibility. It is hard to appreciate they missed all
this, because I previously took in to account all these things in my
own work many years ago

http://en.wikipedia.org/wiki/Dalvik_(software)
http://en.wikipedia.org/wiki/Replicant_(operating_system)
http://en.wikipedia.org/wiki/Dalvik_Turbo_virtual_machine


Java, it is a pity they scrapped the Java OS (but I did not check for
freeware alternative OS). Years ago they forced interpreted Java, and
it was slow and did not handle multiple instances as well. I would
imagine that is one of the reasons why the OS got scrapped. But then
they moved to Just In Time compiling, which I was very happy of as I
knew the benefits for work, and the speed, while still lacking to c,
is much better, which would have made the OS a viable platform.

The good news is that, if you made a Java runtine environment,
translator and interfacing. it is all Java. So, it then should be
significantly easier to translate it in with a pure Java OS, than
Android, even with the c/c## translation replicant stratetergy above.

However, Java is a mess to me, bits and pieces all over the place. If
you don't need it and it is not used by most users. why include it in
the specification, just leave programs add it if they need it. I
loved around for a simpler version of Java. but Java ME, which is what
most mobile apps are made for, only allows 64k for each app, after the
last update. Desktop Java is huge. Javacard, which might suit the
rung platform better, is the only stripped down version I can find,
even the instruction set is stripped down. However, maybe the
minimum form factor of functional Java is smaller, and there is a
suitable PD Java OS?

http://en.wikipedia.org/wiki/Java_SE

I found this comparison page of virtual machines, most of which I dont
know, but maybe some of them might link in with some Java OS's. But I
found one amusing one, "Forth".

http://en.wikipedia.org/wiki/Comparison_of_application_virtual_machines


Thanks again


Steve.

[Andrew Haley]

Steve <nosp...@gmail.com> wrote:
> **Andoid & Java
>
> I spent over 10 hours again going through pages on these subjects.
> Thanks be to God for Wikipedia. Once you find out the first thing,
> Wikipedia gives links, and links to competitors, but finding out where
> to start is the issue.
>
> Android seems to better for use than Java, but for us it is a mess.
> Does not seem anybody had the thought to rewrite the Linux code to
> Dalvik code for simple cross platform portability, but not only that
> code can be written in c assembler etc, and apps are not restricted
> to the Dalvik run time environment (which like the Java run time
> environment, I can not find a simple summary layout description of
> to guage complexity).

This is very confused (and confusing). Android apps are usually
written in Java. They run on the Dalvik virtual machine. As far as I
know, all Android machines run Linux.

> Even if c++ to forth is not available, c++ to c should which can
> translate to forth.

What does this mean? What is "c++ to c" ? How can it translate to
Forth?

Andrew.

[Steve]

***** A misc run time engine for Android and Android use on Ring

After researching Android and Java on misc possibilities, I came to a
couple of conclusions:

While it would be preferrable to have Android on Misc to build market.
even Java, it would be good and easy, to make a Misc runtime engine
for Android.

This would enable misc processor cells and misc code to be used on
Java devices. It would enable android hardware to use misc, or revert
to Dalvic etc versions of code, or for misc code to be translated to
Dalvic (possibly arm/mips/x86) anyway you want to do it. But it allows
the misc code to use all the api's of the Android system, and for
Android apps to locate and use a Misc 32/18 bit coprocessor. They are
the options to choose from for a finale solution. Then with hardware
maker backing, it can be apply for to be incorporated into the Android
standard. Even if it doesn't get approved it can in effect act as a
driver for using misc cells in a design, and making misc devices.


******

The other decision, is to look at using a Android chip platform in the
ring to offer interface/ API services to the misc chip. So, I could
actually use something like the misc run time engine above, but will
look at just interfacing the simple OS to Androids system for
services, as a test proof of concept.

As I am not actually running an Android system with external apps,
even the cheapest integrated all in one solution will do just to run
the hardware and offer services, even a 66mhz solution.

What does anybody think?


Thanks


Steve.

[Steve]

****Mini update. Firmware OS size.

I think the simple os will be closer to 10k words eventually now that
I'm doing a commercial version, rather than the 256+ word PD version I
was suggesting as a community project before.


*Andrew, I will have to get you in a few posts.

[Mark Wills]

> http://en.wikipedia.org/wiki/Dalvik_(software)http://en.wikipedia.org/wiki/Replicant_(operating_system)http://en.wikipedia.org/wiki/Dalvik_Turbo_virtual_machine

I can't make head nor tail of this. It's a confused, rambling stream-
of-consioucness thought-dump.

Please collect your observations together in a more coherant manner
and re-post.

I'm interested, but I can't follow it, unfortunately. :-(

[Elizabeth D. Rather]

On 5/2/13 11:03 PM, Andrew Haley wrote:
> Steve <nosp...@gmail.com> wrote:
...

>
>> Even if c++ to forth is not available, c++ to c should which can
>> translate to forth.
>
> What does this mean? What is "c++ to c" ? How can it translate to
> Forth?

In any case, all attempts to convert C (or C++) that I've seen or heard
of produce truly awful Forth (slow, bulky, unmaintainable) because the
architecture and internal economics of C and Forth are so entirely
different. An architect knows better than to try to use methods intended
for bricks when building in steel and aluminum, or vice-versa. You need
to use any building material as it was designed to be used, and
programing languages are no different. Translators can work for
languages that are inherently similar, but Forth is so different in its
architecture that it is impossible to get a good result.

We often find that we are given a driver or algorithm in C that we need
to use in Forth. What works is to read the code and learn from it the
essentials of what it does, and then code them in good Forth. The effort
pays off handsomely.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Steve]

**** Wireless interfaces.

Well my eyes were going boggled reading through all the different
wireless standards. If they were standard. we should have at least a
combined personal area and general network standard that handles
devices, simply, fast and efficiently. The reality is that we
unforuntately have to use several interfaces to cover things well.

But I have located some good leads.

In the discussion below, I'm also cpsidering a standard for fiferent
and future products.

Bluetooth:
It is a shame that there is no wireless USB or UWB common standard,
but Bluetooth seems to be the only one with any common peripheral
base. However it is slow. very slow, compared to wirelesshd that has
28Gb/s, which in the 60Ghz line of sight range, is a bit unesfull in
this application, and it is bound to be energy intensive. There was
some issue with getting UWB USB into it, so they have cohosted with a
wifi standard, yielding 24Mb/s, but both devices has to have the
seperate wifi to send bt data across it's channel. There is some talk
they will go to a higher speed in future.

Wibree has been incorporated into Bluetooth, as Bluetooth low energy ,
or Bluetooth Smart. Only 270kb/s or so, very slow, but is designed
for devices working of button batteries. Zigbee, 6LoWPan, z-wave,
MyriaNed, MiWi, Dash 7, Ant, Insteon are mainly unsuitable, and Bt has
the low end covered enough. A number are based on IEEE_802.15.4.
But EnOciean energy harvesting wireless. One-net, TinyOS, Osian for
smart dust, and contiki, should be of interest to people around here.

http://en.wikipedia.org/wiki/Bluetooth
http://en.wikipedia.org/wiki/Wibree

IRDA. now has a simplified protocol and does 1Gb/s.

But I was thinking, wouldn't it be good if somebody put USB and other
interfaces over wireless, maybe another product. But I found Wifi
Direct universal plug and play and the future IEEE 802.11ad is also to
have device and interface over wireless support, and low powered
mode. 802.11ad uses 60gb/s but also uses the older wifi bands. So we
have a winner wifi. Interesting to note that Intel has WiGig and
WirelessHD, and older WiDi I wonder if they plan to use the same
hardware when 802.11ad comes out for all of them. Exciting prospects
for the future.

http://en.wikipedia.org/wiki/IrDA
http://en.wikipedia.org/wiki/Wireless_Gigabit_Alliance
http://en.wikipedia.org/wiki/IEEE_802.11ad

http://en.wikipedia.org/wiki/Wi-Fi_Direct
http://en.wikipedia.org/wiki/Universal_Plug_and_Play

So, Bluetooth seems the best option, cohosted with wifi for future
products. So I want to look for bluetooth, wifi, and combination
products. Preferably with processor hosting the the software and/or
android. Still open to parts to run it all from misc as well. I
came up with a very innovative alternative that I was considering
previously, while writing this that would severely simplify this.


Some others:
http://en.wikipedia.org/wiki/Wireless_USB
http://en.wikipedia.org/wiki/TransferJet

I did find this page on node chips, but no wifi with BT:
http://en.wikipedia.org/wiki/Iris_Mote

[Roberto Waltman]

Albert van der Horst wrote:

>You realize that the processor of the Launchpad is $1.10 in sufficient
>quantities, right now? The cost of the Launchpad is in the USB.
>
>So mounting the Launchpad on a bed of nails, could provide you with
>$1.20 thingie, almost there.

As a reference, a low end STM32 (F0) is US$ 0.70 in "large enough
quantities"
--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]

[Steve]

***** Faster embedded Serial buses.

I looked to try to find a newer fast on board serial bus, as I was
asking previously, but all I found was SPI Multi I/O. That is still
only around 200 Mbit/s.
http://en.wikipedia.org/wiki/Serial_bus .wikipedia.org/wiki/
Serial_Peripheral_Interface_Bus#Related_terms

I also found embedded SD card interface;
http://en.wikipedia.org/wiki/Secure_Digital

I found these lists, but don't know if they are up to date on embedded
serial busses:
ttp://en.wikipedia.org/wiki/List_of_device_bit_rates#Computer_buses
http://en.wikipedia.org/wiki/Serial_bus

These things are very slow for this age, you would think they couild
make something faster with some signaling standard like,
HyperTransport, QuickPath Interconnect , DDR5, cube, USB 3 signaling,
anything. It is a shame that nobody in the industry is trying to do
this. A multimode system, could have a 1/8/16/32/64 bit buffer simple
asynchronouse mode that is transperantly pushed over a serial bus, at
a async or clocked out as it arrives in second mode, a memory mode,
and a DMA mode. Memory and dma mode are auto, or set by async
stepping. Sync operating on burst or continuous. Negotiation on mode
by manually setting it and acceptence of hosts, or request to slave.
The usable data width set to 1/8/16/32/64 bits according preference
and max common width, and mode by common supported modes. Simple fast
interfacing. Just some thought.

The important thing is to find something with suitable speed and
parts.

[Steve]

Elizabeth D. Rather wrote:
> On 5/2/13 11:03 PM, Andrew Haley wrote:
> > Steve <nosp...@gmail.com> wrote:
> ...
>
> >
> >> Even if c++ to forth is not available, c++ to c should which can
> >> translate to forth.
> >
> > What does this mean? What is "c++ to c" ? How can it translate to
> > Forth?
>
> In any case, all attempts to convert C (or C++) that I've seen or heard
> of produce truly awful Forth (slow, bulky, unmaintainable) because the
> architecture and internal economics of C and Forth are so entirely
> different. An architect knows better than to try to use methods intended
> for bricks when building in steel and aluminum, or vice-versa. You need
> to use any building material as it was designed to be used, and
> programing languages are no different. Translators can work for
> languages that are inherently similar, but Forth is so different in its
> architecture that it is impossible to get a good result.
>
> We often find that we are given a driver or algorithm in C that we need
> to use in Forth. What works is to read the code and learn from it the
> essentials of what it does, and then code them in good Forth. The effort
> pays off handsomely.
>
> Cheers,
> Elizabeth

Yes true, Elisabeth. I'm only giving a compromise option, as one of
the options on that subject, as it would be too big to handle recoding
it all. I'm looking to just use a low end android arm system to
interface to instead myself. Then it csnbe used for services. But if
anybody really wants it (there are people that have wanted Java in the
past) its there, as horrible as it would be. I think we need to
write our own alternative in the community.

Thanks.

Steve.

[Steve]

Mark Wills wrote:
> On May 3, 9:37 am, Steve <nospam...@gmail.com> wrote:
> > **Andoid & Java
> >
> > I spent over 10 hours again going through pages on these subjects.
> > Thanks be to God for Wikipedia.  Once you find out the first thing,
> > Wikipedia gives links, and links to competitors, but finding out where

> > to start is the issue..

> I can't make head nor tail of this. It's a confused, rambling stream-
> of-consioucness thought-dump.

Sorry Mark. I did miss some auto spell check typos in a few places,
and the links seem to be messed up. But it is pretty clear, straight
forward and coherent, except in two small places I got wrong. It is a
summary of the state of play Mark, so it is fairly dense information
and observations. Not as hard as some Forth code though. :-)

> I'm interested, but I can't follow it, unfortunately. :-(

Please try re-readimg it, and the thread Mark, it is about what was
posted before and in the links I posted, incase any information is
unfamiliar or unclear.


I've just spent around 30 hours on just this, and am unlikely to
rewrite it. So much for the 40 hour work week. :-)


Steve.

[Steve]

Sorry for the delay Andrew.

Andrew Haley wrote:
> Steve <nosp...@gmail.com> wrote:
> > **Andoid & Java
> >
> > I spent over 10 hours again going through pages on these subjects.
> > Thanks be to God for Wikipedia. Once you find out the first thing,
> > Wikipedia gives links, and links to competitors, but finding out where
> > to start is the issue.
> >

>

> This is very confused (and confusing). Android apps are usually
> written in Java. They run on the Dalvik virtual machine. As far as I
> know, all Android machines run Linux.

A summary of the state of play concerning these languages and
transferring them to misc. Dense infitmation and observations.
Pretty straight forward and clear. They reference on pteviouse posts
and the links. sp best to read them if unfamiliar. Do you know Mark?

The Java code is translated to the Dalvik virtual engine etc, because
Android is not truely Java and does not have all the same Java API
set. A real anmoying situation and I don't know if they are repairing
this at all.. You don't have to code all in Java or Dalvik, you can
go native processor code. Great parts of Android are written in C
etc, like Linux. It is really a bit of a b.. system, and the same to
transfer it to Forth, as Elizabeth showed, but its there if anybody
wants it.

>
> > Even if c++ to forth is not available, c++ to c should which can
> > translate to forth.
>
> What does this mean? What is "c++ to c" ? How can it translate to
> Forth?

OK, that is an easy one, there has been code written that can read C
code and produce equivalent forth code, others that can translate
Dalvik to C or C++, I forget, but of course you can compile C etc to
Dalvik, that is what tranlators do.

> Andrew.


Thanks


Steve.

[Steve]

A few people have expressed doubts about emulating other processors on
Misc, but I can assure you that I have strategies to deal with this. I
have been leaving out a few things for comercial reasons, some
concerning my long term work. There are a few strategies that will
speed this up many times on average. On the recent matter of code
translation, It is not going to be pretty, but I wouid take advantage
of Misc pionter that old forth did not have, and put structures in
memory. Again, using a new upgraded 18/32 bit mass array should
compensate a lot for the code speed. Over 100 nodes in a chip is
getting to be a mass array. There are many strategies to skin the
cat.


** Another idea for Android on Misc.

Compile Android to Arm/mips/x86/Dalvik. to Misc code, or emulate, then
translate new code generated from Dalvik. Still not pretty.

[Stephen Pelc]

On Fri, 3 May 2013 01:37:52 -0700 (PDT), Steve <nosp...@gmail.com>
wrote:

>Even if c++ to forth is not available, c++ to c should which can
>translate to forth.

See
http://www.mpeforth.com/arena.htm
and look for
C2ForthKit120.zip

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Albert van der Horst]

In article <7b52b9d7-2838-4a1c...@pl9g2000pbb.googlegroups.com>,
Steve <nosp...@gmail.com> wrote:
<SNIP>

>Even if c++ to forth is not available, c++ to c should which can
>translate to forth.

Remember the "waste millions" stories of Elizabeth Rather?
Converting c to Forth is a bad idea. Converting C++ via C makes
it hard to take a person serious.


>Thanks again

[rickman]

On 5/1/2013 12:23 PM, Steve wrote:
> On May 1, 3:35 pm, rickman<gnu...@gmail.com> wrote:
>> On 5/1/2013 10:58 AM, Steve wrote:
>
>
>>> rickman wrote:
>>>> On 4/29/2013 5:31 AM, Steve wrote:
>
>>> I think it might be possible they want to sell an andreno like device,
>>> which would be great if they take advantage of one of the expansion
>>> board systems out there. I would be interested in something like
>>> that.
>>
>> I understand why they don't make hobbyist type boards, they don't want
>> to support onesy twosy stuff. They only have time for large customers.
>> That is pretty clear when your company is so small and running in
>> startup mode.
>>
>> --
>>
>> Rick
>
> But how much money has Mr Moore gotten from the settlement, and what
> contracts have they landed? Everything is a bit quite, and there is
> likely a logical reason for it.

Yes, things are quiet because they don't have much to say. Not many
companies will talk about their customers because the customers prefer
that.

Don't confuse Chuck Moore and Green Arrays. GA is not his company. I'm
not sure how much he is involved on a day to day basis. His blog, which
has not been updated in some time now, seems to indicate he is off doing
his own thing and not working directly for the company. I seriously
doubt he is a major investor either.

> If they have a big order then chips
> will be cheap, and with a few insiders to run support forums, then
> maybe.

Read Chuck's blogs. He mentioned how many chips have been ordered and
if you do a little math, as someone did in a thread here a month or two
ago, both the initial and the current order of chips were really just
the minimum quantities they can buy, in essence, prototype runs for the
fab. If I am wrong, someone please correct me. So they may be selling
some chips, but it is hardly "big orders" they are getting.

Do a little more math and at the price they are selling they need to
have *much* larger production quantities in order to fund even a small
company. Right now they appear to be running in sweat equity mode with
very low or no salaries.

> Some of the interest from seaforth days should be carrying
> over to orders at GA, like the BMW interest. Now GA might have funds
> to establish their development agenda, and rights, some orders might

> come through. I personally hope for large address space 18 and 32

> bit designs to run large code fast. Even 18 bit is great for my
> purposes.

Agree that 18 bits is not a bad size for embedded CPUs. I think the
fact that it is 18 bits rather than 20 bits (four full instructions per
memory word) says something about Chuck's obsession with "minimal".


> I would like to open the discussion up a bit further Rick. Is there

> any high speed embedded bus serial peripheral interfaces?

Yes, I believe there is something called USB which can get up to 480
Mbps in version 2.0 and some odd 3 Gbps or more in version 3.0. The GA
eval board uses serial port converter chips to connect to a host PC
which is much more limited in speed. I think you might be able to
implement the "full speed" mode at 12 Mbps in a GA144 directly if you
worked hard enough at it. But as is typical with GA and even Chuck
Moore things, the protocol would likely be "dumbed" down and not fully
featured. One limitation is memory as I believe USB *requires* buffers
which are too large for the GA144 chip itself. It would be hard to
provide a memory connection at sufficient rates to keep up with "high
speed" USB at 2 * 60 MBps.

> All this
> bit banging really restricts speed, and the serial interfaces I have
> found are rather slow. Pity there is no embedded usb go 2 or 3 like
> standard to bring a wealth of easy interface periphials and memory.
> Even just a high speed memory interface you could use for code or
> data.

"High speed" memory interface is a bit of a misnomer. High speed is
what, perhaps low 10's of Meg transfers per second? That's extremely
slow by today's standards. They need to give the chip some real I/O and
a real memory interface. They did a software Ethernet interface which
supports 10 Mbps only and likely not a full TCP/IP, although I'm not sure.

Someone once said here that Charles Moore is not so much a chip designer
(in the sense of useful products) but rather is more of an inventor. At
first I disagreed, but once I learned more about the chip I realized
that is pretty much on target. Even ignoring the marketing driven
aspects that most companies would push for in a multi-CPU chip, just
from a purely technical perspective I think the GA144 lacks a great deal
and nearly any other company would have given it some hardware based,
high speed interfaces. If I was in the decision making process, I would
be pushing hard for it to have multi-volt I/Os like nearly *all* FPGAs
have and even most MCU chips.

If you want to do something with MISC, you need to define it clearly and
I wouldn't tie it to the Green Arrays product line. They may not even
be in business in a few years. As yet, I have no feel at all for what
you are trying to do. If you can't explain it succinctly and clearly, I
think it means you don't properly know yourself.

--

Rick

[Elizabeth D. Rather]

On 5/1/13 11:21 AM, rickman wrote:
>
> Don't confuse Chuck Moore and Green Arrays. GA is not his company. I'm
> not sure how much he is involved on a day to day basis. His blog, which
> has not been updated in some time now, seems to indicate he is off doing
> his own thing and not working directly for the company. I seriously
> doubt he is a major investor either.
>

It is very much his company, which the previous incarnation, Intellasys,
was not. The President is Greg Bailey, who has been a colleague of
Chuck's for 40 years, and the other principals are also long-time
colleagues and friends.

It is true, though, that Chuck's designs are driven by internal
concepts, which are often brilliant but not at all market-driven, which
has been a problem for those of us wanting him to see success for many
years.

[Steve]

Albert van der Horst wrote:

> In article <7b52b9d7-2838-4a1c...@pl9g2000pbb.googlegroups.com>,
> Steve <nosp...@gmail.com> wrote:
> <SNIP>
> >Even if c++ to forth is not available, c++ to c should which can
> >translate to forth.
>
> Remember the "waste millions" stories of Elizabeth Rather?
> Converting c to Forth is a bad idea. Converting C++ via C makes
> it hard to take a person serious.
>
>
> >Thanks again
> >
> >
> >Steve.
>

I have to go out, but am just quickly posting to say, that these are
only ment as desperate solutions, of last resort to start before you
do a proper version with the support of many volunteers. I took that
conversion was sreamlined automated, so code maintenance in forth
would not be an issue when it is meant to be maintained in C. I
understand certain parts will be hardware dependent and still have to
hand written in forth. As for desperation tatics, if you have no c++
to forth, you have no other relatively easier options. Please
everybody chill out and take my comments as they were seriously
balancely meant. If anybody still disagrees, they can try to hand
translate all the c and c++ code to forth and see how long it takes.
I did suggest direct coding of smaller portions, but to hand translate
everything to forth might take a life time.


Thanks very much for your patience.


Steve.

[Elizabeth D. Rather]

On 5/4/13 10:04 PM, Steve wrote:
>
...

>
> I have to go out, but am just quickly posting to say, that these are
> only ment as desperate solutions, of last resort to start before you
> do a proper version with the support of many volunteers. I took that
> conversion was sreamlined automated, so code maintenance in forth
> would not be an issue when it is meant to be maintained in C. I
> understand certain parts will be hardware dependent and still have to
> hand written in forth. As for desperation tatics, if you have no c++
> to forth, you have no other relatively easier options. Please
> everybody chill out and take my comments as they were seriously
> balancely meant. If anybody still disagrees, they can try to hand
> translate all the c and c++ code to forth and see how long it takes.
> I did suggest direct coding of smaller portions, but to hand translate
> everything to forth might take a life time.
>
>
> Thanks very much for your patience.

You'd be surprised. Back in the 80's, we were doing a lot of work for
GM, related to the (then) new Saturn plant in TN. At one point, they
wanted to use their MAP standard protocol, but thought it would be
prohibitively expensive to code in Forth, because their working version
in C had cost >$1M. We coded it from scratch in just a couple of months.
Given the complexity of that protocol, I'm sure if we had had a
translator it would have taken at least that long just to test the
translated code, fixing all the bugs, etc. And our version was much
smaller and even faster than theirs.

In general, if you have a working version of something, you have worked
out all the kinks in the spec and have a good handle on the algorithms.
Those are the biggest hurdles and take the most time in the original
development. Given Forth's interactive development nature, recoding goes
surprisingly quickly.

[Albert van der Horst]

In article <P7qdnXc8NM3cihvM...@supernews.com>,

That is a good realistic technique. I had to recode a program in assembler
(not C, but it doesn't matter much). They had had some comsultants earning
a multiple of my fee to define the specs. Those were pretty worthless,
especially wiht respect to error situations,
and I gave them a couple of sheets, with examples to run through their
old software. Never looked at the assembler code. That was another
success, it was so much faster than the old program that it was
completely IO-bound.

>
>Cheers,
>Elizabeth

[Steve]

Albert van der Horst wrote:

Now I'm finding this difficult, we are talking hundreds of megabytes
of code, even gigabytes (I have not checked Android for size) I doubt
we could even read if it was a book case of books. Elizabeth, Albert,
am I missing something fundamental here?

However, I have been thinking of solutions to this issue, because
ultimately, success gives Mr Moore plenty of money to experiment his
internal motivations, as you have said. A major code base and
hardware eco system is a major boon.

1) I've said that an arm or mips code translator, or emulator, could
take a compile of an OS for such a processor and translate/emulate
that to misc. A perfect translation requires no maintenance, all
maintenance is done in the c etc code.

2) I've talked about a misc c compiler, which could compile the lot,
even a bit of intermediate c code better to emulate on misc.

3) But I've heard of c language written in forth words. Would that be
a suitable option for ease? Is there such code?

What people are not taking into account is that android will run at a
few hundred mhz and even if emulation ran this slow (remember I'm
aiming at enhanced misc designs in particular) as long as you have a
foot in the door you can sell a product to somebody. It is always
trying to make something work out.

So the reality is a c compiler to misc, c in forth, or arm translator/
emulator.

People have talked about kick starting a forth PC, I would like to see
a 32 bit misc kickstart, I however would like to one day be able to
get one with my own modifications. GA takes custom orders, if
everybody got together they could fun it, for shares even, and on the
proviso of design release if GA ceases as it is. Mup21 was developed
like this, and now Mr Moore has worked out how to get designs to work
the firest time, the 32 bit could be done cheaper in todays terms. I
do not want competition, but it would be great for the community, and
we could nominate some enhancements. I'm a believer in low cycle, low
transistor in this respect.

Thanks


Steve.

[Steve]

rickman wrote:
> On 5/1/2013 12:23 PM, Steve wrote:
> > On May 1, 3:35 pm, rickman<gnu...@gmail.com> wrote:
> >> On 5/1/2013 10:58 AM, Steve wrote:
> >
> >
> >>> rickman wrote:
> >>>> On 4/29/2013 5:31 AM, Steve wrote:

>
> > If they have a big order then chips
> > will be cheap, and with a few insiders to run support forums, then
> > maybe.
>
> Read Chuck's blogs. He mentioned how many chips have been ordered and
> if you do a little math, as someone did in a thread here a month or two
> ago, both the initial and the current order of chips were really just
> the minimum quantities they can buy, in essence, prototype runs for the
> fab. If I am wrong, someone please correct me. So they may be selling
> some chips, but it is hardly "big orders" they are getting.
>
> Do a little more math and at the price they are selling they need to
> have *much* larger production quantities in order to fund even a small
> company. Right now they appear to be running in sweat equity mode with
> very low or no salaries.

Sorry Mr Rick, but I believe I was saying that if a company ordered
large enough quantity of chips for a product, the price could come
down to less than $1. So whatever they are making or doing today, or
in the past, in pricing and numbers obviously bears little relation to
this.

>
> > Some of the interest from seaforth days should be carrying
> > over to orders at GA, like the BMW interest. Now GA might have funds
> > to establish their development agenda, and rights, some orders might
> > come through. I personally hope for large address space 18 and 32
> > bit designs to run large code fast. Even 18 bit is great for my
> > purposes.
>
> Agree that 18 bits is not a bad size for embedded CPUs. I think the
> fact that it is 18 bits rather than 20 bits (four full instructions per
> memory word) says something about Chuck's obsession with "minimal".

If you are doing small stuff 18 bits is great, and no memory bus if
you are just passing along and processing things.

> > I would like to open the discussion up a bit further Rick. Is there
> > any high speed embedded bus serial peripheral interfaces?
>
> Yes, I believe there is something called USB which can get up to 480
> Mbps in version 2.0 and some odd 3 Gbps or more in version 3.0. The GA
> eval board uses serial port converter chips to connect to a host PC
> which is much more limited in speed. I think you might be able to
> implement the "full speed" mode at 12 Mbps in a GA144 directly if you
> worked hard enough at it. But as is typical with GA and even Chuck
> Moore things, the protocol would likely be "dumbed" down and not fully
> featured. One limitation is memory as I believe USB *requires* buffers
> which are too large for the GA144 chip itself. It would be hard to
> provide a memory connection at sufficient rates to keep up with "high
> speed" USB at 2 * 60 MBps.

Hmm, my choice of words is worse than your sarcasm I think. By
periphials, I mention onboard chip peripherals, dac, memory, flash,
sensors etc. But this is another issue, yes, as long as you have to
use three cores to pump the soft memory bus at speed (over 90kwords/
s), how much do you have left to high speed parallel interface
anything else. I just remembered, usb is one of the standards for
sim cards in phones, I wonder if there is a point to point version for
on board chips with a large parts list?

>
> > All this
> > bit banging really restricts speed, and the serial interfaces I have
> > found are rather slow. Pity there is no embedded usb go 2 or 3 like
> > standard to bring a wealth of easy interface periphials and memory.
> > Even just a high speed memory interface you could use for code or
> > data.
>
> "High speed" memory interface is a bit of a misnomer. High speed is
> what, perhaps low 10's of Meg transfers per second? That's extremely
> slow by today's standards. They need to give the chip some real I/O and
> a real memory interface. They did a software Ethernet interface which
> supports 10 Mbps only and likely not a full TCP/IP, although I'm not sure.

Yes, how many available lines * several hundred mhz at today process,
not something 64 times smaller, or 512 (by area) times smaller in
future. There are recent memory interface advancements more capable
of keeping up those types of speeds.

> Someone once said here that Charles Moore is not so much a chip designer
> (in the sense of useful products) but rather is more of an inventor. At
> first I disagreed, but once I learned more about the chip I realized
> that is pretty much on target. Even ignoring the marketing driven
> aspects that most companies would push for in a multi-CPU chip, just
> from a purely technical perspective I think the GA144 lacks a great deal
> and nearly any other company would have given it some hardware based,
> high speed interfaces. If I was in the decision making process, I would
> be pushing hard for it to have multi-volt I/Os like nearly *all* FPGAs
> have and even most MCU chips.

Hmm, that maybe an issue to do with the tri state asynchronous
interface signalling between nodes, as it is meant to similarly hook
up arrays of these chips.

Rick I was just thinking of the shboom, and it was a shame that the
original design was not released to the public, I then realised that
Ting did 32 and 64 bit FPGA softcores, and I wonder if they are more
new misc, or very old misc like shboom. But why transfer it to asic,
you could pay GA to do a 32 bit.

>
> If you want to do something with MISC, you need to define it clearly and
> I wouldn't tie it to the Green Arrays product line. They may not even
> be in business in a few years. As yet, I have no feel at all for what
> you are trying to do. If you can't explain it succinctly and clearly, I
> think it means you don't properly know yourself.

I have explained nearly all succinctly and clearly, and repeatedly.
However, my simplified writing tends to be overflowing with succinct
clear detail that people that try to speed and skip and literally
confuse themselves. It is not my fault, it is up to them to think
succinctly and clearly about what thread. What I do if I am confused,
is read it again more slowly.

It comes with the territory of trying to do ten times more, with ten
times less. You must mean more 'simply' and 'lighter', meaning ten
times more writing. Your a forth programmer and engineer, surely you
can read my meager writing. I'm a fan of some ancient languages that
fit three times more in the same space, but so wasteful, why not ten.
You can see I'm a true decipher of efficient minimalism. ;-)

>
> --
>
> Rick


Steve.

[Steve]

Stephen Pelc wrote:
> On Fri, 3 May 2013 01:37:52 -0700 (PDT), Steve <nosp...@gmail.com>
> wrote:
>
> >Even if c++ to forth is not available, c++ to c should which can
> >translate to forth.
>
> See
> http://www.mpeforth.com/arena.htm
> and look for
> C2ForthKit120.zip
>
> Stephen
>

Stephen, thank you very much.

I have had a quick glance at the documentation. I take it this is not
a hands free conversion yet, but still the best in the world?

Thank you for sharing this here so people could use it.

Something I forgot to include in my wireless update, that makes
something like this handy, if it can work very smoothly, is that there
are a number of open source software programs for low powered personal
area networks based on a common ieee standard IEEE_802.15.4, like
Zigbee and 6LoWPan. Still no C++ solutions. I think Ill look around
for Java engine in forth solutions, and c++ to c.

I wonder, what would your opinion on the several options I have listed
to get Android onto future misc chips (removing limitations)?

Thanks again for your help to the Forth community Stephen.



Steve.

[Elizabeth D. Rather]

I am unclear about the objective. If your objective is to have a
C-based, compatible version of Android running on your device, the
easiest way to do this is write a C compiler for the chip. That is *not*
the same thing as a "C to Forth translator" because, although a misc
chip may have support for Forth-like features such as stacks, it has a
machine language that you compile to just like any other processor.

If your objective is a Forth-based OS, that is best written in Forth
from scratch, to a specification. But that is a very different
objective, and the two shouldn't be confused.

> People have talked about kick starting a forth PC, I would like to see
> a 32 bit misc kickstart, I however would like to one day be able to
> get one with my own modifications. GA takes custom orders, if
> everybody got together they could fun it, for shares even, and on the
> proviso of design release if GA ceases as it is. Mup21 was developed
> like this, and now Mr Moore has worked out how to get designs to work
> the firest time, the 32 bit could be done cheaper in todays terms. I
> do not want competition, but it would be great for the community, and
> we could nominate some enhancements. I'm a believer in low cycle, low
> transistor in this respect.

If what you want is an Android device programmed in C, I can pretty much
promise you that GA will not do this for you, regardless of how it's
funded. That's not their business objective, and it isn't something they
have the technical skills to do.

[Mark Wills]

On May 5, 7:10 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 5/5/13 5:46 AM, Steve wrote:
>
>
>
>
>
>
>
>
>
>
>
> > Albert van der Horst wrote:

> >> In article <P7qdnXc8NM3cihvMnZ2dnUVZ_rGdn...@supernews.com>,

> Los Angeles, CA 90045http://www.forth.com

>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

Folk are taking here like Android can't be natively programmed in c
(or C++). It most definitely can. Yes, the recommended, or even
preferred way is in Java on top of Dalvik, but you don't have to. Take
Gforth as a case in point. GForth was ported to Android, but it wasn't
ported to java.

[rickman]

I don't get your point. When you use "if" you are not saying anything
useful unless it is tied to something that you have some control over.
"If" pigs had wings...

>>> Some of the interest from seaforth days should be carrying
>>> over to orders at GA, like the BMW interest. Now GA might have funds
>>> to establish their development agenda, and rights, some orders might
>>> come through. I personally hope for large address space 18 and 32
>>> bit designs to run large code fast. Even 18 bit is great for my
>>> purposes.
>>
>> Agree that 18 bits is not a bad size for embedded CPUs. I think the
>> fact that it is 18 bits rather than 20 bits (four full instructions per
>> memory word) says something about Chuck's obsession with "minimal".
>
> If you are doing small stuff 18 bits is great, and no memory bus if
> you are just passing along and processing things.

You miss my point. Is 20 bits really so much larger that it is
impractical? With 20 bits all of the opcodes can fit in the last nibble
of an instruction. Chuck had to do a lot of consideration to figure out
that hobbling this last opcode position wouldn't be a major issue. I
haven't looked at it, but I think I would have just gone to 20 bits and
not worried about it.

>>> I would like to open the discussion up a bit further Rick. Is there
>>> any high speed embedded bus serial peripheral interfaces?
>>
>> Yes, I believe there is something called USB which can get up to 480
>> Mbps in version 2.0 and some odd 3 Gbps or more in version 3.0. The GA
>> eval board uses serial port converter chips to connect to a host PC
>> which is much more limited in speed. I think you might be able to
>> implement the "full speed" mode at 12 Mbps in a GA144 directly if you
>> worked hard enough at it. But as is typical with GA and even Chuck
>> Moore things, the protocol would likely be "dumbed" down and not fully
>> featured. One limitation is memory as I believe USB *requires* buffers
>> which are too large for the GA144 chip itself. It would be hard to
>> provide a memory connection at sufficient rates to keep up with "high
>> speed" USB at 2 * 60 MBps.
>
> Hmm, my choice of words is worse than your sarcasm I think. By
> periphials, I mention onboard chip peripherals, dac, memory, flash,
> sensors etc. But this is another issue, yes, as long as you have to
> use three cores to pump the soft memory bus at speed (over 90kwords/
> s), how much do you have left to high speed parallel interface
> anything else. I just remembered, usb is one of the standards for
> sim cards in phones, I wonder if there is a point to point version for
> on board chips with a large parts list?

Onboard meaning what? On chip? Are you talking about designing your
own chip? On "board"? What do you want to talk on on the board? ADC
and DAC are on chip. An interface to sensors will depend on the sensor.
Many can be controlled from software using the GA144 I/O processors.
There is no difference in "point to point" USB. *All* USB is point to
point.

>>> All this
>>> bit banging really restricts speed, and the serial interfaces I have
>>> found are rather slow. Pity there is no embedded usb go 2 or 3 like
>>> standard to bring a wealth of easy interface periphials and memory.
>>> Even just a high speed memory interface you could use for code or
>>> data.
>>
>> "High speed" memory interface is a bit of a misnomer. High speed is
>> what, perhaps low 10's of Meg transfers per second? That's extremely
>> slow by today's standards. They need to give the chip some real I/O and
>> a real memory interface. They did a software Ethernet interface which
>> supports 10 Mbps only and likely not a full TCP/IP, although I'm not sure.
>
> Yes, how many available lines * several hundred mhz at today process,
> not something 64 times smaller, or 512 (by area) times smaller in
> future. There are recent memory interface advancements more capable
> of keeping up those types of speeds.

I have no idea what you are talking about. If you want an Ethernet
interface on a CPU the smart thing to do is to *add* an Ethernet
interface. It is silly to chew up some thirty or so CPUs in an arcane
software design and still not have a fully functional Ethernet
interface. In today's processes, a memory interface and an Ethernet
interface is ridiculously small compared to thirty of the GA144 cores.

>> Someone once said here that Charles Moore is not so much a chip designer
>> (in the sense of useful products) but rather is more of an inventor. At
>> first I disagreed, but once I learned more about the chip I realized
>> that is pretty much on target. Even ignoring the marketing driven
>> aspects that most companies would push for in a multi-CPU chip, just
>> from a purely technical perspective I think the GA144 lacks a great deal
>> and nearly any other company would have given it some hardware based,
>> high speed interfaces. If I was in the decision making process, I would
>> be pushing hard for it to have multi-volt I/Os like nearly *all* FPGAs
>> have and even most MCU chips.
>
> Hmm, that maybe an issue to do with the tri state asynchronous
> interface signalling between nodes, as it is meant to similarly hook
> up arrays of these chips.

Tri-state? What? I don't have a lot of interest in hooking up a lot of
MISC CPU chips. I just want one that does useful things, like control
an LCD or talk to 2.5, 3.3 and 5 volt devices without having to add
other chips.

> Rick I was just thinking of the shboom, and it was a shame that the
> original design was not released to the public, I then realised that
> Ting did 32 and 64 bit FPGA softcores, and I wonder if they are more
> new misc, or very old misc like shboom. But why transfer it to asic,
> you could pay GA to do a 32 bit.

I'm starting to think you are not so far removed from Gavino. Who cares
about someone else's HDL? If you have an instruction set you can design
the hardware to suit your needs, small size vs. fast performance, vs.
low power...

>> If you want to do something with MISC, you need to define it clearly and
>> I wouldn't tie it to the Green Arrays product line. They may not even
>> be in business in a few years. As yet, I have no feel at all for what
>> you are trying to do. If you can't explain it succinctly and clearly, I
>> think it means you don't properly know yourself.
>
> I have explained nearly all succinctly and clearly, and repeatedly.
> However, my simplified writing tends to be overflowing with succinct
> clear detail that people that try to speed and skip and literally
> confuse themselves. It is not my fault, it is up to them to think
> succinctly and clearly about what thread. What I do if I am confused,
> is read it again more slowly.

I don't agree that you have been succinct or clear. I actually have no
idea what you are trying to do at this point.

> It comes with the territory of trying to do ten times more, with ten
> times less. You must mean more 'simply' and 'lighter', meaning ten
> times more writing. Your a forth programmer and engineer, surely you
> can read my meager writing. I'm a fan of some ancient languages that
> fit three times more in the same space, but so wasteful, why not ten.
> You can see I'm a true decipher of efficient minimalism. ;-)

I'd just like to know what your goals are and what you plan to do the
achieve them. The last I read you wanted to start your own
newsgroup-like domain or something.

--

Rick

[Steve]

Brainstorming ways to get the largely marketable Android system onto
32 bit Misc, which requires running a extremely large non misc code
base. As you can see, my in solution is to use an Android
coprocessing system along side misc, but in terms of part plaement
that is a compromise.

> If your objective is a Forth-based OS, that is best written in Forth
> from scratch, to a specification. But that is a very different
> objective, and the two shouldn't be confused.
>
> > People have talked about kick starting a forth PC, I would like to see
> > a 32 bit misc kickstart, I however would like to one day be able to
> > get one with my own modifications. GA takes custom orders, if
> > everybody got together they could fun it, for shares even, and on the
> > proviso of design release if GA ceases as it is. Mup21 was developed
> > like this, and now Mr Moore has worked out how to get designs to work
> > the firest time, the 32 bit could be done cheaper in todays terms. I
> > do not want competition, but it would be great for the community, and
> > we could nominate some enhancements. I'm a believer in low cycle, low
> > transistor in this respect.
>
> If what you want is an Android device programmed in C, I can pretty much
> promise you that GA will not do this for you, regardless of how it's
> funded. That's not their business objective, and it isn't something they
> have the technical skills to do.

Sorry Elizabeth, I don't want them to make one that runs c. I'm
talking about a pure 32 bit misc as a separate product. If anybody
wants to make it run c they can program it separately after market.


> Cheers,
> Elizabeth

Thanks.

Steve.

[Elizabeth D. Rather]

On 5/5/13 6:17 PM, Steve wrote:
>
>
> Elizabeth D. Rather wrote:
...

>> I am unclear about the objective. If your objective is to have a
>> C-based, compatible version of Android running on your device, the
>> easiest way to do this is write a C compiler for the chip. That is *not*
>> the same thing as a "C to Forth translator" because, although a misc
>> chip may have support for Forth-like features such as stacks, it has a
>> machine language that you compile to just like any other processor.
>
> Brainstorming ways to get the largely marketable Android system onto
> 32 bit Misc, which requires running a extremely large non misc code
> base. As you can see, my in solution is to use an Android
> coprocessing system along side misc, but in terms of part plaement
> that is a compromise.

Why? I don't see that misc has anything to offer the Android market.
It's designed to address a very different set of issues.

>> If your objective is a Forth-based OS, that is best written in Forth
>> from scratch, to a specification. But that is a very different
>> objective, and the two shouldn't be confused.
>>
>>> People have talked about kick starting a forth PC, I would like to see
>>> a 32 bit misc kickstart, I however would like to one day be able to
>>> get one with my own modifications. GA takes custom orders, if
>>> everybody got together they could fun it, for shares even, and on the
>>> proviso of design release if GA ceases as it is. Mup21 was developed
>>> like this, and now Mr Moore has worked out how to get designs to work
>>> the firest time, the 32 bit could be done cheaper in todays terms. I
>>> do not want competition, but it would be great for the community, and
>>> we could nominate some enhancements. I'm a believer in low cycle, low
>>> transistor in this respect.
>>
>> If what you want is an Android device programmed in C, I can pretty much
>> promise you that GA will not do this for you, regardless of how it's
>> funded. That's not their business objective, and it isn't something they
>> have the technical skills to do.
>
> Sorry Elizabeth, I don't want them to make one that runs c. I'm
> talking about a pure 32 bit misc as a separate product. If anybody
> wants to make it run c they can program it separately after market.

Then what is it for?

[Steve]

Thank you Mark.

rickman wrote:
> On 5/5/2013 12:44 PM, Steve wrote:
> >
> >
> > rickman wrote:
> >> On 5/1/2013 12:23 PM, Steve wrote:
> >>> On May 1, 3:35 pm, rickman<gnu...@gmail.com> wrote:
> >>>> On 5/1/2013 10:58 AM, Steve wrote:
> >>>
> >>>
> >>>>> rickman wrote:
> >>>>>> On 4/29/2013 5:31 AM, Steve wrote:

> >
> > Sorry Mr Rick, but I believe I was saying that if a company ordered
> > large enough quantity of chips for a product, the price could come
> > down to less than $1. So whatever they are making or doing today, or
> > in the past, in pricing and numbers obviously bears little relation to
> > this.
>
> I don't get your point. When you use "if" you are not saying anything
> useful unless it is tied to something that you have some control over.
> "If" pigs had wings...

No we are saying normal reality of business, cost of production, the
effective consequence. You are in effect acting like it is not
possible, which is pretty far away from probability. A over for a
large volume, will, bring down the price per chip.

> >>> Some of the interest from seaforth days should be carrying
> >>> over to orders at GA, like the BMW interest. Now GA might have funds
> >>> to establish their development agenda, and rights, some orders might
> >>> come through. I personally hope for large address space 18 and 32
> >>> bit designs to run large code fast. Even 18 bit is great for my
> >>> purposes.
> >>
> >> Agree that 18 bits is not a bad size for embedded CPUs. I think the
> >> fact that it is 18 bits rather than 20 bits (four full instructions per
> >> memory word) says something about Chuck's obsession with "minimal".
> >
> > If you are doing small stuff 18 bits is great, and no memory bus if
> > you are just passing along and processing things.
>
> You miss my point. Is 20 bits really so much larger that it is
> impractical? With 20 bits all of the opcodes can fit in the last nibble
> of an instruction. Chuck had to do a lot of consideration to figure out
> that hobbling this last opcode position wouldn't be a major issue. I
> haven't looked at it, but I think I would have just gone to 20 bits and
> not worried about it.

No, I got that, he might as well went 16 bits for what it is doing, it
had 18 bits supposedly to take advantage of 16 bit cache sram chips I
put forwards last century, that had an extra 2 bits. But that just
disappeared. But you don't get my point that I agree with you that 18
bits still has some usefulness, and further having limited memory
space still has usefulness. You may never want to agree with me, but
at least let one agree with you. :-)

> > By periphials, I mention onboard chip peripherals, dac, memory, flash,
> > sensors etc. But this is another issue, yes, as long as you have to
> > use three cores to pump the soft memory bus at speed (over 90kwords/
> > s), how much do you have left to high speed parallel interface
> > anything else. I just remembered, usb is one of the standards for
> > sim cards in phones, I wonder if there is a point to point version for
> > on board chips with a large parts list?
>
> Onboard meaning what? On chip? Are you talking about designing your
> own chip? On "board"? What do you want to talk on on the board? ADC
> and DAC are on chip. An interface to sensors will depend on the sensor.
> Many can be controlled from software using the GA144 I/O processors.
> There is no difference in "point to point" USB. *All* USB is point to
> point.

Reduced protocol, no daisy changing support,

It is pretty obvious I am talking interface standards to attach parts
on board to chips. The listing of SPI and embedded SD for this
purpose was pretty much a giveaway to what the context was, though
careful restated. You know well that you can get on board separate as
well as the other reinforcing examples given to indicate exactly what
sort of Bus was meant.

>
> >>> All this
> >>> bit banging really restricts speed, and the serial interfaces I have
> >>> found are rather slow. Pity there is no embedded usb go 2 or 3 like
> >>> standard to bring a wealth of easy interface periphials and memory.
> >>> Even just a high speed memory interface you could use for code or
> >>> data.
> >>
> >> "High speed" memory interface is a bit of a misnomer. High speed is
> >> what, perhaps low 10's of Meg transfers per second? That's extremely
> >> slow by today's standards. They need to give the chip some real I/O and
> >> a real memory interface. They did a software Ethernet interface which
> >> supports 10 Mbps only and likely not a full TCP/IP, although I'm not sure.
> >
> > Yes, how many available lines * several hundred mhz at today process,
> > not something 64 times smaller, or 512 (by area) times smaller in
> > future. There are recent memory interface advancements more capable
> > of keeping up those types of speeds.
>
> I have no idea what you are talking about. If you want an Ethernet
> interface on a CPU the smart thing to do is to *add* an Ethernet
> interface. It is silly to chew up some thirty or so CPUs in an arcane
> software design and still not have a fully functional Ethernet
> interface. In today's processes, a memory interface and an Ethernet
> interface is ridiculously small compared to thirty of the GA144 cores.

You're the only one that mentioned Ethernet, I'm still on track of the
same context of only memory interfaces at high speed. The existing
parallel soft bus we are taking about has many lines, why would I be
referring to what you mentioned out of context out of context, instead
of what we were commonly referring to in context, it does not make
sense? Process size we were talking about, and the context used
majesty it obvious it was only process size meant and that smaller
chip process in the future obviously meant faster. Memory
ibterfacecoeriphials standards is obvious, newer ones ties in
completely with memory interfacing on the soft bus.

>
> >> Someone once said here that Charles Moore is not so much a chip designer
> >> (in the sense of useful products) but rather is more of an inventor. At
> >> first I disagreed, but once I learned more about the chip I realized
> >> that is pretty much on target. Even ignoring the marketing driven
> >> aspects that most companies would push for in a multi-CPU chip, just
> >> from a purely technical perspective I think the GA144 lacks a great deal
> >> and nearly any other company would have given it some hardware based,
> >> high speed interfaces. If I was in the decision making process, I would
> >> be pushing hard for it to have multi-volt I/Os like nearly *all* FPGAs
> >> have and even most MCU chips.
> >
> > Hmm, that maybe an issue to do with the tri state asynchronous
> > interface signalling between nodes, as it is meant to similarly hook
> > up arrays of these chips.
>
> Tri-state? What? I don't have a lot of interest in hooking up a lot of
> MISC CPU chips. I just want one that does useful things, like control
> an LCD or talk to 2.5, 3.3 and 5 volt devices without having to add
> other chips.

Sorry, I get you now, well I really did before in a way. Is, multiple
level compatible with tri state logic, that is what Im asking. You do
know they use tri state logic to differentiate between 1, 0 and no bit
recieved on the communications lines?

> > Rick I was just thinking of the shboom, and it was a shame that the
> > original design was not released to the public, I then realised that
> > Ting did 32 and 64 bit FPGA softcores, and I wonder if they are more
> > new misc, or very old misc like shboom. But why transfer it to asic,
> > you could pay GA to do a 32 bit.
>
> I'm starting to think you are not so far removed from Gavino. Who cares
> about someone else's HDL? If you have an instruction set you can design
> the hardware to suit your needs, small size vs. fast performance, vs.
> low power...
>
>
> >> If you want to do something with MISC, you need to define it clearly and
> >> I wouldn't tie it to the Green Arrays product line. They may not even
> >> be in business in a few years. As yet, I have no feel at all for what
> >> you are trying to do. If you can't explain it succinctly and clearly, I
> >> think it means you don't properly know yourself.
> >
> > I have explained nearly all succinctly and clearly, and repeatedly.
> > However, my simplified writing tends to be overflowing with succinct
> > clear detail that people that try to speed and skip and literally
> > confuse themselves. It is not my fault, it is up to them to think
> > succinctly and clearly about what thread. What I do if I am confused,
> > is read it again more slowly.
>
> I don't agree that you have been succinct or clear. I actually have no
> idea what you are trying to do at this point.
>

From Google:
suc·cinct
/səkˈsiNGkt/Adjective(esp. of something written or spoken) Briefly and
clearly expressed

Yep, sounds about right.

> > It comes with the territory of trying to do ten times more, with ten
> > times less. You must mean more 'simply' and 'lighter', meaning ten
> > times more writing. Your a forth programmer and engineer, surely you
> > can read my meager writing. I'm a fan of some ancient languages that
> > fit three times more in the same space, but so wasteful, why not ten.
> > You can see I'm a true decipher of efficient minimalism. ;-)
>
> I'd just like to know what your goals are and what you plan to do the
> achieve them. The last I read you wanted to start your own
> newsgroup-like domain or something.

Lol, "or something". If I explain it again, won't you only just
confuse it again around in circles. You could try not being negative
on everything, it is against reality for everything to always have to
be wrong, which will only confuse yourself. You could try admiting
you are wrong to yourself or apologizing once in a while. I have
much better things to do than be strung around because I'm being nice
and objective in sorting out confusion of somebody that is not taking
time to shove himself aside and think into and through everything
said, aswell as not read it all. This thread deserves better. It is
set up for solutions, which you are welcome to work on, not how things
that are possible, are not. And don't bother saying you still don't
understand, somebody else is welcome to explain. You are spending
heaps of time around here trying to deny things, that you could be
earning another $1000 a week.

Now, thread is on useful projects that could be done to expand the
usefulness and market for Nusc, to expand the reality of what it can
do.

A sub project is to look at a ring product, using a costly second chip
to provide interface and api hosting, instead of emulation or
translation.

Another sub project is to look at more viable ways to get a desirable/
marketable eco system and functionality on it, of Android, inslead of
a single person spending the next 70 years hand rewriting all the code
in forth.

Another aspect is to find a higher speed serial bus for on board
components with a good parts list. SPI is limited.

Another thread was to discuss and gauge the interest in having a
separate forum for misc or hardware issues. Not much interest, so on
hold. Another possible subfforum would be for complaints, for people
that want to complain what we don't gave, or how something is not
possible.

Another idea was to get crowd funding together to approach GA about
finishing their 32 bit design with some high speed interfaces etc
improvements.

Most a good portion of the rest not listed in the first post and
updates are static.


Thanks.


Steve.

[Steve]

Elizabeth D. Rather wrote:
> On 5/5/13 6:17 PM, Steve wrote:
> >
> >
> > Elizabeth D. Rather wrote:
> ...
> >> I am unclear about the objective. If your objective is to have a
> >> C-based, compatible version of Android running on your device, the
> >> easiest way to do this is write a C compiler for the chip. That is *not*
> >> the same thing as a "C to Forth translator" because, although a misc
> >> chip may have support for Forth-like features such as stacks, it has a
> >> machine language that you compile to just like any other processor.
> >
> > Brainstorming ways to get the largely marketable Android system onto
> > 32 bit Misc, which requires running a extremely large non misc code
> > base. As you can see, my in solution is to use an Android
> > coprocessing system along side misc, but in terms of part plaement
> > that is a compromise.
>
> Why? I don't see that misc has anything to offer the Android market

> It's designed to address a very different set of issues.

It is suitable for much more, and is being expanded into 32 bit.

> > Sorry Elizabeth, I don't want them to make one that runs c. I'm
> > talking about a pure 32 bit misc as a separate product. If anybody
> > wants to make it run c they can program it separately after market.
>
> Then what is it for?

http://www.greenarraychips.com/home/documents/roadmap.html

The extra functionality and performance makes it more useful for a
wider range of tasks. If custom ordered it can be more useful again.
In the end it is about native performance and functionality, not at
all asking them to implement android etc, all that stuff is separate.
In the end hands on popularity will drive software development.

[Elizabeth D. Rather]

On 5/5/13 8:51 PM, Steve wrote:
>
>
> Elizabeth D. Rather wrote:
>> On 5/5/13 6:17 PM, Steve wrote:
>>>
>>>
>>> Elizabeth D. Rather wrote:
>> ...
>>>> I am unclear about the objective. If your objective is to have a
>>>> C-based, compatible version of Android running on your device, the
>>>> easiest way to do this is write a C compiler for the chip. That is *not*
>>>> the same thing as a "C to Forth translator" because, although a misc
>>>> chip may have support for Forth-like features such as stacks, it has a
>>>> machine language that you compile to just like any other processor.
>>>
>>> Brainstorming ways to get the largely marketable Android system onto
>>> 32 bit Misc, which requires running a extremely large non misc code
>>> base. As you can see, my in solution is to use an Android
>>> coprocessing system along side misc, but in terms of part plaement
>>> that is a compromise.
>>
>> Why? I don't see that misc has anything to offer the Android market
>> It's designed to address a very different set of issues.
>
> It is suitable for much more, and is being expanded into 32 bit.

Yes, but not in order to take on the Android market.

>>> Sorry Elizabeth, I don't want them to make one that runs c. I'm
>>> talking about a pure 32 bit misc as a separate product. If anybody
>>> wants to make it run c they can program it separately after market.
>>
>> Then what is it for?
>
> http://www.greenarraychips.com/home/documents/roadmap.html
>
> The extra functionality and performance makes it more useful for a
> wider range of tasks. If custom ordered it can be more useful again.
> In the end it is about native performance and functionality, not at
> all asking them to implement android etc, all that stuff is separate.
> In the end hands on popularity will drive software development.

Yes, true. But the initial uses will all be true embedded systems, with
no requirement for GUIs, browsers, and all that jazz which is really a
completely different market.

[Steve]

All that is needed is a CPU with basic functionality to do these
things. These things may help Misc, but Im not expecting GA to do
very much at all themselves. I'm looking at big markets myself, not
just tens of millions. I'm looking at a range of products in time.
If I just did what everybody else us doing with an Arm, what is the
use of that, they have the money to do it cheaper and market it
better, there has to be some edge.

I've let Gavino know that I've been onto him all along, just a shame
people wouldn't leave me alone so I could see if I could get him to
write some code perhaps. :-) I don't really believe he is as naive
as he sounds.


Thanks


Steve.

[rickman]

On 5/6/2013 1:57 AM, Steve wrote:
>
> Thank you Mark.
>
>
> rickman wrote:
>> On 5/5/2013 12:44 PM, Steve wrote:
>>>
>>>
>>> rickman wrote:
>>>> On 5/1/2013 12:23 PM, Steve wrote:
>>>>> On May 1, 3:35 pm, rickman<gnu...@gmail.com> wrote:
>>>>>> On 5/1/2013 10:58 AM, Steve wrote:
>>>>>
>>>>>
>>>>>>> rickman wrote:
>>>>>>>> On 4/29/2013 5:31 AM, Steve wrote:
>
>>>
>>> Sorry Mr Rick, but I believe I was saying that if a company ordered
>>> large enough quantity of chips for a product, the price could come
>>> down to less than $1. So whatever they are making or doing today, or
>>> in the past, in pricing and numbers obviously bears little relation to
>>> this.
>>
>> I don't get your point. When you use "if" you are not saying anything
>> useful unless it is tied to something that you have some control over.
>> "If" pigs had wings...
>
> No we are saying normal reality of business, cost of production, the
> effective consequence. You are in effect acting like it is not
> possible, which is pretty far away from probability. A over for a
> large volume, will, bring down the price per chip.

Yes, of course it is possible. I just don't see anything you have
talked about that would make me think there are going to be any large
orders.

>>>>> Some of the interest from seaforth days should be carrying
>>>>> over to orders at GA, like the BMW interest. Now GA might have funds
>>>>> to establish their development agenda, and rights, some orders might
>>>>> come through. I personally hope for large address space 18 and 32
>>>>> bit designs to run large code fast. Even 18 bit is great for my
>>>>> purposes.
>>>>
>>>> Agree that 18 bits is not a bad size for embedded CPUs. I think the
>>>> fact that it is 18 bits rather than 20 bits (four full instructions per
>>>> memory word) says something about Chuck's obsession with "minimal".
>>>
>>> If you are doing small stuff 18 bits is great, and no memory bus if
>>> you are just passing along and processing things.
>>
>> You miss my point. Is 20 bits really so much larger that it is
>> impractical? With 20 bits all of the opcodes can fit in the last nibble
>> of an instruction. Chuck had to do a lot of consideration to figure out
>> that hobbling this last opcode position wouldn't be a major issue. I
>> haven't looked at it, but I think I would have just gone to 20 bits and
>> not worried about it.
>
> No, I got that, he might as well went 16 bits for what it is doing, it
> had 18 bits supposedly to take advantage of 16 bit cache sram chips I
> put forwards last century, that had an extra 2 bits. But that just
> disappeared. But you don't get my point that I agree with you that 18
> bits still has some usefulness, and further having limited memory
> space still has usefulness. You may never want to agree with me, but
> at least let one agree with you. :-)

Except that 16 bits doesn't implement four opcodes very well. I believe
he wanted to use the chip for audio, so 18 bits was a minimum. I am not
second guessing his decision, just pointing out that he has a real jones
for minimizing *everything* he can. In some cases it is *clearly* too
minimal, like the I/O capabilities.

>>> By periphials, I mention onboard chip peripherals, dac, memory, flash,
>>> sensors etc. But this is another issue, yes, as long as you have to
>>> use three cores to pump the soft memory bus at speed (over 90kwords/
>>> s), how much do you have left to high speed parallel interface
>>> anything else. I just remembered, usb is one of the standards for
>>> sim cards in phones, I wonder if there is a point to point version for
>>> on board chips with a large parts list?
>>
>> Onboard meaning what? On chip? Are you talking about designing your
>> own chip? On "board"? What do you want to talk on on the board? ADC
>> and DAC are on chip. An interface to sensors will depend on the sensor.
>> Many can be controlled from software using the GA144 I/O processors.
>> There is no difference in "point to point" USB. *All* USB is point to
>> point.
>
> Reduced protocol, no daisy changing support,
>
> It is pretty obvious I am talking interface standards to attach parts
> on board to chips. The listing of SPI and embedded SD for this
> purpose was pretty much a giveaway to what the context was, though
> careful restated. You know well that you can get on board separate as
> well as the other reinforcing examples given to indicate exactly what
> sort of Bus was meant.

If you are talking about on board I/O, just what bandwidth do you need?
Most on board devices either will work with the programmed I/O the
GA144 can provide, or needs special hardware to implement, like high
speed USB, Ethernet and especially the really fast ones like
hyper-transport, PCI-E,...

I don't see where you ever said anything about the memory interface
really. Yes, the GA144 needs one. The programmed I/O thing is just way
too slow. The original software supported 250 ns memory cycle times.
Allegedly Chuck has an interface running at ~50 ns, but Chuck likes
building lab queens rather than production designs. But even 20 MHz is
not a very fast memory by today's standars and is far too slow for even
a simple design like an oscilloscope.

>>>> Someone once said here that Charles Moore is not so much a chip designer
>>>> (in the sense of useful products) but rather is more of an inventor. At
>>>> first I disagreed, but once I learned more about the chip I realized
>>>> that is pretty much on target. Even ignoring the marketing driven
>>>> aspects that most companies would push for in a multi-CPU chip, just
>>>> from a purely technical perspective I think the GA144 lacks a great deal
>>>> and nearly any other company would have given it some hardware based,
>>>> high speed interfaces. If I was in the decision making process, I would
>>>> be pushing hard for it to have multi-volt I/Os like nearly *all* FPGAs
>>>> have and even most MCU chips.
>>>
>>> Hmm, that maybe an issue to do with the tri state asynchronous
>>> interface signalling between nodes, as it is meant to similarly hook
>>> up arrays of these chips.
>>
>> Tri-state? What? I don't have a lot of interest in hooking up a lot of
>> MISC CPU chips. I just want one that does useful things, like control
>> an LCD or talk to 2.5, 3.3 and 5 volt devices without having to add
>> other chips.
>
> Sorry, I get you now, well I really did before in a way. Is, multiple
> level compatible with tri state logic, that is what Im asking. You do
> know they use tri state logic to differentiate between 1, 0 and no bit
> recieved on the communications lines?

Tristate and multiple level are different things. The GA144 uses 1.8
volts for the I/O and won't tolerate being pulled up to anything higher.
You can drive a GA144 input through a resistor *IF* you have enough
load on the power rail to sink the current, but this is a very poor
interface and won't work for many designs. You mostly need interface
chips.

Your posts are anything but brief and seldom as clear as they could be.

>>> It comes with the territory of trying to do ten times more, with ten
>>> times less. You must mean more 'simply' and 'lighter', meaning ten
>>> times more writing. Your a forth programmer and engineer, surely you
>>> can read my meager writing. I'm a fan of some ancient languages that
>>> fit three times more in the same space, but so wasteful, why not ten.
>>> You can see I'm a true decipher of efficient minimalism. ;-)
>>
>> I'd just like to know what your goals are and what you plan to do the
>> achieve them. The last I read you wanted to start your own
>> newsgroup-like domain or something.
>
> Lol, "or something". If I explain it again, won't you only just
> confuse it again around in circles. You could try not being negative
> on everything, it is against reality for everything to always have to
> be wrong, which will only confuse yourself. You could try admiting
> you are wrong to yourself or apologizing once in a while. I have
> much better things to do than be strung around because I'm being nice
> and objective in sorting out confusion of somebody that is not taking
> time to shove himself aside and think into and through everything
> said, aswell as not read it all. This thread deserves better. It is
> set up for solutions, which you are welcome to work on, not how things
> that are possible, are not. And don't bother saying you still don't
> understand, somebody else is welcome to explain. You are spending
> heaps of time around here trying to deny things, that you could be
> earning another $1000 a week.

I'll try to not be so negative. Sorry, but I think I am being
realistic, but I understand what you mean.

> Now, thread is on useful projects that could be done to expand the
> usefulness and market for Nusc, to expand the reality of what it can
> do.

What projects have been mentioned?

> A sub project is to look at a ring product, using a costly second chip
> to provide interface and api hosting, instead of emulation or
> translation.

I have no idea what a ring product is.

> Another sub project is to look at more viable ways to get a desirable/
> marketable eco system and functionality on it, of Android, inslead of
> a single person spending the next 70 years hand rewriting all the code
> in forth.

Ok, has anyone come up with possible solutions?

> Another aspect is to find a higher speed serial bus for on board
> components with a good parts list. SPI is limited.

What value is a bus if the GA144 doesn't use it?

> Another thread was to discuss and gauge the interest in having a
> separate forum for misc or hardware issues. Not much interest, so on
> hold. Another possible subfforum would be for complaints, for people
> that want to complain what we don't gave, or how something is not
> possible.
>
> Another idea was to get crowd funding together to approach GA about
> finishing their 32 bit design with some high speed interfaces etc
> improvements.

Positive response... Let us know how this goes for you.

> Most a good portion of the rest not listed in the first post and
> updates are static.
>
>
> Thanks.
>
>
> Steve.

--

Rick

[Brad Eckert]

On Sunday, May 5, 2013 10:57:33 PM UTC-7, Steve wrote:
>
> No we are saying normal reality of business, cost of production, the
> effective consequence. You are in effect acting like it is not
> possible, which is pretty far away from probability. A over for a
> large volume, will, bring down the price per chip.
>

I think Rick is saying there's no clear path from point A to point B. It takes a lot of boring detail work to run a chip company. Not just the exciting cowboy stuff.

Unfortunately, you have to sell a lot of chips to get money to pay people to do the boring part. It's a catch 22.

[Steve]

Minor Update:

I did some more research last night, and managed to find some good
things.  I've made some good discoveries that fgiut in with what I wnt
to do as well.

What I am writing here is a condernsed summary resource of little
clear explanations, assessments, and some opinion, strung together.  
A sentence might cover simply two or three related aspects.   It also
builds on information in prior posts.  So, please read it carefully
from the beginning of the thread to get a proper understanding.  If
people want me to expand out each little explanation further, even
little cartoons like in Starting Forth, to understand it better, then
just this post might take up to a 100 posts to excplain. :-)   The
resource links, context, and previous posts are there to read. The
thread is suitably short for professionals to read through it, and I
am summarising information in update posts like this, so all that is
really needed is to read the updates and the posts since the last
update.  I might eventually start a new thread with a summary of the
summaries in the future for new people to easily get started.

Please, if you know anybody in Misc, ask them to come over now and
again and see if they want to contribute something to projects, or a
project.  It is very much a matter of, developing effectively for misc
will develop more markets for misc.  In this day and age, wireless
applications in particular will be a big thing, to have wireless. 
Relative standards are listed in previous posts, in particular the
ieee basis for variouse ermbedded personal area networks.  There is a
proposal for a network for smart dust too (around the size of a misc
array at 22nm process.

-----------

It appears there are high speed serial onboard interconnect busses out
there for mobile supported by mipi, an Arm initiative, I don't know if
they are excternal busses yet, but from the slow speed and dervices, I
guess at least some of them are.  If the is an open spec, and if it
has a good parts list, it would be good if GA had support for this eco
system.  I'm surprised that nobody here knew of this system.

http://en.wikipedia.org/wiki/Mobile_Industry_Processor_Interface
http://www.mipi.org/
http://www.mipi.org/about-mipi/mipi-interfaces-mobile-platform
http://www.mipi.org/about-mipi/frequently-asked-questions

Slimbus, one of the busses basically goes at 28 MB/s, not too much
faster than 4 lane spi unfortunately, but is a two pin muli drop
serial bus, likely with dma as standard, which in spi, would have had
to be added through extra general purpose pins.  So heart warming.  If
it was 280MB/s instead of 28MB/s and could interface most things,I
would be much happier. :-)   However, there are other buses, one with
300MB/s, and support for both mobile forms I think of pcie and USB 3,
however, detail and speed constrictions I don't know.  There are many
busses.

http://en.wikipedia.org/wiki/Slimbus
http://www.mipi.org/content/mipi-alliance-rolls-out-slimbus®

---------

An ideal embeeded interconnect onboard devices bus.
---------------------------------------------------------------------------

What I would like to see is a multi speed combined single and multiple
drop bus, with ultra simple point to point no protocol support (for
embedded naked io apps)  and multiple optional protocol level
depending on hardware attached.  The speed also would be dependent on
devices attached to the line, as with the voltage etc.  In reality,
you just make your port fit a certain max speed and a voltage etc, and
choose parts that fit, and optionally making it multi voltage.  So in
its simplest form you attach all devices of the same speed (even just
async for GA) to the same lines.  If you have a high speed device that
you require a lower speed device with, you have coexistence protocol
support, or virtual hub support in the high speed and daisy chain the
slower speed device on it.  All together, except for optional security
handling, encryption and data recovery options,  you make the whole
driver protocol software fit in a few KB.  Once a device is attached
either you know how it is handled and add the software, or it is sense
dynamically.  You pick the highest speed serial bus  practical, and
move onto higher speed buses again in future versions, with either
sensing/locking switchable coexistence for the pins, or new pins, and
pick parts to suit the new bus version standard used.  In this way you
don't get stuck with trying to upgrade to a backwards compatible, and
likely limited from being compatible, bus protocol.  Also imagine if
it was multiple phase, I dont know how sophisicated a circuit is
needed to do this (thinking of practicality on small chips like misc) 
but imagine if you can resolve a 16 bit adress in a serial line in a
single pulse, ideal for small embedded, and two lines makes 32 bits
for large embedded.  I notice that past Misc designs have large
internal speed overhead compared to the port or processor clock speed,
so maybe this can be simply used towards multi phase timing, even if
just 4 bits at a time, giving you four lines for four 16 bits, and 8
for 32 bit, meaning more memory busses for the same pin count.  So you
can pick maybe pcie or thunderbolt to start, or hyper transport or
rapidio (what was the name of that Intel one again).  However, one
mode would be custom protocol, that allows any data protocol to be
used on it, maybe with some support to ensure data integrity of the
electrical signalling.  This means it is possible to use USB and
thunderbolt with as the seriasl line, maybe with a electrical bridging
chip and isolation built into the connector, straight off the board to
external services.  So, now we have something that makes it not only
cheaply useable for small run use, but also for mass production, and
delivering 90% of the benefits of a very complex bus system.  The same
could be done for wireless standards, having a common program
interface for multiple wireless standards.

-----------

Now, I happened on mipi by accident, even though I spent a while
looking for newer busses on line.  I found it after I looked up a new
memory bus technology, called serial port memory technology, using
spdram.  Promised much, was a thing Arm was behind and from silicon
image who do HDMI, and wirelesshd that I mentioned.  In that edition
it was only 6 GByte/s for a 4 port serial, and interesting, also aimed
at interconnect use.  It gets a dram chip and serialises the data,
likely saving a few pins.  The website is blank, I'm going to have to
try another browser, but apparently they did not get much acceptence
at first, as the industry was skeptical.  So the next year they shook
up management and brought about a much faster version hybridised with
parallel, that is to be incorporated into the lpsdram interface.  Now
20GBytes/s I think, 4 port serial.  A number of the original members
left, including Intel, so it would be interesting to see what they
have planned as they plans to move thunderbolt to phones, but I'm very
interested in this one, imagine the peripheral  use,  I think you can
limit the number of ports, as well as the speed.  If the protocol/
electrical is simple ernough, a natural for high performance ermbeeded
GA system in a faster process.

www.eetimes.com/electronics-news/4205016/Memory-interface-group-claims-to-be-back-on-track-
http://www.spmt.org/

-------------

I also found a more modern Intel 4 bit version of the ISA bus, that
Intel introduced, I think up to 12 or so MB/s, but I don't know how
many parts would be left for it these days, and then mipi eco system
is better in speed and for mobile embedded.

-------------

Now, here is some links on converting C++ to C programs.  Apparently
that is how the inventor of c++ started out.  It looks like Stephen's
c to forth solution is a rather elegant solution along the lines I was
theorising, well worth investegating.  Pity that with everything I
want and have to do, it is not my sort of thing to investigate, but is
for others that are intetested.  I list a few links on c to forth as
well.

http://www.parashift.com/c++-faq/convert-to-c.html
http://www.tomshardware.com/forum/236425-50-open-source-translation
http://sydney.edu.au/engineering/it/~scilect/tpop/handouts/CPP_to_C.htm

http://www.complang.tuwien.ac.at/forth/faq/faq-general-5.html
http://dl.acm.org/citation.cfm?id=316994
http://compilers.iecc.com/comparch/article/91-12-03
http://compilers.iecc.com/comparch/article/07-07-046

This might not be an acceptabe solution to everybody, but it is here
for those that want it.

----------------

I see that there has been some talk about getting Java on Forth or
Misc, and have a few links about this.

http://computer-programming-forum.com/22-forth/d73ec2f837359b09.htm
http://www.complang.tuwien.ac.at/forth/faq/faq-general-5.html#ss5.7

Does anybody have infoirmatiom on implermrntatiins of this?  I thought
people from the intellasys days tried something. Having a Java OS in
Java, would help reduce the hassel of moveing it over.

------------

I think I might be interested in working with somebody in future to
emulate an arm processor on Misc or translate code (with good
attitudes). I could certainly offer a lot of innovative ideas, to
greatly increase the speed of emulation. However the only ARM
assembly text here I have is from the Arm 1 or 3 series. I will have
to get a hang of both systems first, to maximise results. The on chip
eco system is probably the biggest issue, it is large and expansive.
Or maybe somebody would like to work on c on misc as an alternative,
and maybe ask to work with Stephen on his code (brawn and brains).

C, Arm and Java offer the best eco system expansion chioces (Arm and C
offer Android and Linux).

------------

The modern reality is that the industry has become a commodity like
market in order to make money.  So we need a software and hardware eco
system for our own products to make impact on the commodity side.  It
is too expensive to make our own eco systems of products, so we have
to tap into others to get to a point of being able to afford to make
our own, or wait for developers to make it.  So, c, Java etc short
term is a desirable thing.


Thanks

Steve.

[Steve]

Please, most people don't understand, what is proposed is that the
community can do it, not GA, and could even fund GA to bring their 32
bit product forwards, for them to sell more chips. I'm looking at two
carefully chooen products with hundreds of million unit potential.
They need control logic, I'm trying to choose GA product. I'm wanting
to do things, to also build an eco system for future products, but the
commuity does not need to wait years in which time nothing good may
happen, they can build their own and help their own future. I'm not
worried much about a little competition, it might help the market.
Now I have answered adequately enough times, and explained, but if
some can not see, but bog down just to be negative, there comes a
time to end a conversation. A little skill can enhance the
situation. People who are obstructive are likely never to achieve
anything past what they do, it is a self fulfilling circle of doubt.
Through use you can become skilled in something, some are skilked in
being good at things even, but that does not nessacarily make you a
genius in something, but some are skilled at being geniuses. If you
figure out who you are, you might consider there is more to it than
you can figure, at least a genuise should know that enough to ask..
So rather than trying to limit other people, or limit what other's
could possibly figure out, they should see their own limits, and past
them. Experience can be a very poor teacher of what can ultimately be
done.

I often bend over backwards for people, but in the end it can be a
waste of productivity that stops progress and doing the actual work.

There is a lot to do, and when you can see the credible truth, it is
time to stop wasting time, even if others don't.


Thanks Brad, yours is the first new post I've read. But to answer
your question, there is more ways to get from point a to b. If not,
we would still be programming something like cobol.

[Steve]

To everybody.

I'm sorry that the typos are still getting past me, looking at some of
my latest posts, if t doesn't line up, you are welcome to substitute
appropriate words. I'm pulling all nighters due to a lot to get done
in a short time lately, and this new machine has a few keyboard issues
and can't be updated to a realistic spell system. Plus, sorry being
slightly offside lately.

As most things are listed and said for the moment, there should not be
too much more for now.

[Steve]

[Albert van der Horst]

In article <2d30ca3c-b306-4a7e...@hc4g2000pbb.googlegroups.com>,

Steve <nosp...@gmail.com> wrote:
>
>
>time to end a conversation. A little skill can enhance the
>situation. People who are obstructive are likely never to achieve

Can you solder 0.4 mm non-protruding pins?
Is that what you call "little skill"?

<SNIP>

>There is a lot to do, and when you can see the credible truth, it is
>time to stop wasting time, even if others don't.

How true. Start training, maybe in two years you're at my soldering
skill level.

[the_gavino_himself]

amber smalltalk and node.js seem to point to people doing web gui with java script.


If forth could do this, perhaps it could really be nice for web.

If then forth on a misc chip could run tcp ip and a gui for a web browser...wow you are on your way to both forth web servers and forth client nodes used by businesss to replace the pc. of course with less cost and code. Business are still paying terrible prices for server and pc of 10,000 a node. Forth could be a big business if it could provide an alternative but handle many concurrent users interacting. Business spends 10 million a year just on software to support a few thousdand concurrent users and have 50 to 20 people maintaining it all.

[the_gavino_himself]

android and iphone are terrible, be awesome to see a forth running on a chinese device with forth gui, chat, phonecalls, camera working al from forth gui

could forth do the swipe screen?

[Steve]

Albert van der Horst wrote:

> In article <2d30ca3c-b306-4a7e...@hc4g2000pbb.googlegroups.com>,
> Steve <nosp...@gmail.com> wrote:

> >time to end a conversation. A little skill can enhance the
> >situation. People who are obstructive are likely never to achieve
>
> Can you solder 0.4 mm non-protruding pins?
> Is that what you call "little skill"?

Is that relevant skill?

> <SNIP>
> >There is a lot to do, and when you can see the credible truth, it is
> >time to stop wasting time, even if others don't.
>
> How true. Start training, maybe in two years you're at my soldering
> skill level.

I think you're not Rick, Albert, so how does that have relevance to
the skill of thinking. Obstructung will just limit you.

It has been incredible here, with people professing I don't understand
what I want, while they are misunderstanding everything, unrealistic,
taking most things out of context and being rather irrelevant.

Missing things written over and over again, but claiming to have read
it but not seen it. Like products, projects and solutions listed in
the first post and repeatedy expanded upon, even ones the person has
duscussed themselves.

Having passed by more relevant higher speed sram memory statements in
previouse years by a misc team member. Preferring to state a
convenient figure as maximum, rather than the maximum figure.

Much inability to read out of their own context, and instead of
reading in the greater context of the conversation.

Very little to nothing really relevant to contribute.

Pretty much sums up 90-99% of things from their side, the other 1-10%
is them being realistic or right.

And you can see much of that just in their last post, in context to
previouse discussions.

Doesn't that seem to be a wind up to you, so please feel free to have
a go at then instead.

He might even be able to convince others otherwise, but only because
they don't have the relevant high end programming and design
knowledge and skill, and professional experience to tell otherwise.

Such people should not be accepted.


I am here to do a good thing for the community, people are welcome to
either help or leave.

[Mark Wills]

On May 7, 9:58 pm, the_gavino_himself <visphatesj...@gmail.com> wrote:
> On Sunday, May 5, 2013 8:46:28 AM UTC-7, Steve wrote:
> > Albert van der Horst wrote:
>

> > > In article <P7qdnXc8NM3cihvMnZ2dnUVZ_rGdn...@supernews.com>,

What difference does the underlying languge used make to the user
experience? Do you think people care if their facebook app is written
in C++ or Java? Of course not. Do you think your mother is going to
use a "browser written in Forth" because it's written in Forth? Of
course not.

It's nonsense. Just stop it. The language used to *implement* an
application is irrelevant. It can be Visual Basic, C#, Java, Forth,
Assembly Language. It's only the *user experience* that matters, and
you're as free to fuck that up in Forth as you are in any other
language.

[Mark Wills]

On May 8, 6:36 am, Steve <nospam...@gmail.com> wrote:
> Albert van der Horst wrote:
>

> > In article <2d30ca3c-b306-4a7e-ac54-736baca35...@hc4g2000pbb.googlegroups.com>,

I've tried to read your posts with an open mind, but I can't make head
nor tail of them.

So far, all I've really understood is that you want to make a ring and
(you think) it needs an OS. Quite why a *ring* would need to run an OS
is beyond me, but hey. You've been obsessing in recent posts about
interface technologies. Why does a ring need any kind of interface,
other than, say, a bluetooth interface to it's host?

Here's an idea:

Write a *design*.

You know, actually think about *what* you want to build. When I say
design, I don't mean select a processor, bus technology, interface
technology, operating system or any other such stuff. Just design it
as a finished *product*, all at the conceptual level. Only *then* will
you be ready to select the components and the technologies required to
meet the features and the price-point.

You're putting the cart before the horse. How do you know that your
product needs a MISC processor? Perhaps it could be done with a 4-bit
processor. You don't know, because you haven't designed anything. If
it turns out that a 4-bit processor is all you need, you probably
don't need Forth as an implementation language; you would only need
assembly language. And you certainly wouldn't need an operating
system. Why are folk so hung up on the idea of operating systems? If
your device was a general purpose device (like, say, a PC, which could
be running a bar-code scanning application, and a database, and point-
of-sale GUI, and a connection to stock control ordering system) then
yes, I'd say a operating system, as a method of:

1) Abstracting away the underlying hardware, in order that the
hardware could be changed later with minimal impact to the
applications;
2) Making the development of the applications themselves easier, and
divorced from the underlying hardware;

would be a good idea. You've a way to go though to convince me (and I
suspect others) here that a ring needs an operating system. It's like
saying a child's fire engine toy (which maybe has 3 different siren
sounds and maybe says a few 8-bit sampled phrases) needs an operating
system (clue: It doesn't).

Please structure your thoughts, do a design, and report back. People
will help with advice where they can, but at the moment your scatter-
gun approach is confusing - at least to me! I don't like to be mean,
and I say the above with no malice, but you seem to be coming at this
from the wrong angle.

[Steve]

What ever fb is written in at the moment, it is pretty awful on my
system. Having run around the system updating dispersed settings and
changing things that have to wait for server response each step, is a
nightmare.


Don't worry about Gavino, you may not get a response you like.

I'll answet or you. Apart from snapiness in response, compactness,
efficiency that transfer through the user experience, which makes good
product experience which makes businesses happy to look good, through
forth pocessor hardware, it really isn't going to matter to the user.
It is the programmers and businesses that are the customers of program
languages. You probably have to have two of the programmers,
developers and business customer groups wanting your product, to make
it a popular implementation language. That is how come Java ahd c++
got ahead. Forth without hardware is good, but not much of a paradigm
shifter against entrenchment of the current leaders.

So, it is not a matter of the language being in end user products to
get it popular, but the popularity of the product itself, and what the
language can allow you to do in designing the product to make it
better.

[Steve]

Mark Wills wrote:
> On May 8, 6:36 am, Steve <nospam...@gmail.com> wrote:
> > Albert van der Horst wrote:
> >
> > > In article <2d30ca3c-b306-4a7e-ac54-736baca35...@hc4g2000pbb.googlegroups.com>,
> > > Steve  <nospam...@gmail.com> wrote:

>
> I've tried to read your posts with an open mind, but I can't make head
> nor tail of them.

Sorry, but I can't help you then. They have been explained clearly,
and then extensively to aviod confusion. I am faced with people
picking bits and pieces up out of context and forgetting the rest, and
then arguing nonsence, frankly. As can be in the message.

> So far, all I've really understood is that you want to make a ring and
> (you think) it needs an OS. Quite why a *ring* would need to run an OS
> is beyond me, but hey. You've been obsessing in recent posts about
> interface technologies. Why does a ring need any kind of interface,
> other than, say, a bluetooth interface to it's host?
>
> Here's an idea:
>
> Write a *design*.

I don't believe you guys are being real, and I am not greatly
perceiving sincerity or honesty. Otherwise I would have to be sorry
if you don't have a clue about how to seperate out information, assess
and quantify them, mixing up different subjects together, neglecting
well documented contexts about what's going on. All program design
and factoring skills. If you could design it, you should understand
why. I seem to be the one that actually can design more effectively.
To come here and pull this stunt after what Rick has done is
unacceptably low. All I am doing, seems to be talking to people
seemingly that had the opportunity to go somewhere more but didn't
(psychologically it is pretty obvious), dead ended, tell me I can't go
anywhere, for not one credible, realistic or good reason, but as
spoilers. Sorry, I do not wish to be like those people or reinforce
their negative self defeating image, in becoming like them.

These are general projects and realistic assessment of functionality
and possibilities, not the weird unrealistic conjecture being used
against them. The OS is general (for all misc projects), anybody too
lazy to read that in the first post, but has time to make out it is
something different can leave. The simple OS is also desirable for a
ring project, which is an obvious advantage, as with all modern
intelligent user reprogramable products. It offers very basic program
services to streamline and expand functionality

The ring's sole purpose is to use misc and in that offer higher
functionaslity.

<mistaken deleted>

You have just said, the part that was credible, most of what I
allready have done, but you got it out of whack. Now I asked if
people wanted to do a project, their project, even a simple ring or os
project, and ideas towards any of these seperate projects. Then I
decided to push up the schedule on my seperate commercial
alternatives, because nobody else was interested in the simpler
community ones. The interfaces are about what to use on misc chips,
or with them generally for future projects, given the general io pin
functionality, that delivers a good eco system of parts, and higher
speed parts. The ring is unlikely to use much of that. I allready
knew what to do, how it works, what is needed, now it is about trying
to find the best fit of parts to answer the design. Anybody would
also know that choice of functionality, interfaces is strongly
affected by practicality, part availability and cost. You start a
design by establishing what you can realistcally do, redesign concept
to that, find parts and finish design to that, or go back and redesign
for the parts you can actually use. So parts and practical
considerations for what it is supposed to do, are big considerations
from the beginning, after the initial idea. Anybody trying to do the
design without an idea about what is practically possible, is not
truely integrated, with the cart before the horse, and possibly
drawing fantasies.

I have been shaking my head at the mentality of the attitudes and
statements during a good portion of this thread, that has given the
group a bad history. Stephern and Elizabeth have been much more
helpful. I notice Mr Moore does not come here it some reason.
Actually I did see one post referring to him, unusually, turning up
once to address somebody's statements that were so off the mark he had
to address them.


This sort of rubbish, 99% irrelevant, is wrecking this thread.

[Steve]

Here is another link to a quick implementation of c to forth, and
optimising compiler delivering code like the author's, Paul Rubin
posted elsewhere.

It is briefly down in the document:

http://www.yosefk.com/blog/my-history-with-forth-stack-machines.html


Steve.

[Mark Wills]

Well, okay, let's re-wind a bit. I'm genuinely trying to submit
something positive here!

Can we please start with what this ring product will do? What features
will it have? A small display? Some LEDs? A couple of buttons? A
vibrator? Will it communicate with a smartphone? Will that phone be
the main host?

Can you please elaborate on what it would be used for?

Lets start there. If you have any links for other similar products
that would be good.

Thanks

[Albert van der Horst]

In article <db16461d-616b-43a1...@a16g2000pbu.googlegroups.com>,
Steve <nosp...@gmail.com> wrote:
>

<SNIP>

>
>
>This sort of rubbish, 99% irrelevant, is wrecking this thread.

Another hour wasted. You really should start your soldering practice.
It bears repeating:
Before that you will get nowhere with the GA144.

[Brad Eckert]

On Tuesday, May 7, 2013 10:36:55 PM UTC-7, Steve wrote:
>
> It has been incredible here, with people professing I don't understand
> what I want, while they are misunderstanding everything, unrealistic,
> taking most things out of context and being rather irrelevant.
>

Yeah, but you're all talk. Talk about ideas, talk about discussion, talk about miscommunication. Where's the beef? You can try to herd cats, but if you scold them will they listen to you?

We're interested in design choices and trade-offs, algorithms, the process of problem solving. Especially when it relates to Forth.

[Paul Rubin]

Mark Wills <forth...@gmail.com> writes:
> Can we please start with what this ring product will do? What features
> will it have?

I miss the Java Ring, but it actually had good reasons for being
programmed in Java. You can find lots of info on it with a web search.
In fact wow, it looks like there are some available on ebay. I doubt if
they still work though: they have an internal battery to run the RTC,
and it can't be replaced, and they are all 5+ years old by now, maybe
older.

[Steve]

If you look up 1 wire on Wikipedia you can see it, the uses are lots.
The Java card is a relative standard, don't know if that was used with
the ring, or something else in those days.

Still, nice link about the compiler Paul. I have not read the article
yet but interesting looking stuff, a real programmer.


Thanks.


Steve.

[Steve]

Mr Brad, you're talking, I'm doing. I'll have the beef, you can keep
the cats. Catch your own beef in the river if you want, I can
slaughter mine on a firmly constructed base, while others flop around
doing in the water. But, still, you miss the point of the thread, is
about the options first, up to you to do something about them, I've
got my own to do, and a designated time schedule late year or next
year to start after present jobs are finished. But I suppose you
missed all that, less talk, and more reading. What, are you
contributing or talking? I lay down the challenge, so far one person
has been doing he vast majority of doing, and some others the vast
majority of nothing.

Thanks.

[Steve]

Albert van der Horst wrote:

> In article <db16461d-616b-43a1...@a16g2000pbu.googlegroups.com>,
> Steve <nosp...@gmail.com> wrote:
> >
> <SNIP>
> >
> >This sort of rubbish, 99% irrelevant, is wrecking this thread.
>
> Another hour wasted. You really should start your soldering practice.
> It bears repeating:
> Before that you will get nowhere with the GA144.

Albert, I'm sorry, I figured out you were being offensive and trolling
before. So there is no need for anymore. There are enough people
joking already. I'm sorry if you find me offensive, but I'm just
trying to do the right thing.

[Paul Rubin]

Steve <nosp...@gmail.com> writes:
> The Java card is a relative standard, don't know if that was used with
> the ring, or something else in those days.

Yes, the ring had a microprocessor button running Javacard. They also
made the Java iButton, which was the same thing without the ring.
Neither was as secure as the manufacturer claimed, but it was (because
of the RTC among other things) a step up from a typical low end smart
card. I think it's unfortunate that those products are discontinued, as
I still have applications that could use them. However, as much as I'm
not a fan of Java, I think someone trying to make a comparable product
now should do it in about the same way as DS did, using Javacard.

[Steve]

I'll take you as sincere, Mark. There has been too much fool playing
around here lately, to not take things with some salt.

The answers are not good. Because I'm not doing the simple ring, but
moved up my commercial project, everything is under wraps, I would be
a fool not too. There will likely be patents, and I also don't want
to find Chinese manufacturers doing copies by the time it comes out.
If they want to buy it that's ok. But, it will likely be on par or
better than Apple's plan. There is ussualy not one thing that I've
come up with that Apple has also, that I didn't come up with years and
years before they did. But the reality is that I probably wont be
able to do everything I could do at first. To talk about it before
you are getting ready for launch is not good business. But not many
people will understand that here. As stated before, proper design
work is not likely to start till late year, at least.

But it is more productive to talk about the simple community ring
project. That will give a good indication of base functionality, and
I don't mind if Chinese manufacturers want to order a lot of misc
chips and do their own. The community ring is also not meant to be a
basis for the comnercial ring, which will have a lot of new
innovations, a different structure.

It is after 4 am, so you will have to forgive the writing.

It goes on your finger, contains a consumer wireless device, Bluetooth
is probably the best, even if just the low powered personal area
network version, a touch surface, a button or two, a piezo electric
speaker and vibrator and microphone. A e-ink, or other electrowetting
readout maybe used, due to low power usage on mostly static
information displays. To get things in and out is an issue. BT is
great for communications with devices, not so good for storage,
leaving you to use another device to access downloads. Unfortunately
no propposed consumer electro magnetic general io interface standard
has penetrated the market, or other contactless card or acceptable
general near interface standard (don't know about nfc plans). So, USB
and micro SD are two options. There is a few flat memory card
standards that go into a USB slot. Charging could be by USB. I'm not
up to date with the latest battery technology. Now you have a storage
device that can communicate with your phone, and other things.

Now let's go forwards, you have a bt wireless storage device on your
finger that can play and record sound and carry files that can be used
as an id ring, or nfc device for anything, just on the community
ring. That is three to five products in one just there, and sellable.

But it is late and I'll have to leave it today.


Steve.

[Steve]

Paul Rubin wrote:
> Steve <nosp...@gmail.com> writes:
> > The Java card is a relative standard, don't know if that was used with
> > the ring, or something else in those days.
>
> Yes, the ring had a microprocessor button running Javacard. They also
> made the Java iButton, which was the same thing without the ring.

Yes, I wanted to get one at the time, probably still have the Java
card information somewhere.

> Neither was as secure as the manufacturer claimed, but it was (because
> of the RTC among other things) a step up from a typical low end smart
> card. I think it's unfortunate that those products are discontinued, as
> I still have applications that could use them. However, as much as I'm
> not a fan of Java, I think someone trying to make a comparable product
> now should do it in about the same way as DS did, using Javacard.

Yeah, if I was a Java fan I .. probably would want to, but I would
like to set something up new for forth instead. Little things can go
a long way.

Is Java card the one used in phone sims? They use usb on Sims to.
People don't realise having the lowest powered per performance
processor gives you a big advahtage in these applications. I would
even use the GA4 for a simple one, if the interfacing was not so bad
(memory and comms). Could you imagine if they put a 18bit ram
execution space, or four, on even the existing chip package?

Could you tell us more about the different applications that it
eventually got used for Paul?

[WJ]

Steve wrote:

> I would like to put some ideas out to increase minimal instruction set
> computer processors usefulness,

I would like you to stop posting crap that has nothing to do
with programming.

[Steve]

we don't program on stone tablets.

[Paul Rubin]

Steve <nosp...@gmail.com> writes:
> Is Java card the one used in phone sims?

Yes.

> People don't realise having the lowest powered per performance
> processor gives you a big advahtage in these applications.

The main applications of javacard involve public key cryptography which
needs fast multiplication. There were discussions on this newsgroup a
while back about the GA144's power efficiency at multiplication compared
with a conventional low powered DSP and they were either inconclusive or
unfavorable to the GA144 depending on your point of view. The issue is
that DSP's have dedicated multiplication hardware while the GA144 takes
an efficiency hit by having to multiply in software.

> I would even use the GA4 for a simple one, if the interfacing was not
> so bad (memory and comms). Could you imagine if they put a 18bit ram
> execution space, or four, on even the existing chip package?

There were two models of the java ibutton. One had 6k of ram and the
other had 132k if I remember right. I think they both used an
8051-derived core.

> Could you tell us more about the different applications that it
> eventually got used for Paul?

The same sorts of things smart cards are used for (authentication tokens
mostly), but they had extra capabilities because of the sealed RTC, and
they also supposedly were more secure against certain types of attacks,
since the processor was not accessible to the outside except through the
1-wire interface.

[Elizabeth D. Rather]

On 5/8/13 9:17 PM, Paul Rubin wrote:
> Steve <nosp...@gmail.com> writes:
>> Is Java card the one used in phone sims?
>
> Yes.
>
>> People don't realise having the lowest powered per performance
>> processor gives you a big advahtage in these applications.
>
> The main applications of javacard involve public key cryptography which
> needs fast multiplication. There were discussions on this newsgroup a
> while back about the GA144's power efficiency at multiplication compared
> with a conventional low powered DSP and they were either inconclusive or
> unfavorable to the GA144 depending on your point of view. The issue is
> that DSP's have dedicated multiplication hardware while the GA144 takes
> an efficiency hit by having to multiply in software.

You don't need a GA144. FORTH, Inc. produced smart card apps between 4
and 10 times faster than Java in the late 90's, even without specialized
DSP hardware (although some chip mfrs aiming at smart card apps do have
DSP instructions). We had a version for some AVR parts used in smart
cards. But Java's political clout (it was adopted as a "standard" by
VISA) was to much to overcome.

We developed all the cryptography code in the 90s as part of the OTA
project.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Steve]

Paul Rubin wrote:
> Steve <nosp...@gmail.com> writes:
> > Is Java card the one used in phone sims?
>
> Yes.
>
> > People don't realise having the lowest powered per performance
> > processor gives you a big advahtage in these applications.
>
> The main applications of javacard involve public key cryptography which
> needs fast multiplication. There were discussions on this newsgroup a
> while back about the GA144's power efficiency at multiplication compared
> with a conventional low powered DSP and they were either inconclusive or
> unfavorable to the GA144 depending on your point of view. The issue is
> that DSP's have dedicated multiplication hardware while the GA144 takes
> an efficiency hit by having to multiply in software.

Sorry Paul and Elisabeth, I was referring to low powered applications
like Sims and rings, rather than Java devices or cryptology. People
seem to act like misc is a no advantage to use, so I was pointing out
that it has one major advantage at least. I actually sense there is a
strong and illogical anti misc vibe going around that has no place in
this thread. It is not with any credibility people are doing this,
just smells like bias. There should have been a blank line between
that statement and the one about java card, my apologies for confusing
it.

> > I would even use the GA4 for a simple one, if the interfacing was not
> > so bad (memory and comms). Could you imagine if they put a 18bit ram
> > execution space, or four, on even the existing chip package?

Sorry, the left out blank line again. I was definitely referring to a
ring here separately from the sim.

> There were two models of the java ibutton. One had 6k of ram and the
> other had 132k if I remember right. I think they both used an
> 8051-derived core.

6k, I remember back to the days of the Atari 2600, up to before the
Commodore 64 area, what could be done with 6k. :-)

To think, we could have had 8051/z8 and 80, forth watches and rings
years ago.


Thanks for your time Paul.


Steve.

[Steve]

Reconsidering some of my old ideas, which I forgot, I'm back towards a
lesser $1 cost Forth Ring product, I might try to get that part
working before the rest of the advanced functionality.

In reality, something along similar lines of the Java ring could be
made in bulk for the price more easily, but would not be as
interesting.


Thanks


Steve.

[Steve]

Steve wrote:
> Reconsidering some of my old ideas, which I forgot, I'm back towards a
> lesser $1 cost Forth Ring product, I might try to get that part
> working before the rest of the advanced functionality.

Sorry, using a GA4 potentially, but there is none available.


> Thanks
>
>
> Steve.

[rickman]

This is a message size I can relate to. But maybe I forgot, what is a
Forth Ring?

--

Rick

[Steve]

Ok, now that trolling behavior is down to a minimum I will hopefully
be able to get back to you in a few weeks.

But some questions first:

Which groups would be best to ask the following questions about
Bluetooth and wifi?:

For hardware which is smaller, lower energy or more affordable?

For software, which is smaller or less processing demand?


----------

Now about trolling, I hope all employers know that the shortness or
abundance of useful information in a post is directly proportion to
usefull intelligence. Even if pretend waffle, it is a sign of lack or
of intelligence in integrity and honesty. All of which everybody here
seems to have excelled themselves in various directions.

Post size is variable. Sometimes, particularly in highly intricate
threads like this, a lot needs to be accessed quickly, leading to an
abundance of information in, hopeful
ly, a team effort, rather than an abundance of disruption of effort
from non team players. Sometimes not much needs to be said, except
by the subject maintainer/moderator/supervisor to keep the work up to
date.

There are various tactics of trolls that may not be obvious, even to
people they are trying to annoy. One less obvious tactic, is to
deliberately mistake information in order to have and maintain
wasteful conversation. Like in your business, you may not know if an
employee really knows something you are not familiar with or is just
pretending, so it is in Usenet discussions, even professionals can
have a hard time telling who is right, so discussions need to be
considered cartfully.


Trolling usually exists because individuals perceive they can do it
unseen or get away with it, much like may happen with employees in a
work place, where as some employees will be naturally trust worthy
wherever seen or not.


When reading Usenet forums. please note these behaviours. Also if the
troll is a useful and employable, malignant genius like the fictional
House or Sherlock Homes, or still suitable and employable, or just a
moral dope to your needs.

[rickman]

Dude, you are stepping out of line. Instead of responding emotionally
and insulting people, just show them what they are missing. I'm not
against you. I just don't understand you. Brad seems like a really
nice guy to me and trust me, he has done a *lot* in, with and for Forth.
He is not a guy to dis this way.

On the other hand, feel free to dis me all you want. I don't know that
I deserve it really, but it's no big deal. Or you can just show us the
beef and shut us all up! For example, your challenge... what is that
about? What is the challenge *exactly*?

--

Rick

[Brad Eckert]

On Tuesday, May 14, 2013 9:59:53 PM UTC-7, rickman wrote:
>
> He is not a guy to dis this way.
>

Well, Steve has passion about programming and Forth and seems willing to think and listen. I think he'll grow in his capacity to handle constructive criticism, and being offended with the growth process doesn't help.

[Steve]

(Rick)

Folks, here we have Mr Rick Collins, alleging to be the moderate voice
of reason, as I predicted. Alledging I stepped out of line in my
defence against somebody failing to take into account the previous
posts, as other people have been playing at, then who dissed me to
provoke, after I had treated them nicely, with Rick himself acting
like he has not been stepping out of line. He is also acting like he
does not induce emotional states in people through his repeated action
to the extreme, that becomes as intolerable as someone having to put
up with tolls crawling over them pretending to be cockroaches. Note
also this is an old message he is replying to and has had plenty of
opportunity to reply to before.

He knows that the plan is actually to produce product, like he now is
alleging to suggest, but if he can keep me talking to him I won't have
time.

To show how authentic his sincerity is, have a look at his previous
post:

We have been talking about the ring project from the beginning of the
thread and before in another thread. He has also been provoking long
messages of discussion where I have consistently cleared up his
alleged misunderstanding to show him, and others, what they are
missing, while he confuses things further, which he now is trying to
suggest I should continue to do, like I have not been doing it.
Folks, show him what sort of reaction..

[Steve]

Brad, you know you stepped out of line on a delicate prolonged
situation, with no relevant criticism. I'm saying this to fill others
in on the history of what is wrong. I have been receiving
constructive criticism, unlike a few people in the thread who receive
none.

Stop trying to trawl me. You have a short history here, and while I
am reasonably happy with your post numbers, what you said about
handling constructive criticism did not match the reality.
Constructive criticism goes both ways, I can defend my working out or
accept it is not right, but others seem to be unable to accept
constructive criticism of their criticism.

Now, both of you, that is enough, this is a work thread.

You can start your own threads to talk.


Thanks


Steve.

[Steve]

After some consideration, use of open cl with the os and android
interfacing projects allows future misc to be easily used for co-
procesing. Even if I have to use code formating to archieve extra
speed. Code formating is a technique I came up with years ago, that
uses a certain format of coding in the original language that more
efficiently matches the code of the target environment. In this case
normal CL code could be used, but forthers could code to a format that
suites a misc environment on misc devices. To simpliy this forth and
misc primitives could be encoded to be picked up as straight code on a
misc device.

The small simple os could not only work with Android but as it is
aimed to interface a number of open api's, it could be made into an
alternative to Android for smaller devices. To go one more clear
logical step, the type of integration with open cl above could be
applied to integration with Java or Android. In this case, only a cut
down functional version of Java or Android needs to be used to make a
device, but the code would still be compatible with all normal devices
and sold through the playstore.

Now as part of figuring out what can be used in a simple os, from the
open environment, I would like to ask, if anybody knows anything about
tiny open firmware project? I saw it listed, but when I went to the
site the site was gone (same site as the b16). Anybody, except the
insultingly disrespectful few that have had nothing helpful to say in
the past.


Thanks


Steve

[Brad Eckert]

On Tuesday, May 14, 2013 11:13:08 PM UTC-7, Steve wrote:
> Brad, you know you stepped out of line on a delicate prolonged...

I don't think I like your tea party.

[Alex McDonald]

Steve doesn't like Usenet. I wonder why he's here?

[Alex McDonald]

ftp://ftp.taygeta.com/pub/Forth/TinyBoot/

[Steve]

Don't trawl Alex. Troll arrogance likes Usenet for the wrong reason,
mad hatters babbling on trying to disrupt reason for no reason but
their sense of pride and power :( I think the evidence proves it.

Thanks for the link, but why?

[Alex McDonald]

I really do wonder why you're here, since you so obviously don't like
it. You're free to leave.

>
> Thanks for the link, but why?

Why what?

[visua...@rocketmail.com]

On Tuesday, May 7, 2013 4:28:04 PM UTC-4, the_gavino_himself wrote:
> If then forth on a misc chip could run tcp ip and a gui for a web browser...wow
> you are on your way to both forth web servers and forth client nodes used by
> businesss to replace the pc. of course with less cost and code.
> Business are still paying terrible prices for server and pc of 10,000 a node.
> Forth could be a big business if it could provide an alternative but
> handle many concurrent users interacting.
> Business spends 10 million a year just on software to support a few thousand
> concurrent users and have 50 to 20 people maintaining it all.

Reminds me on a project I once had: to build a converter - hardware and software - between IBM's SNA under VTAM and Siemens MSV2 on their BS2000 computer. Hardware was my own R6511AQ board plus a Zilog HDLC chip, and software was RSC-Forth.

I was paid 9000.00 altogether, and I after finishing and delivery I learned that Daimler-Benz saved 10,000.00 per month on MSV2 licenses to IBM after installation of my converter.

[visua...@rocketmail.com]

On Thursday, May 9, 2013 3:30:11 AM UTC-4, Elizabeth D. Rather wrote:
> > Steve <nosp...@gmail.com> writes:
> >> Is Java card the one used in phone sims?

> > Yes.
> >> People don't realise having the lowest powered per performance
> >> processor gives you a big advahtage in these applications.

> > The main applications of javacard involve public key cryptography which

> > needs fast multiplication...

> You don't need a GA144. FORTH, Inc. produced smart card apps between 4
> and 10 times faster than Java in the late 90's, even without specialized
> DSP hardware (although some chip mfrs aiming at smart card apps do have
> DSP instructions). We had a version for some AVR parts used in smart
> cards. But Java's political clout (it was adopted as a "standard" by
> VISA) was to much to overcome.
> We developed all the cryptography code in the 90s as part of the OTA
> project.
>
> Cheers,
> Elizabeth

I worked at EuroSignCard Luxembourg in 2000 and I was involved in the eEurope Smart Card Charter, learning about the OTA.

It doesn't matter which microprocessor and which software is running on a smart card, because only the smart card data are allowed to be accessed using a special algorithm. Real security is only possible if there is no direct access to the on chip microprocessor, and direct access to the on chip software is not allowed either. That have been the security rules back then. And for security an external smart card reader is needed. Integrating a smart card reader into a PC would allow to break security.

VISA would have done a better job by accepting a smart card with Forth on chip.