• Please review our updated Terms and Rules here

HardMPU <working title>, anyone here an EE?

I noticed a possible error in the disassembly. I assume the 6801 is in mode 0 (hard to actually know without knowing what the HD61J221F does with P20/21/22 at reset, and like I said I can't find any information about that chip). In that case the ROM code would start at address 0xf800, not 0xf000.


(edit) it looks like the 61j22 is an ASIC based on a custom gate array similar to this one: http://pdf1.alldatasheet.com/datasheet-pdf/view/122366/HITACHI/HG62E08.html or http://www.datasheetlib.com/datasheet/184051/hg61h_hitachi-semiconductor.html I think it would be interesting to figure out what that chip exactly does as it would be relevant as to how the 1-MHz MCU deals with the 8MHz bus.
 
Last edited:
JDallas said:
AtMega Only in SMT Package:
Got the ATMega128 Datasheet. I'll assume it might be excluded since its only comes in to 64pin surface mount packages; tqfp-64, qfn-64. Doesn't meet the hobbyist criteria of thru-hole and kit. Haven't got the AVR data sheets yet... I'll consider PIC to be the last choice. ;)
Click to expand...
The AVR based schematic uses an Atmega 1284, which comes in a 40-pin DIP package. So no worries there :)

JDallas said:
A note on Timing:
The protocol communications that fully describe concurrent note or notes on one or more instruments that begin in unison on the next approaching instance of the sheet music time, makes this a "Human-Time" application. The down time between events is the rate at which the music starts the next note. The Roland MPU-401 is just a protocol converter... it doesn't have to do any of the note sound shaping. A 1Mhz processor as perfectly capable to manage that in the original Roland MPU-401.
Click to expand...
I plan on taking advantage of the fact that a modern MCU will have plenty of free time to implement new features. For example: adding a delay between MIDI SysEx messages to compensate for bugs in certain attached MIDI devices (like what is already implemented in SoftMPU).

JDallas said:
Early Comments on the Design:================================

ISA Bus Timing:
The ISA bus interface is therefore the only real speed challenge if you want to take advantage of the newer micros to remove a lot of now-unnecessary TTL logic. Note that the ISA Bus does have a wait-type signal to extend I/O cycles, but I don't find it on your schematic (5th-ATMega) so I assume Roland MPU-401 didn't need it with their 3 register '374 approach.
Click to expand...
I thought about requesting more wait states on the bus, but that might end up slowing down an already slow host machine. I'd rather deal with some extra glue logic.

JDallas said:
Remove the register status 74'74 flip-flop and 74'08 And gates:
The flip-flops that create signals to tell the micro which latch registers have been loaded can likely be removed. The signals would instead use the address decoder to create an interrupt for each register. It might be edge-detect or level-triggered interrupts. No need to keep those 74'74 flip-flops and 74'08 And gates.
Click to expand...
Two of the flip-flops also form the status port (base address + 1, read). The MCU *should* be able to keep track of the status and output these signals. However, if the MCU doesn't flip one of the bits before the host machine reads the status port again, it could get false status information. I see it as being likely that software on the host machine could read the status port immediately after a data port read, for example.

JDallas said:
I/O Write to Port - 74'374s can be reduced:
I don't think all the '374s will be needed with today's micros. If one holds an input command and the other holds input data, they can share the same 74'374 as long as the processor can read it before its written again. The address decoder need only separate the bus address for write data and write command, and generate an interrupt to the micro separately for those. The interrupt would grab the data the same way for both, but the type of interrupt would tell it where to put the data or command internally.
Click to expand...
This definitely makes sense. Even if the flip-flops are kept for the status port, this should result in the reduction of at least one chip.

JDallas said:
I/O Read from Port - 74'374s might be eliminated:
All of these micros have more I/O pins than you need. Instead of using a 74'374 to hold a byte for the host to pickup, it could present the data on one of the micros 8 bit ports and let the address decode enable a 8bit tri-state driver during the bus I/O read cycle. That assures the data timing meets the bus timing. Likewise a interrupt from that address decode would tell the micro that the value has been read and that the next value can be loaded once the driver to the bus is again disabled at the end of the I/O read cycle.
Click to expand...
Makes sense. But wouldn't this just result in replacing a '374 with a '244?

JDallas said:
I need to find out from the MIDI protocol is a read is done as a write command followed by a read data. That would seem logical as it would give a 1Mhz vintage micro plenty of time to have the data ready before the subsequent I/O read actually takes place. A series of reads could be supported by an interrupt service routine getting the interrupt when the prior I/O Read is active, (if more time is needed) then getting the next byte, and waiting until the data bus driver is disabled before writing the next byte onto the micro's 8bit port that goes to that some data bus driver. If it takes less time to get the next byte, just use the release of the 8bit tristate driver to signal the interrupt to place the next byte of data on the micro's 8bit port before the next I/O read occurs on the ISA bus.
Click to expand...
The MPU401 signals the host machine that data is ready for reading via status port bit 7, which also triggers an interrupt on whatever IRQ the user chose with the IRQ jumper.

JDallas said:
Address Decoder Mayhem: The Two 74'138s can probably be improved:
The use of two '138s is annoying. I can see they're using its enable gates instead of combinational logic but it looks like a lot of unused output pins the really be needed. I suspect that can be improved. It might even be an application for the variable reduction mux trick.
Click to expand...
Agreed, seems like this can be done a better way. I'll see what I can come up with.

JDallas said:
I'll read my PDF Roland Tech Manual to see if it gives me sufficient MPU401 addressing information. If you have a good URL for a Roland MPU-401 User's Manual, post it.

Previously:
Basically the MPU-401 is just a two-sided protocol converter? Your ISA lets you interface your computer to it and it does some enhanced protocol conversion and task control but does no music synthesis, just talks with them downstream.

It looks like all the work will be in your coding and that can be refined to address all speed issues with today's faster microcontrollers. Therefore I think its quite valid to do some TTL rippin'.

Do you plan to write your code in assembly language or in C? You might want to do a tasker structure so you can manage several tasks concurrently and allow priority for some functions.
Click to expand...
I plan on using C code for ease of porting/borrowing code from the SoftMPU project.

Please don't take any of the above as dismissive or argumentative. I'm just making sure I understand all the suggestions you made. Thank you!
 
JDallas said:
I/O Write to Port - 74'374s can be reduced:
I don't think all the '374s will be needed with today's micros. If one holds an input command and the other holds input data, they can share the same 74'374 as long as the processor can read it before its written again. The address decoder need only separate the bus address for write data and write command, and generate an interrupt to the micro separately for those. The interrupt would grab the data the same way for both, but the type of interrupt would tell it where to put the data or command internally.
Click to expand...

So you are putting the onus on an interrupt routine to decode & service the 374's in time to clear for the next read/write (and in a specific sequence)?
That is going to be a single point of failure for real-time throughput on the ISA bus, since it'll necessarily have to be a blocking procedure.
It'll also add obfuscation to the code in the interrupt, and add "error-proneness" to the coding effort -- not really worth the 1 or 2 chip parts count reduction IMHO...

gwk
 
pearce_jj said:
I already have a MIF-IPC clone board design done, in case that is of use for this project?

https://www.lo-tech.co.uk/mif-ipc-b/

There is a slight error in the first run of PCBs but I have more (corrected) on order.
Click to expand...
I had designed the first schematic based on the MIF-IPC-A schematic. But I don't think the microcontroller in this project would be able to keep up with the bus using only that interface. But definitely let me know if you sell some of these boards - bare PCB, kit, whatever - as I am trying to find a real MPU-401 to compare against when working on this project.

griffk said:
So you are putting the onus on an interrupt routine to decode & service the 374's in time to clear for the next read/write (and in a specific sequence)?
That is going to be a single point of failure for real-time throughput on the ISA bus, since it'll necessarily have to be a blocking procedure.
It'll also add obfuscation to the code in the interrupt, and add "error-proneness" to the coding effort -- not really worth the 1 or 2 chip parts count reduction IMHO...
Click to expand...
That too. I should have pointed out, I'm not looking for the minimum chip count possible. An extra chip or two is worthwhile if it keeps the firmware simpler and/or more reliable. But eliminating any unnecessary logic is also a good thing.
 
Bear in mind the MIF-IPC is an 8-bit card, therefore we're working with a 4.77MHz clock here. You can assert the wait line if you need to add cycles before applying the response.
 
pearce_jj said:
Bear in mind the MIF-IPC is an 8-bit card, therefore we're working with a 4.77MHz clock here. You can assert the wait line if you need to add cycles before applying the response.
Click to expand...
I could be wrong, but I think the bus runs at the same speed regardless of if 8-bit or 16-bit transfers are occurring. But it looks like, by default, 8 bit transfers include a default of 4 wait states. So on a machine that runs the bus at 8MHz (could be higher or lower on different machines), the MCU running at 20MHz would have to service the bus in 10 instructions or less. It likely takes that much just to jump into the interrupt service routine, therefore I don't see it happening without glue logic to deal with bus reads and writes.
 
Yes, 8-bit slots have a cycle time roughly equivalent to 4.77MHz regardless of CPU clock speed (about 800ns overall transaction time - at least four clocks at 4.77MHz). 8-bit adapters can assert B8 (ZWS) in PC/AT class hardware to eliminate most of the wait-states. But you're adapter doesn't have to do anything in any particular time; there are no checks-and-balances involved in ISA. It can keep the wait line held for eternity, obviously the system is hung in that case though.
 
JDallas said:
Is that for every byte read or for the beginning of a block read?
Click to expand...
For every read.

pearce_jj said:
Yes, 8-bit slots have a cycle time roughly equivalent to 4.77MHz regardless of CPU clock speed (about 800ns overall transaction time - at least four clocks at 4.77MHz). 8-bit adapters can assert B8 (ZWS) in PC/AT class hardware to eliminate most of the wait-states. But you're adapter doesn't have to do anything in any particular time; there are no checks-and-balances involved in ISA. It can keep the wait line held for eternity, obviously the system is hung in that case though.
Click to expand...
Interesting. So basically it is possible to interface the MCU directly (through buffers) to the bus, but it has the potential to slow things down quite a lot on the host machine. I was for some reason under the impression there was a limit to how long you could assert the line to make the bus wait for you.
 
Last edited:
Chuck(G) said:
Is the issue the lack or presence of a MCU with a PSP? If so, the PIC16F77 might be a nice 5V alternative as it does have a PSP.
Click to expand...
A PSP would be a great way to solve this, but the MCU needs to be able to respond to two addresses, the base address and base+1, and do different things with the data going in or out based on which port is being addressed. Would a PSP be able to do that?
 
JDallas said:
No

The AtMega128(4) can do the same thing faster so the host sees a quicker response via the IRQ than with the original system. The latches in that design didn't add speed, they were needed because microcontrollers seldom allow a byte to be latched in directly to their I/O pins.

In short, your system is faster both by clock rate, and because of the use on interrupts to shortcut the process and avoid using unnecessary chips. If you were to run it by polling loops, you'd probably need the extra latches and it would run even slow.
Click to expand...
I realize the latches don't add processing speed, but they should allow the circuit to respond to bus requests much faster than handling it in the MCU directly. If we look at it from the perspective of a game using the MPU to play music, the game could do other things while periodically polling the MPU status register to see if the MPU is ready to accept more data. If using the MCU to directly drive the bus, the game code would be stuck waiting for the MCU to stop asking for wait states every time it goes to write to the data register.

Please let me know if I'm just being dense and missing something here. I'd love to be able to design the circuit more like this: http://postimg.org/image/d34pi93cj/ with the addition on an MCU connected to all the signals on the right, as long as it doesn't sacrifice reliability or make the code extremely complex.
 
Chuck(G) said:
Here's a tutorial
Click to expand...
Seems like an almost perfect solution, but even with address decoding logic, it looks like the PSP can only function as one I/O address. The MPU401 responds to two different I/O addresses, each with a different function.
 
Last edited:
Maybe I'm missing something, but the last time I checked, the ISA bus can do only one thing (read or write) at a time, so you get the benefit of the PSP funciton. As to which I/O address is being accessed, well, a PIC with PSP like the 18F452 runs at up to 40MHz, so it should be able to differentiate between two port accesses.

I'm not trying to push anything here--if it were my design, I'd use a CPLD or FPGA or even a GAL or two. I don't see much difference between programmable logic and a programmable microcontroller in this application. One way you program in C or assembly; the other way, you do it in Veriog or VHDL. Note also that the 8042 in a PC AT responds to more than one address.
 
Chuck(G) said:
Maybe I'm missing something, but the last time I checked, the ISA bus can do only one thing (read or write) at a time, so you get the benefit of the PSP funciton. As to which I/O address is being accessed, well, a PIC with PSP like the 18F452 runs at up to 40MHz, so it should be able to differentiate between two port accesses.

I'm not trying to push anything here--if it were my design, I'd use a CPLD or FPGA or even a GAL or two. I don't see much difference between programmable logic and a programmable microcontroller in this application. One way you program in C or assembly; the other way, you do it in Veriog or VHDL. Note also that the 8042 in a PC AT responds to more than one address.
Click to expand...
Hm, ok. Well I will look deeper into the PSP option. Honestly a CPLD or some GALs are probably the way to go, but it seems 5v tolerant ones aren't common these days. I've never actually built anything with one though, so I need to read up on it some more.
 
SPLDs like 16V8 and 22V10 are still very common. They could reduce your combinatorial logic. You could do everything you needed in a single ATF1504 (maybe a 1502) CPLD. All 5V PTH. Quote a few EEPROM programmers will write them as well with a PLCC44 to DIP40 adapter.
 
May I suggest, if you settle on the AVR design, that you could use an Arduino Mega2560 for prototyping. It has an AVR Mega2560 which is similar to the 1284 you were considering except for more flash (256kB instead of 128kB) and more GPIO pins. The board also provides 54 GPIO pins. You don't need to use the Arduino software with it, you can use it as a general AVR development board if you want. I think it may simplify the prototyping and testing workflow. You can get them for as little as $6 (i.e. http://www.aliexpress.com/item/Mega...le-compatible-for-arduino-No/32386948507.html )
 
JDallas said:
When the host does a I/O Write, it goes into the only 74'374 on the board. No speed difference at all. When the host does a I/O Read, it enables the 74'244 which presents the 8 bit port of the micro to it to read (saving a 74'374 and the code and signal to latch it to an external chip... yank the chip and write to the micro port directly, slight speed improvement).

Note that I dealt with the 74'374 removals in two classes: I/O write where I said one only is needed, and then separately I said for I/O read, you don't need a 74'374 so just put a 74'244 driver to pass the micro 8 bit port data for it to read during a ISA bus read. Note too that the 74'244 would also be used to present the status flags when they're read and the micro data port is tri-stated (I assume your 3 micro choices have that ability).

There is no direct control of the ISA bus by only the I/O pins of the micro. It might be possible at some speeds, but having the 74'244 and the one 74'374 is sensible and less risky. You'll likely also have an address decoder like a dual 2:4 74'139, but I haven't bothered to look into that as you appear to be going with a non-embedded approach now.
Click to expand...
Ah, yes, that makes sense. I was reading that as not using any latches at all. Though, I do still question if the MCU would be quick enough to present accurate status register information as well as switching between tri-state and output modes in time for the bus. By my estimation, there will be about 17 MCU clock cycles between ISA reads and writes. A jump to the ISR (pushing and popping things from the stack, etc) to handle external events takes up almost all of those cycles. It would be easier if we could reliably count on a status register read to be immediately followed by a data register read, but that may not be the case in all software making use of the MPU401.

If by non-embedded approach you mean a PLD instead of 74xx, I was looking into that option, but I don't think learning Verilog or VHDL is something I want to dive into right now. I have not yet found a way to reduce the chip count on the address decoding logic, as it takes at least 11 bits of information to derive what the bus is asking for.
 
You must log in or register to reply here.
Back
Top