폐쇄 . 이 질문은
의견 기반 입니다. 현재 답변을 받고 있지 않습니다.
댓글
.
단, '는 기술적 이유가 아니라 여기에 기타 ' 하드웨어. 항상 업데이트가 필요하기 때문에 (실제 하드웨어에서도 ' 에뮬레이션과 관련된 문제도 아닙니다.
@Raffzahn : FPGA 장치를 사용하는 경우) 하드웨어 수준에서 원래 동작을 정확하게 모방하기 때문에 FPGA 프로그래머가 전혀 모르는 하드웨어로 작업하기 위해 업데이트가 필요하지 않습니다.
Answer
FPGA 에뮬레이터가 일반적으로 빈티지 하드웨어와 공유하는 장점은 하드웨어와 상호 작용하는 장치를 매우 타이밍에 의존하는 방식으로 사용할 수 있다는 것입니다. 예를 들어 NES 용 게임 카트리지가있는 경우 특정 스프라이트에 대한 데이터의 첫 줄을 가져올 때마다 인터럽트를 트리거합니다. 카트리지의 내용을 읽은 다음 에뮬레이트하는 콘솔은 카트리지가 무엇인지 인식 할 수있는 경우에만 게임을 올바르게 실행할 수 있습니다. 인터럽트 라인으로 작업했습니다.
FPGA 기반 하드웨어는 일반적으로 잘 작동합니다. 빈티지 하드웨어보다 안정적이지만 염두에 두어야 할 몇 가지 이상한 단점이 있습니다. 예를 들어, Atari 2600의 일부 프로토 타입 확장 카트리지는 NMOS 6502가 데이터 버스를 높이려고 할 때도 외부 장치를 압도 할만큼 충분히 노력할 수 없다는 사실에 의존했습니다. 라인을 낮게 당기거나 시도 중에 자체를 손상시키지 마십시오. 그 반대는 사실이 아닙니다. 외부 장치가 라인을 하이로 당기는 동안 라인을 로우로 당기려고하는 NMOS 장치는 시도 중에 자신을 손상시킬 수 있습니다 (RIP 2600jr). 버스 와이어를 오버 드라이브하는 기능에 의존하는 NMOS 장치를 최신 레크리에이션 시스템에 연결하고 시스템이 이러한 와이어의 하이 사이드 드라이브 전류를 제한하지 않으면 외부 장치가 손상 될 수 있습니다. 그것이 실제로 어느 정도 문제가 될지는 알지만, 그러한 기술에 의존하는 모든 장치는 아마도 드물기 때문에 손상되면 매우 불행 할 것입니다.
또 다른 잠재적 인 문제는 빈티지 전자 제품이 종종 신호에 대한 응답이 느리기 때문에 장치가 와이어에서 신호를 매우 짧게 출력하면 무시 될 가능성이 큽니다. 일부 빈티지 전자 제품은 출력이 낮아야하는 한 상태와 출력이 낮아야하는 다른 상태 사이에서 일부 입력 조합이 변경되면 짧은 글리치 펄스를 출력하는 경우가 있습니다. FPGA 재현이 이러한 펄스를 무시하도록 설계되지 않은 경우, 원래에는 문제가 발생하지 않았더라도 재현 된 하드웨어에서 잘못된 작동을 일으킬 수 있습니다.
개인적으로 FPGA가 최선의 방법이라고 생각합니다. 빈티지 하드웨어는 멋지지만 신뢰성은 종종 문제가됩니다. 소프트웨어 에뮬레이션은 꽤 잘 작동 할 수 있지만 에뮬레이터 설계자가 알고있는 하드웨어와의 인터페이스로 제한됩니다. 좋은 FPGA 기반의 재현은 거의 모든 종류의 빈티지와 인터페이스 할 수 있습니다. FPGA 디자이너가 알지 못하는 장치를 포함하는 하드웨어는 빈티지 하드웨어보다 더 나은 안정성을 제공합니다.
답변
머리말 : 누군가가 에뮬레이션을 받아 들인다면 의견이므로 의견을 묻는 질문의 이음새, CPU 또는 FPGA의 소프트웨어가 실제와 같든 아니든 상관 없습니다.
자신에게 물어보세요. 실물을 운전하는 것과 같은 SSK처럼? 1950 년대 BMW를 타고 모든 소리, 냄새, 진동 (그리고 계속 유지하는 데 필요한 모든 땜질) 또는 하나처럼 보이도록 제작 된 2020 전기 자전거를 타고 iPod 빌드에서 클래식 사운드를 제공 하시겠습니까? ?
실제 하드웨어, MiSTer와 같은 FPGA 기반 하드웨어 에뮬레이터 및 대량의 소프트웨어를 사용하는 것 사이의 차이점은 무엇입니까? 최신 Windows, MacOS 및 Linux 컴퓨터에서 실행되는 다양한 시스템 용 에뮬레이터입니다.
단순한 사용자라면 최신 키보드와 최신 마우스를 사용하는 것이 좋습니다. 4k 화면에서 640 x 400처럼 보이는 일부 이미지를 처리하면 소프트웨어 만 있으면됩니다. 이미 FPGA 버전은 동일한 최신 장치를 사용하기 때문에 과도 할 것입니다.
반면에 , 이미징이 충분하지 않지만 부피가 큰 Atari 마우스, 흔들리는 Amiga 키보드 또는 부피가 큰 C64 조이스틱, 모두 실제 CRT 눈부심을 느끼고 싶다면 다른 방법은 없습니다. 사실을 이해하는 것입니다.
내 생각에 떠오른 한 가지는 소프트웨어와 하드웨어 에뮬레이터가 모두 정확하지 않을 수 있다는 것입니다.
지금까지는 그렇습니다. 모든 세부 사항에서. 최신 하드웨어는 HLL 소프트웨어를 사용하여 정확한주기 타이밍을 얻을 수있을만큼 빠릅니다. 특히 모든 입력 및 출력이 어쨌든 에뮬레이션 될 때 최신 장치에 매핑됩니다.
하지만 이것은 구현의 품질에 따라 에뮬레이터마다 다르며 버그 수정으로 인해 시간이 지남에 따라 개선되지만 근본적인 문제는 아닙니다.
지연 프로그래밍 및 유지 관리는 접근 방식을 무효화하지 않습니다. 실제 하드웨어를 제외하고는 모든 용도에 차이가 없습니다.
또한 소프트웨어 에뮬레이터의 지연 문제에 대해 들었습니다. “에뮬레이트 된 컴퓨터보다 수백만 배 더 빠른 컴퓨터에서 이와 같은 것을 실제로 느낄 수 있다는 사실에 조금 놀랐습니다.
아마도 수백 번, 대부분의 주요 구성 요소는 그다지 빨라지지 않았으며 대부분은 더 큰 크기의 기기와 데이터 요구로 인해 소모되었습니다.
지연 시간 문제는 언제나처럼 주변에있었습니다. 항상 차이를보고 느낄 수 있다는 말이있을 것입니다. 이것은 매우 헌신적 인 몇 가지 상황에서 사실 일 수 있지만 대부분의 경우 쓰레기입니다. 조이스틱을 테스트 할 때 이미 더 많은 비용이들 수있는 몇 마이크로 초의 느낌을 주장하는 것은 단순히 환상적입니다.
실제 하드웨어 또는 FPGA 기반 에뮬레이션과 소프트웨어 에뮬레이션을 선호하는 기술적 인 이유가 있습니까?
기술적 인 이유를 구성하는 요소 완전히 다른 구현을 비교할 때 그 용어 자체는 명확하지 않습니다.
또는 이것은 당신처럼 채우고 싶은 욕구로 인한 향수 일뿐입니다. 정말 80 년대 또는 90 년대로 돌아 왔나요?
이전 컴퓨터 앞에 앉아 본 적이 있나요? 오늘날의 표준화 된 장비를 떠날 때 다른 키보드를 느낍니다.
그리고 물론 하드웨어 땜질이 있습니다. 여기에 인터페이스를 추가하는 것은 단지 몇 줄의 코드-또는 그냥 구성 어떤 경우에는. 레이아웃, 에칭, 납땜, 특히 작동 할 때까지 저주 및 패치가 필요 없습니다.
답변
원합니다. 질문에 언급 된 “FPGA 에뮬레이션”용어를 명확히하십시오.
먼저, 소프트웨어 에뮬레이션과 같은 것이 있습니다. 6502 CPU의 정확한 소프트웨어 에뮬레이터를 예로 들어 보겠습니다. . 그들은 각 명령 당 사이클 수, 메모리 액세스 주소, 심지어 “내부 상태”(소프트웨어 표시 레지스터의 상태 만)와 같은 실제 CPU의 모든 외부 아티팩트를 에뮬레이션하려고합니다. 그러나 실제 CPU와는 전혀 다르지 않습니다. 처음부터 하드웨어 장치가 아니라 순수한 소프트웨어 문제입니다.
실제 6502의 새로운 기능이 발견되면 (문서화되지 않은 새로운 opcode, 플래그 또는 실행 세부 정보와 같은) ), “구현할 또 다른 기능”과 같이 소프트웨어 에뮬레이터에 삽입됩니다. 구현 자에게 알려지지 않은 실제 기능은 소프트웨어 에뮬레이터에 포함되지 않습니다.
그런 다음 6502 호환 HDL 코어를 살펴 보겠습니다.이제 실제로는 실제 디지털 로직 장치 또는 그 모델 (HDL이 시뮬레이션 된 경우 FPGA 또는 ASIC과 같은 실제 하드웨어에서 구현되지 않음)을 나타냅니다. 그들은 이제 CPU 레지스터를위한 실제 플립 플롭 (또는 래치) 스토리지를 가지고 있으며, 실제 CPU 버스 신호를 구현할 수 있으며 원래 6502 대신 레트로 컴퓨터에 삽입 될 수도 있습니다. 그러나 그들은 “처음부터”만들어집니다. CPU의 사양에 따라 내부 구조가 아니라 교체 할 예정입니다. 그럼에도 불구하고 실제 레트로 CPU에 존재하지만 아직 구현 자에게 알려지지 않은 사양에 설명되지 않은 기능이 부족합니다.
재 구축의 또 다른 수준은 다음과 같은 방식으로 구축 된 HDL 설계 일 수 있습니다.
- 진짜 복고풍 CPU의 캡을 제거하고 사진을 찍습니다.
- 그런 다음 넷리스트 및 트랜지스터 수준 회로도를 다시 만듭니다 (수작업으로 또는 다소 자동화 된 도구로)
- netlist는 게이트 레벨 회로도로 변환 된 다음 HDL 설명으로 변환되며 이는 다시 FPGA 또는 ASIC에서 구현됩니다.
이전 사례와 달리 이제 실제 CPU의 거의 모든 기능 결과 HDL의 구조가 (논리 게이트 및 플립 플롭 수준에서) 실제 구조와 거의 동일하기 때문에 “기본적으로”구현됩니다.
그래도 문제가있을 수 있습니다 (예 : 6502). 비정상적으로 동작하는 몇 가지 지침이 있으며 이러한 동작이 HDL에서 자연스럽게 나타나지 않을 것이라고 생각합니다.
일반적으로 말하자면, “역 엔지니어 후 HDL 재생성”위의 모든 것은 소프트웨어 또는 하드웨어에서 실제로 에뮬레이션 이지만 후자는 아닙니다 .
즉, 이전 소프트웨어의 보존을 고려해 보겠습니다. 최신 하드웨어에서 실행할 수 있지만 사용할 수없는 경우 소프트웨어 에뮬레이터가 작동하지만 실행에 사용되는 이전 소프트웨어 부분은 여전히 똑같습니다.
이제 우리는 오래된 하드웨어 (CPU)를 보존하지만 실제 구현이 불가능하므로 최신 기술을 사용하여 다시 만들지 만 CPU의 논리 구조는 그대로 유지됩니다.
Answer
에뮬레이터 작성자로서 지연 시간 질문에 대해서만 답변을 제공하려면 :
예외가 많지만 “80 년대 및 90 년대 초는 조이패드 및 키보드 입력 변경이 발생하는 즉시 하드웨어에 의해 감지 될 수 있으며, 비디오 및 오디오가 기계에서 출력됨에 따라 거의 즉시 사용자에게 도달합니다. 예를 들어 클래식 CRT TV의 경우 래스터 수준 지금 페인팅은 기계의 실제 출력에 가깝습니다.
지금 하드웨어를 사용하면 입력이 일반적으로 Bluetooth 또는 USB 스택은 호스트 OS에서 특정 간격으로 만 검사 할 수 있으며, 어떤 일이 발생하면 특정 스케줄러에 따라 즉시 발생하거나 발생하지 않을 수있는 관련 프로세스에이를 전달합니다.
많은 에뮬레이터는 게임을 디자인하는 방식과 유사한 메인 루프도 구현합니다.
- 모든 최신 입력을 수집하여 에뮬레이트 된 컴퓨터로 전달합니다.
- 프레임을 위해 머신을 실행합니다.
- 보이지 않는 버퍼에 다음 출력 프레임을 페인트합니다.
- 다음 vsync 및 블록에 표시하기 위해 큐에 넣습니다.
- 반복합니다.
논쟁을 위해 현대 기계가 매우 빠르고 2 단계와 3 단계가 즉각적이라고 상상해보십시오. 그런 다음 :
- 평균 절반 프레임의 입력 대기 시간과 Bluetooth / USB 신호 및 OS가 추가됩니다. 프레임 상단 직후에 발생하는 입력은 전달되지 않습니다. 다음이 시작될 때까지, 끝에서 바로 발생하는 모든 것은 거의 적시에 전달 될 것이며, 그 사이의 지연 시간 범위는 선형이므로 평균은 중간입니다. 그리고
- 다음 vsync에서 프레젠테이션을 위해 프레임을 게시 한 다음 표시 될 때까지 기다리기 때문에 출력 지연의 고정 된 추가 프레임이 있습니다.
따라서 이상적인 하드웨어에서 간단한 루프를 사용하면 평균적으로 무언가를 누르고 화면이 반응하는 사이의 지연이 실제 하드웨어보다 약 1.5 프레임 더 많습니다. 호스트와 에뮬레이트 된 시스템이 동일한 프레임 속도로 실행되는 경우에만 해당됩니다. .
순수 주의자들은 일부 오리지널 게임이 하루에 적절한 시간을 테스트하고 조정 한 후 1.5 프레임으로 인해 감지 할 수있는 불이익을 줄 정도로 세밀하게 조정되었다고 주장합니다.
FPGA는 일반적으로 판매 방법에 관계없이 * 에뮬레이션입니다. 일반적으로 고급 하드웨어 설명 언어로 사양을 다시 구현하는 사람이기 때문입니다. 그러나 그들은 가능한 한 많은 지연 시간을 생략하려고합니다. 좋은 품질은 비디오 버퍼링을 완전히 생략하고 나머지 시스템을 실시간으로 실행하며 최소한의 지연으로 입력을 밀어 넣습니다.
* 자격 아래 @lvd에서 제공 한 수정 사항에 따라 추가되었습니다. 더 많은 색상은 그의 대답을 참조하십시오.
물론 소프트웨어에서 대부분의 소프트웨어 문제를 해결하는 것은 어렵지 않습니다.
- 입력을 더 자주 전달하십시오.
- 하지 마십시오. vsync를 사용하여 vsync에 대한 새 출력을 트리거합니다. 그리고
- 더블 버퍼를 사용하지 마십시오.
극단적으로 FPGA와 유사한 출력 지연 시간을 위해 래스터를 경쟁 할 수도 있습니다. -빈번한 입력을위한 주파수 루프와 기본 하드웨어가 화면 찢어짐을 유발할 수있는 모든 종류의 출력을 지원하는 경우 “도구가 있습니다.
안타깝게도 이러한 접근 방식은 일반적으로 에뮬레이터에서 사용하지 않았습니다. 특히 지연 시간이 널리 논의되는 주제가되어 부정적인 이미지가 멈춰 있기 전에는 더욱 그렇습니다.
댓글
답변
여기에서 다른 게시물에서 HW 대 SW의 많은 측면을 다루었으므로 만지지 마십시오. 대신 다양한 플랫폼 용 에뮬레이터를 코딩하는 동안 얻은 경험과 함께 내 관점에서 LATENCY 문제를 설명하고 싶습니다. …
최신 컴퓨터에서 SW 에뮬레이터를 만드는 것은 직접 I / O 액세스 시간보다 지연 측면에서 훨씬 더 어렵습니다. 가정용 컴퓨터 및 게임 콘솔의 경우 사운드, 시각적 출력 및 사용자 입력을 최대한 정확하게 시뮬레이션 / 에뮬레이션해야합니다. 가장 큰 문제는 소리입니다. 우리의 청력은 다른 어떤 감각보다 훨씬 낫고 소리가 ms 또는 . 화면이 1 ~ 2 프레임 떨어져 있으면 차이를 볼 수 없습니다. 또한 입력이 약간 지연 되어도 괜찮습니다 (대부분의 사람에게 해당).
현대 머신 아키텍처에서는 모든 것이 버퍼링됩니다. (특히 사운드). 따라서 사운드를 출력하려면 사운드 칩으로 전송되고 iv id를 통해 재생되는 PCM 데이터를 만들어야합니다. = “9acf87b885″>
DMA + DAC . 이를 수행하기 위해 일반적으로 2 개의 원형 또는 여러 개의 작은 선형 버퍼가 사용됩니다. 이제 글리치없는 사운드를 생성하려면 버퍼가 충분히 커야합니다. 예를 들어 Windows에서 마지막으로 WAVEOUT 를 확인하려면 최소 20-80 ms가 필요합니다. DirectSound 필요 >400 ms
이제 에뮬레이트 된 프로그램이 조정되는 경우 사운드 출력은 이미 삽입 된 사운드가 재생 된 후에 만 출력됩니다.
일부 플랫폼의 I / O 입력도 마찬가지이므로 지연이 추가됩니다.
FPGA 그러면 버퍼링없이 사운드 출력에 직접 액세스 할 수 있습니다. 입력도 마찬가지입니다.
그러나 게임 입력 대기 시간 (키보드, 조이스틱)은 일반적으로 호스트 시스템의 대기 시간과 관련이 없습니다. . 일반적인 원인은 대부분의 에뮬레이터가 에뮬레이트 된 속도를 유지하기 위해 클럭 틱 을 사용하기 때문입니다. 따라서 CPU 등을 시뮬레이션하고 시간당 원하는 시뮬레이션 클록 수에 도달하면 다음 타이머가 실행될 때까지 절전 모드로 전환됩니다. 호스트 컴퓨터가 빠를수록 에뮬레이션하는 데 필요한 시간이 짧아 지므로 시뮬레이션이 대부분의 실시간으로 반응하지 않습니다.
예를 들어 시뮬레이션이 에뮬레이션 된 컴퓨터의 원래 속도보다 100 배 빠르게 실행될 수 있다고 가정 해 보겠습니다. 즉, 시뮬레이션이 무언가를 수행하는 시간의 1 %만이 Sleep()에 불과합니다. 수면 중에 에뮬레이션은 아무것도 응답 할 수 없습니다. 따라서 키 입력을 놓치거나 클릭을 발생시킬 수 있습니다. 일부 에뮬레이터가 다시 버퍼링을 사용하여 입력을 무시하는 대신 지연 시간을 유발할 수 있습니다. 이 문제를 완전히 제거하는 다른 스타일의 시간 제어도 있습니다. 이 주제에 대한 자세한 내용은 다음을 참조하십시오.