Commander X16

1 hour ago, kliepatsch said:

do you plan to make the UI work with the mouse? Or via keyboard? Or do you just want to provide drawing routines and let the user program handle the interactive part?

My plan was to just provide the drawing routines and let the user handle everything else. I do plan to provide a function that can preserve a window so it can be restored late, effectively allowing for popup windows or message boxes.

48 minutes ago, BruceMcF said:

as would scr2p and p2scr.



The second pair would be particularly helpful to experienced 6502 assembly programmers who are not used to the oddities of both PETSCII and Commodore screencodes

I was thinking of having functions that output strings only accept petscii and then convert it to screen codes. Functions that output/use single character will require screencodes, and then provide a couple of very basic functions for converting to/from screen-/petscii-codes.

I am hoping to be able to keep the size of the generic library within 2K so it can be loaded into "golden" RAM. We will see, it might ned a memory bank for it self in the end.

For now it is just under 400 bytes, but not at all complete yet.

Golden RAM is $0400 to $07FF, which is 1K.

1 minute ago, BruceMcF said:

Golden RAM is $0400 to $07FF, which is 1K

You are right, even greater risk it will not fit in golden RAM.

@JimmyDansbo A nice size to aim for with high RAM segment libraries if they do not require 8K is 4K, then you can make two binaries, one for $A000-$AFFF and another for $B000-$BFFF. Similarly 4 binaries with a 2K high RAM segment library.

Another way of adding the generic library would be to add it as a binary at the end of users own source.

For ACME, this can be done with the !BIN statement. Do anyone know if the same is possible with other assemblers?

It's probably for the best to just make it relocatable rather than forcing developers to put it in any particular part of memory. ca65 is really good at letting you do this.

I have already made it relocatable. It does not care what address it is loaded at. All that is needed is to initialize the library by JSR'ing to the base address after load.

If you have loaded the library to $0400, you just JSR $0400 or if you have loaded it to $A400, you JSR $A400.

Afterwards the functions are callable by BASEADDR+2, BASEADDR+5, BASEADDR+8, BASEADDR+11 and so on.

11 hours ago, desertfish said:

• 
  I assume it will have text output in some form (to place text at specific position). It would be nice if it has routines for both screencode and  PETSCII encoding
  


• 
  box drawing/filling with or without a certain border (and optional "pane" title perhaps)
  


• 
  clear screen
  


• 
  setting background and foreground color
  

+1 on those.

 

11 hours ago, desertfish said:

• 
  scrolling a rectangle up by 1 character 
  


• 
  perhaps also scrolling a rectangle down,left,right by 1 character ?
  

I was thinking, the library could provide a "wrapper" to make easy use of the two text layers, e.g. to be able to easily scroll text in a text field (only one at a time, of course) or something. But I don't know how well that fits with a "compact library" idea ?

11 hours ago, desertfish said:

reading a user inputted string from the keyboard (where the input is constrained by certain width to not clobber the screen outside of a certain rectangle/pane) ?

+1 on that, too. This can be an annoying task, especially for beginners like me, and it is great to have a ready-made tool for string input. And I think this wouldn't be too large of a function.

BTW I'll just give a brief overview on how a few aspects of the UI that I made (not claiming that one should do so ... just to give a few extra ideas into the mix)

• 
  I used display lists. That is, lists with information about where to draw what element, that could be processed by a drawing routine.
  
  
  
  • 
    One list with "labels". It contained I think 5 bytes for each entry. The color, the X and Y coordinates and the 16 bit pointer to a zero-terminated string. The end of the list would simply be marked with a 0 as the next color (which would be black foreground and black background, thus safe to assume that no one uses that). There is a routine that draws all of them in one go.
    
  
  
  • 
    One list with control elements such as buttons, checkboxes, drop-down menus and so on. The amount of bytes occupied by each control element differs. Point is, all data necessary for drawing them is in one single list, and there is a routine that draws all GUI control elements in one go. (But control elements can still be redrawn individually if needed)
    
     
    
  
  
  • 
    This approach is quite memory efficient in terms of size necessary to store the actual UI. The code can become messy. But I think this might be the case for any UI in machine language. (Haven't looked at the source of GEOS in detail though, I have to admit)
    
  
  
  
  


• 
  I organized the whole UI in "panels". They are basically rectangular areas containing stuff. E.g. each panel has its own "labels" and "control elements" display lists. There were several benefits from that. Most importantly:
  
  
  
  • 
    Display lists can be kept shorter than 256 bytes for efficient processing. (If a panel contains too much stuff, simply divide the panel into two to shorten the display lists. Didn't happen for me.)
    
  
  
  • 
    Panels could be activated and ordered. A number is assigned to each panel. There is a list of active panels (think of it as a "stack"). A panel appearing further up in the stack is drawn later, so it appears on top of the other panels. And it is checked first for mouse-overs (because it is on top ...). That's how my drop-down menus work. Basically a panel gets activated and deactivated when operating them. Other pop-ups can easily be done in a similar way.
    
  
  
  • 
    It is easily possible to swap out parts of the UI or even the entire UI just by putting a set of different numbers into the "panel stack". Didn't make use of this yet.
    
  
  
  • 
    Panels speed up the process of recognizing what the mouse is currently pointing at. They subdivide the whole UI into groups, so you don't always have to check each and every control element for mouse-over.
    
  
  
  
  

Great initiative Jimmy. I think we all wrote bits and pieces of these type of routines but it would be great to have a library at our disposal.

 

When I was working on something reusable for my needs I was always struggling with really how generic such a library can and should be. I can think of few dilemmas from the top of my head:

Do I support default screen size only or make it generic, specifically Map width is tricky one because if you want to support anything else than 128 tile width the VERA MID parameter is no longer Y dimension and require more checks and bit shifting.

How to handle colors, do I go for standard predefined colors for different objects/widgets or should they always be passed as parameters. If second what happens if you want to draw e.g. frame parts in different colors to represent highlights etc.

Do I allow different variations e.g. can frame be with rounded corners or square corners or perhaps the whole frame can be built with full or half blocks or even custom characters.

Support for Lower case / Upper case PETSCI / ISO and then translations to screen codes

Before mentioned number to text translations

etc.

 

This can lead to a real rabbit hole of options so I suggest not to overthink and to really simplify the first version and only support default screen and very basic functionality and then see where it leads.