Source : habin96@hanmail.net
다른 곳으로 배포할 경우 출처를 밝혀주시기 바랍니다..^^

 

GoldWave 프로그램을 통해 벨소리 만들기(초보자용)

1. GoldWave 실행

GoldWave 프로그램을 실행하며 아래와 같은 화면이 나옵니다..

Array

2. 파일열기

벨소리를 만들고자하는 파일(mp3,wav 등)을 open합니다.

Array

3. 벨소리 만들 곳 선택

파장이 있는 화면 양쪽을 마우스로 선택하면 드래드할 수 있는 화살표로 변경됩니다.
아래쪽에 보이는 Control 창의 이 있는데요 Array   이 부분을 통해 재생을 하면서 파장이 있는 화면에서 벨소리로 만들 곳을 선택합니다.

☞ 주의사항!!
대부분의 핸드폰의 경우 용량패치했을 경우, 50KB가 최대입니다. 원음벨의 경우 샘플링속도를 8000Hz로 했을 경우 13초이내이고, 4000Hz로 했을 경우 20초정도 됩니다.
벨소리 구간을 무리하게 길게 할 경우 용량초과로 핸드폰 전송이 안될 수 있으니 주의하세요..^^

Array

원하는 구간을 다 선택하셨으면..메뉴바에서 File->Save Selection As를 선택하여 선택한 구간을 다른 파일로 저장합니다.

파일형식->wave, attribute->PCM signed 16bit mono

Array

4. 새로 저장된 파일 열기

Wave 파일로 앞에서 저장했던 파일을 다시 Open합니다.

Array

5. 샘플링 속도 변경하기

메뉴바에서 Effect->Resample 메뉴 클릭

Array

6. 샘플링 속도 변경(441000Hz->8000Hz)

샘플링 속도를 아래 그림과 같이 변경우 “OK” 단추 클릭 후 File 메뉴에서 Save 선택하여 파일을 저장.

Array

7. wav 파일을 벨소리로 변경하기 위해 WSC-MA2 프로그램 실행

wav 파일을 마우스로 선택하여 WSC-MA2 프로그램으로 끌어 놓으면 변환

Array

8. WSC-MA2 변환단계

Array Array
8KHz로 할경우 벨소리 시간은 짧지만 음질은 좋고, 4KHz로 할경우 벨소리 시간은 길어지지만 음질은 안좋아짐.
선택사항.. 체크하면 4KHz 체크안하면 8KHz

9. 벨소리 변환 성공

벨소리가 정상적으로 변환되면 아래와 같은 화면이 나옵니다…^^
변환성공후 File Size가 50KB이상이 나오셨다면 전송이 안되거나, 전송되어도 핸드폰에서 인식이 안될 수 있습니다.

Array

10. 파일 확장자 변경

WSC-MA2로 벨소리 변환을 하면 파일 확장자가 mmf로 생성됩니다.

이 파일 확장자를 ADS-Loader가 인식할 수 있는 ma2로 변경하시면 됩니다.

Array  Array Array

11. 변환시 자주 발생하는 에러

Array

WSC-MA2에서 파일을 변경할 경우 가끔 그림과 같은 메시지가 나오는 경우가 있습니다. 이 메시지는 Wave파일이 규격에 맞지 않았을 경우 발생합니다. Wave 파일등록정보를 보시면 아래 그림처럼 샘플링 속도를 확인 할 수 있습니다.

정상적인 경우

Array

비정상적인 경우로 에러 메시지가 발생됨.

Array

☞ 위에 4번 항목부터 다시 시작하여 샘플링 속도를 8000Hz(8KHz)로 변경하세요..^^

위에 설명한 프로그램은 아래 사이트 게시판에 올려 놓았습니다..^^

[ADS User Community] http://zservice.nayana.to/anycallads/home.php
[Daum Caf? 나만의 ma2,ma3] http://cafe.daum.net/ma2bell

'장난치기' 카테고리의 다른 글

닭강정  (0) 2008.07.01
속청(Speed Listening)  (0) 2008.06.27
GoldWave를 통해 벨소리 만들기  (0) 2008.06.26
G메일의 새로운 기능 실험 - Gmail Labs  (0) 2008.06.15
성공적인 CRM을 위한 레시피  (0) 2008.06.11
마카로니샐러드  (0) 2008.06.08

Source : http://www.parkoz.com/zboard/view.php?id=my_tips&no=11647

 

Array
Image size : 640 x 480, Monday June 09, 2008 04:57:20 am, Uploaded by 이천일

지름신에 너무 충실하여 항상 돈에 허덕여서 곤란한 파코즌 이천일입니다.

요즘 나름 쿨링질 해보겠다면서 이래저래 놀다가 케이블타이질에 완전 맛들려버렸습니다.

그렇게 맛들려서 놀다가 색다른?! (이미 알고 있을지도 모르는 ㅠ) 케이블타이를 이용하는 방법을

연구 아닌 연구를 하게 되었네요.

비록 별거 아닌 내용일지 모르겠지만

한분이라도 도움이 되었으면 하는 마음에서 올립니다^^

그럼 내용이 매우~ 길기 때문에 어여 본론으로 들어가도록 하겠습니다.

1. 케이블타이?

Array

케이블타이라면 여러 종류가 있겠습니다. 또한 여러 회사, 여러 스타일의 케이블타이, 여러 길이 등등...

정말 가짓수를 셀 수 없이 많은 종류를 갖고 있지만,

일반적으로 파코즌이 많이 쓸거라 생각되는 녀석들을 가져와봤습니다.

(랄까 제가 갖고 있는 것들은 이게 전부입니다 ㅠ)

검은색의 케이블타이는 100mm짜리 아주 표준적인 케이블타이입니다.

그 앞의 것은 네임펜 같은 것으로 표기할 수 있도록 되어있는 역시나 표준적 케이블타이입니다.

그 앞의 것은 케이블타이는 아니지만, 기존의 찍찍이 타입 줄감개의 단점인 두께에 따라

너무 얇거나 너무 두꺼울 경우 고정이 제대로 안되던 점을 보안한 뉴타입의 찍찍이입니다.

이 중 다뤄볼 것은 제일 뒤의 아주 표준적인 케이블타이를 가지고 이야기를 해볼까 합니다.
Array

너무나 자주 보던 얼굴이라 궂이 볼 필요 없다고 생각될지 모르겠지만

은근히 쓰임새가 많은 녀석인지라

제 개인적으로는 케이블타이 '공'이라고 부릅니다.

(귀족취급정도 해도 아깝지 않다는...)

이 자가 없으면 선정리가 안된다는 ^^

일반적으로 50묶음단위나 100묶음 단위보다 1000묶음 단위가 비교적 가격대비 양이 상당합니다.

은근히 많이 쓰는 녀석이므로 몇천원 투자해서 1000묶음짜리 하나 사두는 것도 좋지 않을까 싶습니다.
Array

한번 묶으면 다시 풀 수 없다는... 두려움의 존재입니다 ^^

비상시 수갑 대용으로도 가능하다는 이야기를 들었으니...

하지만 철사같은 것이 있으면 묶인 것도 풀 수 있습니다.

케이블타이가 없어서 급박한 나머지 그렇게 해서 재사용한 적이 있기에...
Array

케이블타이와 단짝친구인 니퍼입니다.

일반적인 형태의 니퍼는 아니고 좀 정밀하게 작업하기 위한 니퍼로 새로 구했습니다.

정말 잘 잘리기 때문에 케이블타이와 한 세트로 제격인 것 같습니다.
Array

끝이 얇팍하기 때문에 케이스 내에서 케이블타이질을 할 경우 마무리하기 비교적 쉬우며

나중에 케이블타이를 다시 끊을 때에도 편합니다.
Array

제가 왼손잡이이기 때문에 대략 저렇게 잡습니다.

중간에 검지를 넣어 힘조절을 도우는 것에 습관이 되다 보니...
Array

기존에 쓰던 니퍼입니다.

강한것을 자르기에는 이것이 좋습니다만(철판이라던지 =ㅅ=)

무뎌져서 그런지 도저히 케이블타이가 끊어지지않아

너무나도 힘들게 했었지요.

여튼 도구에 대한 이야기는 이쯤 하고

위의 좀 얇팍한 녀석과 표준 케이블타이를 가지고 시작을 하도록 하겠습니다.

2. 케이블타이를 파헤친다.
Array

이거 찍기 정말 힘들었습니다 -ㅅ-

손으로 들고 찍은 것이라

한손으로 들고 한손으로는 매뉴얼포커스 잡고서 찍으려니

수전증과 빛이 비추어야 홈이 보이고...

여튼 정말 힘들었습니다 ㅠ

여튼 이 홈을 보면 케이블 자체를 왼쪽으로 밀어야 쉽게 들어가지고

반대로 오른쪽으로 밀면 걸리도록 되어있는

한방향 걸림쇠 방식입니다.
Array

그래서 보통 일반적으로 케이블타이 머리부분을 저렇게 끼우고 선을 쭈욱 당기지요.
Array

그러면 이런식으로 묶이게 됩니다.

하지만 여기서 확인해야 할 점은

이렇게 묶었을 경우 정확한 원도 아니고, 그렇다고 각져있는 형태도 아닌

물방울의 형태로 되기 때문에

케이블 자체를 고정하기에는 좋을 지 모르겠지만

쿨러라던지 하드 공중부양이라던지

상황에 따라서는 이러한 모양이 해가 되는 경우가 많습니다.
Array

그래서 그러한 부분을 해결하기 위해

케이블타이 1개가 아닌 2개 이상으로 해결을 봅니다.

현재는 2개를 연결한 모습입니다.

케이블타이가 2개 이상이여도 케이블머리와 걸림쇠만 조심한다면

역시나 같은 원리로 케이블타이는 사용할 수 있습니다.

특히 케이블타이를 2개 이상 연결시에는 끼운 케이블타이가 원래의 케이블타이의

머리쪽으로 이동하게 된다는 점을 명심해두는 편이 좋습니다.
Array

이것은 2개를 연결한 방법입니다.

이러한 방법은 주로 얇은형태의 것을 묶을 때 이용합니다.

IDE케이블이라던지

ODD 홈과 기타의 것을 묶어볼 때에 이용하곤 합니다.

1개로 묶었을 때보다 얇아지고 양쪽 모두 각이 지는 점을 이용하는 방법입니다.
Array

일반적으로 사이에 묶을 것을 중심으로 헐겁게 연결해준 후

마지막으로 양쪽을 잡아당기고 위아래로 좀 더 당겨줌으로서

(사진상에서의 위 아래. 위아래와 옆으로 당기는걸 겸하면 튼튼히 고정할 수 있습니다)

꽉 조여줄 수 있습니다. 
Array

이것은 4개를 이용하는 방법입니다.

케이블타이가 아깝다고 생각이 들 수도 있는 부분이겠지만

사각형 모양으로 고정해야할 경우나 쿨러고정시에는 매우 유용합니다.

밑의 사진에서 그 부분을 다룰 것입니다.
Array

역시나 2개짜리 연결방법처럼

잡아당기면서 위아래로 좀 더 당겨서

튼튼하게 고정합니다.
Array

2개 이상이기 때문에 만약 잘못 묶게 되면 2개 다 버려야 하는 상황이 오곤 합니다.

하지만 그렇지 않고 살릴 수도 있지요.

물론 꽉 묶어버린 상황에서는 거의 불가능하지만

중간에 깨달은 경우에는 구해낼 확률이 높습니다 ^^

위의 사진에서는 ㅡ자의 경우에는 살리기가 거의 힘든 상황이지만, ㅣ자의 경우에는 충분히 살릴 수 있습니다.

하지만 저렇게 자르게 되면...

ㅣ자의 이동방향이 왼쪽이기 때문에 탈출하지 못하지요.
Array

바로 이렇게 됩니다.

잘못 자른 것입니다.
Array

반대로 이쪽으로 자르게 되면(ㅡ자의 머릿쪽에 해당하는 부근)

ㅣ자가 왼쪽으로 이동가능하여 곧 탈출하겠지요.

만일 짧더라도 ㅡ자도 재사용하고 싶다면

최대한 ㅣ자에 붙여서 자르면 ㅡ자도 길이에 따라서는 충분히 사용가능하지요.
Array

이렇게 자르게 되면
Array

결국 이렇게 탈출 가능하게 됩니다.

적어도 한개는 살리는 것이지요.
Array

4개짜리의 경우에는 좀 암울합니다.

4개 다 버리기 참 아깝지요.

하지만 위의 화살표 방향대로 자르게 된다면

각각의 머리들이 왼쪽으로 이동가능하니

곧 탈출하겠습니다.
Array

비록 많이 짧아졌지만

때에 따라서는 사용도 가능하겠지요.

3. 각각의 케이블타이법에 따른 사용처
Array

일반적인 한개를 이용하는 방법입니다.

전원선이나 SATA선 등에 많이 쓰이게 됩니다.

특히 둥그런 모양으로 묶이게 될 경우 많이 쓰이게 되지요.

케이스에 얇은 선을 묶어줄 때에도 간혹 사용하곤 합니다.

(케이스에 나사구멍이 2개 이상이라면 그 부분을 통과시켜 케이블을 묶어줄 수 있지요)
Array

이런식으로 얇은 선이라도 간단하게 묶어줄 수 있지요.
Array

하지만 이런식으로 모가 나있는 형태의 경우라면 상황이 좀 달라질 수 있습니다.

살짝 하자니 선이 헐겁고

세게 하자니 모서리부분부터 고무부분을 파먹고 들어갈 가능성도 배제할 수 없게 되지요.
Array

이럴 경우 2개를 이용하여 조여주었습니다.

오히려 흉해보이는 듯 합니다만 밑을 보면 상황이 많이 다릅니다 ^^
Array

두개짜리의 경우에는 워낙 이렇게 사용하거나 하지 않아서

좀 독특해 보일 수 있겠습니다만

효과는 밑에 보면...
Array

한개짜리의 경우입니다.

더 조여줄 수도 있겠지마는

그럴 경우 모서리부터 짓눌러버리거나 파먹어버릴 가능성이 매우 큽니다.
Array

그에 반해 2개짜리의 경우에는

일단 원체 각이 양쪽으로 나있는 상황이기 때문에

생각 이상으로 별로 짓누르지 않으면서도 거의 밀착상태입니다.

일반적인 케이블의 경우에는

헐거워도 별 상관이 없어

별 큰 차이가 없을지 모르겠지만,

강하게 고정을 시켜야 할 경우에는

큰 차이를 보일 수 있는 부분을 보여주는 예라고 할 수 있겠습니다.
Array

아까 사진상으로는 2개짜리 연결시 먼저 묶어준 모습을 보여줬지만

실제로는 이렇게 한쪽만 묶고 묶을 대상에 두른 후에 헐겁게 묶고

조여주는 방식으로 사용합니다.
Array

이번에는 드디어 본격적으로 효과확인을 할 수 있는 쿨러 등장입니다.

기가바이트 메인보드에 들어있던 쿨러입니다만

사진상이라 표현이 안되지만

120mm입니다.
Array

옆면은 특이하게 기둥처리되있어서 막혀있습니다.

하지만 별로 상관이 없습니다.
Array

케이블타이가 아주 맘에 드는 부분입니다.

참 다행히 나사가 들어가는 부분에 머리만 걸립니다.

쿨러 나사는 다 같기 때문에 어떤 쿨러든 마찬가지의 결과입니다.

머리만 딱 걸리지요.

이를 최대한 이용해야만 정확한 고정이 됩니다.
Array

팬그릴을 이용하여 테스트해보겠습니다.
Array

먼저 하나짜리의 경우입니다.

깔끔하게 고정된거 같아보이지만

실제로는 이상하게만치 헐겁게 되지요.

아무리 조여도 그렇습니다.
Array

왜냐하면 케이블타이 머리부분이 나사처럼의 고정역할은 하지 못한채

단순히 기둥에 묶은 역할만 하기 때문에 대략적으로 묶였을 뿐,

정확한 고정은 하지 못합니다.
Array

옆부분은 나름 타이트하게 묶인 편이지만 머리가 붕 떠버렸기 때문에

완벽한 고정이 되지 못하는 것이지요.
Array

그래서 팬그릴을 화살표처럼 밀어보면

그냥 휙 밀려버립니다.

팬그릴이여서 별 상관없게 보일지 모르겠지만

케이스에 고정한다던지

쿨러들끼리 케이블타이로의 고정시에는

크리티컬로 작용할 수 있는 부분입니다.
Array

그를 막기 위해서 2개짜리 사용법을 활용해봅니다.

여기서 주의할 점은

위에서 케이블을 조였던 것처럼 그냥 두개 연결후 양쪽으로 당기면

1개와 똑같은 결과만 될 뿐입니다.

조일 때의 주의점이 있습니다.

Array

먼저 헐겁게 연결하는 것은 똑같습니다. 하지만...
Array

이렇게 먼저 머리부분끼리의 고정부터 합니다.

이렇게 고정하게 될 경우

케이블타이의 머리부분이 마치 볼트와 너트처럼 되며

특히나 머리부분이 나사를 위한 홈부분에 살짝 들어가게 되서 정확한 고정을 하게 됩니다.

이 부분이 중요 포인트라고 할 수 있습니다. 
Array

이런식으로 살짝 들어가게 되면서 마치 나사로 조인 것 마냥

어느정도 확실한 고정이 됩니다.

생각 이상의, 케이블타이의 고정이라고 생각되지 않을 정도입니다.
Array

그 다음 옆부분을 조여줍니다.

물론 이렇게 할 경우 옆부분은 과도하게 휘게 되서

붕 뜬 것처럼 보입니다만

어차피 저부분이 역할을 하는 것이 아니라

이미 나사를 위한 기둥 안에서 확실하게 고정이 되있기 때문에

옆부분은 없어도 상관 없을 정도입니다.
Array

이렇게 붕 뜬 것처럼 보여 큰 역할을 못해보여도
Array

실제로는 그 부분을 제거해도 튼튼하게 고정될 정도로

내부에서 이미 정확한 고정이 되있는 것이지요.

하지만 옆면 부분을 없앨 경우 케이블타이가 풀려버리는 상황이 올지 모르니

비록 보여주기 위해 옆면을 잘라버렸다 쳐도

실제로는 자르지 마시고 그냥 두시는 편이 좋을 거 같습니다.
Array

이번에는 쿨러 두개를 서로 연결하는 방법을 해보겠습니다.

120mm 두개인지라 은근히 무게도 되고

고작 두 구멍으로 확실한 고정을 시키기란 쉽지 않은 부분입니다.

케이블타이 1개짜리로는 어림도 없는 부분이지요.

(1개짜리로 할 경우 확실한 고정은 커녕 헐거워서 덜렁덜렁할 가능성이 매우 큽니다)

여기서는 드디어 4개짜리를 이용하여 확실한 고정을 해보도록 하겠습니다.
Array

역시 이렇게 먼저 한개를 넣어줍니다.
Array

여기까지는 동일해보입니다만
Array

상대편쪽에 저렇게 연결해줍니다.

주의할 점은 케이블타이 머리가 걸리기 때문에 먼저 ㄷ자 모양으로 만들어주고

쿨러에 넣으려 하면 안들어가집니다.

하나씩 쿨러에 넣어주면서 연결하는 것이 중요 포인트입니다.
Array

이렇게 쿨러를 통과하는 사각형을 만들어 주었습니다.
Array

역시나 쿨러 자체의 고정부터 확실하게 해줍니다.
Array

반대쪽도 먼저 동일하게 해준 후에 고정하는 편이

한쪽 고정 후 다른 쪽 하는 것보다

고정이 훨씬 튼튼하게 됩니다.
Array

한쪽을 확 조이지 말고 조금씩 조여가면서

양쪽을 대략 조인 후

마무리로 확확 당겨줍니다.

한칸이라도 더 세게 당겨줍니다.

그러면 정확하게 머리부분이 나사처럼 저렇게 됩니다.
Array

거의 정확하게 나사처럼 되었지요?
Array

깔끔하게 마무리 해줍니다.
Array

어떤가요? 튼튼한가요?

참고로 양쪽을 손으로 들어준게 아닙니다.
Array

한쪽만 들었을 뿐입니다.

제가 가볍게 든게 아니라

좀 무거운데 손이 되도록 안찍히려고

저렇게 들었습니다 ㅠ

손이 후들거려서 힘들었습니다 ^^

여튼 저정도의 고정이라면

충분히 써먹을만한 정도라 생각됩니다 ^^

4. 보너스 - 활용........이라고 하려 했는데 삽질되버린 ㅠ

Array

이번에는 좀 고난이도로 방열판에 쿨러를 고정시키는 방법을 해보도록 하겠습니다.

이 방열판은 대략 눈치채신 분들도 있겠지만

AMD 64bit 초창기 쿨러에 있던 방열판입니다.

세척해오느라 물기가 보이지만 사용할 것이 아니므로

(세척해왔습니다)

상관없으니 바로 시작해봅니다.
Array

굴러다니던 쿨러를 사용합니다.

(그나저나 정말 더럽군요 -ㅅ-)
Array

이렇게 장착해볼 것입니다.

하지만 먼저 이야기하자면 쿨러가 방열판보다 작을 경우 오히려 고정시키기가 힘듭니다.

고로 이번 실험은 대 실패의 예감입니다.
Array

먼저 쿨러와 직접 고정할 케이블타이를 넣습니다.

원래는 보통 방열판이 살짝 더 넓어야

저 케이블타이들을 눕혀서 넣는데 옆으로 넣기 때문에

제대로 고정시키기 힘든 상황입니다.

경험상 메인보드 노스브릿지 방열판정도가 딱 제격입니다.
Array

그 다음 쿨러에 바로 연결하지 말고 4개짜리를 이용하여

원래 넣은 케이블타이들이 위로 올라오지 않도록 락 역할을 해주도록 만들어줍니다.
Array

그 다음 4개짜리 활용하여 헐겁게 연결해줍니다.

사진상으로 잘 안보일거 같지만 밑부분이 이미 케이블들이 옆으로 뒤틀어지면서

제대로된 고정시키기가 참 어렵게 되어버렸습니다.
Array

그 다음 고정입니다.

틀어져버리면서 고정이 상당히 힘들었네요.

대충 이렇게 된다는것만 보여주기 위해

이정도만 하고 사진 찍습니다.
Array

붕 떠버려서 쿨링 역할이 제대로 안되지요.

이번껀 실패입니다만

쿨러가 오히려 더 크고 방열판이 조금만 넓고...

고정락을 더 활용하기 좋게끔 홈들이 더 많다면

훌륭한 락 역할을 해줄 수 있게 됩니다.

Array

위의 사진에서의 노스방열판 장착모습처럼 말이죠.

저것 저래보여도 댕겨도 안빠질 정도로 완벽한 고정이 되었답니다.

다만 저의 손을 비게 해서

(라는 이유는 핑계고 그냥 지름신이 땡겨서)

얼마전에 케이스부터 쿨러까지 죄다 갈아버렸습니다만 =ㅅ=

Array
이건 잔해물입니다 =ㅅ=

어느샌가 오늘만 이정도를 낭비해버린 꼴이군요 ^^

하지만 이로 인해 도움이 된다면야...

기꺼이 실험정신으로 도전하는겁니다.

이상으로 실험틱한 팁을 끝냅니다.

도움이 되었을지는 모르겠습니다만

한분이라도 도움이 된다면 저로서는 기쁠 따름입니다 ^^

다음번에 또 실험정신으로 -ㅅ-

더 좋은 방법을 연구하돌록 하겠습니다.

  1. 하타 2008.06.18 18:06 신고

    이야, 멋진 활용법 잘 봤습니다. ^ㅡ^

  2. Digital Angel Master 2008.06.19 23:49 신고

    최근에 퍼오는 글은 전부 제목밑에 출처를 표기하고 있습니다.
    도움이 되셨다니 다행이네요 :)

Source : http://www.parkoz.com/zboard/view.php?id=my_tips&no=11632


Image size : 640 x 576, Thursday June 05, 2008 12:36:19 pm, Uploaded by 조승환

표 이외에 별다른 설명이 필요 없네요.

초보자 분들에게 도움이 되었으면 좋겠습니다. ^^

원본출처 : CAMP30

Source : http://www.parkoz.com/zboard/view.php?id=my_tips&no=11588

 


Image size : 640 x 537, Tuesday May 27, 2008 11:42:56 am, Uploaded by 유경목

안녕 하세요.^^;;

안산 파코즌 유경목 입니다.

이번에 소개드릴 팁은 여름을 대비한 아주 간단한 팁입니다.

주변에서 쉽게 구할수 있는 재료를 찾다보니 본의 아니게 옷걸이를 자주 애용하게 되는데

이번에도 역시 옷걸이를 받침대로 활용한 마우스 선풍기 입니다.

구차한 설명이 필요없을 정도로 간단한 팁이기에 중요 포인트만 설명 드리고 넘어 가도록 하겠습니다.

재작에 필요한 재료

1.옷걸이

2.120mm 팬

3.벤치(옷걸이를 자르거나 접는 용도)

4.자(철자나 줄자 치수를 잴수 있으면 됨)

5.드라이버

6.네임팬 - 있으면 좋고 없어도 관계없음 눈대중으로 대충 접어도 큰 불편함이 없을것으로 생각 됩니다.

7.전원 연결용 커넥터

여기에 사용된 파워서플라이는 아래의 이전 게시물을 참고 바랍니다.

▶ [하드] 버리는 파워서플라이 ⇒ 외장 어뎁터로 활용하기
  내용보기 : http://www.parkoz.com/zboard/view.php?id=my_tips&no=11185

아래와 같이 주변에서 쉽게 접할수 있는 재료와 공구를 이용해서 시작해 보도록 하겠습니다.

▽ 클립을 이용해서 아래와 같이 커넥터를 살짝 살짝 눌러주고 아래에서 잡아 당기면 쉽게 분리 됩니다.

▽ 분리된 + 커넥터를 벤치를 이용해서 잘라줍니다.

▽ 120mm팬의 전원선 끝단부에 납땜으로 아래와 같이 연결해 줍니다.

▽ 사용자의 사용 용도에 맞게 연장선을 연결 하시면 더욱 좋겠죠.^^

▽ 먼저 옷걸이의 중앙부를 팬의 마운트홀과 홀 거리만큼 접어 줍니다.

참고로 120mm 팬의 경우 105mm입니다.

그런다음 바닥면을 형성할수 있는 크기를 대략 80mm로 정해서 양쪽을 구부려 줍니다.

▽ 바닥면에서 마운트 홀 까지의 거리는 대략 50mm 중간에 꺽이는 부분까지의 거리는 바닥면에서 30mm정도로

잡았습니다.마우스에 팬의 풍향이 집중 되도록 가능한 높이를 낮게 잡아 주는것이 좋습니다.

마운트 되는 끝단부는 벤치로 살짝 살짝 구부려서 끝단부를 살짝 잘라주고 마무리 하시면 됩니다.

▽ 끝단부는 팬그릴과 함께 나사가 들어갈수 있도록 동그랗게 만들어 주시면 됩니다.

▽ 드라이버를 이용해서 팬그릴과 함께 마운트한뒤 마우스에 풍향이 집중되도록 옷걸이를 살짝 꺽어서

방향을 잡아 줍니다.

▽ 팬의 회전수를 높이려면 +선을 노란색(12v)의 커넥터와 연결 합니다.

▽ 팬의 회전수를 낮추려면 +선을 빨간색(5v)의 커넥터와 연결 합니다.

일반적으로 아주 무더운 날씨가 아니라면 이렇게 연결해 사용 하시는 것이 좋습니다.

▽ 이전 게시물에 등장했던 파워 서플라이에 연결된 모습입니다.

이상...

한여름을 대비해 손에 땀차는 것을 근본적으로 해결한 뽀송 뽀송한 마우스 잡기편을 마치도록 하겠습니다.

부족한 글 스크롤의 압박에도 불구하고 끝까지 관심 가져주신 모든 분들께 감사 드립니다.

항상 건강 하시고 행복한 시간 되시길 바랍니다.^^;;

End

Source : http://itviewpoint.com/46412

 

Array Array
“드륵…드륵…다다다닥…끼리릭…”

대용량 디지털 데이터를 안정적으로 저장할 수 있고, 개발 당시로서는 획기적인 입출력 속도를 제공하면서 대표적인 저장장치로 자리 매김한 ‘하드디스크 드라이브(Hard Disk Drive, 이하 HDD)’는 금세기 디지털 혁명을 이끌었다고 해도 과언이 아니다.

HDD는 딱딱한 플래터(platter)가 디스크 역할을 하기 때문에 ‘하드(Hard)’라는 표현이 붙었다. 이 플래터가 분당 수천에서 1만회 이상 회전하는 스핀들 모터(spindle motor) 위에서 고속으로 돈다. 플래터 위에는 데이터가 기록되는 자성 물질이 깔려 있다. 컴퓨터로 들어온 각종 정보를 HDD에 기록하고 저장된 정보를 읽어내는 역할을 하는 헤드(head)가 수없이 플래터 사이를 누비며 데이터를 읽는다. 정확한 탐지를 위해 스텝퍼 모터(stepper motor)가 헤드의 동선을 제어한다.

IBM이 세계 최초의 HDD인 ‘라막(RAMAC)’ 5메가바이트(MB) 제품을 내 놓은 때가 1956년이다. 그러나 현재 사용되고 있는 HDD의 원형이 된 제품은 1973년 IBM이 개발한 ‘305 라막’ 모델이다. 특히 이 제품은 플래터와 헤드가 접촉되지 않는 방식을 채택, 데이터를 읽고 쓸 때 발생할 수 있는 내구성이 크게 개선됐다. 1980년에는 시게이트테크놀로지가 5.25인치 규격의 ‘ST―506’ 5MB/s 모델을 통해 현대적인 HDD 표준을 마련했다.

이후 약 30년 넘게 HDD의 기본 구조는 변하지 않았다. GMR 헤드, 수직자기저항, 유체베어링 등 신기술을 통해 저장 공간은 대당 1테라바이트(TB, 3.5인치 드라이브 기준)를 넘었고, 처리 속도도 수천~수만 배 빨라졌다.

그러나 주변 장치들이 발전하는 속도에 비해서는 크게 뒤쳐졌다. 물리적으로 움직이는 기계 구동부가 있다는 것이 한계였다. HDD가 ‘컴퓨터 성능을 저하시키는 주범’이라는 오명을 뒤집어쓰고 있는 이유도 바로 이 때문이다.

이러한 HDD가 마침내 변화의 조짐을 맞고 있다. 컴퓨터 주변장치 중에서 가장 변화가 더딘 것 중 하나였지만, ‘플래시메모리 기술’을 맞아 비약적인 성능 개선을 이룰 가능성이 높아졌다.

◆미래 컴퓨터 성능, SSD에 달려 있다

솔리드스테이트디스크(Solid State Disk, 이하 SSD)란 ‘플래시메모리 반도체’만을 이용해 만든 새로운 형태의 PC 보조기억장치다. 구동부가 없고, 플래시메모리와 이를 저장장치로 사용할 수 있도록 돕는 ASIC(주문형반도체) 콘트롤러가 전부다. 제품 명칭에 ‘디스크’라는 단어가 있지만 실제로 ‘자기(磁氣) 디스크’는 들어가지 않는다.

SSD가 처음 등장한 15년 전에는 대부분 전원이 꺼지면 기록된 데이터가 사라지는 휘발성 ‘D램’ 기반이었다. 당시에는 메모리 가격이 너무 높았기 때문에 메모리를 집적시킨 대형 저장장치를 구현하는 것은 비현실적이었다. 그러나 반영구적으로 데이터 저장이 가능한 플래시메모리 기술이 발달하고, 가격도 급격히 하락하면서 ‘자기 디스크’가 아니라 ‘반도체’로만 구성된 보조기억장치가 현실화됐다.

SSD는 반도체를 사용했기 때문에 매우 빠르다. 플래시메모리 반도체 칩 1개의 쓰기 성능은 아직 10~20MB/s로 매우 부실한 수준이다. 그러나 ‘채널’을 확 늘려 여러 개의 플래시메모리를 동시에 읽고 쓰면 성능이 비약적으로 높아진다. SSD 교체를 통해 저장장치 성능이 높아지면 그 동안 HDD 때문에 느렸던 전체 컴퓨터 시스템이 빨라진다. 데이터 병목현상을 한 번에 해소할 수 있는 것이다. 또한 중앙처리장치 및 메모리와 함께 시스템 균형을 이룰 수 있어 전체 시스템 성능이 향상된다. 세계 최고 수준의 SSD 콘트롤러 기술을 보유하고 있는 국내 한 벤처기업 이사는 “현재 고급형 싱글레벨셀(SLC) 플래시메모리를 사용할 경우 읽기 120MB/s, 쓰기 90MB/s를 구현할 수 있다”며 “차세대 콘트롤러에서는 이보다 2배 성능이 나올 것으로 예상하고 있다”고 말했다. 싱글레벨셀 플래시메모리는 보급형 멀티레벨셀(MLC) 플래시메모리보다는 쓰기 성능이 두 배 이상 높지만 값도 훨씬 비싸 가격경쟁력은 크게 처진다. 그러나 이 정도라면 HDD 성능을 뛰어넘는 것은 물론이고, 향후 초고성능 컴퓨터를 구현하는데 핵심적인 역할을 수행하게 된다.

또한 SSD는 HDD와 달리 기계식 구동부가 없는 전자식 구조를 채택했기 때문에 내구성이 높고, 데이터 신뢰성 및 안정성 확보에 탁월하다. 특히 디스크 탐색 시간과 회전 지연시간 등 기존 HDD에서 발생하는 불필요한 동작을 완전히 제거해 데이터 임의접근시간을 최소화했다.
‘디스크’ 위에 원형으로 기록하는 HDD와 달리 SSD는 플래시메모리 내부에 ‘블록(덩어리)’ 단위로 데이터를 기록한다. 따라서 한 번에 많은 데이터 요청이 발생할 경우에도 일정한 속도를 유지한다. 1초에도 수천~수만 회 이상 접속이 이뤄지는 일부 초고성능 서버에서는 접근 속도가 매우 중요한 고려 요소다. 이 밖에도 구동 장치에 소요되는 전력만큼 소비전력을 더 절약하면 휴대기기의 배터리 수명을 늘릴 수 있다.
◆플래시메모리 집적도 높아져 SSD 현실화
최근 SSD 시장의 움직임이 심상찮다. 지난 해 말부터 국내외 주요 기업들이 다양한 형태의 인터페이스를 채택하고, 가격을 크게 낮춘 제품을 잇달아 출시했기 때문이다. 게다가 노트북PC 제조사들은 SSD를 선택사양으로 제공하는 사례가 점차 증가하고 있고, 휴대기기에 채택하려는 움직임도 활발하다.

SSD 대중화의 분위기가 무르익은 까닭은 그 동안 걸림돌로 지적됐던 ‘가격’ 문제가 해소될 조짐을 보이고 있기 때문이다. 플래시메모리의 집적도가 크게 높아져 메가바이트 당 단가가 크게 하락했고, 이 때문에 가격 경쟁력이 덩달아 높아졌다.

SSD는 기가바이트 당 가격을 비교하면 여전히 HDD보다 수십 배 이상 비싸다. 그러나 낸드플래시 가격이 지속적으로 하락하면서 가격 격차가 급속히 줄어들고 있다는 점은 주목할 만하다. 가격조사업체 자료에 따르면 현재 3.5인치 HDD는 1TB 제품도 30만원이 채 안 된다. 그러나 SSD 역시 32GB SLC 모델의 경우 불과 1년 사이에 100만원에서 60만 원대로 절반 가까이 싸졌다. 성능이 다소 떨어지는 MLC 모델은 1/3 이하인 30만 원 선이 무너질 태세다.

웨어 레벨링(Wear-leveling) 기술은 플래시메모리의 단점으로 제기됐던 ‘반도체 셀 수명’ 문제마저 해소했다. 플래시메모리 업체들은 개당 10만회 쓰기(SLC 기준)를 보장하고 있다. 업계는 플래시메모리의 전체 영역을 골고루 사용하는 알고리즘을 적용, SSD 수명을 확 늘렸다. 업계 관계자는 “매일 50GB 쓰기를 반복하더라도 100년 넘게 사용할 수 있다”며 “사실상 수명이 다해 고장 날 가능성은 매우 낮은 셈”이라고 말했다. SSD 수명에 대한 논의 자체가 무의미하다는 설명이다. 그는 다만 “MLC 플래시메모리를 사용할 경우 쓰기 속도가 절반 정도로 저하되고 수명도 5000회 수준으로 크게 하락하는데, 이렇다 하더라도 7~8년 이상 무리 없이 사용할 수 있는 수준”이라고 덧붙였다.

Array

◆SSD, 열악한 환경에서 고성능 발휘

지금까지 SSD는 기업용 서버 및 초고성능 저장장치 성능을 극대화하는데 주로 사용되고 있다. 기존 HDD에 비해 가격은 매우 비싸지만 성능이 탁월하기 때문이다.

그러나 SSD의 향후 가능성은 단순한 성능-용량 경쟁 보다는, HDD가 사용될 수 없는 환경에서 더 빛을 발휘할 수 있다는 가능성에 초점을 맞춰야 한다. 노트북, 휴대용 단말기, 소비자 가전 등 다양한 환경에 쉽게 적용할 수 있고, 차량-항공-군수-산업용 기기 등 극한의 특수 환경에서도 무리가 없다. 정형화된 HDD 디자인에 구애받지 않기 때문에 변형도 자유롭다. 충격-발열-소음-소비전력 등 거의 모든 외적 요인을 견디는 내구성이 HDD보다 훨씬 우수하다.

업계에서는 장기적으로는 HDD를 밀어내고 컴퓨터 주기억장치에 이어 보조기억장치마저 반도체인 SSD로 완전히 대체되기를 기대하고 있다. 기존 HDD를 대체할 것이라는 단순한 전망보다는 컴퓨터 시스템에 직접 내장 되어 1차 보조기억장치로 자리 잡는 것이 SSD의 최종 목표라는 설명이다. 업계 관계자는 “향후 집적도 경쟁에 치우쳐 있는 플래시메모리 기술이 처리속도 경쟁으로까지 확대된다면, HDD는 다량의 데이터를 장기간 쌓아 두는 ‘고용량 백업장치’로 밀려나 버릴 것”이라고 전망했다.

◆잇달아 SSD 채택…2008년 전망은 ‘맑음

SSD는 플래시메모리를 생산하고 있는 업체들이 새로운 시장 수요 창출을 위해 가장 적극적이다. 세계시장 점유율 45%로 낸드플래시 부문에서 전 세계 1위를 달리고 있는 삼성전자는 2006년 3월 64GB SSD 제품을 처음 출시한 데 이어 1월 초 라스베이거스에서 열린 2008 CES 전시회에서 MLC임에도 쓰기 속도가 70MB/s에 달하는 128GB짜리 고속 제품을 선보였다. 기존 제품보다 거의 두배 가까이 향상된 것이다.

낸드플래시 2위 업체인 도시바도 지난해 5월부터 SSD를 본격적으로 양산하기 시작한 데 이어 2008 CES에서 대용량 제품을 대거 공개했다. 세 번째 큰손인 하이닉스반도체도 당초 2009년에 SSD를 양산하려던 일정을 올 상반기로 앞당겼다. 미국 플래시메모리 카드 시장 1위인 샌디스크, 미국 최대 D램 업체인 마이크론, 세계 최대 HDD 업체인 시게이트테크놀로지 등도 SSD 시장에 군침을 흘리고 있다. 심지어 인텔은 올해 안으로 읽기와 쓰기속도가 250MB/s, 130MB/s에 이르는 제품을 내 놓겠다고 공언한 상태다.

SSD는 플래시메모리보다 더 중요한 것이 콘트롤러 기술이다. 콘트롤러가 SSD 성능을 좌우하기 때문이다. 국내에서는 엠트론을 비롯해 뉴틸메카, 오픈네트써비스, 명정보기술 등 중소기업들이 다양한 기술을 전면에 내세우고 고성능 콘트롤러 경쟁에 나서고 있다. 전 세계적으로는 40~50여개 업체가 SSD 시장에 뛰어든 것으로 추정된다.

SSD를 자사 제품에 채택하려는 움직임 또한 점차 활발해지고 있다. 삼성은 지난해 32GB SSD가 장착된 노트북 '센스Q40'과 UMPC '센스Q1-U'를 선보였다. 일본 소니는 UMPC '바이오UX'를, 델과 도시바는 'XPS 1330' '포테제 R500' 등 고성능 노트북에 SSD를 채택했다. 올해에도 UMPC 등 휴대 기기를 중심으로 시장 수요가 크게 늘어날 전망이다. 일부 전문가들은 2012년 출시되는 노트북 10대 중 4대에는 SSD가 사용될 것이라는 전망도 나온다.

시장조사 기관 웹피트리서치는 SSD 시장 규모가 지난해 5억8000만 달러에서 2012년 101억 달러로 20배 이상 커질 것으로 예상했다. 가트너는 SSD를 탑재한 노트북이 올해 약 400만대에서 2010년에는 8배가 늘어난 3200만대에 육박할 것으로 전망했다.

이와 관련 삼성경제연구소는 지난 7일 공개한 ‘차세대 저장장치 SSD의 부상과 시사점’이라는 보고서에서 “군수, 항공, 선박 등 특수분야에서 일부 시장을 형성했던 SSD가 최근 메모리 용량 증가와 가격하락으로 서버와 초슬림 휴대용 노트북PC 등 기업용. 일반소비자 시장으로 채용이 확대되고 있다”고 전망했다.

연구소는 또 “앞으로 저장장치 시장은 HDD가 대용량급, SSD는 중소용량급으로 양분되며, SSD는 저가격화와 고신뢰성, 저소비전력으로 사무용 기기와 서버, 기업용 PC 등에 올해부터 본격적으로 채용되고 내년부터 2010년까지는 노트북PC, PMP, 디지털 캠코더 등 일반소비자용 기기에 채용될 것”이라고 예상했다.

인터넷뉴스부 서명덕 기자

- 지난 주 지면에 게재된 위클리비즈 기사를 늘려 자세히 썼습니다. 아무래도 종이 지면에 들어가는 것은 어려운 건 빠지게 마련이죠. 역시 어려운 걸 쉽게 쓰기는 정말 쉽지 않습니다.^^

출처 : http://www.zdnet.co.kr/builder/dev/0,39035659,39167141,00.htm

 

임베디드 시스템의 핵심인 마이크로 프로세서는 소프트웨어에 의해 제어가 된다. 윈도우CE운영체제는 ARM, X86계열, MIPS 계열 프로세서에서 많이 사용되는 임베디드 시스템용 운영체제이다. 그럼 이 윈도우CE라는 운영체제는 어떻게 만들고 어떻게 디버깅할까?
물론 플랫폼 빌더(Platform Builder)라는 개발 툴을 사용한다. 지난 글에도 많이 언급을 했기에 익숙한 독자도 있을 것이다. 플랫폼 빌더에 대한 이야기는 잠시 뒤로 미루고 필자의 과거 먼저 회상해 보겠다.
필자 역시 처음 컴퓨터에 대해서 공부하기 시작할 때 운영체제에 관심이 많았었다. MS-DOS가 PC운영체제로 널리 사용되던 시절이었다. 이때 우연히 보게 된 UNIX 나 XENIX는 운영체제에 필자의 관심을 끌기에 충분한 요소를 가지고 있었다. 더군다나 소스까지 공개되었다는 사실에 더욱 더 흥미와 관심을 가지게 되었다. 어렵사리 소스를 인터넷을 통해서 받고, 도트 프린터의 기계음이 전산실을 가득 차게 하면서 소스를 프린트해 가며 봤다.
하지만, 역시 여러분의 예상과 같이 프린트된 많은 소스들을 보지 못한 체 분석을 포기했다. 운영체제라는 것은 프린트한 소스만 보면서 이해하기에는 너무나 많은 의미와 내용을 담고 있기 때문이다.
그래도 무의미했던 행동은 아니었다. 어렴풋하게 운영체제에서 어떻게 프로그램이 스케줄 되며, 메모리는 어떻게 관리 되는지 알게 되는 계기가 되었다. 사실 더 자세히 알게 된 시기는 운영체제에 대해 본격적으로 공부를 한 후다.
여러분도 필자와 비슷한 의문과 호기심을 가지고 있을 것이라 생각된다. 하지만 모든 것을 한번에 다 알 수는 없다. 우선은 먼저 운영체제 개발도구에 대하여 간단히 살펴보고자 한다. 그것은 운영체제를 개발하기 위한 개발도구가 어떤 것이 있는지 먼저 아는 것이 순서기 때문이다.
개발도구를 자세히 알고, 개발과 디버깅에 관한 내용을 파악하다 보면 어느덧 윈도우CE에 대한 전문가가 되어 있을 것이다.
우선 그전에 집고 넘어가야 할 것들은 다음과 같다.
"임베디드 시스템용 운영체제도 하나의 프로그램이다."
"임베디드 시스템용 운영체제도 하나의 응용 프로그램을 만드는 것과 같이 컴파일을 하고 빌드를 해야 한다는 것이다"
"운영체제도 디버깅을 할 수 있다!"
그럼 지금부터 윈도우CE를 개발하기 위한 12가지 도구들을 살펴보기로 하자. 개발 툴을 통하여 윈도우CE 운영체제를 개발할 때 어떠한 방식으로 진행되는 지 볼 수 있을 것이다.
1. 플랫폼 빌더(Platform Builder)
윈도우CE 운영체제를 만드는 소프트웨어라고 말할 수 있다. 플랫폼 빌더는 윈도우CE 5.0 버전까지는 독립된 소프트웨어 형태로 제공이 되었다가 6.0 버전부터는 Visual Studio 2005에 포함되는 형태로 제공되고 있다. 플랫폼 빌더의 기능을 정리한다면 다음과 같다.
-윈도우CE 운영체제 및 디바이스 드라이버, 응용프로그램 소스를 컴파일 하고 링크 함
즉, 크로스 컴파일러(Cross Compiler) 및 링커(Linker)를 가지고 있다.
-윈도우CE 운영체제에 포함될 컴포넌트를 결정하고 구성한다.
-디버거 기능을 이용하여 운영체제 내에 포함된 디바이스 드라이버나 응용프로그램을 디버깅 한다.
-플랫폼 빌더는 통합 개발환경(IDE 혹은 Integrated Development Environment)이다. 소스 편집, 관리를 할 수 있다.
-플랫폼 빌더를 이용하여 운영체제 이미지를 포팅 하려고 하는 개발보드에 다운로드 할 수 있다.
-리모트 툴(Remote Tools)을 사용할 수 있게 해 준다. 리모트 툴은 동작하고 있는 개발보드의 상태나 프로세서 정보, 시스템 정보를 확인하는 툴이다.
모든 기능을 나열하기엔 무리가 있다. 운영체제만큼 플랫폼 빌더도 복잡한 기능을 가지고 있다. 하지만 이것 하나만 명심해 두자! '플랫폼 빌더는 윈도우CE 운영체제를 개발하고 디버깅하기 위해서 사용하는 소프트웨어 툴이다.'라는 것이다. 윈도우CE를 시작하면서 가장 많이 사용하고 접하게 되는 툴이다.

Array

PlatformBuilder

2. CETK(Windows CE Test Kit)
윈도우CE 운영체제를 테스트 하는 방법은 무엇인가 물어본다면 다음과 같이 대답하고 싶다. 첫 번째는 기기를 사용할 사용자 같이 테스트를 하는 것이고, 두 번째는 CETK를 통하여 호환성 및 안정성을 테스트 하는 것이다.
윈도우CE를 개발하면서 가장 어려웠던 점은 사용자가 사용하는 환경대로 테스트 해보는 것이었다. 물론 이를 대비하여 다양한 테스트를 한다. 별도 장치를 이용하여 버튼을 반복적으로 누른다든가, 시스템 전원을 On/Off를 반복하여 문제가 없는지 테스트를 한다. 이런 기본적인 반복 테스트를 통해 사용자가 동작 중 생길 문제를 미리 확인하게 된다.
CETK는 이러한 반복적인 테스트를 할 수 있도록 제공된 프로그램이다. 물론 On/Off 테스트와 같은 단순한 반복 테스트보다는 시스템 내에 구현된 디바이스 드라이버와 시스템 자체의 성능과 안정성을 테스트하는데 더 집중되어 있다. 플랫폼 빌더와 함께 제공되는 CETK는 다음 표와 같은 테스트를 할 수 있도록 만들어졌다.

Array

CETK의 큰 장점은 위 테스트 이외에 사용자가 원하는 테스트 항목을 추가하는 기능이 있다는 것이다. 새로운 테스트 항목을 프로그램으로 만들어 추가 할 수 있다는 것이다.
CETK는 일반적인 테스트 관련 툴의 성격보다는 윈도우CE 운영체제 개발자를 위한 소프트웨어로 볼 수 있다. 시스템의 안정성을 확보하기 위한 도구로써 사용될 수 있기 때문이다. 필자의 경우 윈도우CE 운영체제 보다는 윈도우 모바일 장치를 개발했기 때문에 CETK과 비슷한 로고테스트(Microsoft Logo 테스트)를 진행했었다.
테스트의 이름이나 툴은 다르지만 매우 비슷한 테스트다. 실제로 테스트에 사용되는 프로그램 소스가 일부 동일하기 때문이다. 이 테스트를 하던 중 예상외의 결과가 나와서 당황한 적이 있었다. 많은 부분에서 테스트 항목을 패스 못하는 결과를 보여줬다.
BSP도 프로세서 업체에서 최신으로 제공 받았고 포팅 한 OS도 어느 정도 안정성이 있다고 판단된 시점이었다. 사실 의외의 결과였다. 문제의 원인은 포팅 방법과 BSP 문제였다. 포팅 방법 문제는 윈도우CE의 정책을 무시하고 개발한 디바이스 드라이버의 문제였고, BSP 문제는 일부 한정된 조건으로 BSP테스트를 하기 때문에 테스트 항목의 모든 조건을 만족시킬 수 없었으며, 일부항목에 대해서는 아예 고려가 되지 않았다는 것이다.
이제는 BSP에 대한 조건이 강화되어 이전과 같은 결과는 나오지 않지만 BSP 제공할 때 문서를 보면 어떤 테스트는 통과를 하고 어떠한 테스트는 문제가 되는지 설명해 주고 있다. 이런 것처럼 CETK는 혹 있을지도 모르는 문제를 검증하기 위한 마지막 단계이다.

Array

CETK

3. Remote Kernel Tracker
윈도우CE 커널의 소스는 100%로 공개되었을까?
윈도우CE 6.0 버전부터 커널의 모든 소스가 공개 되었다. 따라서 맘만 먹는다면 윈도우CE의 커널이 어떻게 돌아가는지, 프로세서의 스케줄은 어떻게 이루어지는지, 동적 메모리 관리는 어떻게 이루어지는지 확인이 가능하다. 하지만 모든 소스가 공개 되었다고 생각하지는 말기 바란다. 아직까지도 많은 소스들은 공개가 되지 않았다. 윈도우CE는 Linux와 같은 공개 OS가 아니기 때문이다.
커널 소스를 일일이 분석하여 윈도우CE를 속속들이 알기보다는 문제가 생겼을 때 디버깅을 하는데 사용한다는 맞을 것이다. 특정한 문제가 발생하고 문제를 접근해 가는데 있어 소스는 중요한 역할을 한다.
하지만 윈도우CE는 여러 개의 프로세스(Process), 쓰레드(Thread)가 동시에 동작하는 멀티쓰레드(Multi Thread) 운영체제이다. 따라서 소스의 일부만 가지고, 디버거에서 브레이크(Break) 명령을 통해 운영체제의 동작을 일시 정지시킨 다음에 문제를 확인하기에는 어려운 점도 있다.
이때 사용하는 것이 리모트 커널 트랙커이다. 리모트 커널 트랙커는 윈도우CE 운영체제를 좀더 거시적으로 보게 해준다. 윈도우CE를 코드와 코드의 묶음이 아니라 프로세서와 프로세서, 쓰레드와 쓰레드의 관계로 보게 해준다. 이러한 점이 리모트 커널 트렉커의 중요한 점이다. 리모트 커널 트랙커로 할수 있는 기능은 다음과 같다.
-쓰레드간의 상호작용을 그림으로 보여준다.
-시스템 상태의 변화를 보여 준다.
-시스템 이벤트, 인터럽트, 쓰레드간의 연관 관계를 보여준다.
-프로세스와 쓰레드의 생성, 실행, 정지등의 상태를 상세히 보여준다.
한마디로 말해 커널 트랙커는 윈도우CE 운영체제가 동작하고 있는 모습을 자세하게 살펴볼 수 있게 해준다는 것이다. 어느 부분에서 정체되고 있으며 어떻게 접근해 가야 문제점에 다가갈 수 있는지 그래픽을 통해 보여주는 툴이다. 그래서 윈도우CE를 개발하는데 있어 중요한 역할을 하고 있다.

Array

KernelTracker

4. Remote Performance Monitor
윈도우CE 운영체제의 성능은 어떻게 평가할까? 물론 상용으로 판매하는 벤치마크(Benchmark) 프로그램이 있다. PC 환경의 벤치마크 프로그램처럼 프로세서의 성능, 메모리의 성능, 저장 장치의 성능을 측정할 수 있다.
하지만 운영 다루는 입장에서는 어떠한 벤치마크 프로그램이 필요할까? 물론 좀더 세부적으로 측정할 수 있는 툴이 필요하다. 각 프로세스 별로 어느 정도 리소스를 차지하는지, 어떤 프로세스가 많은 스케줄링 시간을 이용하는지 이러한 정보를 알아야 한다. 그래야 프로세서나 쓰레드의 우선순위를 조절해 운영체제가 조화롭게 동작하게 조정할 수 있다. 리모트 퍼포먼스 모니터라는 툴을 이용해 이런 작업을 할 수 있다. 리모드 퍼포먼스 모니터의 역할을 정리하면 다음과 같다.
-쓰레드, 프로세스, 시스템의 성능 및 통계 측정
-시스템 메모리 사용에 대한 측정
-전원, TCP, IP, RAS, ICMP 등 성능 측정

Array

perfmonitor

5. Remote Zoom-in
백문이 불여일견. 즉, 한번 보는 것이 말로 설명하는 것보다 낫다. 사실 이것이 윈도우CE를 개발하면서 비중이 높은 툴은 아니다. 단순히 동작하는 윈도우CE의 동작 화면을 캡쳐해서 저장하는 기능만 가지고 있는 툴이다.
하지만 어떻게 보면 플랫폼 빌더 다음으로 많이 사용한다. 문제점을 보고할 때, 매뉴얼 작업을 할 때 동작하는 장치에 대한 캡쳐 화면이 필요하다. 이때 사용하는 프로그램이 리모트 줌-인이다. 단순히 개발하고 있는 장치와 연결하여 원격으로 화면을 캡쳐하는 프로그램이지만 중요하고 많이 사용된다.

Array

perfmonitor

6. Remote Registry Editor
PC의 레지스터리를 변경해 본적이 있는가? 사실 PC를 많이 사용한 사용자라고 해도 레지스터리 에디터를 이용하여 윈도우 시스템의 설정을 변경하여 사용하는 사용자는 많지 않을 것이다. 또한 있다 하더라도 직접 레지스터리를 수정하는 것이 아니라 PC 최적화 프로그램을 이용해 자동으로 PC를 최적화 해주면서 레지스터리를 변경한 경험은 있을 것이다.
레지스터리는 PC 뿐만 아니라 윈도우CE에서도 중요한 항목이다. PC와 비슷하게 윈도우CE의 설정과 디바이스 드라이버 등록이 레지스터리를 통해 이루어지기 때문이다. 윈도우CE를 개발할 때 제일 먼저 알아야 하는 것이 디바이스 드라이버를 레지스터리에 등록하는 방법이다. 이런 것처럼 레지스터리에 설정을 변경하고 새로운 드라이버를 등록하기 위해서 사용한다.
만약 이런 툴이 없다고 한다면 레지스터리를 변경하고 윈도우CE 운영체제를 새로 만들고 개발보드에 다시 올리는 작업을 반복해야 할 것이다. 그래서 리모트 레지스터리 에디터는 개발에 필요한 중요한 툴 중의 하나다.

Array

Remote Registry Editor

7. Remote File Viewer
임베디드 시스템에 파일을 복사하는 방법은? 이런 문제에 고민할 일은 없었을 것이다. PC에서 파일을 복사하고 지우는 작업은 누구나 할 수 있는 일이다. 하지만 임베디드 시스템에서 파일을 사용하고 복사하는 작업은 복잡하다.(사실 PC에서 동작하는 파일시스템도 그 내부는 복잡할 것이다).
임베디드 시스템의 저장 장소는 플래시 메모리와 같은 저장 장치를 사용하고 동작하는 방법과 다르다. 따라서 비슷한 파일 시스템을 사용하기는 하지만 PC와 동일하다고 볼 수는 없다. 이러한 차이점을 극복하게 해주는 툴이 리모트 파일 뷰어다. PC에서 개발보드 파일 시스템내의 파일을 자유자제로 볼 수 있게 하고 PC로부터 개발보드로, 개발보드로부터 PC로 파일 복사 작업을 쉽게 해주는 툴이다.
윈도우CE 임베디드 시스템은 개발이 어느 정도 진행이 되면 ActiveSync를 통해 PC로 부터 파일을 복사할 수 있지만 그 전에는 운영체제 이미지에 파일을 포함시키는 것 말고는 없기 때문에 리모트 파일 뷰어는 초기 개발 시 중요한 툴의 하나이다.
8. Remote Heap Walker
메모리에는 여러 가지 종류가 있다. 응용 프로그램 내에서 malloc() 과 같은 함수에서 사용되는 메모리 영역, 함수를 호출할 때 인자가 저장되는 영역 등 여러 가지가 존재한다. 하나의 프로그램에서도 이런데 운영체제에는 더 복잡한 메모리 구조를 가질 것이다.
윈도우CE에서 이런 복잡한 메모리 이용 정보를 분석하게 해주는 툴이 리모트 힙 워커이다. 어떠한 쓰레드에서 어떻게 메모리를 할당하고 어떠한 방식으로 메모리를 이용하는지 분석할 수 있게 해준다. 메모리를 할당하고 제대로 해제는 하는지, 특정 프로세서에서 과도하게 메모리를 점유하지는 않는지 분석하기 위해서 사용된다. 잘못된 메모리 사용으로 인해 발생하는 메모리 누수를 방지하기 위해 사용되는 툴이다.
9. Remote Spy
당신의 행동은 다 기록되고 있다. 윈도우CE 운영체제는 윈도우와 그래픽, 이벤트로 구성된 시스템이다. 흔히 GWES(Graphics, Windowing, and Events Subsystem)이라는 명칭으로 부르고 있다.
이중에서 이벤트는 사용자의 입력을 처리하고 반응하는 구조를 말한다. 사용자가 터치패널을 터치하면 터치에 대한 입력 이벤트가 발생한다. 이 이벤트를 받은 이벤트 관리 프로그램은 적절한 위치에 새로운 윈도우를 만들게 된다. 이때 역시 새로운 윈도우가 생성되었다는 이벤트가 발생한다. 이러한 이벤트들의 움직임을 기록할 수 있게 하는 툴이 리모트 스파이다.
어떠한 이벤트가 발생하였으며 그에 따라 어떻게 움직이는지 확인하기 위해서 사용된다. PC용 응용 프로그램 개발자라면 다 들어봤을 Spy라는 프로그램의 임베디드 판이라고 보면 될 것이다.

Array

Remote Spy

10. OSBENCH
운영체제를 벤치마크 하고 싶은가? 그러기 위해서는 PUBLICCOMMONOAKUTILSOSBENCH에 있는 OSBENCH.EXE 프로그램을 사용해야 한다.
OSBENCH 프로그램은 플랫폼 빌더의 한 디렉토리를 차지하고 있는 응용 프로그램이며, 윈도우CE 운영체제의 스케줄러의 성능을 테스트 한다. 운영체제 자체의 성능을 테스트 한다기 보다 개발보드에 포팅된 운영체제가 원래 설계되었던 것처럼 제대로 동작하는지 확인하기 위해서 사용된다. 즉, 보드에 맞게 포팅한 부분이 잘 포팅이 되어 운영체제가 제 성능을 발휘하면서 동작하는지 확인하는 의도로 사용된다.
OSBENCH 프로그램은 앞에서 설명한 프로그램과는 다르게 결과가 화려한 그래픽으로 나타나지는 않는다. 시리얼포트나 파일로 결과가 출력되기 때문이다. 하지만 OS의 성능을 측정하는 중요한 툴이라는 것은 알아두어야 한다. 아울러 ▲시스템 함수 호출에 따른 시간 측정▲세마포어(Semaphore)나 뮤텍스(Mutex) 생성 시간 측정 ▲이벤트(event)관련 처리 시간 측정 등 주로 운영체제에서 사용되는 주요 요소의 동작 시간을 측정하는데 사용된다.
11. ILTIMING
인터럽트는 윈도우CE 운영체제의 심장이다. 물론 다른 운영체제도 인터럽트를 통해 프로세스 스케줄링을 하고 외부 장치에 대한 요구사항을 처리하게 된다. 따라서 하드웨어적인 인터럽트가 발생하고 처리되기까지의 시간이 얼마나 걸리는지 측정하는 것은 성능 측정에 중요한 요소가 된다.
윈도우CE 운영체제에서 이러한 성능 측정을 위해 사용되는 프로그램이 ILTIMING.EXE이다. 윈도우CE 운영체제에서 하드웨어 인터럽트의 발생에서부터 운영체제 처리부분까지, 그리고 인터럽트를 처리할 최종 쓰레드까지의 시간을 측정하는데 사용된다. 윈도우CE 운영체제를 포팅한 개발보드에서 인터럽트의 처리 시간을 측정하고 개선할 여지가 있는지 확인하는데도 유용하다.
12. 기타
윈도우CE운영체제를 개발 하는 데는 이 밖에도 많은 툴들이 있다.
-Remote Processor Viewer : 동작하는 시스템의 프로세스의 정보를 확인하기 위해서 사용한다. 실시간으로 PC에서 프로세스와 그 프로세스에 관련된 쓰레드 정보를 보여준다.
-Remote System Information : 동작하는 시스템의 메모리, 저장소, 플랫폼 이름 등 기본적인 시스템 정보를 확인하는데 사용한다.
-Remote Call Profiler : 프로파일러는 프로그램동작에 대한 분석 정보를 제공한다. 어떤 함수에서 리소스를 많이 사용하고, 프로세스 시간을 많이 사용하는지를 분석해서 프로그램내의 병목점(Bottleneck)을 해소하는데 사용한다.
-Application Verifier : 프로그램에서 생길 수 있는 메모리 누수, 핸들에 대한 잘못된 사용, GDI(Graphics Device Interface) 객체에 대한 누수를 탐지해 내는데 사용한다. 흔히들 응용프로그램에서 메모리를 할당하고 제때 해지하지 않는 문제로 생기는 문제를 미연에 찾아내주는 툴이다.

Array

System Information

Array

Call Profiler

이것들은 모두 윈도우CE 운영체제를 개발하기 위해 사용되는 중요한 툴들이다. 이 밖에도 소스를 관리하기 위한 소스세이프(SourceSafe) 프로그램, 소스를 편하게 보기 위한 프로그램 편집기 등 다양한 툴들이 사용된다.
이제까지 윈도우CE 운영체제를 개발하기 위해 사용되는 개발툴에 대해서 간단히 살펴봤다. 원도우CE를 탑재한 임베디드 시스템을 만든다는 것은 어려운 일이다. 언급한 툴들은 이러한 개발의 어려움을 도와주기 위해 제공된 툴이다.
윈도우CE 운영체제 개발은 참 막연할 일이다. 하드웨어도 새로 개발하는 작업이고 여기에 부트로더부터 시작해서 많은 디바이스 드라이버를 포팅해야 한다. 또한 운영체제가 잘 동작할 수 있도록 설정을 맞추고 테스트 해 봐야 한다. 여기에 다른 윈도우CE용 응용 프로그램이 정상적으로 동작하도록 호환성 보장도 해 주어야 한다.
이러한 모든 작업들은 지금까지 설명한 모든 툴을 이용해 검증하고 확인하면서 개발을 한다. 툴의 사용법을 잘 알고 이용하는 것이 모든 개발의 시작임을 강조하고 싶다. @

필자는?
필자 라영호는 2007, 2008 Microsoft Windows Embedded 분야 MVP이다. 윈도우 모바일 관련 스마트폰 개발과 윈도우CE 관련 장치를 개발하고 있다. 개인적으로 운영하고 있는 윈도우CE에 관한 블로그(www.embeddedce.com)를 통해 윈도우CE 개발에 대한 다양한 생각과 방법론을 함께 생각해 보고자 노력 중이다. 최근에는 윈도우CE를 이용해 어떻게 빠르고 안정적인 시스템을 만들 것인가를 고민하고 있다. 아울러 윈도우CE의 포팅 뿐만 아니라 개발에서부터 최종 제품이 나오기까지 거쳐야 할 다양한 테스트 및 신뢰성 문제에도 관심을 가지고 있다. 조만간 윈도우CE에 대한 다양한 강좌 및 테스트에 관한 내용을 알릴 예정이라고 한다.

출처 : http://www.ibm.com/developerworks/kr/library/os-eclipse-iphone/index.html?ca=drs-kr

 

 

Aptana 아이폰 개발 플러그인과 iUi 프레임워크를 사용해 아이폰 애플리케이션 만들기

난이도 : 중급

Adam Houghton, 선임 소프트웨어 개발자, SAS Institute, Inc.

2008 년 3 월 04 일

이 클립스, Aptana의 플러그인 그리고 iUi 프레임워크를 사용해 아이폰 웹 사이트를 만드는 방법을 배웁니다. 아이폰에서 사용할 수 있는 Javadoc 뷰어 개발 과정을 통해 사용자 인터페이스 디자인를 위한 팁을 살펴보고 아이폰 개발의 미래에 들어보겠습니다.

애플 (Apple)의 아이폰(iPhone) 플랫폼은 개발자들에게 흥미로운 기회를 제공하고 있다. 소형 데스크톱과 터치스크린으로 아이폰과 아이팟 터치(iPod Touch)는 짧은 기간에 100만 명이 넘는 사용자들을 가지게 되었다. 하지만 이런 고품격 디자인과 사유화된(proprietary) 플랫폼은 애플리케이션 개발자들에게 새로운 종류의 도전을 만들어 내고 있다. 애플이 소프트웨어 개발 키트(SDK)를 배포할 때까지는, 아이폰 플랫폼을 목표로 하는 개발자들은 아이폰의 룩앤필(look and feel)을 따르는 웹 애플리케이션을 만들어야만 한다.

운이 좋게도 그 일을 쉽게 할 수 있는 새로운 오픈 소스 도구들을 사용할 수 있다. Aptana의 이클립스용 아이폰 개발 플러그인은 아이폰에 특화된 프로젝트를 생성하고 회전시켜 볼 수 있는 미리 보기 화면을 제공한다. Joe Hewitt의 iUi는 CSS와 자바스크립트 프레임워크인데 아이폰 스타일의 위젯과 페이지를 가지고 있다.

본 기사에서는, Apatana와 iUi를 사용해 새로운 애플리케이션을 만들 것이다. 바로 아이폰에서 사용할 수 있는 간단한 자바독(Javadoc) 뷰어다. 먼저 아이폰에서 자바독을 브라우징할 수 있는 사용자 인터페이스(UI)를 만들겠다. 그런 다음 소스 코드에서 자바독 페이지를 만들어 내는 커스텀 doclet을 만든다. 그 뒤를 이어 아이폰을 목표로 했을 때 생기는 UI 문제를 살펴보고 이 오픈 소스 도구들을 사용해 개발과 디버깅을 간단하게 할 수 있는지, 그리고 앞으로의 아이폰 개발 방향에 대해 설명하겠다.

도구 빠르게 살펴보기

Aptana를 설치하고 iUi를 다운로드하는 것부터 시작한다.

1. 이클립스 V3.2에서 다음을 선택한다. Help > Software Updates > Find and Install.

2. Search for new features to install을 선택한다. 이 창에서는 여러분이 다운로드한 플러그인과 이클립스가 미리 정의해둔 플러그인 사이트의 목록을 보여준다.

3. New Remote Site를 클릭해 Aptana를 추가하고 URL을 다음과 같이 설정한다. http://update.aptana.com/update/3.2/.

4. 목록에서 새로 추가한 Aptana를 선택하고 Next를 클릭해 이용할 수 있는 모든 기능을 선택한다. 창을 닫고 기본 Aptana 편집기로 돌아온다.

5. 이클립스를 재시작한다.

6. Window > Open Perspective > Other를 선택하고 Aptana를 창에서 클릭한다. 툴바에 새로운 아이콘이 나타날 것이다.

7. Home 아이콘을 클릭한다. Aptana 기능에 대한 소개 페이지가 보일 것이다.

8. Apple iPhone Development에서 Download and Install을 선택한다.

9. 기능들을 설치하고, 창을 닫고 아이폰에 특화된 기능들을 Aptana에 설정한다.

10. 이클립스를 다시 시작한다.

11. 최신 버전의 iUi를 다운로드한다(참고자료 참조).

모든 준비가 끝났다면, 이클립스를 사용해 그림 1에 보이는 것처럼 iDoc이라는 새로운 아이폰 프로젝트를 생성한다.

그림 1. 새로운 아이폰 프로젝트 만들기
Array

그림 2는 간단한 아이폰 애플리케이션을 담고 있는 프로젝트를 보여준다.

그림 2. 이클립스에 생성된 아이폰 프로젝트
Array

HTML, CSS, 그리고 자바스크립트를 지원하는 Aptana의 기본 편집기가 제공하는 문법 하이라이팅을 확인할 수 있다.

아이폰 미리보기 모드와 애플리케이션 서버

텍스트 편집기 아래 부분에 Source, iPhone Preview, 그리고 시스템에 설치된 각종 브라우저(예를 들어 Safari Preview, Firefox Preview) 탭들을 볼 수 있다. iPhone Preview를 클릭하여 아이폰에서 보이는 샘플 애플리케이션을 보자. 폰을 돌리려면 브라우저의 바깥을 클릭하고, 네비게이션 막대를 숨기려면 폰 제목을 클릭하라. 가로로 보는 아이폰 미리보기 모드는 아래와 같다.

그림 3. 아이폰 미리보기 모드에서 가로 보기
Array

아 이폰 미리보기 모드는 시간을 매우 많이 절약할 수 있게 하는 장치다. 새로운 디자인 아이디어를 빠르게 테스트할 수 있고 컴퓨터에서 벗어나지 않고도 점진적으로 개발할 수 있다. 애플리케이션을 실제 아이폰에서 테스트해야 할 때가 오면, Aptana에 내장된 애플리케이션 서버가 매우 유용할 것이다. 이클립스 툴바에 있는 Run 아이콘을 클릭하여 서버를 실행한다. 그림 4는 이클립스에서 동작하는 애플리케이션 서버를 보여준다.

그림 4. Aptana 아이폰 애플리케이션 서버가 페이지를 호스트하고 URL 가지고 있는 email 생성한다.
Array

만약 아이폰이 와이파이(WiFi) 연결을 통해 로컬 네트워크에 연결되어 있다면, 서버 창에 보이는 URL에 접속할 수 있다. E-mail this url을 클릭하여 한 단계를 생략하고 여러분 아이폰에 있는 이메일 계정으로 메시지를 보낼 수 있다. 이메일에 있는 링크를 탭(화면을 툭 치는 것)하면, 아이폰의 웹 브라우저에서 애플리케이션을 실행한다.

iUi 데모: 극장 목록 웹 애플리케이션

Aptana 의 기본 애플리케이션이 아이폰에 특화된 HTML과 CSS를 포함하고 있더라도 그 기능은 매우 제한적이다. 좀 더 나은 대안책은 iUi 프레임워크다. iUi는 다양한 아이폰 인터페이스 스타일의 커스텀 위젯과 자바스크립트 효과를 가지고 있다.

다운로드한 iUi 파일 iui-0.13.tar의 압축을 풀고, 파일을 이클립스에 있는 iDoc 프로젝트로 복사한다. 그림 5는 iUi를 가지고 있는 프로젝트를 보여준다.

그림 5. iUi 프레임워크와 예제 프로젝트가 들어 있는 iDoc 프로젝트
Array

iUi 를 사용한 데모 웹 애플리케이션은 위에서 펼쳐진 샘플 폴더에서 찾을 수 있다. 음악 브라우저, 극장 목록 그리고 Digg와 비슷한 사이트를 포함하고 있다. Aptana의 아이폰 미리보기 모드를 사용해 이클립스에서 그것들을 확인할 수 있다. 그림 6은 극장 목록 웹 애플리케이션(samples/theaters/index.html)의 검색 페이지를 보여준다.

그림 6. iUi 예제 극장 목록 애플리케이션
Array

진짜 아이폰의 룩앤필과 얼마나 비슷한지 보기 바란다. 이렇게 미리 만들어둔 위젯은 아이폰 웹 애플리케이션을 빠르게 개발할 수 있도록 해준다.

UI 디자인하기

이번 예제에서는 iDoc이 라는 자바독 뷰어를 만들 것이다. 썬(Sun Microsystems)의 표준 자바독 생성기에 의해 만들어진 방대한 양의 HTML 문서들을 데스크톱에서는 잘 볼 수 있다. 하지만 아이폰에서 읽고 네비게이션하기에는 불편하다. iDoc은 아이폰에 적합한 자바독을 생성한다. ? 지하철이나 짝 프로그래밍 팀에서 관찰자가 도움을 줄 수 있도록 하기에 완벽한 브라우징 애플리케이션 프로그램 인터페이스(API)를 제공할 것이다.

아이폰 휴먼 인터페이스 가이드라인

iDoc에 필요한 UI를 디자인하기 전에 아이폰 개발과 일반적인 웹 애플리케이션의 다른 점을 이해하는 것이 중요하다. 애플의 iPhone Dev Center(참고자료 참조)에서 인용한 그림 7을 보면 이를 매우 멋지게 요약했다. 손가락은 마우스가 아니다. 데스크톱에서 볼 수 있는 픽셀 선택을 없애고 그 대신 탭(툭 치는 것), 플릭(화면을 가볍고 빠르게 휙 스치는 모션) 그리고 핀치(두 손가락으로 화면을 꼬집는 듯한 모션)와 같은 풍부한 사용자 상호작용 모델을 사용했다. 게다가 아이폰은 사용자가 들고 다니면서 시급한 상황에서 자주 쓰기 때문에 애플리케이션에서 원하는 정보를 빠르고 쉽게 제공할 필요가 있다.

그림 7. 손가락은 마우스가 아니다.
Array

애플의 iPhone Human Interface Guidelines(참고자료 참조)는 아이폰 웹 컨텐츠의 세 가지 타입을 정의하고 있다.

아이폰에 있는 사파리(Safari) 호환

비록 페이지의 일부분이 어도비 플래시(Adobe Flash)나 Java™ 애플릿처럼 지원되지 않는 플러그인에 의존하더라도 정확하게 보여줄 수 있는 모든 타입의 웹 페이지

아이폰에 있는 사파리에 최적화

아이폰에 맞게 내용의 크기를 조정했으며, 지원되지 않는 플러그인에 의존하지 않는 웹 페이지

아이폰 애플리케이션

웹 페이지가 아이폰의 룩앤필을 따르는 애플리케이션처럼 보이고, 가능하다면 전화, 이메일, 구글맵과 같은 아이폰의 서비스와 연동된다.

표 준 자바독 페이지는 첫 번째 범주에 해당된다. 아이폰에 있는 사파리와 호환되는 형태다. 정확하게 보이긴 하지만 관련된 정보를 찾으려면 핀칭과 플릭을 매우 잘 해야 한다. iDoc은 완전한 아이폰 애플리케이션을 목표로 하고 있다. 비록 다른 서비스와 연동할 일은 없지만 iDoc의 인터페이스는 마치 아이폰 애플리케이션처럼 느껴질 것이다.

iDoc UI

아 이폰을 목표로 할 때는 포커스를 유지하는 것이 중요하다. 애플리케이션은 특정 작업을 빠르게 수행해야 한다. 모든 가용한 기능을 포함시키려고 하면 안 된다. iDoc에서 사용자들은 클래스 이름, 메서드 이름, 메서드 시그너처 그리고 주석 등과 같은 자바 클래스에 대한 기본 정보를 찾아내야 한다. 이런 정보를 목적지인 구체적인 페이지로 안내하는 세 개로 나눈 네비게이션을 통해 제공할 것이다.

패키지 네비게이션

최상위 패키지

클래스 네비게이션

패키지 안에 있는 클래스, 인터페이스, 예외와 에러

자세한 클래스 네비게이션

클래스 안에 있는 설명, 필드, 상수, 그리고 메서드

세부 페이지

주석, 시그너처 그리고 매개변수

iDoc을 산만하지 않고 태스크에 집중된 상태로 유지하기 위해 기존의 자바독 기능을 몇 가지 제거했다. 예를 들어 패지키 설명 주석은 보여주지 않는다. 이것들은 대개 정보가 유익하지 않거나(예를 들어 acme.client에는 클라이언트 코드가 들어 있다.) 보통 존재하지 않으므로 그것들을 iDoc에서 빼고 인터페이스를 간단하게 만드는 것이 더 나은 선택이다.

세 부분으로 나눈 네비게이션을 위해 edge-to-edge 리스트를 사용한다. 이것은 전형적인 아이폰 애플리케이션에 익숙한 구조로 연락처, 이메일 그리고 음악을 브라우징할 때 사용된다. Edge-to-edge 리스트는 아이템을 44픽셀 높이의 같은 크기로 보여준다. 그리고 많은 양의 정보를 스크롤할 때 유용하다. 애플의 iPhone Human Interface Guidelines는 글꼴, 글자 크기 그리고 경계선 공간 수치를 제공한다. iUi 프레임워크는 CSS와 자바스크립트 언어로 이러한 수치에 맞게 구현해두었다. 따라서 아이폰 컴포넌트처럼 보이는 HTML 목록을 간단하게 만들 수 있다.

Listing 1은 페이지 헤더와 java.applet과 java.rmi 패키지의 첫 번째 2단계 네비게이션을 보여준다.

Listing 1. 페이지 헤더와 번째 2단계 네비게이션 HTML 문서

                
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>iDoc</title>
<meta name="viewport" content="width=320; initial-scale=1.0;
maximum-scale=1.0;
user-scalable=0;"/>
<style type="text/css" media="screen">@import
"iui/iui.css";</style>
<style type="text/css" media="screen">@import
"iDoc.css";</style>
<script type="application/x-javascript"
src="iui/iui.js"></script>
</head>

<body onclick="console.log('Hello', event.target);">
<div class="toolbar">
<h1 id="pageTitle"></h1>
<a id="backButton" class="button"
href="#"></a>
</div>
<ul id="home" title="Packages" selected="true">
<li><a href="#java.applet">java.applet</a></li>
<!-- more packages...-->
<li><a href="#java.rmi">java.rmi</a></li>
</ul>
<ul id="java.applet" title="java.applet">
<li class="group">Interfaces</li>
<li><a href="java.applet.AppletContext.html">
AppletContext</a></li>
<li><a href="java.applet.AppletStub.html">
AppletStub</a></li>
<li><a href="java.applet.AudioClip.html">
AudioClip</a></li>
<li class="group">Classes</li>
<li><a href="java.applet.Applet.html">Applet
</a></li>
<li><a href="java.applet.Applet.AccessibleApplet.html">
AccessibleApplet</a></li>
</ul>
<ul id="java.rmi" title="java.rmi">
<li class="group">Interfaces</li>
<li><a href="java.rmi.Remote.html">
Remote</a></li>
<li class="group">Classes</li>
<li><a href="java.rmi.MarshalledObject.html">
MarshalledObject</a></li>
<li><a href="java.rmi.Naming.html">
Naming</a></li>
<li><a href="java.rmi.RMISecurityManager.html">
RMISecurityManager</a></li>
<li class="group">Exceptions</li>
<li><a href="java.rmi.AccessException.html">
AccessException</a></li>
<li><a href="java.rmi.AlreadyBoundException.html">
AlreadyBoundException</a></li>
<li><a href="java.rmi.ConnectException.html">
ConnectException</a></li>
<li><a href="java.rmi.ConnectIOException.html">
ConnectIOException</a></li>
<li><a href="java.rmi.MarshalException.html">
MarshalException</a></li>
<li><a href="java.rmi.NoSuchObjectException.html">
NoSuchObjectException</a></li>
<li><a href="java.rmi.NotBoundException.html">
NotBoundException</a></li>
<li><a href="java.rmi.RemoteException.html">
RemoteException</a></li>
<li><a href="java.rmi.RMISecurityException.html">
RMISecurityException</a></li>
<li><a href="java.rmi.ServerError.html">
ServerError</a></li>
<li><a href="java.rmi.ServerException.html">
ServerException</a></li>
<li><a href="java.rmi.ServerRuntimeException.html">
ServerRuntimeException</a></li>
<li><a href="java.rmi.StubNotFoundException.html">
StubNotFoundException</a></li>
<li><a href="java.rmi.UnexpectedException.html">
UnexpectedException</a></li>
<li><a href="java.rmi.UnknownHostException.html">
UnknownHostException</a></li>
<li><a href="java.rmi.UnmarshalException.html">
UnmarshalException</a></li>
</ul>

그림 8은 edge-to-edge 리스트를 사용하여 패키지를 선택할 수 있는 최상위 레벨 네비게이션을 보여준다.

그림 8. 진짜 아이폰 애플리케이션처럼 자바독 패지키 네비게이션하기
Array

그림 9는 아이폰 미리보기 모드로 java.rmi 패지키의 결과를 보여준다.

그림 9. Java.rmi 패키지에 있는 인터페이스, 클래스, 예외 네비게이션하기
Array

iDoc 의 세부 페이지에서는 아이폰의 또 다른 구조를 사용한다. 바로 둥근 사각형 리스트다. 이 리스트는 정보를 그룹핑할 때 유용한데 아이폰의 설정 창에서 볼 수 있다. 둥근 사각형 리스트를 사용해 메서드 시그너처와 매개변수 목록 그리고 예외를 구분할 것이다. V0.13에서 iUi는 둥근 사각형 리스트를 오직 폼 입력 용도로만 사용하도록 지원하고 있다. 따라서 정적인 텍스트를 출력할 때 이들 엘리먼트를 그냥 사용하면 틀에 맞지 않은 블록을 만들어 낸다. 그것들의 CSS를 확장하여 (Listing 2에 보이는) iDoc.css 파일을 만들고 정적인 텍스트를 둥근 사각형 리스트로 보여줄 textRow 엘리먼트를 추가한다.

Listing 2. 정적인 텍스트를 정확하게 보여주기 위한 커스텀 textRow CSS 확장

                
/* Adding a new row CSS style to iUi for displaying blocks of text */
.textRow {
position: relative;
border-bottom: 1px solid #999999;
-webkit-border-radius: 0;
text-align: right;
}

.textRow > p {
text-align: left;
margin: 5px 8px 5px 10px;
padding: 0px 0px 0px 0px;
}


fieldset > .textRow:last-child {
border-bottom: none !important;
}

Listing 3은 java.math.BigDecimal의 생성자 중 하나를 보여준다.

Listing 3. textRow 엘리먼트를 사용한 세부 페이지 HTML

                
<div id="java.math.BigDecimal(long,java.math.MathContext)" title="BigDecimal"
class="panel">
<fieldset>
<div class="textRow"><p><b>
public BigDecimal(long, MathContext)</b></p></div>
<div class="textRow"><p>Translates a
<code>long</code> into a
<code>BigDecimal</code>, with rounding according to the context settings.
The scale of the <code>BigDecimal</code>, before any rounding, is zero.
</p></div>
</fieldset>
<h2>Parameters</h2>
<fieldset>
<div class="textRow"><p><b>long val
</b>: <code>long</code> value to be converted
to <code>BigDecimal</code>.</p></div>
<div class="textRow"><p><b>MathContext mc
</b>: the context to use.</p></div>
</fieldset>
<h2>Throws</h2>
<fieldset>
<div class="textRow"><p><b>ArithmeticException
</b>: if the result is inexact but
the rounding mode is <code>UNNECESSARY</code>.</p></div>
</fieldset>
</div>

<fieldset> 태그에 있는 모든 것들이 textRow <div>를 사용해 둥근 사각형 안으로 들어갔다. <h2> 헤드 태그는 목록 위에서 그룹 제목을 보여준다. 그림 10은 결과 페이지를 보여준다.

그림 10. java.math.BigDecimal 생성자 자세히 보기 화면
Array

3단계 네비게이션과 세부 페이지 UI를 모두 끝냈다. iDoc은 사용자들이 특정 작업에 집중할 수 있게 해준다. iUi 프레임워크의 도움과 약간의 커스텀 CSS를 사용해 마치 진짜 아이폰 애플리케이션처럼 보이게 만들었다.


iDoc 개발하기

자, UI 디자인을 만들었고 이제 HTML 파일을 생성하는 코드를 만들어야 한다. 썬의 javadoc 명령어를 끼워 넣은 간단한 Doclet를 만들어보자. 이 예제는 자바 표준 java.* 패키지를 사용하지만 iDoc은 어떤 소스 코드로부터든지 자바독을 생성할 수 있다. OpenJDK(참고자료 참조)라, 공개적으로 사용 가능하며 GPL V2 라이선스를 사용하는 소스 코드를 사용해 자바독을 만들고 배포할 수 있다.

iDoc은 간단하게 패키지와 클래스를 순회하며 위에서 만든 형식대로 정적인 HTML 페이지를 출력하기 위한 메서드를 호출한다. Listing 4는 최종 세부 페이지를 출력하기 위한 메서드다.

Listing 4. 세부 페이지를 출력하기 위한 Doclet 코드

                
private void printDetail(PrintStream p, ProgramElementDoc doc,
String id, String name) {
divHeader(p, id, name, "panel");
textHeader(p, null);
textRow(p, getSignature(doc));
textRow(p, getCommentText(doc.commentText()));
textFooter(p);
if (doc instanceof ExecutableMemberDoc) {
printMethodDetail(p, (ExecutableMemberDoc) doc);
}
divFooter(p);
}

private void printMethodDetail(PrintStream p, ExecutableMemberDoc field) {
if (field.parameters().length > 0) {
textHeader(p, "Parameters");
for (int i=0; i<field.paramTags().length; i++) {
textRow(p, "<b>" + field.parameters()[i].typeName() + " "
+ field.paramTags()[i].parameterName()
+ "</b>: "
+ getCommentText(field.paramTags()[i].parameterComment()));
}
textFooter(p);
}
if (field.throwsTags().length > 0) {
textHeader(p, "Throws");
for (int i=0; i<field.throwsTags().length; i++) {
textRow(p, "<b>" + field.throwsTags()[i].exceptionName()
+ "</b>: "
+ getCommentText(field.throwsTags()[i].exceptionComment()));
}
textFooter(p);
}
}

이 코드는 일반화된 메서드인데 printDetail()는 클래스 설명, 필드, 생성자 그리고 메서드를 출력한다. 나머지 두 개의 타입은 ExecutableMemberDoc의 서브 클래스로 그것들의 매개변수와 던지는 예외에 대한 정보를 추가로 출력한다.






GZIP 압축

간 단하지만 효율적인 성능 팁을 소개하겠다. 바로 웹 서버에서 GZIP 압축을 가능케 하는 것이다. 현재 쓰이는 웹 서버는 대부분 이 옵션을 제공하며, 이를 사용하는 클라이언트로 보내기 전에 페이지를 압축한다. 아이폰의 사파리도 그런 클라이언트 중 하나다. GZIP 압축을 자동으로 지원한다. 간단하게 GZIP 압축을 자신의 웹 서버에서 쓸 수 있게 하면, 아이폰 사용자들은 좀더 빠른 다운로드 시간을 경험하게 될 것이다.


성능 이슈

Aptana 의 아이폰 미리보기 모드는 결과 파일에 대한 디버깅에 도움을 준다. 각 주기마다 빠른 클릭을 통해 설계했던 인터페이스와의 불일치를 찾아낼 수 있다. 하지만 미리보기 모드를 사용하는 것은 성능 문제를 일으킬지도 모른다. 대부분의 컴퓨터들은 아이폰의 620MHz ARM 프로세서보다 세 배 내지 다섯 배 정도 빠르다. 또한 사용자들은 느린 휴대폰 네트워크를 통해 페이지를 다운로드할 것이다. 따라서 자신의 애플리케이션을 실제 아이폰에서 동작시켜 보는 것이 중요하다.

아 이폰에서 iDoc을 시험해본 결과 매우 덩치 큰 HTML 파일을 출력할 때 흔들리는 듯한 화면과 성능 저하를 발견했다. 이것을 수정하기 위해 패키지와 클래스 이름을 네비게이션하는 메인 파일을 하나 만들고 별도의 파일로 각각의 클래스의 주석, 메서드에 대한 자세한 정보를 보여주는 페이지들을 만들었다(Listing 5). 비록 이런 과정을 통해 여러 개의 파일을 만들어 내게 되었지만, 각각의 파일 크기가 작기 때문에 애플리케이션이 매우 부드럽게 동작하게 되었다.

Listing 5. 각각의 패키지를 순회하는 Doclet 코드와 각각의 클래스마다 별도의 파일 만들기

                
out = new FileOutputStream(index);
p = new PrintStream(out);
printHeader(p);

PackageDoc[] packages = root.specifiedPackages();
Arrays.sort(packages);

printPackages(p, packages);

for (int i=0; i<packages.length; i++) {
printPackageDetail(p, packages[i]);
}
for (int i=0; i<packages.length; i++) {
ClassDoc[] classes = packages[i].allClasses();
Arrays.sort(classes);
for (int j=0; j<classes.length; j++) {
// Creating a separate file for each class.
PrintStream p2 = new PrintStream(new FileOutputStream(getFilename(classes[j])));
printClassDetail(p2, classes[j]);
p2.close();
}
}
printFooter(p);
p.close();


iDoc 사용하기

성 능 향상을 통해 iDoc은 이제 출시될 준비가 끝났다. OpenJDK에 있는 java.*와 javax.*에 있는 51개 패키지와 1304개 클래스에 대한 자바독을 만들, 모든 것을 웹 서버로 업로드한다. 16MB가 넘는 크기의 파일이지만 주요 네비게이션 페이지는 단지 112KB에 불과하며 각각의 클래스 자세히 보기 페이지는 평균적으로 13KB다. EDGE 네트워크를 사용하더라도 애플리케이션은 매우 잘 응답한다. 아이폰이 있다면 iDoc 사이트(참고자료 참조)에 접속해 보거나 iDoc을 다운로드하여 아이폰을 위한 자바독을 생성할 수 있다. 그림 11은 최종 애플리케이션을 보여준다.

그림 11. 아이폰을 위해 준비된 51개의 패키지 자바독
Array

iDoc의 잠재적인 확장기능으로는 자바 5 제네릭과 자바독 주석에 포함된 페이지 사이의 링크를 위한 태그를 더 잘 파악하는 것이다. iDoc의 기능 추가에 관심이 있다면 모든 소스 코드는 온라인에서 받을 수 있다(참고자료 참조).


아이폰 개발의 미래


2007 년 10월 Steve Jobs는 애플이 아이폰 SDK를 2008년 2월에 공개할 것을 발표했다. 글을 쓰고 있는 시점이 2007년 12월이기 때문에 아직 구체적인 것은 미지수이지만 SDK를 통해 사파리의 도움 없이 아이폰 바로 위에서 동작하는 애플리케이션을 작성할 수 있게 될 것이다. 아이폰 아키텍처 기반을 얻는 것은 Mac OS X과 비슷하게 개발 플랫폼이 코코아(Cocoa)와 오브젝티브-C가 된다는 것이다. 최근 소식에 의하면 애플의 한 중역은 서드파티 애플리케이션이 몇 가지 인증 절차를 거치도록 하는 것을 제안하기도 했다.

발전된 애니메이션, 그래픽 그리고 네트워크 접속을 사용하는 애플리케이션이 네이티브로 동작할 수 있는 이점을 얻을 것이다. 하지만 SDK가 배포되더라도 아이폰을 위한 웹 개발은 여전히 매력적인 위치에 있을 것이다. 웹 애플리케이션은 쉽게 만들고 간단하게 배포할 수 있다. Aptana와 iUi 같은 도구는 개발을 간편하게 해주며 웹 애플리케이션을 빨리 만들 수 있도록 해준다. iDoc을 통해 보았듯이 SDK를 기다릴 필요도 없다. 오늘 배운 도구를 사용해 아이폰 기능을 완전히 사용하며 진짜 같은 룩앤필을 가진 웹 애플리케이션을 만들 수 있다.

참고자료

교육

· iPhone Dev Center에는 Apple Developer Center에 있는 아이폰 웹 개발과 관련된 유용한 참조 문서들이 있다.

· iPhone Human Interface Guidelines 는 UI 개발 기준과 가이드라인 모음이다.

· OpenJDK는 썬의 오픈 소스 자바 개발 키트다.

· iDoc 시연 ?OpenJDK Javadoc?를 여러분의 아이폰에서 참조하라.

· "Eclipse 추천 도서 리스트 (한글)"를 확인하라.

· developerWorks의 모든 이클립스 기사를 확인하라.

· 이클립스가 처음이라면 developerWorks의 기사 "Eclipse Platform 시작하기 (한글)"를 읽고 이클립스의 탄생과 아키텍처 그리고 플러그인을 사용하여 어떻게 이클립스를 확장할 수 있는지 공부하라.

· IBM developerWorks의 Eclipse 프로젝트 리소스를 참조하고 여러분의 이클립스 기술을 확장하라.

· 소프트웨어 개발에 관한 흥미로운 인터뷰와 논의 소식을 듣기 원한다면 developerWorks 포드캐스트를 확인하라.

· developerWorks의 기술 행사와 웹 캐스트에서 최신 정보를 접하라.

· developerWorks On demand demos에서 IBM과 오픈 소스 기술 그리고 제품에 대한 정보를 무료로 보고 익힐 수 있다.

· IBM 오픈 소스 개발과 관련하여 앞으로 개최될 컨퍼런스, 트레이드 쇼, 웹 캐스트 그리고 다른 행사들을 확인하라.

· 한국 developerWorks 오픈 소스 존을 방문하여 방대한 how-to 정보, 도구, 프로젝트 업데이트를 확인하여 오픈 소스 기술을 활용한 개발에 도움을 얻고 IBM의 제품들을 활용하라.

제품 기술 얻기

· 최신 버전의 Aptana 이클립스 플러그인을 다운로드하라.

· 최신 버전의 iUi 프레임워크를 다운로드하라.

· 최신 버전의 iDoc 생성기 소스 코드를 다운로드하라.

· IBM alphaWorks에서 최신 이클립스 기술 다운로드를 확인하라.

· 이클립스 재단에서 이클립스 플랫폼과 기타 프로젝트를 확인하라.

· IBM 제품 평가판을 다운로드해 DB2?, Lotus?, Rational?, Tivoli?, 그리고 WebSphere? 제품군의 애플리케이션 개발 도구와 미들웨어 제품을 사용해 보라.

· 여러분의 다음 오픈 소스 개발 프로젝트를 다운로드나 DVD로 구할 수 있는 IBM 시험판 소프트웨어를 사용하여 혁신하라.

토론

· 이클립스에 대한 질문이 있다면 Eclipse Platform newsgroups를 제일 먼저 방문하라(이것을 선택하면 여러분의 기본 유즈넷 뉴스 리더 애플리케이션이 동작하고 eclipse.platform을 연다).

· Eclipse newsgroups는 이클립스 확장과 사용에 관해 많은 자료를 가지고 있다.

· developerWorks 블로그에 참여하고 developerWorks 커뮤니티에서 활동하라.

필자소개

Adam Houghton은 SAS Advanced Computing Lab에서 선임 소프트웨어 개발자로 있으며 자바와 관련된 모든 것을 전문으로 하고 있다.

출처 : http://blog.naver.com/lonlykia/36515501

내 USB에 PDA를 넣고 다니다가 아무 피씨에서나 사용^^

MojoPac이 유행이긴 해도 ... 이건 Portable PDA / USB

참조한곳 ::

원저자의 홈피 : http://www.furrygoat.com/2005/09/portable_ce_20.html

여긴 좀더 재밌는게 http://www.furrygoat.com/embedded/

Array Array

한글판과 영문판

(영문판은 DeviceEmulator050419.msi을 설치하면 나온다)

  PPC_2003_SE_WWE_ARMv4.bin

  SP_2003_SE_WWE_ARMv4.bin (스마트 폰)

자 시작!!!

1. 설치할 폴더를 PC 하드에 만든다. 본 예에선 DeviceEmulator로 만듬.

그리고 그밑에 다음 폴더를 추가로 만듬.

OS_ROM_File  (OS 이미지 화일용 폴더)

Apps               (PDA에서 외부 Storage Card로 인식하고 PC <--> PDA 간 화일교환)

State              (종료시 PDA상태 저장용)

Array

2. Device_Emulator_050419.msi 를 다운한다.

3. 설치시작 --

다운 받은 DeviceEmulator050419.msi를 설치한다.

더불클릭으로 하면 안됨. 아래처럼 할것

윈도 : 시작 - 실행창 - cmd ( 엔터)

      msiexec /a DeviceEmulator050419.msi (엔터)

풀어놓을 위치를 물어 보면, 아까 만든 폴더인 DeviceEmulator를 선택!

4.추가 보조 화일 다운 받는다.

http://www.jsifaq.com/docs/files/76011/snetcfg.zip

http://www.furrygoat.com/Software/pce2.cmd.txt

이들을 압축화일은 DeviceEmulator폴더에 압축풀어 넣고 pce2.cmd.txt는 pce2.cmd로 이름 변경하여 넣는다.

5. pce2.cmd 수정 (Emulator 롬 이미지와 화면크기)

롬이미지의 화일의 상대경로만 적는다. 즉 DeviceEmulator폴더 밑의 경로만(화일명 포함) 여기선 oS_ROM_fileOS_ROM.bin

Array

화면 크기 640x480x16이 기본이고 이대로 사용해되 되나,

     PDA뽀다구는 240x320x16으로 수정하면 ^^됨.

Array

6. 지금 까지가 진행된 모습.

Array

7.한글 PPC2003 이미지 얻기.

http://www.microsoft.com/downloads/details.aspx?familyid=EEC33AE3-C129-4C25-ABAA-18E8E842178F&displaylang=en

이링크에서 "continue"를 누르면 됨. 여기서 한국어판을 다운 받는다

이름이 Windows Mobile 5.0 Emulator Images for Pocket PC - KOR.msi 이고

크기는 100메가정도.

공백없는 화일명으로 변경한다 (msiexec 의 오류때문) image.msi로 변경.

더불클릭으로 하면 안됨, 반드시 아래와 같이 따라할것 !!!!!

윈도 : 시작 - 실행창 - cmd ( 엔터)

     msiexec /a image.msi (엔터)   [암호 물어보걸랑 숫자 "1"만 쭉 넣는다]

그러면 Windows Mobile 5.0 Emulator Images for Pocket PC - KOR라는 폴더가 생기고 그 아래 찾아보면 다음과 같은 이미지 화일 (확장자가 *.bin) 4개를 얻는다.

Array

GSM은 GPS버전, VR은 전화기(?), VGA는 화면 크기가 640x480인것이다.

여기서 PPC_KOR.bin을 OS_ROM.bin로 이름을 변경하여

DeviceEmulator 폴더 아래의 OS_ROM_file 폴더에 복사해 넣는다.

8.실행하기 :

DeviceEmulator 폴더 아래의 pce2.cmd 더불클릭 !!

시스템 성능에 따라 약간의 시간이 경과한후 PDA 나타난다..

혹, 네트웍 관련 어쩌구하는 에러나오면 무시!

참고로, 한글판이나 Windows Mobile 5.0는 속도가 좀 느리다

노스우드 펜2.4에서도 좀 버벅 거리는 듯...

실행모습들 ...

Array Array

화면 크기가 640*480인것 :한글 PPC2003 실행

Array

(그냥 옆으로 퍼진 화면일 뿐...)

9. USB스틱에 DeviceEmulator 폴더 내용을 모두 복사한후 거기서

pce2.cmd 실행해도 !

추신: 본문 펌 허가로 변경하였습니다. 댓글남기시고 퍼가심 되겠슴다

댓글은 스팸때문에 로긴한 분만 허용입니다 ^^

추신 2; DeviceEmulator050419.msi 화일을 받지 못하시는 분들을 위해 필요없는 롬 이미지를 제외한 응용프로그램 폴더만 압축해서 올려 놓았습니다. 압축풀어 사용하시면 될듯 (시험해보지 않았으므로 ...) 합니다. 이후 위절차중 "7"번 부터 따라하시면됩니다 .

추신 3: USB PDA에서 인터넷 접속 :  http://blog.naver.com/lonlykia/36528014

추신 4: ActiveSync 사용법 추가 : http://blog.naver.com/lonlykia/38368283

" 추신5" : 내용이 헷갈리시거나 설치가 곤란한 분은 투데이스에 제글을 올리신 분이 모든 과정을 완료한 작업 완료화일을 올려 두셨군요. 이걸 받아서 압축 풀고 실행하시면 위의 복잡한 과정 필요없이 됩니다. 아래 링크에서 다운 받으시기 바랍니다

===================

혹시 사용해 보고 싶다면
http://ftp6.ohpy.com/up/elbbs/2007/06/02/50097/1180750372/pocket.zip
http://ftp6.ohpy.com/up/elbbs/2007/06/02/50097/1180750641/pocket.z01
다운 반아 압축을 풀고 start.cmd 실행하세요.
=======================

  1. JihooLee 2009.10.02 14:11 신고

    DeviceEmulator050419.msi 파일을 다시 올려주세요!!!

ARM과 파워PC에 기반한 임베디드 프로그래밍 최적화 기법

박재호 | jhrogue@yahoo.co.kr

프로그래밍 분야에서 ‘최적화’만큼 다양한 의미로 사용되는 단어도 드물 것이다. 최적화란 개발 목적과 사용하는 언어, 애플리케이션의 특징 등에 따라 모두 다른 의미로 사용되는 탓이다. 다만 그 핵심만은 대부분 비슷하다. 프로그래밍 분야의 최적화는 요구 사항을 충족시키지 못하는 소프트웨어를 개선해서 원하는 결과를 얻도록 하는 작업이라는 점에서 동일하기 때문이다. 한마디로 개발자나 환경에 따라 최적화의 의미는 제각기 달라지지만, 최적화의 중심에는 ‘속도’와 ‘크기’가 있다.
하지만 이 또한 시대가 바뀜에 따라 조금씩 달라지고 있다. 시대가 바뀌면서 CPU의 성능이 좋아지고 메모리의 용량 또한 늘어나는 덕에 정량적인 ‘속도’와 ‘크기’가 차지하는 의미가 작아지는 탓이다. 대신 ‘사용 편의성’과 ‘즐거운 경험’ 같은 요소가 중요해지고 있다.
이런 상황은 어디까지나 프로그래밍 전반에 대한 것일 뿐 임베디드 소프트웨어는 좀 더 복잡한 제약 조건하에서 개발되는 탓에 여전히 속도와 크기가 중요한 역할을 차지한다. 일반 데스크톱 PC나 워크스테이션과는 달리 임베디드 장비에 들어가는 CPU는 성능도 떨어지고 메모리(램이나 플래시) 용량도 적다. 때문에 수행 속도, 반응 속도, 실시간 성능, 실행 전 펌웨어 이미지 크기와 실행 중 프로세스 이미지 크기를 확보하기 위해 적잖은 공을 들여야 한다. 물론 속도도 빠르면서 이미지 크기도 작은 요구 사항을 동시에 충족할 수는 없다. 어느 한쪽을 희생해서 다른 한쪽을 살려야 한다. 이런 과정에서 특정 하드웨어에 대해 얼마나 균형을 잘 맞추느냐에 따라 임베디드 소프트웨어 개발 승패가 판가름 나는 경우도 있다.
5부는 이런 배경을 염두에 두고 임베디드 분야를 중심으로 널리 사용되는 ARM(Advanced RISC Machine)과 파워PC 계열 CPU를 토대로 C와 어셈블리 언어 특성을 활용해서 효과적인 소프트웨어를 제작하는 방법에 대해 알아본다. 여기서 주의 사항이 하나 있는데, 워낙 변수가 많은 알고리즘과 특정 컴파일러 버전에 따른 최적화 특성은 설명에서 제외한다.

최적화의 기초와 잘못된 상식

세계 최초의 64비트 CPU로 등장한 알파(21x64 시리즈)를 설계할 당시에 핵심적인 팀을 네 개로 나누었는데, 그 중에 소프트웨어 팀이 하나 끼어있었다. 놀랍게도 이 팀이 담당한 업무는 바로 알파에 최적화된 컴파일러를 제작하는 것이었다. 높은 클럭 주파수로 움직이는 CPU를 제작하는 과정에서 조금이라도 하드웨어의 복잡성을 줄이기 위해 최대한 단순하게 CPU를 설계했다. 원하는 성능을 얻기 위한 노력을 소프트웨어(즉 컴파일러)로 떠넘긴 것이다. 이런 변화는 칩 제조사가 가장 골머리를 앓는 부분이 하드웨어 부문에서 소프트웨어 부문으로 바뀌어 버린 역사적인 전환점으로 생각해도 될 정도이다.
주 로 CISC(Complex Instruction Set Computer) 기반으로 설계된 CPU를 다루던 프로그래머는 손으로 최적화한 어셈블리 코드가 월등히 뛰어나다고 생각하기 쉽다. 하지만, RISC(Re duced Instruction Set Computer) 환경이나 RISC와 CISC를 결합한 CPU에서는 그다지 큰 차이가 나지 않는다. 어떤 경우에는 컴파일러가 사람보다 더 우수한 기계어 코드를 생성하기도 한다. 연구에 따르면 프로그램을 작성하는 데 걸린 시간은 프로그래밍 언어와 상관없이 프로그램을 작성한 행의 수에 비례한다. 그러므로 그 만큼 많은 행을 담고 있는 어셈블리어 프로그램은 생산성이 낮을 수밖에 없는데, 최종 결과물마저 C 언어와 같은 고급 프로그래밍 언어와 비슷하다면 똑 같은 일을 하기 위해 시간과 노력만 낭비한 셈이 된다.
성능이 의심스러울 경우 수동 최적화를 하기 이전에 우선 컴파일러가 생성한 코드가 정말 최적인지 아닌지를 가려내야 하며, 현재 상태에서 얼마나 개선이 가능한지 평가해야 한다. 또한 성능이 중요한 프로그램을 작성할 경우 아키텍처에 맞춰 컴파일러가 해당 알고리즘을 위한 최적의 코드를 생성하도록 프로그램을 작성해야 한다. 컴파일러가 알아서 최적화된 코드를 생성하기를 기대해서는 안 된다는 말이다.

구체적인 최적화 기법 소개

자 그럼 이제부터 C 프로그래밍 언어를 활용한 본격적인 최적화 기법을 살펴보기로 하자. 우선 ABI(Application Binary Interface)를 사용한 최적화 기법부터 소개한다. 여기에서 먼저 짚고 넘어가야 할 것은 컴파일러가 좋아하는 방식으로 프로그램을 작성해야 최적화를 달성할 수 있다는 점이다. 그럼 어떻게 해야 컴파일러가 좋아하는 방식의 프로그램이 되는 것일까? 복잡한 어셈블리어로 코딩을 하지 않더라도 프로그램 작성 과정에서 조금만 공을 들이면 그럴듯한 효과를 얻을 수 있는 규칙들이 있다. 여기에서는 가장 범용적으로 사용할 수 있는 몇 가지 기본 규칙 들에 대해 알아보자.

ABI와 최적화
ABI(Application Binary Interface)는 응용 프로그램과 운영체제, 응용 프로그램과 라이브러리 사이에 필요한 저 수준 인터페이스를 정의한다. 또, 목적 파일과 관련되어 있어 원시 코드 컴파일 과정에 개입하는 API(Application Programming Interface)보다 저수준이다. ABI는 아키텍처와 운영체제마다 조금씩 차이가 있으며, 인수 전달 방법과 반환 값 전달 방법을 포함한 함수 호출 규약을 정의한다.
고 수준에서 생각해보면 함수를 정의하는 이유는 공통된 부분을 한 곳에 모아서 중복이 되지 않도록 만들어 코드의 유지 보수성을 높이는데 있다. 저수준에서의 함수는 코드의 크기를 줄이면서 연관된 코드를 한 곳에 모아 지역성을 높임으로써 캐시 적중률을 높이는 과정에 도움을 준다. 그렇다면 만일 함수 본체 길이가 길어서 컴파일러가 함수 본체를 호출한 곳에 인라인으로 확장하지 못하여 추가적인 속력 개선이 필요하다면 어떻게 해야 할까? 이 때 ABI 규칙을 알고 있다면 상당히 유리하다. 앞서 ABI가 아키텍처마다 다르다고 했으므로 여기서는 ARM과 파워PC로 나누어 생각해보자.

● ARM
ARM ABI 정의 규칙인 APCS(ARM Procedure Standard Call)에 따르면 컴파일러는 함수로 넘기는 인수를 담는 레지스터네 개를(a1~a4) 할당한다. 즉 표준 C로 함수를 선언할 때 인수를 네 개 이하로 유지할 경우 인수를 넘기기 위해 스택을 사용하지 않고 레지스터만 사용하게 되므로 상당한 속도 개선의 효과를 얻을 수 있다.

● 파워PC
파워PC 32비트 ABI에 따르면 일반 변수를 위해 레지스터 R3에서 R10번까지를 사용하고, 부동소수점 변수를 위해 F1에서 F8까지를 사용한다. 따라서 표준 C로 함수를 선언할 때 인수를 여덟 개 이하로 유지한다면 속도를 개선할 수 있다.
물론 인수를 레지스터로 넘기는 방식이 늘 가능한 것은 아니다. 예를 들어, 가변 길이 인수(va_arg)를 사용할 경우에는 어쩔 수 없이 스택에 인수를 집어넣어야 한다. 따라서 속도 개선이 필요하다면 가변 길이 인수를 고정 길이 인수로 변경해야 한다. 또한 레지스터 길이를 초과하는 경우(예: 구조체를 인수로 넘긴다)에도 레지스터와 스택으로 나뉘어져서 인수를 전달하게 되므로 이 점도 고려 대상에 넣어야 한다.
함수 호출 과정에서 레지스터를 사용한다고 해서 크게 속도가 높아지지 않을 것처럼 보일지도 모른다. 하지만 함수 호출이 수십만 번에 걸쳐 일어난다고 가정할 때 코드 ‘크기’ 최적화 때문에 인라인이나 매크로가 불가능한 상황에서 속도 최적화를 가장 먼저 달성하는 좋은 수단이 될 수 있다.

다른 CPU에서는 어떻게 함수 호출 과정에서 최적화 작업을 수행하나?
비단 ARM이나 파워PC 뿐만 아니라 MIPS도 인수 전달에 레지스터 네 개를 사용하며, x86_64도 인수 전달에 레지스터 여섯 개를 사용한다. x86의 경우 ABI 수준에서는 기본적으로 스택만 사용해서 인수를 전달하도록 정해져 있다. 물론 x86에서도 컴파일러에 따라 레지스터 두세 개를 사용해서 조금이라도 속도를 높이는 옵션이 존재하는 경우도 있지만 표준은 아니다. 예를 들어 마이크로소프트 비주얼 C++은 인수 전달에 레지스터 두 개를 사용하며, 볼랜드 C++는 세 개, 왓콤 C는 네 개를 사용한다.
레 지스터가 적은 x86의 경우에는 스택 프레임 포인터를 저장하는 EBP(Base Stack Pointer)를 다른 목적으로 활용하도록 컴파일러가 ESP 레지스터를 교묘하게 조작하는 방법을 사용하기도 한다. 일례로 gcc의 경우에는 -fomit-frame-pointer 옵션을 붙이거나 ?O2 최적화 옵션을 붙일 경우 프레임 포인터를 사용하지 않는다.

루프 최적화
구조화된 프로그래밍 기법에서 사용하는 주요 요소로 판단과 반복이 무척 중요하다. 우선 반복을 위한 루프 최적화부터 살펴보기로 하자.

● 불필요한 반복 제거
가장 기본적인 루프 최적화 기법으로 불필요한 반복을 제거하는 기법이 있다. 3~5회 정도만 반복하고 끝나는 경우 루프를 풀어서 사용한다면 크기를 희생해서 성능을 높일 수 있다. 하지만 코드 크기가 증가할 경우 캐시 적중률이 낮아져서 성능을 높이기는커녕 성능을 떨어트리는 원인이 될 수도 있으니, 반드시 루프 내에 들어있는 코드 크기가 작을 경우에만 적용해야 한다.
루프를 완전히 풀지 않고 언롤링이라는 기법을 사용해서 크기와 성능의 균형을 맞추는 방법도 있다. ARM 플랫폼을 예로 들어보자면 ARM7이나 ARM9 프로세서에서 뺄셈을 처리하는 데 한 사이클, 분기를 처리하는 데 세 사이클이 소요된다. 전체적으로 루프를 한번 도는 데에 네 사이클이 필요한 셈이다. 이럴 경우에 루프문의 몸체를 여러 차례 반복해서 같은 비율만큼 반복수를 줄이면 성능을 높일 수 있다. <리스트 1>과 <리스트 2>를 비교해 보자.

<리스트 1> 일반적인 방법의 예제
int checksum (int *data, unsigned int count)
{
    int sum = 0;
    for (; count != 0; count--) {
        sum += (*data++);
    }
    return sum;
}

<리스트 2> 언롤링 기법으로 작성된 예제
int checksum_unrolling(int *data, unsigned int count)
{
    int sum = 0;
    do {
        sum += (*data++);
        sum += (*data++);
        sum += (*data++);
        sum += (*data++);
    } while (count != 0);
    return sum;
}

<리스트 1>은 일반적인 방법으로 작성했으며, <리스트 2>는 언롤링 기법으로 작성했다. 언롤링 기법을 사용할 경우 루프 반복 회수가 4 * count 사이클에서 count 사이클로 줄어들기 때문에 상당한 이득을 얻을 수 있다. 물론 언롤링 양은 무작정 늘여서는 안 된다. 코드 크기가 커지게 되면 캐시 적중률이 떨어져 사이클을 절약해서 얻는 장점을 모두 상쇄시켜버리는 탓이다. 배열 크기가 언롤링 양에 비례할 경우, 가장 높은 성능을 달성하기 때문에 만일 배열 크기가 언롤링 양의 배수로 떨어지지 않으면 배수 크기만큼만 언롤링 루프로 만들고 나머지는 루프 바깥에서 언롤링하면 된다. 결국 배열 크기를 4나 8 배수로 정렬시킬 경우 코드를 어지럽히지 않고도 루프를 2, 4, 8배로 쉽게 언롤링할 수 있는 것이다.

● 루프 결합
루프는 아키텍처를 불문하고 값비싼 연산이 필요하므로 여러 루프가 있을 경우 하나로 결합하는 편이 성능면에서 월등히 유리하다. <리스트 3>과 <리스트 4>를 살펴보자.

<리스트 3> 루프를 두 번 돌리는 예제
void foo(int count, int *x, int *y)
{
    int b;
    for (b = 0; b < count; b++) {
        x[b] = b;
    }
    for (b = 0; b < count; b++) {
        y[b] = b;
    }
}

<리스트 4> 루프를 한 번 돌리는 예제
void bar(int count, int *x, int *y)
{
    int b;
    for (b = 0; b < count; b++) {
        x[b] = b;
        y[b] = b;
    }
}

예제에서 알 수 있듯이 <리스트 3>의 foo는 루프를 두 번 돌리는 반면에 <리스트 4>의 bar는 한 번만 돌린다. 이럴 경우 루프 연산에 따른 사이클을 절약할 수 있을 뿐 아니라 경우에 따라서는 캐시를 좀 더 효과적으로 사용하여 성능을 높일 수 있다.

● 불변 코드 분리
코드 내부에서 바뀌지 않은 부분은 코드 바깥으로 분리시킴으로써 반복적인 계산을 막을 수 있다. 아주 단순한 논리인 듯하지만 조금만 신경 쓰면 상당한 효과를 얻을 수 있다. 비단 strlen 같은 함수 호출뿐만이 아니라 사칙연산과 같은 경우에도 고정된 상수 값을 루프 내부에서 매번 계산하는 대신, 변수를 하나 잡아 미리 계산한 뒤에 루프로 진입하여 상당한 개선 효과를 얻을 수 있다. 가독성이나 기타 이유로 몸체 크기가 작은 함수를 호출해야 한다면 매크로 확장이나 인라인을 고려하자.

<리스트 5> 다중 함수 호출 예제
void foo(const char *str)
{
    int i;
    for (i = 0; i < strlen(str); i++) {
        …
    }
}

<리스트 6> 단일 함수 호출 예제
void bar(const char *str)
{
    int i;
    int len = strlen(str);
    for (i = 0; i < len; i++) {
        …
    }
}

두 리스트 중 <리스트 6>의 bar은 매번 strlen 함수를 호출하는 foo와 달리 한번만 호출한다. <리스트 5>의 foo는 str의 길이가 길어질수록 눈에 띄게 속력이 느려지지만 bar는 항상 고정 시각에 루프를 돌릴 수 있다.

● 루프 증가를 감소로 대체
거의 대부분의 아키텍처에서는 0에 도달할 때 ZERO 플래그를 재설정한다. 때문에 줄어든 변수를 명시적으로 0과 비교할 필요가 없다. 이런 방법을 응용하면 for 루프 속도를 높이는 한 가지 힌트를 찾을 수 있다.

<리스트 7> 루프 증가 예제
void checksum_inc(int *data)
{
    unsigned int i;
    int sum = 0;
    for (i = 0; i < 64; i++) {
        sum += *(data++);
    }
    return sum;
}

<리스트 8> 루프 감소 예제
void checksum_dec(int *data)
{
    unsigned int i;
    int sum = 0;
    for (i = 64; i != 0; i--) {
        sum += *(data++);
    }
    return sum;
}

논리적으로는 큰 차이가 없어 보인다. 하지만 두 코드를 어셈블한 내용을 살펴보면 이야기가 달라진다. ARM의 경우를 예로 들지만 다른 아키텍처도 거의 유사하다.

<리스트 9> 루프 증가의 어셈블 예
checksum_inc
MOV r2, r0 r2 = data
MOV r0, #0 sum = 0
MOV r1, #0 i = 0
cheksum_inc_loop
LDR r3, [r2], #4 r3 = *(data++)
ADD r1, r1, #1 i++
CMP r1, #0x40 i와 0x40(십진수 64)를 비교
ADD r0, r3, r0 sum += r3
BCC checksum_inc_loop; (i < 64) 이면 loop 반복
MOV pc, r14 sum 리턴

<리스트 10> 루프 감소의 어셈블 예
checksum_dec
MOV r2, r0 r2 = data
MOV r0, #0 sum = 0
MOV r1, #0x40 i = 64
cheksum_dec_loop
LDR r3, [r2], #4 r3 = *(data++)
SUBS r1, r1, #1 i-- (자동 플래그 갱신)
ADD r0, r3, r0 sum += r3
BNE checksum_inc_loop; (i != 0) 이면 loop 반복
MOV pc, r14 sum 리턴

checksum_dec와 checksum_inc를 비교해보면(밑줄 그은 곳을 참조) 플래그 설정을 위한 CMP 명령이 하나 줄어들었다는 사실을 발견할 수 있다.

● 분기 제거
루프문에 분기가 들어가면 성능이 떨어진다. 때문에 루프 내에서 분기를 어떻게 제거해야 할 지 고민해야 한다. 만약 최적화 컴파일러라는 것이 있어서 이런 일들을 개발자가 일일이 하지 않는다면 몰라도 일단 아직은 모두 수작업으로 해야 하는 일들이다. <리스트 11>을 살펴보자.

<리스트 11> 분기가 있는 루프문
do
{
    printf("첫번째 출력n");
    if (--a < 0) break;
    printf("두번째 출력n");
} while (1);

코드 논리상으로는 큰 문제가 없어 보인다. 하지만 <리스트 11>을 <리스트 12>와 같이 수정하면 루프문 안에서 조건문을 제거할 수 있어 성능을 향상시킬 수 있다.

<리스트 12> <리스트 11>에서 분기가 제거된 코드
printf("첫번째 출력n");
a--;
if (a>=0) {
    do
    {
        printf("두번째 출력n");
        printf("첫번째 출력n");
    } while (--a<0);
}

이번에는 <리스트 1>의 checksum 함수를 <리스트 13>과 같이 고쳐보자.

<리스트 13> <리스트 1>의 수정
int checksum_dowhile(int *data, unsigned int count)
{
    int sum = 0;
    do {
        sum += (*data++);
    } while (--count != 0);
    return sum;
}

코드를 이렇게 고치면 역시 처음에 count와 0을 비교하는 부분이 빠져서 두 사이클(비교에 이은 분기)을 절약할 수 있다. 물론 언롤링 기법에 비해 성능이 떨어지긴 하지만 코드 크기를 유지한 상태에서 처리 속도도 어느 정도 개선할 수 있으니 두 마리 토끼를 모두 잡아야 하는 경우에 유용하게 쓸 수 있다.

왜 이렇게 루프 최적화에 목숨을 거나?
다른 최적화 기법도 많은 상황에서 루프 최적화에 상당한 지면을 할애해서 다양한 방법을 소개하는 이유는 우리 주변에서 생각보다 루프와 관련된 성능 저하가 많이 일어나기 때문이다. 임베디드 장비를 개발할 때 시스템 속도를 개선하기 위해 사방팔방으로 뛰어다녀 보니 결국 루프 횟수를 줄이거나, 루프 하나를 돌 때 단 몇 사이클이라도 아끼는 방법으로 귀결됨을 여러 차례 목격했다.
지금도 기억나는 가장 극적인 성능 개선은 수천 번에서 수만 번을 반복하는 루프 내부의 불변식을 매크로로 정의해서 확장했을 때 성능이 자그마치 2배에서 10배까지 향상되었을 때였다. 앞서 strlen과 같은 값비싼 함수를 루프 내부에 넣은 예제를 보고 웃고 넘길지 모르겠지만, 주변 코드를 살펴보면 의외로 이런 사소하다고 보면 사소하지만 성능에 치명타를 입히는 코드가 많다. 최적화가 필요하다면 가장 먼저 루프와 루프 내부에 들어있는 분기문을 집중 공략하기 바란다.

분기 최적화
루프 최적화에 이어 이번에는 분기 최적화에 대해 알아보자. 루프 최적화는 조금만 손을 보면 상당한 성능 개선을 이룰 수 있는 반면 분기 최적화는 구현도 어렵고 성능 개선 효과도 미미하다. 하지만 몇 가지 규칙을 알고 있다면 프로그램 작성 과정에서 자연스럽게 성능을 높이는 출발점이라는 점을 염두에 둔다면 반드시 관심을 가져야 할 기법이다.

● 기본 switch ~ case 문 최적화
프로그램을 작성하다 보면 switch ~ case 문을 자주 사용하게 된다. 하지만 switch ~ case 문은 실행 중에 수많은 조건을 판별해서 분기해야 하기 때문에 CPU 입장에서는 상당히 난감한 구문이라고 보면 틀림없다. <리스트 14>를 살펴보자.

<리스트 14> switch ~ case 문 예제
switch (x) {
    case 10: case 12: case 14: case 16: case 20:
    foobar();
    break;
}

<리스트 14>와 같은 코드를 작성했을 경우 컴파일러는 10, 12, 14, 16, 20일 경우를 일일이 판단해야 하는 탓에 상당한 어려움을 겪는다. 파워PC의 어셈블리 코드인 <리스트 15>를 보면 <리스트 14> 코드가 얼마나 복잡하게 만들어지는지 알 수 있다.

<리스트 15> <리스트 14>의 파워PC 어셈블리 코드
lwz R3,x # x를 R3으로
cmpwi cr0,R3,10
beq cr0,lab10 # if (x == 10) goto lab10
cmpwi cr1,R3,12
beq cr1,lab12 # else if (x == 12) goto lab12
cmpwi cr5,R3,14
beq cr5,lab14 # else if (x == 14) goto lab14
cmpwi cr6,R3,16
beq cr6,lab16 # else if (x == 16) goto lab16
cmpwi cr7,R3,18
beq cr7,lab18 # else if (x == 18) goto lab18
cmpwi cr0,R3,20
beq cr0,lab20 # else if (x == 20) goto lab20
...
lab10:
lab12:
lab14:
lab16:
lab18:
lab20:
# foobar 호출

하지만 아주 간단한 수정만 한 <리스트 16>을 어셈블리 코드로 만들면 전혀 다른 결과를 얻을 수 있다.

<리스트 16> 수정된 switch ~ case 문 예제
switch (x) {
    case 10: case 11: case 13: case 14: case 15:
    foobar();
    break;
}
< 리스트 16>을 어셈블리 코드로 만들면 <리스트 14>때 보다 코드의 양도 훨씬 적어지고 판단 횟수도 줄어드는 것을 확인할 수 있다. 별로 다르지 않은 코드지만 그 결과는 큰 차이를 나타내는 것이다. 그리고 이 차이의 중심에는 컴파일러가 좋아하는 방법으로 프로그램을 작성한다는 규칙이 있다.

<리스트 17> <리스트 16>의 어셈블리 코드
lwz R3,x # x를 R3으로
subic R4,R3,10 # tmp = (x - min)
cmplwi cr3,R4,5 # 논리 비교 (tmp, max-min)
bgt cr3,out # if tmp < 0 또는 tmp > 5,
# x 는범위 [min,max] 바깥
# foobar 호출
out:

● 고급 switch ~ case 문 최적화
앞에서는 아주 기초적인 구성의 switch ~ case 문의 최적화 방법에 대해 알아보았다. 이번에는 조금 더 복잡한 형태의 Switch ~ case 문을 이용해서 최적화 하는 방법에 대해 알아보자.

<리스트 18> 고급 switch ~ case 문 예제
switch(x){
    case 0: code_for_case_0;
    case 1: code_for_case_1;
    case 2: code_for_case_2;
    case 3: code_for_case_3;
    case 4: code_for_case_4;
    case 5: code_for_case_5;
    case 6: code_for_case_6
    case 7: code_for_case_7
    default: code_for_case_d;
}

감이 있는 개발자라면 <리스트 18>과 같은 코드가 테이블 검색법을 사용할 경우 제격이라는 생각이 들지 모르겠다. 이번에는 파워PC 어셈블리어와 ARM 어셈블리어를 동시에 제시해서 비교해보기로 하자. 먼저 <리스트 19>를 통해 테이블 검색 기법을 사용하는 파워PC부터 살펴보자.

<리스트 19> <리스트 18>의 파워PC 어셈블리 코드
lwz R4,x # x를 R4로
lwz R7,$TABLE # TABLE 주소를 R7로
slwi R5,R4,2 # 4를 곱함 (테이블 엔트리 당 4 바이트)
lwzx R3,R7,R5 # TABLE[x]를 R3로
mtctr R3 # 카운트 레지스터 적재
bctr # 카운트 레지스터 내용으로 분기

<리스트 20>은 테이블 검색 기법을 활용하는 ARM 어셈블리어의 코드이다. code_for_case_?를 담은 TABLE을 정의하고, 오프셋을 계산해서 바로 프로그램 카운터를 적재하는 방법을 사용할 경우 최적화를 달성할 수 있다.

<리스트 20> <리스트 18>의 ARM 어셈블리 코드
x RN 0
CMP x, #8
ADDLT pc, pc, x, LSL#2
B code_for_case_d
B code_for_case_0
B code_for_case_1
B code_for_case_2
B code_for_case_3
B code_for_case_4
B code_for_case_5

<리스트 18>과 같은 방식은 아주 빠르게 실행되기 때문에 switch 문을 사용하더라도 비교에 따르는 부하가 거의 없다. 물론 최적화 컴파일러 종류나 문맥에 따라 범위 비교나 테이블 방식으로 코드를 생성하지 못할 수도 있다. 반면에 무작의 case처럼 100% 불가능한 상황이 아님에 주목하자. ‘할 수 없다’와 ‘할 수 있다’는 하늘과 땅 차이기 때문이다.

고급 최적화 기법: ARM CPU 아키텍처에 밀접한 memcpy 루틴
지금까지는 구조화 프로그래밍에서 가장 많이 쓰이는 요소인 반복과 분기에 대한 C 프로그래밍 최적화 방안에 대해 알아보았다. 그럼, CPU 아키텍처에 밀접한 방식으로 어셈블리 프로그램을 작성해야 하는 경우는 어떨까? 물론 이 경우에도 최적화를 위해 사용할 수 있는 기법들이 있다. 그 중 가장 대표적인 것이 바로 메모리 관련 함수를 작성할 때이다. 실제로 최적화된 메모리 관련 라이브러리는 대부분 어셈블리 언어로 작성되어 있다. 리눅스 커널 내부에서도 자주 사용하는 메모리 함수는 모두 아키텍처 별로 어셈블리어를 사용한다. 리눅스 커널 코드를 받아와서 arch/아키텍처/lib 아래를 보면 아키텍처 별 최적화 기법을 총정리한 어셈블리 코드를 확인할 수 있다.

논리 트리와 해시를 사용한 수동 switch ~ case 문 제작
case 문에 들어가는 값이 연속적인 고정 범위일 경우에는 컴파일러 차원에서 어느 정도 최적화가 가능하다. 하지만 일반적인 switch ~ case 문에서는 어떻게 할까? 크게 두 가지 방법을 생각해볼 수 있다. 하나는 선형 스위치 트리에서 벗어나 깊이가 얕은 트리를 구성하는 방법이다. 나머지 하나는 case 문에 들어가는 조건이 규칙성을 가질 경우 해시 테이블을 만들어서 대응하도록 하는 방법이다. 하지만 둘 다 어셈블리어를 사용해서 코딩을 진행해야 하므로 실제 적용 과정에서 투입한 비용에 비해 이익은 그다지 크지 않다. 결국 switch ~ case 문을 사용할 경우 최대한 case 문에 일관성 있는 조건을 지정해야 컴파일러를 사용한 자동 최적화 작업이나 어셈블리어를 사용한 수동 최적화 작업이 쉬워진다.
CPU 아키텍처에 밀접한 최적화의 좋은 예로 uClibc에서 구현하고 있는 memcpy(memmove, bcopy) 루틴을 들 수 있다. 이 함수를 작성하는 과정에서 사용하는 각종 최적화 기법을 이해하고 있다면 어렵지 않게 다른 부문에도 적용할 수 있을 것이다.
uClibc에 들어있는 memcpy 함수 구현부는 상당히 길고 복잡하기 때문에 모두 소개하기는 어렵다. 여기에서는 일단 내부에서 어떤 점에 주목해서 구현했는지에 대해 알아본다.
복사 과정에서 조금이라도 속력을 높이기 위해 다양한 조건을 고려한다.

● 방향: 정방향 복사인가 역방향 복사인가(복사 시작 주소와 복사 대상 주소 크기를 비교한다)
● 정렬: 복사 시작 주소와 복사 대상 주소 위치가 정렬되어있는가
● 크기: 12바이트나 32바이트 단위로 복사가 가능한가

각 경우를 모두 따져서 해당 조건에 맞는 서브루틴으로 분기하기 때문에 memcpy를 구현하는 어셈블리 코드 길이가 무척 길어졌다. ARM CPU에서 제공하는 LDM/STM 명령을 사용해서 한 번에 블록 전송이 가능한 경우를 살피기 위해 크기를 따지며, 정렬의 경우 메모리 버스와 캐시 라인을 효과적으로 사용하기 위한 목적으로 따진다. ARM CPU의 경우 엔디안을 리틀이나 빅 양쪽 중 하나를 사용할 수 있으므로, 방향까지 잘 따져야 한다.
32비트 블록 전송을 위한 ARM 어셈블리 코드 조각을 보면 <리스트 21>과 같이 단순하면서도 무척 효율적이다.

<리스트 21> 32비트 블록 전송을 위한 ARM 어셈블리 코드
.Lmemcpy_bloop32:
ldmdb r1!, {r3, r4, r12, lr}
stmdb r0!, {r3, r4, r12, lr}
ldmdb r1!, {r3, r4, r12, lr}
stmdb r0!, {r3, r4, r12, lr}
subs r2, r2, #0x20
bge .Lmemcpy_bloop32

앞 에서 설명한 조건을 고려해보면 Lmemcpy를 사용할 경우에는 복사 시작과 복사 대상 주소가 정렬이 되어있고, 전체 자료 크기가 32비트 배수가 될 경우 최대의 효과를 올릴 수 있다. 이래서 우리는 때로 C만 사용하는 경우에도 별로 상관없어 보이는 어셈블리어로 구현된 라이브러리를 확인할 필요가 있는 것이다.
C 언어를 컴파일러가 좋아하는 방식으로 제대로 작성하기만 해도 상당한 성능 개선을 달성할 수 있다는 사실을 직접 확인했다. 물론 정말 좋은 컴파일러라면 이번 기사에서 소개한 내용에 맞춰서 프로그램을 작성하지 않더라도 개발자 의도를 파악해서 자동으로 처리해줘야 하겠지만 유감스럽게도 이렇게 훌륭한 컴파일러는 존재하지 않는다. 컴파일러 이론이 계속해서 발전하고 최적화 기능을 강화한 컴파일러 구현 결과물이 계속해서 나오고는 있지만 그 만큼 컴퓨터 아키텍처와 알고리즘이 복잡해졌기 때문에 효과가 반감되는 느낌이다.
결국 최고 성능을 달성하기 위해서는 개발자가 만든 함수를 어셈블리 코드로 바꿔서 어떤 문제점이 있는지 파악하고 속도를 높이기 위해 다른 코드들과 비교하며 어떤 제약점이 있는지 파악해야 한다. 이렇게 문제점과 제약점을 파악하고 나면 컴파일러가 좋아하도록 최적화한 코드를 C로 만들 수 있게 된다.
최적화와 관련해서 주로 C 언어적인 특성에 집중하다 보니 이번 기사에서는 CPU 메모리버스 특성, CPU 캐시 라인 정렬, 파이프라인, 부동소수점 루틴까지 고려한 최적화 방식은 다루지 않았다. 다음에 기회가 생기면 CPU 아키텍처와 관련해서 좀 더 깊이 있는 최적화 기법을 다루기로 약속하며, 쓸만한 참고 자료를 정리해 두었으니 참고하자.

참고 자료
1. ARM System Developer’s Guide, ㈜ 씨랩시스 역, Andrew N. Sloss, Dominic Symes, Chris Wright 저, 2005년 사이텍 미디어 출간
2. 임베디드 메모리 최적화 기법, 여인춘 역, Kris Kaspersky 저, 2004년 에이콘 출간
3. GCC 완전 정복, 김경헌 역, Kurt Wall과 William von Hagen 저, 2006년 에이콘 출간
4. 리눅스 문제 분석과 해결, 박재호 역, 마크 윌딩 저, 2006년 에이콘 출간
5. 리눅스 디버깅과 성능 튜닝, 박재호 역, 스티브 베스트 저, 2006년 에이콘 출간
6. Inside the machine, John Stokes, 2007년 No Starch Press 출간
7. 위키피디아(최적화): http://en.wikipedia.org/wiki/Optimization_%28computer _science%29
8. PowerPC Compiler Writer’s Guide: http://openlook.org/blog/684
9. x86 ABI: http://www.caldera.com/developers/devspecs/abi386-4.pdf
10. x86_64 ABI: http://www.x86-64.org/documentation/abi.pdf
11. PowerPC 32bit ABI: http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF77852569970071B0D6/$file/eabi_app.pdf
12. PowerPC 64bit ABI: http://www.freestandards.org/spec/ELF/ppc64/PPC-elf64abi-1.9.html

출처 : 마이크로소프트 [2006년 12월호]

GBA 하드웨어스펙
GBA Hardware Specification

Item Description
CPU ARM7TDMI
Memory 외부 RAM 256KB / 내부 RAM 64KB / I/O 레지스터 / VRAM / 팔레트 RAM / OAM / 세이브용 RAM 64KB
Screen 240 x 160 dot
Color 32768 color
Graphics mode Mode 0~5 (0~2 mode : Tile Mode,  3~5 mode : Bitmap Mode)
Background Tile Mode
  16색 x 16팔레트 or 256색 x 1팔레트
  Background 최대 4개, BG 사이즈 : 128x128 ~ 1024x1024
  Tile character 정의 수 : 1BG 당 최대 1024까지
Bitmap Mode
  256색 x 1팔레트 or 32768 color 직접 사용.
  BG Double Buffer 또는1개만사용
  BG Size : 240 x 160
Sprite 최대 128개 / 사이즈 : 8x8 ~ 64x64 / 팔레트 : 16색 x 16팔레트 or 256색 x 1팔레트
1D Mapping or 2D Mapping
Sound GB호환 4-Channel Direct Sound 2-Channel
Effect Background 와 Sprite 확대, 축소(Scale), 회전(Rotate), Window 2개, 모자이크 처리, 알파블랜드(투명), fade out,
Layer 순서지정(0~3), X/Y 대칭(flip)
Key 상, 하, 좌, 우, A, B, L, R, Start, Select<
Timer Timer(0~3) 4단계의 주기
DMA DMA(0~3) 4-Channel
Interrupt Vblank, Hblank, Vcount, Timer, DMA, Key, Communication, Cartrage
Communication 최대 4명, Multiboot
Bios Call 43개

GBA게임을 만들자.
GBA용 게임을 직접 만들 수 있다면 좋겠다는 생각을 하는 분들은 그 길이 열려있으니 노력해보기 바란다. GBA프로그래밍이 가능하다는 것은 반드시 게임이 아니라도 GBA를 이용한 무한한 가능성을 펼칠 수 있을 것이다.
GBA개발의 기본은 컴파일러와 그것을 직접 실행할 수 있는 도구다.
1. 개발할때 중간 확인은 에뮬레이터를 통해서 할 수 있다.
대표적인 에뮬레이터는 visualBoyAdvance로 여러가지 기능을 지원해 개발시 가장 좋은 파트너라할만하다. 무료소프트웨어라는 점도 장점이다.
2. 컴파일러는 실제 실행코드를 생성해내는 핵심적인 프로그래밍도구다.
현재 닌텐도에서는 수천만원에 이르는 겜보이 개발환경프로그램을 판매하고 있지만 그런걸 사서 취미를 즐길 미친넘이 몇명이나 있을까나..
무료! 역시 무료로 구할 수 있는 컴파일러가 있다. DevkitAdvance 이넘이다.
이 넘은 c,c++ 컴파일러로 상당히 유연한 모양을 하고 있는 커맨드툴이다.
그외에 GBA전용 헤더파일과 파일컨버터등도 필요하다. 모두 무료로 구할 수 있다.
3. 메모장으로 프로그래밍을 하기란 어렵다! 따라서 적당한 툴이 있어야한다. 개인적으로 좋아하는 acroeditor나 ultraeditor의 경우는 문법강조가 될 뿐만 아니라 커스텀툴 설정을 통해 dos모드의 툴을 연계해서 사용할 수 있기 때문에 아주 편리하다.
4. 에뮬로만 돌리면 재미가 없다. 짜피 pc에서 돌 프로그래밍이라면 어렵게 gba프로그래밍할 필요가 없기 때문이다. 역시 gba용으로 만들었으면 그것은 겜보이에서 돌려야하지 않겠는가!
여기에 필요한 것은 nand형 메모리매체를 지원하는 겜보이 램팩들이다. 닥터, 울트라 등의 메모리롬팩을 준비하자.
모든 것을 포함해서 4번의 메모리롬팩은 10만원정도에 구매할 수 있고 나머진 공짜다. 이제 필요한건 열정뿐이다!

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

GBA게임만들기 (1) - 개요와 환경셋팅
1. 들어가기에 앞서
본격적으로 GBA게임을 만들기 전에 몇가지 설명을 하고 시작하겠습니다.
먼저 가장 큰 도움을 받은 곳은 아래 주소의 까페입니다.
http://cafe.naver.com/gbastation.cafe
입문자에게 너무나 친절한 설명이 인상적입니다.
두번째로는 GBA개발자의 전당인 아래 주소입니다.
http://devkitadv.sourceforge.net/
여기에서 최신 개발툴을 받을 수 있는데 무료에다가 성능도 쓸만합니다.
다운로드 링크는 아래와 같습니다.
http://sourceforge.net/project/showfiles.php?group_id=67315
그외에도 어느정도 실력이 붙자 외국의 여러 개발자 포럼이나, 프리롬 사이트에서도 많은 도움을 받았습니다. 일본에서 사온 GCC프로그래밍편 특별판 리눅스 - 리눅스에서 각성한 우리들의 게임보이!란 책도 큰 도움이 되었네용. 이책은 리눅스에서 겜보이를 연결할 수 있는 드라이버와 케이블을 제공해주고 있는데 예제로 들어가 있는 소스의 경우 큰 도움이 되었습니다.

2. 환경설정
개발을 하려면 개발환경을 갖춰야합니다. 크게 컴파일러,에디터,에뮬레이터,기타소스 로 나눠서 설명하겠습니다.
- 컴파일러 설치
위의 소스포지의 툴은 바로 겜보이프로그래밍을 위한 컴파일러가 되겠습니다.
일 단 위의 다운로드 링크에서 총 6개의 파일을 모두다 받아서 같은 곳에다가 풀면 한 폴더 밑에 쭉하고 풀리게 됩니다. 일단 컴파일러는 압축을 푸는 것만으로 설치가 완료되는데 좀더 편리하게 사용하기 위해서 환경변수의 path에 압축을 푼 폴더와 그 폴더의 bin폴더를 잡아주는게 좋습니다. 음 그렇게 정리한 zip파일이 아래 있습니다.
devkitadv.zip
- 에디터 설치
비 주얼C같은 경우는 통합개발환경이라고 해서 에디터도 지원해주지만 이 무료툴은 에디터가 없습니다. 물론 메모장같은걸로 작업하고 cmd에서 타이핑으로 컴파일해도 되지만 그게 왠 생노가다 입니까.. 최소한의 에디터환경을 구축하는게 좋죠.
일단 컴파일러도 공짜를 쓰고 있으니 에디터도 공짜를 구합시다.
http://acrosoft.pe.kr/bbs/zboard.php?id=ae_download
위 주소에 가시면 아크로에디터의 최신 버전을 받을 수 있습니다. 아크로에디터는 무료답지 않게 외부컴파일연동이나 코드의 색상강조기능을 갖고 있어서 편리합니다. 아래순서대로 잡아주세요.
      1.일단 저걸 받아서 setup으로 설치하고나서 실행하신 후에 메뉴를 봅니다.
      2.메뉴>도구>사용자도구설정 으로 들어가셔서 '추가'를 누릅니다(두개를 추가할겁니다)
      3.메뉴이름 : GBA(gcc)
         명령 : devkitadv경로bingcc.exe
         인자 : -o %PATH%%NAMEONLY%.elf %FULLNAME% -lm
         작업디렉 : %PATH%
      4.하나 더 추가합니다.
메뉴이름 : GBA(objc)
         명령 : devkitadv경로binobjcopy.exe
         인자 : -O binary %PATH%%NAMEONLY%.elf %PATH%%NAMEONLY%.gba
         작업디렉 : %PATH%
위의 과정을 끝내면 일단 에디터환경도 끝입니다. 이젠 아크로에디터에서 소스입력해서 간단히 컴파일할 수 있게 된거죠. 위의 내용을 입력하기 귀찮으실테니 사용자도구불러오기에서 아래 파일을 불러오셔도 간단히 셋팅됩니다.
GBAtools.aut
- 에뮬레이터 설치
에뮬은 일반적으로 사용되고 있는 Visual Boy Advance를 사용합니다. 근데 홈피가 박살났는지 마땅한 정식링크는 없습니다. 각 자료실등에서 받을 수 있는데 일단 여기에 링크해두겠습니다. 압축을 풀면 설치가 끝입니다.
VisualBoyAdvance-1.7.zip
- 기타소스
위의 세가지를 다 설치해도 아직 할일이 남았습니다. GBA프로그래밍을 위한 헤더와 게임프로그래밍을 위한 BMP변환기, 맵타일생성기등입니다. 각각 아래 링크에 있습니다.
      헤더파일 : GbaHeaderFiles.zip
      BMP변환기 : BMP2HEADER.exe
      맵타일생성기 : MapEditor.exe
3. 개발의 흐름
실제로 개발에 들어가면 위에서 셋팅한 환경을 이용해 다음과 같은 순서로 작업하게 됩니다.
a. acroeditor실행(당연하죠..=.=)
b. 소스입력 및 이미지를 헤더로 변환(BMP변환기나 맵타일생성기 이용)
c. GBA(gcc)를 이용해서 소스로부터 elf생성
d. GBA(objc)를 이용해서 elf로부터 gba생성
e. VisualBoyAdvance를 이용해서 소스테스트
즉 간단히 말해 소스를 만들고 1차컴파일하면 elf가 되고 2차컴파일하면 대망의 gba가 되는겁니다.
이번엔 이정도로 해둘까요. 담엔 직접 개발소스를 정리해가죠.

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

GBA게임만들기 (2) - 간단한 샘플프로그램 제작
개발환경이 셋팅되었다면 무엇보다 역시 간단한 샘플을 만들어보는 것이 최고죠.
GBA 환경에서 개발하기 위해서는 기본적으로 C나 C++에 대한 이해가 필요합니다. C와 C++은 비슷한 것 같지만 사실은 완전히 다른 언어에 가깝습니다. 어떤쪽이 더 좋다라고 말하긴 힘들죠(C++이 나온 이유가 C의 불만을 개선하기 위해서라곤 하지만 결국 무식한 쪽도 나쁘지 않더라는 것이죠)
C에서 가장 어렵고 힘든 개념은 아마도 포인터일 겁니다. 초심자들이 힘들어하는 부분이기도 하고 반대로 C가 중급언어로서 강력한 힘을 갖는 이유이기도 합니다. C++은 역시 상속과 관련된 클래스컨트롤입니다. 객체디자인 자체가 어려운 일이죠. 이 프로그래밍언어 자체를 모르는 것은 어떻게 해결해야하는가 하면, 예제를 따라가면서 점점 공부해가는 방법밖엔 없습니다.
즉 영어로 얘기하자면 단어공부, 문법공부를 다 한뒤에 독해를 하는게 아니라 독해를 해가면서 모르는 단어를 찾아보고, 문장이 이해가 안되면 문법책을 뒤져보는 식의 공부죠. 사람마다 공부하는 방식이 있겠지만 프로그래밍을 배울때는 이런 방법이 나쁘지 않습니다.
밑에 샘플은 그저 카피해서 컴파일하는 훈련을 위한 소스입니다.
그저 카피해서 아크로에디터에서 컴파일 해봅시다 ^^
소스원문


#include "gba.h"
#include "bg.h"
void WaitForVsync(void){
   while(*(volatile u16*) 0x4000006 >= 160){};
   while(*(volatile u16*) 0x4000006 < 160){};
}
int main(void) {
   u16 *palette = MEM_BG_PAL;
   u16 *tiles = MEM_BG_CHAR(0);
   u16 *bgmap = MEM_BG_MAP(28);
   u8 x = 5;
   u8 y = 5;
   u8 z = 29;
   SetMode( MODE_0 | BG0_ENABLE );
   REG_BG0CNT = ( BG_SIZEA_256_256 | BG_COLOR_256 | BG_CHARBASE(0) | BG_MAPBASE(28) );
   palette[0] = RGB(10,20,30);
   palette[1] = RGB(31,22,10);
   u16 i;
   for( i = 0 ; i < 32 ; i++ ) tiles[i] = 0 + ( 0 << 8 );
   for( i = 32 ; i < 64 ; i++ ) tiles[i] = 1 + ( 1 << 8 );
   bgmap[0] = 1;
   bgmap[5] = 1;
   bgmap[32*y+x] = 1;
   bgmap[32*y+z] = 1;
   while(1) WaitForVsync();
   return 0;
}


위의 소스가 어떤 의미인지 전혀 설명할 생각은 없습니다. 위 소스는 주크님이 네이버의 '포터블 Game' 까페에 연재하시는 글에서 발췌했습니다(주크님이 작성하신 저 예제파일을 최초의 소스로 선택한 이유는 짧아서입니다. 죄송^^; )
이번 강좌에서 오직 해볼 실습은 컴파일입니다. 다음의 순서로 컴파일을 해보죠.
1. 위 소스 원문을 카피하여 아크로에디터에서 빈문서를 열고 붙여넣기를 한다.
2. test.c로 적당한 폴더에 저장한다.
3. test.c를 저장한 폴더에 1회강좌에서 기타준비물에 있던 gba관련헤더압축파일속에 있는 gba.h와 bg.h를 카피한다.
4. 아크로에디터에서 도구 > 사용자도구 > GBA(gcc) 를 실행한다.
5. 이어서 도구 > 사용자도구 > GBA(objc) 를 실행한다.
6. test.c를 저장한 폴더를 열어보면 해당폴더에 test.gba를 발견할 수 있습니다. 에뮬로 실행해보세요.
위 의 순서대로 진행하여 에뮬레이터에 이상없이 파란바탕에 오렌지 점이 몇개 찍혀있으면 성공한 겁니다. 이번 강좌는 소스를 작성하고 컴파일하는 연습을 하는 것이기 때문에 충분히 연습해보고 향후 개발시에 이러한 순서와 내용을 숙지하면 충분합니다(코드를 작성하고 헤더를 모아서 컴파일을 두번한다라는..)

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

GBA게임만들기 (3) - 컴파일러 공부
이제 워밍업은 이쯤으로 하고 진짜로 공부를 해보겠습니다(즉 이젠 제대로 읽고 이해를 하고, 외워야한다는 뜻입니다^^)
현재 겜보이용 프로그램을 만들 수 있는 툴은 몇가지가 나와있습니다. 그 중에 제 강좌에서 다루고 있는 devkit advance도 있습니다만, ham툴도 있고 arm사에서 직접 배포하는 툴도 있습니다.
즉 간단히 하고 싶은 말은 툴은 많이 있다는 겁니다. 일단 본 강좌는 설치가 가장 간단한(압축을 풀면 끝나니까) devkit advance로 진행하고 있는 겁니다. 따라서 이 툴을 먼저 공부하지 않으면 프로그래밍을 해도 그걸 어떻게 겜보이용 프로그램으로 바꿀지가 막막해지는거죠(아까부터 '툴(tool)'이라고만 했는데 정확하게는 컴파일러를 지칭하고 있습니다-c 또는 c++이란 언어의 형식으로 씌여진 문서를 겜보이가 이해할 수 있는 기계어의 집합으로 번역해주는 프로그램이라고 이해하시면 간단하겠네요)
그럼 이제 본격적인 devkit advance의 설명을 드리겠습니다.
일 단 devkit은 오픈소스그룹인 gnu에서 누구나 사용할 수 있는 프리컴파일러인 gcc를 기반으로 만들어졌습니다. 현재 http://gcc.gnu.org 에서 배포하는 gcc는 인텔계열 cpu에 최적화 되어있는데 반해 devkit은 겜보이의 cpu인 ARM7TDMI에 최적화 되어있습니다(어짜피 컴파일러라는게 cpu가 이해할 수 있는 언어로 c를 번역하는것이라 그 cpu가 무엇이냐에 따라 다른 컴파일러가 필요한거죠. 따라서 일반적인 c컴파일러를 구해서 프로그래밍해도 겜보이에서 돌지 않습니다. devkit이 아니라도 정확하게는 ARM7TDMI용 컴파일러가 필요한 것이죠)
그 외의 특징이나 제공되는 툴은 전부 gcc의 규격에 따르고 있습니다. 따라서 gcc를 공부하는 것이 devkit advance를 공부하는 지름길입니다.
사실 gcc는 리눅스나 유닉스 사용자라면 대부분 어느정도 사용법을 알고 있습니다.
일단 제가 강좌를 위해서 참고한 사이트는 아래 주소입니다.
http://junjaewoo.com/kldp/Gcc_and_Make-KLDP-html/gcc_and_make.html#toc2
아래 사이트에서 직접 공부하셔도 되고 제가 간단히 정리한 아래글을 보셔도 됩니다 ^^
단 위 링크에서 공부하시는 경우 devkit의 gcc와 옵션에서 약간 차이가 날 수 있으니 유의하세요.
1. gcc.exe
gcc.exe 는 이름 그대로 gcc의 핵심적인 기능입니다. 하지만 많은 분들이 착각하시는데 gcc는 c컴파일러가 아니라 중앙에서 소스를 통제하고 관장하는 프로그램입니다. 코드를 보고 c컴파일러가 필요한가, c++컴파일러가 필요한가도 판단하고, 링크도 하지만 실제적인 컴파일은 다른 프로그램이 하게됩니다(신경쓸 필요는 없지만요)
따라서 gcc를 공부한다는 것은 gcc의 링크기능과 컴파일 통제기능을 공부한다고 볼 수 있습니다.
일단 gcc의 모든 옵션을 간단히 살펴보고 사용예제를 통해 익혀보겠습니다.
-pass-exit-codes : 이 길다란 옵션은 컴파일중에 심각한 오류가 발생하면 탈출하란겁니다.
--help : 도움말을 표시
--target-help : 특정명령어에 대한 도움말을 표시(--v-help 이런식으로 쓰이죠)  
-dumpspecs : 스펙문자열안에 있는 모든 빌트를 표시
-dumpversion : 컴파일러 버전을 표시
-dumpmachine : 컴파일러의 타겟 프로세서를 표시
-print-search-dirs : 컴파일러가 패스로 잡은 폴더를 표시
-print-libgcc-file-name : 컴파일러의 동료라이브러리 이름을 표시
-print-file-name=[lib] : 라이브러리의 전체경로를 표시
-print-prog-name=[prog] : 컴파일컴포넌트의 전체경로를 표시
-print-multi-directory : gcc라이브러리 버전이 있는 루트폴더를 표시
-print-multi-lib : 커맨드라인오셥과 라이브러리폴더간의 매핑을 표시
-print-multi-os-directory : OS라이브러리에 잡힌 상대경로를 표시
-Wa,[options] : 어셈블러에 대해 컴마 구분자를 무시
-Wp,[options] : 전처리기에 대해 컴마 구분자를 무시
-Wl,[options] : 링커에 대해 컴마 구분자를 무시
-Xlinker [arg] : 링커에게를 무시
-save-temps : 임시파일을 지우지 않음
-pipe : 임시파일 보단 파이프를 사용함
-time : 각 서버프로세스 실행시간
-specs=[file] : [file]컨텐츠의 빌트인스펙을 오버라이드함
-std=[standard] : 입력소스를 [standard]로 간주함
-B [directory] : 컴파일러 검색 패스에 [directory]를 추가함
-b [machine] : [machine]을 위해 gcc를 실행함
-V [version] : [version]의 gcc를 실행함
-v : gcc버전을 표시함
-E : 컴파일이나 어셈블, 링크를 하지 않고 전처리만 함
-S : 어셈블이나 링크를 하지않고 컴파일만 함
-c : 링크를 하지 않고 어셈블과 컴파일만 함
-o [file] : [file]로 컴파일될 파일을 출력
-x [language] : 컴파일러가 인지할 파일이름에 대해서 언어를 명시한다.
옵션이 많지만 실제로 사용되는게 그렇게 많지는 않습니다. 일단 상단에 설명에 표시로 끝나는 넘들은 표시하는 넘들이라 컴파일과 상관은 없고 그냥 궁금할때 써보면 됩니다.
예 를들어 'gcc -print-search-dirs' 이렇게 명령을 내리면 gcc가 기본적으로 잡고 있는 모든 패스를 보여줍니다. 여기에 헤더나 라이브러리가 위치하지 않는다면 -B 옵션을 이용해서 잡아줘야합니다. 또 한가지 예를 들자면, 'gcc -dumpmachine' 이라고 명령을 내려보면 'arm-agb-elf' 라고 뜹니다. 즉 devkit의 gcc는 arm프로세스를 위한 컴파일러라는 뜻이죠.
일단 디스플레이 옵션들은 그렇다고 치고 핵심적인 옵션들은 아래쪽에 있는 옵션들입니다.
test.c라는 c소스가 있다고 가정하고 차근차근 설명해보겠습니다.
1단계 : 그냥 친다.
'gcc test.c' 라고 아무런 옵션도 없이 명령하면 결과는 'a.out'이라는 미리 약속된 이름의 실행파일을 만들어냅니다. 컴파일상으로 완전하지만, 저런 이름으로 출력되길 원하지는 않을 겁니다.
2단계 : 출력파일의 이름을 준다.
'gcc -o test.elf test.c' 라고 치면 컴파일의 결과로 test.elf가 만들어집니다. 저 명령을 잘보면 '-o test.elf' 여기까지가 한셋트고 그걸 제외하면 'gcc test.c'가 되어 1번과 같은 명령입니다. 옵션은 뒤에 붙여도 무방하니까 'gcc test.c -o test.elf'라고 써도 동일합니다. 이 -o옵션은 test.c파일을 컴파일한 후에 어떤 이름을 붙일지를 결정해줍니다.
3단계 : 여러개의 파일을 모아서 컴파일한다.
test.c외에도 test2.c, test3.c 라는 파일이 더 있고 이것들을 한꺼번에 모아서 컴파일해야할 경우가 생깁니다. 이런 경우는 2번에서 파일이름만 확장해주면 됩니다.
'gcc -o test.elf test.c test2.c test3.c' 이렇게 됩니다.
4단계 : 컴파일만 하기
실 제로 c어플리케이션은 여러개의 파일로 구성해서 하나의 파일이 그러한 여러개의 c파일을 통합하는 방식이 됩니다. 이런 경우 각각의 모듈들을 미리 컴파일 해두면 나중에는 그것을 묶기만 하면됩니다. 따라서 하나의 모듈이 완성되면 그것을 미리 컴파일만 해두고 싶은데 그럴때 사용하는 옵션이 -c옵션입니다. 'gcc -c test.c' 이렇게 하면 약속된 이름인 'test.o'가 생성됩니다.
3번단계에서 'gcc -o test.elf test.c test2.c test3.c' 이렇게 하면 컴파일러는 그 시점에서 세개의 c파일을 컴파일해야하지만 미리 'gcc -c test.c','gcc -c test2.c','gcc -c test3.c'를 해두어서 test.o, test2.o, test3.o 를 생성해두었다면,
'gcc -o test.elf test.o test2.o test3.o' 라는 명령을 통해 간단히 링크하는 과정으로 생성할 수 있습니다.
5단계 : 추가적인 패스를 지정한다.
4 번까지의 예제에서 test2.c 또는 test2.o가 같은 폴더에 있다고 가정하고 있습니다만 사실은 다른 폴더에 있을 수도 있죠. 이런 경우 명시적으로 컴파일러가 파일을 검색할 폴더를 지정해줘야합니다. 그것은 -B옵션으로 가능합니다. 가령 test2.o가 c:test라는 폴더 밑에 있다면
'gcc -o test.elf test.o test2.o test3.o -B c:test' 라는 명령을 통해서 해당폴더를 검색하게 할 수 있습니다.
일단 GCC는 여기까지 살펴보고 다음은 make.exe를 공부해보겠습니다.
2. make.exe
make 란 말그대로 만들어내는 프로그램입니다. 위의 gcc를 이용해서 복잡한 파일이 연결된 프로젝트를 컴파일하려면 매번 귀찮은 일이기도 하거니와, 타이핑 중에 실수도 유발하게 됩니다. 따라서 이러한 과정을 하나의 파일에 저장해서 스크립트로 만들어두고 사용하면 편리하겠죠. 바로 그러한 기능을 수행하는 것이 make.exe입니다. 따라서 make.exe의 옵션도 배워야하고 make.exe가 인식할 수 있는 컴파일 스크립트도 배워야합니다.
헥헥..너무 길어서 나중에 마저 작성..

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

RPG제작타일샘플
block.psd
Book1.xls
test.fla

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

퍼지로직 샘플
그러면 실제로 제가 슈팅 게임에 사용한 적 캐릭터의 움직임을 제어하는 룰베이스를 한번보죠.  
#define PURSUIT 0 // 추적 모드
#define ATTACK 1 // 공격 모드
#define RUN 2 // 회피 모드
char rule_base_x[3][3][5] = // ML SL 0 SR MR
{
  -3, -3, -2, 0, 2, // LEFT
  -3, -2, 0, 2, 3, // 0
  -2, 0, 2, 3, 3, // RIGHT
  -3, -3, -4, 3, 2,
  -4, -2, 0, 2, 4,
  -2, -3, 4, 3, 3,
  0, 2, 3, -3, -2,
  0, 3, 4, -3, 0,
  2, 3, -3, -2, 0
};
char rule_base_y[3][3][5] = // MU SU 0 SD MD
{
  -4, -3, -2, 0, 2, // UP
  -3, -2, -2, 0, 2, // 0
  -3, -2, -2, 3, 2, // DOWN
  -4, -3, -4, 0, 0,
  -3, -2, -4, 0, 2,
  -3, -3, -4, 0, 2,
  2, 2, 3, -3, 0,
  0, 3, -4, -3, 0,
  0, 3, -3, -2, -2
};  
< 하나는 X, 하나는 Y 에 대한 rule base 입니다. >
위에서 각각의 인덱스의 의미는 다음과 같습니다.
첫째 : 동작 모드 선택
둘째 : 플레이어 캐릭터의 움직임
세째 : 적 캐릭터에서 본 플레이어 캐릭터의 떨어진 거리
< 주석으로 표기된 어림수 기호의 의미는 예컨데 SL 이라면 왼쪽으로 조금 떨어졌다는 것입니다. >  
각 캐릭터의 위치는 프로그램 상에서
X = X + DX ;
Y = Y + DY ;
라는 식으로 갱신 되므로, 각 각의 배열 요소의 값은 적캐릭터의 DX 와 DY 값이 됩니다.
그러니까 시시 각각 변화하는 플레이어의 동작을 적절한 인덱스 값으로 바꾸어서, 그 인덱스에 해당하는 rule base 값을 적 캐릭터의 DX 와 DY 값으로 이용하면 되는 겁니다.
동작모드의 경우는 여러개를 준비해 두고 게임의 적절한 상황에 맞게 인덱스를 지정해 주면 다양한 적의 움직임을 만들수 있습니다.
그러면 실제로 rule base 는 어떻게 정해 주어야 할까요?
두 가지 방법이 있습니다.
하나는 경험적인 방법이고, 하나는 시행착오법입니다.
제가 위에서 사용한 룰베이스의 값들은 제가 게임 중에 캐릭터를 어떻게 조작하는지를 모방해서 만든 것입니다.
그러니까 룰베이스의 데이타를 제공하는 사람의 경험능력에 달려 있는 경험적인 방법이죠.
저 같이 게임을 제대로 못하는 사람이 만들면 잘 해야 만든 사람 정도 실력 밖에 구현이 안되죠.
반면에 시행착오법은 최적의 룰베이스를 시행착오를 통해서 컴퓨터가 스스로 찾도록 하는 것입니다.
요즈음 신경망 인공지능을 이용해서 퍼지 룰 베이스를 찾아내는 연구가 활발하게 이루어지고 있는 것으로 알고 있습니다.
---------------------------------------------------------------
그러면 실제로 적 캐릭터를 움직이는 함수입니다.
void type_move(void)
{
  byte b, i, j, k ;
  int delta_x, delta_y, bm = 0 ;
  delta_x = character[thunder].x - character[type01].x ;
  delta_y = character[thunder].y - character[type01].y ;
  if ( delta_x > 45 )
    torp_fire(character[type02].x, character[type02].y) ;
  for (b = 0 ; b < MAXNO ; b++)
  {
    if(beam[b].energy==0)
      continue ;
    bm++ ;
  }
  if ( character[type01].energy >= character[thunder].energy )
    i = ATTACK ;
  else if ( bm && abs( delta_x ) < 60 )
    i = RUN ;
    else i = PURSUIT ;
  if (abs(delta_x) < 20)
    bullet_fire(character[type01].x, character[type01].y+5) ;
  switch(character[thunder].dx)
  {
    case -3 :
        j=0 ;
        break ;
    case 0 :
        j=1 ;
        break ;
    case 3 :
        j=2 ;
        break ;
  }
  if ( abs(delta_x) < 5 )
    k = 2 ;
  else if ((delta_x) <= -5 && (delta_x) > -30)
    k = 1 ;
  else if (delta_x <= -30)
    k = 0 ;
  else if ((delta_x) >= 5 && (delta_x) < 30)
    k = 3 ;
  else if (delta_x >= 30)
    k = 4 ;
character[type01].dx = rule_base_x[i][j][k] ;
character[type01].x+ = character[type01].dx ;
  switch(character[thunder].dy)
  {
    case -3 :
        j = 0 ;
        break ;
    case 0 :
        j = 1 ;
        break ;
    case 3 :
        j = 2 ;
        break ;
  }
  if ( abs(delta_y) < 15 )
    k = 2 ;
  else if ((delta_y) <= -15 && (delta_y) > -60)
    k = 1 ;
  else if (delta_y <= -60)
    k = 0 ;
  else if ((delta_y) >= 15 && (delta_y) < 60)
    k = 3 ;
  else if (delta_y >= 60)
    k = 4 ;
  if ( random(5)==0 )
  {
    character[type01].dy = rule_base_y[i][j][k] ;
    character[type01].y+ = character[type01].dy ;
  }
}  
세세 하게 설명 하지 않아도 차근히 살펴 보시면 이해 하 실 수 있을겁니다.
의외로 간단하죠.
마지막에 if ( random(5)==0 ) 으로 한 건 100% 적용하면 제가 도저히 이길 수가 없으므로 y에 대해서는 1/5 만 적용되도록 한 겁니다.
어디 게시판에 보니까 '로드 런너'라는 애플시절의 게임을 아이비엠 용으로 만드는데, 게임의 상황에 따라서 미묘하게 변화하는 적 캐릭터의 동작 속도를 구현하기 어렵다고 하는데, 퍼지를 이용하면 간단하게 될 것 같네요.

출처 : http://pda.actionfilter.com

'Games' 카테고리의 다른 글

Mabinogi Official Opening  (0) 2008.05.26
MStar  (0) 2008.05.26
GBA 게임 만들기  (1) 2008.03.23
Hearts and Other Trick-Taking Games  (0) 2008.02.20
Casino Games  (0) 2008.02.20
바카라 게임방법  (1) 2008.02.20
  1. ㅎㅎ 2014.10.04 12:19 신고

    책 내셔도 될듯...

+ Recent posts