...
The actual mapping logic is orchestrated by the “monitor_bus” component.
...
cpustateram
| Code Block |
|---|
+-------------------+ (clock) clkA | | clkB (clock) -------> <-------> | <------- | weA | | | enaB ------> | (cpu_state_write) weA | <------- | | enaB (1) | enaA | ------> | <-------> | | | diA[127:0] | historyram0 | doB[7:0] -------------> (1) enaA | ---------------> | | addrA[9:0] | ------> | addrB[13:0] ------------> { | <-------------- | (0 [15:0]) | +-------------------+ |
I haven’t dived too deep into historyram0 and historyram1 as yet, though from my initial gleaming of it, historyram was trying to be more ambitious with the volume of data it captured in each trace entry (current x,y,z,a and a lot more).
Hence the reason why the left-side (write) has a data-bus size of 128-bits (can write 16-bytes per clock cycle).
cpustateram
| Code Block |
|---|
| (monitor_cpu_state[15:0]) | | (monitor_memory_access_address[31:0])| +-------------------+ | } --> (clock) clkA | diA[63:0] | cpustateram | clkB (clockdoB[7:0] (cpu_state_rdata[7:0]) -------------> <---------------> | | (cpu_state_write_index) weAaddrA[3:0] | | enaB (1addrB[6:0] (cpu_address_next[6:0]) ------->-----> <-------------- | | (1) enaA | | +-------------------> | { | | (0 [15:0]) | | (monitor_cpu_state[15:0]) | | (monitor_memory_access_address[31:0])| | } --> diA[63:0] | cpustateram | doB[7:0] (cpu_state_rdata[7:0]) -------------> ---------------> + |
This ‘cpustateram' component gets mapped to that $7000-$7fff region (from the 6502 cpu’s addressing perspective).
It's a dual-port ram, where I've put:
stuff on the left relating to signals wanting to write data into the ram.
stuff on the right relating to signals wanting to read data from the ram.
So on the left-side (write), seems like the idea is to write a big chunk of cpu-state related information within a single clock cycle.
monitor_cpu_state (16-bit, one byte is the internal cpu-state details, and the other byte is the currently read byte, I think)
monitor_memory_access_address (32-bit), the current address being accessed.
On the right-side (read), this is to let this 6502 monitor cpu read out this data via an 8-bit bus (a byte at a time).
So, the assembly code within "monitor.a65" will read from $7000-$7fff to try retrieve this cpu-state trace history.
This seems to be the data that is used to generate the output from the uart-monitor's z command. I.e., this stuff:
| Code Block |
|---|
.z
uS Address Rd
15 0000A50E:EA
00 00008100:00
00 00008100:00
00 00008100:00
06 00008100:00
14 0FFF8100:00
15 00008101:00
15 0FFF8101:4C
17 00008102:4C
17 0FFF8102:0D
18 00008103:0D
18 0FFF8103:A5
4F 00008103:A5
4F 0FFF8103:EA
14 0000A50D:EA
14 0FFFA50D:EA |
Signals relating to cpustateram
| Code Block |
|---|
| | (cpu_state_write_index) addrA[3:0] | +--------------------------------------------------------------------+ | addrB[6:0] (cpu_address_next[6:0]) | ------------>monitor_top.v / uart_monitor | monitor_cpu_state[15:0] | <-------------- | | ------------------------> +--- | | | monitor_memory_access_address[31:0] | | -------------------+ |
This ‘cpustateram' component gets mapped to that $7000-$7fff region (from the 6502 cpu’s addressing perspective).
It's a dual-port ram, where I've put:
stuff on the left relating to signals wanting to write data into the ram.
stuff on the right relating to signals wanting to read data from the ram.
So on the left-side (write), seems like the idea is to write a big chunk of cpu-state related information within a single clock cycle.
monitor_cpu_state (16-bit, one byte is the internal cpu-state details, and the other byte is the currently read byte, I think)
monitor_memory_access_address (32-bit), the current address being accessed.
On the right-side (read), this is to let this 6502 monitor cpu read out this data via an 8-bit bus (a byte at a time).
So, the assembly code within "monitor.a65" will read from $7000-$7fff to try retrieve this cpu-state trace history.
This seems to be the data that is used to generate the output from the uart-monitor's z command. I.e., this stuff:
| Code Block |
|---|
.z
uS Address Rd
15 0000A50E:EA
00 00008100:00
00 00008100:00
00 00008100:00
06 00008100:00
14 0FFF8100:00
15 00008101:00
15 0FFF8101:4C
17 00008102:4C
17 0FFF8102:0D
18 00008103:0D
18 0FFF8103:A5
4F 00008103:A5
4F 0FFF8103:EA
14 0000A50D:EA
14 0FFFA50D:EA |
Signals relating to cpustateram
| Code Block |
|---|
-----------------> | | +----------------+ | | | monitorctrl | | | (monitor_cpu_state[15:8])| | | | cpu_state[7:0] | | | | -----------------------> | | | | | | | cpu_state_write | | | | <----------------- | | | | | | | cpu_state_write_index | | | | <---------------------- | | | | | | | +----------------+ | | | | +----------------+ | | (cpu_state_rdata) | monitorbus | | | cpu_state | | | | ----------------> | | | | | | | (cpu_address_next[15:0]) | | | | cpu_address[15:0] | | | | ----------------> | | | | | | | (cpu_di) | | | | read_data[7:0] | | | | <--------------- | | | +----------------+ | | | | +----------------+ | | | cpu6502 | | | (cpu_address_next[15:0]) | (monitorcpu) | | | address_next[15:0] | | | | <------------------- | | | | | | | (cpu_di) | | | | data_i[7:0] | | | | --------------> | | | +----------------+ | | | +--------------------------------------------------------------------+ |
This was me deep-diving even further to learn more about the signals that relate to cpustateram and how that interact with other components.
historyram0 and historyram1
| Code Block |
|---|
(clock) +-------------------+ (clock) (clock) +-------------------+ (clock) clkA | | clkB clkA | | clkB -------> <------- -------> <------- | | | | (history_write) | | (1) +--------------------------------------------------------------------+ (history_write) | | (1) monitor_top.v / uart_monitor weA | | enaB monitor_cpu_state[15:0] | weA | | enaB ------> <------------------------> ------> <------- | | | | monitor_memory_access_address[31:0] | | ------------------------------------> | | | +----------------+ | | (1) | | | | monitorctrl | | | (monitor_cpu_state[15:8])|1) | | | | cpu_state[7:0] | | | enaA | | -----------------------> | | enaA | | | | ------> | | | | cpu_state_write | ------> | | | | | | <----------------- | | | | (history_wdata[127:0]) | | | | (history_rdata_lo[7:0]) (history_wdata[191:128]) | | (history_rdata_hi[7:0]) | cpu_state_write_index | diA[127:0] | historyram0 | | | <----------------------doB[7:0] | | | diA[63:0] | historyram1 | | | | +----------------+ | | | | +------ doB[7:0] ----------+ | | (cpu_state_rdata) | monitorbus | | |---> ---------------> cpu_state | | -------------> | | ----------------> | | | | | | | (cpu_address_next[15:0]) | | | | cpu_address[15:0] | | | | ----------------> | | | | | | | | (cpu_di) | | | | read_data[7:0] | | | (history_write_index[9:0]) | | | (history_read_address_lo[13:0]) (history_write_index[9:0]) | | (history_read_address_hi[12:0]) <--------------- addrA[9:0] | | | addrB[13:0] | | +----------------+ | | | | +----------------+ | | | cpu6502 | | | (cpu_address_next[15:0]) | (monitorcpu) | | | addrA[9:0] | | addrB[12:0] address_next[15:0] | ------------> | <-------------- | ------------> | <------------------- | | | | | | | | (cpu_di) | | | | | | data_i[7:0] | | | | +------------------->+ | | | +----------------+ | | | +--------------------------------------------------------------------+ |
...
+ |
I haven’t dived too deep into historyram0 and historyram1 as yet, though from my initial gleaming of it, historyram was trying to be more ambitious with the volume of data it captured in each trace entry (current x,y,z,a and a lot more).
Hence the reason why the left-side (write) has a data-bus size of 128-bits (can write 16-bytes per clock cycle).
I believe it relates to using the z xx command. I.e., z with a hex-byte parameter. I think the parameter is the index of the trace-entry within the ram to read from, I believe it will then print register-information just as is done with the r command, but making use of the trace-entry values for these register values had at the time of the trace.
Deciphering the 'J' command
...