Jump to content
  • 0

20x30, 40x15, 20x15 text mode


mobluse
 Share

Question

There are these text modes (below) now, but I would also like 20x30, 40x15, 20x15 text. They would be useful for making apps for visually impaired or that could be seen from a long distance. If I must choose only one of these text modes to be added, I would prefer 20x15. I know these characters could be drawn using bitmap graphics, but I would prefer e.g. a 20x15 text mode that works using PRINT in BASIC. Clarified feature request: Line wrap and screen editing should work as normal with e.g. 20x15 text mode.

$00 40x30 text  
$01 80x30 text (currently unsupported)
$02 80x60 text  
$80 320x200@256c
40x25 text
Edited by mobluse
Link to comment
Share on other sites

23 answers to this question

Recommended Posts

  • 0

Thanks! but there are problems with it. I wrote:

Quote

10 SCREEN 0:REM 40X30
20 POKE $9F2A,32
30 POKE $9F2B,32
40 PRINT "X16   ";
50 GOTO 40

and RUN it and press Esc, but then "BREAK IN 40" and "READY." is not seen until I press Enter a number of times, and then it appears, but then there is no cursor and you cannot list the program. This 20x15 mode would need to be a bit improved so that line wrap works and the cursor is the same as before.

Link to comment
Share on other sites

  • 0

yeah, the interactive basic prompt will not "recognise" the resolution to be lower than 40x30 characters.

Your program however can deal with this just fine, If you're not printing text lines that wrap over the screen edges.  Just contrain everything within 20 columns and 15 rows and you should be ok

Link to comment
Share on other sites

  • 0

I tested this:

Quote

10 SCREEN 0
20 POKE $9F2A,32
30 POKE $9F2B,32
40 POKE $386,20
50 POKE $387,15
60 N=0
70 PRINT N;
80 N=N+1
90 GOTO 70

but it skips some numbers each third line when printing 4-digit numbers. I think line wrap and the screen editor should work as normal in 20x15 text mode.

Link to comment
Share on other sites

  • 0

Although this won't fix the skipped numbers, I recommend that you add these lines:

Quote

52 POKE $388,16
54 POKE $389,14

The kernal uses these variables, and sets them when switching to other screen modes. Therefore, setting them will likely make 20x15 mode act a bit more normal.

Link to comment
Share on other sites

  • 0
43 minutes ago, mobluse said:

I tested this:

but it skips some numbers each third line when printing 4-digit numbers. I think line wrap and the screen editor should work as normal in 20x15 text mode.

It skips on the two-digit numbers as well. They just go by so fast that you don't see them unless you add a delay in the loop.

Link to comment
Share on other sites

  • 0

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.

  • Thanks 1
Link to comment
Share on other sites

  • 0

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.

Edited by kelli217
Link to comment
Share on other sites

  • 0

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.

  • Like 1
Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0
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 🙂

Edited by x16tial
Link to comment
Share on other sites

  • 0
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. 

 

 

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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.

Edited by x16tial
Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
3 hours ago, paulscottrobson said:

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.

The intent is not to go back again... the point was to test this configuration and suggest it to Michael as the default state of the machine, not to use it on an ad-hoc basis.

 

Link to comment
Share on other sites

  • 0

Can anyone give up to date info on the likely size of the text modes if (or when!) the X16C comes into existence (I realise it may be the same on all machines)?

Last I saw, I believe in one of the two "dream computer" videos, they would likely be:

80 columns by 60 rows

80 x 30

40 x 60

40 x 30

20 x 30

20 x 15

I'm sure this is discussed in documentation somewhere but I think posting on here is the only way to ensure I get up to date info as someone will know if the docs online are out of date in this regard.

Thanks for any help.

 

Link to comment
Share on other sites

  • 0
On 8/27/2021 at 2:52 PM, James Anders Banks said:

Can anyone give up to date info on the likely size of the text modes if (or when!) the X16C comes into existence (I realise it may be the same on all machines)?

There are really only two text modes, both of them 80x60, with the default being 16 colors for any character's background and foreground, and the other being a fixed background color with 256 foreground colors. You can then adjust the vertical and horizontal scales if the display. Pixel-for-pixel scaling means setting each scale value to 128, which is the default. You can double up the pixels in both dimensions by setting them to 64, which gives you 40x30, and so on. 

Also, the text layer can be scrolled around, and and the default tile map is actually 128x64, so there are a bunch of characters off screen. Scaling up allows you to make the tile map smaller, giving you more VRAM for other things, like a second layer or sprites.

Link to comment
Share on other sites

  • 0
1 hour ago, SlithyMatt said:

There are really only two text modes, both of them 80x60, with the default being 16 colors for any character's background and foreground, and the other being a fixed background color with 256 foreground colors. You can then adjust the vertical and horizontal scales if the display. Pixel-for-pixel scaling means setting each scale value to 128, which is the default. You can double up the pixels in both dimensions by setting them to 64, which gives you 40x30, and so on. 

You can set the screen to 40x30 characters with the F4 key or SCREEN 0 

This (probably) still uses the same memory layout as 80x60, which is actually 128 columns and 60 rows. Regardless, it would be nice for the KERNAL to support 80x30 mode.

I don't particularly care about 20 column modes (although I guess some people might want 22 column modes to make it easier to port VIC-20 games), but I really do want something that resembles the standard of 80x25 for ANSI terminal emulation. 80x30 is close enough: I can use the lower 5 rows for status information, but not having an actual 80x25 (or 80x30) mode supported by the KERNAL is annoying. 

Edited by TomXP411
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use