36 Character Kernel (redux)

[Omegamatrix]

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

 

 

[Thomas Jentzsch]

Cool stuff. Thanks for sharing too.

[alex_79]

Work perfectly on all my PAL consoles.

Thanks for sharing!

 

[+ZeroPage Homebrew]

The font is incredibly easy to read and I have to commend you on filling exactly 36 characters on each line! The colours look great and I can't wait for people to use the kernel for text adventures or even in game text information!

 

I booted from cold and let it run for 15 minutes and it performed perfectly, it didn't change one pixel on the screen.

 

- James

 

WATCH AT 60FPS:

 

 

[orange808]

Looks good on my machines, Omega.  I'll have to port this one over to Unocart.

Edited February 15, 2021 by orange808

[Omegamatrix]

Thanks for everyone who has tested so far. The goal of this build was to ensure complete console compatibility if possible.

 

35 minutes ago, ZeroPage Homebrew said:

The font is incredibly easy to read and I have to commend you on filling exactly 36 characters on each line! The colours look great and I can't wait for people to use the kernel for text adventures or even in game text information!

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".

 

 

[+Andrew Davie]

15 hours ago, Omegamatrix said:

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.

 

 

 

 

Survived a fiery run through the valley of the hairdryer of death riding upon the glitchomatic 2600 without incident.

 

[+Andrew Davie]

12 hours ago, ZeroPage Homebrew said:

The font is incredibly easy to read and I have to commend you on filling exactly 36 characters on each line! The colours look great and I can't wait for people to use the kernel for text adventures or even in game text information!

 

Agreed on the text adventures. Scott Adams from Adventure International is interested.... I approached him a while back.

The font is Glacier Belle, give or take a pixel, one of the PlusCart optional fonts. It's a beautiful thing.

 

Regarding the 36-char justification - I sense a fellow OCD "sufferer"

 

 

[+Andrew Davie]

13 hours ago, orange808 said:

Looks good on my machines, Omega.  I'll have to port this one over to Unocart.

Before you do that, at least be aware that PlusCart and UnoCart codebases are now combined/reunified.

If you change to a 36 char kernel, then you'll break that reunification effort.

I did make an abortive attempt to use this kernel on the PlusCart, but I couldn't see a way to dynamically change background colour for menu selection (and changing text colour is a no-go because it requires a regeneration of the kernel ROM/binary, which is too slow).

Another way of putting that, the kernel I was working with was (if memory serves correctly) restricted to a black-only background.

PlusCart requires a blue background (+selected item background).

Edited February 16, 2021 by Andrew Davie

[Thomas Jentzsch]

Not sure why changing text color would be impossible on-the-fly, it is read from RAM.

 

The background color is a problem because not all HMOVE blanks invisible. Not sure if this can be fixed.

[+Andrew Davie]

Just now, Thomas Jentzsch said:

Not sure why changing text color would be impossible on-the-fly, it is read from RAM.

 

The background color is a problem because not all HMOVE blanks invisible. Not sure if this can be fixed.

I was thinkng about drawing the characters in inverse, to give menu selection, rather than changing the colour. Still in the mindset of having a background bar highlighting the text. I didn't think through the wording of my message very carefuly; you're right - on-the-fly text colour change is OK. Unfortunately, text colours are very poorly distinguished on non-black backgrounds. The richness doesn't come through compared to black BG because, of course, the colours are mixed 50% with the BG.

[Thomas Jentzsch]

Yes, color mixing with non black backgrounds requires some extra thought. But you could e.g. use a complimentary color for non-highlighted entries resulting into a (more or less) gray font display. And a bright color with a hue close to the background for a highlighted, colored font.

 

Anyway, changing the background color is the better option. But for that the late HMOVE would have to be moved. @Omegamatrix is that feasible?

[+Andrew Davie]

3 minutes ago, Thomas Jentzsch said:

Yes, color mixing with non black backgrounds requires some extra thought. But you could e.g. use a complimentary color for non-highlighted entries resulting into a (more or less) gray font display. And a bright color with a hue close to the background for a highlighted, colored font.

 

Good idea; might work. Discussing colour mixing with @Thomas Jentzsch reminds me of the months of arguments we had on this subject when programming Boulder Dash

[orange808]

7 hours ago, Andrew Davie said:

Before you do that, at least be aware that PlusCart and UnoCart codebases are now combined/reunified.

If you change to a 36 char kernel, then you'll break that reunification effort.

I did make an abortive attempt to use this kernel on the PlusCart, but I couldn't see a way to dynamically change background colour for menu selection (and changing text colour is a no-go because it requires a regeneration of the kernel ROM/binary, which is too slow).

Another way of putting that, the kernel I was working with was (if memory serves correctly) restricted to a black-only background.

PlusCart requires a blue background (+selected item background).

My apologies.  I meant to say, port it into my own ACE game engine.  I have an older version already ported, but I can't use all 36 characters reliably.

 

 

[+batari]

Excellent!

 

I think it's time to use one of these improved character displays for the Harmony menu. This one should work fine as I was using a black background anyway.

I'll probably use 12 lines instead of the 13 so I can keep the Harmony logo in there. I need to make some other changes as well to make it work effectively, but mostly it's usable as it is. Basically, the Harmony logo on top, one line of status text, a horizontal separator line, 10 lines of menu text, a horizontal separator line, then one line of status text on the bottom.

 

Since the Harmony Encore is a mix of conventional hardware (512k RAM) and an ARM chip, it can do true co-processing, letting the 6507 run freely in a 4k bank while the ARM can run code, so a spinner isn't needed. To make it work I would want one of the banks to be able to display some portion of the menu without switching banks (while the ARM is loading data from SD, for instance) and do away with the spinner, and make it work more like Concerto where the screen is always active.

 

So what I would need is one of the 4k banks to handle the kernel overhead (overscan, vblank), the Harmony logo, and the top line of the menu and the bottom line (both frames, of course.) That should fit in 4k I would think?

 

Also I think that batari Basic probably needs a text kernel at some point with actual PRINT statements! But before that would happen, this engine would best be put in a loop, reduced to one bank if possible and use the CDFJ or DPC+ fetchers instead of being unrolled and spanning several banks as it is.

 

I wish I had more time, otherwise I would get started on them today...

[+D Train]

10 hours ago, Andrew Davie said:

Scott Adams from Adventure International is interested.... I approached him a while back.

WOW.

[Omegamatrix]

15 hours ago, Thomas Jentzsch said:

Anyway, changing the background color is the better option. But for that the late HMOVE would have to be moved. @Omegamatrix is that feasible?

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.

 

 

6 hours ago, batari said:

Excellent!

 

I think it's time to use one of these improved character displays for the Harmony menu. This one should work fine as I was using a black background anyway.

I'll probably use 12 lines instead of the 13 so I can keep the Harmony logo in there. I need to make some other changes as well to make it work effectively, but mostly it's usable as it is. Basically, the Harmony logo on top, one line of status text, a horizontal separator line, 10 lines of menu text, a horizontal separator line, then one line of status text on the bottom.

 

Since the Harmony Encore is a mix of conventional hardware (512k RAM) and an ARM chip, it can do true co-processing, letting the 6507 run freely in a 4k bank while the ARM can run code, so a spinner isn't needed. To make it work I would want one of the banks to be able to display some portion of the menu without switching banks (while the ARM is loading data from SD, for instance) and do away with the spinner, and make it work more like Concerto where the screen is always active.

 

So what I would need is one of the 4k banks to handle the kernel overhead (overscan, vblank), the Harmony logo, and the top line of the menu and the bottom line (both frames, of course.) That should fit in 4k I would think?

 

Also I think that batari Basic probably needs a text kernel at some point with actual PRINT statements! But before that would happen, this engine would best be put in a loop, reduced to one bank if possible and use the CDFJ or DPC+ fetchers instead of being unrolled and spanning several banks as it is.

 

I wish I had more time, otherwise I would get started on them today...

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.

 

 

[freshbrood]

This looks awesome. Can this be used in VBatari Basic for the 2600?!

Edited February 17, 2021 by freshbrood

[Omegamatrix]

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

 

 

 

[+Andrew Davie]

8 minutes ago, Omegamatrix said:

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.

 

Remarkable. Will test/review soon and hopefully I can get it into PlusCart!

Edit: nevermind - the menu in PlusCart is dynamic. 

Still.... amazing.

Edited February 18, 2021 by Andrew Davie

[Omegamatrix]

@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.

 

 

[+Andrew Davie]

2 minutes ago, Omegamatrix said:

@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.

Yes after I posted I thought "mmh, chaing BG between lines should be simple" you just beat me to modifying my post again

Would be nice to get this into PlusCart; I'm still recovering from the last kernel mod... will tackle soonish.

[Omegamatrix]

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.

[+batari]

28 minutes ago, Omegamatrix said:

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.

Awesome! I'll start working with it when you switch back to STA. (If you are, that is.)

 

I am not 100% sure how it all works though. It's clear what the graphics data is, but what is the "morph" and "bit 0"?

[Omegamatrix]

23 minutes ago, batari said:

Awesome! I'll start working with it when you switch back to STA. (If you are, that is.)

 

I am not 100% sure how it all works though. It's clear what the graphics data is, but what is the "morph" and "bit 0"?

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.