Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/27/2013 in all areas

  1. Hi there, I am a bit out of luck these days, last week or so I burned a 4x20 OLED (looking for a good LCD replacement for the MB6582). Well, SID happens :-), as I always wanted a VFD in the MB6582 anyways, I have ordered the Noritake CU20045-UW5J. Good news is, it will fit the MB6582 quite nicely without the need for a riser card and also I did not burn it just yet :-)... I´ve connected and wired it up in 4-bit mode to the MB6582, as usual. When turning it on (with the default mb6582.hex firmware) it shows very scrambled characters, looks like it has not been switched to 4-bit mode by the default display initialization routine. Consulting the datasheet, the first thing that is being sent to the VFD apparently needs to be the "Function Set to 4-bit mode" command. Here is the relevant section: 7.7.1 Function Set Command 20H to 3FH This instruction initializes the system, and must be the first instruction executed after power-on. So, I´ve ported the 4-bit lcd display routines from the MIOS basic driver to modules/app_lcd/clcd/app_lcd.inc (which by default contains an eight-bit driver), changed the initialization sequence to really send 0x02 nibbles at first (4-bit mode), have included the changed app_lcd properly, set the DisplayType to 7 (in main.inc) and have verified that this code really is executed (tested that by playing around with the initialization stuff). With the changed driver, I do get improved character output, but only some characters look ok, other characters are wrong (the "big D" as in MIDIbox is ok). So, changing to "my" 4-bit driver improved things a little and that indicates that the display can take a late switch to 4-bit-mode... but now I am utterly confused, if a "D" was written properly to the display, doesn´t that mean I am in 4-bit mode? Maybe I´ve screwed up the driver? Could it be a timing issue, probably with the "LCD_Busy" checking? And is there any other "USER_LCD" 4-bit demo code available, so that I can verify things? Maybe some MIOS-base-level routine sends data to the display before the user initialization and screws things up? Hmm, sorry for all the questions and the confusion! Thanks for any help :sheep: Bye, Peter PS: Thorsten, I´ve also got a 256x64 OLED evaluation display lying around, so if you are into a little bit of display code hacking, just tell me and I´ll come over :-)
    1 point
  2. Hope I didn´t miss anything: a) checkout - use subversion to checkout the latest mios8 sources b) toolchain - manage to compile your own midibox sid -> and test upload mb6582.hex to your first core. c) replace app_lcd.inc in mb6582 directory with your new version (e.g. the downloaded one from my thread) d) adjust main.inc to use custom display type 7, i think. e) adjust makefile to include app_lcd .inc f) test with garbage instructions in new app_lcd.inc, if it is compiled (compiler should be annoyed) g) adjust initialization code in app_lcd.inc h) compile new version i) upload to first core
    1 point
×
×
  • Create New...