20x30, 40x15, 20x15 text mode

[Elektron72]

In the Commander X16 ROM, switching between the officially supported screen sizes is handled by the kernal function screen_set_mode, located in kernal/drivers/x16/screen.s. Prior to returning, this routine performs a JSR to a routine called scnsiz, which is located in kernal/cbm/editor.s. It sets $386 and $387 (labelled as llen and nlines, respectively), then proceeds to set $388 and $389. Specifically, $388 contains the number of lines plus one, and $389 contains the number of lines minus one. Although I am not sure exactly what they do, they are referenced multiple times in the file, so they are likely used for something important.

[Elektron72]

I tried making some changes to the ROM to better support 20x15 mode, and have successfully fixed the issues with the test program. The modified ROM is available at https://github.com/Elektron72/x16-rom/tree/screen-20.

[kelli217]

I think if I were going to use a 20×15 screen, I'd rather just handle it in software for now, as in your recommendations to add lines 52 and 54 rather than make changes to a ROM image that currently doesn't even match what's in Proto2, much less Proto3...

Except that for some reason, the software solution doesn't work.

[Elektron72]

The reason why it doesn't work with the official ROM is because the routines screen_set_char and screen_get_char in kernal/drivers/x16/screen.s are not equipped to handle more than one continuation line. Continuation lines are created when text (whether typed or printed by a program) goes off the right side of the screen, and wraps around to the left. These lines are handled differently by the kernal in order to allow line wrapping of BASIC code in 40x30 mode. As long as you make sure this does not happen, 20x15 mode should work fine.

[paulscottrobson]

It's broken really. SCREEN 128:SCREEN 0 doesn't work, for example. It creates a graphic screen on top of the text screen, and starts it at $10000 in VRAM. Problem is there isn't enough VRAM for a 320x200 graphics screen there. Ideally the kernal should work out the screen size from the tilemap sizas and the scaling and the physical limits of the display, whatever L0 is set to.

[x16tial]

1 hour ago, paulscottrobson said:

It's broken really. SCREEN 128:SCREEN 0 doesn't work, for example. It creates a graphic screen on top of the text screen, and starts it at $10000 in VRAM. Problem is there isn't enough VRAM for a 320x200 graphics screen there. Ideally the kernal should work out the screen size from the tilemap sizas and the scaling and the physical limits of the display, whatever L0 is set to.

It's odd that the character tileset is at $0f800 to $0ffff, basically smack in the middle of VERA memory.  (it's at the end of Bank 0... it makes a little sense, but not much)

Better in my opinion to put it right after 80x60 screen memory, at $04000 to $047ff.

Then you have a contiguous block from $04800 to $1f9bf (108k)

So then the 320x240 (screen 128) mode (layer 0) should start at $04800 instead of $10000 (layer 1 text is still at $00000)

After SCREEN 128:SCREEN 2, a POKE $9F29,33 will turn off the graphics layer (not much help I know, but for anyone who cares ?

[TomXP411]

50 minutes ago, x16tial said:

It's odd that the character tileset is at $0f800 to $0ffff, basically smack in the middle of VERA memory.  (it's at the end of Bank 0... it makes a little sense, but not much)

Better in my opinion to put it right after 80x60 screen memory, at $04000 to $047ff.

Then you have a contiguous block from $04800 to $1f9bf (108k)

So then the 320x240 (screen 128) mode (layer 0) should start at $04800 instead of $10000 (layer 1 text is still at $00000)



After SCREEN 128:SCREEN 2, a POKE $9F29,33 will turn off the graphics layer (not much help I know, but for anyone who cares

I seem to recall reading that VERA can only access one bank at a time, so configurations that span the 64K boundary aren't going to work. 

If it is possible to configure screen modes that span the 64K boundary, then it makes more sense to put the character set data at the top of RAM, just ahead of the PSG registers. I think $1E800 is the closest 512 byte boundary. 

Of course, it's easy enough to reconfigure VERA yourself and test those modes. If it works, you might suggest that to Michael as a change over on the ROM Github page. 

 

 

[paulscottrobson]

11 minutes ago, TomXP411 said:

I seem to recall reading that VERA can only access one bank at a time, so configurations that span the 64K boundary aren't going to work. 



If it is possible to configure screen modes that span the 64K boundary, then it makes more sense to put the character set data at the top of RAM, just ahead of the PSG registers. I think $1E800 is the closest 512 byte boundary. 



Of course, it's easy enough to reconfigure VERA yourself and test those modes. If it works, you might suggest that to Michael as a change over on the ROM Github page. 



 



 

This is as you say easy enough. The problem seems to be getting back again. It's fine if you crossdevelop as most people are doing, but if it's supposed to work as a standalone system it's a bit ropey.

[x16tial]

49 minutes ago, TomXP411 said:

I seem to recall reading that VERA can only access one bank at a time, so configurations that span the 64K boundary aren't going to work. 

As far as I know, this isn't true.  The VERA is pretty much all about wrapping/incrementing within its memory space.

Yeah, top of RAM could work, but it's just a little weird, because the Tilebase has to be at 2k boundaries, so you'd have 448 bytes between 1F7FF and 1F9C0.  Not a lot, but still.

[StephenHorn]

1 hour ago, TomXP411 said:

I seem to recall reading that VERA can only access one bank at a time, so configurations that span the 64K boundary aren't going to work. 

I've never seen this, it is not represented in the emulator implementation, and it is not documented in the official VERA reference.