f



Tethered Forths (was: The meaning of xt in Forth-94)

On 7/2/2015 3:10 AM, Raimond Dragomir wrote:
 >> BTW, I would love to see a forth system targeted to ARM chips
 >> (and/or the MSP430) that keeps the dictionary on the host other
 >> than the executable portions.  But maybe this is not really
 >> important.  Mecrisp seems to support reasonably small targets, just
 >> not the really small ones. --
 >>
 >> Rick
 >
 > This is my plan. I have the 'host' part quite ready now. The only
 > 'application' that I'm interested in writing with it is
 > cross-compilers. (although host' can be some bigger embedded systems
 > like BBB or rPi).
 >
 > My dictionary space is separated completely because I want it to be
 > stored anywhere (internal flash, external spi flash, sd card, or even
 > serial link (another machine - typically 'host')). The code is
 > tokenized and it's really compact. It seems that the dictionary is
 > 2.5 times bigger than the real code!
 >
 > My intended target architectures will be:
 >
 > - very small: targets with no REPL. No need of dictionary at all

What is REPL?

 > - small: dictionary over the serial link. REPL needs some host
 > special console or terminal program of course.
 >
 > - medium: dictionary on target, target has REPL but only the
 > interpreter (no compiler). Here there are two cases: - dictionary
 > merged with code - in internal flash - dictionary is on an external
 > medium (serial flash, sd card) These cases are only for the
 > cross-compiler to know if it should merge the dictionary with the
 > code. The target kernel will know what medium for the dictionary will
 > have anyway. For this architecture I'm mainly thinking of Cortex-M
 > chips around 32k flash 4K ram. They are a lot. If you afford a serial
 > spi flash on the system (the smallest 512kbytes serial flash costs
 > $0.15 these days lol) you can have the dictionary local, with a
 > standard REPL.
 >
 > - large: typical standalone forth system with REPL
 > interpreter/compiler. I name it large because it "must" provide all
 > the features of the 'host' one: file system (sd card based) with full
 > include file stack, full wordlist support, nested quoations and
 > locals, well everything. Here is a system that will suport the large
 > model (I have a few designs like this): - LPC4088 120MHz Cortex-M4 -
 > 8MB / 32MB SDRAM - 8MB serial quad spi flash - SD card with Chan's
 > fatfs - Ethernet 10/100 with uip stack (I choos uip which is much
 > simpler but works perfectly. I'm building other high level protocols
 > on it) - a cooperative multitasking os (we are forthers, don't we :)
 >
 > For such a system my only problem right now is to decide if I need an
 > editor or not... I can upload files with tftp protocol and then type
 > "include file" in the REPL. I also have 'cat' command to view files.
 > I miss an editor so that the system to be completely standalone.

So you are going to add file system support to your Forth?  That could 
be very useful in an embedded system.  Or will this be under some other 
OS?  Ethernet is even better!  What target platform are you using to 
develop this?

-- 

Rick
-- 

Rick
0
rickman
7/2/2015 3:00:40 PM
comp.lang.forth 7148 articles. 0 followers. markrobertwills (871) is leader. Post Follow

7 Replies
391 Views

Similar Articles

[PageSpeed] 40

rickman <gnuarm@gmail.com> writes:
> What is REPL?

Read-eval-print loop, Lisp terminology for an interactive text
interpreter.  I think this is sometimes called the QUIT loop in Forth.
0
Paul
7/2/2015 3:22:27 PM
On 7/2/2015 11:22 AM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> What is REPL?
>
> Read-eval-print loop, Lisp terminology for an interactive text
> interpreter.  I think this is sometimes called the QUIT loop in Forth.

Hmmm... that sounds like there are no comms back to the host which 
implies that all debugging would be through some external device like a 
JTAG or one wire debugger.

-- 

Rick
0
rickman
7/2/2015 3:31:39 PM
joi, 2 iulie 2015, 18:00:45 UTC+3, rickman a scris:
> On 7/2/2015 3:10 AM, Raimond Dragomir wrote:
>  >> BTW, I would love to see a forth system targeted to ARM chips
>  >> (and/or the MSP430) that keeps the dictionary on the host other
>  >> than the executable portions.  But maybe this is not really
>  >> important.  Mecrisp seems to support reasonably small targets, just
>  >> not the really small ones. --
>  >>
>  >> Rick
>  >
>  > This is my plan. I have the 'host' part quite ready now. The only
>  > 'application' that I'm interested in writing with it is
>  > cross-compilers. (although host' can be some bigger embedded systems
>  > like BBB or rPi).
>  >
>  > My dictionary space is separated completely because I want it to be
>  > stored anywhere (internal flash, external spi flash, sd card, or even
>  > serial link (another machine - typically 'host')). The code is
>  > tokenized and it's really compact. It seems that the dictionary is
>  > 2.5 times bigger than the real code!
>  >
>  > My intended target architectures will be:
>  >
>  > - very small: targets with no REPL. No need of dictionary at all
> 
> What is REPL?
> 
>  > - small: dictionary over the serial link. REPL needs some host
>  > special console or terminal program of course.
>  >
>  > - medium: dictionary on target, target has REPL but only the
>  > interpreter (no compiler). Here there are two cases: - dictionary
>  > merged with code - in internal flash - dictionary is on an external
>  > medium (serial flash, sd card) These cases are only for the
>  > cross-compiler to know if it should merge the dictionary with the
>  > code. The target kernel will know what medium for the dictionary will
>  > have anyway. For this architecture I'm mainly thinking of Cortex-M
>  > chips around 32k flash 4K ram. They are a lot. If you afford a serial
>  > spi flash on the system (the smallest 512kbytes serial flash costs
>  > $0.15 these days lol) you can have the dictionary local, with a
>  > standard REPL.
>  >
>  > - large: typical standalone forth system with REPL
>  > interpreter/compiler. I name it large because it "must" provide all
>  > the features of the 'host' one: file system (sd card based) with full
>  > include file stack, full wordlist support, nested quoations and
>  > locals, well everything. Here is a system that will suport the large
>  > model (I have a few designs like this): - LPC4088 120MHz Cortex-M4 -
>  > 8MB / 32MB SDRAM - 8MB serial quad spi flash - SD card with Chan's
>  > fatfs - Ethernet 10/100 with uip stack (I choos uip which is much
>  > simpler but works perfectly. I'm building other high level protocols
>  > on it) - a cooperative multitasking os (we are forthers, don't we :)
>  >
>  > For such a system my only problem right now is to decide if I need an
>  > editor or not... I can upload files with tftp protocol and then type
>  > "include file" in the REPL. I also have 'cat' command to view files.
>  > I miss an editor so that the system to be completely standalone.
> 
> So you are going to add file system support to your Forth?  That could 
> be very useful in an embedded system.  Or will this be under some other 
> OS?  Ethernet is even better!  What target platform are you using to 
> develop this?
> 
> -- 
> 
> Rick
> -- 
> 
> Rick

You already got the answer for REPL :)

I use a win7 box, 32bit.
I test the system on a BBB and a cubie board also.

I already have file system support, just a wrapper for some FILE* c functions. I'm only supporting binary mode.

For my "large" cortex-m systems with sd cards I already have the fatfs
working in the c kernel. Only that I have to do more work to port it
effectively, because it's not quite the same thing as standard c FILE*.
But the cortex-m large model is not my first priority now.

My first priority now is cross-compilation support. I want to make sure
that my cross-compilers development will be as easy as possible before
making the next step.



0
Raimond
7/2/2015 3:35:36 PM
joi, 2 iulie 2015, 18:31:40 UTC+3, rickman a scris:
> On 7/2/2015 11:22 AM, Paul Rubin wrote:
> > rickman <gnuarm@gmail.com> writes:
> >> What is REPL?
> >
> > Read-eval-print loop, Lisp terminology for an interactive text
> > interpreter.  I think this is sometimes called the QUIT loop in Forth.
> 
> Hmmm... that sounds like there are no comms back to the host which 
> implies that all debugging would be through some external device like a 
> JTAG or one wire debugger.
> 
> -- 
> 
> Rick

Read-eval-print loop is from the point of view of the device, not the human
operator. The machine reads the input text, evaluate it (execute the 
commands, etc) and then prints the results of the executed commands (display
in fact).
REPL is my shortcut for the forth interactive text interpreter/shell,
being it classical or "simulated" (tethered). It's a shorter name for the thing :)
0
Raimond
7/2/2015 3:40:55 PM
On 7/2/2015 11:35 AM, Raimond Dragomir wrote:
> joi, 2 iulie 2015, 18:00:45 UTC+3, rickman a scris:
>> On 7/2/2015 3:10 AM, Raimond Dragomir wrote:
>>>> BTW, I would love to see a forth system targeted to ARM chips
>>>> (and/or the MSP430) that keeps the dictionary on the host
>>>> other than the executable portions.  But maybe this is not
>>>> really important.  Mecrisp seems to support reasonably small
>>>> targets, just not the really small ones. --
>>>>
>>>> Rick
>>>
>>> This is my plan. I have the 'host' part quite ready now. The
>>> only 'application' that I'm interested in writing with it is
>>> cross-compilers. (although host' can be some bigger embedded
>>> systems like BBB or rPi).
>>>
>>> My dictionary space is separated completely because I want it to
>>> be stored anywhere (internal flash, external spi flash, sd card,
>>> or even serial link (another machine - typically 'host')). The
>>> code is tokenized and it's really compact. It seems that the
>>> dictionary is 2.5 times bigger than the real code!
>>>
>>> My intended target architectures will be:
>>>
>>> - very small: targets with no REPL. No need of dictionary at all
>>
>> What is REPL?
>>
>>> - small: dictionary over the serial link. REPL needs some host
>>> special console or terminal program of course.
>>>
>>> - medium: dictionary on target, target has REPL but only the
>>> interpreter (no compiler). Here there are two cases: -
>>> dictionary merged with code - in internal flash - dictionary is
>>> on an external medium (serial flash, sd card) These cases are
>>> only for the cross-compiler to know if it should merge the
>>> dictionary with the code. The target kernel will know what medium
>>> for the dictionary will have anyway. For this architecture I'm
>>> mainly thinking of Cortex-M chips around 32k flash 4K ram. They
>>> are a lot. If you afford a serial spi flash on the system (the
>>> smallest 512kbytes serial flash costs $0.15 these days lol) you
>>> can have the dictionary local, with a standard REPL.
>>>
>>> - large: typical standalone forth system with REPL
>>> interpreter/compiler. I name it large because it "must" provide
>>> all the features of the 'host' one: file system (sd card based)
>>> with full include file stack, full wordlist support, nested
>>> quoations and locals, well everything. Here is a system that will
>>> suport the large model (I have a few designs like this): -
>>> LPC4088 120MHz Cortex-M4 - 8MB / 32MB SDRAM - 8MB serial quad spi
>>> flash - SD card with Chan's fatfs - Ethernet 10/100 with uip
>>> stack (I choos uip which is much simpler but works perfectly. I'm
>>> building other high level protocols on it) - a cooperative
>>> multitasking os (we are forthers, don't we :)
>>>
>>> For such a system my only problem right now is to decide if I
>>> need an editor or not... I can upload files with tftp protocol
>>> and then type "include file" in the REPL. I also have 'cat'
>>> command to view files. I miss an editor so that the system to be
>>> completely standalone.
>>
>> So you are going to add file system support to your Forth?  That
>> could be very useful in an embedded system.  Or will this be under
>> some other OS?  Ethernet is even better!  What target platform are
>> you using to develop this?
>>
>> --
>>
>> Rick --
>>
>> Rick
>
> You already got the answer for REPL :)
>
> I use a win7 box, 32bit. I test the system on a BBB and a cubie board
> also.
>
> I already have file system support, just a wrapper for some FILE* c
> functions. I'm only supporting binary mode.
>
> For my "large" cortex-m systems with sd cards I already have the
> fatfs working in the c kernel. Only that I have to do more work to
> port it effectively, because it's not quite the same thing as
> standard c FILE*. But the cortex-m large model is not my first
> priority now.

Just to be clear, this is running under an OS on the BBB target, right? 
  I assume a Linux of some flavor?


> My first priority now is cross-compilation support. I want to make
> sure that my cross-compilers development will be as easy as possible
> before making the next step.

When do you expect to support one of the smaller models for something 
like a CM4 with no external memory?  I just bought a couple of MSP430s 
as well.

Not sure what I can do to help, but I'm available if there is something 
I can do.  I'm good at writing if you would like me to work on 
documentation.

-- 

Rick
0
rickman
7/2/2015 3:50:11 PM
> Just to be clear, this is running under an OS on the BBB target, right? 
>   I assume a Linux of some flavor?
> 

Oh yes, sorry I didn't understand the question.
My BBB and also cubie board have both some Debian linux. I compile
the kernel directly on them (so you must have the gcc installed).

These are my 'hosts'. My real host is a windows pc but I want to be
compatible with these linux embedded 'hosts' because "you never know" :)
I have a potential application for a BBB or a rPi and cross-compiling
for such targets is a non-sense...

> 
> > My first priority now is cross-compilation support. I want to make
> > sure that my cross-compilers development will be as easy as possible
> > before making the next step.
> 
> When do you expect to support one of the smaller models for something 
> like a CM4 with no external memory?  I just bought a couple of MSP430s 
> as well.
> 
Those are my priority, that's why I want to have the cross-compilation
working smoothly.

> Not sure what I can do to help, but I'm available if there is something 
> I can do.  I'm good at writing if you would like me to work on 
> documentation.
> 
You can help with a MSP430 kernel (just the virtual machine) because
I never worked with the thing. Of course if you know the MSP430 chips...

But the documentation is probably the most usefull thing you can help. I admit
I'm not very good at it and I really don't have enough time.
We can keep in touch. I only want to have my cross-compilation stabilized
and then I will consider my system stable. 

My first cross-compiler will be almost for sure for a Cortex-M general
architecture (it is not a native code compiler so it will not care about
the M0/M3/M4 differences). In fact it will be quite a generic cross compiler
for 32bit targets with separate code, ram and dictionary spaces.

As a general architecture, the kernels will be written in C and or asm
and will provide everything that will not be written in forth (at the bare
minimum the virtual machine, but also HAL drivers at some level). The 
cross-compiler will need some sort of kernel map file, and possibly the
kernel binary in order to merge it with the application binary for
generation of a single binary (this is optional).

If you really want native code compilers like VFX, you aren't lucky...

> -- 
> 
> Rick

0
Raimond
7/2/2015 4:25:18 PM
On 7/2/2015 12:25 PM, Raimond Dragomir wrote:
>
>> Just to be clear, this is running under an OS on the BBB target, right?
>>    I assume a Linux of some flavor?
>>
>
> Oh yes, sorry I didn't understand the question.
> My BBB and also cubie board have both some Debian linux. I compile
> the kernel directly on them (so you must have the gcc installed).
>
> These are my 'hosts'. My real host is a windows pc but I want to be
> compatible with these linux embedded 'hosts' because "you never know" :)
> I have a potential application for a BBB or a rPi and cross-compiling
> for such targets is a non-sense...
>
>>
>>> My first priority now is cross-compilation support. I want to make
>>> sure that my cross-compilers development will be as easy as possible
>>> before making the next step.
>>
>> When do you expect to support one of the smaller models for something
>> like a CM4 with no external memory?  I just bought a couple of MSP430s
>> as well.
>>
> Those are my priority, that's why I want to have the cross-compilation
> working smoothly.
>
>> Not sure what I can do to help, but I'm available if there is something
>> I can do.  I'm good at writing if you would like me to work on
>> documentation.
>>
> You can help with a MSP430 kernel (just the virtual machine) because
> I never worked with the thing. Of course if you know the MSP430 chips...
>
> But the documentation is probably the most usefull thing you can help. I admit
> I'm not very good at it and I really don't have enough time.
> We can keep in touch. I only want to have my cross-compilation stabilized
> and then I will consider my system stable.
>
> My first cross-compiler will be almost for sure for a Cortex-M general
> architecture (it is not a native code compiler so it will not care about
> the M0/M3/M4 differences). In fact it will be quite a generic cross compiler
> for 32bit targets with separate code, ram and dictionary spaces.
>
> As a general architecture, the kernels will be written in C and or asm
> and will provide everything that will not be written in forth (at the bare
> minimum the virtual machine, but also HAL drivers at some level). The
> cross-compiler will need some sort of kernel map file, and possibly the
> kernel binary in order to merge it with the application binary for
> generation of a single binary (this is optional).
>
> If you really want native code compilers like VFX, you aren't lucky...

I'm happy to help as I can.  You can email me directly at gnuarm dot 
2007 at arius dot com.

-- 

Rick
0
rickman
7/2/2015 4:55:48 PM
Reply:

Similar Artilces:

forth in forth
I came across this in the archives: >The widely shared belief (among both Forthies >and outsiders) that every "real" Forth programmer hacks together >his own compiler/interpreter/programming environment also makes >the Forth community look frivolous or at best naive. Most people >who program for a living know that there are more useful ways to >spend their time than building their own programming environment -- >the key to productivity is leveraging off other peoples' work. HERESY in the Forth community! Imagine... NOT coming up with your own CASE...

When did FORTH become Forth
Just curious, If I recall correctly, didn't Forth used to be FORTH? Blueeyedpop wrote: > Just curious, If I recall correctly, didn't Forth used to be FORTH? The IBM 1130 didn't do lower case. -jpd (co-developer of FORGO, a FORTRAN compile&go system for the 1130) Blueeyedpop wrote: > Just curious, If I recall correctly, didn't Forth used to be FORTH? Yes, back when we used A(or K)SR33s. Jerry -- Engineering is the art of making what you want from things you can get. ����������������������������������������������������������������������� When did we stop...

applications in forth or forth libraries
is there a archive of applications built in forth? something like cpan for perl? etc.? On Dec 2, 3:46=A0pm, gavino <gavcom...@gmail.com> wrote: > is there a archive of applications built in forth? > > something like cpan for perl? etc.? Well, you'll find some things. Take a look at forthfreak.net to get the pointers. The main problem is that even "ANS compatible" Forths are not compatible at all if you add the mindset of the programmer to the standard. There are some classes of problems that are better solved by non-ANS extensions than with ANS. And almost every...

Forth is to program , Forth is NOT to study ..
Forth is to program , not to learn , nor study . Study is for students , Students dont eat well . They seek help and subsidy , and credencials .. all , far from productive programming . There is NO arguement , NO arguement in Forth , cause it is always done LEAST WORK , FASTEST runtime . In 40 years , Humans have built up school systems , universities, industries and factories Since it is a "system" , its uncompetitive . Competition and profits are impossible from any system . Accountants can see the "books" indicate this is ...

no forth pc? no forth replacement for mysqL? a la www.prevayler.org? no forth appserver?
how about a forth clone of iceWM in 1% the code? On Wednesday, February 12, 2014 8:36:49 PM UTC-6, the_gavino_himself wrote: > how about a forth clone of iceWM in 1% the code? Right now, what I'm interested in is niche RPGMaker-type games on Android. I've done some of this work already in Java, including creating a map editor (on Android) and a playable demo, using First Seed Material (http://www.tekepon.net/fsm/index.php) assets I gave up on my last alternatives to Java when I found Terminal IDE, which allowed me to move code all the way from Java source to installable ...

Forth
Hi Chris, http://www.figuk.plus.com/codeindex/index.html Your fourth code index, at the above URL looks really excellent and gives a good show for our favorite language. I am continuing to enjoy reading it. Currently, I have sorted it by applications. Applications are the area of Forth that are my favorite. I am wondering if a version might be made available to catalog editor words, commands and functions? I have found that many neat features are never used in some of the Fourth editors because it's not obvious where they are or what they do. I really like the idea of your index and ...

Forth
Was there ever a forth on cart for the 8 bitters? And if so, anyone got one they dont want anymore... On Thu, 28 Apr 2005 17:16:43 +0000, Ziggy wrote: > Was there ever a forth on cart for the 8 bitters? Not that I'm aware of. If there is one, I would be interested on Infos. There are a couple of disk based forth systems for the Atari 8bit, see http://www.strotmann.de/twiki/bin/view/APG/LangForth > > And if so, anyone got one they dont want anymore... I can build you one, if you like (8 KB Cart, or AtariMax Flashcart), if you need one for work, not for colle...

FORTH
Has anyone got an implementation working on a TREO 600? Ian implementation of what On Fri, 23 Apr 2004 18:44:49 +0000 (UTC), "Ian Jones" <bellevueparkw@btinternet.com> wrote: |Has anyone got an implementation working on a TREO 600? | |Ian | Alien at Large wrote: > On Fri, 23 Apr 2004 18:44:49 +0000 (UTC), "Ian Jones" > <bellevueparkw@btinternet.com> wrote: > > |Has anyone got an implementation working on a TREO 600? > | > |Ian > > implementation of what What he said in the subject line. (Hint: it&#...

Forth
Anyone know of a version of Forth for RISC OS? I used to use Forthmacs by Hanno Schwalm a few years ago, but I've been out of the Acorn scene since 2000, recently returned with an Iyonix. Hanno's site seems to be down and no reply from his old e-mail address. Anton -- Hi, By the process of poking various fingers onto keys Anton generated this: > Anyone know of a version of Forth for RISC OS? > > I used to use Forthmacs by Hanno Schwalm a few years ago, but I've been out > of the Acorn scene since 2000, recently returned with an Iyonix. Hanno's > site see...

3 books on eBay: Starting FORTH; Thinking FORTH; FORTH Programmer's Handbook
Forth Programmer's Handbook by Conklin and Rather Search for eBay Item # 4129534182 Excellent (like new) condition, second EDITION (August 1998), sixth PRINTING (August 2000). Thinking Forth by Leo Brodie (1984) Search for eBay Item # 4129545378 Excellent (like new) condition, this is the 1994 reprint from Fig Leaf Press (Forth Interest Group, Inc). Starting Forth by Leo Brodie (1987) Search for eBay Item # 4129553634 Second edition, in very good condition. Shows slight wear, but very clean. The softcover binding is in excellent shape. ...

Id love to surf web with 4megs ram forth pc using forth and forth chips
when will this happen? cant wait!! On 9/27/2013 11:52 AM, the_gavino_himself wrote: > when will this happen? > > cant wait!! > I'll happen when someone comes up with several $M in funding. 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." ========================...

3 books on eBay: Starting FORTH; Thinking FORTH; FORTH Programmer's Handbook #2
Forth Programmer's Handbook by Conklin and Rather Search for eBay Item # 4129534182 Excellent (like new) condition, second EDITION (August 1998), sixth PRINTING (August 2000). Thinking Forth by Leo Brodie (1984) Search for eBay Item # 4129545378 Excellent (like new) condition, this is the 1994 reprint from Fig Leaf Press (Forth Interest Group, Inc). Starting Forth by Leo Brodie (1987) Search for eBay Item # 4129553634 Second edition, in very good condition. Shows slight wear, but very clean. The softcover binding is in excellent shape. ...

Forth and AI (Was Re: C vs Forth, was Howerd's ANN : Forth Versus C
Jeff, I would be interested in hearing your experiences using Forth with AI. Steve Graham === Bill Spight <Xbspight@pacbell.net> wrote in message news:<4095C3EA.1549F111@pacbell.net>... >>> > Symbolic Computations on a Personal Computer, -- S. N. Baranoff >>> > >>> > List Processing and Object-Oriented Programming Using Forth, -- >>> > Dennis L Feucht >> It might be interesting to hear from Messers Baranoff and Feucht bout >> the difficulties and trade-offs of using Forth for symbolic >> computati...

Writing ANS Forth in ANS Forth
Hi I'm currently attempting to write an ANS-compliant ITC Forth system for the ARM as a personal learning project. I've implemented my system primitives as code words and am now starting to look at the implementation of the high-level words. I've noticed that a number of systems use non-ANS definitions or user variables such as LATEST in their implementation of high-level words. I'm currently trying to decide how this fits in with a strictly ANS-compliant system. Here are my thoughts so far regarding two possible approaches... 1) Implement non-ANS words and use them in hi...

Web resources about - Tethered Forths (was: The meaning of xt in Forth-94) - comp.lang.forth

Tethered Aerostat Radar System - Wikipedia, the free encyclopedia
The aerostats are large fabric envelopes filled with helium, and can rise up to an altitude of 15,000 feet (4,600 m) while tethered by a single ...

Tethered - Flickr - Photo Sharing!
Reminds me of a commercial I've seen.

HowTo Jailbreak Firmware iOS 4.3 for iPhone 4 / iPhone 3GS / iPod touch 4, 3 / iPad 1 (TETHERED) - YouTube ...
UPDATED July2011 : this tethered method will work on firmware the new 4.3.4 using new 0.9.8b3 redsn0w! Written guide support : http://tinyurl.com/6cqssbq ...

ACT Police officer capsicum sprays tethered dog
A tethered dog was capsicum sprayed by an ACT Police officer during a raid on a Griffith property last month.

A giant, tethered tablet: Acer shows its Android Display
Acer's DA220HQL looks like a giant Android tablet, with its 1920 x 1080 pixel, 21.5-inch touch screen but you wouldn't want to carry it around. ...

Abbott, Hockey tethered to a common fiscal purpose
The government&#8217;s primary job between now and the next election is to repair the fiscal setting. On this score, Tony Abbott and Joe Hockey ...

Man floats above Stampede city on chair tethered to balloons
A man has been charged after attempting to parachute into the Calgary Stampede from a lawn chair suspended by dozens of balloons, police say. ...

Dev-Team: tethered jailbreak for iOS 5.1 with redsn0w ready
... Blog , the team has outlined everything you need to know about jailbreaking and updating to iOS 5.1 and confirm redsn0w is capable of a tethered ...

Why Bother with Wireless? Tablet Owners Stay Tethered
In theory, it’s a choice for a lots of tablet buyers: Do you get the iPad, or Kindle Fire, or whatever, with a wireless data connection, or without ...

Users Will Be Able To Turn An iOS 6 Tethered Jailbreak Into An Untethered Jailbreak
If you’re one of the many with an A4 device running an iOS 6 tethered jailbreak , you’ll be able to convert it into an untethered one via Cydia ...

Resources last updated: 1/25/2016 12:17:57 PM