• Please review our updated Terms and Rules here

HardMPU <working title>, anyone here an EE?

Trixter said:
Does this mean your implementation will be 100% MPU-401 compatible? Even the IRQ-driven intelligent mode?
Click to expand...
That's the plan, at least to the same extent SoftMPU is. Things such as the metronome, FSK, etc, will probably not be implemented.
 
JDallas said:
Ok, I'll take a look at minimizing *all* the glue for the embedded option. I'll find some time Monday or Tuesday night and post a pads schematic Wednesday. I'll let you know if it looks good or not when I know.

I'll include the ISA and AtMega128(4) so I'll be sure about the timing (that might be after the schematic). I'll likely write the interrupt service routines in assembly language so that timing won't be an unknown and should be as fast as possible.

Maybe all of that will be ready next weekend. Wednesday I'll try to have a feasible schematic for an embedded solution. (i.e. minimal logic glue). I might have to use a mux logic trick that is confusing to see, but perfectly valid and in all digital logic books. That would be cool as the last time I had to do a design like that was on one of my EE exams about 45 years ago. :)

By the way, adding the metronome would only take a timing interrupts... like that tasker structure I was talking about.
Click to expand...
Thanks again for all your contribution on this. I have learned a lot already while tweaking the design.

Since the last schematic I posted, I have removed the latch for the command register, along with the necessary logic changes to make that work. It still has the flip-flops in place though. I'll wait to see what your determination is on the timing before making any other major changes to the design.

True, the metronome would not be difficult to implement. But I think almost everyone that cares about intelligent mode these days is using it for old games, so I don't know that it would be worth the effort to include it. If however there is a need for it, then so be it :)
 
ab0tj said:
True, the metronome would not be difficult to implement. But I think almost everyone that cares about intelligent mode these days is using it for old games, so I don't know that it would be worth the effort to include it. If however there is a need for it, then so be it :)
Click to expand...

What about recording? Last time I checked DOSBox couldn't do that in MPU-401 intelligent mode in MIDI sequencer Texture.
 
cthulhu said:
What about recording? Last time I checked DOSBox couldn't do that in MPU-401 intelligent mode in MIDI sequencer Texture.
Click to expand...
This would be based on the same code as what is used in DosBox, so no it would not be included initially. Let's get that part working right before feature creep sets in. The nice part about basing it on a flash microcontroller is that features can be added along the way, and updates can be installed by the end user with an $8 programming dongle.

I have started a list of requested features to be looked at along the way. Recording is now on there, along with a note to make sure I'm fully understanding the question about "IRQ driven" intelligent mode.
 
I guess my opinion on such a project is that, if you're not going to actually implement everything a real hardware MPU-401 would do, why bother. People tend to want one of two things: To make an MT-32 work with games, and to hook up actual synthesizers and work with sequencers. If your goal is the former, then any sound blaster + MIDI box + SoftMPU will work and those are still readily available. If the goal is the latter, you need the real thing.

Some of the real power of a true MPU-401 is that it is hardware interrupt-driven, which reduces CPU usage on slow systems (no polling) as well as reducing jitter. For an 808x-based system, it makes complex sequencing possible.
 
Trixter said:
I guess my opinion on such a project is that, if you're not going to actually implement everything a real hardware MPU-401 would do, why bother. People tend to want one of two things: To make an MT-32 work with games, and to hook up actual synthesizers and work with sequencers. If your goal is the former, then any sound blaster + MIDI box + SoftMPU will work and those are still readily available. If the goal is the latter, you need the real thing.

Some of the real power of a true MPU-401 is that it is hardware interrupt-driven, which reduces CPU usage on slow systems (no polling) as well as reducing jitter. For an 808x-based system, it makes complex sequencing possible.
Click to expand...
SoftMPU depends on EMM386, therefore any machine that can't run EMM386 can't use SoftMPU. This card would work on those machines. This card also generates an interrupt when data is available for reading, like the real MPU401. Though, SoftMPU has the same ability by using the sound card to generate an interrupt. Does intelligent mode recording generate interrupts for other events?
 
Trixter said:
Yes, for TRACK DATA requests. You can also use the interrupt for playing.

Have you read the technical specification? Here's a copy, OCR'd for your searching pleasure: ftp://ftp.oldskool.org/pub/misc/Hardware/Roland/MPU-401 technical reference manual.pdf

Also, not sure if you'd seen this or not: http://www.amibay.com/showthread.php?57231-Cloning-an-MIF-ISA-Card
Click to expand...
I have read that manual, a few times now. As far as I can tell, the MPU requests more data by sending a message to the host. The interrupt is just a byproduct of this, letting the host know that the MPU sent a message. This hardware would act the same way, it would just need the functionality added in the firmware.

I have seen the MIF clone. But that only handles the interfacing, you still need the MPU itself.
 
Last edited:
JDallas said:
I think the interrupt is the only way the MPU can signal the host to check the MPU out. I don't think it can send any message in the sense of information leaving the card. I assume it leaves a message in the buffer and sends an IRQ to make the host look and read any pending messages inside the MPU.
Click to expand...
Right. What I mean to say, is that it's the act of putting a message in the buffer that raises the IRQ, the IRQ itself isn't the signal to request more data. The way this circuit is set up, it should have the same behavior.

JDallas said:
I looked over the manuals for the MPU-401 and MPU-IPC-T tonight... Isn't your project board really more like a MPU-IPC-T than a MPU-401?

I've been looking over the MPU-401 Tech Manual and the MPU-IPC-T User Manual, and your design seems to be effectively a IPC-T perhaps with intelligent mode (but I thought the IPC-T had that too). I've looked at the MPU-401 schematics and its host interface is a simple, more generic interface than the -401.
Click to expand...
Correct. It resembles an MPU-IPC more than an MPU-401, but the MPU-401 is the standard all others were built to for software compatibility. The MPU-401 (plus interface board) and MPU-IPC should be functionally equivalent.

JDallas said:
I looked over the double 74'138 and it is set up correctly to address the board as an 8 I/O block. It supports these 300-307h, 310-317h, 320-327h, 330-337h blocks using JP1.

The board select address is: xxxx.xx11.00JJ.0xxP (binary) where JJ is a single jumper installed to select 00b, 01b, 10b or 11b to complete the second digit in the block addresses above. "P" is A0 and selects a the data port when low or the command port when high.

The two 74'138 decode this address correctly into the for events: (1) I/O Write Data, (2) I/O Write Command, (3) I/O Read Data, (4) I/O Read Command.

The MPU-IPC-T board select address is: xxxx.xxJJ.JJJJ.X00P where its jumper pads default to xxxx.xx11.0011.X00P

I assume that you want the board selection to be as accurate as possible as long as it doesn't require some even more chips.
Click to expand...
In practice, you will almost always see the MPU-{401,IPC} used at 330h. 300h seems to be the secondary choice. If you look at the schematic for the MIF-IPC-A, which is the interface board for the MPU-401 on IBM computers, A1 and A2 are also ignored, so it appears to show up at (for example) 330-337 as well. The MIF-IPC (original version of the interface board, which had timing issues on faster machines) passed through A1-A2 to the MPU-401, I gather that the intention was to support multiple MPU-401 boxes on one interface card, but it seems to have never been implemented.
 
JDallas said:
You have one and a half dual flip-flops (74'74) leaving one half unused. There is a nice Texas Instruments 9-bit flip-flop (latch) that could be used to remove the second 74'74
Click to expand...
Ah, wonderful. That approach makes a lot of sense. I am writing down chip numbers for a future second parts order :)
 
ab0tj said:
If you look at the schematic for the MIF-IPC-A, which is the interface board for the MPU-401 on IBM computers, A1 and A2 are also ignored, so it appears to show up at (for example) 330-337 as well. The MIF-IPC (original version of the interface board, which had timing issues on faster machines) passed through A1-A2 to the MPU-401, I gather that the intention was to support multiple MPU-401 boxes on one interface card, but it seems to have never been implemented.
Click to expand...

Look at the MPU401 schematic; the address selection (I.e. Unit number) logic is implemented, however as with the MIF-IPC, the jumper block pin header is omitted and a trace added to 'hard set' the address (as unit 0). One of the goals of my card is to enable multiple device selection.
 
Last edited:
What I really would like to see, is an 8Bit ISA Combi-Card.
What it should combine?
- perhaps: EGA with LPT/COM
- perhaps: OPL2/3 with MPU401i
- perhaps: VGA with SCSI
- perhaps: EMS-Card with LPT/COM

Such cards would be VERY usefull for older Retro-PC's with only a view slots,
or in an Amiga 2000 with a Bridgeboard.

Doc
 
pearce_jj said:
What are you testing?
Click to expand...
Currently building the last schematic I posted on here, just so I can get started writing some software for the MCU, testing various way of interfacing with the bus, etc. So far it is all wired up, just waiting for the ISA prototyping board so I can actually access the ISA bus signals. Manual testing of address decoding logic and some other things seem to be working out so far.

JDallas said:
I went to the Texas Instruments website and used their parts selector to choose only through hole chips with (1) PDIP package, (2) 0-70C or -40-+85C thermal, and (3) Active production status. I downloaded the spreadsheets and while its useful to me on looking at some alternative design options here, I'm going to make a quick reference text version I'll post to give anyone a quick reference example of what's in production today in regard to plastic through hole chips.

I should be done with my alternate schematic today and you can ponder it and use any or none of it as you wish. The double 74'138 circuit functions in only two chips so it has value, I'll show an alternate method that is just a different approach.

After I post that, I'm going to look at Atmel Simple PDL chips to see how much logic it can consume from the TTL glue.
Click to expand...
As always, I appreciate your input. I'm looking forward to seeing what your schematic looks like. I'm building the circuit on a breadboard for now so I can easily change it to incorporate the tricks you have shown me.
 
JDallas said:
Unidirectional buses can work without sacrificing Port C's JTag. The critical event is reading the Command/Data port between what may be back to back cycles (the command port has no handshake. So, for alternate design with Unidirectional, I'd use Port A in full to read that pathway and because the data written to the host has a handshake of Status and IRQ, its not as critical an event.
Click to expand...
I think Port B can be used as a full byte if the handshake signals are moved to free pins on Port C and Port D. The ISP signals are only used during programming, so they should not interfere during normal operation. ISP could be done away with entirely, but it might make it harder for the end user to do firmware upgrades.
 
JDallas said:
Schematic with the dual reset feature.
Click to expand...
I do like how much cleaner your version is. I'll have to put in an order for some more logic chips to try it out.

In other news, the ISA prototyping board finally arrived last night. Shipped from Thailand, no wonder it took so long. I soldered some pin headers to the ISA signal area and wired it up to my breadboard. After correcting the order of the address lines, I can at least cause a MIDI program to lock up. Previously it was just "could not initialize sound hardware". I think something is wrong with either my code or my wiring as the flip-flops are not being reset. More debugging tonight as time allows. But at least it's progress!
 
You must log in or register to reply here.
Back
Top