finally back in the workshop. Got my big beast of an analyser working, it is a Biomation CLAS2000 with an embedded mac computer in the base. I have just managed to capture the data lines (and multiplexed Bank address) from my 65c816 project board. Very happy with that
Question is how many lines from the processor do I need to capture in order to then take the data and write a program that converts the data to 65c816 opcodes etc?
Hmm, absolute minimum might be the data lines, a clock, and VPA. RDY if you use it (and ABORT, and the interrupt lines) But at least a few low-order address bits is going to help. How complex a program do you want that to be? If it's very nearly a 65816 emulator, you need fewer lines!
I think the first step is to capture all 16 address lines, VPA, VDA, nRESEt (don't use the RDY line), both nIRQ and nNMI. The analyser is sophisticated enough to de multiplex the data bus. Still learning to use it. Only problem with it is the heat generated from it!
At present I am using the PHI2 clock to capture the data, but also have the option of internally clocking the analyser to capture at 200Mhz. Hopefully this is fast enough as my board runs at 819.2Khz
Ah, you've got lots of channels.
VP might be handy if you have any trouble with interrupts.
M/X and E will help with on-the-fly disassembly, if your code does much mode-changing.
You'll surely want RnW too.
Cheers
Ed
VP might be handy if you have any trouble with interrupts.
Did you mean VPB perchance? That signal is negated during cycles 7 and 8 of an interrupt sequence.
Quote:
M/X and E will help with on-the-fly disassembly, if your code does much mode-changing.
MX is a little cumbersome to use, in that the meaning of the signal depends on the clock phase. You'd have to demultiplex and latch it to be able to correctly identify the register widths for the duration of an instruction. In my POC unit's monitor, I ended up maintaining state information in RAM about the m and x status register bits during disassembly so immediate mode instructions (including BIT #)would correctly disassemble.
E, on the other hand, will always be low when the '816 is running in native mode, so its use should be straightforward.
AFAIK, WDC is the only bunch who put a "B" on the end of signal names. I found it confusing for the first few years, because it looked like it stood for "bit," as in IRQB being "interrupt-request bit," like saying you drive a Chevy car so someone doesn't make the mistake of thinking you drove a Chevy toaster. Rather unnecessary. Then I realized it must be short for "bar," since they may have had trouble with that in their early literature that was apparently done on typewriters or daisywheel printers. Maybe using the underscore character on the line above didn't come out at the right height or something. I had to ask our computer-science daughter-in-law how to put the overbar on things in my website. I'm glad html has a way to do it; but AFAIK, there's no way to do it on the forum. There are several other ways these things get written, and they're all confusing.
/IRQ seems to be least confusing to me, and is visually indicative of a line going over the text. I'm not that much of a hardware guy, but I was unaware that leading-slash wasn't actually standard.
/IRQ seems to be least confusing to me, and is visually indicative of a line going over the text. I'm not that much of a hardware guy, but I was unaware that leading-slash wasn't actually standard.
I've seen active-low signals notated as *IRQ or IRQ\. I prefer /IRQ in cases where I can't overstrike characters. In the data sheet for their MicroVGA module, SECONS uses a trailing octothorpe to indicate a low-true signal, e.g., RESET#. Whatever floats your boat!
