36 Character Kernel (redux)

[+Andrew Davie]

I knew it would be easy

 

[+batari]

OK, so looking at this, the below is a bit difficult to work with:

  IF {9} = 0
    lda    #{9}                  ;2  @63
    sta    GRP0                  ;3  @66   {9} = 67 = "_33_34"
    sax    ENAM0                 ;3  @69   clear ENAM0
  ELSE
    lda    #{9}                  ;2  @63
    sta    GRP0                  ;3  @66   {9} = 67 = "_33_34"
    php                          ;3  @69   clear ENAM0 as value above has Zero flag cleared

The problem is that if we ever need to load a zero, the entire memory footprint will shift by one byte. Is there any way to level out memory? I get that it may not be a simple problem to solve.

 

Can we PHA instead of SAX? That would balance out memory.

[Thomas Jentzsch]

5 hours ago, batari said:

Can we PHA instead of SAX? That would balance out memory.

PHA should work here. And a brief test showed no problems.

[Omegamatrix]

PHA is a good optimization. I tested it and it exposed some minor bugs in the existing kernel where the SP was not set between rows, but that is easy to fix and will work fine. Now that the stack is used consistently it opens the door to use PLA inside the kernels instead of LDX #ENAM0 and TXS. That will save some more bytes.

 

BTW I always take advantage of X index register to delay cycles when I can. If the value of X is known using ZP,X saves a byte over using ZP Absolute. There are some areas in the code where I offset the known value of X to do this, and it might not be obvious to others reading the code. Example:

    ldx    #LEFT74_8             ;2  @10
    ldy    #{5}                  ;2  @12
    lda    #{1}                  ;2  @14
    sta    GRP0                  ;3  @17   {1} = CD = "_03_04"
    lda    #{4}                  ;2  @19
    sta    GRP1                  ;3  @22   {4} = QR = "_17_18"
    sta    RESP0-LEFT74_8,X      ;4  @26            saves a byte over using sta.w RESP0

 

 

I've been thinking about the kernel that can be any background color and I don't see nearly enough cycles to use CDFJ at all because it doesn't have X or Y as fast loads. The all black kernel should be able to do CDFJ as it is close to the old examples I did.

 

If we get to bus stuffing the colored background is no longer an issue to reduce into a loop. Who knows with bus stuffing maybe we can figure out how to do 40 characters. I'm not sure what the routine would look like but there would be a lot more cycles available to try and make it work.

 

[Thomas Jentzsch]

1 hour ago, Omegamatrix said:

BTW I always take advantage of X index register to delay cycles when I can.

Why not for "sta.w ENAM0" in KERNEL_2 too? X is LEFT74_8 from KERNEL_1, so you only have to make sure at the beginning of KERNEL_B.

 

But reusing X from KERNEL_1 could save even more. "ldx #LEFT74_8" would become e.g. "ldx #LEFT74_8 | {10}". You would have to modify the two ,X offsets accordingly. And then you do not have to "lda #{11}" in KERNEL_2 and can replace that with a NOP. And finally do "stx ENAM0" and "sta GRP0 - (LEFT74_8 | {11}),X" to save a byte.

 

And maybe the two extra free cycles allow more? There are 2+3 = 5 in total now, enough for changing a TIA register.

Edited February 19, 2021 by Thomas Jentzsch

[Omegamatrix]

9 hours ago, Thomas Jentzsch said:

Why not for "sta.w ENAM0" in KERNEL_2 too? X is LEFT74_8 from KERNEL_1, so you only have to make sure at the beginning of KERNEL_B.

This was something I did think of, but purposely left out because it made the macros less clear as there would be a dependency outside fo them, and I didn't need the savings.

 

9 hours ago, Thomas Jentzsch said:

But reusing X from KERNEL_1 could save even more. "ldx #LEFT74_8" would become e.g. "ldx #LEFT74_8 | {10}". You would have to modify the two ,X offsets accordingly. And then you do not have to "lda #{11}" in KERNEL_2 and can replace that with a NOP. And finally do "stx ENAM0" and "sta GRP0 - (LEFT74_8 | {11}),X" to save a byte.

 

And maybe the two extra free cycles allow more? There are 2+3 = 5 in total now, enough for changing a TIA register.

"ldx #LEFT74_8 | {10}" won't work because {10} uses more than the four lower bits. "ldx #LEFT74_8 | {11}" is an option for kernels that are static and would save 2 cycles.

 

This morning I played around with RESM0 instead of using PHA/PHP to see I could perhaps eliminate the 4 cycles used to reset the stack, however it didn't work out.

[Thomas Jentzsch]

7 hours ago, Omegamatrix said:

"ldx #LEFT74_8 | {10}" won't work because {10} uses more than the four lower bits

I meant to use "R{1}L0x_BIT0_" here. Which does only use bit 1, no? I did a brief test and it seems to work and I got 5 free cycles which could be used to change e.g. the background color every 2nd line.

 

Have you managed to replace "ldx #ENAM0, txs" with PLA?

 

BTW: I am using the following colors:

COL_BACKGROUND       = COL_82
COL_HIGHLIGHT_BK     = COL_86
COL_TEXT             = COL_18 ; yellow as complementary color
COL_HIGHLIGHT_TEXT   = COL_1E ; or COL_AE if you want some color here

 

Edited February 20, 2021 by Thomas Jentzsch

[Omegamatrix]

14 hours ago, Thomas Jentzsch said:

I meant to use "R{1}L0x_BIT0_" here. Which does only use bit 1, no? I did a brief test and it seems to work and I got 5 free cycles which could be used to change e.g. the background color every 2nd line.

 

Have you managed to replace "ldx #ENAM0, txs" with PLA?

 

BTW: I am using the following colors:

COL_BACKGROUND       = COL_82
COL_HIGHLIGHT_BK     = COL_86
COL_TEXT             = COL_18 ; yellow as complementary color
COL_HIGHLIGHT_TEXT   = COL_1E ; or COL_AE if you want some color here

 

I have been able to implement PLA, and made several changes to make the macros more cleaner and save a few minor bytes. I've added in the optimizations to allow for a write. Here is the latest any color background 36 char kernel.

 

 

36 Char (20210220_C).zip

 

 

BTW thanks for the color suggestion too. I am color blind but it is much more readible for me too.

 

 

[Thomas Jentzsch]

Digitized music might work too. Or is the frequency too low?

[Thomas Jentzsch]

Another idea how to save cycles: Use M0 and M1 alternatively! That way you have to update the stack pointer (LDX #ENAM1, TXS instead of PLA) only every 4 lines. I think that should work, no?

 

So that would save 4 cycles every 4 lines. Together with one wasted cycle we would have another 5 cycles free every 4 lines.  

 

This would allow e.g. updating the background in 3 out of 4 lines. Or we could move "lda #RIGHT_8, sta HMP1" to the beginning of KERNEL_2 (before lda #{9}, not 100% sure about the timing). Then there would be 5 free cycles at the end of KERNEL_2 and 5 free cycles at the beginning of every 2nd KERNEL_1. That would allow e.g. changing the foreground colors.

[Omegamatrix]

Alternating missiles is a good idea. I will look at it implementing it sometime in the next few days.

 

I did a quick check of moving "lda #RIGHT_8, sta HMP1" in Stella and it seemed okay. The latest the write can be done though is ending on cycle 19 as A, X, and Y are in use. Might cause an issue, might not. I can easily put in a compile switch to move it around though.

[Thomas Jentzsch]

4 hours ago, Omegamatrix said:

The latest the write can be done though is ending on cycle 19 as A, X, and Y are in use. 

Ending at cycle 21 by my math. Which should be OK because of the 5 cycles earlier HMOVE. It looks OK on my PAL console.

 

BTW: I changed COL_TEXT for PAL into $28 (COL_28 is $38 for PAL). $38 has a slight tint to red.

Edited February 23, 2021 by Thomas Jentzsch

[Omegamatrix]

Meant to post this earlier but ran out of time. Here are two examples of background color changing.

 

 

 

 

36 Char (20210226_B).zip

 

 

 

[+Andrew Davie]

Very pretty. Next challenge, text colours.

[+Andrew Davie]

I'd be happy to spend an extra scanline to get different text colours on each line... but maybe it's possible without that "waste"?

I don't need a new colour on each line of the font -- just at the very beginning so it's all the one (selectable) colour.

[+Andrew Davie]

Just a few notes on the source code.

I downloaded and assembled and it produced a working binary.

But with the following...

 

--- Unresolved Symbol List
NO_ILLEGAL_OPCODES       0000 ????         (R )
vcs.h                    0000 ????         (R )
RowGfx.h                 0000 ????         (R )
macro.h                  0000 ????         (R )
Colors.h                 0000 ????         (R )
--- 5 Unresolved Symbols

 

These appear to be a result of not including quotes around the filenames in the include statements.

I don't know if this should be flagged as an error by dasm -- but something weird is going on here because they're being interpreted as symbols too in this case, and that's wrong. My preference is to flag the lack of quotes as an error.

Secondly, I was looking at how/where the COLUP0 and COLUP1 are set, and came across that it's already done/working from a colour table. Took me ages to find how, though, as I was searching for stuff like "R1_TEXT_COLOR_0" and only finding one occurrence in the files. At first I thought: missing file, but then it clicked... a MACRO is generating the labels/definitions

 

Long story short; possible dasm issue, and code is already doing what I want

 

 

[+Andrew Davie]

Reading the manual, the include directive is not listed as handling the filename without a quote.

I'll flag this on dasm's bug page.

 

[+SpiceWare]

Hmm, I thought we'd fixed that.  It was introduced when I added support for using constants with include while working on SpiceC.  That let me prompt the user and generate a config.h file like this:

 

MENU_KERNEL = "Menu/48pixel.asm"
GAME_KERNEL = "Game/space.asm"
SCORE_KERNEL = "Score/radar.asm"
AUDIO = TIA_ONLY
    MAC DIGITAL_AUDIO
        nop #AMPLITUDE
        sta Sleep3
    ENDM

 

 

Then the main 6507 source file would include the appropriate kernels like this:

 

       INCLUDE SCORE_KERNEL

 

This topic covers the enhancement, the last few replies (17-19) cover it breaking include vcs.h without quotes and how we fixed it.