PAC-V 제작 #8 - 롬 동작모드 개선

지난 제작 글(#7)이 2016년 8월이었으니까, 거의 8년만에 구조 변경이네요 ㅎ.ㅎ

[서론]

보통 PAC-V에는 FMPAC 롬(BIOS 16KB + 팩커맨더 48KB)을 다운로드해서 씁니다.

만약 PAC-V에서 동작하는 FM BIOS가 다른 S/W와 동작 문제가 발생하면,

부팅 시 P키를 눌러서, Dummy ROM 모드로 구동하면 되구요.

저는 turboR의 슬롯을 개조해서 SLOT 0-1에 PAC-V를 장착하기 때문에,

BASIC 프로그램에서 FM BIOS (MUSIC ROM)루틴을 제대로 쓰지 못합니다.

아시다시피 turboR의 FM BIOS는 본체의 H/W Timer를 사용하며, MIDI까지 통합되어있습니다.

그 때문에, 다른 외부 FM BIOS가 내장 BIOS보다 먼저 동작하는 상황이 발생하면 망하는 거죠. ㅎ.ㅎ

저처럼 turboR SLOT 0-1에 PAC-V를 꽂으면, 본체 내장된 SLOT 0-2의 BIOS보다 우선순위가 높아지니까요.

참고로 FM 내장된 MSX2+ 기종에서는 문제가 생기지 않습니다.

FMPAC의 FM BIOS와 본체 내장 FM BIOS가 같은 코드니까요~

어디까지나 turboR의 SLOT 0-1을 개조해서 사용하는 경우만 해당이 됩니다.

PAC-V에 FMPAC BIOS로 세팅해놓고, 필요할 때마다 P키를 눌러서 Dummy ROM 모드로 변경하는 방식은...

저처럼 Dummy ROM 모드를 주로 쓰는 경우는 꽤 번거로운 작업이 됩니다.

그래서 처음 PAC-V를 개발할 때 부터, FMPAC ROM 대신 그냥 Dummy ROM을 탑재하는 옵션을 넣었죠.

(참고로 이 Dummy ROM은 릴리스 하는 압축파일에 PACV.ROM이라는 이름으로 들어있습니다.)

결국 롬 동작모드는 FMPAC ROM(64KB) 또는 Dummy ROM(16KB), 둘 중 하나를 다운로드 하는 것으로 결정되구요.

FMPAC ROM 모드에서는 FM 사운드 칩(OPLL)이 없는 FMPAC 카트리지처럼 동작합니다.

Dummy ROM 모드에서는 오리지널 PAC 카트리지처럼 인식됩니다요.

물론 LED 비주얼라이저는 롬 모드 상관없이 똑같이 동작하구요.

암튼, 저는 Dummy ROM으로 사용하고 있었죠.

가끔 팩커맨더를 쓰고 싶을 때만 FMPAC.ROM을 다운로드해서 구동합니다.

그리곤 다시 Dummy ROM으로 다운로드ㅋ

.

.

.

그러던 어느날 이것도 좀 귀찮다는 생각이 들더라구요.

게다가 PAC-V 후기형(Blue)에서는 FRAM을 쓰고 있는데, 낭비되는 영역이 아까운 느낌도 있었구요.

롬 모드를 쉽게 전환할 수 있는 방법과 남은 FRAM(또는 SRAM)을 활용하는 방법을 생각해보기로 합니다.

[본론]

1) 롬 동작모드

기존처럼 동작모드가 현재 다운로드 된 ROM의 종류로 결정되는 방식이 아닌,

사용자가 부팅 중 P키를 눌러서 변경하는 방식으로 바뀝니다.

설정된 동작모드는 FRAM(또는 SRAM)에 저장되기 때문에,

전원을 끈 후 다시 켜더라도 모드가 유지됩니다.

그리고 소프트 리셋을 할 때에도 P키를 눌러 모드 변경이 가능합니다.

MMC/SD에서 롬/디스크 게임을 구동할 때 재부팅(소프트 리셋) 되니까, 이 때에도 변경할 수 있습니다.

아래 사진은 부팅 시, 현재 동작모드가 표시되는 모습입니다.

'Op.Mode'가 동작모드를 의미합니다. ㅎ.ㅎ

2) BASIC'n v2.1

PAC-V에서 SRAM 저장용으로 쓸 수 있는 공간은 32KB입니다.

지금까지는 PAC SRAM 8KB만 사용하고 있었습니다.

여기서 16KB를 Dummy ROM 모드 대체용으로 사용합니다.

아무 동작 안하는 것 보다는 쬐금 쓸모있는 프로그램을 넣어두는 게 나을 것 같아서요 ㅎ.ㅎ

근데, 기존 PAC 세이브/로드와 충돌하지 않는 롬 프로그램 중에서 쓸만한 것들이 뭐가 있을까요?

딱히 떠오르는 프로그램이 없네요. BASIC'n 정도밖에는요ㅋㅋ

그렇게 BASIC'n v2.1 롬이 들어가게 되었습니다.

롬 동작모드는 BASIC'n과 FMPAC 2개가 되겠습니다.

4) 2 x PAC

기존 데이터 저장 공간 32KB에서 16KB는 BASIC'n으로 할당되었으니, 이제 16KB가 남았네요.

PAC 8KB 데이터를 두벌을 넣을 수 있도록 해봅니다. PAC 카트리지를 두개처럼 쓰는거죠.

부팅 시, 동작모드와 함께 PAC 번호가 [PAC SRAM #0] / [PAC SRAM #1] 으로 표시됩니다.

아래는 부팅 중 P키를 눌러서 동작모드를 바꿔 본 모습입니다.

커서키 좌우로 선택 후 리턴키를 누르면 적용됩니다.

그럼, 이만... ㅎ.ㅎ/

PAC-V Tool v1.10

 

Download: PAC-V_Tool_110_20240619_1.zip

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

    PAC-V Tool v1.10 (2024-06-19)

        By Yeongman Seo <sharksym@hitel.net>

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

* UPDATE

  SRAM/FRAM 구조가 변경되었습니다.

  FMPAC.ROM을 다운로드하면, 새로운 BIOS로 동작합니다.

  기존 Dummy BIOS 모드가 삭제되고, BASIC'n 2.1 롬이 탑재됩니다.

  참고) BASIC'n 모드에서도 PAC 카트리지로 정상 인식됩니다.

  PAC SRAM 8KB 영역이 두개로 늘어났습니다.

  부팅 시, P키를 눌러서 동작모드 및 SRAM 영역 선택이 가능합니다.

  커서 좌/우로 모드 선택 후 RETURN 키를 눌러 적용합니다.

  동작모드는 아래 4가지입니다.

  BASIC'n 2.1 [PAC SRAM #0]

  BASIC'n 2.1 [PAC SRAM #1]

  FMPAC BIOS [PAC SRAM #0]

  FMPAC BIOS [PAC SRAM #1]

* PACV.COM

  PAC-V 카트리지의 SRAM을 관리하는 프로그램입니다.

  MSX-DOS1 및 MSX-DOS2 에서 동작합니다.

  BIOS롬, LED패턴을 카트리지에 다운로드 할 수 있으며,

  파나소닉 PAC 데이터를 SAVE/LOAD 할 수 있습니다.

* 요구 사항

  PAC-V 카트리지

  MSX-DOS1 또는 MSX-DOS2

* 파일 목록

  PACV.COM     - 카트리지 관리 프로그램

  PACV.INI     - LED 패턴 (기본 수직 막대)

  PACV_1.INI   - LED 패턴 샘플#1

  PACV_2.INI   - LED 패턴 샘플#2

  PACV_3.INI   - LED 패턴 샘플#3

  README_K.TXT - 한글 설명서

* 사용법

  PACV W|P|S|L Filename [Slot[SubSlot]]

    W: FMPAC BIOS 다운로드   (영어 및 한글 패치버전 가능)

    P: LED 패턴 데이터 다운로드       (슬롯번호 생략가능)

    S: PAC 데이터 덤프 및 디스크 저장 (슬롯번호 생략가능)

    L: PAC 데이터 다운로드            (슬롯번호 생략가능)

  예) PACV W FMPAC.ROM 1

      PACV P PACV.INI

      PACV S SRAM.PAC

      PACV L SRAM.PAC

* 주의 사항

  PACV.COM 프로그램은 PAC-V 카트리지 전용 툴입니다.

  파나소닉의 PAC 및 FM-PAC 카트리지에서는 동작하지 않습니다.

  S 또는 L 커맨드로 PAC 데이터 SAVE/LOAD 시,

  현재 설정된 SRAM 8KB 영역 한개만 적용됩니다.

Leonardo Padial 아자씨와 'MMC Disk'

구글 포토에서 (많이) 지난 6월 12일 사진을 띄워주길래, 조금 적어봅니다.

아래 사진은 2005-06-12에 찍은 건데, 당시 폰카메라 화질이 안좋아서 흐릿하네욤 ㅎ.ㅎ

제 GT에 LPE-MMC-V1 카트리지를 꽂은 모습입니다.

기억하시는 분 계시겠지만, MMC/SD Drive의 옛 이름 'MMC Disk'이죠.

2004년에 MMC Disk를 만들어서 공개했을 때, 유럽 아자씨들이 관심을 꽤 보이더라구요.

사진 보시면 SCC 칩이 안보이죠?

코나미 SCC게임들을 구동하거나 MGSEL 등의 뮤직 프로그램을 활용하려면 SCC가 있는 편이 좋은데요.

왠만한 MSX 유저들은 사운드 전용 SCC카트리지를 하나씩은 갖고 있었으니까,

이런 MMC/SD 미디어를 쓰는 디스크드라이브에 자체에 대한 것으로 관심이 많이 받은 것 같아요.

그리고, 선라이즈 IDE에 CF-SD 어댑터 쓰면 되는데, 이딴 거 왜 만들었냐고 핀잔도 좀 받았다는 게...ㅎ.ㅎㅋ

암튼 2005년쯤 Padial씨가 연락이 왔는데,

제 회로를 기반으로 No SCC 버전의 MMC Disk를 만들었다고 하면서, 보드 하나를 선물로 주겠다고 그러더라구요.

그래서 그 때 받았던 보드가 LPE-MMC-V1이었습니다.

그 후로 많은 교류는 없었지만, 20년이 지난 지금은 고인이 되셨네요.

이젠 이메일도 못 보낸다능...ㅠ.ㅠ

암튼, 그 후로 LPE-MMC 시리즈가 꽤 많이 나왔는데요.

아래 사진은 2007년에 나왔던 LPE-MMC-V6입니다.

확장슬롯 통합 버전이라서, 서브슬롯 1개는 MMC Disk가 점유된 상태니 나머지 3개 슬롯만 보이네요 ㅎ.ㅎ

갑자기 구글 포토에서 사진이 뜨는 바람에 좀 끄적여봤습니다.

즐거운 오후 되세요~ ㅎ.ㅎ/

HI-TECH C v3.09 - Win32 Recompiled version test

모두(?)가 아시는 그 하이테크 C 컴파일러의 Win32 버전이 나왔습니다.

무슨 개소리냐구요? ㅎ.ㅎ

.

.

.

제가 20년 전에 처음 HI-TECH C를 쓸 때는 MSX 에뮬(paraMSX)을 이용했었습니다.

뭐, turboR 실기에서도 소스 컴파일을 할 수 있습니다만...

당시 GT + MMC/SD 조합으로도 긴~긴~ 빌드 타임을 기다리는 건 무리였죠ㅋ

암튼 그렇게 쓰다가, 2008년 부터는 성능이 괜찮은 윈도용 CP/M 에뮬을 발견해서 지금까지 활용했습니다.

커맨드 프롬프트에서 직접 실행 할 수 있어야, MAKE 등의 기타 툴을 활용하기 좋으니까요.

참고로 CP/M 에뮬은 일본 아자씨가 만든 CP/M EXEcutor입니다.

그러다가 개인 프로젝트의 소스가 점점 커지고 윈도에서도 작업 효율이 점점 안좋아졌는데요.

시간이 지나면 PC 성능도 함께 올라가니까 그럭저럭 에뮬로 버틸만 했습니다요.

시간은 흘러~ 1년, 5년, 10년, 15년...

어느날(며칠 전) HI-TECH C가 디컴파일이 되었다는 소식을 듣게 되었습니다 ㅎ.ㅎ

원래 HI-TECH C CP/M 버전은 ANSI C를 지원하는 상용 컴파일러입니다.

근데 20년 전에 제작사가 사후지원을 종료하면서, 프로그램을 공개(free)로 풀어버렸죠.

저도 옵티마이저, 뱅킹 툴 등을 만들고 짜깁기해서 지금껏 잘 쓰고 있는데요.

최근 이 CP/M용 실행파일을 디컴파일해서 활용가능한 수준의 C 소스로 만든 분이 나왔더라구요.

대충 히스토리를 보니...

먼저 CPP, P1, CGEN, ZAS, LINK 등의 기본 컴파일러, 어셈블러가 만들어졌구요.

https://github.com/nikitinprior?tab=repositories

다른분이 LIBR(라이브러리안)을 추가하고, 소스를 모두 묶어서 빌드할 수 있게 만들어놨네요.

https://github.com/ogdenpm/hitech

오~~ 필요한 거 다 있네요? ㄷㄷㄷ

궁금해서 바로 받아서 빌드해봤습니다 ㅎ.ㅎ

참고로, 최종 커밋은 지난 5월 31일에 들어갔네요.

https://github.com/ogdenpm/hitech/commit/6c762963ce7ab16fef74b7551588411abbc6e69a

간단한 Hello World 프로그램을 컴파일해서 비교해보니, 출력물이 오리지널과 똑같습니다. 굿굿!!

모든 툴이 진짜 다 괜찮은지 확인하려면, 큰 소스를 빌드해보는 방법뿐이겠죠?

M 파일매니저를 빌드해봅시다!

먼저, CP/M 에뮬을 쓰는 MAKEFILE을 뜯어고쳐서 Win32 리컴파일 버전을 쓰도록 수정했습니다.

참고로 CP/M은 서브디렉토리 개념이 없어서, 편하게 쓰려면 Tool, LIB, Source 등을 모두 개별 드라이브로 분리해야하는데요.

다행하게도 CP/M EXEcutor는 윈도의 폴더를 에뮬의 드라이브로 매핑해주는 기능이 있습니다.

그래서 제가 쓰는 툴들은 가상의 드라이브(A: B: C: D:)를 쓰도록 환경을 구성했었죠.

Win32 리컴파일 버전은 파일명에 디렉토리 패쓰를 쓸 수 있고, 긴파일명도 당근 지원됩니다.

M 파일매니저를 빌드해보니, 출력물은 거의 똑같네요.

바이너리에서 차이나는 부분은 사실 CP/M의 레코드 사이즈(128 바이트)로 인한 거였구요.

실제 동작하는 영역은 똑같았습니다. 완벽하네요!! ㅎ.ㅎb

아래의 M.COM 실행파일(멀티뱅크 로더)를 비교해보면, 끝부분의 dummy 영역만 차이가 나는 것을 볼 수 있습니다.

아래는 긴파일명(LFN)을 테스트해 본 모습입니다.

MPXFW.C였던 파일명을 길게~~ 30글자 넘게 만들어도 잘 컴파일됩니다.

링커의 MAP파일에서도 아래처럼 정상적으로 표시됩니다.

라이브러리도 디렉토리 패쓰를 지정할 수 있어서 좋아요.

아래는 MAP파일에서 조금 동작이 달랐던 부분인데요.

같은 오브젝트 내의 심볼을 이름으로 정렬하느냐, 주소로 정렬하느냐 정도의 차이였습니다.

어차피 사람이 인식하는데엔 별 문제없는 수준입니다요 ㅎ.ㅎ

그리고, 가장 중요한 빌드 타임을 비교해보아요~

CP/M 에뮬 + Z80 바이너리 VS Win32 네이티브 프로그램

얼마나 빨라졌을까 궁금하시죠? ㅎ.ㅎ

# M 파일매니저 빌드

CP/M 에뮬 조합 환경 -> 약 55초

Win32 리컴파일 버전 -> 약 16초

# C LIB x 8개 빌드

CP/M 에뮬 조합 환경 -> 약 10분

Win32 리컴파일 버전 -> 약 1분 15초

속도가 많이~많이~ 빨라졌네요!

참고로, C 라이브러리는 멀티코어로 8개 동시에 빌드한 상태였습니다.

이거 순차적으로 빌드하면 1시간 걸립니다요. (아마 MSX로 빌드하면 하루종일ㅋ)

제 PC는 라이젠5 7600입니다. 참고하셔요~

그럼, 이만...

지난 20년 개발의 추억 #9 - XII-V

월간 추억팔이 #9편이 나왔습니다~ ㅎ.ㅎ

#1 ~ #8편은 아래 링크를 이용하세요!

https://sharksym.blogspot.com/2023/07/20-1.html

https://sharksym.blogspot.com/2023/08/20-2.html

https://sharksym.blogspot.com/2023/10/20-3.html

https://sharksym.blogspot.com/2023/10/20-4-mmcsd-drive-v3.html

https://sharksym.blogspot.com/2023/11/20-5-paramsx-r.html

https://sharksym.blogspot.com/2024/01/20-6-paramsx-r-v11.html

https://sharksym.blogspot.com/2024/03/20-7-audiofactory.html

https://sharksym.blogspot.com/2024/04/20-8-mmcsd-drive-v4.html

2019년으로 넘어가면서 파라동에도 많은 변화가 생깁니다.

일명 '대란 X-II' 본체 수백대가 장터에 나오면서, 새로운 X-II 유저가 많이 늘었습니다.

작년 2018년에 MMC/SD V4가 나오게 되면서, 주변기기가 없던 분들도 X-II를 쉽게 활용할 수 있게 된 것도 하나의 이유겠죠? ㅎ.ㅎ

조금 문제라면...

'대란 X-II'로 MSX 실기를 처음 접하시는 분들은, 어쩔수 없이 '삽질'을 많이 하셨던 것 정도겠네요.

안그래도 슬롯 동작에 좀 문제가 있던 모델인데, 침수 피해를 복구한 본체들이라... 상태가 더 메롱메롱ㅋ

저는 X-II를 써본 기억이라고는 88년 쯤, 아는 형네 컴터로 조금 만져본 게 전부였는데요.

이번 '대란 X-II'로 구한 기기로 저의 주변기기 테스트용으로 잘 쓰고 있습니다요~ ㅎ.ㅎ

(MMC/SD V4 만들 때에도 X-II 땜에 겁나 힘들었슴다 ㅠ.ㅠ)

어느날, 이 많은 X-II를 좀 더 활용할 수 있는 방법이 없을까? 고민하다가 두가지를 생각했습니다.

1) Z80 고속모드 및 잡다

MSX 본체를 싸게 만들 수 있게 된 이유 중 하나는, 야마하, 도시바의 MSX-ENGINE 칩 때문이었는데요.

후기 MSX2+/turboR 기종들은 Z80 내장된 도시바의 T9769 시리즈를 사용하구요.

초기 MSX2 기종들은 Z80 없는 야마하 S1985를 주로 씁니다.

대우 MSX2(CPC-300/400) 기종들은 MSX-ENGINE이라고 부르긴 민망하지만, 확장슬롯과 메모리매퍼 256KB 로직을 묶은 칩을 썼습니다.

근데, 대란 X-II를 사용기들을 보니, 본체의 Z80, RTC 칩이 죽어있는 경우가 꽤 많더라구요.

저도 Z80 교체하고 VDP도 V9958로 하나 바꿔서 사용하고 있습니다.

암튼 기존 Z80 및 주변 칩들을 뽑고, 작은 도터보드를 꽂아서 활용성을 높이는 거죠.

Z80 20MHz + 램 + 기타 등등 짬뽕하는거죠. turboR BIOS로 노말/고속 모드 대응도 하구요.

물론 VDP는 V9958로 업글해야겠지만요.

근데 X-II를 일년 넘게 써보니...

보수했던 키보드는 역시나 또 접점불량 고질병 발생.

전면슬롯, 외부 확장슬롯 및 주변기기 카트리지들의 동작 호환문제.

AV 보드 동작 불안 등등

.

.

.

이건 뭐, 종합 병동이네요. 차라리 AV보드, 키보드를 새로 만드는 게 X-II 활용에 더 도움이 될 것 같았습니다.

결국 이 계획은 접었습니다요! 에혀...ㅋ

2) X-II 전용의 LED Visualizer

X-II 전면을 보면 FDD용 베이가 2개가 있는데요.

여기 여분의 FDD B: 쪽에 PAC-V의 LED 비주얼라이저를 박으면 멋지구리할 것 같은 느낌이 들더라구요.

사이즈를 측정해보니, LED도 잘 보이고 PCB도 수납하기에 별 문제 없어보였습니다.

아래처럼 만들면 되겠더라구요.

이름은 XII-V로 정했습니다. 이름만 봐도 X-II 전용 비주얼라이저 같죠? ㅎ.ㅎ

참고로 PAC-V는 PAC 기능에 LED Visualizer가 추가된 일반적인 카트리지 형태입니다.

슬롯 하나를 점유하는 방식이죠.

근데 X-II는 이걸 본체에 내장해야하니까, 사용자가 슬롯을 맘대로 고를 수가 없습니다.

게다가 본체의 확장슬롯(SLOT 0-0, 0-1, 0-2, 0-3)은 이미 점유된 상태라 빈 곳도 없구요.

그럼 XII-V에 확장슬롯을 넣고 슬롯 커넥터 3개 + 비주얼라이저를 만들면 어떨까? 고민도 잠깐 해봤는데요.

후면 슬롯을 개조해서 /SLTSL 3개를 reserved pin을 활용해서 출력, 전용의 서브슬롯 x3을 장착하는 방식이죠.

.

.

아앜... 배보다 배꼽이 커지네요. 포기~ㅋ

결국, PAC 기능은 완전히 제거하고 LED Visualizer만 I/O 포트로 구현하게 됩니다.

문사운드 같은 I/O 카트리지 형태로 진행합니다. 전면부 슬롯과 병렬로 케이블을 연결해서 I/O 포트만 사용합니다.

PAC-V의 비주얼라이저와의 차이라면...

PAC-V는 LED 애니매이션 패턴을 SRAM에 저장하고 배터리 백업으로 동작하지만,

XII-V는 이 패턴이 플래쉬롬에 미리 기록되어있어서 배터리를 쓰지않습니다.

대신 PAC-V처럼 유저가 패턴을 편집할 수는 없지만, 미리 내장된 패턴 4개 중에서 선택해서 쓰는 방식입니다.

이번 XII-V는 오버리치님, 곰님과의 협업(콜라보~)으로....

회원님들의 전면부 덮개를 받아서 레이저로 가공 및 아크릴 덮개 제작과 슬롯 케이블 작업도 진행되었습니다.

저는 LED쪽과 메인보드 제작만 했습니다 ㅎ.ㅎ

그리고, 가끔 장터를 보면 XII-V를 구하신다는 분이 계시던데, 이건 앞뒤가 좀 안맞는 얘기입니다요.

XII-V로 개조된 X-II를 구매하신다고 하면 말이 되겠지만요.

그럼, 다음편에서 뵙겠습니다! ㅎ.ㅎ/

M File Manager v4.4 for MSX-DOS2

 

Download: M_v4.4_20240610_fixed.zip

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

    M File Manager v4.4 for MSX-DOS2 (2024-06-08)

        By Yeongman Seo <sharksym@hitel.net>

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

* UPDATE

  @ 기능 변경/개선

  - 일부 기능키에서 클릭 대신 누름 동작으로 변경

  - 속성(Attribute)표시용 문자 변경

  - 파일 선택 표시용 문자 변경

  - 속성 변경과 타겟 패널 열기용 단축키 서로 바꿈

    속성변경 -> CTRL + RETURN

    패널열기 -> SHIFT + RETURN

  - 현재 파일과 동일한 확장자의 파일을 선택하는 기능 추가

    CTRL + SPACE

    (예: MUSIC.IMS 파일에서 키 입력 시, 모든 *.IMS 선택됨)

  - #IMSP 및 #MPXP에서 연속 재생 시, 취소키 추가

    기존 CANCEL(파나소닉 기종의 취소) 및 STOP 사용

  - #MPXP에서 ID3v2.4 지원

    UTF-8 문자열 표시 및 연도 TAG(TDRC)

  - 도움말 파일(M.HLP, M_IL.HLP) 업데이트

긴파일명(LFN) 사용 시 주의 사항

오리지널 MSX 유저라면 아마 나이가 40대 후반에서 50대,60대 정도일겁니다.

최근에 MSX를 접하신 30대 분들이라면, 아마 태어나셨을 때 MSX가 단종되었을거에요.

아마 처음 접하신 PC도 윈95가 설치된 PC가 아닐까 싶으네요.

이제 MSX-DOS, MS-DOS에서 사용되는 디렉토리, 파일명에 대한 얘기를 한번 꺼낼 시기가 된 것 같습니다.

.

.

.

MSX-DOS, MS-DOS를 쓰다가 윈95를 처음 쓸 때 기억하시나요? ㅎ.ㅎ

기존 FAT에 긴파일명(LFN)을 쓸 수 있게 되었는데, VFAT이라고 불렀습니다.

디렉토리 엔트리는 32바이트의 파일 또는 서브 디렉토리로 구성됩니다.

기존 FAT에서는 파일/서브 디렉토리는 하나의 엔트리였지만,

VFAT에서는 긴파일명(LFN) 표시를 위해 여러개의 엔트리를 사용하여 표시합니다.

파일명이 길수록 더 많은 엔트리를 소모하는 식이죠.

VFAT을 지원 못하는 OS에서는 LFN 엔트리가 보이지않고 기존 8.3 짧은 파일명으로 인식됩니다.

따라서 8.3 파일명으로 데이터를 읽는데에는 아무런 문제가 없습니다.

그냥 볼륨+시스템+히든 속성의 이상한(?) 파일들이 잔뜩 있는 것으로 인식되는 것 뿐이욤 ㅎ.ㅎ

근데, 여기서 주의해야될 부분이 한가지 있는데요.

VFAT을 지원하는 OS에서는 LFN으로 저장된 파일을 삭제, 이동 등의 작업 시 연결된 엔트리들이 함께 처리됩니다.

만약 VFAT을 지원하지 않는 프로그램 또는 OS에서 디스크작업을 하게 되면. 연결된 LFN 엔트리가 손상되어 쓰레기로 남습니다.

결국, MSX-DOS/DOS2 및 구버전 MS-DOS에서 쓰이던 디스크관련 프로그램을 쓰면 안된다는 얘기죠.

음...

LFN 얘기를 처음 들으셨으면, '그럼 파일명을 8.3 포맷으로 짧게 해주면 되겠네'라고 생각하실 수도 있는데요.

원래 FAT에서는 파일명이 항상 대문자로 저장됩니다. 따라서 파일명에 소문자가 섞여있으면 무조건 LFN으로 바뀌게 됩니다요.

그럼, MSX용 디스크에 LFN 파일을 넣고 MSX-DOS2에서 파일 삭제를 하면 어떤 결과가 나오는지 한번 테스트해보겠습니다~

아래처럼 문자수는 8.3 포맷으로 짧게 보이지만, 소문자가 섞여있는 LFN 파일 2개를 MSX 디스크에 복사합니다.

M 파일매니저에서는 아래처럼 긴파일명으로 인식이 되는 것을 볼 수 있어요.

그럼, 파티션을 덤프해서 실제 디렉토리 엔트리가 어떻게 저장이 되는지 봅시다.

일반 파일들은 32바이트 엔트리로 저장되는데, 해당 LFN 파일은 각각 64바이트로 저장된 것을 확인할 수 있어요.

LFN은 빨간색으로 표시했습니다.

그럼, Ys3(k).DSK 및 Ys3(k).USR 두개 파일을 삭제해봅시다. 물론 MSX에서 삭제해야겠죠?

파일이 삭제되면 각 엔트리의 첫 바이트가 E5H로 변경이 됩니다.

근데 아래 스샷에서 여전히 원래값 41H로 시작하는 엔트리가 보이시죠?

MSX-DOS2는 저 엔트리가 연결된 하나의 파일이라고 인식을 못하기 때문에 그냥 둔거에요.

이 손상된 드라이브는 윈도에서 CHKDSK /F 명령으로 쉽게 수정을 할 수 있습니다.

수정 후 덤프해보면 아래처럼 모두 삭제된 엔트리를 볼 수 있어요.

.

.

.

그리고, 보너스입니다.

윈도10 이후에서는 모든 드라이브에 'System Volume Information'이라는 긴이름의 폴더가 생성됩니다.

이동식 드라이브도 마찬가지구요.

만약 MSX에서 쓰이는 디스크를 윈도에 연결(마운트)하게 되면, 해당 LFN 폴더가 생성이 됩니다.

이 폴더를 지우지않고 MSX에서 그대로 사용하면, 이 폴더가 MSX-DOS2에서는 볼륨명으로 인식이 됩니다요~ ㅎ.ㅎ

원래 LFN 엔트리는 속성(Attribute) 값이 0FH가 되는데, 기존 FAT에서는 이런 파일이 없습니다.

그래서 Volume label + System + Hidden + Read-only 모든 속성을 켜서 LFN 인식으로 쓰는 꼼수를 쓴거죠.

그리고 LFN 엔트리들은 별도의 연결 리스트를 사용하지 않습니다. 단지 여러개 엔트리가 연속으로 설정되도록 되어있어요.

암튼 MSX-DOS2에서 이 엔트리를 볼륨명으로 인식하게 되면서, "B "로 볼륨명이 표시되는 현상이 있습니다.

아래 덤프된 엔트리를 보시면 왜 그런지 이해되시죠?

96바이트의 LFN 엔트리의 첫 부분이  42H, 20H, 00H 값으로 시작됩니다. Volume label 속성이니 이걸 걍 볼륨명으로 인식한거죠.

제가 만든 M 파일매니저에서는 볼륨명을 읽을 때 LFN은 무시하도록 되어있어서 이런 현상은 나오지않습니다. 참고하셔요.

그럼, 이만...