2011-08-19 29 views
5

Tôi đang lên kế hoạch tạo bộ mô phỏng Hệ thống Sega Master trong vài tháng tới, như một dự án sở thích trong Java (tôi biết nó không phải là ngôn ngữ tốt nhất cho điều này nhưng tôi thấy nó rất thoải mái khi làm việc, và với tư cách là người dùng thường xuyên của cả Windows và Linux, tôi nghĩ một ứng dụng đa nền tảng sẽ rất tuyệt vời). Câu hỏi của tôi liên quan đến đếm chu kỳ;Câu hỏi về độ chính xác đếm chu kỳ khi mô phỏng CPU

Tôi đã xem qua mã nguồn cho trình mô phỏng Z80 khác và cho các trình mô phỏng khác, và đặc biệt vòng lặp thực hiện thu hút tôi - khi nó được gọi, int được chuyển thành đối số (giả sử 1000 là một ví dụ). Bây giờ tôi nhận được rằng mỗi opcode mất một số chu kỳ khác nhau để thực hiện, và khi chúng được thực hiện, số chu kỳ được giảm đi từ con số tổng thể. Khi số chu kỳ còn lại là < = 0, vòng lặp thực thi sẽ kết thúc.

Câu hỏi của tôi là nhiều người trong số các trình giả lập này không tính đến thực tế là lệnh cuối cùng được thực thi có thể đẩy số chu kỳ đến giá trị âm - nghĩa là giữa các vòng lặp thực hiện, có thể kết thúc bằng , 1002 chu kỳ được thực hiện thay vì 1000. Điều này có ý nghĩa không? Một số trình giả lập giải thích điều này bằng cách bù vào vòng lặp thực hiện tiếp theo và một số giả định không - cách tiếp cận nào là tốt nhất? Cho phép tôi minh họa cho câu hỏi của mình vì tôi không đặc biệt giỏi khi đặt mình lên trên:

public void execute(int numOfCycles) 
{ //this is an execution loop method, called with 1000. 
    while (numOfCycles > 0) 
    { 
     instruction = readInstruction(); 
     switch (instruction) 
     { 
     case 0x40: dowhatever, then decrement numOfCycles by 5; 
     break; 
     //lets say for arguments sake this case is executed when numOfCycles is 3. 
     } 
} 

Sau khi kết thúc ví dụ lặp này, numOfCycles sẽ là -2. Điều này sẽ chỉ bao giờ là một sự thiếu chính xác nhỏ nhưng liệu nó có quan trọng trong kinh nghiệm của mọi người không? Tôi đánh giá cao sự hiểu biết của bất cứ ai về điều này. Tôi có kế hoạch để làm gián đoạn CPU sau mỗi khung như thế này có vẻ thích hợp, vì vậy 1000 chu kỳ là thấp tôi biết, đây chỉ là một ví dụ mặc dù.

Rất cám ơn, Phil

Trả lời

2

Là một bài viết khá thú vị về Arstechnica nói về giao diện điều khiển mô phỏng thời gian gần đây, cũng liên kết tới khá một vài mô phỏng mà có thể làm cho việc nghiên cứu khá tốt:

Accuracy takes power: one man's 3GHz quest to build a perfect SNES emulator

Các bit có liên quan được rằng tác giả đề cập, và tôi có khuynh hướng đồng ý rằng hầu hết các trò chơi sẽ xuất hiện hoạt động khá chính xác ngay cả với độ lệch thời gian là +/- 20%. Vấn đề bạn đề cập có khả năng không bao giờ thực sự giới thiệu nhiều hơn một phần nhỏ của một lỗi thời gian phần trăm, mà có lẽ là không thể nhận thấy trong khi chơi trò chơi cuối cùng. Các tác giả có lẽ đã không xem xét nó có giá trị đối phó với.

+0

Cảm ơn :-) Tôi đã xem bài viết này cách đây vài ngày và đó là một bài đọc rất thú vị. Có vẻ như tôi có thể bỏ qua vấn đề này - đã cắt công việc của tôi nhưng nên vui vẻ! :-p – PhilPotter1987

0

Tôi đoán điều đó phụ thuộc vào cách chính xác bạn muốn giả lập của bạn được. Tôi không nghĩ rằng nó phải là chính xác. Hãy suy nghĩ thi đua của nền tảng x86, có rất nhiều biến thể của bộ vi xử lý và mỗi biến thể có độ trễ thực thi khác nhau và tỷ lệ phát hành.

+0

Vâng, tôi nghĩ miễn là tôi buộc nó với tỷ lệ khung hình - nói 50fps nếu tôi bắt chước một PAL console - Sau đó, giữa những khung nếu tôi thực hiện bao nhiêu chu kỳ nó là và sau đó tạm dừng trong khi tôi cập nhật màn hình cần được đầy đủ. Đoán tôi sẽ tìm ra :-p Cảm ơn câu trả lời. – PhilPotter1987

4
  1. nhất giả lập/mô phỏng đối phó chỉ với CPU Clock tics

    Đó là tốt cho các trò chơi vv ... Vì vậy, bạn có một số timer hoặc những gì bao giờ hết và chạy các mô phỏng của CPU cho đến khi CPU mô phỏng thời gian của bộ hẹn giờ. Sau đó, nó ngủ cho đến khi khoảng thời gian hẹn giờ tiếp theo xảy ra. Điều này là rất dễ dàng để mô phỏng. bạn có thể giảm lỗi thời gian bằng cách tiếp cận mà bạn đang hỏi. Nhưng như đã nói ở đây cho trò chơi là điều này thường không cần thiết.

    Cách tiếp cận này có một hạn chế đáng kể và đó là mã của bạn chỉ hoạt động một phần trong thời gian thực. Nếu khoảng thời gian hẹn giờ (độ chi tiết thời gian) đủ lớn, điều này có thể đáng chú ý ngay cả trong trò chơi.Ví dụ: bạn nhấn phím Bàn phím trong thời gian khi mô phỏng Ngủ thì không phát hiện được. (đôi khi các phím không hoạt động). Bạn có thể khắc phục điều này bằng cách sử dụng mức độ chi tiết thời gian nhỏ hơn nhưng đó là trên một số nền tảng rất khó. Trong trường hợp đó, lỗi thời gian có thể "hiển thị" nhiều hơn trong phần mềm được tạo ra Âm thanh (ít nhất là đối với những người có thể nghe và không bị điếc với những thứ như tôi).

  2. nếu bạn cần một cái gì đó phức tạp hơn

    Ví dụ, nếu bạn muốn kết nối thực HW để thi đua của bạn/mô phỏng thì bạn cần phải bắt chước/mô phỏng BUS'es. Ngoài ra những thứ như xe buýt nổi hoặc ganh đua của hệ thống là rất khó để thêm vào cách tiếp cận # 1 (có thể thực hiện được nhưng với nỗi đau lớn).

    Nếu bạn cảng timings và thi đua để chu kỳ máy mọi việc trở nên dễ dàng hơn nhiều nhiều và đột nhiên những thứ như tranh hoặc HW ngắt, BUS'es nổi đang giải quyết bản thân gần như một mình. Tôi chuyển ZXSpectrum Z80 giả lập của tôi để loại thời gian và nhìn thấy ánh sáng. Nhiều thứ trở nên rõ ràng (như lỗi trong tài liệu mã hóa Z80, thời gian vv). Ngoài ra tranh chấp đã rất đơn giản từ đó (chỉ vài dòng mã thay vì bảng giải mã khủng khiếp gần như mỗi mục nhập kiểu lệnh). Giả lập HW cũng khá dễ dàng, tôi thêm những thứ như chip điều khiển FDC AY mô phỏng cho Z80 theo cách này (không có hack nó thực sự chạy trên mã ban đầu của chúng ... thậm chí là định dạng mềm :)) nên không còn TAPE Loading hacks và không hoạt động cho các trình tải tùy chỉnh như TURBO

    Để thực hiện công việc này, tôi đã tạo mô phỏng/mô phỏng của mình là Z80 theo cách sử dụng mã như microcode cho mỗi lệnh. Vì tôi rất thường sửa lỗi trong Z80 bộ hướng dẫn (vì không có tài liệu chính xác 100% nào ở đó, tôi biết ngay cả khi một số người cho rằng chúng không có lỗi và hoàn chỉnh), tôi có cách giải quyết nó mà không cần lập trình lại chương trình giả lập một cách đau đớn.

    Mỗi lệnh được biểu thị bằng một mục nhập trong bảng, với thông tin về thời gian, toán hạng, chức năng ... Bộ lệnh toàn bộ là một bảng của tất cả các mục nhập cho tất cả các hướng dẫn. Sau đó, tôi tạo một cơ sở dữ liệu MySQL cho tập lệnh của tôi. và tạo các bảng tương tự cho mỗi bộ lệnh tôi tìm thấy. Sau đó, đau đớn so sánh tất cả chúng lựa chọn/sửa chữa những gì là sai và những gì là chính xác. Kết quả được xuất sang tập tin văn bản đơn lẻ được nạp lúc khởi động mô phỏng. Nghe có vẻ khủng khiếp nhưng thực tế nó đơn giản hoá mọi thứ thậm chí tăng tốc độ thi đua khi giải mã lệnh bây giờ chỉ là truy cập con trỏ.Các tập tin dữ liệu hướng dẫn thiết lập ví dụ có thể được tìm thấy ở đây What's the proper implementation for hardware emulation

Vài năm trở lại tôi cũng xuất bản giấy về vấn đề này (buồn bã tổ chức đó cho rằng hội nghị không tồn tại nữa vì vậy các máy chủ đang xuống cho tốt trên những giấy tờ cũ may mắn là tôi vẫn có một bản sao) Vì vậy, đây hình ảnh từ nó mô tả problematics:

CPU Scheduling

  • a) Full throtlle không có đồng bộ hóa chỉ nguyên tốc độ
  • b) # 1 có lỗ hổng lớn gây HW vấn đề đồng bộ hóa
  • c) # 2 nhu cầu ngủ rất nhiều với granularity rất nhỏ (có thể là điều khó giải quyết và làm chậm) Nhưng các hướng dẫn được thực hiện rất gần thời gian thực của họ ...
  • Đường màu đỏ là tốc độ xử lý CPU của máy chủ (rõ ràng là ở trên mất thêm một chút thời gian để nó được cắt và chèn trước khi lệnh tiếp theo nhưng khó rút ra được)
  • Dòng màu đỏ tươi là tốc độ xử lý CPU được mô phỏng/mô phỏng
  • alternatin g green/blue màu sắc đại diện cho hướng dẫn tiếp theo
  • cả axises là thời gian