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

JimmyDansbo · Post by **JimmyDansbo** » Fri Jan 22, 2021 6:06 pm

You could change your original code to something like this:

Quote

draw_panel:

   lda   panel_data_length

   sta   r11

   ldx   #0

@loop:

   cpx   r11

   beq   @end

   lda   panel_data_x, x

   asl

   sta   VERA_ADDR_L

   lda   panel_data_y, x

   sta   VERA_ADDR_M

   lda   panel_data_char,x

   sta   VERA_DATA0

   lda   panel_data_col, x

   sta   VERA_DATA0

   inx

   jmp   @loop

@end

   bra   @end

panel_data_length:

   !byte   $0C

panel_data_x:

   !byte $03,$04,$06,$07,$05,$02,$08,$03,$07,$04,$06,$05

panel_data_y:

   !byte $01,$01,$01,$01,$02,$02,$02,$03,$03,$04,$04,$05

panel_data_char:

   !byte $53,$53,$53,$53,$53,$53,$53,$53,$53,$53,$53,$53

panel_data_col:

   !byte $04,$04,$04,$04,$02,$02,$02,$01,$01,$08,$08,$0A

This way you only increment X once each iteration and you can avoid using Y.

Looking forward to seeing what you make of it.

Happy Coding ?

m00dawg · Post by **m00dawg** » Sat Jan 23, 2021 12:31 am

I hadn't though of that but yep it sure simplifies some things and results in smaller code. I managed to get it working my old way. It's probably not efficient. I did it by creating a 16-bit add function so I could easily add addresses. Here's the chunk of code that's relevant I think:


	; Draw Characters from Byte Array
; r0 = pointer to data
; r1 = offset to add for after reading 4 bytes
; r2 = 16-bit add result
.proc draw_characters
  DATA = r0
  OFFET = r1
  RESULT = r2
draw_panel:
  lda #04
  sta r1
@draw_char:
  ldy #0
  lda (DATA),y      ; x coord
  cmp #$FF          ; if the value is FF, we are at the end so we're done.
  beq @end
  asl               ; shift because X coords are by two
  sta VERA_addr_low
  iny
  lda (DATA),y      ; y coord
  sta VERA_addr_med
  iny
  lda (DATA),y      ; char
  sta VERA_data0
  iny
  lda (DATA),y      ; color
  sta VERA_data0
	; Move the reference of the character array by 4 bytes
@skip_pointer:
  jsr add16
  lda RESULT
  sta DATA
  lda RESULT+1
  sta DATA+1
  jmp @draw_char
@end:
  rts
.endproc

`add16` being the 16-bit function. Nothing special there. The "simple" program to test things is now has 9 includes haha. But I also write a print string routine. It (probably poorly) converts from PETSCII to Screencodes so one can use ASCII strings with the assembler. It also lets you specify and x,y and the color (of the entire string). That plus other odds and ends. The actual full test code is 'drawchars.asm' in my repo here:

https://gitlab.com/m00dawg/commander-x16-programs

It pulls stuff from the libraries folder. Each file is a single routine so there's a few of them. Kinda makes it harder to paste the entire code but I think the meat and potatoes are above.

That said, I hadn't thought of multiple arrays until you mentioned it so I'll have to ponder how this could be useful for both storing static character data as well as how I might go about structuring files. Messing with files is the next thing on my list to do...

JimmyDansbo · Post by **JimmyDansbo** » Sat Jan 23, 2021 7:06 am

It is very common to split a multibyte array into multiple singlebyte arrays on 8-bit platforms because of the extra work that comes with having to work with values larger than what 8 bit can hold.

When you store the data in a file, it will essentially become 1 large single byte array. When you load it into memory, you will only have the start address to work with, but if you define your data length in the file like in your code, you can use that to calculate the starting point of each array/section.

Like this:

Quote

Load File into RAM at some_address

Load 1st byte from some_address and store as data_length

panel_data_x=BaseAddress+1

panel_data_y=panel_data_x+data_length

panel_data_char=panel_data_y+data_length

panel_data_col=panel_data_char+data_length

....

This way you only have to do the 16 bit addition 3 times.

You might be able to find a bit of inspiration from my placeholder for random Commander X16 stuff: https://github.com/JimmyDansbo/cx16stuff

m00dawg · Post by **m00dawg** » Sat Jan 23, 2021 4:47 pm

Aha yep that makes a lot of sense. And yep I'll definitely peruse your code! That's been very helpful to do. Yesterday I was diggin throguh PetDraw, ChaseVault and x16-edit to figure out how to do loading routines and working with files. That was very helpful. Definitely a gap in the docs on how some of these Commodore kernel routines work. I've only managed to dig up basic summaries when searching for them online. I suppose I ought to document some of these and maybe put in a PR to the x16-docs repo...

But anyways back to the arrays! If I can bend your ear slightly, it sounds like multi-arrays is the better option for when the array lengths are fixed. Is there a trick for when you might have variable data? I don't want to get too much in the weeds here, since this thread is about how to mess with UIs, but while I was planning out a music tracker, I realized early on I'll likely need to use a sparse file format. That is, I only store row/channel data if there is data to store. That means each pattern will be of variable length, and so will each row. There are end-of-row and end-of-pattern markers so we know when these end, but their lengths could be all over the place.

I would guess here there isn't an elegant solution, other than unpacking the pattern into an unsparse format (which I'll likely need to do when editing a pattern). There the data would be fixed (effectively a matrix of rows x channels, although originally I was going to allow for a variable number of effects which complicates things) so multi-arrays could work well there. Although to support all 25 channels of sound on the X16, a normal 64 row pattern would still exceed 8k so I'll have to contend with banking.

JimmyDansbo · Post by **JimmyDansbo** » Sat Jan 23, 2021 5:35 pm

42 minutes ago, m00dawg said:

Definitely a gap in the docs on how some of these Commodore kernel routines work. I've only managed to dig up basic summaries when searching for them online. I suppose I ought to document some of these and maybe put in a PR to the x16-docs repo...

I belive that the C64 KERNAL API is not documented for the CX16 as it is already well documented in the C64 programmers manual. You can find KERNAL API calls and PETSCII values here: https://cx16.dk/

46 minutes ago, m00dawg said:

Is there a trick for when you might have variable data?

I don't quite understand the question. Maybe you could start a new thread regarding this topic? I think I can help in the understanding if only I understand your data layout.

m00dawg · Post by **m00dawg** » Sat Jan 23, 2021 5:39 pm

Oooh yeah that's extremely helpful thank you! I was only able to find, via Googling, just quick summaries of the kernel codes which is probably ok as a reference, but as someone new to 6502 and the commodore kernel, it was bit lacking. cx16.dk is a wonderful resource by comparison! Awesome!

For the file format question, yep, I have a thread for my tracker ideas that I can @ you on. It's also here:

JimmyDansbo · Post by **JimmyDansbo** » Sat Jan 23, 2021 9:08 pm

Btw, I find these links extremely useful when programming for the Commander X16

6502 Reference

65C02 Reference