MarOS1.5.0 - Beta Version

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
paradigm x
 
Posts: 237
Joined: Sun Feb 07, 2010 3:49 pm

Re: MarOS1.5.0 - Beta Version

Post by paradigm x »

thanks for the reply. glad to hear i cant mess it up by flashing.

it was just i saw a message in Conb0x which said 'dont connect to x0x0b0x in bootloader mode!' which made me think id done something wrong.

either way all good now. will flash my other x0x when i get a chance, but going to do some mods and replace the tacts.

cheers
Ben

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

Re: MarOS1.5.0 - Beta Version

Post by antto »

Nordcore wrote:BTW: It is not possible to break the boot loader with the update procedure.
The boot code has a separate code space (a whopping 512 bytes) which can only be written by a hardware programming device.
sadly, it is
there are lockbits which let you "lock" the app and boot sections from writing, and in our situation the lockbits should be configured to lock the boot section from writing
but it turns out that quite a number of pre-flashed atmega162s come unlocked, including mine.. guess how i learned that

the unreleased v1.02 of BANNED includes some checks for that reason
it requests the fuse and lock bits from the bootloader, and prints a warning if the boot sector is not locked
here's what happens with one of my x0xb0xes:
Image

0xFF is the default value, all flash sectors are writable

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

Re: MarOS1.5.0 - Beta Version

Post by antto »

Paradigm X wrote:thanks for the reply. glad to hear i cant mess it up by flashing.

it was just i saw a message in Conb0x which said 'dont connect to x0x0b0x in bootloader mode!' which made me think id done something wrong.

either way all good now. will flash my other x0x when i get a chance, but going to do some mods and replace the tacts.

cheers
Ben
here's the situation with the old bootloader (i call it x0xb00t1)
- it has absolutely no feedback, you cannot figure out if you're running the bootloader or the atmega is frozen into a bad loop due to corrupted/missing firmware
- it uses a very primitive serial protocol, with single character commands
-- this means that by merely sending any random junk to the USB, anything that gets thru the USART receiver as valid data bytes - you may get the bootloader into programming mode and you may clear a page, you may change the address for the next page, etc..

if the boot sector was properly locked via the lockbits - at worst you would corrupt your firmware only - and that's not terrible
but since on some (or many) chips it seems to not be locked, then you can in theory corrupt the bootloader itself

now, to actually send data to the x0xb0x (besides modifying the ft232 chip out) you need to connect the USB to a computer, where it will appear as a virtual serial port
so, any program which opens that serial port and sends the "right" kind of data to the bootloader, could potentially corrupt it
that could be a serial terminal program (like realterm or many others), or one of the dedicated x0xb0x apps
the x0xb0x apps (c0ntr0l, BANNED) can talk to the bootloader, or to the firmware
but they don't know what they talk to.. not easily
so it's left in the hands of the user, to be careful

do not tell the program to connect to the firmware, if the x0xb0x is running the bootloader
because the serial protocol between the firmware and the app is more complex, and thus there is more data going on, so chances get higher to hit some magical combination of junk data that causes the bootloader to attempt to shoot its own foot

especially do not do it with BANNED, because BANNED uses even more app<->firmware messages, and sends a bunch of queries on connect to figure out what firmware it's talking with
the mentioned BANNED v1.02 includes a check for that, when you tell it to connect to the firmware, it tries to safely detect whether the x0xb0x is actually running the x0xb00t1 bootloader first, before sending a pile of fancy messages
this is also included in the BANNED_wx (the rewritten version which is also not released yet)

that's the situation with the old bootloader.. there's not much that can be done about it
unless everyone buys (or makes) a programmer to lock their chips

User avatar
paradigm x
 
Posts: 237
Joined: Sun Feb 07, 2010 3:49 pm

Re: MarOS1.5.0 - Beta Version

Post by paradigm x »

Well, a bit more carefully, i updated my other x0x last night. backed up all patterns in BANNED and then updated firmware, worked first time.

then had a 2 hour jam with the two boxes, had so much fun, this latest version is superb, subtle use of randomisation in play mode is fantastic, the new save pattern method is great (lost so many patterns messing about with done button), overall seems much more stable and tighter syncing, overall just really pleased with it.

So thanks so much to nordcore, mario, antto, sokkan and all others involved with keeping the x0x moving forward!

cheers

User avatar
paradigm x
 
Posts: 237
Joined: Sun Feb 07, 2010 3:49 pm

Re: MarOS1.5.0 - Beta Version

Post by paradigm x »

I twigged the run button = stop pattern/restart synced to bars function last night, so much fun! this thing gets better and better.

thanks once more

ben

User avatar
paradigm x
 
Posts: 237
Joined: Sun Feb 07, 2010 3:49 pm

Re: MarOS1.5.0 - Beta Version

Post by paradigm x »

ok well something ive found while playing;

If in play mode you set a loop less than 16 notes (using done and 1-16) if you press run then restart again using run, it goes back to a full 16 note loop. i had anticipated it would remember the shorter loop settings.

not sure if a bug or wai or limitation of the way it works? not a major problem but would be great if it could work as i thought it would.

still loving it btw, it just seems really solid and tight, everything works perfectly with no little odd occasional glitches i got with sokkos now and again.

cheers
ben

User avatar
Nordcore
 
Posts: 99
Joined: Sat May 23, 2015 3:14 pm

Re: MarOS1.5.0 - Beta Version

Post by Nordcore »

Paradigm X wrote:not sure if a bug or wai or limitation of the way it works?
It's worse: it is how it should work.

Removing that would even save some byte.
I think I can add a User-C setting to enable/disable the "loop reset on STOP".

User avatar
paradigm x
 
Posts: 237
Joined: Sun Feb 07, 2010 3:49 pm

Re: MarOS1.5.0 - Beta Version

Post by paradigm x »

ok, well thats no biggie, just wondered. an option woudl be great if possible but not a major priority.

still loving this so much! its so tight and just works really well. all the little syncing problems i had are gone!

if i may add a feature request (if possible) - when you press run/stop to stop start the sequence, would it be possible for the run/stop led to flash so you know its going to stop/start? not critical by any means but theres no way of knowing if its registered. not a big thing but would be awesome if its easy.

thanks so much.

User avatar
Nordcore
 
Posts: 99
Joined: Sat May 23, 2015 3:14 pm

Re: MarOS1.5.0 - Beta Version

Post by Nordcore »

I noticed that (somewhat broken looking) missing feedback by the R/S LED (in MIDI-Sync while it waits for the next bar) also.
I try to squeeze some LED blinking in the code. It is not complicated, but a little bit lengthy...

User avatar
paradigm x
 
Posts: 237
Joined: Sun Feb 07, 2010 3:49 pm

Re: MarOS1.5.0 - Beta Version

Post by paradigm x »

hi. it doesnt necessarily need to flash, im not at my x0x now but as i recall the run leds isnt lit when midi synced? a solid on led would be fine if easier/smaller.

brilliant.

thanks, ben

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

Re: MarOS1.5.0 - Beta Version

Post by antto »

not sure about sokkos and its derivatives, but at least in the stock firmware there's a famous LED blink bug when you're in slave mode
the LED blinking is controlled by the incoming sync clock (as it should) but there is also a chunk of code that does a fixed-rate blink, and the two effectively XOR each other

User avatar
Nordcore
 
Posts: 99
Joined: Sat May 23, 2015 3:14 pm

Re: MarOS1.5.0 - Beta Version

Post by Nordcore »

Yes, this bug was there. I fixed that some (not too long) time ago.

... and being there: I added some "timeout" code, so you could still STOP the x0x in MIDI-Sync-Mode when the external clock gets lost.

... and I'm thinking about an "auto sync source" mode, where a missing clock switches to internal clock. Plus synchronizing the internal clock speed to the external sync. That could provide a bullet proof clock output, that would still continue, even it if the source gets lost (stupid DAW programs, crashing Laptop, flimsy cables...)

User avatar
manneokoko
 
Posts: 10
Joined: Tue Feb 16, 2016 1:58 am

Re: MarOS1.5.0 - Beta Version

Post by manneokoko »

Hello Nordcore and all,
What a nice surprise to see that this OS is still being developed!
I have a couple of feature requests that would improve the box allot, maybe not possible but..
Improved Live record.
  1. When a note is pressed down during several steps then all steps should get that note. (now it will only record the exact step where you start pressing the key, not the following steps when you keep pressing the key)
  2. If R/A/S/U/D buttons is pressed down during several steps then all those steps should get R/A/S/U/D (not only the initial step that is held down).
  3. Some way to clear R/A/S/U/D while live recording - maybe hold down one of the R/A/S/U/D + press DONE.
  4. Alternative way: note + R/A/S/U/D can be recorded simultaneous: When you hold down a Note key+R/A/S/U/D, note and R/A/S/U/D state will be input for all the steps that pass when held down.
Possibility to set root key for the randomizer.
Now it always randomizes in C, and then we have to press D/U to transpose to the right key - it would be better if the transpose setting is kept even when making a new randomization.

What do you think is any of these possible?

User avatar
ioth
 
Posts: 30
Joined: Thu May 04, 2017 7:16 am

Re: MarOS1.5.0 - Beta Version

Post by ioth »

Hey Nordcore, found snother small bug, when in randomizer mode pressing the F key twice it clears tha pattern (thats right),
but it also sets the length to 15 steps. would be cool if it always goes to 16 steps.

Best, ioth

User avatar
Nordcore
 
Posts: 99
Joined: Sat May 23, 2015 3:14 pm

Re: MarOS1.5.0 - Beta Version

Post by Nordcore »

Thanks for the report, will look at that.

I suspect, I messed something up with the (barely tested) 3/4 mode.
Which has 15 steps "pattern length", but defaults to having step 13 set to "Brick"-Pseudo-Note (=End of pattern mark) ...
so the proper behavior in that mode should be, that it first sets step 1 to 15 to Rest and than step 13 to "Brick". ( ... step 16 is somewhat undefined it that mode, so I would leave that as what happens "naturally" w/o adding extra code lines. )

In usual 4/4 mode, it should of course fill the pattern with 16 rest "notes".

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

Return to “x0xm0dz”