Wilba
-
Posts
3,310 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by Wilba
-
-
-
-
If the MB-SID wavetable could control all SID regsiters with each step, then you could quite easily turn a subset of the SID register dump into a MB-SID patch, just like HardSID... the only tricky bit would be finding the exact start and end of the desired sound... and even then it might not capture note-relative differences... i.e. maybe the filter cutoff varies with note pitch, etc. Anything that might be different depending on what note is played is not going to be captured correctly.
But again this assumes you could play back all SID registers. MB-SID's wavetable can only control three CCs. You could make a very similar sounding MB-SID patch by using envelopes and LFOs to modulate the pitch, pulse width and filter cutoff, but turning a set of discrete register values back into envelopes and LFOs is non-trivial ;)
What might be reasonably easy to do is write more perl script converters that can output the data a little more like MB-SID parameters, so the user can at least have a look, and manually set up the LFOs and envelopes.
One strange thought though: SID files get played back at ~60 Hz whereas the MB-SID can update at 1220 Hz! So even if you get the envelope and LFO waveforms to match, MB-SID is going to produce smoother modulation - any "sample and hold" artifacts from a ~60 Hz update will be lost, unless you also add in S&H ;)
Am I just dreaming to want to be able to play back the exact sounds of "The Last Ninja" or "Cobra" in my own compostion via midi? Is it all too hard??
Not too hard, just hard.
The SID register dump is in hex and it doesn't expand each SID registers into its component bits, i.e. the column labelled "WF" (short for waveform) shows SID register "Control Reg" (refer to SID datasheet) - the "4" is pulse width waveform bit, the "1" is gate bit.
This could be translated into more MB-SID friendly values, I agree ;)
But don't wait around for someone to do that for you... check out the SID datasheet which describes all the registers and what they do... learn hex numbers and decypher the "Cobra" sound yourself.
-
sorry to burst your bubble:
http://www.midibox.org/forum/index.php?topic=7626.msg52294#msg52294
;D ;D ;D
LMAO... I beat you by 45 mins... HA!
http://www.midibox.org/forum/index.php?topic=7675.msg52217#msg52217
;D ;D ;D
-
SID songs are really just a capture of the SID register changes... they're like the original "game" machine code stripped down to just the SID register update bits... and SID player apps (on the PC side) are basically a mini-C64 emulator.
So turning a sequence of SID register changes back into envelope/LFO/wavetable parameters automatically is hard... but there are tools to help you do it manually.
You can capture a sequence and play it back, and the HardSID software let you do this, so I go a-hunting and found this for you ;D Mechanicus Guitar Patch Tutorial
So if you're clever enough, you can identify which bits are setting the oscillator and filter configuration, and which bits are setting a pitch and gating oscillators (i.e. starting a "note") and then which bits are modulating the modulateable? bits after the gate. If you're up to doing this a bit more manually, check out TK's tutorial on ripping C64 sounds by looking at the SID register changes.
-
I bought a crimping tool a while back (on the recommendation of another MIDIBoxer- hope they'll forgive me for not remembering who they were)....
It was probably me ;D
-
I heard that Futurlec takes about 2 weeks before they ship... I'm unfortunately at 20 days already, and it's still sitting at "Order Entered". ARGH. It was either $80 at Futurlec, or $220 at Digikey, foolish me thought that waiting a couple of weeks wouldn't be so bad.
There's nothing wrong with nagging them... 20 days is quite a bit over. Just remember if they start ignoring your emails then get your money back on your credit card ;)
toneburst: those pins look right to me too... and while you probably won't rush out and buy a crimping tool, they're well worth the $10 and save a lot of cursing. Just make sure you buy lots of spares as sometimes you make a mess of the crimping and you can't reuse it...
-
I didn't think it would work, but I just successfully burned a PIC16F88 with my trusty old JDM burner and WinPic800. Haven't actually tried the IIC MIDI app yet, but it verifies OK. I added an 18 pin IC socket to my JDM and wired it up like the adapter published here.
I've also burned the PIC18F4620 successfully as well... so if you have a JDM burner that worked fine for PIC18F452 chips, then give it a go with the other ones and you might not need a new burner!
btw, WinPic800 is really fast too... I don't know what magic it does, but I've had none of the hassles I had with IC Prog...
-
No I didn't... ;)
I actually bought a whole lot from Futurlec, but alas I've ceased recommending them after the last order was bungled so badly and they stopped replying to my emails and then I got the credit card charge retracted... *evil laugh*
It's a pity cos they had good prices for these kinds of things which have such a stupid markup from local distributors.
-
Thanks for that info, Roter!
I'm still not clear about how the SID could get fried.
If the audio in is open, the capacitor doesn't have a ground, so how can it charge up?
I still believe though that if the audio in was permanently tied to ground, before inserting the SID and turning on, then you would never have a problem. In fact, if you always have the audio in tied to ground, it makes that extra 100K resistor redundant.
But if the later C64 schematics have that 100K resistor tying the audio in to ground, then it can't hurt to add it in.
-
It sounds like a good idea...
I've just finished my new MB-SID front panel PCB and I can give some advice.
It's possible to make a PCB footprint that can take the ALPS 16mm encoders or the smaller Bourns or ALPS ones... since the pins aren't overlapping you can add tracks to support the differences in pinouts as well.
Some people would be happy with TK's placement of the encoders (they aren't perfectly aligned with the "steps" on the 2x40 LCD) whereas some people (like me) may want to use smaller knobs and place the encoders exactly aligned with the "steps". One of the advantages of getting a PCB made is you aren't restricted to 0.1" (100 mils) alignment so you can align the encoders exactly to the steps. Either way you go on this, you still have to choose a "standard" 2x40 LCD size (they're not all the same!) so that the front panel cutouts are the right size, and the mount holes on the PCB are right.
Getting the right knobs is the biggest hassle, I've found... TK's design uses knobs from www.albs.de which are relatively cheap (I think 0,60 EUR?), and the front panel holes are bigger than the knob diameter so they poke through the panel. This I assume makes the construction easier, you can mount encoders, buttons and LEDs all on the one board. Basically if people are going to use a standard PCB and panel, they will also need the right knobs to suit. Same with buttons and button caps.
One final point: After seeing Rigo's ingenious use of JB Weld here, I plan to use this technique to mount my PCB to the panel and provide lots of support everywhere... I plan to use threaded metal spacers (looks like a 10mm tall M3 hex nut) and glue these to the panel and then mount the PCB to these. So maybe you don't need to drill mount holes in the front panel - people can use this trick to make mount points where they want them, and this might help accomodate slight differences in LCD dimensions, etc.
-
You might want to read the thread about Feedback Loop on SID ... the link presented: Commodore C64 Modifications :: Adding A Feedback Loop also discusses the grounding of the input pin for low noise, on the next page.
Also, the SID module has a capacitor between the SID input pin and port J4 (the audio in port) and you "ground" the audio in at J4, not at the SID input pin. This is supposed to protect the input pin. Since this is an input pin, I can't see how that pin even if it was tied directly to ground could cause any problems... there would be no current going into the SID, and no current going out. I don't know the specifics of how other people have fried their SIDs... where are these tales of tragedy? Post some links please!
I have plugged and unplugged a lot of 8580s and 6582s into my PCBs which have the audio in pins bridged (i.e. always grounded) and have not fried any SIDs because of this. I've even listened to the noise go up and down while grounding/ungrounding the audio input, and still not fried a SID this way.
So stop worrying ;D
-
This is a great idea, Smash!
I suggest even putting on a test app that might assist people getting MIDI communication going.... like MIDImon perhaps? That might be a really easy way to prove the PIC is receiving MIDI, with any old MIDI hardware you have... so if you have trouble uploading new apps, you can start the debugging at the PC end instead (i.e. MIOS Studio, MIDI drivers in Java, MIDI interfaces, etc.)
-
another tip: put the PIC in a spare IC socket (assuming you use the cheap ones, not the expensive machine pin ones)... this makes it easier to insert and remove from the PCB as well as preventing the pins being bent. An old trick from when I was constantly moving PICs between PCB and burner.
You should also get an IC removal tool... just a cheap one that looks like a really wide pair of tweezers... I can't believe I went so long without one, cursing every time I had to pull an IC out... if only to give the SID chip some respect, get one ;D
-
Good to hear!
Just to recap: you swapped the two optocouplers around, so now the SmashTV PCB (which previously was giving the frame errors and overrun errors) is WORKING? and the Mike's PCB which was only sending out upload requests is unchanged?
You really should swap the optocoupler back and prove it's really the optocoupler (you seemed to think reseating the optocoupler was the cause, highly doubtful, but make sure anyway). Put a big tick on the "good" optocoupler!!!
So Mike'S PCB is broken in another way. It's hard to know how, since you had the "good" optocoupler in there, and the PIC which was eventually proved to be good, and the loopback test passed... since it's sending upload requests, the PIC is powered and oscillator is good... maybe it is continually resetting? Check power supply I guess... and all solder joints around the optocoupler, TX, RX pins...
The best news is, you now have a working PIC + Core PCB + MIDI connection. This makes debugging the second Core a lot easier... because you know what the bug CAN'T be...
Now that you have MIOS on the PIC, when you put it in the other PCB, you should only get ONE upload request, and you have 2 secs to upload a new MIOS, or you can upload an application at any time. What this means is when you put that PIC in the other PCB, if you keep getting upload requests you know the PIC is resetting itself for some reason... I guess you could also try the LCD in the other PCB and check if it's "READY" also...
-
well in theory, if you receive the upload request, this sort of proves that the PIC is running and its UART is set up with the right baud rate, etc. since your computer is receiving it fine. There are configuration bits burned into the PIC so the bootloader and MIOS know whether to use standard MIDI baud rate or the alternative serial port baud rate (and more recently, whether to use IIC_MIDI instead).
What I'm confused about is the frame errors and overrun errors... because I think they imply the PIC is receiving at a different baud rate, or with serious bit errors... but your loopback test proves that at least your MIDI interface sends and receives at the same baud rate without errors... hmmm...
I was theorizing about the oscillator... it's definiately working or you would not receive upload requests at all.
If I were in your shoes with what you have at hand, I would get one of those experimenter boards, in Australia they're called "Wish boards" (brand name), I guess they're also called breadboards... they're white or cream coloured plastic boards with lots of holes in them that you can insert components into without soldering... then I'd make up a Core board with that... I guess this assumes you have enough spare bits lying around...
What you'd end up creating is the bare minimum to get the Core sending and receiving MIDI, which is basically the 5v supply (7805+caps), the crystal and its two caps, the optocoupler bit and the MIDI sockets... and also 100 ohm resistor tying the reset pin to 5v.
OK, it's a big ask I guess, if you're not really into electronics or have the extra bits lying around... but if you're keen to keep up the hobby and make more things, one of these experimenter boards are very cool to have around, you can easily whip something up to test circuit ideas etc. or even just test LEDs or chips...
Back to the issue of the two boards giving different error messages...
Can you swap the optocouplers and see if the error messages stay the same? i.e. if they swap their error messages also...
I know both PCBs passed the loopback test but it might be useful to know if one optocoupler produces errors the other doesn't.
-
well if the loopback works, then I guess it has to be the PIC not working properly... either its oscillator/clock is bad somehow or there's still the chance that the MIDI interface is at fault.
You've basically validated the electronics and wiring between PC and PIC... so now it's just a matter of either end being the fault (although there's still the change the PCB is at fault)... At this point, (if it was me) I would be trying that PIC in another known-working Core, and trying a known-working PIC in the non-working PCB... this would identify if it was the PIC or the PCB.
-
Sebo is right, but the versions he speaks of are out by one :-)
In a multi-SID box (V1) you can have each SID on its own MIDI channel.
For a single SID, I think TK said once that you can assign each of the three oscillators its own MIDI channel, but this was only configurable from SysEx, not from control surface, and I can't find out how to do this from the documentation.
In V2, it is planned that you can do this a lot easier, and one SID can have three single-oscillator "mini" patches for a C64-like sound.
-
You've copied the MIDI output log in the first post, not the MIDI input log...
OK so the last log from SmashTV's PCB... I assume you're using MIDI sockets soldered directly to the PCB? That would eliminate any MIDI socket wiring mistake perhaps, leaving just the issue of soldering joints, optocoupler or PIC... the fact that you're getting frame errors and overrun errors indicates that the PIC is receiving something, otherwise you would ONLY receive upload requests.
NOTE ALSO that the bootloader will reset after each frame error or overrun error, and so you will receive another upload request after each error.
Try this test again: http://www.ucapps.de/howtodebug/mbhp_core_extract_io_loopback.gif
What you're looking for here is an echo back of what you send... TAKE THE PIC OUT OF THE SOCKET and short the TX and RX pins (just shove a bit of wire into the IC socket!)
In MIOS Studio, if you compare the MIDI In and MIDI Out windows while trying to do an upload (you will have to start the upload manually!) then they should be the same. This will validate the optocoupler, the MIDI In and MIDI Out wiring, and hopefully your MIDI interface.
You should try this with both PCBs and see if you get the same results.
Don't assume that since you've done this before that you don't need to do it again! GET NEW RESULTS! Oh, and unplug that LCD and everything else, just power the Core PCB...
OK so assuming you get good loopback, then you can basically assume that the PCBs, optocoupler and MIDI wires, cables, etc. are all good, and move on to debugging if it is the PIC itself that is the problem or the UARTs on either end not talking nicely (i.e. the PIC's oscillator is not right, it's UART not set up correctly somehow, bad configuration bits burned on the PIC)...
Did you burn the PIC yourself? It's definately a PIC18F452? Is the SmashTV PCB built completely from a SmashTV kit? Just checking ;-)
ANYWAY from what you've just posted, the fact that the two PCBs do different things implies that there's more than one error... i.e. each PCB might have a different soldering fault, or one has a soldering fault and the PIC is also faulty, etc. Do tests on both to see what is different... as this can highlight specific issues with the PCBs perhaps...
-
I had a closer look at your last posted upload message log...
Starting upload of mios_v1_9c_pic18f452.hex
Hex file contains code in MIOS range, forcing reboot!
Received Upload Request
Received SysEx message of less than 8 bytes
Sending block 00000400-000004FF
Received error code 0C: MIDI IN Frame Error
This was an expected error - please ignore!
Received error code 0C: MIDI IN Frame Error
Received SysEx message of less than 8 bytes
Sending block 00000500-000005FF
Error: Received unexpected Upload Request
Sending block 00000500-000005FF
Error: Received unexpected Upload Request
Sending block 00000500-000005FF
Received SysEx message of less than 8 bytes
Received unexpected MIOS SysEx message = 40000140000E0C01F7 expected = 00007E4000
Received unexpected MIOS SysEx message = 40000140000E0C01F7 expected = 00007E4000
Received SysEx message of less than 8 bytes
...
Aborting after 16 errors
This was strange to me:
Received unexpected MIOS SysEx message = 40000140000E0C01F7 expected = 00007E4000
MIOS Studio reports receiving a "MIOS SysEx Message" so the complete message would have been something like:
"F0 00 00 7E 40 00 01 40 00 0E 0C 01 F7"
which looks suspiciously like two messages merged, the upload request:
"F0 00 00 7E 40 00 01 " (missing "F7" at end)
and a frame error:
"40 00 0E 0C 01 F7" (missing "F0 00 00 7E" at start)
Now this could just be a dodgy "merging" of SysEx messages in the Java MIDI drivers... or maybe something wierd on the PIC... I don't really know... but you should at least try using MIDI Yoke routing tricks to see if this at least gets rid of the "unexpected MIOS SysEx messages" so all you get are just framing errors. Similarly, these "Received SysEx message of less than 8 bytes" suggests there's something wierd going on in the SysEx receive buffers... that some kind of merging is occurring... hmm...
Can you try using MIOS Studio and also post a dump of the MIDI In monitor as well as the upload log?
So let's for a moment assume the framing errors are valid. The framing errors might be happening in two directions - bytes might be dropped from PIC to computer... perhaps a cause of this merging
Framing errors might be happening if the baud rate is not the same between the PIC's UART and the computer's UART. Since the baud rate is relative to the PIC's clock, and thus it's crystal and oscillator configuration, if the crystal is dodgy then that might be the cause... or even if the PIC's configuration bits weren't correct... the computer's UART might be tolerant of the PIC sending data slighly out of sync...
The other possibility is that the PIC is receiving data but due to a faulty optocoupler, wiring, soldering or PCB fault, the bits it's receiving aren't right... the start/stop/parity bits of the serial data are wrong, the UART can't make sense of a random bitstream and throws up framing errors.
-
I've been lurking a while... might as well add my 2 cents (and a fresh pair of eyes)
Hiya,
I know answering my own post seems a bit like talking to myself, but here goes anyway...
Explaining something makes you fully understand it. And it's cathartic.
Tried the send/receive SYSEX loopback test in MIDI-OX. Fails with both interfaces (I get an error message saying something like 'the port is trying to send something, please wait until it has finished and try again'). A couple of times I have been able to send and receive a SYSEX file, but not all the bytes sent have made it back to the MIDI input.
Just to clarify, exactly what "loopback" test was this?
Did you plug a MIDI cable directly between MIDI In and MIDI Out on your computer's MIDI adapter?? If you've done this, confirm you get "local echo" (play some notes on the keyboard, or send SysEx or parameter changes or whatever, and confirm the MIDI In and Midi Out monitors show the same stuff).
MIOS Studio is written in Java and some people have trouble with the MIDI drivers in Java, and suggest using MIDI Yoke to solve the problem... creating a routing between the "virtual" MIDI Yoke ports and the real MIDI ports.
Did you confirm the ID programmed in the PIC is the same as the ID you are using to upload? (You've probably checked this, the PIC's ID is sent in the upload request).
I feel sorry for you and know how frustrating it can be to debug something like this. You can always post the Core to me and I'll confirm it's a PIC or PCB issue and not your MIDI interfaces!
-
In that datasheet, the asterisk next to the "A" in the pinout is matched with the asterisk next to the "LED weiß Voltage", indicating that when it is a white LED backlight (i.e. white on blue LCD, etc) then you only need 60 mA and the voltage drop is 3.5v not 4.2v.
I'm no expert either, I'm only highlighting a possible mistake... and it wouldn't hurt to use a bigger resistor, whereas you might burn out those white LEDs if you use one too small.
-
The Core has a circuit for controlling LED backlight current, it is usually connected to pins 15,16 of the LCD as per diagrams. Why don't you use this?
Second, the white LED is 3.5V forward voltage... typically white LED backlights are only on the edge, not an array all around the LCD... hence the two different forward voltage specs (3.5v and 4.2v).
SO I suggest you double check that 13 ohm resistor! You might be powering the white LEDs at 115mA!
-
You set the MIDI channel in the "CFG" submenu (parameter "Chn")
Anyone built a MidiBox 64 and lives in melb australia?
in MIDIbox HUIs
Posted
I live in Melbourne, and so does stryd_one... I haven't build an MIDIbox 64 though but can help you out with finding parts.
Rockby Electronics have A LOT of good gear at good prices... I went there yesterday and the guy told me about their unadvertised "warehouse" they have next door... it was full of clearance items at ridicuoulsly cheap prices.... stuff that would make a MIDIbox builder drool... all kinds of switches, rotary pots, slide pots... whole tubes of 74HC4051 (like 24 in a tube) for $2.50 (that's what you need for the AIN module!), lots of nice aluminium knobs, screws, rack mount gear, cases, etc.
Other good vendors locally are Crest Technologies and Switches Plus, both can give you some of the exotic stuff like encoders and LCDs and PLED displays.