MIDI with the MacPlus?

[MIST]

I would like to play MIDI from my (FPGA) MacPlus. I was expecting that Cubase can simply send and receive MIDI through the SCC/modem serial port as the SCC is definitely able to send and receive at 31250 bit/s. But Cubase only offers me 500k/1M and 2Mbit. This suggests that there's more hardware involved. Is there any software that would allow me to play MIDI at 31250 bit/s through the modem port?

There is the Midiman MacMan interface: https://ia801504.us.archive.org/10/items/Macintosh_Garden_Manuals_2021_M/MIDIMAN_Macman.pdf This seems to be exactly the hardware I bascially already have on my board as this seems to be just a dumb MIDI to RS422 converter. But that would not work with Cubase?

 

[Snial]

I would like to play MIDI from my (FPGA) MacPlus. I was expecting that Cubase can simply send and receive MIDI through the SCC/modem serial port as the SCC is definitely able to send and receive at 31250 bit/s. But Cubase only offers me 500k/1M and 2Mbit. This suggests that there's more hardware involved. Is there any software that would allow me to play MIDI at 31250 bit/s through the modem port?

There is the Midiman MacMan interface: https://ia801504.us.archive.org/10/items/Macintosh_Garden_Manuals_2021_M/MIDIMAN_Macman.pdf This seems to be exactly the hardware I bascially already have on my board as this seems to be just a dumb MIDI to RS422 converter. But that would not work with Cubase?

The way it works is that the serial port can be driven by an external clock. So, if the clock is at, e.g. 1MHz and you select 1MHz, then the SCC does a ÷32 to get 31250. But I think, also the MIDI Patchbay control panel sets it accordingly. I have used my Mac Plus with my MIDIMAN:


I think you need to press the button for MIDI mode.

 

[MIST]

Thanks. That was hopefully the missing info.

I still wonder why I did not scope any outgoing data at all since my FPGA IMHO should just have used the standard clock source instead. But adding the extra 1mhz clock should be quite simple.

 

[Snial]

Thanks. That was hopefully the missing info.

I still wonder why I did not scope any outgoing data at all since my FPGA IMHO should just have used the standard clock source instead. But adding the extra 1mhz clock should be quite simple.

Is your FPGA written in Verilog or VHDL? Can't you add external clocking, as that would be more helpful and accurate? BTW: if that's the nano Mac, it's great!

Is the CPU running at approx the same rate as a real Mac/128/512/Plus/SE/Classic? e.g. are you using an OpenCores 68K?

 

[MIST]

Yes, it's the NanoMac. It runs at exactly the correct speed. One thing I am still missing is the exact memory cycles available to the CPU during the video slot. But that should only result in a minor error.

And yes,.I can just create the necessary 1mhz clock. If the rest of the scc is implemented to a sufficient extent then this should just work. Adding support for an external clock is also possible but would require additional hardware. It's easier to generate the clock inside the FPGA as well.

 

[Snial]

Yes, it's the NanoMac. It runs at exactly the correct speed. One thing I am still missing is the exact memory cycles available to the CPU during the video slot. But that should only result in a minor error.

Isn't it simply interleaved on a Mac Plus? During an active scan line, the CPU gets one 4 cycle memory fetch (to RAM) and the Video gets the other. It doesn't affect ROM and the CPU isn't stalled if it doesn't need to access RAM (e.g. internal CPU cycles). Because there's 60.15fps x 10944 fetches per frame x 4 cycles per fetch, that's: 2633126.4 potential cycles lost => potentially as little as 4.87M cycles/second.

On the SE and Classic it's different. The CPU gets 3 fetch cycles, then the video gets 1.

And yes,.I can just create the necessary 1mhz clock. If the rest of the scc is implemented to a sufficient extent then this should just work. Adding support for an external clock is also possible but would require additional hardware. It's easier to generate the clock inside the FPGA as well.

OK! And what HDL did you use to develop the FPGA?

 

[MIST]

Memory access on the early Macs only runs at 2MHz, with the CPU using every second memory cycle and the unused one of the video cycle during blanking. Audio and floppy PWM also get one per display line during blanking. But the chipset must also have used some for memory refresh. I don't know yet, how many these were.

Anyway, with the external 1Mhz clock and some small adjustments in SCC interrupt handing, this is now possible:

The device on the left is a SAM2695 dev board. But a commercial synth like the mt32 works equally well. I should actually try Space Quest 3 with my MT-32 one day.

 

[Snial]

Memory access on the early Macs only runs at 2MHz, with the CPU using every second memory cycle and the unused one of the video cycle during blanking. Audio and floppy PWM also get one per display line during blanking. But the chipset must also have used some for memory refresh. I don't know yet, how many these were.

I thought it was roughly every 2ms, but a refresh cycle is only a /RAS isn't it? A Mac Plus has plenty of CPU for handling many MIDI channels.

Anyway, with the external 1Mhz clock and some small adjustments in SCC interrupt handing, this is now possible:

Excellent!

The device on the left is a SAM2695 dev board. But a commercial synth like the mt32 works equally well. I should actually try Space Quest 3 with my MT-32 one day.

I've just been watching a video on the SAM2695, interesting GM sound module with some synth features. I used to have an MT-32. I'd probably try and put MT32-PI on one of my Raspberry PIs. However, at the moment it'd only work on my PI-3 unless I do something clever like figuring out how to make the underlying Munt MT-32 emulator work with multiple cores (it's a single-core implementation as far as I can see).

I was thinking of doing it at the partial level, but I'm not totally sure of the underlying software architecture. Munt allocates partials to Partial objects, but I don't yet know if each one then computes a single sample at a time, so that there's a superloop for each partial; or whether each partial computes multiple samples at a time (e.g. 1ms worth) and there's some other mechanism. The easiest way, IMHO would be to allocate the main app to a single core, e.g. core 0; then have core2 allocated to even partials and core2 allocated to odd partials (here, each core spin-waits on a trigger, then runs through all its allocated partials).

It wouldn't be optimal, but since a PI-2 runs at 900MHz, and a PI-3 runs at 1.4GHz a second core only has to take a 500MHz load off for it to perform as well and splitting the entire functionality between 3 cores should certainly achieve that. Additionally, given that the MT-32 only has one reverb, if the reverb emulation is applied after the values from all the active partials get summed, then perhaps Core 1 could be dedicated to reverb.

 

[MIST]

That's exactly why I prefer to work on such things using FPGAs. Trying to squeeze x parallel and in sync working processes onto n cores is not trivial and not straight forward. Those FPGAs sure have their own limitations, and developing for them isn't trivial. But especially these massively parallel processes running closely coupled feel so much more natural with them.

This of course depends on how much analog number crunching you need to do. Implementing floating point calculations inside and FPGA isn't easy. But parallel digital logic is their natural use case.

 

[Snial]

That's exactly why I prefer to work on such things using FPGAs.

Understandable. I did a little verilog for my MPhil.

Trying to squeeze x parallel and in sync working processes onto n cores is not trivial and not straight forward.

True, though it was pretty natural with Transputers. They had parallel process opcodes which linked in the address of a process to be scheduled by a hardware scheduler and then started or ran the process (startp and runp).

Those FPGAs sure have their own limitations, and developing for them isn't trivial. But especially these massively parallel processes running closely coupled feel so much more natural with them.

Sure.

This of course depends on how much analog number crunching you need to do. Implementing floating point calculations inside and FPGA isn't easy. But parallel digital logic is their natural use case.

I'm quite a fan of fixed-point arithmetic.

 

[MIST]

I am sure a fpga based mt-32 clone would find it's users ...

 

[Snial]

I am sure a fpga based mt-32 clone would find it's users ...

I'm sure it would. I just don't have access to programming for FPGAs using a Mac (except if it's emulating Windows). I think the idea of multi-core Munt is quite interesting though.