stryd_one

Sounds about right to me. jw: by your description it seems that you are not receiving a duplicate message, but a message corresponding to the neighbouring pin. You only explained the behaviour of one pin, so it's not clear whether Shorting pin5 also triggers pin6, shorting pin6 also triggers pin5 or Shorting pin5 also triggers pin6, shorting pin6 also triggers pin7 Which one it is, will tell us a fair bit...

Corrected ;D

Now youre getting there ;) There's info for your mac in the application development section of the wiki, and the readme files in the mios_base package. Cheers!

Heheh thanks for the info man.

Yeh my bad man, I dunno why I thought it was full-speed. Now that I searched it I have found a few references from TK that it's 400k. Look forward to seeing the mod!

Thanks TK :)

Ahhh yes the pictures say it well :) Sounds like you're well on your way man, good luck!

Thanks man... Wet or dry?

Fair call, I think we've both had enough of that! On the electronic side of the of analysis tip, I can't help but wonder what exactly it was... I dunno if you read about it, but apparently they magically started working again the next day... so obviously it wasn't really locked up, *something* (the RTC apparently) was still ticking away happily. Interesting that it didn't go crazy on Feb 29, but on new year's instead... I guess there's some counter or something in there that only goes up to 365 days :D Makes me think about error handling though. I mean let's put this in a midi context... Say you have some function for setting a midi channel, which accepts a char as a parameter: signed char SetChannel(unsigned char newchannel) { } Seems fine, but, there's no such thing as channel 255 ;) So I mean you can do stuff like forcing the input to a legal value like signed char SetChannel(unsigned char newchannel) { if (newchannel > 15) newchannel = DEFAULT_CHANNEL; foo(bar, newchannel); return 0; } or Limit it signed char SetChannel(unsigned char newchannel) { if (newchannel > 15) newchannel = 15; foo(bar, newchannel); return 0; } wrap it around signed char SetChannel(unsigned char newchannel) { if (newchannel > 15) newchannel -= 16; foo(bar, newchannel); return 0; } wrap it again signed char SetChannel(unsigned char newchannel) { newchannel %= 16; foo(bar, newchannel); return 0; } Etc etc... But, say you want it to fail, and return an error? signed char SetChannel(unsigned char newchannel) { if (newchannel < 16) { foo(bar, newchannel); return 0; } else { return -1; //return an error code if the requested channel is invalid } } OK you can have it pop up a message on the LCD, or send an error code via sysex or whatever... But then what? I mean, what if some other function depends on the success of this one (as in the case of the Zune 30G heh).... Then you have to test for this function's success... And what if that fails? That line of "what if that function fails?" could lead all the way back to the main loop of the app, and prevent it from running, or prevent it from returning to the main loop. Is there a "right way" to deal with this, some kind of a standard or convention (official or otherwise) or is it just a matter of adjusting for the specific needs of your app, or a bit of both, or what?

I thought that'd kill the finish, but it looks like it was blank. Nice one :)

Nice 1. How'd you get the silkscreen off the panel?

Shouldn't that be a rule of finger? ;)

It's not "happy" at all for the vast majority of the human race mate :( Most people fail to realise the extent to which capitalism/democracy is flawed. Sure it looks OK from where we're standing... That's because WE are the bad guys. (as exemplified by BF's reaction: "Hey you're killing my buzz man, don't talk about the world's problems, I'm busy trying to drown those out with entertaining toys") Take it to a 3rd world country, where you make as much in one day as a whole family makes in a year, and try saying that again.... Hell, just take it to the ghetto in your local town. Tell it to the homeless people where you live.... Tell it to the girls selling their bodies to eat.... I do think capitalism is the best system we've seen so far, at least in the modern world... But do we stop making computers because the one we have now is the fastest one yet?

Heheh, yeh there are good reasons to hold onto your old machines. Especialy now that real serial and parallel ports are being phased out, but still widely used :( What adapter does it say to use? If your programming voltage is correct, and the LM317 doesn't get too hot, you should be OK.

That's what I thought: +5V is connected to analog ground somewhere.

Nice!

Heheh no surprise there... Got an older *desktop* PC? That's your best bet... In the BIOS config for your motherboard. See, I *knew* you'd already read this thoroughly :) Very observant... Weird! Why do you think the cable is OK? The strange timing behaviour might be a noise thing... Which could likely be your cable... Burner gurus where are you? :D

Sorry mate I didn't mean to freak you out! I wouldn't be too concerned about it, it's a slim risk... it's there though. I think the odds of a problem are currently several thousand to one. That's an unusual supply but hey, if it's good for MFOS... It does say though: Make sure the wall wart outputs between 300mA and 1000mA. ....strange to specify an upper limit, as the supply should only supply whatever's drawn.... I dunno... Mate if I were you I'd do a lot less experimenting, and a lot more waiting patiently for seppo. :D

Need? No. I would though, for the primary reason that if you're cloning something you clone it ;) (anyway I guess it's a bypass cap and that's good) Guess so: http://www.muzique.com/schem/caps.htm Google is good :) Hey, you chose the XLR connector, you tell me! :D I would find a way to connect the cable shield, if that's what the original does. (clone, blah blah) I don't think it matters in this case, the rectifier will take care of it anyway....

LOL. I gave up asking angel to DIY a long time ago.

Remember it's festive season, so it might take a while before anyone reads your post and answers, and there are lots of people with burner modules. That said, not many people have used this chip.... Maybe you'll have to solve it yourself... I haven't got a burner or used this pic, but I'll give you what I do have: Tried another PC? Some parallel ports just don't like to work. What about, as phil said, trying different parallel port modes? Were the results the same in all of them? You mentioned you'd done the voltage testing, without the HC11s loaded. I paused on that last time, but it seemed you'd been doing your reading so I didn't need to double check... I thought after it was still not working, I'd better, so I checked the ucapps.de page, and I didn't see anything about testing with them removed. If you concur, maybe try testing the voltages Timing: Interface x16 / PIC x3 is that the verry lowest setting for both of those two timings? Did you try that testing procedure on the page you linked? The one with the hardware adapter? What were the results? Got a new cable? It's interesting that it is able to detect that it's a PIC chip in there, but it looks like it goes all 0's when it tries to talk to it. I'd be doing some research into the detection method used, and also how the ID is sent. Err, I dunno....

Rant: I've been saying for years now: Thanks to capitalism and it's offshoots, we pay the lowest rate possible for our engineers, and give them as much work to do as they can possibly endure, in the shortest possible timeframe. That's the sort of thing that results. Common examples are smartphones which crash daily, the fact that gnome desktop and firefox have crash recovery now, etc etc. I'm sure you can think of some of your own. I've also been using the example that one day it will happen somewhere serious, and possibly cause loss of life or injury or %badthings. Seems I was right: http://www.abc.net.au/news/video/2008/10/15/2391330.htm I actually guessed that one was a firmware malfunction before it was confirmed by the ATSB. The airline tried to cover it up by blaming it on interference from an electronic device on board, which got heaps of airtime, including a full 10-minute timeslot on a popular current affairs TV news show. And of course the incident was not the hot news topic by the time that the investigation was complete, so not many people realise that was total speculation/BS/paid advertising. The fault was somewhere (they don't say where, but you can figure it out) between the triple-redundant inertial sensors (like accelerometers/gyros, they tell the computer which way the plane is flying) and the completely non-redundant flight computer they all connect to. So, obviously, this was a firmware fault on that computer (unless all three inertial sensors had the exact same fault simultaneously, very unlikely). I should also add for you air travellers, that this was nicely covered up, and somehow airbus were not forced to ground all models of aircraft running this firmware until it was repaired, as is the standard response when a serious fault is found. I should remind you that airbus were receiving terrible publicity at the time. Cover-up anyone? Oh - also the same systems are used on boeing aircraft. Essentially, to really fix this, means a firmware upgrade for nearly every large airliner in the sky. How much do you think it would cost to ground them all until that's done? Ahhh, the mighty dollar. You get what you pay for ... or ... what you don't ;) I might also add that without capitalism/patents/competition/etc we could have a common database of working implementations of software/firmware/etc, which would be used by all manufacturers, and screwing up leap year dates would not happen. It's only because the Zune devs have had to make their own implementation, that they made this small oversight.... The really sad part is, you can bet your ass that some hardworking zune dev will get his ass kicked for this, and the company directors that shell out the workloads and pay rates will get off scot-free. Grr.

I wouldn't recommend trying non-standard connections unless you really know exactly what you're doing. There is a risk of frying components. Follow the schematic bugfight linked to and the pinouts I posted, and it will be correct. Huh? It's not supposed to work like that. Digital power (5V unipolar) goes into the core. The connection between core:j10 and aut_ng:j1 gets this digital power to the aout_ng board. Analog power is a different issue. Separate wallwarts is not recommended, ground shifts can cause damaged components. Perhaps the power supply is where you guys are failing. What PSU did you plan to use?

Sorry for English. Hendrik asked about this in the chat but I missed him and didn't get to tell him the answer... Download the new zip and setup the new toolchain: Quick Start Guide Toolchain Setup midibox_lc_v1_6c.zip Enjoy :)

response_t foo, bar, humbug; :D