TK.

Wow, after almost one day 182 chips have been ordered! 68 left to reach the minimum limit! :) Best Regards, Thorsten.

This hasn't been discussed yet. I don't know how customs are handled in the US, but if it is similar to Europe (no customs have to be paid so long the costs are below a certain limit) it will be favourable to distribute the chips to individual people from Europe. Best Regards, Thorsten.

Doch, vorgestern hat mich jemand wegen des gleichen Problems kontaktiert, und gestern hat er mir auch schon die Loesung praesentiert: das .hex File wurde unter MacOS generiert, und enthaelt deshalb keine Carriage-Returns (CR). PBrennerNG kommt damit nicht zurecht. Kurzfristige Loesung: .hex File bspw. mit Wordpad oeffnen, und am Ende eine Leerzeile einfuegen. Alternativ: Source Code nochmal unter DOS assemblieren. Einfach "make" eingeben, das hast Du bereits geuebt! Mittelfristige Loesung: ich muss die releasten .hex Files nachtraeglich in das DOS-Format konvertieren Langfristige Loesung: PBrennerNG geschmeidiger machen - Sprut ist informiert Gruss, Thorsten.

Great that you found the solution by yourself! :) Best Regards, Thorsten.

This thread is about continuously running bulk orders for the "GM5" chip - this is an Atmel AVR based USB chip with preburned USB-MIDI firmware (out-of-the-box solution) This product has been developed by http://www.ploytec.de Schematic/PCB Layout: http://www.ucapps.de/mbhp_usb_gm5.html Unbeatable prices: 4.50 EUR per unit for a batch of 250 chips 3.50 EUR per unit for a batch of 1000 chips Minimum order quantity: n x 250 The compact PCB can be ordered as well: 3.00 EUR per piece for a batch of 100 PCBs Minimum order quantity: n x 100 The chip will work under Windows/MacOS/Linux with the common USB-MIDI-Driver, but there is also a custom driver for Windows available for better performance (a drawback of the current MBHP_USB* modules) Per chip you will get 5 physical MIDI IOs (means: 0.90 EUR per IO port - compare this with commercial interfaces! :)). The dedicated Windows driver makes it multi-client capable. Under MacOS the interface is multi-client capable by default. Package: TQFP32 (SMD, but can be soldered with a good soldering iron similar to AN2131SC (-> MBHP_USB)) So, please add your name and the quantity of chips to this list -> http://www.midibox.org/dokuwiki/tk_gm5_bulkorder First come, first serve! We need n x 250 chips, if more than 250, but less than 500 chips are preordered, you need to wait for the next run Best Regards, Thorsten.

SDCC limits it to 8 bit (unfortunately) Initially I considered to propose a union (sometimes also called aggregate), because access to individual bits is much faster (single assembler instruction) But for your usecase it doesn't help, because you don't access the bits directly, but via an index (button number variable) - unions cannot be accessed this way (in other words: you have to statically specify the bit number/union element which should be accessed) Best Regards, Thorsten.

Hey, is this already the final pic? The panel looks more beautiful than expected from the first pictures! Definitely a reference design for small & still ergonomic solutions :) Best Regards, Thorsten.

Blogged :)

Easy: we would re-implement your project, make it much better, publish the sources and allow everybody to sell the devices for a better price at EBay ;) Don't know, if anybody would feel motivated to support somebody, who doesn't give something back to the community... there are enough forums, where you can discuss with professionals, so why do you search for help in an hobbyist forum, if you don't share the same spirit? Best Regards, Thorsten.

No, there isn't a better way. But you could optimize the handling by storing 8 solo button states per byte. To set a solo flag, use cur_but_solo[button >> 3] |= MIOS_HLP_GetBitORMask(button); To clear a solo flag, use cur_but_solo[button >> 3] &= MIOS_HLP_GetBitANDMask(button); To check a solo flag, use if( cur_but_solo[button >> 3] & MIOS_HLP_GetBitORMask(button) ) { ... } // no typo, use OR mask instead of AND To output 8 flags to LEDs, use MIOS_DOUT_SRSet(sr, cur_but_solo[button >> 3]); // will copy 8 bits to a shift register etc... The MIOS_HLP* functions are equivalent to (1 << (button & 7)), but much faster! Best Regards, Thorsten.

Alright, thats what I expect. Init() will be called before the copyright message (and before the LCD initialisation), whereas DISPLAY_Init() will be called after the copyright message Best Regards, Thorsten.

Fine! :) It's strange, that the wrong font is used for the copyright message, according to the code it should work. Are you sure? For the reboot message it's clear, but there is no solution, as the font is not statically assigned anymore, but under control of your application. However, since the message is only displayed after code upload, and not under normal circumstances, it should be acceptable, no? Best Regards, Thorsten.

Seems that there is an error in the .lkr script. Does it work, when you replace: CODEPAGE NAME=page START=0x3000 END=0x7FFF by CODEPAGE NAME=page START=0x3000 END=0xFFFF Best Regards, Thorsten.

I cannot say exactly, what will happen with my copyright message. The new font should be selected before it is print... or do you see a different text? Did you already try this out, or was it just a question? Now, it doesn't matter anymore where the font is located (it will be located by the linker automatically...) The new upper address is 0xffff. Best Regards, Thorsten.

Sieht nicht gut aus! :-( Koenntest Du bitte zum Vergleich mal die posix_bin Tools ausprobieren? Kopiere das Verzeichnis nach C:\posix_bin Oeffne die Kommando-Zeile, und tippe set PATH=C:\posix_bin;%PATH% Nun sollte "make" funktionieren. Ich gehe davon aus, dass Du GPUTILS bereits installiert hast. Falls nicht, bitte vorher erledigen, und dann erst die Command Shell oeffnen Gruss, Thorsten.

The default default font location is always the same. If your application overwrites this location, the font has to be included into the project, and initialized from there. Under http://svnmios.midibox.org/trunk/modules/glcd_font/ you will find a new font: GLCD_FONT_NORMAL This is exactly the MIOS font, which you now have to include into your project In order to update, download following files and copy them into the modules/glcd_font directory: glcd_font.h, glcd_font.mk, glcd_font_normal.asm, glcd_font_normal.inc, glcd_font_normal.xpm Thereafter add "glcd_font_normal.o" to the OBJS variable of your Makefile Thereafter initialize this font in Init() with: MIOS_GLCD_FontInit(GLCD_FONT_NORMAL); instead of MIOS_GLCD_FontInit(MIOS_GLCD_FONT); In general, you now always have to use GLCD_FONT_NORMAL instead of MIOS_GLCD_FONT - so, probably you also need to change this at other places in your code. Best Regards, Thorsten.

yes, it's very likely that the LCD has been fried because of (temporary) mixed data/power lines Best Regards, Thorsten.

It seems, that you are using an older SDCC version (you can verify this with "sdcc --version" The latest release is v2.8.0 Yes, and maybe you need to add the p18f4620.lkr file to the etc/lkr directory, if it isn't in there yet (don't remember, if it was in your .zip package) Best Regards, Thorsten.

falsch, MPASMWIN versteht nur Bahnhof! ;-) Die Sourcen sind mit diesem Assembler nicht mehr kompatibel (die Aenderungen waren notwendig, damit man die Applikationen auch problemlos unter MacOS und Linux assemblieren kann). Am besten gehst Du mal die aktuelle Installationsanleitung durch: http://www.midibox.org/dokuwiki/windows_toolchain_core Dir fehlen "MinGW make", "MSYS" und "GPUTILS" Nach erfolgreicher Installation, die "cmd" Shell oeffnen, in das midibox_808_... Verzeichnis wechseln, und "make" eingeben. Gruss, Thorsten.

If you don't find a way to reduce code size, then yes: just change to a PIC18F4620, it can save you from a lot of additional programming effort No - you asked how to verify the allocated memory areas, I proposed three different possibilities to find this out. If the content of main.lst and project.map doesn't make sense to you, then you rely on the output of MIOS Studio Best Regards, Thorsten.

MIOS Studio displays the address blocks during code upload. E.g.: [tt] ... Sending block 00007500-000075FF Received Checksum: 24 - OK Sending block 00007600-000076FF Received Checksum: 36 - OK Sending block 00007700-000077FF Received Checksum: 65 - OK Sending block 00007800-000078FF Received Checksum: 49 - OK Sending block 00007900-000079FF Received Checksum: 5E - OK Sending block 00007A00-00007AFF Received Checksum: 2E - OK Sending block 00007B00-00007BFF Received Checksum: 4E - OK Sending block 00007C00-00007CFF Received Checksum: 25 - OK Sending block 00007D00-00007DFF Received Checksum: 14 - OK Sending block 00007E00-00007EFF Received Checksum: 3E - OK Sending block 00007F00-00007FFF Received Checksum: 4D - OK [/tt] (red marked text is the code area, which contains the graphical default font) You will also find the allocated addresses in the .lst and .map file So, which address range is allocated by your application? Btw.: you can "repair" the graphical default font by uploading MIOS again Best Regards, Thorsten.

Ich habe in RC20 das Startup Delay erhoeht. Bitte mal ausprobieren, falls es nicht hilft, in cs_menu.inc den Wert von 0x18 auf bspw. 0x20 oder hoeher setzen, und mir den minimalen Wert mitteilen. Dieses Problem kann in Zukunft immer wieder auftreten, je nachdem, wieviel CPU Zeit die Synth Engine verbraucht. Andererseits moechte ich das Startup-Delay auch nicht zu hoch setzen, da es im Normalfall (also mit BankSticks) stoert. Gruss, Thorsten.

RC20 is available now, it contains some bugfixes: Best Regards, Thorsten.

Does your code overwrite the area between 0x7c00..0x7fff? Or did this ever happen? Best Regards, Thorsten.

Hallo, Nein, zwei reichen. Oder besser gesagt: ein BankStick benoetigst Du zum Speichern der Patterns, einen weiteren falls Du den Song Modus verwenden moechtest. Bis zu 6 weitere BankSticks koennen als zusaetzlicher Pattern-Speicher angeschlossen werden. Jeder "Pattern-BankStick" speichert 128 Patterns. Tip am Rande: falls Du BankSticks verwendest, die vorher bereits mit der MBSEQ V3 zum Einsatz kamen, so solltest Du sie erstmal formatieren, ansonsten sind die Default-Pattern unbrauchbar MB808 macht das nicht von alleine. Die SysEx-Kommandos koennen bspw. mit MIDI-Ox gesendet werden: [tt] ;; first BS: ;; F0 00 00 7E 40 00 0D 01 00 60 0C 00 00 00 00 00 00 00 00 F7 ;; second BS: ;; F0 00 00 7E 40 00 0D 01 00 60 0C 00 01 00 00 00 00 00 00 F7 ;; ... ;; 8th BS: ;; F0 00 00 7E 40 00 0D 01 00 60 0C 00 07 00 00 00 00 00 00 F7 [/tt] fein! :) Das kannst Du im setup_808_default.asm File einstellen. Einfach in der SR/Pin Spalte drei freie DOUT Pins eintragen - neues .hex file bauen - fertig! :) Gruss, Thorsten.