5x7 dot matrix screen

Talk about your programs in progress. Discuss how to implement features, etc.
Forum rules
This section is for testing Commander X16 programs and programs related to the CX16 for other platforms (compilers, data conversion tools, etc.)

Feel free to post works in progress, test builds, prototypes, and tech demos.

Finished works go in the Downloads category. Don't forget to add a hashtag (#) and the version number your program was meant to run on. (ie: #R41).
User avatar
edrive
Posts: 34
Joined: Mon Jan 18, 2021 8:03 pm
Location: Germany
Contact:

File Download 5x7 dot matrix screen

Post by edrive »

Last update: Insert mode

Try It Now!

DOTMAT8.PRG
#R46 DOT MATRIX V8
(15.59 KiB) Downloaded 74 times
#R46 DOT MATRIX V8


dotmatrix_random_menu.png
dotmatrix_random_menu.png (26.17 KiB) Viewed 14006 times

See comments in last post.

;======= vv initial first posting vv =======

Hello + Happy New Year!

;

Ever thought your 80 column screen with 8x8 pix characters is to much?
This program will reduce your screen to 20x10 characters at nice 5x7 dots only ;-)
Make your screen look like a HD44780 LCDisplay or like a schedule table seen in public transportation.

Since I preordered last October I'm trying to learn programming the X16/65C02.
So here is my very first program I've ever put online.


The only thing that it does is to let you write some characters on the screen.
While you can choose from some color settings and 4 dot styles.
Each character is 48x32 pix.

The program makes no use of any external or internal font and doesn't load any assets either, which keeps the PRG size small (<5K).
Instead it creates a tileset of just seven 8x8pix basic tiles by some code.
These tiles are then put together in a Layer0 map to create something that looks kind of similar to characters, while making intensive use of vertical&horizontal flipping.
To achieve the dotmatrix effect a mask is applied in Layer1, letting you only see the dot part of the hard to read blocky writing in Layer0.
Characters are stored in pattern tables - telling the computer which of the basic tiles to use and how to flip them.
There are 2 pattern tables. One for the upper left corner and one for the middle left of each character consisting of 4 tile assignments. A third table assigns 6 of these patterns to a character (also using flipping of now complete patterns).

Cursors are done as sprites.

At the moment only an ASCII subset of 96 characters is supported.

Keys:
All keys with chr$ values from $20 to $7F will put something on the screen.
Cursor (arrow) keys will move the cursor.
'Home/Pos1', 'End', 'Return/Enter', 'Backspc', 'Del' will do at least something similar like one expects.
No control characters like <lF>, <cr> or white spacing are supported.
F1 shows the avaliable functions keys.


Things to be aware of:
When starting it tries to load the file "DOTTEXT.TXT".
In case it fails, it will then save an empty "DOTTEXT.TXT".
Which can be overwritten with the user text by hitting F2.
Text is fixed to 200 characters.
Filename and device (#8) are hardcoded.
So far the only way to load a previously saved text is to restart the program.

Since PETSCII characters aren't supported (yet), it sets the X16 to ISO mode.

Program runs in 640x480 @8bpp mode, while not affecting the color palette.
It assumes that the default palette is present in VERA.

Best way to test is to put some characters on the screen and toggle through the 8 presets by hitting F4.
When using F6 or F7 it is likely to get something inverted, hard to read.
Try F6 and F7 subsequently or F4 to take you back to a preset.


Issues:
Sometimes the cursor and some F-keys aren't reacting immediately.
(need to learn more on the CBM style input things or maybe a x16emu host system issue)

Would love to hear if this is running elsewhere - if at all?
Especially if and how the keyboard responds.
Please consider this as an early 'test/proof of concept/programming exercise' version.

Program is written in assembly using cc65 (V2.19) and x16emu (R46) (on an OpenSuse system).



here some screenshots:
x16emu-2024-01-06-20-11-47.png
x16emu-2024-01-06-20-11-47.png (10.78 KiB) Viewed 44921 times
x16emu-2024-01-06-20-08-51.png
x16emu-2024-01-06-20-08-51.png (10.5 KiB) Viewed 44921 times
x16emu-2024-01-06-20-13-31.png
x16emu-2024-01-06-20-13-31.png (9.91 KiB) Viewed 44921 times
Last edited by edrive on Fri Mar 01, 2024 12:42 am, edited 17 times in total.
User avatar
desertfish
Posts: 1038
Joined: Tue Aug 25, 2020 8:27 pm
Location: Netherlands

Re: 5x7 dot matrix screen

Post by desertfish »

Very nice, I like cycling through the various presets, good job!
User avatar
edrive
Posts: 34
Joined: Mon Jan 18, 2021 8:03 pm
Location: Germany
Contact:

Re: 5x7 dot matrix screen

Post by edrive »

x16emu-tu.png
x16emu-tu.png (9.48 KiB) Viewed 44889 times
TomXP411
Posts: 1720
Joined: Tue May 19, 2020 8:49 pm

Re: 5x7 dot matrix screen

Post by TomXP411 »

Nice. I've been considering doing pseudo-emulation of the Tandy Model 100, which looks a bit like
Virtual T.png
Virtual T.png (5.64 KiB) Viewed 44858 times
The Model T has 40 columns x 8 rows, and the controller is literally 4 20x4 character LCDs bonded together. This makes me want to try to do something like that on the X16.

and for pure silliness, here's my Fake Commander M100 screen:
Commander 100.png
Commander 100.png (28.9 KiB) Viewed 44851 times
It would be really interesting to see what would happen if I used your method, but with the pixels 1/2 of the width and height.
User avatar
edrive
Posts: 34
Joined: Mon Jan 18, 2021 8:03 pm
Location: Germany
Contact:

Re: 5x7 dot matrix screen

Post by edrive »

Like your idea also. Glad to see, that I'm not the only one ;)
The only difference from your simulation to your upper screen are the gaps between the dots.

No matter what method is used, one needs more space in terms of pixel for each character to get the gaps.
Because we have a limited resolution, the only way is to go big.
A gap size of one pixel and a dot size of also 1 pix makes characters look kind of spread around and thinned out.
In your upper screen the dots take more space than the gaps.
Meaning dots need more pixels than gaps, letting you end up even going bigger.

Unfortunately my method doesn't scale down - at least not, when relying on my basic tile set.
The program is only using these seven 8x8pix basic tiles in Layer0:
basic_tiles.png
basic_tiles.png (770 Bytes) Viewed 44817 times
Because they are so simple, creating them by some loops is very easy and the code is far less than ready to use bitmap definitions.

To make a character, 4 of these tiles are combined to a pattern and 6 of those patterns make one character.

To go smaller, I would need to shrink these tiles.
But there aren't any smaller, say 4x4, tiles or mapping available.
So the next idea would be to combine 4 basic 4x4 'pseudo' tiles into one 8x8 real tile.
But that leaves me with the problem to carry all other tiles in almost all other combinations within my one basic tile.
Not even that, the other tiles may also be in different flipped positions. Creating them all by code would be at least a challenge.

A way to go might be to have what I'm using as patterns as ready to use bitmap based tiles.
So far the program uses 25 patterns for the corners and 54 for the midsections.
In total this means ca. 80 8x8 tiles in case I want to shrink to half size.
Should be at least possible to put these into VERA.

The disadvantage would be to have one complete new tile for each new pattern, in case one wants to extend the character set. While with my method takes just 4 bytes for every (new) pattern.

To get an idea here is an example how my patterns look when combined to characters.
This is what my program actually creates in Layer0:
hw_nomask.png
hw_nomask.png (7.62 KiB) Viewed 44817 times
After applying a mask in Layer1 it turns into this:
hw_mask.png
hw_mask.png (7.32 KiB) Viewed 44817 times

I will take your idea into consideration for future versions.
TomXP411
Posts: 1720
Joined: Tue May 19, 2020 8:49 pm

Re: 5x7 dot matrix screen

Post by TomXP411 »

Yeah, the simulated LCD display is actually a bit less dense than the real thing. I actually turn off the dot spacing when using Virtual T, because it’s a little distracting. The other thing thst makes the two look different is the character set. Tandy used a 6x8 character cells, so the characters are 5 pixels wide. This makes for a 240x64 bitmap screen, which would have to be rendered as a bitmap to work. That’s given me some ideas, though. :)
User avatar
edrive
Posts: 34
Joined: Mon Jan 18, 2021 8:03 pm
Location: Germany
Contact:

Re: 5x7 dot matrix screen

Post by edrive »

Just want to let you know that I found a way to automatically generate a new tiles set from my old pattern definitions, allowing to have an additional 40x20 character mode.
The new tiles set combines 4 of my previous basic tiles into one single tile (where each former 8x8 tile takes now only 4x4 pix within a new 8x8 pix tile).
This forces me to have a lot of combinations ending up having about 80 more tiles in VERA (for one dot color only).
Even though the PRG file is relatively small and still doesn't load any assets (has now grown from 4,5K to 6K), it now eats up almost the complete VERA RAM.
Code is too buggy at the moment, so no upload. Screenshot is just a first impression.
dotmatrix_screen_40x20mode.png
dotmatrix_screen_40x20mode.png (44.58 KiB) Viewed 37787 times
User avatar
edrive
Posts: 34
Joined: Mon Jan 18, 2021 8:03 pm
Location: Germany
Contact:

Re: 5x7 dot matrix screen

Post by edrive »

Here's a new version with some major changes and new features:
DOTMAT.PRG
#R46 DOT MATRIX screen for X16
(7.76 KiB) Downloaded 211 times
Major changes:
The program now supports a new mode with 40 * 20 characters while each character takes 16x24 pix.
(When in "old" 20*10 mode characters are 32x48 pix).

Hitting F11 toggles between modes.

For the 40 * 20 mode I had to reduce the available dot colors.
Due to the now small dot size, different dot styles won't work.
So F5-F8 behave slightly different depending on the mode.

The text file created/saved is now 800 byte (without header bytes) - even in 20*10 mode.

An animated intro screen has been added.

For those, who love those blinken lights ;-):
As long as the intro screen is shown, the animation may be restarted with F3.

Any (keyboard) key skips the intro.

Additional features:
F1 now also shows the available character set, when hit twice/subsequently.
TAB-key now moves the cursor 4 positions to the right (if possible).

Bugfix:
The character codes for $3C and $3E where mixed up and showing arrows instead of '<','>'.

Last but not least:
Program is renamed to "DOTMAT.PRG".
Runs on #R46.
Text buffer is always 800 bytes (taking 40*20 characters).
This means, that when in 20*10 mode you may store things not actually seen...

The program size has almost doubled to ca. 8K.
It occupies some 3K extra, when loaded.

Besides that, mostly everything mentioned in my 1st post still applies.

DOT MATRIX 40*20 example screenshots
DOT MATRIX 40*20 example screenshots
DOTMAT_40x20_mode.png (32.02 KiB) Viewed 29539 times
User avatar
edrive
Posts: 34
Joined: Mon Jan 18, 2021 8:03 pm
Location: Germany
Contact:

Re: 5x7 dot matrix screen

Post by edrive »

Just re-upped the latest version as a quick fix: DOTMAT3.PRG.
(see first post)
It had some issue when hitting F3 during the intro.
User avatar
edrive
Posts: 34
Joined: Mon Jan 18, 2021 8:03 pm
Location: Germany
Contact:

Re: 5x7 dot matrix screen

Post by edrive »

Version "DOTMAT4" tries to smoothen the cursor key responsivness.
Not knowing it better, in previous versions I kind of used the joystick keys to keyboard mapping only.
Hope I fixed that.
(But since I don't have the real hardware (yet) and no working joystick passthrough to the x16emu,
I can't tell how this works out, when having one connected.)

As a new gimmick:
The logo may be turned on - but only on pages at 20*10 mode.
It allways overlays the text ...for the moment.
Unfortunately the logo can't be centered, unless it looks totally screwed up.

Some remarks on the recently added functions:

Since the program now has a menu and a simple sequencer, the key behavior might be different.

When in "normal" mode, that is when you can write text on the screen,
as usual, F3 delets the text from the actual page.
F4 toggels between 40*20 and 20*10 characters mode, but stays on the same page.
All other F-keys either enter a menu or are unused.
Page up / down moves to next or previous page.

When a menu is active, only the listed buttons will work, ESC-key will exit the menu.
Except - in most cases - the F1-key takes one to the "help / main menu".
When marked with "->" the action takes place directly and also exits the menu.

Menus are shown in the same mode/color settings as the actual page.
Which might be kind of unusual, especially when you managed your color settings to something unreadable.
I thought of introducing a "take me back to something normal button", but I discarded it as part of the game ;).
In case you're completely lost, hit (blindly) ESC, then F11, then F4 (and optional finally F1).
Or better: Keep on toggling colors...

When a sequence is running, only the ESC or F5-key will stop the sequence.
While ESC exits to normal mode, F5 will exit into the sequence menu.
Space pauses/resumes the sequence.
The sequence starts (F5) with the page that was last used in normal mode.
There are no settings for sequence timing so far.
A small animated sprite may be activated (shown in the lower left corner), as a reminder that a sequence is running - in case of having only empty pages.

I haven't found time for working on the load/save file handling.
It still saves just 800 byte (no CBM header) from the actual page.
At least the save/load functions may be used as a clipboard via the file system to copy text from page to page.

A "show non-printables" option may be activated.
This applies to characters with chr$ values of <32 ($20) or >=128 ($80).
It's more intended for testing the program itself to check if any invalid characters have been generated.
You may recognise this in case you edit DOTTEXT.TXT with an external editor.
Non printables are shown as:
non_print_x.png
non_print_x.png (613 Bytes) Viewed 22879 times
And in case the value is 0 as:
non_print_0.png
non_print_0.png (613 Bytes) Viewed 22879 times
Post Reply