Trixter
Veteran Member
My goal is to port the most excellent SoftMPU software to a PIC chip.
Does this mean your implementation will be 100% MPU-401 compatible? Even the IRQ-driven intelligent mode?
My goal is to port the most excellent SoftMPU software to a PIC chip.
That's the plan, at least to the same extent SoftMPU is. Things such as the metronome, FSK, etc, will probably not be implemented.Does this mean your implementation will be 100% MPU-401 compatible? Even the IRQ-driven intelligent mode?
Thanks again for all your contribution on this. I have learned a lot already while tweaking the design.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.
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
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.What about recording? Last time I checked DOSBox couldn't do that in MPU-401 intelligent mode in MIDI sequencer Texture.
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?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.
Does intelligent mode recording generate interrupts for other events?
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.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
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.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.
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.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.
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.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.
Ah, wonderful. That approach makes a lot of sense. I am writing down chip numbers for a future second parts orderYou 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
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.
It looks like the 74ACT823 has a DIP package... But I can't find them for sale anywhere, either.Can't use that circuit, no DIP packages on either chip.
It looks like the 74ACT823 has a DIP package... But I can't find them for sale anywhere, either.
Parts are starting to show up, so I'm putting together a breadboard for testing designs: http://postimg.org/image/3o96ruh3h/
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.What are you testing?
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.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.
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.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.
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.Schematic with the dual reset feature.