mirror of
https://github.com/TomHarte/CLK.git
synced 2024-11-26 23:52:26 +00:00
Corrects 16-bit read-modify-write.
Subject to the TODO proviso on 'correct'; has my 6502 prejudice pushed me into unrealistic bus signalling?
This commit is contained in:
parent
5dc3cd3a2f
commit
f529eadbec
@ -97,6 +97,10 @@ template <typename BusHandler> void Processor<BusHandler>::run_for(const Cycles
|
||||
read(data_address_, data_buffer_.next_input());
|
||||
break;
|
||||
|
||||
case CycleFetchDataThrowaway:
|
||||
read(data_address_, &throwaway);
|
||||
break;
|
||||
|
||||
case CycleFetchIncorrectDataAddress:
|
||||
read(incorrect_data_address_, &throwaway);
|
||||
break;
|
||||
@ -120,7 +124,7 @@ template <typename BusHandler> void Processor<BusHandler>::run_for(const Cycles
|
||||
break;
|
||||
|
||||
case CycleStoreDecrementData:
|
||||
write(data_address_, data_buffer_.next_output());
|
||||
write(data_address_, data_buffer_.next_output_descending());
|
||||
decrement_data_address();
|
||||
break;
|
||||
|
||||
@ -149,7 +153,7 @@ template <typename BusHandler> void Processor<BusHandler>::run_for(const Cycles
|
||||
bus_operation = operation;
|
||||
|
||||
case CyclePush:
|
||||
stack_access(data_buffer_.next_stack(), MOS6502Esque::Write);
|
||||
stack_access(data_buffer_.next_output_descending(), MOS6502Esque::Write);
|
||||
--s_.full;
|
||||
break;
|
||||
|
||||
|
@ -159,7 +159,8 @@ struct CPU::WDC65816::ProcessorStorageConstructor {
|
||||
if(!is8bit) target(CycleFetchIncrementData); // Data low.
|
||||
target(CycleFetchData); // Data [high].
|
||||
|
||||
if(!is8bit) target(CycleFetchData); // 16-bit: reread final byte of data.
|
||||
// TODO: does this look like another read? Or if VDA and VPA are both low, does the 65816 actually do no access?
|
||||
if(!is8bit) target(CycleFetchDataThrowaway); // 16-bit: reread final byte of data.
|
||||
else target(CycleStoreDataThrowaway); // 8-bit rewrite final byte of data.
|
||||
|
||||
target(OperationPerform); // Perform operation within the data buffer.
|
||||
@ -720,7 +721,7 @@ struct CPU::WDC65816::ProcessorStorageConstructor {
|
||||
target(OperationConstructStackRelative);
|
||||
target(CycleFetchIncrementData); // AAL
|
||||
target(CycleFetchData); // AAH
|
||||
target(CycleFetchData); // IO.
|
||||
target(CycleFetchDataThrowaway); // IO.
|
||||
|
||||
target(OperationConstructStackRelativeIndexedIndirect);
|
||||
read_write(type, is8bit, target);
|
||||
@ -1052,6 +1053,7 @@ void ProcessorStorage::set_emulation_mode(bool enabled) {
|
||||
}
|
||||
|
||||
void ProcessorStorage::set_m_x_flags(bool m, bool x) {
|
||||
// true/1 => 8bit for both flags.
|
||||
mx_flags_[0] = m;
|
||||
mx_flags_[1] = x;
|
||||
|
||||
|
@ -23,6 +23,8 @@ enum MicroOp: uint8_t {
|
||||
/// Fetches from the address formed by the low byte of the data address and the high byte
|
||||
/// of the instruction buffer, throwing the result away.
|
||||
CycleFetchIncorrectDataAddress,
|
||||
/// Fetches a byte from the data address and throws it away.
|
||||
CycleFetchDataThrowaway,
|
||||
|
||||
// Dedicated block-move cycles; these use the data buffer as an intermediary.
|
||||
CycleFetchBlockX,
|
||||
@ -306,7 +308,7 @@ struct ProcessorStorage {
|
||||
return byte(read);
|
||||
}
|
||||
|
||||
uint8_t *next_stack() {
|
||||
uint8_t *next_output_descending() {
|
||||
--size;
|
||||
return byte(size);
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user