Hawkeye

Had to test that new-old scope from ebay :) Thanks for listening! Greets, Peter

Yo, TB - i used this one: http://www.reichelt....T=0&OFFSET=500 one output goes directly to the C64 9V AC plug pins, the other through a rectifier to a 2Amps 5V vreg attached to a *big* heat sink, protected by a crowbar. Add a few fuses and you´re good to go - i know you can do moar protection stuff in the PSU, but it will suffice for me :-D

hehe, send me one, i´ll gladly scope it :) (edit: i´d be upset if this thing was silent, mah self-built linear cost at least 30€ :frantics:)

Hi there, it is your choice, but I would recommend to have better separation, all glued together by main, to keep inter-module dependencies low: your main.c module includes square_font.h, creates a pointer to it, includes font.h (for rendering) and gfx_1322.h (for output) the font pointer is passed to functions in font.c, with the to-be rendered string and renders to a render buffer (with 16 shades of grey) that buffer is then passed to gfx_1322 (or any other low-level gfx engine) to be output on the screen. possible function calls in main.c: u8* buf = create_buffer(256, 16); // Allocate, clear and return a 256*16 pixel square output buffer (that can hold 16 shades of grey) = 2048 bytes character* font = &superpoint_square; render_text(font, "midibox", 8 /* chosen brightness */, 0, 0 /* in-buffer coordinates */, buf, 256 /* buffer width */); display_buffer_1322(0, 20 /* screen coordinates */, buf, 256, 16 /* buffer width & height */); free_buffer(buf); Bye, Peter

Hehe, thanks & have lots of fun building it :) You will love it! :)

Sauraen, there a specialized VSTIs, that can render classic instruments nicely, but they will not be free - I´ve seen really nice Piano and Violin "emulators", impressive stuff... but quality comes at a price :) Bye, Peter

Great progress! I´d recommend to roll font.c on your own, and let it render a rectangular area to a memory buffer (like the voxel demo), which can then be put to the screen by specialized routines written for different displays (and thus be reused by MIOS users with other graphical displays). It is a kind of an abstraction layer - font rendering is generic, putting the rendered buffers to screen is specialized. Possible module layout idea: font.h/.c (generates rectangular bitmaps, ready for outputting to screen, takes a user-supplied character array pointer - to choose the font) gfx_1322.h /.c (general purpose gfx routines for this oled, such as outputting a rectangular buffer to screen, putpixel, setpixel, line(), etc... ) Also, I´d put special things like meters, virtual "knobs" like the machinedrum display has, etc. to different modules, as they have nothing to do with a font, they can also render to rectangular buffers and the gfx_1322 routines can output them (so they can too be reused by users with other displays). Have a great time! Peter

RIP Jack Tramiel and thanks for making home computers affordable, so that 8-year olds like myself could afford one after saving lotsa pocket money :) He will be remembered for countless hours of 8-bit fun, then and today.

Yo, TB, Wilba used normal "through-hole" LEDs for backlighting the knobs and in the photo tut, there is some info on how to do it with SMD LEDs (man, that was quite some work ;-)): Greets, Peter

Hi ultra, heheh, yes, me was lazy, thats why the example refers to approach type "one", which is good to start with - once that is done and you can use your font after #include "square_font.h", we can move to the next step, that is put the font extern declaration in the header and the font data in the square_font.c file - its all in the text somewhere :) Bye, Peter

Hi there, that already looks very nice! Regarding your .h / .c question, there are two approaches. In both cases, create one .h file by hand, which contains the struct info. In case one, your generator only creates a square_font.h file, which the user can include, when he needs it - the advantage is, that he needs not add a .c file to the makefile - the disadvantage is, when the font is used by more than one module (.c), there will be a linker problem because of redefined data. In case two, which is more general, your generator should create a square_font.h file, which contains an "extern" definition, so that any module can include it and use that font, and the .c file contains the font data. I would recommend this approach, as the benefits outweigh :) Example, to keep it simple, i´ve just created one "character" struct, a font is an array of characters. Also, the lazy generator only creates a .h file (method one), this has to be adapted later. font.h (not generated): -------- typedef struct character_struct { u16 bitmap[16]; u16 left_shift; u16 width; } character; square_font.h (generated) ------------------------------------ #include "font.h" character square_font[] = { { .bitmap = { 0x0, 0x0, 0x0, 0xfe00, 0x200, 0x200, 0xfe00, 0x8200, 0x8200, 0xfe00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }, .width = 0x07, .left_shift = 0x00 }, { ... }, ... }; Did not test this in the compiler, may contain some typos but like this the "named" structure initialization should work. Greets & have fun, Peter

Hi! Regarding the voltage regulators - i ´d suggest only using one high-power voltage regulator, e.g. a 78S05 (2 Amps max) with a large heatsink, and a big load resistor ahead of it to burn off excess volts, so that the vreg gets fed optimum input voltage (it has to burn off excess voltage, so if you feed it 15V, it has to burn off the difference to the target voltage, which generates a lot of heat). If you are developing a non-audio MIDIbox (e.g. a MBSEQ), you could employ a switching 5V power supply with 3 Amps, these are really cheap and power efficient. Greets, Peter

Yes, the euoropean versions have that "repair protection", too :) You can open the psu case with some force somehow, which will be instantly rewarded with a fresh nose of 80s air (which was well concealed), ah nice, but then you see a dark gumball of epoxy and you´re out of options. You can´t even reuse the case, because you hacked it open in the end, frustrated because the top would not come off :). It might be worth it, because of the 80s air, though :)

Great! :sorcerer:

Looking nice... What works good for me are Reichelt 10mm knobs - good grip and also possible to get your fingers between them in tight spaces. Also, maybe rethink the use of white 1200mcd leds, even if they are "pulsed" as in led-matrix connected, they will be probably bad to your eyes after some time (green, yellow or red is best for long usage). It is like supermodels, sweet to look at, but when you have to work with them, annoying after a few minutes :-). Also, if you have the time, wait for TKs new LPC17 based solution, it will be <put 10 pages of hymn text here> ;-). Greets, Peter

Hey, don´t worry too much, better you fried your old PSU than it fries your SIDs @some later point in time :-) Building a replacement unit is not so difficult... you can find many options and suggestions here on the forum, at the current point I also think Altitudes solution is the most elegant ;-) Greets, Peter

Hi there, Yes, now convert every binary line into a 16bit hex value, separate by commas and you are good to go. Your serializer also needs to write width and left_lead -> see the last link in my "edit" note below for how the serializer output format should look, ignore my long posting above, the proposed advanced structure initialization is much better. You should read the bitmap font first (on your big computer) and then write out the serialized "c struct initialization string", which you put into a separate header file for each font. For each font, make your serializer iterate all 96 characters starting with character 32 (which is space). Write a serializer loop that writes a long string for the whole font struct, that is a "C struct initialization" just as described in the link. To access the width of a "space", just: width = myFont->character[0].width; Bye, Peter

Hi there, nice! Instant initialization of complex pointered structures is not available in C - when dealing with "pointer" types, you need to store an address to a memory location, so initialization would be a 2-stage process, first storing the data, then getting and storing the address of it. But, data serialization to the rescue. You can write a small "font data serializer" on your real computer, in your favourite language (script language is also fine), that creates a "C readable" seralized font description, that can be directly accessed. Also, I´d put the different serialized fonts into different header or c files, so the user can include anything that is necessary (and thus reduce code size). The font_char struct looks quite fine. It has a sizeof 16*2 + 1 + 1 bytes, which would be 34 bytes. Nao, some architectures/compilers do a structure aligning to int-size boundaries (here: 4bytes), i´d therefore make left_lead and width also 16 bits wide (u16), just to be on the safe side (sizeof / 4 = not a fraction), maybe structure aligning is turned off on MIOS32, but me iz not sure, also unsure about the future :). Ok, long talk, here is some code, you need to strip away the typedefs, the main, and the printf(), i just tried it on a big computer, so that i do not tell you complete nonsense :) typedef unsigned short u16; typedef unsigned char u8; /* One font char contains 18 16-bit words, or 36 bytes */ struct font_char { u16 bitmap[16]; u16 left_lead; u16 width; }; struct font { struct font_char character[96]; /* Starting at ascii character 32, which is a space, includes numbers, symbols, upper and lowercase letters */ }; /* Generated by off-line generator, made by big computer :) */ /* Put this in a header file and let the user choose which fonts he needs, to save space */ struct font serialized_square_font = { 0x0000, 0x1001, 0xFEED, 0xBEEF /* ,... and 1724 16-bit words more */}; int main() { /* Let the user choose which font he wants, be obtaining a pointer to his preferred font */ struct font* myFont = &serialized_square_font; /* Lets output the second and third bitmap "line" of the first character in the user-selected font */ printf("%x\n", myFont->character[0].bitmap[2]); printf("%x\n", myFont->character[0].bitmap[3]); /* Note, you have to subtract "32" from every printed character value, as your font "starts" at character 32, which is the "space". */ } Have lots of fun! Bye, Peter Edit: having switched to C++ 10 years or so ago, i was unaware of the following method of struct "by name" initialization - I´d *highly* recommend to go this route: http://linuxprograms...ation-advanced/ It has the advantage, that the correct element order is not necessary and that less errors can occur - just write a "c font generator" that creates initializations in that format.

Hi and welcome! if you want to go full DIY (there is a nice control surface board available from SmashTV which can save you a lot of time), here is a small photo tutorial, but it is quite some work :) Greets! Peter

J: great to hear! The moar 256x64 OLED users, the better :) Ultra: very nice! As far as i´ve understood, you are currently using the "lineTo" methods to draw the font, which makes sense for this linear font. But to have a more universal font-drawing mechanism, i´d recommend to implement a packed bitmap font engine, that can handle characters with front leading ("j" in your example). What you always have to keep in mind is the uC-limitations, you don´t have endless space, so "packing" data as well as possible is a necessity, or you will run out of memory for your main program... So instead of using a full byte, if a pixel is lit or not, you could use a bit and extract it via bit operations (and/or/not bitwise operators -> wikipedia has some article on it). To store a character with left offset, and flexible length you could * put all characters in a 16x12 pixel bitmap (width x height), which will use only 192/8 = 24 bytes of space for each character. * have a character "leading" and character "width" control parameter associated with each character, which you can also put into your packed font data structure (=26 bytes per character). * do not output "blank pixels", so that the left offset of the "j" does not overwrite the right character pixels of the "a" in your demo. Quick pseudo-algorithm to draw "j" with positive left-side leading (Sorry don´t have more time to write the inner loop pixel checking and setting) unsigned char x = 100; // Current x "cursor" coordinate unsigned char y = 16; // Current y "cursor" coordinate // Grab output buffer, that has enough room to store the to-be-rendered screen data ... // Character output loop, example just writing character "j", assuming font with height 12 pixels, j has a left lead of 2 pixels, forces cursor to "go back" unsigned char leftLead = packedCharacter['j'][24]; // Byte 25 contains the left leading unsigned char width = packedCharacter['j'][25]; // Byte 26 contains the width for (unsigned char yChar = y; yChar < y + 12; yChar++) { for (unsigned char xChar = x - leftLead; xChar < x - leftLead + width; xChar++) { // Code, that checks, if a pixel is lit in character buffer // Only, if pixel is lit, modify output buffer } } // Write output buffer to screen ...

You are most welcome - when seeing all those nice font pics, my fingers also ache to code :) Me also hopes to attract moar people to this nice display :) Maybe you can share the font engine, when ready? Greets, Peter

Hi Ultra, don´t know, if I completely understand the question, but will formulate a possible answer :) as you have only 16 shades of grey/blue, you only need 4 bits for that information. The memory is organized in bytes with 8 bits, so you can store 2 pixels in each byte. If you want to set both pixels to color 15 (lightest shade/white), the byte would have to look like 1111-1111 in binary. Example: If the left one should be light grey (1000), the right one dark grey (0100), it would have to look like 1000-0100. The C notation for entering binary numbers is to use the prefix "0b", you may not need this, just enter the values directly in decimal format (0-15) or copy them from your font bitmap source buffer. The computation operation to combine these two values from 0-15 is first a "left shift" operation, which shifts your left pixel value so that it is on the left side: unsigned char bothPixels = 0; // Yet unknown unsigned char leftPixel = 0b1000; // Light grey bothPixels = leftPixel << 4; // Shift bit pattern to the left, bothPixels now contains "1000-0000" Then you just add the right pixel on top of that value unsigned char rightPixel = 0b0100; // Dark grey bothPixels += rightPixel; Now you can write this two-pixel byte to display memory (you usually write two bytes or four pixels at once). Regarding your question on how to calculate the "one byte" value with two pixels of the same color, it can be shortened to unsigned char pixelColor = 5; // Decimal example unsigned char bothPixels = (pixelColor << 4) + pixelColor; Have lots of fun! Greets, Peter