Create a single page web application that is a disassembler for the Mitsubishi M50740 series microcontrollers from the 1980's. The application should support drag-dropping of binary images, and disassembly projects. A disassembly project will consists of lines of disassembly. Each line will consist of address, hex instruction bytes, address label, mnemonic, and comment. Comment is freely editable. Address label is editable, but needs to be globally unique to the project. The mnemnoic is derived from the instruction bytes. Where absolute or relative addresses are encountered in an instruction, these will be shown with an editable reference label. Reference labels and address label are connected such that editing one will update the other. Double-clicking an address label in an instruction mnemonic will scroll the target address into view. Upon load of binary files, the labels will be automatically generated using a naming scheme such as 'addr_XXXX' where XXXX is the hexadecimal address labelled/referenced. Upon loading binary files, the user will be asked what is the start address. Binary object loads typically cover non-overlapping regions, but if a user indicates a region that overlaps existing disassembly they are warned of such. They may still elect to replace existing work for the overlapping region. Because this processor family has reset and other vectors at the end of the memory map, it is a reasonable guess that binary files cover up to the end of this region. Use that to determine an initial guess for starting address and populate the 'load' dialog with it. For example, a 6144-byte binary file probably covers the addresses 0xe800-0xffff, so prepopulate the start address as e800. Let the user select the processor family. None is an option for adding additional roms to existing disassemblies. For fresh disassemblies, let the default be for the M740. Undo and redo functionality is available. Comments are freely editable and come in two varieties: propagating and non-propagating. Propagating comments are shown on any lines that reference the associated labelled address (if any). For any given line, its non-propagating comment overrides a propagating comment. Propagating comments can only be edited at their source line, and should be shown in a different color (perhaps grey) on lines displaying such to highlight the fact that they originated from a propagated comment. The project file format is JSON. Let the project filename extension be asmp. There will be a provision to also emit an assembly listing which is a simple textual representation of the disassembly work, and suitable, say, for printing. When loading a binary, the tool should start with only define byte definitions in the listing. If the loaded region overlaps a vector, such as reset, those addresses may be queued for disassembly. When all such queueing is completed, each starting address found may be disassembled up to the point of encountering a terminating instruction, such as ret, halt, etc. This effectively consumes the define byte directives and converts them to equivalent disassembly instructions. For each branch instruction encountered, the target address is added to the disassembly queue. Disassembly proceeds until the queue has emptied. It is possible for the user to queue (and thereby start) disassembly at any address. It is possible for the user to revert disassembled instructions to the raw define byte format at any address. Areas of the loaded binary which have not been disassembled should show as .db regions The binary of all non-disassembled regions (such as those containing vectors) should show in the disassembly. Labels for the service routines should be generated appropriately, such as 'nmi', 'reset', 'irq', etc. Also generate appropriate labels for special function registers, such as those for on-chip peripherals. The two processors in this family will be the 740 and the 745, but others should be considered as well. Also generate regions for RAM sections and special function registers based upon processor family. Sections of memory may have a 'type' such as RW (for ram), RO (for rom), and SFR (for peripherals). All sections (ram, rom, SFRs) should be shown in the disassembly. All the bytes of sections should be shown, not just the referenced ones. E.g. the ram and stack section should show all bytes, even if no references have yet been found. They may be found later, or explicitly labeled by the user. Non-contiguous sections of the memory map should be delineated visually, perhaps with a horizontal bar describing section features. Let section headers support collapsing the section from view. The user may add or delete regions of memory. Each byte in the disassembly potentially has a state indicating whether it is an instruction, data, or unexplored. The user can change the type at any address. T will change between byte (8-bits), word (16 bits), dword (32 bits). D will cause disassembly to be queued (and executed recursively as when first loading a rom image). U will mark a selected address or address range as 'unexplored' and remove any disassembly or data definitions and revert to bytes. 'S' can be used to create a string. Strings will be created intelligently. If a single address is selected, then the string definition can auto-proceed over unexplored bytes until an optional null, or $ termination is found. If a range of addresses are selected, string definition will be forced over that region, potentially undefining any existing parts therein. 'A' can be used to create an array. The user is prompted to create the array of a specified type, byte, word, dword, or char. Char type will create a string. The range presented will be from the starting address over a count. The count will be determined by either the selected range, or in the case of only a single selection, from that point up to the end of unexplored bytes. The count will take into consideration the size of the data type selected, and adjusted to be an integral multiple thereof. The work area will consist of two views -- disassembly and raw hex. These will be shown in two tabs, so one or the other will be visible. These views will be approximately synchronized such that whatever is in view in the disassembly tab will have its corresponding hex be scrolled into view when selecting the hex tab. The hex tab will be read-only, and the regions of bytes will be highlighted according to type. A selection in the disassembly tab will be reflected visually when presenting the associated hex tab. Similarly, selecting a region of bytes in the hex tab will select those same region of bytes in the disassembly tab, and scroll those into view. Let the hex display resemble a typical format, e.g.: 0000 43 72 65 61 74 65 20 61 20 73 69 6E 67 6C 65 20 Create a single 0010 70 61 67 65 20 77 65 62 20 61 70 70 6C 69 63 61 page web applica 0020 74 69 6F 6E 20 74 68 61 74 20 69 73 20 61 20 64 tion that is a d 0030 69 73 61 73 73 65 6D 62 6C 65 72 20 66 6F 72 20 isassembler for 0040 74 68 65 20 4D 69 74 73 75 62 69 73 68 69 20 4D the Mitsubishi M 0050 37 34 30 20 73 65 72 69 65 73 20 6D 69 63 72 6F 740 series micro The hex area should include all memory regions, not just the rom region. Discontinuities in the address space should be demarcated with a header as with the disassembly display. A sample binary is provided as "VCR_ROM_M50950-0xe800-0xffff.bin". Let us build the project.