philetaylor

I think that I had screwed up my register bank selection so when I thought I was writing to one bank I was writing to another, I think I was basically splatting bits everywhere!

Right, it is 3am and I am controlling my first DMX light with Midibox!!!!! I wrote a simple MIDI->DMX program on the core and after much messing about, I have finally got it working 8) Is it appropriate for me to turn this into a proper 'project' now? I will carry on testing and refining over the weekend but I would like to put a page up on the wiki. Thanks for all of your help and encouragement so far, I think a lot more will be needed though :-) Phil

I think that I may (eventually) do both IIC and Slaved Core versions but as I only have 1 core at the moment, the IIC route is getting all of my attention, hopefully I will have a simple IIC_DMX working soon and I will post the code for people to look (or laugh) at !!!! Thanks Phil

Well I have found the problem and (not surprisingly) it was my mistake! In a couple of places I was in the wrong bank when I wrote data, I went through my code with a fine tooth comb and late last night (about 2am) I got it working...... Just when I think I have got my head round memory management, I find something else that 'bites me'. Thanks Phil

I did wonder about the watchdog timer, I am doing clrwdt in any of the 'big' loops, is there anything else I should do and would the wdt expiring cause the Core to reboot????? Phil

I know I really should take multiple backups at various times, I am usually pretty strict with myself....... I am sure it will be a really silly error but I am damned if I can find it, I even tried using a different PIC in case I had damaged this on by constantly removing it from its socket. I am starting to think I should have bought ZIF sockets for the IIC_MIDI and PIC Burner :-) I think I may start again as I can transplant a lot of the code back into the IIC_SpeakJet package and do it a bit at a time until I find what is causing the blowup! I did try displaying what was coming back to the core from the IIC (using IIC_Midi_Receive in the Tick function) and that appeared to just be one byte of 0xFF. AFAIK, I am not sending 'anything' back to the core so I am not sure how that is getting there? I know 0xFF can be used to put the IIC_MIDI into cmd mode, I wonder if it works the other way round as well????? Phil

Hi. I was getting quite close to getting my IIC_DMX512 interface working but I spent most of last night trying to figure out what I have broken that is causing the Core to keep rebooting...... I have verified that when I reprogram the IIC PIC with the original IIC_MIDI firmware, it doesn't cause the Core to reboot but put my firmware on it and it does :( I know it is a longshot but does anybody have any suggestions as to what might be causing the Core to reboot, I did wonder whether I was erroneously sending interrupts to the I2C instead of the USART but I don't think so? Phil

Maybe I won't get much 'proper' work today but at least I am learning about PIC memory management...... Yes that works, 0x70-0x7f are the ACCESS bank and are as you say visible from all banks. Thanks Phil

Hi. I am currently working on another mod to IIC_MIDI to make it into a DMX512 interface. Using some hacked code from another pic16f88 based Parallel->DMX interface, I have made some progress although my lack of knowledge regarding PIC memory management is really causing me some headaches. As I am using the IIC_MIDI to effectively buffer 255 channels of DMX it requires me to use all 4 gpr's and I can't quite get my head round bank switching and what is visible when in another bank. I have configured a register (called DMX_CHANNEL) in gpr0 which temporarilly stores the current DMX channel that is being updated by the Core but when I SWITCH_FSR_UPPER to access the upper banks I seem to lose the DMX_CHANNEL register (I assume because it is in the lower banks?). Is there any way round this or alternatively another regsiter I can use that is visible across all banks (other than W)? I don't expect anybody to 'spoon feed' me but does anyone know of a good tutorial on this as I am really struggling to get my head round it. I have also looked at other turorials that say on certain PIC's banks 1/3 and 2/4 are shared I assume this isn't the case with the 16f88? From re-reading the spec (again) am I right in thinking that if use registers 0x70-0x7f then these are shared across all banks??? Thanks Phil

Hi Nebula, my main reason for going the IIC route is really due to a post by /tilted/ in another thread for the MBSEQ V4 wishlist where he says: That is why I thought the IIC route would be best (especially as he knows a lot more about MIOS/Midibox than I do!) It allows the Core to only deal with 'changes' to the DMX stream and as arum said opens the door to a DMX<->RS232<->MIDI<->Whatever other protocol bridge with the Core only doing minimal processing. I am not sure how 'official' the magnulator is as far as timings etc, hopefully it is a reasonable place to start but yes I suppose investing in a copy of the spec would be worthwhile (eventually!) Phil

I have done a bit more research and I think the IIC_DMX can be realised 'relatively' easily! I am currently looking at the source of the Magnulator! http://www.freedmx.com/Magnulator.htm which is a 256 channel buffered parallel to DMX interface using a 16f88 and uses the UART rather than creating the DMX single with one of the output lines! I think that by 'merging' the IIC_MIDI code with the Magnulator! code I should be able to get something working although I may try with 64 channels first as I haven't quite got my head round bank switching on the 16f88 yet! I agree that many commercial desks are really poor and amazingly unstable, I have had to reboot desks mid-show more times than I care to mention, something that I have never had to do with my digital audio desks. Phil

To be honest this has been motivated by my need to program a Zero 88 Leap Frog to control some Mac 250's for a show I am doing this week. It is totally counter-intuitive and far too complicated for my needs, I have found this with almost all lighting desks and I would like something 'simpler'. I agree that for full functionality Core V4 will be able to handle much more processing but I think that handing over the DMX to an IIC would still be the best way to go especially as it would give the potential for more universes to be added by adding more IIC's (I am getting way too far ahead of myself now!!!!) The 368 bytes of RAM on the 16f88 may be a limitation as I mentioned on my other message but 256 channels should be do-able as each channel should only require 1 byte of ram to store its value. I would definately be interested in collaborating on this but it is probably medium-to-long term for me also as I still have to finish the Minidisc controller project and fit in some 'real' work! My thoughts are to have something that 'could' work stand-alone so would have some faders etc and the ability to store scenes/chases/fixtures etc on a bankstick would be nice but again I am getting ahead of myself! Cheers Phil

I know that this has been discussed before but flushed with success over getting my Sony Minidisc controller working (although it still has a way to go to be fully functional), I have been thinking about other possible projects and I am thinking of attacking DMX512 now! My thoughts at the moment as I know that previous comments have suggested that if DMX was handled by the core then it basically wouldn't be able to do anything else due to the fact that it requires an almost continuous stream, is to utilize an IIC module and reprogram it to 'stream' DMX to one of the IIC J1 outputs via an SN75176 differential bus transceiver. I think that I could use the IIC to maintain the DMX stream and then simply send individual channel changes from the core to the IIC, this would free-up the core and I could create a simple lighting desk. I know the RAM on the 16F88 would limit the number of channels that I could manage but I would have thought I could manage 128/256 without too much difficulty. I could also potentially support DMX in as well although I expect that memory would then become a 'major' issue! I am thinking that I could also use the existing MIDI Show Control command set to allow remote control of the 'Midibox DMX'. This is very much a 'concept' at the moment but I thought I would see if anybody was interested in something like this and whether people think it is likely to be possible???? Cheers Phil Off to the cupboard to see if I can find a working oscilloscope!

Hi. I know that it isn't 'technically' MIOS, but I have been building a MIDI<->RS-232 translator (for Sony Minidisc control) and I am using an IIC MIDI and an LTC module (I suppose you could call it "IIC RS-232"). The IIC Midi code does quite a bit of processing to check that it is a valid Midi stream which I don't want it to do. I have done a quick-and-dirty hack to prot.asm which forces all bytes to be sent as single byte MIDI (F8-FF) whereby I commented out andlx 0xf8 and xorlw 0xf8 in PROT_Tick_Rx_NewStatus! I know that this isn't perfect as it means that 2 bytes are sent over the I2C for each 1 byte of RS-232 but as I am working at 9600baud I wasn't concerned about this. Is there a more elegant way of achieving this? As it isn't exactly easy to debug the IIC I didn't want to change too much and I last used assembler on 6502's in the late 80's! Phil

I have had a bit of a redesign, I got fed-up of removing and reinserting the optocoupler in the core everytime I wanted to send an updated program so I decided to use the IIC for the RS-232 comms (with the LTD) but of course the IIC does quite a lot of MIDI processing which is not compatible with the Sony RS-232 protocol (it uses 0xff as a terminator for a start) so I bypassed most of the MIDI processing from IIC_MIDI and reprogrammed the IIC PIC. It is all working now with feedback including sending track counter information as MTC events). I still need to do a 'lot' of tidying up of the code and a 'lot' more testing. I have learnt an enormous amount about PIC programming in a very short time, I didn't realise how rusty my assembler skills were (mostly 6502 in the late 80's)!! Cheers Phil

Well I have had a fun few evenings! The kits arrived on Tuesday (thanks Mike) and I got them (Core, IIC, RTC, LCD) built and tested that evening. There was only 1 solder bridge when I built the core which (unfortunately) was shorting the output of the bridge rectifier, once I fixed that everything came up and I was able to load MIOS and one of the sample programs. I then built the other two kits and they both worked first time. Great work everyone that has been involved in the development! I have now written a fairly simple C based project which receives MMC commands on the IIC and forwards them to the Core (RTC Com interface) in the correct format for the Sony MDS-E11/MDS-E52 Minidisc decks! I did need to make a slight mod to mios_midi.inc and re-make MIOS in order to force the Core baud rate to 9600 (the Sony only supports this...). In case you are interested, the only line that needed changing was: movlw 2*0x21-1 ; set baudrate to 38400 baud to movlw 2*0x80-1 ; set baudrate to 9600 baud I got the number from the Datasheet for the PIC. It is actually 9766baud but seems to be OK. I did wonder as interfaces 0x2 -> 0xf aren't used for anything would it be worth using them as a way of setting different baud rates for the internal USART from within MIOS_MIDI_InterfaceSet? I still have many other things that I would like to add including feedback from the Minidisc desk back to MMC and maybe display track info on the Core LCD. Once I have done this (and tidied up the code a bit) I am quite happy to release my work back to the community but so far I think I have jumped the biggest hurdle in actually getting the things talking! I did find a commerical product that seems to fulfil a similar function for Sony video decks but as it is about 500UKP this may become a low cost option? Cheers Phil

That's good. I have placed an order for exactly that (+ an LCD) with Mike so watch this space !!!

Thanks for the info both of you, I (not surprisingly) have more questions.... My current thought is to use an IIC-MIDI module to handle the 'actual' midi, I would plan to connect this to my Yamaha 01x which has MMC transport controls. I was then thinking of 'also' connecting an LTC module to handle the RS-232 side of it. Do you think this would be a workable configuration? If I do it this way, my thoughts are that I would 'only' need to create a MIOS application to handle the translation and I can leave the midi communications to the IIC-MIDI? Am I barking up the wrong tree here? Thanks Phil

Hi. Sorry if this is the wrong forum, but I am new here. I am interested in the midibox project and I have an application that I would like to try. I have a sony MDS-E52 Minidisc Deck which can be fully controlled via an RS-232 interface. It appears that a good staring point for me would be to purchase a Core and LTC module and then write an interface between MMC and Sonys RS-232 protocol?? From searching the archives, somebody asked a similar question about 5 years ago but there didn't seem to be any follow-up other than it should be possible. I am a C programmer and I have some experience of assembler (from college many years ago!) but before I embark on this project I wondered if it is likely to be possible? Can I use MIDI<->RS-232 with the LTC module and control what is sent over the RS-232 port or can it just be used as a TO-HOST style port? Also the Sony desk only supports 9600,n,8,1. Is it possible to set this baud rate on the serial port and still support MIDI commands on the MIDI ports? I would appreciate any pointers anybody can give me. Thanks Phil