Q: developing firmware, lots of questions..

Discuss mods, hacks, tweaks, etc.

Moderators: altitude, adafruit_support_bill, adafruit, phono, hamburgers

Please be positive and constructive with your questions and comments.
Locked
User avatar
antto
 
Posts: 1636
Joined: Thu Apr 15, 2010 3:21 pm

Q: developing firmware, lots of questions..

Post by antto »

hi there, i just began messing with the firmware code
so far, i was able to upload .hex files and try em
i managed to compile the original x0x firmware (v1.05) and modded it just a little bit (changed the blink speed)

there seems to be very little info about all of it, so i'll put some of my questions here

what's the maximum acceptable size of the .hex file?
what's the maximum eeprom memory size that i can use for patterns and stuff?
can the VCA envelope be triggered sepparately from the main envelope (filter)?
how does the tempo work? it seems to "jitter" when i turn the knob, and is it changed at integer values only?
how does the Note-Pitch work? can it go higher/lower than what i can see in the original firmware?

i don't really understand how the whole thing "flows" it'd be great if someone can explain..
as far as i can tell, the do_tempo() function is in the center, but i'm not sure exactly
i haven't programmed in C, neither specific hardware like this
my experience is with C++ and mainly console-apps and some Digital Signal Processing (similar to VSTs)

what i want to do is change the way this thing edits/stores/reads the patterns
currently, a pattern (as in almost all other clones) is just an array of "steps" with Note/Gate/Accent/Slide values
i want to change this to Note-Data(Pitch/Accent/Slide) and Time-Data(Gate/Tie/Rest) .. just like it is in the TB-303
yet, i'm not sure where in the code to look at, any tips and clues are welcome
also any other tips and clues about what to do and not do, are welcome
thanks

User avatar
antto
 
Posts: 1636
Joined: Thu Apr 15, 2010 3:21 pm

Re: Q: developing firmware, lots of questions..

Post by antto »

bump?

and what is the note_off(1) meant for?
it simply doesn't end the note, doh..

Sokkan
 
Posts: 240
Joined: Sat Sep 01, 2007 12:56 pm

Re: Q: developing firmware, lots of questions..

Post by Sokkan »

Hi,

Try using the java application (javrprog) for uploading the firmware instead, it will tell you the maximum size, it is 15872 bytes as far as I remember.

Size of the EEPROM i do not know, but it should be apparent by looking at the schematic and see how many address pins are used for it.

There is no VCA envelope, just a gate. The VCF envelope is triggered by that gate.

The tempo is not nice, but I only adjust it carefully in small steps and then it is acceptable. I never really thought about fixing it...

The synth only uses 6 bits for note information, the lowest 11 values (0x0 to 0xA) is not usable which leaves 52 notes in the range as in the firmware.

Each step in a pattern is stored as an 8-bit integer. The slide and accent information is masked out of it. End of pattern is defined as 0xFF and a rest as 0x0 as far as I remember. The firmware is based upon manipulating just an integer value for everything, it is not a trivial task to change this. I have thought about doing this myself to add triplets but more or less everything needs to be rewritten then.

Good luck! :)

User avatar
antto
 
Posts: 1636
Joined: Thu Apr 15, 2010 3:21 pm

Re: Q: developing firmware, lots of questions..

Post by antto »

ahum..
so i changed the pattern size to 20 bytes
the first 4 bytes of each pattern is now the TimeData (2bits per step)
NoteData is still 1 byte per note, but i rearanged it to: 0xASUDKKKK - Accent/Slide/Up/Down/Key

i had to change lots of other things in order to play this.. ah well..
i really gotta do a big CTRL+A, DEL

User avatar
antto
 
Posts: 1636
Joined: Thu Apr 15, 2010 3:21 pm

Re: Q: developing firmware, lots of questions..

Post by antto »

i almost got it working..
having problems with the .hex file now
it's 42.7KB right now (even that i deleted a lot of code)

what's the maximum hex size possible? (if it matters, my x0x is from x0xsource)
btw, when i extract the eeprom memory to a file, it's 1900 bytes long

and a few questions about controlling the synth part..
note_on(note,S,A); <- this will trigger a note, okay
if S=0 nothing unusual happens.
if S=1 the CV signal will pass thru a LP filter (slide) before going to the VCO

note_off(0); <- kills the note
note_off(1); <- ????
i guess this is meant for running the CV signal dry again (i.e. not thru the LP filter, slide)

textile
 
Posts: 221
Joined: Mon Nov 23, 2009 9:34 pm

Re: Q: developing firmware, lots of questions..

Post by textile »

Hi ! If you make a log of this I'm sure it will be appreciated.
I am trying to change some things about as well but I'm still learning.

User avatar
antto
 
Posts: 1636
Joined: Thu Apr 15, 2010 3:21 pm

Re: Q: developing firmware, lots of questions..

Post by antto »

i did it (was tough..)
now, i can program a pattern like on a 303 (pitchmode and timemode sepparately)
i still need to consult my 303 expert about some "rules" (like what happens with slide->rest)

another thing i'll try to figure out is what kind of code consumes more size
i guess i should turn all my macros into functions instead.. gotta check..

User avatar
rv0
 
Posts: 395
Joined: Tue Jul 14, 2009 4:50 pm

Re: Q: developing firmware, lots of questions..

Post by rv0 »

:o respect! amazing how quick you did this

I really wanna test this stuff :)


*prepares to buy x0xb0x*

User avatar
antto
 
Posts: 1636
Joined: Thu Apr 15, 2010 3:21 pm

Re: Q: developing firmware, lots of questions..

Post by antto »

:mrgreen:
now, i'm really frustrated about my .hex file
till now, i deleted a lot of the original firmware code to make space for my own
i removed the Keyboard, Pattern/Track-Play
i also changed some of the existing code to work with the new pattern format and so on..
i got about 80% of the new Pattern Edit mode (pitch mode, time mode, pattern preview in edit mode)
the hex is 38.2kb
even at that size, doing some things which don't increase the size do seem to "spoil" it.. i'm not sure why
i added a big "menu" function to deal with button interaction in common situations (like there are several places in the code where you can modify Up/Down/Accent/Slide, and need to check the buttons for that)
so i tried doing all this in a single function and then call it in the appropriate places, instead of "inlining" the same code everywhere
the function needed a few additional variables to work
updated the firmware - it "kinda" worked in half, or not at all
i updated it several times too, recompiled, restarted the c0ntr0l app, updated again - couldn't get it to work "normaly"

is that because i have too many global variables or something? size was still below 40KB

and just wondering..
can the Atmega162 chip be replaced with a "bigger" (so i can use bigger hex files and more processing memory..) ? or is it too complicated/impossible (note, i'm not into electronics and soldering, i can do only simple stuff like cleaning a CPU Fan) :roll:

Sokkan
 
Posts: 240
Joined: Sat Sep 01, 2007 12:56 pm

Re: Q: developing firmware, lots of questions..

Post by Sokkan »

The size of the hex-file is unimportant, the Sokkos hex-file is 45kB. What is important is the numbers that winAVR will tell you after a successful compilation. You can only fit 15872 bytes into the AVR, anything larger than that will not be flashable. If you download the Sokkos source code and compile it the size of the binary will sum up to 15870 bytes(if I remember correctly), hence, it will fit. You will get a listing of what constitutes the file and then you can check the size your global variables take up.

If you wrote lots of functions the compiler will inline some of them to improve speed, this can be turned off via a compiler flag. You should really look into the manual for the compiler and see what you could benefit of. The flag for winAVR is "-fno-inline" if I remember correctly, it should be in the Makefile you get with the Sokkos source.

There is no drop-in replacement for the current microprocessor unfortunately, there were some efforts to make a replacement board of some kind but I haven't heard anything from it in a while. What really should be done is to write it in assembler instead. :)

(Oh, the reason you cannot fit 16384 bytes in the microprocessor is of course that the bootloader sits at the end taking up place. You could rewrite the bootloader and make it's footprint smaller to have more space to play around with. But then you also need to change a constant in c0ntr0l or javrprog so that they know the correct size of it.)

User avatar
antto
 
Posts: 1636
Joined: Thu Apr 15, 2010 3:21 pm

Re: Q: developing firmware, lots of questions..

Post by antto »

ahum, thanks Sokkan
it's also good to know that the external EEPROM is 4KB (for patterns)
so i can still have 16 banks of 8 patterns, at least until i figure how much memory will track mode need

btw i added tripplet mode to the patterns, it's funny ;]
why did no one tried to write a 303-like sequencer before? it's soo cool now :mrgreen:

User avatar
antto
 
Posts: 1636
Joined: Thu Apr 15, 2010 3:21 pm

Re: Q: developing firmware, lots of questions..

Post by antto »

how is the EEPROM->SAVE & LOAD work!?
i know the external memory is 4kb, i have already extracted it a bunch of times and the size of the .xbp file is too small, not only that, it differes
most of the times i got 1900 bytes, then, i also have 2 attempts which ended up with a 1902 and 1904 bytes

at first the CLEAR EEPROM function worked at least twice (i was using either the stock 1.05 firmware or the SokkOS)
now, it seems that doesn't work
Import xbp doesn't seem to work now either
what could be wrong? some bug in c0ntr0l? some bug in my firmware? (i haven't touched anything about compcontrol) Serial Port communication fail?

and btw, what is the clock_leds() supposed to do exactly?

User avatar
helyx525
 
Posts: 61
Joined: Fri Apr 23, 2010 11:58 am

Re: Q: developing firmware, lots of questions..

Post by helyx525 »

antto wrote:and btw, what is the clock_leds() supposed to do exactly?
The LEDs are attached to the AVR using the SPI serial bus.
IIRC, clock_leds() takes the current LED state bits and shifts them out via SPI and latches them into the external LED drivers.

Locked
Please be positive and constructive with your questions and comments.

Return to “x0xm0dz”