Solid State Blog

기본적으로 윈도우간 주고받는 메시지가 디버깅 출력창에 다음과 같이 표시된다.

SENDING command id 0xE100 to CWinApp target.
SENDING command id 0xE101 to CWinApp target.
SENDING command id 0xE103 to CIExplorerDoc target.
No handler for command ID 0xE123, disabling it.
No handler for command ID 0xE122, disabling it.
No handler for command ID 0xE125, disabling it.
SENDING command id 0xE140 to CWinApp target.
SENDING command id 0xE100 to CWinApp target.
SENDING command id 0xE101 to CWinApp target.
SENDING command id 0xE103 to CIExplorerDoc target.
No handler for command ID 0xE123, disabling it.
No handler for command ID 0xE122, disabling it.
No handler for command ID 0xE125, disabling it.
SENDING command id 0xE140 to CWinApp target.
SENDING command id 0xE100 to CWinApp target.
SENDING command id 0xE101 to CWinApp target.

간혹 이런 디버그 메시지가 오히려 디버깅을 힘들게 하는 경우가 있는데 다음과 같이 디버깅 관련 변수를 설정하면 위의 메시지를 제거할 수 있다.

 

#if defined(_DEBUG)

   afxTraceFlags = 0;
   // *** UNCOMMENT NEXT LINE if you want multi-app debugging ***
   // afxTraceFlags |= traceMultiApp;

   // *** UNCOMMENT NEXT LINE if you want main message pump trace (includes DDE) ***
   // afxTraceFlags |= traceAppMsg;

   // *** UNCOMMENT NEXT LINE if you want Windows message tracing ***
   // afxTraceFlags |= traceWinMsg;

   // *** UNCOMMENT NEXT LINE if you want Windows command routing trace ***
   // afxTraceFlags |= traceCmdRouting;

   // *** UNCOMMENT NEXT LINE if you want special OLE callback trace ***
   // afxTraceFlags |= traceOle;

   // *** UNCOMMENT NEXT LINE if you want special database trace ***
   // afxTraceFlags |= traceDatabase;

   // *** UNCOMMENT NEXT LINE if you want special Internet client trace ***
   // afxTraceFlags |= traceInternet;
#endif /* DEBUG */

 

위와 같이 변수를 적절히 조절하여 디버그 메시지를 조절하여 출력할 수 있으며 afxTraceFlags가 NULL이 되면 아무런 메시지도 출력하지 않는다. 시점은 App가 초기화 되는 시점인 InitInstance가 적당하다.

원래 콘솔게임은 신경도 안썼지만 NDSL을 영어 삼매경 때문에 구입하게 되었다.

구입 후에 NDSL이 마스크 롬에 의존하는 방식이 좀 답답하다는 생각이 들었고 SD카드가 꼽히는 NDS 슬롯은 없을까라는 생각을 하게 되었는데 이미 누군가 만들어놨더라... 그래서 구입한 "EZ5"

국내 정발후 닥터류는 단속으로 자취를 감췄고 구할 수가 없어 결국 해외 사이트 구매신청, 결재 문제로 거의 1주를 소비후 손에 받은 것이 슬롯에 꼽고 동작할때 부터 오락가락했다.


"not found EXFS." ?? 그래서 이것 저것 찾아보다 EZFlash V: Troubleshooting에서 찾은 결론이

Ambiguous Erroneous Screens
boot moonshell
version 1.5 by moonliht
jan 12 2007 094421 gmt+9:00
ITCMO X 20A1310,0 X 0 , 0 X 5804
DTCMO X 209F060, 0 X 800000, 0 X 22b0
init filesystem
filema x count=256
not found EXFS.

Symptoms: EXFS not found, erroneous reboots, black screen between games (random). The error message is shown above - the date is unique as to when your card was purchased. This error appears when you don't have a MicroSD card attached as well, see #1 in the topic above.

Cause: PASS-ME system on EZV is corrupted.

Solution: Get a replacement from the store of origin.

교환! 헉; 이건 재배송하면 배보다 배꼽이 더 클것 같았다.
그래서 이것 저것 만지다가 결국 이렇게 됐다.

EZ5 내용물이 궁금하신 분들은 보시라..=ㅁ=

EEPROM 하나랑 ASIC 하나 주파수 발생용 크리스탈 하나가 전부인 듯 간단하구나..후훗

 

간혹 이것저것 하다 보면 C++이나, Java 말고 asm으로 코딩해야 하는 경우가 생길 수 있다. 물론 디바이스 드라이버를 개발하는 등의 경우를 제외하고도 말이다. 나의 경우에도 아주 특별한 이유로 ASM 코드를 포함시켜야 하는 경우가 있었는데 MS에서 제공하는 ARM 컴파일러에서는 인라인 어셈플러를 지원하지 않았다. (물론 내가 못 찾았을수도 있지..=ㅁ=) (이하의 내용은 VS 2005 기준이다. )

아무튼 그리하여 인라인 말고 asm을 obj파일로 생성하여 링크하는 법이 있지 않겠나 하여 찾은것이 Jeff Abraham's WebLog의 블로그에서 찾은 룰 파일이였다.

<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile Name="Arm ASM" Version="8.00">
   <Rules>
      <CustomBuildRule
         Name="Arm asm" DisplayName="Arm asm"
         CommandLine="armasm -o &quot;$(IntDir)\$(InputName).obj&quot; [$Inputs] "
         Outputs="$(IntDir)\$(InputName).obj"
         FileExtensions="*.asm"
         ExecutionDescription="Executing tool..."
      >
      <Properties></Properties>
      </CustomBuildRule>
   </Rules>
</VisualStudioToolFile>

위의 내용을 메모장으로 저장하여 armasm.rule 이란 이름(다른 이름도 상관없다.)으로 저장하고 Project > Custom Rules... 을 선택한 후 Find Existing... 버튼을 눌려 해당 룰파일을 로딩해주면 asm 파일은 arm 어셈플러로 빌드시켜준다.

이렇게 설정후 asm파일을 다음과 같은 형태로 코딩한다.

 CODE32
 AREA |.text|, CODE, ARM
 IMPORT MessageBoxA // 사용할 함수명
 EXPORT _Function // 노출할 함수명

_Function PROC

...

ENDP

그리고 C코드 상에서는 어셈으로 작성된 함수에 관한 프로토 타입이 없으므로 이를 정의하고 사용하면 된다.

void _Function(void);

int main()
{
  _Function();
  return 0;
}

가끔 CE 관련 개발을 하다보면 Command Prompt가 절실할 때가 있다. 특히 WM5 같이 지원 안해 버리는 경우는 더욱더.
RAPI를 이용하면 왠지 만들수 있을것 같았지만 이미 누가 친절하게 만들어놨다. 이름하야 Device Command Shell in Visual Studio 2005, VS의 Add-ins형태로 동작한다.

이 툴은 아래의 링크에서 받을수 있다.


http://www.gotdotnet.com/Workspaces/Workspace.aspx?id=50618f79-c7b1-4588-9c0a-cf4ddae8092a


간단한 사용법은 VS의 Command Window에서 DeviceCommandShell.Connect.DeviceCommandShell를 실행하면 실행가능한 명령어 목록이 나오며 실행방법은 다음과 같다.

ce.list : 디바이스 목록
ce.connect.[디바이스  ID] : 디바이스 접속
ce.dir [디렉터리] [필터] : DIR

이 외의 추가적인 명령어는 ce.help로 확인 가능하다.

아 오늘 일이 안풀리는구낭... 협력사로부터 업데이트된 소스를 우리쪽 소스에 머지작업을 진행하고 통체로 커밋을 하는 작업을 진행중이였다. 보통 이런 경우는 대량 커밋이 동반되는데 그 부작용에 대한 걱정은 안할 수가 없다. 왜냐하면 내가 모든 소스를 이해할 수가 없기 때문이다.


그래도 어느 정도 작업이 진행되었고 정상 동작하는 것이 확인되어 커밋을 했다. 그 후 누락파일이 없는지 확인하기 위해 별도로 체크아웃을 받아 빌드를 했는데... 무지막지한 오류를 뿜어내고 있었다. 누락파일을 확인하기 위해 머지된 소스를 확인했는데.. 코드가 머지 전으로 원복되어 있었다. 이런 젠장스..;;; 분명히 클린 업데이트를 한적도 없는데... 그래서 다시 머지하고 커밋을 했는데... 한번 꼬이기 시작한 일은 쉽게 풀리지 않았다. 분명 수정된 바이너리인데 CVS에서 서버의 원본과 같다고 생각하고 커밋을 하지 않는 것이였다.


간혹 넘겨받은 소스에 CVS폴더가 머지되어 꼬이는 경우가 있었지만 이번에는 그 경우가 아니였다. (미리 이전에 다 지웠거덩..;;) 할 수 없이 다른곳에 체크아웃 받은 곳에서 커밋을 했는데...이번에도 커밋이 되지 않았다. 머피의 법칙은 여전히 유효했다. 서버가 커널페닉을 밷어내고 디스크의 inode가 꼬여버린 것이다. 아 좌절의 연속이다..T.T;


여차저차해서 복구한 후 마무리를 지었는데...황금같은 개천절은 다 날라가고 난 뒤였다.

아...이런거 자꾸 퍼오면 안되는데..;;

Flash로 이미지 겔러리를 호스팅 해주는 사이트이다. 무엇보다 디자인이 멋지다.

예전에 Flash가 나타나기 전에 Director와 CGI로 이런걸 생각한 적이 있었다. 지금 생각하면 이런 기술이 이렇게 확산될지는 몰랐지만, 사실 생각만 했었다는 건 무의미하지...;;

입사 후 첫휴가로 비진도에 다녀오게 되었다. 비진도에 들어가기 위해서는 통영항에서 출발해야 하는데 기차로는 갈 수 없고 고속버스로 4시간쯤 걸린것 같다. 오후 늦게 출발한 이유로 이미 도착했을때는 해가 졌고 비진도로 들어가는 배도 비수기에는 하루 2번 밖에 없는 이유로 하룻밤을 통영에서 보내게 되었다. 어느 항이나 마찮가지겠지만 통영 부근에는 섬도 많고 지형도 만형태로 되어 있어서 내부의 바다는 아주 잔잔했다.


통영에 도착하자 가장 먼저 눈에 들어온것이 있는데 남망산공원의 시민회관이였다. 특별히 목적이 없었던 이유로 여객터미널에서 걸어 남망산 공원에 올라갔다.



남망산 공원에는 조각공원도 있긴 했는데 밤이고 사실 보이는게 없었다.;; 그래서 야경 몇장 찍고 숙소로 내려왔다.

다음날, 일어나보니 11시였다. 뭐 사실 특별한 계획을 가지고 움직인게 아니라서 시간은 편하게 잡았다. 나오니 여전히 날은 흐렸다. 음... 사실 조금씩 불안해지기 시작했다. 맑은 날씨를 기대했는데...
그리고 표를 예매하는데 뉴스에선 "산산" 얘기가 나왔다. "산산"? 알고보니 대만으로 가려던 태풍이 우리나라로 진로를 바꿨다는 뭐 이런..;;
그렇다고 계획을 수정할 수는 없었다. 태풍이 올라오면 어디든 날씨야 안 좋을테니...



아무튼 표를 예매하고 배를 채우러 주변에 음식점을 찾았다. 바닷가라 주변에 횟집이 무지하게 많았다.(당연한건가..) 그런데 회를 좋아하지 않는 이유로 밥집을 찾아 여기저기 돌아다녔는데 거의 좌절 수준이였다. 어디가도 물고기랑 연관이 안된 곳이...
결국 분식 집에서 라면에 김밥으로 배을 채우고 선착장으로 갔다.


탁트인 바다를 기대했는데 주변에 섬이 많아서 큰 호수 같다는 느낌도 들었다.



그리고 기다려서 2시에 처음으로 배란 이동수단을 타봤다. 배멀미나 하지 않을까 하는 막연한 불안함이 있었지만 생각보다 재미있었다. 그래도 깊이가 가늠되지 않는 검푸른 바다는 여전히 무서웠다.



약 40분쯤 배를타고 드디어 비진도에 도착했다. 경치는 추천 받은대로 분명 좋았다. 그런데 젠장스... 비가 오고 있었다. 빨리 숙소를 잡을려고 민박과 팬션을 알아봤는데 비수기 임에도 불구하고 여전히 바가지 모드였다. 그래도 나름 괜찮은 "바다이야기"에 숙소를 정하고 비가 그치기를 기다렸다. (참고로 펜션은 4~5만원, 민박은 2~3만원 정도 물론 비수기일 경우)



기다리는 중 TV를 확인, 아~ 여전한 태풍의 얘기와 비가 계속 될거라는...그래서 구경은 포기하고 먹을거리를 사러갔다. 그런데 역시 섬이라 최소한의 것만 구할 수 있었다. 옆방에서는 고기냄새가 넘어오고 있지만...; 담에 섬에 갈때는 필요한건 다 사들고 가야겠다.

그리고 다음날 태풍이 올라온다는 얘기를 듣고 섬에 계속 머무를 수는 없었다. 잘못 하다가는 계속 남아있을지도 모르니깐.. 그래서 아쉽지만 정리해서 서둘러 섬을 빠져나왔다. 남은 사진으로만 만족하는 수밖에...

기술의 발전은 끝이 없나보다. Gigapxl이라니..;;

사진은 예제로 올라온 사진이며 http://www.gigapxl.org/ 에서 더 확인할 수 있다.

 

이어지는 내용