+Andrew Davie Posted February 18, 2021 Share Posted February 18, 2021 I knew it would be easy Quote Link to comment Share on other sites More sharing options...
+batari Posted February 19, 2021 Share Posted February 19, 2021 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 19, 2021 Share Posted February 19, 2021 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. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted February 19, 2021 Author Share Posted February 19, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 19, 2021 Share Posted February 19, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted February 20, 2021 Author Share Posted February 20, 2021 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 20, 2021 Share Posted February 20, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted February 20, 2021 Author Share Posted February 20, 2021 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. 5 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 20, 2021 Share Posted February 20, 2021 Digitized music might work too. Or is the frequency too low? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 22, 2021 Share Posted February 22, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted February 23, 2021 Author Share Posted February 23, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 23, 2021 Share Posted February 23, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 1, 2021 Author Share Posted March 1, 2021 Meant to post this earlier but ran out of time. Here are two examples of background color changing. 36 Char (20210226_B).zip 3 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 1, 2021 Share Posted March 1, 2021 Very pretty. Next challenge, text colours. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 1, 2021 Share Posted March 1, 2021 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. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 1, 2021 Share Posted March 1, 2021 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 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 1, 2021 Share Posted March 1, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 1, 2021 Share Posted March 1, 2021 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.