cc65 is an open-source C compiler for 6502 family CPUs. Most of us ignore the compiler and just use the included macro assembler, ca65, and some of the other tools it comes with.

I find it easiest to use on Linux, but I think there's a version for Windows too.

Okay, I just added the Renesas 740 instruction set to my local build of WFDis, so it's untested. However, since you have a 128kB ROM, that would be too big to disassemble as a single chunk within the address space, so the banking would need to be known.

Looking at the ADEC, it receives 2 port pints from the CPU, and outputs /ROM1 /ROM2 /ROM3. 4 banks of ROM would be 128kB/4 = 32kB each, which is promising. Since the separate A16 is also going into the ROMs, that also might point to the ROMs take the upper half of memory, although the name "A15" would make more sense. However, it's inputting 6 address lines, and the addressing might be a lot more complex.

It does also read /DME, so it might split code reads and data reads to different ROM chips.

If you upload or private message me the ROM file, I can do some initial smoke testing before uploading the new version of WFDis that supports it.

Again, it may not be of much help in hardware troubleshooting, but I'm happy to support more 6502 family revisions for their own sake.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

R.R, in spite of what I said earlier, I confess to being curious about this loop. Would it be feasible to share the Logic Analyzer results with us, or would that be too much information to manage? I know you have a lot on your plate already.

Ideally, for each cycle I'd like to see the following (in regard to the Master CPU), sampled at the rising edge of the 2 Mhz clock on pin 40...
- the SYNC signal
- the 8 bits on the data bus
- the 8 lower address bus (A7 - A0) as they appear on IC4 or on the RAM (IC11).
- (optional) the 8 upper address bus (A15 - A8) as they appear on IC1 or on the RAM (IC11).
- (optional) the R/W signal

Of course, this'll be raw data, and meaningless until the instructions get disassembled. But if the loop is fairly short -- a few dozen cycles, say -- then I'll bet someone would be willing to manually disassemble it. And there might be a clue there, although it's hardly guaranteed.

Even if you or White Flame were to use the disassembler, the LA info may still prove useful in various ways. For example it'll reveal the Program Counter and perhaps the memory banking options that prevail when the loop is running.

J.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

To me, the signals at the IC2 slave CPU look good so far.
Don't know, whether IC2 is in a socket or not.

I agree with Jeff that the LA data from the IC1 master CPU endless loop might provide some more clues,
but interpreting the data would require some work.
//We don't know for sure which of the peripherals show up where in the IC1 address space.

Well, at least we know the addresses for the on-chip peripherals. According to the M50734 datasheet they're mapped into the region $00DA to $00FF -- in other words, in zero page (a choice which offers significant advantages ).

Meanwhile, we want to continue looking for clues that don't involve disassembly. Has anyone had a close look at the other page of the schematic -- pdf pg 122, the page that doesn't include the Master CPU? I'm thinking the fault could be in the scanning of all the keys and switches. Like, one of these switches is what activates the sound. But maybe the Master CPU simply can't "hear" that switch.

Hmm. OK, I'm still wondering if we're concentrating too much on the Master CPU. We wanna consider both pages of the schematic.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

After taking a look at the LA captures, maybe we are going to be a little bit smarter... maybe not... but I still don't trust IC2.
IMHO IC2 pin 21 always LOW and IC2 pin 22 always HIGH is not supposed to be normal.

Did a search for Mitsubishi M50726 and M50926 microcontrollers, but found no clear evidence that they were manufactured on _this_ planet so far.
//Could be as well have been manufactured on planet Mars by evil space aliens, same thing for the YM* chips.

Hmm... we don't have the capacity for delayering and reverse engineering old Yamaha sound chips.

Also, it would be good to have high resolution pictures of what the hardware actually looks like.

Maybe we are just missing a simple (and maybe obvious) little detail.

That joke, where the mechanic, standing besides a completely disassembled car, tells the customer:
"Eventually, I was able to locate the source of the problem. The fuel tank is empty."

Firstly I would like to thank you all for your help and contributions to date. I have already learned a lot more about this DM pcb and it's expected operation than I knew before.
I will take photos today of the DM and DRV pcb's. There are only 3 socketed IC's on the DM board. IC2 HD63B01,IC6 Rom1 and IC8 ROM3.
I will also try to get samples as Dr Jefyll spoke off. If they are pictures I will just stick to address and data in the loop. If I expand it to see everything there would be many pictures because of the smaller operations done while in the loop. I will post some pictures so you can see. I can download as a .csv excel file and edit out the extra samples but it's not as easy to read.
Thanks for the explain Chromatix
I go to work to work on the organ now

Here are pictures of the DM board in two parts, and the DRV board. Having some problems yesterday with the laptop I use for the LA but using alternate today should bring more success. There are a lot of instructions in the loop. Almost like it doesn't know there is a problem. I am unable to access the SYNC signal. The ic is one of those higher density dip packages and I can't get clips on to it.

Does anyone know what causes /DME (pin 2) to become active?

The datasheet describes the bit to enable it (bit 5 of the Port 0 function register at address $F5) but doesn't mention how it works, and the Renesas programming manual (linked earlier in the thread) doesn't really mention it at all. It looks like all the Renesas chips have less than 64k and therefore don't have the /DME pin, which would explain why it's not mentioned in the manual.

I've disassembled ROM1, a first draft at least. (I agree that investigating the hardware is more likely to be fruitful, but I'm curious about how the code works.) The contents from $00000 to $0FFFF are identical to the contents from $10000 to $1FFFF and I was hoping that would mean that I didn't need to bother with /DME, but the code is enabling it and disabling it (via bit 5 of $F5) in various places, and there's some sort of address mapping that I don't yet understand.

$0000 to $1FFF is RAM (and possibly some I/O), the ROM contents are all $FF. $2000 to $202C contains (in ROM) JMP instructions, none of which are referenced anywhere. ($202D to $202F are NOPs.) $2030 to $2057 are the (start of) the ISRs that the interrupt vectors from $FFF4 to $FFFF point to.

Here's where things get strange. $2058 to $236C are wrappers routines that JSR to $8000+3*n, where n is 0 to 24 inclusive (i.e. JSR $8000, JSR $8003, up to JSR $8048). Some, but not all, of these routines disable (yes, disable) /DME (by clearing bit 5 of $F5) before calling $8000+3*n, then restoring $F5 after the JSR. All of the routines do write to (and restore) both $1C03 and $01, so possibly one or both is an I/O location; I'd think that the former is more likely to be I/O than the latter.

This would suggest that there are a series of JMP instructions from $8000 to $804A, but that is not the case. There is a routine from $7FE9 to $8015, a routine from $8016 to $8020, a routine from $8021 to $802B, and a routine from $802C to $804A. In fact, there isn't a single JMP instruction (or even a $4C byte) in any of those routines.

Those unreferenced JMPs from $2000 to $202C would seem like a strong candidate for what's somehow being mapped to $8000 to $804A; the trouble is there aren't enough JMPs, i.e. the former area is smaller than the latter. So maybe it's accessing ROM3 (as a post earlier in the thread would imply) or ROM2? I don't have the contents of ROM3 or ROM2, so I can't say.

Also, it doesn't appear that $8000 to $804A is being mapped to RAM somehow, as I haven't found anything that initializes (i.e. writes to) $8000 to $804A.

Back on the topic of /DME, the code appears to set the P0_5 to be an output, driven high, when /DME is disabled. It doesn't make sense to me that merely enabling /DME would cause it to go active (i.e. low); why have a special function for what could be accomplished with an ordinary GPIO? Plus, the block diagram in the datasheet suggests that the /DME signal is based on instruction decoding. If anyone can shed any light on /DME, I'm all ears. (Don't worry, there's still plenty of things I can look at without understanding /DME.)

dclxvi, thanks for jumping into the thread (and for trying to solve this riddle).

From the M50734SP datasheet at the start of this thread:

PDF page 2: the block diagram says that /DME is generated by the instruction decoder.

PDF page 5: When the /DME signal is "L", an additional memory space of 64k bytes can be obtained. However the space can be used only for data memory.
PDF page 5: from the memory map picture, /DME seems to be "H" by default, selecting the first 64kB of memory space.

PDF page 25: $00F5, Port P0 function register, Bit 5: P05/DME selection Bit, 0=P05, 1=/DME, cleared by /RES.
PDF page 24: $00F6, Port P0 data register
PDF page 24: $00F7, Port P0 direction register: 0=input, 1=output, cleared by /RES.

PDF page 32: When the Port P0 function register is set/reset, CLB, SEB and STA instructions must be used.

;---

Found the datasheet again in a bigger PDF at Bitsavers:
Mitsubishi single chip 8 Bit microcontrollers, 1989, starting at PDF page 667.

Unfortunately, /DME isn't explained in any of the datasheets.
/DME also isn't explained in the 740 family software manual, so IMHO it has to be a M50734 hardware specific thing.

;...

I'm starting to assume that /DME is sort of a "simplified 6509 bank switching trick":
maybe /DME _always_ goes LOW when data is read/written during specific addressing modes.

If this is true, it would make sense if an ISR:
0) pushes register $F5 on stack, //for indicating which 64kB bank of data memory was in use
1) disables /DME in register $F5, //for selecting the first 64kB bank of data memory
2) does some job,
3) and then pulls/restores register $F5 from stack. //for selecting the right 64kB bank of data memory again.
//assuming that Port0 Bit 5 is configurated as output and "HIGH" if /DME is disabled in register $F5.

We don't know what's in the IC13 address decoder (maybe it's another Toshiba TC17G gate array),
but P1 and P2 seem to be used by the bank switching mechanism (maybe indicating four 64kB banks in total).
The address decoder selects:

IC6 (128kB ROM, labeled "Main") most likely contains code.
IC7 (128kB ROM, labeled "Pattern") might contain data (might contain code, too). It's present in the PCB.
IC8 (32kB ROM, labeled "ROM3 Bank"), might contain code\data. I think it could show up at $8000. It's present in the PCB.
IC11 (32kB RAM), I think it won't show up at $8000.

IC3 (YM2154, RYP4 Rythm Generator, 128 Bytes).
IC4 (MI-1, 256 Bytes max.) contains sort of a SPI interface and does the handshake with the slave CPU.

;---

Considering the MRE board, sort of a 128kB cartridge could be plugged into CN4,
but it's tied per SPI or such to Port3 of the M50734.
That cartridge certainly won't show up at $8000.

//It's interesting to see pins labeled R/W and /RDY at the CN4 connector.

RR, thanks for posting the pictures.

The DM PCB is high quality PCB material indeed, so we could assume to have no hairline cracks on this PCB.
Not the cheapest connectors were used, so I think the problem can't be a connector that went bad, either.

IC2 (slave CPU) and IC8 (ROM3 Bank) sockets don't look 'high quality' like the socket for IC6 (ROM Main),
but IMHO that's nothing to be worried about now.

Sorry to say this, but I see nothing obvious in the pictures that could be the source of a problem.

Considering the width of the signal traces and the diameter of the vias on the DM PCB,
thou shalt not try to solder any components out of the DM board until you have adequate tools and until you know what you are doing.
//Only replace electrolytic capacitors in the power supply on a DM board that's fully functional, that is.

Hmm... would be good if we would be able to plug the DM board into another HS-5, just to be 100% sure that the problem is located on the DM board indeed.

Although it's just a theory (so far), that does make a lot of sense!

For those unfamiliar with the 6509, its bank switching for data engages only on the last cycle of an (ind),y instruction... which is the cycle that does the actual data access. Then it returns to normal on the very next cycle, and it's business as usual.

So, timing-wise, 6509 bank-address outputs behave just like real address lines. (For example, on an ordinary 6502 doing an ordinary LDA or STA, it's only during the last cycle that A15 - A0 output the data address.) This is very significant. It means the banking scheme can be organized to deal with 64K chunks, and the extended space that's created is linear, in the sense that "A16" has the same relation to A15 as A15 has to A14, and so on. Software, too, sees it as linear, which means address arithmetic is still feasible (ie, only slightly clunky) even beyond 64K.

OK, I'm going slightly OT. But 64K chunks form the basis for 65816 addressing, KK Computer addressing and 6509 addressing (although, tragically, the 6509 is flawed by having a pair of I/O registers appear in $0001/$0000 of every bank. It's still a linear space, but it's peppered with addresses that aren't memory, so WTH ???).

KK and the '816 output 16+8= 24 address bits. The 6509 outputs 16+4= 20. The M50734 outputs 16+1= 17. And it seems /DME is the +1 bit.

Edit:
To clarify "engages only on the last cycle of an (ind),y instruction..." -- with 6509, it is lda (ind),y and sta (ind),y which are affected. Other instructions which use (ind),y mode are not affected.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Jeff, thanks for clarifying the 6509 bank switching.

Assumed pin configuration of the address decoder IC13 (XB828A0):

'S' supply, 'I' input, 'O' output.

;...

DVI and DVO seem to belong to a :16 divider, generating the 125kHz clock out of 2MHz.

A15..A10 are inputs (fed by the master CPU). //6 inputs.
A16 is an output, selecting between the lower and upper 64kB half of a 128kB ROM.

// Hmm... IC13 input pin 4 (/PB) is connected to IC3 pin 37 /CTO.
// From the list, IC3 pin 37 is an output for "LED Control".
// The signal is labeled 'Bank select' in the HS-5 schematic.
// Maybe they needed another bank select signal, but there were not enough pins available at the IC1 master CPU.

So in theory, we have inputs which could be (or could be not) bank select signals:
/DME, P1, P2, /PB. //4 inputs.

Chip select outputs would be:
/ROM1, /ROM2, /ROM3, /RAM, /MI, /RYP. //6 outputs

;...

OK, that's 11 used inputs and 8 used outputs so far.
Pin 13 appears to be an output, so no ATF22V10 or GAL22V10.

An option would be building/wiring an adaptor from (for instance) DIP24 wide precision socket (EPROM pinout) to DIP24 narrow precision socket (XB828A0 pinout),
to buy a functional XB828A0, maybe at ebay, (or to rip it out of another HS-5 organ), //trying to solder it out of the DM PCB most likely would damage the DM PCB, don't do that.
then to plug the contraption into an EPROM programmer for reading it like an EPROM,
what would give us a binary file containing a list\table which input Bit pattern gives which output Bit pattern,
and from that in theory it might be possible to try extracting the logic equations from IC13.

Edit:
Dang: no XB828A0 at ebay.
So another option would be passively scanning/snooping the inputs\outputs of IC13 with a logic analyzer.