Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


Omegamatrix last won the day on November 15 2015

Omegamatrix had the most liked content!

Community Reputation

1,960 Excellent


About Omegamatrix

  • Rank
  • Birthday 02/06/1975

Contact / Social Media

Profile Information

  • Gender
  • Location
  • Interests
    Atari 2600 collecting, playing, programming
    Watching movies

Recent Profile Visitors

40,597 profile views
  1. Meant to post this earlier but ran out of time. Here are two examples of background color changing. 36 Char (20210226_B).zip
  2. I feel this is on the level of a technologcial first, like the first cell phone call. Who would've thought 40 years ago that the 2600 would be part of a chat room???
  3. 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.
  4. 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. 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. "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.
  6. 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.
  7. The STA ENAM0 vs SAX ENAM0 is a simple change. It's in the macro for kernel 2. Here is the updated macro with that fix in place: ; ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ; 00--00--00--0011--11--11----00--00-- MAC KERNEL_2 sta RESP0 ;3 @1 lda #{11} ;2 @3 sta.w ENAM0 ;4 @7 lda #{1} ;2 @9 sta GRP0 ;3 @12 {1} = AB = "_01_02" lda #{5} ;2 @14 sta GRP1 ;3 @17 {5} = OP = "_15_16" ldy #{2} ;2 @19 ldx #{3} ;2 @21 lda #{10} ;2 @23 sta GRP0 ;3 @26 {10} = AB & EF = "_MORPH" This is write is being done early, while still drawing the previous GRP0... sta RESP0 ;3 @29 sty GRP0 ;3 @32 {2} = EF = "_05_06" stx GRP0 ;3 @35 {3} = IJ = "_09_10" lda #{4} ;2 @37 sta GRP0 ;3 @40 {4} = MN = "_13_14" ldx #{8} ;2 @42 lda #{6} ;2 @44 sta GRP1 ;3 @47 {6} = ST = "_19_20" lda #{7} ;2 @49 sta GRP1 ;3 @52 {7} = WX = "_23_24" sta RESP0 ;3 @55 stx GRP0 ;3 @58 {8} = 23 = "_29_30" sta RESP0 ;3 @61 IF {9} = 0 lda #{9} ;2 @63 sta GRP0 ;3 @66 {9} = 67 = "_33_34" sta 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 ENDIF ldx #RIGHT_8 ;2 @71 stx HMP1 ;3 @74 ENDM In the above kernel too you can see cycles 26 to 35 are pretty busy for P0. The GRP0 write just before RESP0 contains bits from {2} and {1}. It actually is updating GRP0 while it is still be written but was the only work around for doing RESP0 at cycle 29. Even still there was one unwanted bit from {2} showing which originally I masked with the ball. That effectively killed the background using a different color than black as the border should remain black to hide the HMOVE comb and even out the screen with PF0. The fix involved moving P0 left by one more pixel, but unfortunately the graphics had to be compensated and Bit 0 of the original graphics from {1} was lost from the shift. However a missile of course could be used a pixel, and I just had to figure out how have 1 copy of the missiles display instead of 3.
  8. Just to explain the kernel changes a little bit to everyone, I'm using SAX and PHP to disable M0 before the first copy is drawn at the end of the line. The last copy of M0 is being used to draw a text pixel that was lost when GRP0 was shifted left by one. GRP0 being shifted left solved the issue of the morphed graphics write showing on the screen. The morphed graphics write was done as GRP0 had to be updated while it was being drawn in order to hit RESP0 at the correct cycle. That's about it. Edit: I just realized I don't need SAX at all. I could simply use STA and have no illegal opcodes. Just tunnel vision from staring at the code to long ha ha.
  9. @Andrew Davie by dynamic/static I meant the screen text, but the colors can always be changed dynamically. Use the joystick up/down to see. The problem with dynamic revolved around using PHP vs SAX. SAX is used when a zero value for a load is known, and PHP is used when the loaded value is not zero (and Zero flag is not set). Anyhow I don't think it is and issue for CDFJ to do dynamic text as with FastJump as it is easy enough to jump between two kernels (one uses PHP, the other uses SAX). With a static text rom the compiler already takes care of it so that is no issue.
  10. Well, I'm eating my own words as I think I figured out a solution to making the background any color. This should be fine for static roms. It could also be used for CDFJ as fastjump could easily take care of jumping between two routines that either do PHP, or do SAX. I take back what I wrote in the message about figuring out a dynamic solution. It is already figured out... just now. Lets hope this kernel is stable. 36 Char (20210217_A).zip
  11. Unfortunately no. I've poked and prodded at this kernel a lot see if background color could be done, but didn't come up with a solution. There may be a kernel that can do it, but I sense it is more like a different approach rather than a little tweak. Just for clarity setting the background color is not the problem. The problem is the ball which then displays two black lines on the screen. Coloring the PF the same as the background looks a little weird too as the HMOVE comb is still on the left. I've tried to remove using the ball altogether but the timing is incredibly tight during the portion of the screen where it is being used. The ball's purpose is only to mask a single pixel. Ibelieve it is easily feasible and just comes down to sweat equity. I was using CDFJ before for the 1008 and 576 character demos and it worked pretty good. The kernels are well suited to CDFJ or DPC+ implementation.
  12. I took a stab at it. Might not be exactly what you are looking for but could give you some ideas. SoftwarePfCollision.zip
  13. Thanks for everyone who has tested so far. The goal of this build was to ensure complete console compatibility if possible. The font is Glacier Belle, and is one of the fonts used on the PlusCart. I edited a few of the characters but otherwise it is unchanged. With a platform like the PlusCart it is easy to load in pre-built roms that function as a single menu screen. When a new screen is needed a new rom is loaded. CDFJ though could build a text adventure game pretty easily. The ARM has no issues making the graphics on the fly. For this demo I wrote a C++ program to make the graphics as there are 12x19x14 = 3,192 defines needed for the one screen. These defines are found in "RowGfx.h".
  14. Hello all, Here is an updated 36 character per row kernel. It should be very compatible with different consoles, but I am hoping @alex_79, @Andrew Davie, and @ZeroPage Homebrew can maybe try to confirm. 36 Char (20210215_A).zip
  15. The impossibility of snow has happened. This just isn't right...

    1. Show previous comments  4 more
    2. doctorclu


      That's interesting.  What is the average temperature there year round?   Figure it would at least get really cold up there.

    3. Omegamatrix


      It's mild as we are on the ocean. Not too hot not too cold. Very comparible to a place like Seattle. Here is what google came up with for averages. For reference 0 degrees is when water freezes. When I converted 20 degrees Celsius it came to 68F.



    4. ls650


      We get the same kind of weather as Vancouver or Seattle: lots of rain, and  temperatures rarely drop below freezing - but when we get an arctic outflow at the same time as wet rain coming in from the Pacific, the two collide and we get a dump of heavy wet snow that can freeze and be quite icy and nasty.


      The snow has been falling lightly since it started Friday night, and is accumulating slowly.  The forecast is for a Pacific front to force out the cold air tonight, and the temp will go up to +5c Monday, and +9c Tuesday.  Then all this snow melts and people get flooded basements...

  • Create New...