sompost

Thanks for the link. I though I read all of what I could find on DB50XG and midibox. Perhaps I should have used an LPC17 core to start with. But then, there's an engineer inside me that tells me, it's only UI work I do and that a PIC18 is sufficient (you know, "make it as simple as possible..." etc). I write in "C redux", i.e. I try hard avoiding all C constructs that produce lots of code. As for the QS300 thing, that's disappointing. I thought because Yamaha's spec defines a QS bulk dump, the clones would implement that too. Cheers!

Great stuff! I have a rather similar project simmering on low heat. Mine is based on the Core8 module, though. Anyway, I read somewhere on the Intertubes that the DB50XG clones by NEC don't support the QS300 mode of the original. Have you verified this by any chance? I can see in your code that you provide a specific macro to turn QS300 processing off, so perhaps you know more. Thanks

Rock'n'Roll! I can get at the boot sector now. Thanks for your help (SD and Timer)! There's still one small problem: I seem to be unable to switch to higher bit rates, perhaps because of the level shifter, but that can wait. I'll get FAT done first. Ralph

OK, I'm back. After a timeout caused by my buying and subsequent (ab)using of a Yamaha MOX6 (Yes!!!) I returned to my midibox project. As noted above and implemented in the meantime, all text output (as for now) goes to the text area of the T6963C. I can see all the MIOS messages now, while also being able to do graphics, including text-as-graphics. Think of it like a PC: first booting in text mode and then switching to graphics mode. Just for the looks, I seriously consider dumping screens full of fake driver initialization messages on the display while booting, like on a unix system. Anyway, the next item on my list before starting the project for real is driving an SD card. I bought one of these cheapo SD card holders for $2 on ebay, the sort that don't work because there's a missing ground connection on them. So I fixed that, and while being at it also breadboarded a level shifter using diodes and a transistor. That's the short version of where I'm now. Don't ask for the long one. The basics seem to work: I can write bits to the card using the MSSP module (SPI) of the 18F4620, and get as far as the card responding to the GO_IDLE_STATE request (CMD0). Then I get illegal command responses for everything else. I understand that "older" cards are quite sensitive to the initial bit rate not being to high, so I'd like to use the TMR2/2 option using Timer2, but get an infinite boot-reset loop. Timer2 is not used in MIOS, is it? What are the minimum steps to setup the timer2 to, say 500kHz, no interrupt. Yes, I do read the data sheet, but that also lied about the SPI setup. Thanks for suggestions (also tricks/need-to-knows about SD card communication)

I know, it sounds kinda obvious, doesn't it... :rolleyes: Ralph

Thanks for your assistance, but I cannot get it to work the way I wanted. Here's what I discovered: as soon as execution coming from USER_LCD_PrintChar runs into any of the following, the system goes berserk (instead of the copyright message I get random bytes from the memory thrown at me): CALL __gptrget1 BANKSEL foo TBLRD*+ (and/or the setting up of the table pointer) I suppose that whatever is printing the copyright message via USER_LCD_PrintChar is not expecting any of these changes to the global state, and is subsequently confused as to what it wanted to print. There's no need to investigate (unless you cannot help it :whistle: ). For this and other reasons, I'm considering using the text mode of the T6963C for printing text (I might even sacrifice a pin of the DOUT to enable run-time-switching between 6 and 8 bit modes). Thanks again for your help. Ralph

All's not well with my GLCD driver. From the observed erratic behaviour it appears that I might be low on stack space. So I increased it as proposed in the Wiki pages: Makefile: MIOS_WRAPPER_DEFINES = -DSTACK_HEAD=0xeff -DSTACK_IRQ_HEAD=0xe3f p18f4620.lkr: DATABANK NAME=gpr3 START=0x300 END=0x37F ... DATABANK NAME=stack START=0xE00 END=0xEFF PROTECTED I.e. I removed the stack at 0x300 and moved it to 0xE00. Note that the IRQ stack is still only 64 bytes large, and the normal stack 3 times that. Is that OK so far? IRQ routines don't call into LCD routines, or do they? Would you make both stacks the same size? Programming close to the bare metal is fun, but the fun starts wearing off...

Thanks, that explains it pretty much. I'll report on my progress, as soon as I get to it. :thumbsup: Ralph

Hi all, I am building a controller for a DB60XG card using a midibox core8 unit (PIC18F4620) and a T6963C-compatible GLCD (though TK advises against using it). I wrote my own driver in C, and it appears to work fine so far (graphics and text). My only issue so far is that I had to bypass the MIOS GLCD initialization sequence to have full control of the T6963C (and to save memory of the MIOS graphics routines and fonts that I don't use). This would be fine by me, but now I don't see the MIOS copyright message at startup anymore, which is somewhat unsatisfactory. I tried different methods such as enabling the text mode of the T6963C, which did show the copyright message but left the device in a state where I didn't see my stuff. I also tried to route the USER_LCD_PrintChar function through my routine, but get only garbage on the screen. Here's my question (finally...): What is the initialization sequence in MIOS, i.e. which of the following functions is called when? USER_LCD_Init USER_LCD_Clear USER_LCD_PrintChar (to write the copyright message) Init (within main.c) DISPLAY_Init (within main.c) Note that the init and clear functions call into my own C routines which appears to work fine. Any advice would be appreciated. Thanks, Ralph