NanoMac, a candy bar sized FPGA Mac Plus / PlusToo

[jgardner]

Yes, sure. The 1Mhz clock is implemented and Cubase is using it. Otherwise, Cubase would not work properly. Initially my core lacked the 1Mhz clock and thus Cubase wouldn't work. This ha been discussed in another thread here.

The interesting thing is that M would not use that external clock by itself. So the nearest bitrate it can achieve using the internal 3.686Mhz clock is 3686000/128 = 28796. This is exactly what we are seeing. Cubase switches to the 1Mhz clock and then uses a 1000000/32=31250 setting. Afterwards M also uses it.

The odd part is that M does not use the /128 dividers anymore. Either it does not touch the bitrate settings at all and thus continues to use whatever Cubase has set or it recognizes that the 1Mhz clock has been activated and then uses the appropriate divider for 1Mhz.

M actually has the same setting for 500kHz/1Mhz and 2Mhz as Cubase. But it doesn't seem to honor them ... although it doesn't fully ignore them as changing between 500kHz, 1Mhz and 2Mhz does change the resulting bitrate between 57600bit/s, 28800/bit/s and 14400 bits/s.

Furthermore, there is a "External Clock" setting in the Options menu of M which somewhat sounds like it's meant for exactly this purpose. But it doesn't seem to do anything. Maybe it's expecting some kind of different hardware?

How much experience do you have with MIDI on the classic mac in general and M in particular? What exact hardware does it expect to be connected, and how does it use it? What is the purpose of the "External Clock" option? It seems to me that this isn't a problem with my implementation, but rather a lack of understanding how M is to be configured and used. Is it expecting other software or some kind of driver to setup things?

Installing M and getting it running on a real mac is quite straightforward, so I'm not sure where it differs with the FPGA at the moment. I've installed in on an SE I bought a week ago, which was never used for music, and it worked without complications setting it up, copying the externals is all it needs to work.

"External Clock" is used for M to send out a clock signal to sync to MIDI devices that can be slaved to the Mac, making M the master clock.
M doesn't need any specific hardware to work, as it's meant for all MIDI devices. It only needs a MIDI capable synth, which in the case of this project expects MIDI data on channel 1, 2, 3 and 4. I think it's more likely related to the way the external interacts with the hardware it expects, which is the hardware of the mac itself.

 

[Snial]

Yes, sure. The 1Mhz clock <snip> M would not use that external clock by itself. <snip> 3686000/128 = 28796. <snip> Cubase switches <snip> Afterwards M also uses it.
<snip> "External Clock" setting in the Options menu of M <snip>

How much experience do you have with MIDI on the classic mac in general and M in particular? <snip>

After I bought my LC II back in 1993, I bought Cubase Lite, which came with a MidiMan Mac interface (1 in, 3 out). I used it with our keyboards at the time: A Yamaha SY-22 keyboard Synth (8 parts, 16-note poly, dynamic voice allocation); a legendary MT-32 (8 parts + drums, 8-32 note poly, static voice allocation); a Casio CZ-101 (1x4 poly part or 4x1 mono parts).

So, I did quite a bit of sequencing with that setup and frankly that's enough for my needs, because the effort needed for arrangements that needed more parts x polyphony was more than I'd ever expend (so in practice I'd end up with about 5-6 usable parts split between the instruments I had). I also used the same setup with my Mac Plus ( I'm not sure why I didn't always use the LC II, maybe I needed more space at one point and the Plus was more compact). I also tried it with my PB100.

I interfaced as described above, by setting a 1MHz rate, which seemed to work. But I also used the standalone Mac OS Midi Manager thing. I didn't use OMS. I also used a public-domain notation app called Lime. At one point I wanted to write my own librarian and sound editor for the MT-32, so I found some code from the MacTech archive and started to write one. I was only partially successful because I didn't really understand the synth architecture for the MT-32. Later I adapted it into a librarian / sound editor for a DX-100 using THINK C and TCL, which did work.

Later, when I upgraded to my PM4400 and then my iBook/300 I had a Roland Sound Canvas with a MIDI interface and Cubasis (VST?). That was my last Mac OS 9 era MIDI app. I still have that, but prefer simpler sequencers. On my PB1400 I use Logic Fun V4 which I uploaded to the Macintosh Garden after I verified it was OK with the original developers.

So, I have IMHO a reasonable amount of practical experience with that era of MIDI on a Mac. I have no experience of M.

 

[Snial]

<snip> M doesn't need any specific hardware to work, as it's meant for all MIDI devices. It only needs a MIDI capable synth <snip>

I don't get why M doesn't use an external 1MHz clock to drive the SCC. It was never hard to code for that and it's the way interfacing MIDI to an early Mac was intended to be done.

 

[MIST]

If M doesn't use any additional hardware, then how is midi gear connected to the Mac? Unlike the Atari ST, none of the early Macs came with midi interfaces. Or did some?

The observed behaviour of M would make sense if there was a 4Mhz clock source in the Mac. But it IMHO always was 3.868 MHz. I am sure I am missing something. But having never owned or even used any Mac doesn't help ...

Maybe Snial can use his emulator to see how M behaves there.

 

[jgardner]

If M doesn't use any additional hardware, then how is midi gear connected to the Mac? Unlike the Atari ST, none of the early Macs came with midi interfaces. Or did some?

The observed behaviour of M would make sense if there was a 4Mhz clock source in the Mac. But it IMHO always was 3.868 MHz. I am sure I am missing something. But having never owned or even used any Mac doesn't help ...

Maybe Snial can use his emulator to see how M behaves there.

Ah yes M did require a MIDI interface! Sorry I didn't mention this before, not sure why I overlooked that detail. Though every serial MIDI interface works without the need of installing drivers, so they all do function in the same way. It would be useful to know more about this universal design element in the classic mac serial MIDI interfaces. I'll do some research and see what I can find on the relation between the Apple MIDI manager and the universal way MIDI interfaces worked with it. These specs must have been available to manufacturers and programmers at the time ....

 

[jgardner]

Installing M and getting it running on a real mac is quite straightforward, so I'm not sure where it differs with the FPGA at the moment. I've installed in on an SE I bought a week ago, which was never used for music, and it worked without complications setting it up, copying the externals is all it needs to work.

"External Clock" is used for M to send out a clock signal to sync to MIDI devices that can be slaved to the Mac, making M the master clock.
M doesn't need any specific hardware to work, as it's meant for all MIDI devices. It only needs a MIDI capable synth, which in the case of this project expects MIDI data on channel 1, 2, 3 and 4. I think it's more likely related to the way the external interacts with the hardware it expects, which is the hardware of the mac itself.

Also I falsely stated that the external clock setting turns M into the master clock! It's actually the reverse. There is another setting I got confused with called "send clock" which is indeed to slave other hardware to M, but "external clock" is so M can be slaved to other MIDI clock sync signals and MIDI real-time messages.

 

[jgardner]

While I'm trying to collect some more info on all this, I'll also prepare a new drive image with other software to test, as I think it may not be specific to M, even if with Cubase all works. I'll also add the first version of Opcode's OMS, which attempted to simplify things and add additional functions, and became the standard MIDI framework for 68k and PPC macs. M does not require OMS, but it does work with it, as well as many other MIDI tools and sequencers that often came with OMS as a bundled package from 1991 onwards.
Opcode's MAX is another tool that would be great to have functional on the nanomac. MAX still exists today as MAX/msp and is a very easy to use graphical programming environment. The first version was just for MIDI data, and I'm quite experienced with this tool. I can create custom MAX patches with data visualization for custom MIDI i/o monitoring. It may require the same as M though but it would be interesting to see if it works. I will prepare a MAX patch specifically to visualize incoming and outgoing MIDI data with almost no setup necessary. A MAX patch looks something like this:

 

[MIST]

Please don't spend too much time on this, as I am not sure if I'll dive very deep into debugging this. The potential user base is pretty small, and it doesn't make much sense to spend too much time into something that'll barely be ever used.

That said, I took a closer look, and I am not sure what the relationship between the Apple MIDI Drivers and the MIDI hardware is. It seems these drivers aren't needed, and they also don't seem to be for system 6. And the MIDI hardware in fact seems to be very similar and only consist of the MIDI line drivers connected to the RS422 RX/TX and a 1 Mhz clock generator that feeds into the CTS/HSK1 line. Without this Cubase wouldn't be working at all.

So it's more a software problem and perhaps a minor hardware issue. What exactly is M trying to do? And what prevents if from working as expected? Is it expecting a different hardware? A different MacOS version? I dunno ...

 

[MIST]

Ah and please don't prepare anything that expects to receive something via MIDI. I don't own any device that would send MIDI.

 

[jgardner]

Please don't spend too much time on this, as I am not sure if I'll dive very deep into debugging this. The potential user base is pretty small, and it doesn't make much sense to spend too much time into something that'll barely be ever used.

That said, I took a closer look, and I am not sure what the relationship between the Apple MIDI Drivers and the MIDI hardware is. It seems these drivers aren't needed, and they also don't seem to be for system 6. And the MIDI hardware in fact seems to be very similar and only consist of the MIDI line drivers connected to the RS422 RX/TX and a 1 Mhz clock generator that feeds into the CTS/HSK1 line. Without this Cubase wouldn't be working at all.

So it's more a software problem and perhaps a minor hardware issue. What exactly is M trying to do? And what prevents if from working as expected? Is it expecting a different hardware? A different MacOS version? I dunno ...

Sure that's understandable, also already having Cubase working is incredible as it at least offers a workaround to get M working. I know it is very niche, but the community of music technologists and researchers, even if small, would be greatly helped by an FPGA alternative to the actual hardware to preserve this important chapter of music technology history. I'm already super grateful for the work you've done so far, as it shows there is a way to get this working, if not now, at some point in the future.
M is actually just a very simple music sequencer, which works with small data loops of MIDI data, mainly note pitch and velocity data. These are algorithmic so the sequencer generates variations on melodic material, and with a performance focus, kind of like ableton live is more performance focused than DAWs like cubase or logic. You can control the sequencer with the computer keyboard in real-time for live performance with a computer. The only data M can send is: MIDI pitch and velcotity (max 16 channels), MIDI program changes for synth presets and MIDI clock, so hardware like drum machines could be synced to M's sequenced notes. Ideally I can do all the needed research before requesting an implementation for the Nanomac, so the time investment from your side is minimal. For this I need to be more precise than I have, and to know as much as possible on how the implementation currently works. I'll try to gather as much info as I can from the MiST and MiSTer respositories. Also if in the end it still looks too complicated I fully understand. Starting next year I'll receive some funding to perform this type of research. Maybe it would make more sense as a paid work? I love how the open source mentality often means that everyone contributes for free, but somehow that also doesn't seem fair to me if many hours are spent on getting these kinds of niche things working ...

 

[jgardner]

Please don't spend too much time on this, as I am not sure if I'll dive very deep into debugging this. The potential user base is pretty small, and it doesn't make much sense to spend too much time into something that'll barely be ever used.

That said, I took a closer look, and I am not sure what the relationship between the Apple MIDI Drivers and the MIDI hardware is. It seems these drivers aren't needed, and they also don't seem to be for system 6. And the MIDI hardware in fact seems to be very similar and only consist of the MIDI line drivers connected to the RS422 RX/TX and a 1 Mhz clock generator that feeds into the CTS/HSK1 line. Without this Cubase wouldn't be working at all.

So it's more a software problem and perhaps a minor hardware issue. What exactly is M trying to do? And what prevents if from working as expected? Is it expecting a different hardware? A different MacOS version? I dunno ...

On if it's a software issue or not I can only say that I have M running on multiple Powerbook Duo's, an SE/30 and an SE, all without any setup or MIDI issues, tested on multiple versions of classic mac OS from the first to the last. It always works straight after copying the MIDI extensions without setup and does not seem to be very system dependent. It also works with all three different serial MIDI interfaces I've tested it with. The first version of M is from 1987, and compatibility seems to be pretty good as I've never experienced that it didn't work as expected, but of course I could just have been lucky so far.
Claude (AI) had this to say, though I may need to feed it a lot more info to get a better answer: "The FPGA implementation likely doesn't properly set the SCC status register(s) that indicate external clock availability on reset, causing "M" (via MIDI Manager) to fall back to internal clock mode, whereas Cubase performs additional initialization that fixes this state. The SCC (Zilog 85C30 or compatible) has specific registers (likely Write Register 11 for clock mode selection and Read Register 0 or 10 for status) that MIDI Manager reads to detect external clock presence, and if these don't return the correct values indicating "external clock available and stable on HSK pin," the software defaults to using the Mac's internal 3.6864 MHz clock instead."

 

[MIST]

The AI remarks really aren't very helpful. There is no status register that indicates any availability of external clocks. What AI does is that it just takes the text you give it and generates a text that is statistically derived from it. It doesn't understand or comprehend anything. AI can summarize things, and AI can reproduce things similar to what have been done before and was thus part of it's training data. But as you learned, MIDI on the Mac is not a popular topic and thus AI hasn't had a chance to digest much about that.

What I did try yesterday is to route the external clock to the SCCs CTS input, as these are tied together in the Mac. M might try to detect changes in the CTS signal to detect the presence of the external clock. But it seems it doesn't do that ... or I don't feed the signals as M would expect it. That also doesn't explain why it works after Cubase has been run.

As MIDI is not working reliable enough to be usable, I'll remove/disable the MIDI part until it's better understood.

You might just wait for snials emulator to be ready. After all, you probably don't need two such systems and his emulator is likely to be way cheaper and easier to build as it only needs to get the software side running and is not intended to be an exact hardware replica as well.

 

[joevt]

A program can enable external clock, enable loopback, begin automatic transmission, and count the number of bytes received in a certain amount of time to determine if the external clock is working.
https://68kmla.org/bb/index.php?threads/localtalk-but-faster.45615/post-505309
https://68kmla.org/bb/index.php?threads/localtalk-but-faster.45615/post-505648

 

[MIST]

Ah ... indeed, the loopback ... It seems that's not implemented.

Using an emulator someone could run M and capture the SCC write accesses. This would tell if M enables the loopback.

 

[MIST]

Everything looks correct when running M in minivmac. Registers are being set to use the external clock as expected. And while preparing to trace the same in the NanoMac I stumbled upon this copy'n paste bug:

NanoMac/src/macplus/scc.v at aec312834ca06c1b649206ca282dbedd9781475f · MiSTle-Dev/NanoMac

A Macintosh Plus inside an FPGA. Contribute to MiSTle-Dev/NanoMac development by creating an account on GitHub.

github.com

Register 11 is addressed at address 12 ... it's pure luck that Cubase actually works with that.

I'll test this evening if that actually fixes M. But I am pretty confident.

 

[MIST]

Yes, that was it. M is now working ... at least it does play something over MIDI. Since it doesn't play any song, it's hard for me to tell whether it's correct, what it does ...

And indeed Claude just rephrased what was already said, and it was nowhere near the real problem which was a broken register address decoding which was due to some copy'n paste error.

 

[jgardner]

Yes, that was it. M is now working ... at least it does play something over MIDI. Since it doesn't play any song, it's hard for me to tell whether it's correct, what it does ...

And indeed Claude just rephrased what was already said, and it was nowhere near the real problem which was a broken register address decoding which was due to some copy'n paste error.

Whoa incredible! So good to hear that M now works! And that the fix will likely work for all other MIDI software as well. I will soon receive a bunch of Tang Nano's that I ordered so I can hopefully start testing this too, in the next week. That will make testing a little simpler as I know what to expect from M, and I'll gather as much software as I can to test and report back. This is huge for the 80s music software preservation community, and I will definitely spread this news to anyone working with classic macs and MIDI, and I'll make sure to mention who made it happen! Thanks so much for your work on this! I've been literally waiting for this moment for about 5 years haha

 

[MIST]

My recommended setup currently is the Tang Nano 20k + a raspberry pi pico, both wired up on a breadboard.

Stefan is more actively working on the Tang Nano 20k standalone variant which is IMHO somewhat more cumbersome for development but should be fine for a pure user.

You'll of course need some physical MIDI interface. Some midi shield meant to be used in the Arduino world should do the trick. It's important that the shield will work with 3.3v io as the FPGAs IO does not tolerate 5v.

Finally, you could if course get some if our shields manufactured. Some of them include MIDI and production is rather affordable.

You might join the misterynano thread over on atari-forum.com . There are a bunch of people using this.

 

[jgardner]

After I bought my LC II back in 1993, I bought Cubase Lite, which came with a MidiMan Mac interface (1 in, 3 out). I used it with our keyboards at the time: A Yamaha SY-22 keyboard Synth (8 parts, 16-note poly, dynamic voice allocation); a legendary MT-32 (8 parts + drums, 8-32 note poly, static voice allocation); a Casio CZ-101 (1x4 poly part or 4x1 mono parts).

So, I did quite a bit of sequencing with that setup and frankly that's enough for my needs, because the effort needed for arrangements that needed more parts x polyphony was more than I'd ever expend (so in practice I'd end up with about 5-6 usable parts split between the instruments I had). I also used the same setup with my Mac Plus ( I'm not sure why I didn't always use the LC II, maybe I needed more space at one point and the Plus was more compact). I also tried it with my PB100.

I interfaced as described above, by setting a 1MHz rate, which seemed to work. But I also used the standalone Mac OS Midi Manager thing. I didn't use OMS. I also used a public-domain notation app called Lime. At one point I wanted to write my own librarian and sound editor for the MT-32, so I found some code from the MacTech archive and started to write one. I was only partially successful because I didn't really understand the synth architecture for the MT-32. Later I adapted it into a librarian / sound editor for a DX-100 using THINK C and TCL, which did work.

Later, when I upgraded to my PM4400 and then my iBook/300 I had a Roland Sound Canvas with a MIDI interface and Cubasis (VST?). That was my last Mac OS 9 era MIDI app. I still have that, but prefer simpler sequencers. On my PB1400 I use Logic Fun V4 which I uploaded to the Macintosh Garden after I verified it was OK with the original developers.

So, I have IMHO a reasonable amount of practical experience with that era of MIDI on a Mac. I have no experience of M.

This is actually very valuable information to me, as I'd love to know more about programming possibilities (and limitations) at that time. It was such a fruitful time in terms of creative approaches to music making, with sequencers that found unique ways to maintain a human-like character while still sequencing with a computer. I could tell people approached computers differently as the role of 16-bit personal computers in studios or on stage was still quite new, resulting in very experimental approaches, before the main methods for computer based music making as we know them today became standard. Multi-timbral synth development combined with these fascinating software tools was such a combination, and still pretty compact. That moment where hardware was fully optimized for computers, and computers would be optimized for the hardware keeps fascinating me. Would be great to hear more of your experiences on this. I currently control my studio from an imac g3 with OS9 and Sounddiver + Logic. I recently experienced making an album this way and it worked really well. It would be great if the level of integration Sounddiver offered comes back at some point to truely unite legacy and modern workflows.

 

[jgardner]

My recommended setup currently is the Tang Nano 20k + a raspberry pi pico, both wired up on a breadboard.

Stefan is more actively working on the Tang Nano 20k standalone variant which is IMHO somewhat more cumbersome for development but should be fine for a pure user.

You'll of course need some physical MIDI interface. Some midi shield meant to be used in the Arduino world should do the trick. It's important that the shield will work with 3.3v io as the FPGAs IO does not tolerate 5v.

Finally, you could if course get some if our shields manufactured. Some of them include MIDI and production is rather affordable.

You might join the misterynano thread over on atari-forum.com . There are a bunch of people using this.

Great! Thanks for the info. I will go for the pico then combined with the Nano, I have one here already. I'll definitely join the thread as well. This also solves the expense problem with MiSTer, especially for use cases where the main focus point is not to support the largest amount of games and systems. I plan on building the Nano into an empty Mac Plus case, and see how far I can go from there in replicating an authentic experience somewhat, with some useful modern added functionalities, and of course amazing reliability. I have a custom display for it to replace the CRT as well, though it's 800x600 which isn't ideal.