일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- snes
- 이스
- 오블완
- 3DS
- mobilesuit
- 컨트롤러
- 슈퍼패미컴
- 게임보이
- GOG
- Apple II
- 닌텐도 스위치
- MSX
- 슈퍼마리오
- 건담
- analogue
- 앙상블
- ps4
- Game Gear
- 메가드라이브
- 게임기어
- mister
- PSP
- fpga
- 메트로이드
- 티스토리챌린지
- 패미컴
- ensemble
- 모빌슈트
- PC엔진
- YS
- Today
- Total
Just a Blog
MSX 실기와 OCM 클론(MiSTer MSX 코어, IQ3 000 큐티)에서 BASIC 실행 차이 세번째 분석 본문
MSX 실기와 OCM 클론(MiSTer MSX 코어, IQ3 000 큐티)에서 BASIC 실행 차이 세번째 분석
wehong 2022. 8. 26. 01:09좀 더 파혜쳤더니, 문제 발생 원인에 더 좁혀졌다. 문제가 발생하는 지점은 'VPOKE'로 VRAM 3800H 번지에서 스프라이트를 만드는 곳이 아니라, 'VPOKE'로 VRAM 2000H 번지에서 컬러 테이블을 변경하고 있는 곳이었다. 더 정확하게는 VRAM의 2006H 번지와 2007H에 어떤 값을 기입해서 0~9 숫자와 일부 기호 캐릭터의 색을 변경하니 스프라이트 충돌 분기가 발생했다. MiSTer MSX 코어와 IQ 3000 큐티에서 이 부분을 빼니 실기와 동일하게 정상동작 했다.
하지만 다른 코드에서 'VPOKE'로 해당 번지에 값을 넣어 봤는데 이런 현상이 재현되지는 않았다. 즉, 단순히 VRAM 2006H, 2007H 번지 메모리가 문제가 있는 것은 아닌 것 같다. 하지만 문제의 BASIC 프로그램에서는 2000H~2005H 번지 까지 값을 넣은 것은 상관이 없었고, 2006H나 2007H 번지 중 하나에 값을 넣으면 간혹 돌발적인 스프라이트 충돌이 발생했으며, 2006H와 2007H에 동시에 값을 넣으니 계속 스프라이트 충돌이 발생했다.
확실한 것은 'VPOKE' 구문으로 스프라이트를 만들 때는 문제가 없어 보인다는 점이다. 하지만 VRAM의 컬러 테이블에 있는 데이터 때문에 스프라이트 충돌이 발생한다는 것은 더 이상한 현상 같다.
또 다른 분석방법으로, MSX의 또 다른 FPGA 구현(MSX1 규격 구현)인 'MSX1' 코어에서 실행해 봤더니 이런 이상현상이 전혀 나타나지 않았다.
참고로 어떤 일본인 사용자분의 블로그에서 MSX VRAM에 대한 훌륭한 정보를 얻었다.