Ive mentioned "Perception IME" and tried to Explain this before,

I am simply trying again... hopefully without confusing everyone in the process...

first a little background, with many languages being spoken around the world, there is also many ways to write ideas,

each of these ways are picture based in some way...

the question is then ... how many pictures?

in English this is somewhat limited, 26 letters, 10 numbers and various symbols with specific meanings.

I will choose Japanese as an example language to compare,

the majority of keyboards are "qwerty" or "azerty" based,
with some being Dvorak or another Keymap.

Generally with 1 symbol per key or a modified meaning when
used with the Control / Alt / Shift or Command keys.

in Japanese there are 50 based sounds,
and you have 2 sound based symbol groups to type this,

But there is a major catch to this... both symbol sets use
the *same* english forms.

there is a further complication as well,
a third set of symbols.

these three sets of symbols are known as "Hiragana" "Katakana" and "Kanji".

The Hiragana and Katakana symbols are the easiest to type
and are generally widespread for use to enter material.

The challenge for entering Japanese is to do with selecting Kanji

While it IS possible to keymap for Hiragana or Katakana to be usable on a keyboard each, you can't create a Keymap for both Hiragana AND Katakana successfully as each symbol in
these two sets uses between one to three english characters
for a basic sound meaning.

Examples are A I U E O becoming あいうえお or アイウエオ,

and かが　さざ　ただ　な　はばぱ　ま　や　ら　わ　ん
kaga saza tada na habapa ma ya ra wa n

okay... skipping any further details ... we also have Kanji

Now this is where things get interesting...

Kanji don't work on a "single press for a single Kanji" entry rule.

Hell... you can't simply say a single word in japanese without context.

I'll use the word "Kanji" iself as a prime example of this.

there are 14 pair of Kanji options in the menu when triggering the Windows IME
after typing "kanji" without the Hiragana or Katakana written forms.

[edit]so the whole point of my trying to explain this is to find out who else wants this kind of support being available?

If anyone who know of other than Japanese needing such functions being added properly to the OS?

I also plan on making this an open to all project once the initial main library is
built and accessible from two or more language packs.

I will be adding a "nihongo.language" library for locale support and I will additionally
be adding the IME commodity support through the way locale.library and its preferences get applied.

I'm still in the middle of sorting out a proper development machine and I've already started making a list of beta testers,
and I would be more than appreciative of any messages in this thread towards support or interest in testing.

I will not ask for anything more than a listing of files and their versions installed from what I package.
followed up by a description of actions triggering any particular error.

Thank you also in advance to everyone who has shown support already as well

What "codecs" are used for the two movie files?,
does mplayer recognise the packets in the datastream
while DVplayer does not?

Can you expand further with information about the content of the two movie files themselves regardless of the content?

Theora Video with Vorbis Audio encoded within an OGM file?

Mpeg4 Video with Mpeg3 Audio in AVI or MKV ?

Dolby or DTS 5.1 channel Audio? Stereo Audio ?

What is the video size?

PAL/NTSC bitrates for digital playback?

Do you know any of what I am asking?

@kilaueabart

はい、少し日本語分かります。
前に日本の鳥取県鳥取市すんでましたでも。。。
その時間あいだに結婚しあります、その結婚は今止まった。

Yes, I understand a little bit of the Japanese Language.
Before I lived in Tottori City, Tottori Prefecture, Japan

During that time I was married but that is now ended.

[edit]
as for my use of Japanese... I was CamelCasing based on
Word / Particle and Modifier points...

Ni for に and De for で along with
~Shitai for ～したい as examples...

[/edit]

@nbache

That is correct, dead-keys are immediate pre-processing
for the next key only and exit change of state after the
subsequent entry...

@all

I can not however deal with dead-keys for Hiragana, Katakana
and Kanji input over and above normal English input.

as any "Japanese Windows" or Linux system is fully capable
of multiple language input which is the proper target
for the Perception IME.

Basically *any* input will be handled with Perception IME
being the layer inserted for language specific rules.

the "default" rules will be "raw" or English input with the
existing "deadkey" triggers for umlauts and similar input.

However for Arabic/Japanese/Chinese and other languages that
need an extended set of rules to be input properly...

That is where Perception IME will make itself available with
a common perception.library which the normal language libs
that are the "nihongo.language" and "mandarim.language"
libraries (these are coded, not data based) will insert
the IME into the normal Intuition level processing.

I will be using the list of locale "Preferred Languages" to
decide which IME modules will be immediately accessible
from the controlling commodity and perception.library


Beyond that any IME preferences will be "per-language"
and I have not decided where to store them yet.

I will not be adding them as a general Preferences Editor.
as they will only be limited to the controlling CX tool.

The "nihongo.language"(Japanese) library will only bind
to the Perception IME library when it is present
along with launching the CX tool also being optional.

the following rules of behaviour will apply...

"default English Input layout", Recognition of the 4 added
Japanese only jp106 keys.

there will be a toggle between English and Japanese modes,
with the "Japanese" state being further expanded for
Hiragana / Katakana / Double-Wide-English / Kanji-Menu

Each Hiragana is 1-3 Letters to type, Katakana is another
symbol set repeating the same input options.
Double-Wide is a UTF8 encoding option for 16bit/symbol
input and Kanji mode can have an indefinite depth tree
for selecting what Kanji are "typed" based on a whole
string selection process.

typing "kanji" on any other Japanese IME will give the
following options...
Hiragana=かんじ
Katakana=カンジ
Kanji= 1:漢字 2:莞爾 3:完治 4:寛治　5:感じ 6:...

Using the exact same data entry of [kanji] followed by
pressing space twice with a number or enter key to select
from the displayed menu of choices
(the Windows IME gave 14 built-in dictionary options)

so a definite example that simple dead-keys will not suffice
to handle this kind of input (do you want to enter triple
dead-key combos to select each character in the word then
needing to know a triple dead-key number entry to select
which variation with a possibility of getting it wrong?)

Trying to input IME level material using dead-keys only
would be like trying to drive a car or a semi-trailer rig
after the medical removal of the drivers eyes and no
prior training...

the Perception IME will have to fill this glaring gap
and I am considering how to handle other options as well.

@nbache

> That sounds like an interesting project indeed!

I have several open-source projects to work from which helps

> So you basically need to make individual keys do different
> things based on the context and/or mode you're currently > in, partly based on keys having been used beforehand (or > even afterwards )? Sort of like what is already being done
> with dead/deadable keys, except much more complicated and > using many more of the available keys?

not just individual keys but "string" based.
AIUEO K/G* S/Z* T/D N H/B/P* M* R Y W ordering instead of
Aa-Zz ordering for a start...

Not only single-deadable keys but double / triple and
for specific Chinese Entry examples...
there ARE currently full 8 key entry combinations
for selection of which list of symbols prior to triggering
display of the list to select...

so the "dead key" system on AmigaOS would not cope as
it would at best only handle double or triple combinations

there is a minimum of 3 keys for selecting singular Kanji
or Chinese Pictographs...for the most basic of entries.

> Obviously the existing keymaps and the system support for > them cannot handle this.

Seriously, this is *way* past dead-keys as I require
to have a typed string typed normally before triggeriing
any of the "string conversion" options using space or enter
which will then popup a menu listing of Kanji

state will be held along with Japanese 106 Keymap recognition
of the extra "Japanese only" keys on my own jp106 keyboard

These are not marked in English at all and have fixed functions.

Japanese also has like Chinese the attribute of being a
seperate written and spoken language...
each (written/spoken) is literally its own language
with translation skills required.

Certain words are used written but never spoken,
and there are the spoken words that are never written.

and for each Kanji you can have from 1 through to 5 different spoken words based on context.

> Hopefully you will be able to build on some of the basics > of the keyboard handling system (one end) and the input
> system (other end) , though, to make an extension which
> will plug in nicely. It might be something to include in
> the OS on a longer term.

I'm planning for this entire "extension" to the OS to be
added in a simple manner and make use of the existing options
that are already part of the OS itself where possible
just to apply the KISS rule.

so any inclusion later for the OS itself, will remain "optional".

SSolie and the rest of the OS developers only need to work
with me for the sum total of a documented mechanism for
Perception to slot into the rest of the OS with.

Beyond that there will be no requirement other than the existing standard locale.library and intuition.library API Interfaces to remain unchanged long-term.

I will be making Perception itself open-source once I can work out an acceptable license so that it can be a "3rd-party" addon option.

I *will* actively support and accept submissions and deal with this myself.

I will not burden the AOS4.x team with supporting it at all
I am more than willing to work entirely on my own as needed.

I just hope some users will support the additional addons
after buying the OS and working out which they need.

> Best regards,

> Niels

@kilaueabart

英語のケーボードはむずかしにはいちゃたないでしょうね

huh?

英語 = Eigo = "English" as said in Japanese,
日本語 = Nihongo = "Japanese Language" in the Japanese Language

the 語 Kanji literally means language...
the 英 Kanji has an imprecise reference to English from the UK

日本 is the Kanji name for Japan itself
( nihon & nippon are both valid for this Kanji pair)

English~Keyboard Difficulties~Data Entry~Wanted~You agree?
inexact but approximate word replacement without meaning.

Japanese and English don't literally mean the same thing due
to major structural differences...

English has a LOT more structure than Japanese,
mostly to do with "verb ending" and particles as
modifiers to what is said.

@all

and yes, I will co-ordinate with ssolie once I finally get
to writing this into an AOS4.x system of my own.

Ive also got a couple of other projects lined up as well,
which includes building a "developer cluster" for making
an accessible network system for developers that don't have
access to AmigaOS 4.x equipment for themselves.

but the "Perception IME" will be slotting into the existing
locale.library setup adding another library which will
remain optional.

I'm not going to force anyone to need the full installation
but when the additional library is present,
it will be *fully* functional.

@Chris - Yeah I got that Email, but the machine setup I am using decided to develop an allergy to any factory spec CPU capability ...
any usage above 80% factory spec of 2.5GHz and it switches itself off

@LiveForIt - I am not talking about Display,

@ChrisH + LiveForIt - Japanese and Chinese Input is not just a matter of a simple keymap
(there are over 350,000 Unique Kanji for Japanese alone...
I have seen an official dictionary, think of 2:1KG bags
of sugar, side by side as a book, it is a bit larger)

so combinations of
"a ka/ga sa/za ta/da na ha/ba/pa ma ra ya wa" is just the first of 5 rows... this won't fit a standard keyboard,

there are no less than 45 distinct Hiragana characters,
of which there are 3 modifiers,

In addition to this THE ENGLISH KEYBOARD REMAINS UNMODIFIED at the keymap for provision of the standard A-Z/a-z and symbols mappings...

so please don't assume that a keymap will solve the issue
it won't... that is why I am making the Perception IME to
deal with such things for languages unable to be supported
by keymaps alone.

I *will* be making a modified US Latin1 layout for use with
jp106 layout Keyboards (such as the one I used typing this)

Apologies if this seems offensive, but "bullet.library"
and "keymaps" are only small pieces of what I need to do.

Look at Windows or Linux or Mac OS for a "Language Bar" or
UIM/SCIM/IM-JA/...

this kind of tool is what I am working on for a complete
handler of any "Keyboard" device being attached to AOS4
and later on AROS as well.

//UTF8-NEW//Japanese//
「日本語はちょっと違うでしょう、でもねこの漢字はもちろんむずかしくないね。ごめんなさいでもこの漢字は英語のケーボードはむずかしにはいちゃたないでしょうね」//UTF8-END//
//Romaji-NEW//
NihonGoHaChottoChigauDeshou, DeMoNeKonoKanjiHaMochironMuzukashiKunaiNe.GomennasaiDeMoKonoKanjiHaEigoNoKeeBoodoHaMuzukashiNiHaiChattaNaiDeShouNe
//Romaji-END//

There is "Kanji" as Feelings or "Kanji" as Characters...
which do I mean? the only way to know is which character
and the normal limitations of a keyboard do not suffice
therefore use of the spacebar and enter/return keys are
changed when the IME is in Japanese/Chinese modes...
there is additionally "double-entry" modifiers as well.

use of the "-" symbol can mean "1" or "ichi" *OR* it can
mean the extension of the vowel[aiueo//Japanese Order]
following it.

Japanese selects 1 or 2 consonants of english with a vowel
or the vowels without.
with the option of... a- being an aa sound...
with the option of double-typing the first consonant
introducing either a doubling or other sound modifier.

Chinese also introduces 4 "tones" in addition with between
1 letter + tone, through to 7 letters + tone for selecting
any *single* Pictograph.

Please note... the Japanese I entered is spaceless and is reliant entirely on the reader being able to parse the correct Kanji.

so "Checkout the bullet API" is barking entirely up the
wrong tree... as display is already done

I am talking about *INPUT* which is entirely seperate from "Display"...

grrr...

Can anyone interested in a full UTF8 only Input option for AmigaOS4.x please send me a list of all the current European language key-combinations for umlauts and other extended character marks please?

I'm going to be putting together a Universal Input Method Editor for AmigaOS4 and AROS

I was originally intending this for adding only Japanese to start with...but I may as well handle the basic "special case" characters

try an Ethernet "MTU" size of 1088...

I used to use an MTU size of 576 and 1088 between
MiamiDx on AmigaOS3.9BB2 and Linux and had a throughput
from Samba on the A4000 serving over 10Mbit Ethernet
of 100KBytes/second transfer rates...

Literally fast enough to watch video stored on the Amiga
from the Linux machine (I was also viewing from windows)

but if you really want to tweak for speed then you need to
consider ALL the devices on the network concerned
and what timings they all have.

I'm also in Christchurch, not so far away :)

@ChrisH - only badly coded drivers would use signed pointer math on the 680x0 systems,
PPC based OS versions I don't yet know enough details to say anything...

@everyone...(@TonyW - exec.library AutoDoc AllocMem variation for multiple Allocations in a List)

see the exec.library AutoDocument for "AllocMem()" variants...

There is a **SINGLE** Memory Allocation libcall in exec.library blocking use of addresses above 2GB,
and this specific exec.library/_LVOAllocMemPooled()??? call documents the 2GB boundary as exclusively introduced
by this library call...

All Classic Kickstart drivers *DO*NOT*CARE* as long as the CPU can validly read and write the block of memory
within the standard 680x0 4GB of Addressable memory.

Any *3rd*Party* drivers such as diskimage.device, fmsdisk.device, gvpscsi.device oktagon.device,
as compiled by Lattice C or SAS C&C++ or the GCC compilers will not currently be using any kind of signed pointer math
produced from the compilers without an explicit declaration of signed pointer testing directly in the sources.

so ChrisH's comment about drivers would more apply to any additional drivers not provided as part of AOS2.x/AOS3.x releases.

There is ****NOTHING**** else stopping full usage of 4GB in the software at this time I am aware of...
THIS IS FULLY DOCUMENTED IN THE THIRD EDITION ROM KERNEL REFERENCE MANUALS.

However you do have to realize... the original Classic
AmigaOS is written on a processor where IO devices use
64KB blocks of memory as a minimum AutoConfigure block size

Additionally the memory map has the following...

2MB ChipRAM
8MB FastRAM (ZorroII?)
5MB Motherboard & Zorro2 IO space (ECS and AGA / CIA / IDE or SCSI functions)
1MB ROM Space (512KB Cartridge, 512KB Kickstart)

AutoConfig Occurs at a fixed Address below the 2GB watermark,

if you physically map 4GB of memory... without "holes" for the IO device spaces on the 680x0 series processors,
I understand from the 68000/68010/68020/68030/68040 and 68060 Manuals that this will trigger
"double bus fault" conditions... only ONE type of device can respond at any given memory location.

Double-Bus faults are a *lockup* condition so any type of device IO would halt the processor with only one interrupt
allowing a response (Interrupt 7, all interrupt lines set), this is the NMI or Non-Maskable.

These are the only two things blocking usage of memory...
if anyone wants to install 3x ZorRAM 512MB cards into any A3000 or A4000 Amiga they can quite happily use the entire
1.5GB of FastRAM on all three cards in addition to any other expansions present...

The total sum of memory installable on AmigaOS 3.9 and older is ~1.95GB (allowing for the IO device space holes),
however... THIS INCLUDES THE MEMORY FOR A GRAPHICS CARD AS WELL...

I have no experience or current knowledge of the PPC systems available... but I will definitely be exploring options
once I get my hands on a sam440flex followed by a sam460ex...

if anyone wants any further clarification on any of this information they can lookup the exec AutoDoc for
the Alloc*() routines and additionally the Memory Map as described in the various Hardware reference books...

AutoConfig itself *does*not*limit* memory to 2GB... it will actually quite happilly map a 2GB Memory board *STARTING*
at the 2GB boundary for use as Memory (but it may not be pool allocated)...

The AmigaOS exec itself is not limited to generating addresses above 2GB without a device being AutoConfigured above that
soft boundary...

But you had better be prepared for the condition of a false failure within the Allocator when it returns memory that IS
bit 31 set tested (this is the Soft Error condition for a multiple Allocation with a single libcall to exec.library)

To my knowledge there is only the hardware limitation for certain memory regions below 2GB that are mapped to IO not memory
so can anyone force a fixed Memory device to be added to exec through Adding the Memory concerned directly to the
Memory lists for testing purposes?

I'm more than happy to try hacking this into any of the big-box Amiga systems where this is possible...

Hell... anyone got a Zorro card which would allow wire-wrapping for experimentation? I'm game to try it...
only Classic systems with Zorro3 capabilities would be able to support such an experiment to my knowledge.

There is also a documentation reference with regards the 68000 TAS(Test-And-Set) Read-Modify-Write cycling of access to memory
being actively broken by the Amiga chipset (the chipset itself would need modification to support SMP for this approach)

so any kind of SMP option with 680x0 Classic Amigas would require use of the 68020+ "Co Processor Protocol" as documented
in the Motorola-SPS / Freescale 680x0 Documentation (more fully explained in the 68040 and 68060 User Manuals).

This would allow an FPGA that is setup as a custom Co-Processor (same protocol as the FPU and MMU chips but a different ID)
to actively respond or modify bus arbitration between processors... including HALT and Interrupt handling.

not a small project in itself but does require that the SMP co-processor isolates the CPUs from all other bus master capable
devices for both BIU and Interrupt Handling logic, possibly having its own limited register set for such things.

The Motorola Co-Processor protocol is 16bits per transfer and can deal with a 16bits per Word "discussion" with the limits
of 2 words for the instruction, and 128 words for immedate data operations.

I would need to read the PPC documents for the appropriate chips to find an equal solution there.

How about re-use of an existing script based package manager with the features required?

Would I be able to buy and use an 8GB or 16GB SDHC card
and use that for an initial OS bootstrap device?

Curious as to what limitations it has

(EDIT: Additional material below)

@nbache
Initial usage for use as a primary system, later being
only for bootstrap, I will need room for Development work.

I am considering having both AmigaOS + Linux Installed.

I would be looking towards porting a distribution of Linux
that I am already familiar with called SourceMage

@sinan
I was discussing an SD card and not SSD device for use,
Do you know the difference?

Why ever are you using SetSignal() at all?

I'll have to dig out some very overloaded signal handling
and show that to you from a partial network stack I wrote.

this might help you with making MUI and other things work
nicely.

o tanjyobi omedetou gozaimasu
Happy Birthday in Japanese too

Samurai_Crow: I'll be more than happy to work with you in building this up with a framework around it as I have in mind to do something similar for CPU level operations...

so if you want to do the Graphical Chipset, I can work on handling the non-graphical chipset operations and splitting them out.

I will definitely be putting my own Radeon HD5450 through its paces to test anything if you want any direct coding help as well.

Would multiple cards provide extra units?

regardless of PCI or PCI-Express bus usage?

and to my knowledge the PCI Express Bus complex shows
as an extended form of PCI,

I'm definitely going to test this theory by getting
more than one sam and the appropriate cards :)

Okay...then I will want to find a 4port SATA card,
no point in my buying a sam440 or sam460 and not being
able to use more than 4 ports without it being 2 chips


Then this controller would be more the type of thing I am
after for a sam460... but I would like to find the PCI
equivalent even if 4 ports internal
Ascent Technology Ltd NZ

is there no way to use a card with 6 SATA ports in addition
to the sam440ep onboard 4 ports of SATA?

optionally using such a card for SATA on a sam460?

Would the U-Boot firmware require to boot off only
one of the first 4 ports found?

Would the extra two ports simply remain missing?

I would simply like to have this clear before I finish
purchasing a sam440 or sam460

as I have the option to run a full set of SATA devices
filling the onboard port set of a sam440 or using
this card and also add an optical drive or two.

I just want to be clear whether such a card is worth the
purchase for use with any of the samantha boards

--EDIT--
The Url as requested...
Ascent Tech Ltd NZ

Mostly hacker materials...for myself or others
(not illegally cracking into others systems)

some testing and some quick coding,
mostly in AmigaE / C / Assembler.

I did one submission for an FFT routine in Lame but it was
later revised and updated to a quicker routine.
That submission was in 680x0 Assembler.

Other submissions have mostly been technical discussions
and otherwise assisting others however I have been able.

I'm more specifically interested in being able to do for the community any small task at this point.

Ive already got a couple of ambitious projects I want to
complete on AmigaOS4.x at least for myself but to expand
the options the Amiga community has where I can.

so anything where I can earn small amounts towards a sam460
would be very appreciated at this point

@Elwood
@nubechecorre

afaik "Mesa" is an Implimentation of the "OpenGL" specification,

OpenGL being full definition,
MiniGL being minimal function definition,

Mesa and Drivers being implimentation...

Rogue and Hans please correct me if I am wrong