Front Panel LCD Display

[sunnyboy010101]

I see in several places on the internet the front panel display showing RomWBW and so on, but after building my front panel and just now connecting the LCD panel display (power off, of course) then powering up... nothing.

I verified by turning the pots that backlight is working and I can get a block of output.

So I went looking and re-reading the directions and entered the MBASIC program on the directions to take input from the keyboard and display it on the screen. Running it - it WORKS. 

So the LCD is properly displaying output if I use an MBASIC program. I'm sure I could write a C program (I have the compilers) or even an assembler program to exercise the LCD and/or write stuff to it.

But I'm running the latest RomWBW (v3.4.1) and I thought that it would "do stuff" with the display like I see on the internet.

What am I missing? (i.e. how are others getting that lovely multi-line RomWBW display?)

Thanks

-R

[Wayne Warthen]

Hi,

The LCD Display support in RomWBW was recently added and is only available in the Development Snapshots.  You can upgrade your ROM to the current Developoment Snapthot.  The Development Snapshots are found at https://github.com/wwarthen/RomWBW/releases.

Thanks, Wayne

[sunnyboy010101]

Thanks Wayne.

Now I just have to research ROM programmers and source the programmable ROMS.

-R

[Wayne Warthen]

It is possible to reporgram your ROM in-situ using the FLASH.COM application.  This process is generally covered in the User Guide.  However, it is risky because if anything goes wrong, you won't have any way to recover to a known good ROM.  For that reason, having an EEPROM programmer is much safer.

Thanks, Wayne

[Guido Santer]

Hi. Try upgrading to the current Version. This did the trick for me.

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/fe8647aa-31d2-485b-942e-200a7650997fn%40googlegroups.com.

[sunnyboy010101]

I'm now writing a C program to write to the LCD. My first one worked but didn't use the busy status signal from the LCD, so I'm modifying it to detect the busy signal, but have a question about that.

In assembly the status is read and then left shifted to the carry bit, which is then tested as as part of the 'busy loop'. But reading the Hitachi LCD tech document, it seems the status is really just wait until 0. If that's the case, is the assembly "shift left and test carry" just the most efficient/convenient way to do it for assembler or is it the only way to detect the busy signal? That is, do I really need test against bitmasks or is a simple "test against 0" sufficient?

Thanks,

-R

[Wayne Warthen]

On Friday, November 1, 2024 at 10:10:52 AM UTC-7 sunnyboy010101 wrote:

In assembly the status is read and then left shifted to the carry bit, which is then tested as as part of the 'busy loop'. But reading the Hitachi LCD tech document, it seems the status is really just wait until 0. If that's the case, is the assembly "shift left and test carry" just the most efficient/convenient way to do it for assembler or is it the only way to detect the busy signal? That is, do I really need test against bitmasks or is a simple "test against 0" sufficient?

You must isolate bit 7 of the status register.  You cannot simply test the entire byte value of the status register because the other bits have other meanings.  You can isolate bit 7 with the "shift left and test carry" approach or by ANDing the status value with 0x80.

Thanks, Wayne 

[sunnyboy010101]

Thanks Wayne.

[sunnyboy010101]

I re-read the Hitachi sheet on the LCD display, and decided it was easier for current purposes to just use a small time delay. The program works perfectly now and I was able to write a second one that takes command-line input for the displayed text.

Odd thing though - if I hard-code the string in the C program, then upper and lower case are shown, but using command-line input, the text is converted to all caps when displayed. I'll have to do some reading on the C compiler I'm using and see why it does that.

But it works! (and I'm almost comfortable with ED).

[Wayne Warthen]

The CP/M CCP (Console Command Processor) converts all command lines to upper case.  This happens before the command line is ever seen by your C application.  For compatibility, all of the derivative CCPs do the same thing.

-Wayne

[sunnyboy010101]

Thanks Wayne! I figured as much, but figuring and knowing are not quite the same. If I want to keep lowercase in the display, I'll either hard-code the text in the program (like my v1) or read it from a file (proposed v3).

The current purpose behind this program is that I can call it from my boot batch file (profile.sub) and thus set up the LCD on boot with the current version of RomWBW. I suppose one could even emulate the unix "MOTD" (message of the day) where quotes are randomly grabbed from a file on boot. 

We do something similar as an assignment in my Java Networking course; I have students write a Poem of the Day (POD) finite state machine telnet server.

-R

[Doug Jackson]

Have a look at the lcd.asm source in the current development version of RomWBW.

When you enable LCD support, it displays the current version on the LCD screen.  You can also configure it to display disk access info.

I use Nibble transfers to my LCD in my gm7307 keyboard and LCD driver.

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/3f184e95-a8d1-4939-b0c3-6c65ade3b884n%40googlegroups.com.