Hawkeye

Looks great :-) You may need to ask Thorsten, how it is wired up correctly, as I may have forgotten it by now (or never ever completely understood it :-)). I have a working prototype in my drawer though and a high-res cam :) The display itself is great, has high contrast and a very stable image, even when viewed from the side at an angle. Greets! Peter

Hi there,. got all LED digits (Kingbright LED digits with shared anode - SA52-11GWA) parts yesterday and just started to build it, but I have a problem... Wanted to first build the BPM display and have enabled it on shift registers SR 9 - for segments with 220R resistors and SR10 - for the common led-digit anodes, soldered in eight bridges instead of 220R resistors, using pins 7-4, as described in the pdf documentation. Unfortunately, whenever I attach a LED digit to a shared anode 7, 6, 5 or 4 on SR10 and connect the segment pins to SR 9, all segments are constantly on (quite dim)... When I change the BPM and its third digit switches (e.g. from 130.9 to 131.0 bpm), all LED segments get brighter... so, something is happening, but somehow it is messed up :) - the behaviour is also independent of which common anode pin I am using (as long, as it is 7-4). What is most interesting, is that when I attach some LED digit segments directly only to the four pins on SR10, (also the anode, just wired up three random segments and the anode to pins 7..4 on SR 10), different segments are turned on, and stay turned on, when I change the BPM. So, clearly something is going on, but I don´t understand what :-) - could it be, that the anode/segment shift registers somehow have swapped behaviour? Here is the config: ################################################## # Optional BPM digits ################################################## # set to 1 or 2 to enable the 3 optional BPM digits # 0: BPM digits disabled # 1: BPM digits with common cathode # 2: BPM digits with common anode BPM_DIGITS_ENABLED 2 # define the DOUT shift register to which the segments are connected (0=disabled) BPM_DIGITS_SEGMENTS_SR 9 # define the DOUT SR and pin to which the common pins are connected # we are counting from right to left # Example: 140.5 BPM: (COMMON1 = .5, COMMON2=0., COMMON3=4, COMMON4=1) # SR Pin BPM_DIGITS_COMMON1_PIN 10 7 BPM_DIGITS_COMMON2_PIN 10 6 BPM_DIGITS_COMMON3_PIN 10 5 BPM_DIGITS_COMMON4_PIN 10 4 Thanks for any help! Greets, Peter

Hi - nice pic! regarding 2), Thorsten has just added support for a direct BPM-changing encoder in RC .51 :-) regarding 3) - the left/right keys move you to the left and right - you can then use the standard encoder to change the note. Good luck hacking the displays, it can be fun and rewarding at times and at other times grey-hair accelerating :) Greets! Peter

Nice FM sounds! ´tis brings soo back the 90s "Soundblaster Pro" memories - in a good way! Greets! Peter

For me, knowing to have some 25+ year old sound chips, that have certain (very hard to emulate) imperfections, is half of the fun. Thinking, that these very same chips have played the tunes of Hubbard/Galwyn/Huelsbeck to the total awe of us 80ies computer kids (me was one, too) is the other half :). They have souls. And you put them in your gear. How much better can it get? :-) The SIDs have some unique imperfections,e.g. some internal distortion when all oscs are active - very hard to simulate... also, when emulating the filters digitally, there might be some harsh "aliasing" tones... which you could offset with a nice analog filter to achieve "perfection" again... but then... was it ever "perfect" ? :-). I like the filters of the SIDs a lot... no, more than a lot... they are imperfect, with audible "dents", but that defines their character :-). Personally, I think the SIDs will still last for a while (the prices will rise, though - good investment to stock some). There have been many, many C64s. Greets, Peter

Thanks :-)

Well done - looks very good! :-) Its near-identical (but more hot-blooded) twin says "Hello ´Bro :ahappy:" Greets, Peter

Hi Ultra, Thanks! As soon as my seq is done (TK. helped massively lately, thanks!), i will concentrate on this, promised :) Regarding the datasheet: here you go: http://www.newhavend...2-25664UCB2.pdf There are also two slightly differently sized versions available, both being a 256x64 oled with 16 shades of blue/yellow. Regarding the fonts - everything is possible, even differently shaded (and antialiased) fonts... Using a 8x8 font, you could fit tiny 32x8 characters (which would be great for a multichannel "tracker", old amiga noisetracker style, btw. :), ) also possible would be something like 20x5 characters (12x12 px font) plus some leftover border pixels or better legible and smooth-looking 16x4 characters (16x16px) ...it totally depends on the project! Regarding graphics access... it is quite easy... you position your "cursor" and then write 2 bytes (4 pixels) "en bloc". The cursor then advances to the next 4-pixel position, so for a full bitmap dump, you need not reposition the cursor manually. Using double-buffering and this buffer-copying technique, it was possible to yield 30 fps on the display with some calculation in the background (voxel space)... On the other hand it is difficult to manipulate a single pixel, as there is no read access... you either have to know what the neighboring 3 pixels look like (big memory buffer, bad) or you write everything... Which is totally ok for bitmaps with a width of a multiple of 4. To be honest, it needs to be said, that we would need moar testers for this display, as we had certain initialization problems at first (and the newhaven tech docu is not, ahem, gold quality :-)) Also, as the price is really ok, one could drive more than one display, depending on the projects needs. Greets! Peter Edit: here is a picture of a "pattern" demo, so that you can assess the "16 shades" better: http://img228.imageshack.us/img228/6641/mg9659f.jpg

really great, yeah - good quality for zero bucks :)

Nice one, Altitude, new food for the machinedrum... i´ve also got some more freebies: Spunkface samplers (good stuff): http://spunkfacesamplers.com/freebies/ And drumsamples.org: http://www.drumsamples.org/ Greets! Peter

Yes, build a new one - the old ones are unreliable... I would have documented building mine, but don´t want to collect bad karma points, when people are electrocuted when following the doc... :-( You can build one of these: http://www.retro-don...wernetzteil.php and it will work very fine, if you a) place the voltage regulator filtering capacitators very close to the 78S05 b) add a second 2200uf ripple filtering capacitator in parallel pics: Just make sure you take care when operating with high voltages and always unplug the psu before working on or near it. Greets! Peter

Very, very cool! Thanks!!! Hope to provide test results, soon! Greets, Peter

Yes! Sounds totally mad scientist style! :-) Love the sounds @ 0:28 - a lot like old "The Prodigy" - quality :) Greets, Peter

Very nice - sounds like you had some fun :) I really really like the section around 0:45, until the distorted drums kick in - but that is personal taste :) Greets! Peter

You can haz my order - have grown used to the blue vfd (with glass screen very close to the panel) by now :) Greetz! Peter

Yes, sampled my gf from all positions in the holidays :) Unfortunately, i ain´t got moar sids in the drawer - got enough bad karma points for ripping C64s already :-)

Hm... do you have a use example? I mean, do you intend to read the full files... or do you want to read from many files incrementally? Would memory buffering be possible (and switching to the next file, when the buffer is full)? You could always concatenate file data on an external platform and use seeks within a large file to avoid opening up multiple files... "Fake files" within a large file, so to say. Also, it would be interesting to know how much time it really costs to close and open a file on sd memory media... Greets! Peter Edit: Sorry, did not properly read... a sample-playback engine... I think, somebody already tried that on a Core32, but if I remember right, there were speed problems because of SD latency... maybe a forum search might help. Cheers!

Ah, interesting... me thinks I should update mine - last time I compiled, everything was fine :-) Have fun coding for MIDIbox - it is really nice! Greets, Peter

Yes, using a 5V switcher on the 5V "logic" (not audio) chain seems plausible and energy-efficient, but aren´t the 5V and 9V added together in the 6582, for Power Option "B" (when using 6581 12V SIDs). In this case, you´d have "switcher" input for the SIDs on the audio chain... Of course, you could go with power option "D", as technobreath suggested... and supply everything from the outside... Or stay with power Option "A" and use the suggested solution (but then, only 9V SIDs and it is not a "universal PSU", again). Greets, Peter

Hi & welcome :) regarding 1) if everything else works, don´t worry 2) you need to adjust for LPC17... these settings are for the old STM32 core... here are my environment variables for reference... export MIOS32_FAMILY=LPC17xx export MIOS32_PROCESSOR=LPC1768 export MIOS32_BOARD=LPCXPRESSO Greets! Peter

Hi Falk, Brauchst nix von Doepfer :-) MIDIbox = sehr einfache Modulbauweise... Schau mal auf ucapps.de und guck Dir das LPC17 Kernmodul und das DIN Eingabemodul an - daran kannst Du Deine ersten Taster/Encoder (keine Potis, dafür gibts AIN) anschliessen und loslegen :-). Ciao und viel Spass! Peter

What t´breath said is all true. Just here to let you know that the slightly modded retro-donald design works great and is even better regarding noise than the original psu: Greets, Peter