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

드디어 기나긴 어셈블리어의 늪을 빠져 나와 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... 이래서는 영 답이 안 나오는 데... 어떻게 해결 방법을 찾아야겠습니다. 반드시 말이죠. ㅠㅠ

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

 헥헥... 추석 이후에 전주 칼퇴를 목표로 열심히 일찍 퇴근했더니만, 이번주는 꽤 많은 시간을 투자할 수 있었습니다. 덕분에 고민도 많이 했고, 기능도 여럿 추가했습니다. 일단 아래 스크린샷 먼저 보시죠. ^^)/~

 가장 큰 변화는 어플리케이션 패널(Application Pannel)을 추가해서 굳이 GUI Shell을 통하지 않고서도 프로그램을 실행할 수 있게 한 것과, CPU 및 메모리 상황을 표시하는 어플리케이션이 추가된 것입니다.

 어플리케이션 패널은 마우스가 위치했을 때 해당 항목을 붉은 색으로 바뀌게 하여 사용자로 하여금 알기 쉽게 한 것이 포인트입니다. 제가 원래 GUI쪽은 거의 신경을 안쓰는 편인데... 이번은 저 혼자만 볼게 아니라서 신경을 좀 썼습니다.

 CPU 모니터는 일정 시간동안 CPU 부하 및 현재 대기중인 태스크의 수를 표시하도록 되어있습니다. 숫자만 덩그러니 표시하는 건 좀 없어보여서 아래에 그래프도 같이 표시하도록 했습니다.

 메모리 모니터도 CPU 모니터와 비슷한 방식이지만, 좀 다른 점은 아래에 사용량 그래프에 그라데이션 처리가 되어있는 점이랄까요? ㅎㅎ 메모리 사용량이 높아지면 게이지가 점점 올라가면서 붉은 색 계통으로 바뀝니다. 굳이 그럴 필요 없지만... 왠지 뭔가 변화를 줘야할 듯 해서.... 나름 많이 신경썼습니다. ㅡ_ㅡV...

 그외 소소한 변화는... 타이틀 바를 좀 더 진하게 한 것과, GUI쪽에 일부 최적화를 수행한 것 정도입니다. 크게 눈에 보이지는 않지만, 화면을 그리는 속도가 약간(??) 더 빨라졌습니다. ^^  와우~!!!

 아참~ 가운데 보이는 시커먼 화면은 방금 추가된 따끈 따끈한 GUI Shell 입니다. 알맹이는 Console꺼를 그대로 쓰면 되기 때문에, 화면만 먼저 만들었습니다. 처음에는 검은 바탕에 하얀 글씨였는데, 맨 처음 만들었던 32bit OS 생각이 나서 검은색 바탕에 녹색(메트릭스 스타일??)로 바꿨습니다. 한때 선망의 대상이던 모노크롬 모니터처럼 말이지요. ^^;;;;

 어휴~ 만들다보니 상당히 많이 왔습니다. 이제 파일 다운로더 프로그램과 테트리스 정도 만들고 거사(?)를 시작할 생각입니다. 이 정도면 남에게 보여줘도 부끄럽지 않을 것 같으니 말이지요. ㅎㅎ 그나저나 70KByte도 안되는 크기로 참 많은 일을 할 수 있군요. 예전에는 몰랐는데 말입니다. ;) ㅎㅎ

 아래는 지금까지 작업한 내용을 실행해 볼 수 있는 파일입니다. 예전과 마찬가지로 qemu64MyOs.bat 를 실행하시면 됩니다.


 일단 밥 좀 먹고 다시 작업을 해야겠군요. ㅎㅎ
 그럼 다들 좋은 하루 되세요 ^^)/~~~


ps) X 버튼을 눌렀을때 윈도우 및 태스크를 종료하는 기능을 추가했습니다. 그 동안 귀차니즘으로 안했었는데... 더이상 미룰 이유가 별로 없더군요. ㅎㅎ 첨부파일은 최신으로 새로 올렸습니다. ^^)/~

+ Recent posts