Appler 디버깅하기 ___ 2

일단 빌드해서 startup.asm은 무사히 넘어갔지만,

다음으로 걸린 부분은 floppy.inc 입니다.

emulate.asm을 컴파일하다가 floppy.inc에서 에러가 났습니다.

에러가 난 부분입니다. 역시 잘 모르겠지만 뭔가 기묘하네요.

CurrentDrive와 OtherDrive를 찾아보니 저렇게 선언되어 있는데 이것도 기묘합니다.OTL

우선은 xchg라는 인스트럭션이 뭔지 몰라서, 다시 터보 어셈블러 퀵 레퍼런스를 참조했습니다.

xchg는 값을 바꿔주는 거군요. 일종의 swap이네요.

그런데 이번에 문제가 되는 부분은 앞서보다 복잡하네요.
CurrentDrive/OtherDrive가 사용되는 곳이 많아서 종잡기도 힘들고,
선언된 곳의 저 모양새는 대체 무엇인지 이해가 되질 않습니다.

Drive_S가 배열인걸까요?
그래서 0번은 CurrentDrive, 1번은 OtherDrive로 사용되는 거...
이건 매뉴얼을 다시 찾아 보기로 하고...

Drive_S라는 걸 찾아보니 일종의 structure로군요.

Globals.inc에 선언되어 있습니다.

위에서 보았던 CurrentDrive와 OtherDrive의 선언 부분의 의미를 알아냈습니다.
CurrentDrive    Drive_S    <0>
Drive_S 타입으로 변수 CurrentDrive를 선언하면서, 초기값 0을 할당한 것입니다.
Drive_S는 스트럭쳐로 여러개의 값을 가져야 하지만 ?로 표시되어 있는 ID에 대한 것만 초기화 해 주는 것인 듯 합니다.

터보 어셈블러의 User's Guide 12장에 있는 해당 부분은 다음과 같습니다.

그런데, 아직도 에러가 난 부분의 의미가 뭔지 모르겠습니다.
CS:OtherDrive[SI-1]-CurrentDrive

각 부분의 의미도 정확히 파악이 되지 않으니 전체가 뭘 의미하는지도 모르겠고,
[]이 배열인 듯 하면서도, 선언된걸로 보면 배열이 아니었고...상상력이 부족한걸까요?

좀 크게 보겠습니다.

DeviceSelect 프로시져

하나의 프로시져 였습니다. DeviceSelect라는...
경우에 따라 DeviceSelect10 혹은 DeviceSelect20을 수행하는데, 문제가 되는 부분은 DeviceSelect10인 경우입니다.

이 프로시져를 호출하는 경우를 좀 봐야겠습니다.

ResetFloppy 프로시져

C0EBr/C0EBw 레이블

아래쪽의 C0EBr/C0EBw는 레이블 이름도 이상하고, 시작이 어디서부터인지도 명확하지도 않고 헷갈립니다.
반면에 위쪽의 ResetFloppy는 뜻이 비교적 명료합니다.

좀 더 자세히 분석해 보기 전에 몇가지 모르는 것들을 찾아보았습니다.

Save/Restore 매크로

자주 나오는 Save/Restore는 매크로였고 간단하게 push, pop으로 구현되어 있습니다.

IRP 지시어

IFNB 지시어

매크로에서 사용된 IRP와 IFNB 지시어에 대한 설명이구요,
IRP로 Repeat를 하는데, 인자들 리스트를 r로 정의하였고 IFNB에서 리스트가 비어있는지 검사하면서 반복하는 듯 합니다.

even 지시어

프로시져의 시작부분에 있던 even이라는 지시어에 대한 설명입니다.
16 bit memory alignment를 위해서 짝수번지에 맞추라는 의미인 듯 합니다.

lods 인스트럭션

메모리에 있는 것을 읽어서 al(혹은ax, eax)에 넣는 작업을 합니다.
REP 혹은 LOOP로 반복구간을 정하나 봅니다.


다시 소스를 확인해 보겠습니다.

호출시 al에 담긴 값이 CurrentDrive의 ID와 일치하면 DeviceSelect20을 수행하고 프로시져를 마칩니다. 즉, 바꿀 필요가 없다는 의미이겠죠.
그렇지 않고 바뀌어야 한다면 WriteTrack을 호출하고 돌아와서 CurrentDrive의 값을 하나씩 읽어와서 OtherDrive에 있는 값과 바꿔치고, OtherDrive의 값을 다시 CurrentDrive에 넣습니다.
여기에서 [SI-1]이 사용된 이유는 그 위에서 lods byte ptr CS:[SI]를 수행하면서 si의 값이 증가되었기 때문인 듯 합니다.
그렇다면 어째서 CS:OtherDrive[SI-1]-CurrentDrive일까요?
CurrentDrive를 왜 뺀걸까요?

사실 모르겠습니다. 그리고 CurrentDrive를 빼지 않는게 맞는 것 같습니다만....
일단 저 부분을 제 생각대로 고치고, 나중에 확인해 보겠습니다.

-CurrentDrive 제거

뜨악...그래도 에러?

대충 메시지 보고 찍어서 다시 수정해 보았습니다.
두번째 에러는 실수로 건드렸나 봅니다.

byte ptr 추가

이제야 빌드 완료입니다.

음...디버깅을 한다고 했는데, 겨우 빌드까지만 다 했습니다.
빌드만 했는데 진이 다 빠진 느낌입니다.
오늘은 여기까지만....

Appler 디버깅하기 ___ 1

앞선 게시물에서 언급했던 Appler라는 에뮬레이터를 디버깅해 보기로 했습니다.
http://re-coder.blogspot.kr/2013/06/dosbox-ms-dos.html

소스가 온통 어셈블러 뿐이고, 틀림없이 MS-DOS의 System Call을 사용할 것이 불을 보듯 뻔하지만, 인터넷에 널린 자료들을 이용해서 한번 도전해 보겠습니다.

일단 디버깅을 하기 위해서,
소스를 빌드해야겠지요.
(이를 위해서 터보 어셈블러 5를 구해서 설치했습니다.)

에러가 발생하네요

소스를 보았지만 뭐가 잘못된 건지 모르겠습니다.

다시 인터넷에서 터보 어셈블러의 매뉴얼을 구해서 "Illegal immediate"에 대해서 찾아 보았습니다.

도움이 안되는군요

이젠 맨땅에 헤딩하기...트라이얼 앤 에러...시행착오...

일단 의심스러운 SlotLen을 지워 봤습니다.

startup.asm은 컴파일 성공입니다. 그러니까 SlotLen이 문제라는 의미군요.

혹시나 []안에서 덧셈이 문제일지도 모르니 상수로 더했을 경우엔?

역시 덧셈은 문제 없습니다. SlotLen이 문제임이 더 확실해 집니다.

만약에 SlotLen 하나면 쓴다면?

역시 안됩니다. 결론은 SlotLen

하지만 어떻게 해야 할까요?
SlotLen을 무시할 수는 없고, 값의 의미와 변경여부를 따져서 상수로 대체하거나 다른 레지스터를 사용할 수도 있겠지만 무언가 방법이 있지 않겠냐 싶습니다.
터보 어셈블러에 종속적인 표기 방법의 문제처럼 보이니까요...

몇줄 위에 보이는 것처럼 offset을 붙여보았습니다.

소용이 없습니다.

WORD라는 type으로 지정을 해주면 될까요?

안되는군요.

혹시 앞에 ds: 세그먼트 때문일까요?

아니군요. 

좀 기괴하지만 혹시 이건....

역시 안됩니다. 되면 이상한건가요?

이것도 기괴하지만 매뉴얼에서 얼핏 본 표기방법의 변형

안되구요.

역시 매뉴얼에서 얼핏 본 표기방법의 변형 2번째

마찬가지로 안됩니다.

혹시나 해서 어디서 많이 본 듯한 식으로 고쳐 보았습니다.

헐...되네요.

그럼 원래의 소스와 의미가 맞도록 고쳐서는...

역시 됩니다.

실제로 저렇게 표기했을 때, 실행시에도 정말 같은 효과가 나타나는지는 확인해 봐야하지만 일단은 방법을 찾았습니다.
의외로 어셈블러에서 이런 부분때문에 어려움을 겪게 되는군요.
오히려 하드웨어적인 부분이나, 인스트럭션과 레지스터의 사용 조건이 어려울거라 생각했는데 말입니다.

잠깐 앞서 수정했던 부분을 조금 더 살펴 보겠습니다.
문제가 되었던 SlotLen이라는 것이 어떻게 사용되는지 살펴보았습니다.

SlotLen이 선언된 부분

SlotLen이 사용된 곳은 여기가 전부입니다. 단 2줄.

음... 잘은 모르겠지만 SlotPrg의 길이를 보관하는게 SlotLen이구요,
하나는 C700h에 SlotPrg를 복사할 때 길이를 세는 용도로 SlotLen이 사용되구,
또 하나는 C700h에 복사한 SlotPrg의 다음에 값을 넣을 때 SlotPrg의 길이를 더해주는 용도로 SLotLen을 사용합니다.
결국 SlotLen은 SlotPrg의 길이를 보관하는, 그 값이 바뀌지 않는 상수입니다.
만일 앞서 수정한 부분에서 문제가 생긴다면 상수 9로 대체해도 되지 않을까 싶습니다.

마지막으로 앞에서 수정했던 WORD PTR과 mov에 대한, 터보 어셈블러의 퀵 레퍼런스 가이드의 내용을 참고 삼아 소개하는 것으로 이번 포스팅을 마치겠습니다.

그런데 WORD와 WORD PTR이 뭐가 다른걸까요?

에뮬레이터와 어플리케이션의 연계 디버깅?

앞선 포스팅에 이어서 DOSBox와 관련된 문제가 있었습니다.

DOSBox에서 vim을 사용하면서 나온 문제였는데, 특이하게 Linux환경에서만 발생하는 듯 합니다. (MS-Windows에서는 문제가 없음을 확인했으며, 문제의 발생을 확인한 환경은 Ubuntu 10.04였습니다.)

우선 스크린샷으로 문제를 확인해 보겠습니다.

vim으로 test.txt라는 파일을 새로 만듭니다.

파일을 저장하면 정상적으로 저장됩니다

해당 파일인 TEST.TXT가 만들어진 것을 확인할 수 있는데, read-only입니다.

같은 파일을 수정해서 다시 저장해보겠습니다.

저장이 안됩니다!!

DOSBox에서 생성된 파일은 read-only로 생성이 되고, 그래서 수정이 안된다?
그러면 당연히 DOSBox의 문제라고 생각할 수 있으나 vim이 아닌 다른 에디터에서 수정한 후 저장하면 저장이 됩니다.
단지 vim만 저장을 못합니다.

그럼 vim의 문제일까요?
MS-Windows 환경의 DOSBox에서는 문제가 없습니다.
Linux환경이라 해도 VirtualBox에 MS-DOS를 설치해 vim을 사용하면 문제가 없습니다.

아마 vim도 다른 에디터와는 뭔가 다른 방법으로 파일을 저장하고 있으며,
DOSBox도 Linux 환경에서는 파일 I/O에 관해 일부 기능에 버그가 있는 것이 아닌가 싶습니다.



여기에서 발생하는 재미있는 문제가 하나 있습니다.
vim에서 문제가 발생하는 부분을 디버거로 트레이스 할 수 있겠지요.
하지만 두개의 제품이 연계하면서 발생하는 문제를 하나만 디버깅해서는 제대로 잡을 수 없을 겁니다.
따라서 vim에서 문제가 발생하는 부분이 다시 DOSBox로 어떻게 이어지는지,
혹은 반대로 DOSBox에서 발생한 문제가 어떻게 vim으로 이어지는지를 확인해야 할 겁니다.

이런 연계 문제를 디버깅하려면 어떻게 해야 할까요?
Linux에서 gdb로 DOSBox를 디버깅하면서 DOSBox에서는 터보디버거로 vim을 디버깅하나요?
gdb와 터보디버거가 연동할 수 없는 환경이니 의미가 없을겁니다.

만약에 DOSBox에 내장디버거가 있어서 vim을 자체 디버거로 디버깅할 수 있다면 어떨까요?
그 상황에서도 gdb가 디버깅하는 DOSBox는 정상적인 루틴이 아닌 내장디버거에 의해 각종 trap이 설치된 변형된 루틴일 수도 있어 오히려 디버깅이 어려울 수도 있을겁니다.

이상적으로는 DOSBox를 디버깅하는 디버거가, DOSBox라는 에뮬레이터와 그 안에서 돌아가는 vim이라는 application이 존재하는, 일종의 nested? embedded?임을 인식해야만 할 겁니다.

현실적으로는 디버거가 환경을 인식한다 하더라도 효율적인 디버깅 방법도 고민스러우며, 얼마나 다양하게 쓰일 수 있는냐도 의심스러운 부분입니다.
따라서 통상적으로 분산 시스템의 연계 문제를 디버깅할 경우에 synchronization을 방해하지 않고 디버깅하는 방법은.......
메시지를 기록해서 이를 분석하는 방법입니다.

쉽지는 않겠지만 한번 디버깅을 해 보겠습니다.

DOSBox는 얼마나 충실하게 MS-DOS를 에뮬레이션하는가

앞서의 게시물에서 VirtualBox에 MS-DOS를 설치하는 방법을 설명하였습니다.

하지만 정작 설치된 MS-DOS를 사용하다보니 불편한 점이 하나 둘씩 나타나게 되더군요.
앞서 언급했듯이 파일을 전송하거나 받는 것이 매우 불편하고,
마우스도 드라이버는 따로 잡아주어야 작동을 하고,
조이스틱은 에뮬레이션도 곤란한듯이 보입니다.
비교적 많은 프로세스 파워를 필요로 하는 것도 낭비적인 요소로 보입니다.

이러고보니 자꾸 DOSBox와 비교가 되더군요.
확실하게 VirtualBox에 MS-DOS를 설치해 사용하는 것보다 DOSBox가 월등히 장점이 많은 것은 사실입니다만, DOSBox가 얼마나 정확하게 MS-DOS를 재현해내는가 의심이 드는 사건이 있었습니다.

MS-DOS 환경에서 구동되는 Appler라는 Apple][ 에뮬레이터를 실행했을 때 발생한 문제입니다.
우선 DOSBox에서 실행한 화면입니다.

Appler 구동 화면

디스크이미지를 선택하기 위한 디스크매니저 화면

디스크매니저의 화면을 자세히 보면,
우측상단의 Path&Filter 부분이 좀 이상해 보이지 않습니까?
정상이라면 C:\EMULATOR\APPLER\*.DSK,*.NBL이 되어야 합니다.(APPLER뒤에 백슬래쉬)
그래서인지 그 아래의 Directory 부분도 .과 ..도 보이지 않아서 상위 디렉토리로 이동도 불가능하며, 이 디렉토리에 있어야 하는 APPLER.DSK는 보이지도 않고, 존재하지도 않는 APPLER라는 서브 디렉토리까지 보입니다.
(단지 보이는 것만의 문제가 아니라 실제 작동도 안됩니다.)


처음엔 Appler의 문제라고 생각했는데, VirtualBox에서 확인해 보니 제대로 작동합니다.
VirtualBox에 설치한 MS-DOS에서의 Appler를 실행한 화면을 보겠습니다.

Appler 구동 화면

디스크매니저 화면

Path&Filter도 정상이고 Directory 부분에 모든 폴더와 디스크 이미지가 제대로 보입니다.


과연 DOSBox는 얼마나 믿을 수 있는 걸까요?


Appler를 받을 수 있는 곳
Appler Binary : http://www.sanskritweb.net/apple/
Appler Binary & Source : http://www.zophar.net/apple2/appler.html