th0mas

The capacitors c1 and c2.. are they shorting against each other?

Looking for a box to house your midibox project? I just found the coolest case to use - plus, it's hard plastic and not metal so it's easy to work with. http://www.armchairempire.com/images/feature-articles/sega-master-system/sega-master-system.jpg ^^ that's a picture of the box. I'll post dimensions when I have them. I just bought two of these from a local thrift store.

not yet, it's being shipped atm. Won it this week. I'll let you know whenever I get it.

I think I'm going actually, I'm just going to build a midibox seq so I have enough buttons. I don't think I'll end up with extras, I have a number of cases to build. I figured the auction was going to go over $10, but wasn't home to attempt to snipe myself a winning bid. I'm glad it went to a fellow midiboxer and not some parent for a drooling kid :)

You outbid me for that :(. I had my eyes set on some of these games for about a week, prior to this thread being started (the similiarity to monome was brought up in a hackaday thread and I went shopping). Oh well, I did win one last week anyways :).. I wanted 32 buttons but I don't think I'm going to build that controller anymore anyways, instead just a midibox seq.

:) anything you do is obviously at your own risk, but someone with a better understanding of the risks involved than I (Thorsten) was willing to run it, so I don't think it's that risky :)

hard plastic

I had the chance to play one of those things in a zellers store (here in Canada) the other week. It's a pretty fun little toy.. The keyboard sucks as bad as would be expected, but some of the samples aren't actually that bad (and those big buttons are backlit). Someone expecting to use the entire case should be wary because it's pretty cheap plastic (but definitely big enough to house all the midibox gear, plus you could probably use some of the internal ROM samples for something) edit: also, the scratchpad is not really useable, all it has connected to it is a little switch detecting if you're pushing right or left, no speed or anything like that, it's not even a rotary encoder as far as I can tell.

You could try uploading a little project I made a couple weeks ago that tests your LCD data pins for a short. You can read about it here: http://www.midibox.org/forum/index.php?topic=6514.0 Aside from that, I think there's no harm in uploading the FM s/w and seeing if it plays. Your LCD is independent from that (aside from some catastrophic short or something) and, assuming the rest of the hardware is okay, it will run, albeit without the LCD.

dengel: if the LED's are independent circuits of one another then you'd need seperate pots for each LED would you not?

audiocommander: What I got from reading the datasheet was that the 8 event control lines can only be used to trigger the 8 presets. In order to program the presets or do anything else you need to communicate over the serial connection unfortunately. My current idea for implementation is to make it an add-on module to any midibox that has it's I2C bus free (like most control surfaces.. not a SID or FM if I remember correctly). The host CORE module takes all MIDI data and forwards it along the I2C bus to the destination CORE module (that has no MIDI connection, only that I2C connection), so it can use it's free RS-232 RX/TX pins to communicate with the chip directly.

stryd_one: It's your home turf, so go for it :) nerd of nerds: monome is usb-based, I don't think there's going to be any direct connection between a midibox-based project and itself.

afaik seq24 is pretty unique in it's sequencing paradigm. Each pattern can be muted/unmuted individually to all other patterns - not like most sequencers (like mb seq) where there is one global pattern that is "the pattern" and you can mute out specific tracks or change pattern. In essence, though, yes, they are near equivalents in the sense that they are sequencers :) I don't necessarily see where monome (or monome clone based on mbhp, since monome is usb) would be useful with a midibox seq.. basically you'd have an individual button to trigger each pattern, and you could code it so that button lights up when that pattern is playing, but that's about it. Using it with seq24 would be cooler :).

Well, monome's a nice looking box, but you want it to *do* something right? Take a look at seq24, a linux-based MIDI pattern sequencer (http://www.filter24.org ). The way it operates is, you have a 2-dimensional grid of patterns that you can switch on and off on the fly. Mapping each pattern to a button on a monome-like controller would make for a very cool sequencer interface, since you can have each pattern be only a layer of the sound data (ie, a pattern specifically for you drumline, bassline, etc.) Seq24 already has support for toggling patterns using MIDI events, so it wouldn't be hard to get a button press on a midibox control surface to toggle a seq24 pattern on/off. Seq24 would need to be modified so that whenever a pattern is turned on/off it also sends a midi event to the controller to say "that pattern is now on", so the control surface can respond by turning on the proper LED. Add some cool features like having the LED's blink at the start of each midi event (or, say whenever a note is played on a specific channel, or whenever that pattern's note is played, whatever is not too bandwidth consuming) and support switching pattern maps (so instead of just 32 buttons controlling 32 patterns, you have prev/next buttons that switch the pattern map to the prev/next 32 patterns). That's my current idea anyways. Assuming my ebay auctions go as planned I should have parts for ~$100 including the already ordered kits from SmashTV's excellent service.

With slight work, you could make a monome clone to work with seq24 as a pattern controller for live use (my current plan :) )

Hi Thorsten, A pass message - great idea. When I was testing my SID that did not have a short, I only knew that it had passed due to previous knowledge with using the application. Same with the delay and other modifications. As for the "unexplained error" with your SEQ, it could be a couple things. One thing that I was thinking about is that some LCD modules might respond, since we are sending them data via raising each pin during our tests. So maybe it's responding? The only other thing that I could think of, aside from it being a short ;), is that it'd be due to the dual LCD's connected - I didn't look at the schematics for connecting two LCDs to check this, however. Funny story, when i was testing the application, I kept getting what I thought was a bug, like what you're getting with your SEQ. I stared at the pins and was sure that there was no short, and could not explain it (and was hunting the code and the PIC datasheet for an answer). Turns out there was a single strand of wire that had gotten caught and shorted the pins together, and I only saw it under a magnifying glass :) Cheers, Tom

Sounds great Thorsten! If it ends up being buggy/problematic then let me know and I'll remove it from here & the wiki. Note that the commented code is definitely buggy, for example if you uncomment it and attempt to debug all the pins on PORTC you wreck the UART pins and, like I said, crash everything in the midi chain :) If it provides a use I'll augment it to work the other applicable ports/pins as well.

Done. Filehosting is permanent as it needs to be.. I have a second host as well. If TK or anyone wants to mirror it, go for it.

LCD Short Test is a simple application to test if any of the data pins on your LCD connection are shorting. It does this by raising each pin individually and checking if any other pins are receiving the signal. Your best bet is to disable the power to the LCD module while you test this. That's best for it's protection and will prevent the output of false positives due to interaction with the LCD driver itself. Currently it does not test the 3 pins from PORTD that are on this port, nor can it tell if you are shorting against the backlight, power, or contrast pins on the port. Only D0-D7. Possible modifications would be to get it working with the other PORTD pins on J15, and get it to work with other ports. Note: Be careful. You can't do this to all of the ports, and make sure you don't, say, do it to the PORTC pins that are the UART Rx/Tx, since they are the MIDI connection :). I did this, and I crashed MIOS, the PIC, and my MIDI interface all at once! DISCLAIMER: You might ruin both your PIC and your LCD module. Use at own risk. Personally, I'd wait before using this until one of the senior members says that doing this is a good idea. How to read the output from the application: The shorts are reported via MIDI sysex dumps. I only ever use the lower four bits in each byte so as to avoid using the 8'th bit and confusing the MIDI driver. In the dump you will see the port (0x0b for PORTB), followed by two bytes, representing which bit we have turned on (ie 0xFE is 11111110 in binary, which means we've risen the first pin). Following is another two bytes, representing the readout on the port (again with the data byte split into two bytes for Sysex transfer). Let's say it's 0xFC, which equals 11111100 in binary. That means that when we rose data pin 1, it rose both pins 1 and 2. Therefore there is a short between pins 1 and 2! Full example: Sysex message is F0 00 00 0B 0F 0E 0F 0C Breaking this up, we have: Sysex header: F0 00 00 Port: 0B (PORTB) Risen pin: 0F 0E (0xFE, or binary 11111110, meaning pin 0 is risen) Port readout: 0F 0C (0XFC, or binary 11111100, meaning both pin 0 and 1 are receiving signal) Meaning: Pin 1 and two are shorting. Obviously you will always see these in pairs (in the above example, pin 1 will also cause pin 0 to receive signal). link: http://th0mas.sixbit.org/lcd_short_test_v0_1.zip Again: Wait until someone says that this should be a safe thing to do before running it. Cheers, Tom

Sounds like a bad connection to the LCD. When you start up do you see the MIOS copyright? by any chance did you also, say, close your case or move it around? Maybe you're pinching a wire or something like that. I know that my LCD is pretty messed up when I close my case atm ;). Does the device *work* and just not the LCD? Do you get a midi message when you turn on the module?

One thing to remember. In MIOS, if the CORE is responding with "upload request" during the file transfer, then the program is NOT being sent (even though MIOS thinks things are going okay and continues to send the incremental chunks until it is done). Only if you're seeing Checksum messages returned from the core is it actually receiving data from the computer. Otherwise check your MIDI in on your CORE.

Wahoo! :) I have a speakjet in front of me, but I (now) need either the MAX or another PIC.. I think I'll go with the PIC since it seems to be more versatile. Cheers, Tom

Hi TK, I have a question for you. In thread: http://www.midibox.org/forum/index.php?topic=2870.0 Someone brings up the use of a MAX3100 for SPI->UART conversion, and you mention that that IC might be the best solution for adding MIDI ports to MIOS. Behind the scenes did you try this and find it unsuitable, or is it still a possible method to get an extra UART connection to a CORE module? I've purchased a SpeakJet and am planning on hooking it up to MIOS. Cheers, Tom

D'oh! It's too slow as stryd_one predicted :( Oh well, I already have another plan for them - plus this was a great 'hello world' application for myself :D.

Oh, well, that goes the obvious answer :). I've never built or used an AIN board, but I can throw ideas around. Are the random MIDI messages on CC's that DO have pots connected, or are they from ones that don't exist and the AIN pins are currently tied to ground?