Đăng ký làm mới bộ nhớ Z80

Question

Tôi một lần nữa với một câu hỏi Z80 vô hại khác :-) Cách lõi giả lập của tôi hiện được cấu trúc, tôi tăng 7 bit thấp hơn của thanh ghi làm mới bộ nhớ mỗi lần một byte opcode được lấy từ bộ nhớ - điều này có nghĩa là cho các lệnh đa byte, chẳng hạn như các lệnh bắt đầu DD hoặc FD, tôi tăng thanh ghi hai lần - hoặc trong trường hợp của lệnh như RLC (IX + d) ba lần (vì nó được đặt ra opcode1-opcode2-d -opcode3).

Điều này có đúng không? Tôi không chắc chắn - hướng dẫn sử dụng Z80 là không rõ ràng về điều này, vì nó nói rằng CPDR (một lệnh hai byte) tăng nó hai lần, tuy nhiên phần 'Memory Refresh Register' chỉ nói nó tăng sau mỗi lần lấy lệnh. Tôi đã nhận thấy rằng J80 (một trình mô phỏng tôi đã kiểm tra là tôi không chắc chắn về điều này) chỉ tăng sau byte byte opcode đầu tiên của một lệnh.

Điều gì là chính xác? Tôi đoán nó không phải là cực kỳ quan trọng trong mọi trường hợp, nhưng nó sẽ được tốt đẹp để biết :-) Rất cám ơn.

Kính trọng, Phil Potter

Answer 1

Tất cả các tài liệu tham khảo tôi có thể tìm thấy trực tuyến nói rằng R là tăng một lần theo hướng dẫn không phụ thuộc vào chiều dài của nó.

Answer 2

Sean Young's Z80 Undocumented Features có một câu chuyện khác. Một lần cho unprefixed, hai lần cho một tiền tố duy nhất, cũng hai lần cho một tiền tố đôi (DDCB chỉ), và một lần cho tiền tố no-op.

Hướng dẫn chặn tất nhiên ảnh hưởng đến R mỗi khi chúng chạy (và chúng chạy BC lần).

Answer 3

Biểu đồ thời gian Zilog giữ câu trả lời cho câu hỏi của bạn.

Làm mới xảy ra trong T3 và T4 của tất cả các chu kỳ M1 (tìm nạp mã).

Trong trường hợp chỉ dẫn một mã opcode, đó là một lần làm mới cho mỗi lệnh. Đối với các hướng dẫn tiền tố đơn (tiền tố được đọc bằng các chu kỳ M1), đó là hai lần làm mới cho mỗi lệnh.

Đối với những lệnh DD-CB-disp-opcode và FD-CB-disp-opcode lạ kỳ lạ (kỳ lạ vì byte dịch chuyển đến trước opcode cuối cùng thay vì sau), số lần làm mới ít nhất 3 (cho hai tiền tố và opcode cuối cùng), nhưng tôi không chắc chắn nếu byte chuyển được đọc như là một phần của chu trình M1 (sẽ kích hoạt làm mới khác) hoặc chu kỳ đọc bộ nhớ thông thường (không làm mới). Tôi có xu hướng tin rằng byte dịch chuyển được đọc trong một chu kỳ M1 cho các hướng dẫn này, nhưng tôi không chắc chắn. Tôi hỏi Sean Young về điều này; anh cũng không chắc. Có ai biết chắc chắn không?

UPDATE:

Tôi đã trả lời câu hỏi của riêng tôi lại những hướng dẫn DD-CB-disp-opcode và FD-CB-disp-opcode lạ. Nếu bạn kiểm tra tài liệu của Zilog về các lệnh loại này, chẳng hạn như RLC (IX + d), bạn sẽ lưu ý rằng lệnh yêu cầu 6 chu trình M và 23 chu kỳ T được chia nhỏ thành: (4,4,3,5, 4,3).

Chúng tôi biết hai chu kỳ M đầu tiên là các chu kỳ M1 để tìm nạp tiền tố DD và CB (4 T-chu kỳ mỗi). Chu kỳ M tiếp theo đọc byte dịch chuyển d. Nhưng chu trình M đó chỉ sử dụng 3 chu trình T, không phải 4, vì vậy nó không thể là một chu kỳ M1; thay vào đó là một chu kỳ đọc bộ nhớ bình thường.

Đây là sự phân hủy của các RLC (IX + d) sáu M-chu kỳ chỉ dẫn của:

1. M1 chu kỳ để đọc các tiền tố 0xDD (4 T-chu kỳ)
2. chu kỳ M1 để đọc các tiền tố 0xCB (4 T-chu kỳ)
3. Memory đọc chu kỳ để đọc các byte chuyển (3 T-chu kỳ)
4. chu kỳ M1 để lấy opcode 0x06 và tải IX vào ALU (5 T-chu kỳ)
5. Memory đọc chu kỳ để tính toán và đọc từ địa chỉ IX + d (4 T-cy Cles)
6. Memory Write chu kỳ để tính toán RLC và viết kết quả để giải quyết IX + d (3 T-chu kỳ)

(Việc tính toán RLC chồng chéo M-chu kỳ 5 và 6.)

Những hướng dẫn loại là duy nhất ở chỗ chúng là các chỉ dẫn Z80 duy nhất có chu kỳ M1 không tiếp giáp (M-chu kỳ 1, 2 và 4 ở trên). Chúng cũng chậm nhất!

Paul

Answer 4

Tôi đã nhìn thấy một vài nhận xét ngay bây giờ rằng các hướng dẫn DDCB và FDCB lạ này chỉ tăng thanh ghi R hai lần.

Nó luôn luôn là giả định của tôi (và cách tôi thực hiện giả lập Z80 của tôi) rằng thanh ghi R được thực hiện vào cuối mỗi chu kỳ M1.

Để tóm tắt lại, những DDCB và FDCB hướng dẫn lạ bốn byte dài:

DD CB disp opcode

FD CB disp opcode

Rõ ràng là hai opcodes tiền tố được đọc bằng chu kỳ M1 , khiến thanh ghi R được tăng lên ở cuối mỗi chu kỳ đó.

Cũng rõ ràng rằng byte dịch chuyển theo sau tiền tố CB được đọc bởi chu kỳ Đọc thông thường, vì vậy thanh ghi R không được tăng lên ở cuối chu kỳ đó.

Điều đó để lại mã opcode cuối cùng. Nếu nó được đọc bởi một chu kỳ M1, thì thanh ghi R được tăng lên ở cuối chu kỳ, dẫn đến tổng cộng 3 lần gia tăng, hoặc trường hợp đặc biệt Z80 chu kỳ M1 này và không tăng thanh ghi R.

Có khả năng khác. Điều gì sẽ xảy ra nếu opcode cuối cùng được đọc bởi một chu trình đọc bình thường, giống như byte dịch chuyển trước nó, chứ không phải bởi một chu kỳ M1? Điều đó tất nhiên cũng sẽ làm cho R đăng ký được tăng lên chỉ hai lần cho các hướng dẫn này, và sẽ không yêu cầu Z80 để làm cho một ngoại lệ không tăng thanh ghi R vào cuối mỗi chu kỳ M1.

Điều này cũng có thể có ý nghĩa tốt hơn về trạng thái nội bộ của Z80. Khi nó chuyển sang các chu kỳ đọc bình thường để đọc các byte bổ sung của lệnh (trong trường hợp này là byte dịch chuyển theo tiền tố CB), nó sẽ không bao giờ chuyển trở lại chu kỳ M1 cho đến khi nó bắt đầu lệnh tiếp theo.

Có ai có thể kiểm tra điều này trên phần cứng Z80 thực, để xác nhận giá trị của thanh ghi R theo một trong các hướng dẫn DDCB hoặc FDCB này không?