Did the ROM file get posted somewhere?

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

Please can someone tell me the meaning of "$2058 to $236C are wrappers routines that JSR to $8000+3*n". I have been trying to get pictures from the logic analyser but to see all the code being executed there is very little on the screen so what I have done is to start going through the code and putting it into an excel spreadsheet. Here is part 1 from the boot up start. haven't detailed the read cycles only write cycles. If there are particular sections any one would like more detail off then I can add a bit map. Your expertise in decoding is amazing guys. Thanks

Update: The $8000 mapping mystery is solved. ROM3 contains JMP instructions from $8000 to $804A. So those routines from $2058 are $236C are calling ROM3 routines. In effect $8000+3*n are entry points in ROM3 which are called from ROM1.

In fact, this goes the other way as well. The JMP instructions in ROM1 from $2000 to $202C, which aren't referenced by ROM1, are instead referenced by ROM3. Thus $2000+3*n are entry points in ROM1 which are called from ROM3.

The precise behavior of /DME remains a mystery, however. (The theory earlier in the thread certainly sounds plausible, though.) There is at least one routine (and it does enable /DME) in ROM1 which appears to treat (some) $2xxx address as data, even though the ROM contents at those addresses is code. Furthermore, according to the schematic, the RAM is 256K bit (i.e. 32k x 8-bit), and $0000 to $1FFF (the section of memory that is (mostly likely) RAM) is only 8K (bytes). So it's possible /DME is used to access ROM2 or RAM or both, but that's just blind speculation at this point.

Spent some more thoughts on this.

The IC1 main CPU comes out of a RESET with /DME=1, P1=1, P2=1, probably /PB=1.

We have a MIDI port that's connected to the UART in the IC1 main CPU. //Electrically, that's different from RS232, but a MAX232 could fix that.

We have a cartridge slot tied to IC1 by something like SPI,
so we could assume that there is some "mechanism" for recognizing a plugged_in cartridge, for transferring code from it into RAM, and maybe for executing the code.

Hey, in theory one could try to write sort of a monitor program running as an ISR in the background,
just to see what's going on inside that HS-5...

Because I haven't been able to find any hardware faults to date I have continued with my LA looking at the loops the processor is is running. I now have 4 blocks of code. The LA pictures are not worth posting because there would be so many so I have put them into a spreadsheet starting at boot up. Today I plan to return to ADEC the main decoder chip to find which addresses go with the chip selects that are active. Attached are the code extracts. I have also been monitoring the rd/wr lines and after the boot file there is not a single wr instruction. It seems a little odd that it's not writing to any other ic's. Still it's only 550uS into the program.

Dumps of ROM1 and ROM3 were sent to me privately. I don't mind sharing information with the rest of the group, and I realize that the manual with schematics is out there, but I think it's wise to be cautious about posting ROM dumps or disassemblies publicly.

In cases where the cat is already out the bag (Applesoft BASIC comes to mind here), it may not be such a big deal.

Code executed between $2000 and $7FFF comes from ROM1. Code exectued from $8000 to $FFFF comes from either ROM1 or ROM3 depending on which is currently selected. This is how it goes from one to the other.

At $91CA in ROM3 is routine that gets called from ROM1. Before actually getting to $91CA, ROM3 has to be selected. So what ROM1 does is a JSR $2058. The $2058 routine saves which ROM is currently selected, then selects ROM3, then does a JSR $8000, then restores the previous selected ROM. At $8000 in ROM3 is a JMP $91CA. So the $2058 routine "wraps" (as the term is commonly used) the functionality of selecting and restoring the correct ROM around the JSR $8000

The routine at $2076 does the same thing, except it's a JSR $8003 instead of $8000. This pattern continues at $2094 with a JSR $8006.

At $2148, the pattern changes slightly, as it also saves the Port 0 (data) register and the Port 0 function register, and disable /DME before the JSR (to $8018). Subsequent routines up to the routine starting at $234F follow one of these two patterns.

Starting at $236D up to the routine starting at $25FF are the routines which handle the other direction, i.e. selecting ROM1 instead of ROM3. For example, ROM3 will do a JSR $804E. At $804E is a JMP $2003, and at $2003 is a JMP $239C. At $239C, it's the same pattern as before, except it select ROM1 instead of ROM3. So $239C is one of the routines that "wraps" the functionality of selecting ROM1 around a JSR $A188.

The routine at $5F3C loops until bit 4 of the value at address $1800 goes low. At this point I don't know what $1800 is used for, but the /INT1 interrupt handler writes to it. So maybe look at the /INT1 pin (pin 60), and see if the signal there looks weird. However, based on that particular trace it looks like it's getting stuck before interrupts are enabled, so who knows.

/DME update: based on what ROM1 and ROM3 are doing, it's looking very much like the theory suggested earlier is correct, i.e. that (when enabled) /DME is active (i.e.) low only on the last cycle of instructions with (zp),Y addressing.

I believe that /DME does not apply to (zp,X) addressing, based on my analysis of ROM1 and ROM3 so far, but my understanding of the code is incomplete at this stage.

/DME is used to access ROM2 and the upper 24K of RAM ($0000 to $1FFF is only 8k of the 32K * 8 bit RAM, and I think RAM actually ends at $1BFF and $1C00 to $1FFF is I/O). Port 0 bit 3 (pin 63) selects RAM when 1, and selects ROM2 when 0. Port 0 bit 2 is A16 of the 128k * 8 bit ROM2. Note that both of those signals run to the address decoder.

I do like the combination of private sharing of data and public sharing of analysis!

Today I took some samples from the ADEC ic. At the top left is shown the signals I'm looking at and bottom left the outputs. I put A16 as an input by mistake. A16 is clearly related to /DME, just inverted. Present also are /ROM, /RAM, DVO, MI. I don't think this is just an address decoder. The 2nd picture shows activity on the P2 line.
The signals on ADECsignals1-1.jpg just repeat in the loop. The was no activity on /ROM2 or /ROM3. Please feel free with suggestions on the next step.
In the boot file it is clear that there are lots of WR's but from the on I havn't found a single other WR. If I check the ADEC picture you can clearly see that /RAM is frequently selected but it's only a RD cycle.

If that's the endless loop, then it feels like the master CPU IC1 reads a Byte from the IC4 MI-1 at $1800..$1BFF, and it doesn't like the result.

To me, this indicates that either something could be wrong with the SPI communication to the other boards,
or that something could be wrong with the communication with the IC2 slave CPU (HD63B01).


In the HS-5 schematics, IC2 pin 21 is labeled /IS, and IC2 pin 22 is labeled /OS.
In the HD63B01 manual, PDF page 565 (546), there is a description for how /IS and /OS are supposed to work for the HD63B01Y0.
//To me, the manual looks like only the HD63B01Y0 has that /IS and /OS feature. It seems to be missing for the HD63B01V1 and HD63B01X0.

If the master CPU does a read/write to the slave CPU, /IS is supposed to go low.
The slave CPU is supposed to acknowledge the falling edge at /IS after some time by generating a spike at /OS.
After power on, the master CPU probably wants to initialize the slave CPU at some point, so check for spikes at /OS.


IC4 MI-1 uses pin 31..37 for talking with microcontrollers on the boards: UK, LK, PK20L. Try to see, if there is activity.
Quote from the organ forum:
"Basically, the Gate array chip (TC17G005AN-0023, XB809A00) provides the Serial Clock and makes a data request from each of the keyboards.
When a keyboard sees its data request input signal go low, it gets the okay to send note data via the KD pin to the Gate array chip"

IC4 MI1-1 uses pin 38..41 for talking with the microcontrollers on the DRV board. Try to see, if there is activity.

Hope, this helps.

I should clarify. With 6509, it is only lda (ind),y and sta (ind),y which are affected. 6509 does not bank-switch for other instructions which use (ind),y address mode (although perhaps the M50734 does -- it's unknown).

J.

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

In reply to ttlworks:

IC2 pin 21 marked /IS is LO and there is no activity.
IC2 pin 22 marked /OS is HI and there is no activity.

IC4 MI-1 pins 31 to 37 all are non active and are HI excepting pin 34 which is LO but non active.
IC4 MI-1 pins 38 to 41 all non active.

To me, it still feels like something is wrong with the slave CPU.
It doesn't seem to acknowledge communication attempts by the master CPU.

So let's focus on the slave CPU IC2.
We already have checked that the 8MHz crystal is oscillating, that there is a RESET, and that /IS goes active.

The slave CPU is supposed to do some writes to the external RAM plus peripherals, at least at power up,
check if there is activity at pin 62 (/WR) and pin 63 (/RD), especially after power up.

The problem with the slave CPU is, that the code is on_chip, 4kB of ROM. (Probably mask ROM "programmed" my the manufacturer.)
HD63701 was an EPROM version of the HD6301, EPROM programming and verifying is described on page 608 (589) of the manual,
but it's hard to tell whether reading out the HD6301 ROM this way might be possible or not.

Anyhow, the socket of the slave CPU doesn't look like high quality,
and I think that it is _not_ designed to survive more than 5 plugging/unplugging cycles of the chip.

Edit: IC14 (YM2414) pin 24: check if the 3.2MHz clock is there.

In reply to ttlworks: RD/WR pins 62 and 63 are active at boot and onwards. IC14 pin 24 is active 3.2Mhz.

Interesting yesterday looking at IC28 the 40H138 3-8 line decoder used after the slave processor. The first trace shows the outputs from the chip select lines /Y1, 2, 5, 6. Looks pretty much as you might expect. The second trace, in which nothing was changed except for being turned off and then back on for a new trace, shows a completely different pattern where three of the outputs are low at the same time. I have now seen this a couple of times and wonder how this is possible.