Good day, my monitor is 2560x1440, but on fullscreen there are black borders around the Picotron window. To get fullscreen without borders I have to enable stretching, which makes the image blurry.

1440p is just 720p doubled so I assumed there should be no problem scaling to that resolution, but it seems like the window itself is running at 1920x1080 in the center with black borders around it.

Is there a way to scale to cover the entire screen without making the image blurry?

Unless the resolution is a width that's a multiple of 240 and a height that's the same multiple of 135, you will have black borders. 2560x1440 is not a clean multiple.

Also Picotron takes Windows scaling (from Display Settings) into account. So you even can have not full screen on FullHD screen.

Thanks, setting the high DPI option to program (rather than system) through "Properties" helped! Now the black border is much smaller, so it's nicer to use.

I've been playing with some CRT filters using Reshade. Even if you don't want a CRT look, some of these plugins can stretch the screen arbitrarily. You may want to look into it. https://reshade.me/

I had same problems on MacOS when using build-in dysplay. Did the same trick with HDPI to make barders less.
BTW, it works OK on my external monotors with 16:9 and 16:10 resolution.. Which is a bit strange :)

I don't know if it's possible but it might look nice to include a fake monitor frame in the black bars top/bottom for 16:10

Picotron must be calculating resolution incorrectly — I can't read the code so I can't be sure, but I know that some SDL functions return sizes in scaled pixels, and others return sizes in actual pixel size. Easy to get them confused.

This is Picotron in 1728x1117 scaled 2x

This is Picotron in 3456x2234 not scaled:

The actual resolution is no different between the two, and yet Picotron determines the closest possible based on the imaginary scaled resolution.

In fact this gets even weirder, because for some calculations Picotron uses different pixel units, sometimes scaled sometimes not. This leads to the display being centered in between pixels when scaling, making pixels very blurry despite the borders.

Edit:
I have no idea how ARM assembly works but this looks familiar enough

000000010005e65c         bl         imp___stubs__SDL_GetWindowSize 

SDL_GetWindowSize used in display code feels a bit odd to me, as it returns the scaled operating system units — there is another, SDL_GetWindowSizeInPixels that generally makes more sense for this use case. (again, I don't know ARM assembly so I'm only inferring this from context, it could be unrelated)

Edit 2:
After figuring out ARM assembly and patching in an additional procedure that doubles the units, which isn't correct as it would break on unscaled displays (but I can't access the other SDL function, I don't think it's being pulled in when loading SDL, so this will have to do):

  _getWindowSizeAdjusted:
000000010005e7f4         sub        sp, sp, #0x80                               ; Set up the stack, CODE XREF=_os_apply_video_config+88, _blit_to_sdl_window_hardware+124, _handle_sdl_messages+1092
000000010005e7f8         str        lr, [sp, #0x80 + -128]                      ; Remember return address
000000010005e7fc         bl         imp___stubs__SDL_GetWindowSize              ; SDL_GetWindowSize
                             ; Now dereference and double both width and height
000000010005e800         ldr        w10, [x1]
000000010005e804         add        w10, w10, w10
000000010005e808         str        w10, [x1]
000000010005e80c         ldr        w10, [x2]
000000010005e810         add        w10, w10, w10
000000010005e814         str        w10, [x2]
000000010005e818         ldr        lr, [sp, #0x80 + -128]
000000010005e81c         add        sp, sp, #0x80
000000010005e820         ret
                        ; endp

The window is now positioned at the (almost) correct x and y:

Very clearly this also affects the width and height, so that would have to be fixed too, but I already spent all day starting at instructions so that's as far as I'm going to investigate :)

Either way it should be very easy to fix.