werty's new number notation ?

Conventionly we have the 10 'ascii' digits possibly mapped into a [I think] 5 * 7 'image matrix' - the '0 to 9' character renderings.

For machine code programming of a 16 bit CPU, it is much more intuitive to have the number, hex in this case, mapped to a 4 * 4 'image'.

So. eg. 13=hex0D would be rendered in it's 4 * 4 'image' as: [13=8+5=8+4+1=##0# : pixel on/off = #/0] 0000 0000 0000 ##0# And the following char, which looks a bit like a "Z" #### > 256 * 16 00#0 > 256 0#00 > 16 #### > 1 represents the number: (8+4+2+1)*256*16+2*256+4*16+15 = ? Wow ! I don't find my calculator ! = hexF24F

I've chosen to give the MSbit first [top-posters are screwed here!].

So if the "Z" looking image represents the number %F24F, then perhaps 'ADD %F24F ...' could be displayed as "+Z..." ? And you could see the individual bits change the "Z", another image.

IMO the concepts which werty is selling are similar to the abacus, which more DIRECTLY represents eg. "7 - 5 = 2", than 'our way of going via the 'symbols': "7", "5", "2", "-","=".

werty correctly realises that skipping the extra stage of translating concepts to text has great advantages, when communicating with a CPU-systems.

Of course we still need the text, in our case ascii, to communicate with humans - because of convention.

== Chris Glur.

Reply to
news
Loading thread data ...

That's a great idea indeed, but let me enhance it a little. How about 8x8 images with 8-bit of color information per pixel, allowing for many more images. In fact the total number of unique images is 2^2048, that's more than enough to associate each atom in the universe with an image and still have enough room for any parallel universes we haven't discovered yet!

And why not give everybody on our planet a unique image, dispensing with passports, social security numbers, barcodes etc! Basically we replace everything with an image! Programming would be a breeze as each image encodes up to 64 instructions! This means you can't make any mistakes any more - you instantly notice there is something wrong in an image!

But let me try out something really far out futuristic... How about associating some of the useless images with the sounds that we can make with our throats? Perhaps use images that can be easily written with a few twists of your wrist. That way we can see an image, immediately know what sound it represents, and quickly write it all in one go! I call this new concept an "alphabet". It's just a dream, but I know I can patent it (in the US anyway). Imagine the possibilities...

Wilco (in qwerty mode)

Reply to
Wilco Dijkstra

This mode of communication must be catching, because your werty- inspired idea is simply an unusable extension to Braille. Both you and werty suffer from unfettered imaginations (that's good) untempered by even a little research and contemplation before hitting the keyboard (that's bad).

Of course you're right there; so, if I'm actually communicating with a human, read this the conventional way.

*plonk*

-- Alex McDonald

Reply to
Alex McDonald

--snip--

Wilco Dijkstra wrote:

No. UI must be based on human attributes. Because of the '5 plus or minus 2 rule', the hex system has already proven to be optimum. Human minds can much more easily handle 4 'items' than 8.

Although colour is great for adding info, the OP's context was/is a minimalist hand-held device. So colour is not cost effective.

--snip--

That works fantastically, since the body movements soon become a reflex, giving fast efficient input. Perhaps in future eye movements will be used. But OP is considering present hardware, just freed from commercially derived mental constraints.

We aren't talking about what's "catching". We know that currently the herd is following Micro$hit. I've used M$ and currently linux which has better inet connectivety than my prefered OS, but the herd hasn't used [to be qualified to evaluate and reject] my less conventional prefered OS.

Yes Braille confirms it, but less so than the abacus.

A key element of bra> Which humans do i NEED to communicate

Well we are mutually communicating now ?

--snip--

If you are writing 'fragments': sequences of asm-instructions; they must be based on a higher-level model/concept. Eg. the standard forth primitives were based on [or evolved from] a stack-machine model.

Similarly the [some 68] p-code instructions which I ported as minimalist Pascal to several MCUs, was based on the P-code, stack machine.

I suppose you CAN just start, without a higher model/plan to code in hex/asm, and hope to be able to later factor the code into primitives; which can be forth-like-threaded as it evolves ?

I too had to start with a hex-programmer in the 70's, before an assembler was available.

Now I want to go to the other extreme: no selecting keys to type near English notes to the-little-man-in-the-box. Just selecting 'constructs' from a syntax directed menu. Of couse the Luddite herd, who are always just following this month's flavour, say it can't be done.

== Chris Glur.

Reply to
news

And Forth is an appealing language for defining the language that is used to define new entries in the menu. Indeed, if the language used to define new entries is well designed, there could easily be no need to type notes to the little-man-in-the-box at all ... the system can generate and store those notes, and the only time it becomes necessary to look at the contents of the notes is when the system is not behaving as desired.

Reply to
Bruce McFarling

Having trouble seeing the tongue for the cheek? ;)

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

No, no, no. Hex is not the optimum. Historically proven is that people tend to use a decimal system or something on base 12 or 20. Base 20 is my favourite btw....

What for the messures of a minimum would you like to have in your hands? We dont talk about what Werty was able to buy in his prefered hardware shop ;)

That result of research is not really usable in a brain-storming. I would like to see research results too - since otherwise we'll always have to reinvent the wheel. That would not be that cost efficient as needed. So you should not make another limitation to what is good inside a "brain-storming" ;)

In my first computer there was a BASIC and I wrote a FORTH based on it (or better: based on parts of it) ;) This was comfortable these days.

-Helmar

Reply to
helmwo

Chris Glur.

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

No i will do it different .

I will bypass the assembler . I will not write a

"one for one" Prim' to OopCode assembler ,

I will start by creating Primatives that are not one

for one with Op Codes .

This quickly tunnels the need to learn / memorize the

unintuitive gotchas of the Op Codes .

Notice Forth HAS a built in assembler , which

is merely bait .

I wont do the bait , i will give the Primatives , that

are very intuitive and powerful .

It will be a competition to see who can improve these Primatives ... ----------------------------

Building a state machine can show the methods

of modern Forth .

Clever S'M' 's have 3 , low cost SRAMs .

The first has the Primatives , the 2nd has the

Jump tables , the 3rd has the

higher level Jump Tables .

3rd SRAM can address the top address lines of the 2nd SRAM , but 2nd SRAM has a counter driving 2nd SRAMs lowest address lines .

And same for the 2nd to the 1st SRAM .

1st SRAM is "started" or jumped to a place then 1st SRAMs "asyncronous" , built in Address registers "burst" 4 OpCodes . Address register is merely a up counter , that counts to 4 , wraps around , then waits for the next address from the 2nd SRAM . When 2nd SRAM finishes one of its jump table ,

, its time for the 3rd SRAM .

Its the way Forth executes ...

Dont worry about conditional branches yet .

Attach this SM to a tiny mcu , and let it boot

the mcu .

You can learn ARM opcodes and how they work together , without cracking a book .

But you will NOT be able to explain what you learned. Because as you learn the Op Codes , you will not want to waste time , passing this to the Left Cerebral cortex for translation , into English . It will go directly into the Right C'C' .

Reply to
werty

Chris Glur.

Where do you buy your acid?

Reply to
Larry Elmore

I dont think one can create on meds nor

drugs , because its not accidental imagination

its hard work , mental control of what is

imagined .

I have 40 years of programming computers

and i hate asides . If it is not simple and

straight forward , needs no Doc's ( sorry Elizabeth)

then i have no place for it .

All the s/w you see , study /disassemble today

is an aside , everything .

The fastest way is to do it yourself , with min'

hardware that expands to megabytes of RAM .

Then Apps like ____.JPG and __.MP3

will NOT be studied nor copied .

There is a much faster way , than goin to

college and studing computer science .

Reply to
werty

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.