I've been mainly working with the 68000 inverse assembler so far, and I wanted to post a few comments here to help anyone else who might try and do the same.
First of all, it's worth noting that the 68000, 68008, and 68010 inverse assemblers are almost identical, which makes sense, since the processors themselves share almost the same instruction set and physical interface. The disassembled source for the inverse assemblers in this thread is very useful, but we actually have the original sourcecode for the 68010 inverse assembler in the 10391B Inverse Assembler Development Package here:
https://www.keysight.com/us/en/lib/software-detail/instrument-firmware-software/10391b-inverse-assembler-development-package-version-0200-sw575.htmlIn the "Examples" folder is I68010.S, which on comparison with the disassembled 68010 inverse assembler in the INVASM_SRC.zip file supplied in this thread, I've verified has identical code, apart from a minor difference in the entry point around task setup, which may even be injected at compilation time by ASM.EXE, I haven't checked. The actual steps around disassembly are the same though, and critically this original source file has all the comments and proper names intact, making it much more readable.
From the comments in the original 68010 inverse assembler source, and the great resources in this thread, it's fairly easy to work out the pin mappings for the pod connections. From the header comments of the disassembler, we have this:
* THE LOGIC ANALYZER CAPTURES 24 ADDRESS LINES, 16 DATA LINES AND
* 8 STATUS LINES ON THE RISING EDGE OF LAS.
*
* THE 8 STATUS LINES FOR THIS INVERSE ASSEMBLER ARE:
*
* BIT 0 --- R/LW (CPU PIN 9)
* BIT 1 --- LLDS (CPU PIN 8)
* BIT 2 --- LUDS (CPU PIN 7)
* BIT 3 --- LVMA (CPU PIN 19)
* BIT 4 --- FC0 (CPU PIN 28)
* BIT 5 --- FC1 (CPU PIN 27)
* BIT 6 --- FC2 (CPU PIN 26)
* BIT 7 --- LBGACK (CPU PIN 12)Here's what I did, which follows the expectations of the config files with the invasm_v3.zip archive here:
Pod A1:
15-0 - D15-D0
CLK - AS
Pod A2:
15-1 - A15-A1
0 - UDS
Pod A4:
15-8 - A23-A16
7 - BGACK
6-4 - FC2-FC0
3 - VMA
2 - UDS
1 - LDS
0 - R/W
Here's what it looks like on the unit:
Using UDS as A0 may seem counter-intuitive, but there's no external A0 line on the 68000, it's the UDS and LDS strobes that indicate which half of the 16-bit data bus is being read/written to perform 8-bit operations. Now LDS being asserted and UDS not asserted is how you'd normally tell when you were doing an 8-bit operation on an odd address, but UDS and LDS are active low, while the address lines use a high logic level when asserted, so we use UDS being high, indicating there
is not valid data on the "upper" (even address) data lines, to work out that it must be an 8-bit odd address operation.
While trying to use the 68010_P inverse assembler on my 1670G though, I ran into problems right away - none of the instructions would actually disassemble. It became clear why on some examination, the UDS and LDS lines were both logic high when sampled. As per the comments in the original source file, the system wants you to connect your clock signal to AS, the address strobe, and set it to trigger on the rising edge. This line is active low, so basically when a bus operation (IE, read or write generally) is being completed, we latch all the lines. That's all well and good, except as per the 68000 User's manual, when performing either a read or a write, at the falling edge of the main clock entering S7 "the processor negates AS, UDS, or LDS". Negates in this context meaning no longer asserts, which being active low signals mean these strobes all go high. Since we sample at the edge of AS going high, it makes perfect sense that UDS and LDS would also have been negated at this point. We need to know what UDS and LDS were set to prior to this occurring. The solution to this problem is already given above as for the Z80 - we need to use slave clock settings to sample these lines. Doing this is easy - we connect the clock source for the CPU to another pod clock (I used clock M on pod 4), and set it up as a slave clock source to trigger on the
rising edge of the clock:
We then assign this slave clock to pods A4 and A2, so that UDS/LDS in both the "STAT" field and the A0 position of the address are sampled using the slave clock. And since the slave clock is triggered on the rising edge of the CPU clock signal, while AS being negated (going high) occurs on the falling edge of the CPU clock, we'll now latch everything but the data lines a half-clock cycle prior to AS being negated. Since the data lines don't get negated by the CPU on a write until another half clock cycle, and for reads until the devices have a chance to see and respond to AS being negated, we're safe to sample them with the main clock. With this configuration, the inverse assembler works as expected. When interpreting results though, it's important to have a solid idea of how 68000 prefetch works, since the logic analyzer will show instruction words being pulled in while the prior instruction is still executing, meaning you may see things logically out of order from a code perspective, but in the correct order for how the bus operations actually occur in hardware. The result is something like this:
Home
Help
Search
Login
Register
Recent Posts
