크악... 이제 슬슬 쉘을 만들까 해서 sprintf() 함수를 구현하고 있었습니다. 처음에는 cdecl을 강제로 줘서 예전에 스택 어드레스로 하던 가변 인자 처리 방법을 써볼까 했는데... 64bit gcc는 cdecl을 줘도 무시하더군요. ㅡ_ㅡa... 그것도 당당히 무시한다는 경고까지 띄우고 말입니다. ㅡ_ㅡa...

그래서 결국 중계 역할을 하는 함수를 하나 둬서, 함수 Call 시에 레지스터로 넘어간 파라메터를 스텍에 집어 넣은 후  sprintf() 함수를 불렀습니다. 스택에 파라메터가 다 들어가 있으니 당연히 예전 방식대로 처리할 수 있었지요. ;) 그런데 의외의 곳에서 낭패를 봤습니다. ㅡ_ㅡa.... 다음 코드를 보시죠. ㅠㅠ


아시는 분은 아시겠지만, “...”으로 함수 파라메터를 정의했다면 다른 함수로 “...” 을 넘겨줄 수 없습니다. 쿨럭..;;; 왜 이걸 생각 못했는지... 그래서 예전에 쓰던 va_arg() 시리즈 물은 혹시 잘 될까 싶어서 써 봤는데... 의외로 링크 에러가 안 나는 겁니다. 그래서 정의된 곳으로 가서 확인했더니 라이브러리 함수가 아닌 builtin 함수를 가리키고 있더군요. ㅡ_ㅡa... 그냥 바로 코드로 전환되어서 링크 에러가 안 났던... ㅠㅠ

진작 이놈들을 썼으면 훨씬 전에 끝났을 텐데... vsprintf() 함수나 구현하고 sprintf()랑 printf()는 vaprintf()를 사용하도록 변경해야겠군요. Calling Convention 때문에 고민 꽤나 했었는데... 왠지 허무합니다. ㅠㅠ 에궁... 이렇게 또 하루를 날려 먹는다는... 그나저나 매번 가변 인자 때문에 고생했었는데, 좋은 걸 알았네요. ㅎㅎ 이제 걱정 안해도 되겠습니다. ;)

아우... 일단 자고 내일 일찍 와서 마무리를 해야겠습니다. 그럼 다들 좋은 밤 되세요. ;)


ps) CharSyam님이 지적하신 내용을 보고 본문을 다시 읽어봤더니, va_arg()를 라이브러 함수인 것 처럼 표현해서, 약간 수정했습니다. 본래의 의도는 va_arg()가 지시하는 함수가 라이브러리 함수가 아니라 builtinXXX 시리즈 함수라는 뜻이었는데, 마치 va_arg() 자체가 함수라는 것 처럼 썼더군요. va_arg() 시리즈는 매크로가 맞습니다. ;) CharSyam님 감사합니다. ;)

고향에서 엄마가 어찌나 바리바리 싸 주시던지... ㅎㅎ 올라오는데 종이 백이 찢어 질려고 해서 후덜덜하면서 올라왔습니다. :) 그래도 집에 와서 보니 흐뭇하네요 ;) 엄마 만세~~

짐 정리와 집 정리 좀 하고 컴퓨터 앞에 앉아 펩시를 마시고 있는데(펩시 짱~!!!)... “아~ 돌아왔구나” 하는 안도의 한숨과 “윽~ 내일 출근해야 하는 군하” 하는 통탄의 한숨이 같이 나오는군요. 크윽... 출근하기 싫어요. ㅠㅠ

에궁... 오늘 할 일도 많은데 언능 씻어야겠습니다. 그래도 이틀만 더 가면 다시 주말이니 힘내야겠어요 ㅎㅎ 언능 작업하고 자기 전에 또 MileStone이나 하나 올려야겠습니다. ㅎㅎ


좀 있으면 할머니 댁에 가야함에도 불구하고 일정이 좀 밀린지라 미친듯이 작업했습니다(그것도 설날 새벽에 이 짓을..~!!! ㅠㅠ). 그 결과~!!! 일단 목표치까지는 완성했습니다. ;) 아우 이거 원 노가다가 아주 장난이 아니군요. 그리고 생각 난 김에 MileStone 성 글에는 앞에 [MileStone]을 달기로 했습니다.

예전에 한번 달았다가 별로 효용이 없어서 블로그를 옮기면서 안달았는데... 글을 검색하려니 태그로 검색하는 것 보다는 제목으로 검색하는게 더 눈에 들어오더라구요 ㅎㅎ 앞으로 어떻게 될지는 모르겟지만, 일단 다는 걸로 했습니다.

[MileStone]을 달려고 글을 찾던 도중... 64bit로 최초로 전환해서 올렸던 글을 봤습니다. 작년 7월이더군요. 허허... 그후 가능성을 검토하기 위해 한 3개월 투자해서 GUI까지 후딱 만들고 지금 2번째 만들고 있는 건데... 그간 고생이 참 많았던 것 같습니다. ㅠㅠ 수많은 가상 머신들을 테스트하며 무료로 쓸 수 있고 멀티 코어까지 지원하는 놈을 찾기가 쉽지 않더라구요. 개발 환경은 또 왜이렇게 구축하기가 힘든건지... 지금 생각하면 눈물이 앞을 가립니다. ㅠㅠ

어쨋거나 지금은 검증까지 완료된 상태니 다시 그런 고생은 안하겠지요. ;) 옛날 글을 보니 감회가 새로워서 한자 끄적거려 봅니다. ㅎㅎ

이크~ 더 늦기 전에 이만 자야겠군요. 다들 떡국 많이 드시고, 새해 복 많이 받으세요 ;)


프로젝트 홈페이지: http://dev.naver.com/projects/nanumfont/


작년부터 GUI에 사용할 무료 폰트가 없을까 많이 고민했었는데, 어제 웹서핑을 하다가 네이버에서 공개한 무료, 그것도 고정 폭 글꼴을 찾았습니다. @0@)-b 비트맵 방식으로 처리하는데 고정 폭만큼 편한 게 없는지라 테스트를 위해 바로 설치해 봤습니다.


아래의 그림은 제가 주로 쓰는 Bitstream Vera Mono 폰트와 나눔고딕 코딩 폰트를 비교한 것입니다. Bitstream에 비해 샤프한 느낌이 나고 한글이 예쁘게 잘 나온다는 것을 알 수 있습니다. 헷갈리기 쉬운 숫자 0과 영문 O를 쉽게 구분할 수 있도록 한 것도 맘에 드는군요. ;)



<나눔고딕 글꼴>



<Bitstream Vera Sans Mono>


Bitstream을 보다가 나눔 고딕을 보니 약간 어색한 문자가 보이기도 하지만, 공짜로 쓸 수 있고 한글이 예쁘게 잘 나오기 때문에 향후 나눔고딕 폰트를 본 따 GUI를 만들 생각입니다. MINT64 OS가 한층 더 이뻐지겠군요. ;) 프로젝트를 진행하시는 분께 감사의 메일이라도 보내야겠습니다.


아우~ 이제 좀 있으면 고향으로 출발해야 할 시간이군요. 다들 즐거운 설 되시고 떡국 많이 드세요 ;)

아아~  지난 주에 내내 정리하고 작업해서 인터럽트 처리에 기반이 되는 IDT와 TSS쪽 관련 작업을 완료했습니다. 아우~ 이번에는 생각보다 정리할 것이 많아서 아주 식겁했습니다. 분량이 다른 것보다 1.5배나 많아서 죽는 줄 알았거든요. ^^;;;;

이것 참... 역시 어림짐작으로 대충 가늠했더니만, 이런 일이 생기는군요. ㅡ_ㅡa... 이것 말고도 대충 대충 잡아 놓은 부분이 아주 많은데... 살짝 겁이 나기 시작했습니다. 올해 안에 끝낼 수나 있을지 모르겠네요. 이건 뭐... 미친 듯이 정리하지 않는 한 어렵겠다는 생각도 얼핏 들었습니다.

어쨋거나 시작한 일이니 마무리는 해야겠고... 도중에 그만두자니 성격에 안 맞고... 역시 전 고생을 사서하는 타입인 것 같습니다. ;) 죽이 되던 밥이 되던 달려 봐야겠습니다. ;)

이크... 벌써 또 이렇게 시간이 됐군요. 이만 자야겠습니다. 다들 좋은 밤 되세요

ps) 맨 앞의 그림은 Divide by zero 예외를 발생시켜서 임시 예외 핸들러를 부른 화면입니다. 아주 허접하지만 Milestome 용으로 올려 봅니다. ;)

오늘 블로그를 돌다가 Xeraph 님의 블로그에서 재미있는 글을 봤습니다. “인텔 기가비트 NIC의 성능 향상 기법”이라는 내용이었는데, 원문은 http://xeraph.egloos.com/4808876 에서 보실 수 있습니다.

내용을 간단히 요약하자면 기가 비트쯤 되면 초당 무시무시한 패킷이 오고 가는데, 이것을 패킷이 올 때마다 인터럽트를 발생하게 하여 처리하면 인터럽트 처리의 오버 헤드 때문에 시스템의 전체적인 효율이 떨어진다는 것입니다. 어차피 패킷은 주기적으로 들어온다고 가정하면 인터럽트가 아닌 타이머를 사용할 수 있고, 주기적으로 패킷을 한꺼번에 읽도록 하면 효율을 높일 수 있다는 내용입니다.

실제로도 인터럽트가 자주 발생하면 현재 수행 중인 컨텍스트를 저장하고 복원하는 오버 헤드 때문에, 시스템의 성능이 급격히 떨어지게 됩니다. 저도 그런 경험을 한번 했었는데, 이 글을 읽고 나니 번뜩 떠오르더군요. 예전에 2003년쯤 자작한 kkama OS를 구동시키기 위해 펜티엄 2 233Mhz를 가진 노트북을 샀었습니다. Dell사 꺼였는 데, 플로피 디스크를 내장하고 있었기 때문에 상당히 메리트가 있었지요. ㅎㅎ

OS를 만들면서 GUI도 갖다 붙이고, HDD도 갖다 붙이고 하다가 장난 삼아(?) 시리얼 포트 드라이버를 만들 때였습니다. 전송 속도를 115200으로 맞춰 놓고 PC에서 노트북으로 데이터를 전송했더니, 정상적으로 패킷이 수신되지 않는 문제가 발생했습니다. 이상하다 싶어서 전송하는 동안 아무런 작업을 하지 않았더니 제대로 수신되더군요.

몇 번을 반복한 결과 시리얼로 패킷이 전송되는 동안 OS가 비정상적으로 느려지고, 마우스와 키보드, 그리고 HDD의 인터럽트, 그리고 인터럽트 불가 지역을 동시 다발적으로 수행할 때 패킷이 빠진다는 것을 알았습니다. 순진하게 시리얼 포트의 인터럽트가 발생할 때 마다 패킷 하나씩만 읽어 가서 FIFO에 남은 패킷이 계속 인터럽트를 유발했던 것이지요. 그러다 보니 처리가 늦어지고  패킷은 FIFO에서 밀려 사라지고... 등등의 문제가 발생했었습니다.

해결 방안은 간단했습니다. 시리얼 포트의 FIFO 크기를 늘리고, 인터럽트가 발생했을 때 마다 FIFO에 있는 데이터를 모두 읽음으로써 인터럽트의 발생 회수를 줄인 것입니다. 더불어 인터럽트 불가 영역을 줄여서 인터럽트에 좀더 빨리 반응하도록 한 것도 도움이 됐습니다.

안 그래도 지금 OS를 새로 만들고 있는데, 이런 점을 고려해서 잘 만들어야겠다는 생각이 드는군요. 그 동안 잊고 있었는데, 이점을 고려하면서 해야 할 것 같습니다.

에궁... 그럼 이만 또 자야겠네요. ㅎㅎ 다들 좋은 밤 되세요 ;)

에궁... 테스트 버전의 키보드 드라이버를 MINT64 OS에 추가했습니다. ^^;;; 예전에 만든 OS는 필요한 키만 추려서 처리했는데, 이번에는 다 처리하도록 만들었습니다. 뭐 아직 정리가 좀 덜 되긴 했지만, 역시나 기록을 남긴다는 차원에서... ^^;;;

회사에서 맡은 일도 어느 정도 해결 한지라 부담 없이 작업에 몰두했더니, 밤이 꽤 깊었네요. 이만 자야겠습니다 . 자세한 포스팅은 내일 해야겠군요. ㅎㅎ 그럼 좋은 새벽(?) 되세요 ;)

안녕하세요, kkamagui 입니다. ;) 새해가 되어 처음으로 하는 포스팅이군요. 그간 일이 좀 있어서, 일도 좀 하고(휴가인데 말이죠... ㅠㅠ) 코드 정리 작업을 병행하다 보니 이제서야 하나 올립니다. ㅎㅎ 아우 휴가를 정신 없이 보냈네요. 그나마 위로 일찍 올라 왔으니 이 정도는 한 것 같습니다. 계속 밑에 있었다면 아마... GG ㅠㅠ

이제 월요일이 되면 다시 회사로 가야 하는 데... 끔찍하군요. 어디 짱 박혀서 하고 싶은 것만 하고 살 수는 없을까 심히 고려 중입니다. 나이라도 어리면 과감히 퇴사하고 다른 것에 뛰어들어 볼 텐데... 좀 있으면 꺾인 환갑이라 그럴 수도 없네요. ^^;;;; 그냥 회사 다니면서 잠 좀 줄여 이것 저것 하는 정도 밖에는.... 그나마 졸졸하던 칼퇴도 이번 달부터는 힘들듯... ㅠㅠ (아아~ 이거 난 언제 자라는 말이냐... ㅠㅠ)

위에 그림은 새로 정리해서 만든 MINT64 OS의 스크린 샷입니다. 점점 소스 공개가 불투명해지고 있는 상황에서 이런 스크린샷을 올리는 게 과연 옳은 일인지는 모르겠지만... 개발 기록을 남긴다는 차원에서 꾸준히 올리고 있습니다. 어찌됐던 빨리 마무리 되었으면 좋겠는데... 점점 알 수가 없네요. ㅠㅠ

앗... 벌써 시간이 이렇게... 일단 자야겠습니다. ^^;;; 다들 좋은 밤 되시고... 아 아니구나... 좋은 아침 되세요 ;)

http://kkamagui.tistory.com/614에 제 PC에서 테스트한 A20 게이트의 이상 증세에 대해 글을 남겼습니다. 생각 외로 많은 분들이 관심을 가져 주셨는데, 그 중에서 A20 게이트에 따른 주소 공간의 변화에 대한 내용을 한번 정리할 필요가 있어서 글을 하나 끄적 거립니다.

A20 게이트는 아시는 분은 아시겠지만 어드레스 라인 20bit에 관련되어 있습니다. 즉 A20 게이트가 비활성화 될 경우 어드레스 라인 20bit가 강제로 0으로 설정되어 홀수 Mbyte에 접근되지 않는 것이지요. ^^;;;; 물론 코드에서 홀수 Mbyte에 접근할 수 있지만 이것은 다시 짝수 Mbyte에 맵핑됩니다. 아래 그림을 보시면 한눈에 알 수 있습니다. 3Mbyte + 64Kbyte 영역에 접근하는 예를 나타냈습니다.



따라서 이 때문에 코드에서 사용하는 선형 주소는 짝수 Mbyte에 중복 맵핑되는 결과를 가져옵니다. 이로 인해 전체적인 주소 공간은 아래 그림과 같이 변환됩니다.

따라서 1Mbyte 이하의 위치에서 코드가 실행되는 상태에서 1Mbyte ~ 6Mbyte 까지 영역을 모두 0으로 초기화하는 프로그램을 실행한다면, 1Mbyte ~ 2Mbyte 영역을 초기화하는 순간 자신이 실행 중이던 코드 영역(1Mbyte 이하에 있는)을 모두 0으로 초기화하게 됩니다. 실행되는 코드는 1Mbyte 이하의 어드레스에 존재하므로 프로세서는 온통 0x00으로 도배된 코드를 실행하게되고, 이는 잘못된 인스트럭션이므로 예외(Exception)이 발생하게 됩니다. 즉 프로그램이 멈추거나 리부팅하게 됩니다.

이전에 글을 대충썼더니만, 증상에 대해서 오해하시는 분들이 있어서 다시 한번 정리합니다. ^^
휴일인데도 이런걸 하고 있는 걸 보면... 역시... ㅠㅠ)-b 골방 폐인인듯... ㅎㅎ

그럼 다들 즐거운 연말 보내세요 ;)

회사에서 시간이 좀 남아서 정리를 하던 중에, 재미있는 글을 발견했습니다. 글 주제는 Core의 수가 점점 증가하는 것이 대세이고, 이것을 효율적으로 지원하는 것이 처리 속도를 향상시키는데 도움이 될 것이라는 내용이었습니다. 그 문서에 Intel 사이트의 웹페이지 링크가 첨부되어 있었는데... CPUID를 사용해서 물리적인 Core Processor와 Hyper Threading Logical Processor의 수를 검사하는 방법이 나와 있었습니다.

나름대로 깔끔한 문서라서 회사에서 킵(?) 한 다음 집에 와서 키워드로 검색하니, 이번에는 동영상 강의가 나오더군요. @0@)-b PDF로 작성된 문서보다 훨씬 깔끔하게 정리되어 있어서 공유 차원에서 올립니다. 동영상 강의는 http://software.intel.com/en-us/articles/hyper-threading-technology-and-multi-core-processor-detection 에서 볼 수 있습니다.

제가 만드는 MINT64 OS에서는 Performance를 크게 고려하지 않기 때문에, Core Processor인지 Hyper-Threading Logical Processor 인지 굳이 구분하지 않습니다. 만약 같은 Package에 있는 같은 Core인가, 아니면 같은 Core에 있는 Hyper-Threading Logical Processor인가 판단하여 적절하게 스케줄링하면 보다 높은 Performance를 낼 수 있을 것 같지만... 자세한 건 실제로 벤치마킹한 문서를 봐야 알 것 같습니다. 나중에 시간 나면 Core나 Hyper-Threading에 따라서 어떻게 스케줄링해야 하는지도  한번 봐야겠습니다. ㅎㅎ

차 시간이 다가와서 이만 가야겠군요. ;) 다들 메리 크리스마스~!!!

image

어제 후배에게 테스트를 부탁한 뒤로 생각한 것인데, 각 PC 별로 64bit 및 멀티 코어 검사에 문제가 없는지 확인할 필요가 있을 것 같습니다. 지금 상황으로 보니 프로세서가 64bit 모드를 지원하더라도 BIOS나 기타 문제 때문에 64bit로 전환되지 않는 문제가 있는 것 같더라구요. ㅎㅎ

좀더 자세한 내용은 실제로 테스트를 해봐야 알겠지만... AMD 프로세서 쪽도 체크해 볼 필요가 있을 것 같습니다. 지금까지는 Intel이나 AMD나 64bit 쪽 전환하는 과정이 같다고 가정하고 작업을 했었는데... 순간 아닐 수도 있다는 생각이 들었습니다. 마침 이번 주가 즐거운 크리스마스고 고향집(홈 스윗 홈~!!!)으로 내려갈 예정이니 고향집에 있는 PC(AMD PC)를 마구 굴려서 정보를 뽑아 낼 예정입니다. 그리고 테스트 결과를 여기 블로그나 스프링노트쪽에 올려야겠습니다.

이거 원~!!! 할 일이 태산이군요. ;) 그나마 다행인 것은 틈틈이 책을 좀 봐서 리뷰는 대충 끝냈다는 거~!!! 이제 문서만 만들면 되는데... 왜 이렇게 문서를 만들기가 귀찮은지... 그냥 스프링노트에 끄적거린걸 바로 날려 버리고 싶은 충동이 마구 마구 밀려옵니다. ㅠㅠ)-b 그래도 처음하는 리뷰이니만큼 신경을 좀 쓰긴 써야 할 것 같군요. ㅎㅎ 아흙~!! ㅠㅠ

에궁... 이제 그만 슬슬 자야겠습니다. 사실 잔다기 보다는 몬스터 헌터 2G에 재미를 붙여서 그거 좀 하다가 잘려고... (‘’ )a... 이래도 되는 건지 잘 모르겠군요. ㅠㅠ)-b

그럼 다들 좋은 밤 되시고, 크리스마스 준비 잘하시길~ ;)

ps) 윗부분에 스크린샷은 A20 게이트를 활성화하고 찍은 겁니다. ㅎㅎ 뭐 키보드 컨트롤러를 사용해서 On 하는 건 이제 구식이라 BIOS와 시스템 컨트롤 포트를 사용해서 깔끔하게 처리했습니다. ;) 세상 참 좋아졌군요. ㅎㅎ

지금 A20 Gate에 대한 내용을 정리하고 있습니다. 뭐 예제로 보는 것이 가장 확실해서 간단한 예제를 하나 만들어 제 PC에 동작시켜 봤는데... 일반적인 상황이라면 분명히 죽어야 하는 예제인데 이상하게 버젓이 살아서 동작하는 겁니다. @0@... 혹시나 해서 이것 저것 테스트 해봤습니다만, A20 Gate 쪽이 완전히 동작하지 않는 것 같았습니다. 이제 XT 시절에 쓰던 프로그램을 다시 돌릴 일이 없으니, 무의미하긴 하지만.... 없으니 뭔가 좀 허전하더군요. 에러를 발생시키기 위해서 A20 Gate를 비활성화 했음에도 불구하고 잘 동작하는 것 보면 작동 안 한다고 보는 것이 맞겠지요. ㅎㅎ

혹시나 해서 후배 PC에 돌려봤는데, 일단 후배 PC는 자동으로 A20 Gate가 켜지는 건 아닌 것 같았습니다. A20 Gate를 끄고 OS를 부팅했을 때는 계속 리부팅 되더라구요. ^^;;; 그런데 이상한 점은 64bit 모드로 전환되지 않는 다는 것이었습니다. 정상적인 상황이라면 64bit로 전환되어 커널이 실행되어야 함에도 불구하고 64bit로 전환하는 곳에서 멈춰 있었습니다. ㅡ_ㅡa...

원인은 좀 더 살펴봐야 알겠지만... 살짝 골치가 아프네요. ㅎㅎ 이거 원... 프로세서가 64bit를 지원하는 것 만으로는 안되는 것이 있나 봅니다. ㅠㅠ 어흑... 머리야...


ps) A20 게이트와 주소 공간에 대해서는 따로 정리를 한번 했습니다. ;)

http://kkamagui.tistory.com/619

아우~ 이번 내용에 대한 정리는 지난 주부터 시작했는데, 이것 저것 일이 많아서 진도가 굉장히 안 나가는군요. ㅠㅠ 특히 온 주말을 디버깅에 투자했더니 더 그런 것 같습니다. ㅎㅎ 사실 한번 만들었던 걸 다시 만들려니 더 진도가 안 나가는 것 같기도 하네요. ㅎㅎ

드디어 기나긴 어셈블리어의 늪을 빠져 나와 C 코드로 접어들었습니다. 이제 대부분의 작업을 C 코드로 할 수 있겠군요. ㅎㅎ 물론 중간 중간에 꼭~!!! 어셈블리어로 처리해야 하는 부분이 있어서 완전히 빠져 나왔다고 보기는 어렵지만, 어찌되었든 C 코드를 쓸 수 있다는 데 의의가 있으니... ^^;;;

아흙...회식에서 술을 좀 퍼먹고 왔더니, 체력이 거의 바닥입니다. ㅎㅎ 자면서 코딩해서 내일 다시 뒤집어 엎는 게 아닌가 슬슬 걱정이 되는군요. 일단 뭐 대충 이만하면 됐으니 그만 자야겠습니다.

다들 좋은 밤 되세요 ;)

거의 이틀 간의 삽질 끝에 부팅에 성공했습니다. ;) 물론 한번에 성공한 건 아니고, 여러 문제가 있었습니다. ^^;;;; 것 참... 버그가 한 두 개가 아니더군요.


첫 번째 버그는 IDE 하드를 체크하는 루틴에 있었습니다. 가상 PC에서는 IDE를 사용한다는 가정하에 코드를 작성했는데, 실제 PC는 SATA였기 때문에 동작하지 않더군요. ^^;;; 원래는 타이머를 체크하면서 검사하게 되어 있었는데 인터럽트 불가 루틴이 앞에 있어서 결국 타이머가 이벤트가 발생하지 않았고 무한 루프를 돌았다는... ㅠㅠ


두 번째 버그는 대충 만든 동적 메모리 할당 루틴 때문이었습니다. 이상하게 어디서 int 타입으로 계산했는지 2GB 이상의 어드레스의 메모리를 할당 받으면 sign extension이 일어나서 Unsigned Long 타입으로 받았을 때 상위 32bit가 모두 0x0F로 설정됐습니다. ㅠㅠ  가상 PC에는 메모리를 최대 64MB로 설정해 놨기 때문에, 발견되지 않았더군요. 크윽...


세 번째는 MTRR 레지스터를 잘 못 설정해서 생긴 문제였습니다. ㅠㅠ 어설프게 배웠더니(?) 홀수 MB 메모리는 캐시를 사용하도록 설정하고 짝수 MB는 캐시를 사용 안 하도록 설정했더군요. 그 덕분에 굉장히 느린 GUI 화면을 볼 수 있었습니다. ㅡ_ㅡa... 어찌나 느리던지... RDTSC를 통해 CPU 속도도 재보고, 프로파일러를 만들어서 화면 업데이트 속도도 재 봤는데... 헉... 초당 3 프레임 정도 나왔습니다. 하도 이상해서 램, 비디오 램 두 영역을 잡아서 1024 * 768 * 2 Byte를 동일한 함수에서 채워 봤습니다. 얼래... 램이랑 비디오 램이랑 둘 다 비슷하더군요. ㅡ_ㅡa... 램 영역은 캐시를 활성화 하도록 했기 때문에 원래대로라면 램이 더 빨라야 하는데 말이죠. ^^;;;; 결국 잘못 셋팅해서... ㅠㅠ


이런 자잘한(?) 문제를 다 해결하고 나서야, 광속(?)으로 동작하는 MINT64 OS를 볼 수 있었습니다. 코드 두줄 바꿨을 뿐인데 정말 빠르더군요. ㅠㅠ)-b 크윽... 초당 3프레임 나올 때는 진짜 띵~ 하던데...ㅠㅠ 기념으로 사진을 찍어서 올립니다. ㅎㅎ 동영상을 찍고 싶었지만 카메라가 꾸져서... 다음에 디카를 사면 한번 찍어 올리겠습니다. ㅎㅎ


이제야 다시 정리(?)하는데 집중할 수 있겠군요. 덕분에 주말의 2/3을 날렸네요. ㅎㅎ 그래도 기분은 좋습니다. ;) 앗싸 MINT64 OS 만세~!!!


ps) 이번에 좁은 책상을 버리고 퍼즐 형태의 사무용 책상으로 바꿨더니 작업 능률이 200%는 올라간 것 같습니다. 역시 작업 환경은 무조건 좋고 봐야 합니다. ;) 그지? 후배야? ㅋㅋ

지금까지 만들기만 실컷 만들고 플로피 드라이브와 디스크가 없어서 테스트를 못하고 있었습니다. 그러다 오늘 문득 USB에 심으면 바로 테스트 할 수 있겠다는 생각이 들더군요. 그래서 부트 로더를 좀 수정한 다음 USB에 옮겨 담으니 떡!! 하고 부팅이 됐습니다. @0@)-b

물론 한번에 된 건 아니고, 이것 저것 설정 문제 때문에 삽질을 좀 많이 했습니다. 대략 8시부터 시작했는데, 벌써 2시군요. ㅡ_ㅡa... 거의 6시간 동안 작업했다는.... 그런데 좀 이상한 건 듀얼 코어 활성화에 64bit 전환, 그리고 램도 거의 4기가까지 잘 잡히는데... 윈도우가 굉장히 느리더군요. ㅡ_ㅡa... 뭔가 이상했습니다. 가상 머신에서 테스트하는 것 보다 더 느리게 동작했습니다. ㅠㅠ

hlt() 루틴도 빼 보고 타이머 인터럽트의 회수도 줄여 봤지만... 테스트를 하면 할수록 클럭의 속도가 낮게 잡힌 것이 아닐까 하는 생각이 들더군요. 물론 BIOS에서 스피드 스텝 옵션은 끈 상태였습니다. 아우... 당췌 무슨 일인지... 일단 오늘은 밤이 늦었으니 이만하고... 내일은 튜닝을 좀 한 다음 인증 샷을 올리겠습니다. ;)

그럼 다들 좋은 밤 되세요 ^^)-b

ps) 정리해야하는데, 다시 일을 벌이는 듯한 느낌이군요. 만약 스피드 스텝쪽 문제라면 왠지 챕터 하나가 더 늘어날 듯 하다는... ㅠㅠ 아흙... 미쵸...

OS를 만들면서 지금까지는 makefile을 거의 배치 파일 수준으로 사용하고 있었습니다. 이게 무슨 말이냐 하면... 디렉토리에서 소스 파일 이름만 달랑 추출하고, .C 파일과 같은 소스 파일이 수정되었을 때만 커널을 다시 빌드한다는 이야기입니다. 귀차니즘때문에 이렇게 쓰시는 분들이 많을 것 같다는... ^^;;;; 이렇게 되면 헤더 파일이 수정되었을 때, 해당 헤더 파일을 당겨쓰는 .C 파일들이 자동으로 빌드되지 않기 때문에 문제가 생깁니다.

뭐, 사실 혼자 테스트 할때는 매번 Clean해서 전부 삭제하고 다시 빌드하면 되니 신경을 안썼는데... 거사(?)를 치루려다 보니 이런것 하나하나가 신경 쓰이더군요. 결국 makefile을 뒤엎어서 의존성 관련 부분을 추가했습니다. 거의 3시간 정도 이것만 한 것 같네요. ㅠㅠ

C 파일로 부터 의존성 정보를 뽑는건 아주 간단합니다. "gcc -c -M Main.c Main2.c > a.txt" 와 같이 옵션을 주면 아래와 같이 이쁘게 출력해 줍니다. 이렇게 생성한 a.txt 파일을 makefile에 포함시켜주면 나머지는 규칙에 따라서 알아서 빌드해 줍니다. :)
Main.o: ../Source/Main.c ../Source/Main.h
Main2.o: ../Source/Main2.c

makefile에 포함시키려면 다음과 같이 써주면 됩니다. $(wildcard a.txt)는 디렉토리에서 a.txt 패턴이 들어간 파일명들을 스페이스바로 구분한 리스트를 나타내며, ifeq는 두 항목을 비교하는 것입니다. 즉 아래 코드는 같은 디렉토리에 a.txt가 있으면 해당 파일을 makefile에 포함시키라는 의미입니다.
ifeq (a.txt, $(wildcard a.txt))
include a.txt
endif

위의 내용을 추가해서 만든 makefile을 실행한 것입니다. 의존 관계에 대한 정보가 아주 자알~ 생성되고 있음을 볼 수 있습니다. ;)
C:\MINT64\01.Kernel32>make dep
make -C Temp -f ../makefile InternalDependancy
make[1]: Entering directory `/c/MINT64/01.Kernel32/Temp'
gcc.exe -c -M ../Source/Main.c ../Source/Main2.c > .dependancy
make[1]: Leaving directory `/c/MINT64/01.Kernel32/Temp'

아아~ 이거 원... 마음이 급해서 날림으로 만들었더니, 이런데서 시간을 많이 잡아먹는군요. ㅎㅎ 하루를 그냥 날린 것 같습니다. ㅠㅠ 나머지 작업은 할 수 없이 내일 해야겠네요. ;)

그럼 다들 좋은 밤 되세요 ;)

에궁 에궁~ 요즘 글 정리하랴 OS 코드 정리하랴 정신이 없습니다. 정리하던 도중에 OS의 구조가 바뀌는 바람에 또 한번 식겁(?)을 하고 겨우 다시 원점으로 되돌려 놨습니다. ^^;;;; 지난번까지는 모두 어셈블리어로 작업을 했었는데, 이제 C 코드를 같이 빌드할 수 있게 되었습니다. 덕분에 작업이 더 수월해 지겠군요. >ㅁ<)-b

image

아우~ 했던 작업을 또 할려고 그러니 귀찮은 것도 있고, 정리도 하려니 시간이 아주 좔좔 들어가는군요. ㅠㅠ 잠을 좀 자긴 자야 할텐데... 큰일입니다. ^^;;;; 일단 오늘도 늦었으니 이만 자고 나머지는 내일 정리해야겠군요.

다들 좋은 밤 되세요 ;)

에궁... 좀 전까지 해서 보호 모드로 전환하는 내용까지 대충 마무리했습니다. 이제 좀 더 손본 다음 메모리를 잠시 정리하고 64bit로 전환하면 되겠군요. 화면 캡처하랴 그림 그리랴 표 만들랴 완전 정신 없습니다. ㅠㅠ

아우 어찌나 길고 험난한지... 아주 죽을 맛입니다. ㅠㅠ 그래도 찔끔 찔끔 진도가 나가고 있으니 그나마 다행이네요. ㅎㅎ 일단 오늘은 몹시 피곤하니 일찍 자야겠습니다. 다들 좋은 밤 되세요 ^^

에궁~ 드디어 지루했던 부트 로더에 대한 내용을 완료했습니다. 이제 32bit 보호 모드로 전환하는 과정부터 해서 64bit 모드로 전환하는 과정까지의 내용을 다룰 차례인데, 이것 또한 한 두 챕터로 끝날 것 같지 않네요. ^^;;;; 64bit 모드로 전환하는 내용까지만 어찌 어찌 진행되면 나머지는 내용이 그리 많지 않을 것 같은데 말이지요. 끄응...

12월에 거사를 치를 생각인데, 개인적인 바램은 거사 전에 64bit 모드 전환까지 내용을 다룰 수 있었으면 하는 것입니다. 사실 앞부분이 CPU에 굉장히 의존적인 부분이라 설명할 것도 많고, 구현 할 것도 많거든요. ㅠㅠ 아흑... 이제 곧 12월인데 가능할지 모르겠습니다. 목차도 한번 정리해야 하는데... 정신 없이 뽑았더니 목차를 너무 세분화해서 한 챕터 분량이 아닌 것도 더러 있었습니다. 아흑... 진짜 미쵸... ㅠㅠ

일단 오늘은 몸이 않 좋아서 일찍 자야겠습니다. 그리고 나서 내일은 무한 버닝~!!!! @0@)-b 주말에 콱 그냥 다 써버리는 센스를~!!! ㅎㅎ

그럼 다들 좋은 밤 되세요 ^^)/~

요즘 일 때문에 MINT64 OS라는 이름으로 새로 코드를 정리하고 있습니다. ㅎㅎ 이번에는 부트 로더에 OS 이미지를 로딩하는 기능을 추가하는 내용 때문에 만들었는데, 로딩하는 기능을 만들고 나니 커널이 없어서 테스트할 수가 없더군요. ㅠㅠ 그래서 가상 OS 이미지를 만든 후, 이를 부트 로더가 로딩하여 실행하도록 했습니다.

1024 섹터의 가상 OS 이미지를 만들어야 했는데, 처음에는 코드 블럭을 매크로를 만들어서 반복하려고 했습니다. 그런데 동일한 매크로를 1024번 반복해서 입력하려니 이것도 일이더군요. ㅡ_ㅡa.. 그래서 NASM 문서를 살펴봤더니 묘수가 떠올랐습니다. 바로 전처리기 문법을 사용하는 것입니다. 전처리기를 사용하니 엄청 간단하게 되더군요. @0@)-b 나중에 NASM 전처리기 문법에 대해서도 한번 정리할 필요가 있을 것 같습니다.  ㅎㅎ

아래는 가상 OS 이미지를 부트 로더가 로딩한 후 실행한 화면입니다. 1024개의 0~9가 정상적으로 실행되었다는 것을 표시하고 있습니다.

이제 조금만 더 정리하면 32bit 커널까지 가겠군요. 어찌 이래 갈 길이 먼지... ㅎㅎ 진짜 시간이 장난 아니게 걸리네요. ㅎㅎ 뭐 설마 밑 빠진 독에 물 붓기겠습니까? ^^;;; 언젠가는 차겠지요. ㅎㅎ

에궁~ 이만 자야겠습니다. 다들 좋은 밤 되세요. ㅎㅎ

오늘도 어김없이 글을 정리하면서 BIOS 서비스 루틴에 대해서 쓰고 있었습니다. 보통 위키피디아를 많이 찾는데, 오늘은 왠지 구글신에게 물어 보고 싶더군요. 역시나 멋진 링크를 보내 주셨습니다. 만세~!!!!


http://bioscentral.com/misc/biosservices.htm

http://www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/inte1at0.htm


위의 링크로 가면 BIOS 서비스 루틴 및 기타 BIOS 관련 자료들을 쉽게 찾을 수 있습니다. 아주 잘 정리되어 있더군요. ㅎㅎ 좋구로~!! 이렇게 일거리가 또 하나 줄어든다는~!!!

아래는 이번에 정리하면서 새로 만든 부트 로더의 화면입니다. 아무래도 따라하기 식의 내용이다 보니, OS를 완전히 처음부터 다시 만들고 있습니다. ㅎㅎ 이제 조금만 더 있으면 OS 이미지를 로딩하고 실행하는 화면이 나오겠군요. ;)

OS 이름 때문에 상당히 고민했는데, 그냥 MINT(민트)64 OS로 정했습니다. Multi-core INTelligent 64bit OS의 약자로 멀티 코어를 지원하는 똑똑한 64bit OS라는 의미입니다. ㅎㅎ 약간 촌스럽긴 하지만, 여자 친구의 강력한 지지가 있어서.. ^^;;; (후배야 쏘리 ㅠㅠ 횽 맘 알지? ㅋㅋ)

어휴... 코딩하려 글 적으랴... 내용 검증하랴... 시간이 무지 부족하군요. ㅡ_ㅡa... 이래서는 영 답이 안 나오는 데... 어떻게 해결 방법을 찾아야겠습니다. 반드시 말이죠. ㅠㅠ

엇, 고민하는 사이 벌써 잘 때가 됐군요. 다들 좋은 밤 되시고, 감기 조심하세요 ;)

여자 친구가 와서 주말 내내 바이오 하자드를 했습니다. ㅡ_ㅡa.. 역시 여자 친구가 헤어나질 못하더군요. ㅎㅎ 어찌나 재미있어 하던지… 덕분에 벌써 Easy 모드 끝판을 깼습니다. ㅡ_ㅡV 여자 친구가 기뻐하는 모습을 보니 사기를 잘했다는 생각이 드네요. ^^;;; 평소에 뭐하나 제대로 해준 게 없었는데, 이걸로 어느 정도 만회한 것 같습니다. 앗싸~!!!

덕분에 이번 주말은 거의 진도를 못 뺐네요. ㅎㅎ 그래도 세상에서 가장 간단한 부트 로더(?)를 만드는 내용까지는 진도를 나갔으니 다행입니다. 어찌나 간단한지 정신이 휑~ 해질 정도입니다. 이래서야 욕이나 얻어 먹지 않을까 걱정이 되는군요. ^^;;;;; 그래도 처음에는 뭐든지 다 힘들고 어려우니, 이 정도 내용은 되야 어떤 사람(?)이라 충분히 따라올 수 있을 꺼라고 위로하면서 쓰고 있습니다. 과연... 그럴지는 저도 잘… ㅠㅠ

개구리가 올챙이적 모른다고... 처음에 OS를 만들 때는 힘들고 어려운 게 사무쳐서 내가 나중에 잘 알게 되면 이런 이런 내용을 주로 다뤄야겠다고 생각 많이 했었는데... 지금은 그런 내용들이 하나도 생각 안 나는군요. 오히려 지금은 당연히 알고 있어야 하는 내용이라고 생각도 하는 부분도 있어서 상당히 조심스럽습니다. 아무래도 이런 가정들이 하나 둘 늘어 가다 보면, 중요한 내용을 빠뜨릴 것 같다는 느낌 때문일 겁니다. ^^;;;

어휴… 역시나 쉽지 않군요. 그래도 일단 달려 보겠습니다. 듬직한 후배들만 믿고 말이죠. ;)

ps) 이 글을 보고 있는 후배야... 바로 너란다 ㅋㅋ 앞으로 잘 부탁하께 ㅋㅋ

아아~ 이거 글 쓰는 일이 쉽지 않군요. 챕터 하나 쓰는데 거의 3주 동안 하고 있습니다. 물론 그 중에 2주는 퇴근을 완전 늦게 해서 작업할 시간이 부족한 것도 있지만… 내용 자체가 워낙 많다 보니 장난이 아닙니다. @0@

지금 A4로 거의 30쪽째 쓰고 있는데, 퇴고 할 때마다 자꾸 내용이 추가됩니다. ㅠㅠ 챕터의 주제는 64bit 프로세서에 대한 내부 설명입니다만, 왜 이걸 넣었는지 후회가 되는군요. 실제로 코딩을 진행하면서 각 챕터 관련된 부분은 다시 설명할 예정이라 간단하게 정리하려고 시작했는데, x86-64 프로세서가 워낙 복잡하다 보니 쉽게 끝나지가 않습니다.

리얼 모드 + 보호 모드 + IA-32e 모드의 3가지에 대해서 각각 세그먼테이션, 페이징에 대해 설명하니 총 5개 정도가 되고, 그 앞에 각종 레지스터와 모드에 대한 설명이 또 들어가니 양이 정말 장난 아닙니다. ㅠㅠ 쓰는 것도 일이지만 퇴고하는 것도 일이군요. 어제 오늘 거의 4시간씩 투자하면서 읽고 수정했는데 아직 1/3이 남았다는… 크윽…

그래도 이번 챕터만 지나가면 다음부터는 직접 코딩하면서 만드는 과정이기 때문에, 이렇게 오래 걸리진 않을 꺼라 생각합니다. (사실 이거 하나 보고 계속 달리고 있는 중입니다. ㅠㅠ 도중에 몇번이나 목차에서 챕터를 날리고 싶은 충동이 밀려와서… ㅠㅠ)

아흑… 또 시간이 이렇게 흘렀군요. 언능 자고 내일도 최대한 빨리 와서 마무리 해야겠습니다. 에궁… 진짜 이건 아닌데… ㅠㅠ

그럼 다들 좋은 밤 되시길 ;)

이번 주말은 좀 특별해서 시간이 많이 날 줄 알았는데, 결혼식이다 뭐다 하는 바람에 결국 시간에 쫓기고 말았습니다. ㅠㅠ 주말에 해야지 하면서 잡았던 스케줄은 엉망이 됐습니다. 이궁…

결국 이렇게 되면 또 평일에 번개같이 집으로 달려와서 이것 저것 하는 수 밖에 없는데… 어쩔 수 없군요. 이번 주도 미친듯이 집으로 달려와야겠습니다. @0@)-b 물론 며칠이나 가능할지는 두고 봐야 알겠지만 말입니다. ㅎㅎ

요즘 계속 글 쓰는게 어렵다는 생각을 합니다. 예전부터 느끼고 있던 거였지만, 요즘 들어 쓰는데 시간을 많이 투자하다보니 더 깊이 와 닿습니다. 정말 무슨 책이라도 한권 봐야할까요? ㅠㅠ 이럴 줄 알았으면 책이라도 왕창 읽어 놓는건데… 한참을 쓰다 보면 내가 무슨 말을 하고 싶은 건지 잊어 먹는 경우도 종종 있고, 적당한 어휘가 떠오르지 않아 한참을 고민하는 경우도 많습니다. 아무래도 국어가 따리는거 같네요. ㅠㅠ

아흑… 계속 쓰다보면 좀 나아지려나… 글짓기에 소질이 없어서 그런가보다 하고는 있는데, 무지 힘들군요. ㅎㅎ 그래도 시작한 일이니 계속 해야겠지요. ;) 일단 열심히 해볼 생각입니다. @0@)-b 홧팅~!!!

헛… 벌써 시간이 이렇게… 이만 자야겠습니다. 다들 좋은 밤 되세요~ ;)

ps) elf64 관련 문서는… 결국 주중에 업데이트 해야겠네요. ㅠㅠ)-b 아흑…

소프트웨어 멤버십에서 활동할 때 자료 남기는 습관이 든 이후로,  뭘 했다 하면 주절 주절 적어 놓는 게 버릇이 됬습니다. 메모장은 보통 회사 밖에서는 스프링노트(http://kkamagui.tistory.com)을 많이 쓰고, 요즘은 회사 때문에 미투데이(http://www.me2day.net/kkamagui)를 씁니다. 회사에서는 블로깅하기도 힘들 뿐더러, 회사가 보안이 나름 엄격한지라 외부로 뭘 보내면 의심을 받거든요. ^^;;;;

요즘 OS를 만드는 내용에 대해서 정리를 하고 있는데, 초반 설치부터 GUI 애플리케이션까지 모든 과정을 다 다루려고 하니 쓸게 한두가지가 아니더군요. 쩝쩝 힘듭니다. ㅠㅠ 오늘은 GCC 소스를 이용해서 크로스 컴파일러를 만드는 내용을 좀 적어 봤는데, 예전에 블로그에 남긴 글을 참고하면서 썼습니다. 정말 간단한 메모만 남겼는데 그것 때문에 훨씬 수월하게 끝낼 수 있었습니다. 처음에 크로스 컴파일할 때는 옵션부터 시작해서 빌드 순서까지 수많은 시행착오를 거치며 며칠 동안 했었는데, 오늘은 1시간도 안 걸려서 끝나더군요. ㅠㅠ)-b GCC 소스를 통해 크로스 컴파일러를 만드는 방법은 http://kkamagui.tistory.com/507 에서 볼 수 있습니다.

아흑... 정리란 역시 좋은 것이군요. 이게 없었더라면 주말 다 날릴 뻔 했습니다. ㅠㅠ 얼마나 다행인지... ㅎㅎ 앞으로도 계속 열심히 남겨야겠습니다.

메모 쵝오 >ㅁ<)-b

ps) 그러고보니 스프링노트에 elf64 파일 포맷 재배치하는 방법에 대한 글을 쓰다 말았는데, 언능 마무리해서 포스팅해야겠군요. (근데 볼 사람이 있을라나… ㅡ_ㅡa..)

이거 원… 오늘 메타 블로그 사이트에 들어갔다가 고전 게임인 테트리스에 저작권이 걸려있다는 글을 봤습니다. 몇 해전에 그 많던 온라인 테트리스 게임이 사라진 이유도 저작권 계약을 하지 못해서였다네요.

이런… OS에 응용 프로그램으로 테트리스 만드는 걸 하려고 했는데, 다른 게임으로 대체해야겠습니다. ㅠㅠ 이거 원 만들어 놓고도 못쓰니 살짝 답답하군요. 끄응... 그럼 당체 무슨 게임을 만들어야… ㅠㅠ 퍼즐 맞추기 같은 거는 저작권이 없을라나... 아님 피자 먹는 스네이크 게임이라도... ㅠㅠ

혹시 이런 게임이 들어갔으면 좋겠다고 생각하시는 게 있으시면 댓글로 제보 부탁 드립니다. 최대한 반영해서 OS에 넣도록 할테니, 괜찮다고 생각하시는 게 있으시면 바로 댓글 주세요 ;)  정 안되면 퍼즐 맞추기라도 해야... ㅠㅠ

그럼 다들 좋은 밤 되세요~ ;)

아유… 요즘 OS를 대충 만들어 놓은 거에 대해서 글을 좀 적고 있습니다. 글 재주가 워낙 없는지라 진도가 무지 안 나가는군요. 쩝쩝… 특히 앞부분은 기술적인 내용보다는 소설(??)에 가까운 내용들이라 더 진도가 안 나가는 것 같습니다. ㅡ_ㅡa... 그렇다고 안 쓸 수도 없는 일이니… 쿨럭;;;

겨우 겨우 서론 부분을 끝내 놓고 나니 이번에는 환경 구축이 문제로군요. GCC와 NASM을 사용해서 개발했기 때문에 이 두 가지만 설치 가능하면 이론상(?) 어디서든 OS를 개발할 수 있습니다. 물론 GCC가 64Bit 빌드 옵션을 지원하지 않으면 크로스 컴파일러를 만들어야 하는 부분이 추가되긴 하지만... 이러한 수고로움 정도야 OS를 개발하는데 드는 시간과 노력에 비하면 아무것도 아니지요. ㅎㅎ

아아~ 이것 참... 그냥 윈도우에서 개발하는 걸로 못 박기는 그렇고... 이것 저것 차이를 들어서 적자니 귀차니즘이 도지는군요. ㅠㅠ 이 일을 어찌해야... 뭘 정리하는 게 쉬운 일이 아닌 것 같습니다.

크으... 일단 오늘은 이만하고 내일 다시 해야겠습니다. 창작의 고통 + 잠이 몰려와서 죽을 것 같군요. ㅎㅎ

다들 좋은 밤 되세요 >ㅁ<)-b

오늘 간만에 글을 좀 썼습니다. 사실 썼다는 표현보다는 쓰고 있다는 표현이 더 맞는 것 같습니다만… ㅎㅎ  역시나 진도가 안나가는군요. 마이크로소프트웨어 기고할 때도 그랬는데, 역시 서문이 가장 어려운 것 같습니다.

저 같은 경우 본문은 소스 코드 설명이나 현상 설명 같은 내용들을 주로 넣으니 굳이 작문을 할 필요가 없는데, 서문 같은 경우는 그런 내용이 아니라 좀 가벼운 내용들 + 잡설 위주로 쓰는 편이라 상당한 고통이 따릅니다. 말 그대로 “작문”을 해야하니… 말 주변이 없는 저로서는 출산의 고통(?)과 맞먹는군요. ㅠㅠ 끄응… 그래도 넘어야 할 산이니만큼 꾸역꾸역 써야겠지요. ㅠㅠ

아래는 2004년 경에 만든 32Bit OS의 GUI 시스템 화면입니다. 내용물을 비교하자면, 지금 것과 비교하면 완전 최악이지만 GUI 시스템은 그리 크게 바뀌지 않은 것 같습니다. 그때도 상당히 고민했었는데… 지금 생각하니 그 당시는 너무 몰랐기 때문에 복잡하게 구현할 수 밖에 없었던 것 같습니다. 지금 코드는 훨씬 간단한데 말이지요. ㅎㅎ

 

마치 배경처럼 나와 있는 저 까마귀 그림은 제가 손수 그림판으로 그린 거라는… 지금 생각하니 저것도 웃기는 군요. 왜 저걸 그리고 있었을까나… ㅎㅎ 이궁…

에혀~ 밤이 깊었으니 자야겠습니다. 오늘은 좀 일찍 자는군요. ㅎㅎ 내일은 좀 더 일찍자야겠습니다. ;)

 에구에구... 오늘 교육 끝나고 집으로 쏜살같이 달려와서는 그 동안 마음에 걸렸던 부분들을 수정했습니다. 사실 더이상 손대기에는 시간도 부족하고, 목표로 정한 것이 있어서 더이상 구현만 할 수는 없었다는... ㅠㅠ 그래서 완성도는 약간 떨어지지만, 프로토타입을 완료했습니다. ㅎㅎ

 지금까지 진행된 것은 멀티 태스킹 + 파일 시스템 + 동적 메모리 관리 + GUI 시스템 + 기타 시리얼, 마우스, 하드 디스크 드라이버 등등 정도 입니다. 뭐 많이 하긴했는데, 적어놓고보니 별거 없군요. ㅠㅠ 아래는 1.0 버전의 스크린샷입니다.

 파일 시스템이 추가되어서 시리얼로 실행파일을 매번 전송해서 실행하는 번거로움이 없어졌습니다. "Application Pannel"에서 "GUI Shell"을 실행한 다음 루트 디렉토리에 있는 테트리스 실행파일을 load 명령으로 실행하면 테트리스가 실행됩니다. ^^)-b GUI 쉘은 화면을 지우는 cls 명령과 디렉토리를 표시하는 dir 또는 ls 명령만 가지고 있습니다. 

 기념삼아 프로토타입을 테스트할 수 있는 파일을 올립니다. 아래 파일을 다운 받으셔서 압축을 푸신 다음 "qemu64MyOs.bat" 파일을 실행하시면 됩니다. 


 아아~ 오늘도 늦게까지 작업했더니 피곤합니다. ㅠㅠ. 일찍 끝낼 수 있었는데 QEMU가 Single Core 모드로 동작할때 IOAPIC 쪽을 사용하지 않는 걸 몰라서 한참 삽질했습니다. ㅡ_ㅡa... 커널이 잘못된 줄 알고 2시간동안 갈아 엎었습니다. 디버그 코드 덕에 겨우 알았다는... 싱글 코어일때는 PIC를 그대로 쓰도록 바꿔놔야겠군요. ㅎㅎ

 이크~ 저는 이만 자야겠습니다. 다들 좋은 밤 되세요~ ㅎㅎ

 

 
 이번주는 결혼식이다 뭐다해서 그렇게 많은 시간을 투자하지 못했습니다만, 막판 스퍼트해서  파일시스템을 추가하는데 성공했습니다. >ㅁ<)-b 사실 대부분의 코드는 윈도우 환경에서 시뮬레이션하면서 검증했기 때문에, 그냥 컨트롤 C+V 신공으로 끝냈습니다. ㅎㅎ

 그리고 내친김에 GUI 쉘에 dir 기능도 추가했습니다. GUI 쉘을 만든지는 좀 됬지만 귀찮아서 그냥 뒀는데, 점점 불편함이 커지더군요. 쉘 기능이 필요할때는 콘솔 모드 커널로 빌드해서 쉘을 쓰다가 다시 GUI 테스트할때는 윈도우 모드로 빌드해서 부팅하고... 이걸 수백번 정도 반복하다보니 그냥 만드는게 편하겠다는 생각이 들었습니다. 그래서 뚝딱~!!! 만들었습니다(사실 이 일이 더 많이 걸렸다는... ㅠㅠ).

 아래는 GUI 쉘로 루트 폴더와 이미지 폴더를 본 화면입니다. 깔끔하게 잘 나오는 걸 볼 수 있습니다. ㅎㅎ (이미지 윈도우는 /image/image0.img 파일을 읽어서 화면에 표시하도록 수정되었습니다)

 이거 뭐 점점 기능이 추가될수록 갈아 엎는 코드의 양도 많아지는군요. 이번에도 몇군데나 갈아 엎었습니다. ㅠㅠ 처음에는 간단한 OS를 만들자는 생각이었는데, 욕심이 자꾸 생겨서 이것도 추가하고 저것도 추가하게 되네요. 이렇다 언제 거사(?)를 시작하게 될지... ㅡ_ㅡa...

 진짜 내일 동적 메모리 할당쪽 알고리즘만 좀 더 수정하고, 거사를 시작해야겠습니다. 고칠게 있으면 거사를 진행하면서 고치던가 해야겠군요. ㅎㅎ

 내일 교육은... 또 물건너 간 것 같습니다. 푹 자다 올듯... ㅠㅠ
 다들 좋은 밤 되시길 ;)

+ Recent posts