CPUMOD project: what's next?

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

CPUMOD project: what's next?

Post by antto »

calling all devs (if any, hopefully)

we have a board with an atmega2561 which plugs into the original x0x cpu socket (atmega162)
we also have a bootloader for it and an adapted version of the stock firmware (v1.05) (thanks to guest)

currently, only very few people have this thing, so if any drastic changes should be made to the project (bootloader/firmware and such) i think now is the best time, before it becomes too hard/messy to make changes

the new CPU gives 16x more flash space for firmware code, so now lack of space is no excuse ;]

the new bootloader runs at 3x higher baudrate - 57600 (that's good because the hex files will tend to be bigger)
currently there is no dedicated control app for flashing firmware to it over USB, but since the bootloader is based on a widely used avr bootloader (thanks to guest) - avrdude can be used for the job for now
the bootloader code is also in C, which is very nice ;]

-----------------------------------
there are all kinds of ideas about what to do now
some are easy to do, others maybe harder and more drastic

my overall idea is that whatever should be done - should be done to this stock firmware
like bug fixing, maing it slightly more proper, and so on
all in order for any new OS to have a "good" starting point, with less bugs to start with

one idea is to implement OS-update-via-MIDI
if this is to be implemented ever, i think it should be now because it involves modifying the bootloader
once these cpumod boards "hit production" and are sold to normal users - it will be too late for adding such a feature, because they will need to buy programmers to change their bootloader which is silly

the other ideas are not related to the bootloader:

2nd idea is to change the serial protocol
this is the "protocol" of communication between the x0xb0x firmware and the "control" app
the original protocol had things that were never used/implemented as well as one byte per each message which has no real purpose and could be removed to make messages a bit smaller
new messages can be implemented for more expandable control via PC

3rd idea is to change the sequencer MODEs
currently, if you look at Pattern Play mode - there are 3 versions of it on the FUNC switch, the only difference is the clock mode - internal/dinsync/midisync
the same applies to trackmode and so on, this wastes positions
instead, this can be optimized by changing the meanings of these positions
making 1 pattern play, pattern edit, and track mode, and the actual clock mode will be selectable from elsewhere
these kind of changes would require re-labeling the front panel

okay, that's what i can think of so far
we need more brains to discuss these things :mrgreen:

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

Re: CPUMOD project: what's next?

Post by antto »

i see a crowd of interest :lol:
so for now i'll do some minor things
will change the "code style" from

Code: Select all

if (cond) {
}
to:

Code: Select all

if (cond)
{
}
and i'll make a "Settings" mode on USER C
then the midi input/output channels will be selectable from there

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

Re: CPUMOD project: what's next?

Post by antto »

okay, there isn't any interest from devs :|

i will instead attempt to directly implement my own firmware (n0nx0x2 or so) which will be based around the original TB-303 sequencer interface and will require a new front panel

Luap
 
Posts: 363
Joined: Wed Jul 08, 2009 7:10 pm

Re: CPUMOD project: what's next?

Post by Luap »

Ahh give them time. Im sure they'll chime in soon enough ;)
Good work so far though! I would surely help if I could, but me & programming just don't get along! :oops:

A question though.. If updates via midi is implemented, does that leave any further use for the USB port? It made me wonder if (some way off in the future!?) USB could be omitted entirely from a revised version of the sub board. And while a revised version of x0x boards is in mind, perhaps even build the new CPU mod into the main board? But yeah, sorry, I know the mini CPU boards needs to get off the ground first :P

Keep up the good work!

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

Re: CPUMOD project: what's next?

Post by antto »

os-update-via-midi has to be implemented in the actual bootloader, which is not as easy as implementing midi-sysex stuff into the firmware
basically to change the bootloader you have to use a programmer

i had lots of trouble and bad luck with the programmer, and i don't want to touch it again, these cpumods are too rare right now ;]

in my case, the USB is very convenient
if i had to use midi to upload the firmware - this would mean changing cables around, closing the DAW (if it was running) then updating the OS, then changing the cables again, starting the DAW..

while normal users would have to do this like once or twice to change their OS - as a developer, i will be doing this a number of times a day/hour while developing, when fighting with bugs, so it's gonna be very frustrating
so i personally prefere USB

if you completely remove the USB, then neither c0ntr0l nor BANNED will work
memory dump via sysex could be implemented in the OS (that would be easier because you cannot brick the cpu in the process) and you'll have to use some app, afaik there are existing ones, but then you cannot have fancy features like individual pattern import/export, changing the tempo (huh) and sequencer control (not that this was implemented in the old x0x but was meant to be)
so then if you want those fancy features over midi - you'll need a dedicated app

but you'll still need to switch midi cables to dump patterns and use such features, if you use the x0x in slave mode
or use some midi merger maybe

if someone would alter the PCB, i'd like some other things to be changed:
(this is entirely in favour of my n0nx0x firmware tho, so many people can dissagree)

1) sepparate the TEMPO LED and switch from the encoder
2) rearange the buttons to have 24 buttons and LEDs in the same positions like on the TB-303
3) smaller LEDs as on the 303

oh well

User avatar
aminoacid
 
Posts: 352
Joined: Tue Jun 20, 2006 5:27 am

Re: CPUMOD project: what's next?

Post by aminoacid »

hi!

im not one of the digital people either. however from reading some about the micros lacks, id really suggest start with what you said anto about getting main things straight like midisync dinsync and timing etc.


ive probobly only suxeeded once with flashing a new firmware. its quite daft that you have to try on different computers to get it work for a human like my self who cant reprogram my own computer to get it working with the xox...


i think alot of special special sequencer features are more for the fun of it then for the music. get the instrument working like a clock first!


id love to help but i am more in to analogue and listening! ab recordings and oscilosope.

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

Re: CPUMOD project: what's next?

Post by antto »

i already started working on n0nx0x v2.00
so it's too late now :?

i modified BANNED in order to recognize it as a different OS and to recognize the pattern format it uses
i'll also add support in BANNED to recognize if the x0x is running with the CPUMOD (this will require a small modification to the x0xb0x2 code, which is currently available on guest's site)
basically there will be a handler for the OSID message, and the new OS will have to reply, then BANNED will know that it's not the stock firmware

the little bugs i found so far:

### Pattern Edit mode
- the x0x does not send midi notes when playing
- when you press play (or master starts) - the x0x doesn't start immediately but waits for a counter to wrap around
- there appears to be no dinsync mode, can't verify that myself
### Other
- the tempo is written to the internal eeprom every time you turn the tempo encoder (it's in the interrupt) .. this is not very healthy for the eeprom
- external eeprom write() waits for the eeprom status to be "okay" for more commands, but read() doesn't, so reading immediately after writing fails
- LED blink timer messes up one of the slave modes (LEDs blink both via the external clock as they should, but also by the blink timer and it ends up looking irregular)

--------------
i'll add any new bugs i find to the list and i might do a bugfix version of the stock firmware (from guest's site) in parallel
but it's not a priority for me now
i'd help if i see another dev who would be willing to code his own firmware
ive probobly only suxeeded once with flashing a new firmware. its quite daft that you have to try on different computers to get it work for a human like my self who cant reprogram my own computer to get it working with the xox...
you've had trouble? did you use c0ntr0l or BANNED?
flashing firmware is very easy now, you should be able to do it from any computer i think (windows/osx)

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

Return to “x0xm0dz”