Bit Exact?

[GrantMTG]

Hi,

FWIW, I was using the latest dasm to build the project on Windows (https://github.com/dasm-assembler/dasm/releases) and discovered that the
ldaa #'
was not having the intended effect of loading accumulator A with $20 (ASCII space). On my copy I changed the 11 instances to
ldaa #$20
and the output was then bit identical to my original .OBJ file found on the web. Not sure if there is a flag that enforces the original desired behaviour or not. So, if anyone is having issues this could be why. Could also be a line ends thing between Windows (CRLF) and other OS's that is affecting the assembler?

---

Search for differences

1. EPROM\Yamaha\DX7-V1-8.OBJ: 16,384 bytes
2. ajxs_DX7_v1_80\Yamaha_dx7_rom_v1_8.bin: 16,384 bytes
   Offsets: hexadec.

3A3: 20 0D
523: 20 0D
557: 20 0D
562: 20 0D
3079: 20 0D
3197: 20 0D
3206: 20 0D
38F4: 20 0D
396E: 20 0D
39B5: 20 0D
3EBD: 20 0D

11 difference(s) found.

---

Anyway, good work. I did some hand disassembly of v1.7 and v1.8 but never got nearly as far. I did notice a huge change in basic structure between those two DX7 versions, like you have mentioned between the DX7 and the DX9. Maybe someone got sacked lol. I am eager to try out your new DX9 version!

[ajxs]

Hi Grant, great to hear from you!
This is an interesting issue. Thanks for pointing this out! I did all of the development on Linux, so I didn't pick up on this. I think you might be right that this is caused by the CRLF sequence on Windows.

Dasm uses a single quote for single character literals, like LDAA #'f, so where I put the empty character literal (#') dasm might mistake the trailing CR (ASCII 0xD) character as being part of the character literal, and insert that. Did you resave the file on your Windows system prior to building? Your editor might have automatically converted all the line endings to CRLF. I did some development on a Windows system a few years ago and had some similar things happen to me.

I'm traveling at the moment, and don't have access to a Windows system to check. I'll test this out in Windows when I get home in a week, and might end up filing a bug with Dasm. Maybe I'll even fix it myself.

I might have a look at the v1.7 ROM and see how much changed! When I get back I'll be doing the final testing on a big bug fix with DX9/7 that fixes the portamento/pitch EG rate to more closely match the DX7. I'll also be publishing the annotated DX9 assembler in a week or two.

Thanks so much for your help!

[GrantMTG]

I guess this was self-inflicted by however means I saved the original file. Probably I took the RAW file and saved it from a browser which removed the whitespace at the end of the line. I went back and made sure the trailing space was there before CRLF and it builds fine now. So, more user error or "gotcha" than dasm bug. Some assemblers enforce a trialing/matching quote, such as '0' which is probably better, but it is what it is for now.

The changes from v1.7 to v1.8 were extensive. They did fix a few bugs, but obviously someone was unimpressed with v1.7 enough to change much of the core too. I haven't examined all of it by any means, but definitely a different style. Most of the expansion boards were built on v1.7 and probably having to redo all of the hand-built expansion code to work with v1.8 was too much bother.

Regarding the DX9, it sucks that they soldered so much down on the PCB.

[ajxs]

At your recommendation I took a look at the v1.6 DX7 ROM. I couldn't find v1.7, but I found v1.6(?) here (incorrectly labeled as 'original maskrom'). This is the version described in Yamaha Service News E-318 (the copy I have appears to have originally come from your site, thanks!), labeled IG11464. The version string labels the ROM as v1.6, but subsequent versions seemed to jump back to v1.5? Who knows. Yamaha must have spent a fortune on mask ROMs for the DX7!

You're right that the earlier ROM versions were very, very different! Thanks for pointing this out! Some of the noteworthy differences I found:

• This ROM version uses a totally different method to send MIDI: v1.8 queues up an interrupt when an outgoing MIDI message is enqueued, and the subsequent SCI interrupt handler sends any queued messages. This version just sends any queued messages periodically in the firmware's main loop. It's a bit weird that the DX9 uses the same method as the v1.8 DX7 ROM considering that both synths were designed at the same time. I've read that there are two DX9 ROM versions, but I've only ever seen one.
• The weird 'Pascal-like' string format, with a header byte containing the number of chars in the string (minus 1). The TX7 ROM actually uses Pascal strings, but it uses the correct format. The TX7 came out much later, so I'm not surprised it's different. The string-handling code from the DX9 eventually ended up in the DX100/TX81Z.

Yamaha must have had multiple teams working on the software. I'd love to know more about the design of these synths from Yamaha's side, but I imagine that's lost to history at this point!

[GrantMTG]

_ My guess is that the orphaned 6303 code and this symbol table were in the working memory of whatever development system Yamaha were using, and somehow ended up mixed in with the actual code before being sent off to create the mask ROM. It's anyone's guess how something like this would happen. It's clear that the DX9 binary was written over this data, so maybe it was just what happened to be in the development system's memory before? Maybe they took a snapshot of the whole memory space of their development system after running their final tests?

If you have any ideas, or have any insight to share about what tools Yamaha might have used, please reach out! I'd love to hear any theories you might have. _

I'll bite. It's probably even more simple than that. The output of the assembly build process is a series of .hex records or .s19 records. (Opinion: Until recently the whole idea of using BINs was pretty foreign since you had to move your output files from a computer terminal to a serially connected burner. Hence ASCII based formats) So, you turn on your stand alone EPROM programmer, it bleeps to life and you then send the .S19 or .HEX files over a serial terminal link to it. Various pieces of code are placed at their correct locations. Then you burn it. Cool. Done. Now what happens if you walk away without turning it off and someone else uses it. Unless they specifically do a memory fill then your old code is there and the second person's code is dropped over top of it. So person #2's code works as designed, but in the holes in it's image are your things that didn't get overwritten. I'm sure this is quite foreign to all but those that have used a serially connected programmer, but I bet this is just code from someone who used the EPROM programmer earlier that day. Now whether that has anything to do with the DX9 is hard to say. Here's the first "professional" burner I ran into

https://www.ebay.com/itm/266737842646

I'm sure it was many, many thousands of dollars back in the day. Kontron is a VERY high end company.

[ajxs]

I like your theory. This is probably pretty close to what happened. One of the things I looked at was whether the leftover data matched one of the formats used to serialise binary data, like Intel HEX, or Motorola S records (like you mentioned). From what little I can tell from the Hitachi/Motorola assembler manuals, it seems likely that this is the internal symbol table data. The Motorola M68MASR cross-assembler manual mentions a 10-byte symbol format, for instance. I wonder how this got mixed in with the data for the mask ROM though.

A lot of the Hitachi reference material talks about serialising the data to paper tape prior to creating the mask ROM. I wonder if the Yamaha engineers even had access to an EPROM burner, or whether they'd print the code to paper tape in Intel HEX format, then take it down the road somewhere. I'm sure they had some kind of development system to test their code in house though. I really wish we could learn more about how synths were engineered back then!

By the way, I actually opened a PR to correct the issue with dasm not handling carriage return bytes properly in character literals: dasm-assembler/dasm#148 It doesn't look like the project is being actively maintained at the moment though, unfortunately. So it might be a while before this gets merged.