Text drawing libs? (ala ncurses, Turbo Vision)?

[m00dawg]

Did the C64 and the like ever have a common TUI like Turbo Vision or ncurses? Turbo Vision was mentioned in passing in this thread, and that got me thinking that's something that could be common to a lot of non-game/productivity apps and could be useful on the X16.

Thinking about my probably too lofty goal of a music tracker, at least some of what I might use could be common to other TUI based apps such as menus, text boxes, text overlays, text scrolling within a box/window, etc.

Of course I can template out UI designs in something like petdraw16 but that wouldn't really work for a fluid UI where I might want to change the width of one of the channels (to show more or less effect columns for instance). I think having routines to draw the UI might be more efficient?

Just mostly thinking aloud of something folks other than myself might be able to use and before I go down some bespoke solution wondering if there is some possibility to combine UI efforts there perhaps (though my 6502 skills are in their infancy admittedly).

[TomXP411]

AFAIK, there was never a Turbo Vision like UI for the C64. The C64 didn't have a mouse as standard hardware, and the 1351 was actually fairly uncommon and relatively expensive for what it was... and GUIs like TV are really fairly awkward to use with just a keyboard. It's certainly possible, but it's frustrating and kind of pointless... there are definitely better ways to structure menus for keyboard based input. 

(I'm assuming you are talking about the psuedo-GUI used in Borland's DOS IDEs.)



There was also a similar system bundled with Visual BASIC for DOS, which was super easy to use and made DOS GUIs very simple to create. 

I seem to recall one or two Commodore programs that used similar text-based GUIs, but nothing was ever available as a pre-packaged toolset. If you're interested in something like this, you'll probably have to build it from scratch - because anything developed when the C64 was king is likely to be based on obsolete practices and standards anyway, not to mention the fact that the Commander architecture has diverged far enough that revising an existing Commodore based library is likely to be as much effort as a ground-up development effort.

 

[m00dawg]

Yep something like that...and gosh I hadn't thought about text based mouse support but actually I did use the mouse quite a bit in Impulse Tracker and definitely use it in FamiTracker and Deflemask. I actually use it more for those, which I don't consider an ideal UI construct for a tracker but haven't mastered all teh shortcuts fully. That's one great thing about Impulse Tracker. Perhaps slightly less tidy interface but an awful lot of it could be used via just the keyboard (granted with some reaching up to the F keys).

Anyways yep realizing a full tracker has a lot of moving parts that could be tackled somewhat independently, the UI being certainly a rather big one (and arguably the most important).

[JimmyDansbo]

I worry that creating a library to provide TUI functionality might become to heavy? In any case it will be more resource intensive than something written specifically to an application. When that is said, some of my fondest memories are writing code in those Borland TUI's so I would love to see something similar on the Commander X16 platform and I might even be able to help out in creating such a library...

[m00dawg]

1 minute ago, JimmyDansbo said:

I worry that creating a library to provide TUI functionality might become to heavy? In any case it will be more resource intensive than something written specifically to an application. When that is said, some of my fondest memories are writing code in those Borland TUI's so I would love to see something similar on the Commander X16 platform and I might even be able to help out in creating such a library...

I worry about that too, though it might depend on where it lives and what all that it does. Like having something as simple as a "Draw PETSCII Box" routine that draws a box given top-left and bottom-right coords and positions the cursor.

It's complicated by likely wanting to interface directly with VERA here for speed and other functionality (e.g. scrolling) over the kernel routines, but, on the pro, that means some of this code might not always be needed to be resident in low RAM. It could live in hi-ram maybe or parts of it even on disk. Once the screen is drawn to VRAM, that code space could be free'd up until it's needed (though granted that in it of itself isn't an easy solve).

Hmm or actually, I wonder if taking a page from Chase Vault can be done here where the various UI screens are composited in VRAM and then jump-scrolled to. That would work for the static bits of a UI. In my case the main screens like the pattern view, order view, instrument details view, etc. Though I also need some of this space for the visual pattern buffer (for scrolling during playback - though I'll have to see how fast I can push the next pattern into VRAM...)

[TomXP411]

2 hours ago, JimmyDansbo said:

I worry that creating a library to provide TUI functionality might become to heavy? In any case it will be more resource intensive than something written specifically to an application. When that is said, some of my fondest memories are writing code in those Borland TUI's so I would love to see something similar on the Commander X16 platform and I might even be able to help out in creating such a library...

The computer definitely has enough power to run something of that scale. I ran Turbo C++ on my 8MHz 640K XT clone, and the Commander will arguably be about 2-3x faster than that machine, for most purposes. 

I've been examining KickC over the weekend, and I've been adding some libraries to handle disk I/O. With the open nature of the libraries and the quality of the assembly code it generates, that might be a good platform for developing windowing libraries. 

** update: after looking at the assembly KickC generates, I don't think it's the best option for ROM resident routines, although I think its console I/O code is more than enough for writing statically linked code. 

 

[m00dawg]

I was playing around with some things yesterday with drawing lines and boxes. And it's fun - I'll keep doing that as it's good practice and there might be times I want to draw a dialog box or something where programmatically drawing a box could make sense perhaps.

But then I thought this morning - it might be more efficient, at least in system RAM, to store this as data. Instead of instructing the computer to draw a box starting a position 4,2 with length 6,6; I could just read character data from a file. The file could just be something like the x/y position, character, and color. In that context, it only draws what is in the file so could be used to draw over stuff rather than the entire screen buffer. But then this requires routines to read files off disk which itself takes some space though a routine to read 4 bytes and tend that to VRAM doesn't seem bad at all.

For a very fluid sort of UI, I don't think above may help much, but for apps, like some sort of tracker (say one that looks a bit like Impulse Tracker), there's largely static panes with information filled within them. So like the main pattern view, the order list, the instrument list, etc. The frames and basic positions of informational labels (like the Song name) are all static.

[m00dawg]

Per the above, here's a simple example of what I was thinking. For folks that know what they're doing this is perhaps simplistic haha but nonetheless, this seems it might possible be a reasonably way to do it? The byte array is what I was thinking could come from a file. So that's the next step - loading it into some temp space, chucking it into VRAM and then calling it good. Once I get that far, next thought is being able to see how much space I have in VRAM to store these panes where I can just jump to different map_base's or pan the screen to jump to those elements.

	 
.include "library/preamble.inc"
.include "library/x16.inc"
.include "library/macros.inc"
; .include "library/printhex.inc"
	; Variables
; VERA Settings
VBLANK_MASK = %00000001
RES80x40 = %01100000
	.proc clear_screen
  CLEAR = $93 ; PETSCI value to clear the screen
  clear_screen:
     ; set background color in a dirty manner (we did not hear that from Greg King)
     ; https://www.commanderx16.com/forum/index.php?/topic/469-change-background-color-using-vpoke/&do=findComment&comment=3084
     lda #$01
     sta $376
     lda #CLEAR
     jsr CHROUT
     rts
.endproc
	start:
main:
  jsr clear_screen
  lda #$00
  sta VERA_ctrl ; Select primary VRAM address
  sta VERA_addr_med ; Set primary address med byte to 0
  sta VERA_addr_low ; Set Primary address low byte to 0
  lda #$10
  sta VERA_addr_high ; Set primary address bank to 0, stride to 1
  lda #RES80x40
  sta VERA_L1_config
	
draw_panel:
  lda panel_data_length
  sta r11
  stx $0
  sty $0
@loop:
  cpy r11
  beq @end
  lda panel_data,x      ; x coord
  asl
  sta VERA_addr_low
  inx
  lda panel_data,x      ; y coord
  sta VERA_addr_med
  inx
  lda panel_data,x      ; char
  sta VERA_data0
  inx
  lda panel_data,x      ; color
  sta VERA_data0
  inx
  iny
  jmp @loop
@end:
  jmp @end
	; number of chars to read in panel data
panel_data_length:  .byte $0C
; [x : y : character : color], [x : y; ,...]
panel_data:
.byte $03,$01,$53,$04
.byte $04,$01,$53,$04
.byte $06,$01,$53,$04
.byte $07,$01,$53,$04
.byte $02,$02,$53,$02
.byte $05,$02,$53,$02
.byte $08,$02,$53,$02
.byte $03,$03,$53,$01
.byte $07,$03,$53,$01
.byte $04,$04,$53,$08
.byte $06,$04,$53,$08
.byte $05,$05,$53,$0A
	 	
		

[JimmyDansbo]

3rd and 4th line after draw_panel: should be ldx #0 and ldy #0 I think?

It seems to me that your panel data is very inefficient, do you really need to be able to set individual coordinates and colors for each character?

Back when I created TUI components for DOS, It would suffice to have a back- and a foreground-color, starting coordinates, width and height. Granted that was just for creating windows and menus.

 

[m00dawg]

Yep those are bugs, worked because I would guess address 0 of the ZP happened to be 0 ? I discovered that later on. I also started converting this to indirect mode since this data will likely be pulled in off disk and placed somewhere in, say, a RAM bank, or somewhere where indirect might be required. I'm not finished with this because of course that's a bit more complicated. A good exercise though! I did get it working but will need to find a better way than I was doing since I can only output about 64 characters because the 'x' register rolls over and that won't do.

The plan there is to basically read 4 bytes, then store the memory address of the 5th byte and then loop. That means x only has to count to 4. If I relegate the drawing to only the visible part of the screen, I can also have a byte terminator (where X is greater than 80 for example) so I don't need to store the byte count.

As far as drawing boxes, yep I originally was doing that. And that way may end up using less total RAM when you account for the UI data plus the drawing routines. Plus it was a fun puzzle so I still might go down that route - for things like a dialog box I think it would be a better solution for instance.

For static UI stuff, using a block of data is easier and I can more readily do things like leveraging the 256 color palette if I want to make the main application window a little fancier and can bake in window titles and headers and things. Having both would arguably be best and then I can figure out what works best for what I end up doing.

It's been fun! The indirect memory stuff, unsurprisingly, has been a little difficult to get used to but I'm slowly getting there!