I am in the middle of writing a PLATO terminal for the Atari ST for IRATA.ONLINE.

I'd ultimately like it to work that I would simply write to a buffer, which I would then blit rectangles to the screen when the buffer changes.

Initially, the buffer will be 1-bit monochrome, but I may extend this to multiple planes to support more color, as I get the terminal implementation ironed out.

The first question is, should I use vro_cpyfm or vrt_cpyfm?

While I am a competent programmer, I had not written any software for the ST, and am needing to do this out of necessity...Ideally I would love to work with somebody to do the system specific parts (window control, line draw, point draw, character output, key input) while I implement the protocol decoder and the non-system specific bits, but I'll simply settle for the above question.

tschak909 wrote:The first question is, should I use vro_cpyfm or vrt_cpyfm?

If the buffer is monochrome, you should use vrt_cpyfm. That should work in all resolutions. But if you need colors, vro_cypfm is the only choice. Note that in this case the buffer must have the same format as the screen resolution, even if you need lets say only 16 colors, while the screen has 256 colors.

No, unfortunately not. That would only work if VDI would also scale the source bitmap up/down while blitting, but it does not (NVDI can do that if you add 0x8000 to the writing mode, but other VDIs cannot handle that; also it might look rather ugly). The source and destination rectangle should be of the same size. That also means: a) if the source bitmap is larger than the window, you have to make sure that the non-displayed parts are clipped away and b) if it is smaller, you have to explicitly clear the remaining parts of your window to the background.

ThorstenOtto wrote:No, unfortunately not. That would only work if VDI would also scale the source bitmap up/down while blitting, but it does not (NVDI can do that if you add 0x8000 to the writing mode, but other VDIs cannot handle that; also it might look rather ugly).

Unfortunately, because the PLATO terminal is natively 512x512 pixels, I will HAVE to do coordinate scaling when displaying on anything that isn't a TT Hi-Res display. I was initially just going to basically do coordinate mapping for each dot that I output to my internal bitmap, and then blit that result to the target window.

tschak909 wrote:Unfortunately, because the PLATO terminal is natively 512x512 pixels, I will HAVE to do coordinate scaling when displaying on anything that isn't a TT Hi-Res display. I was initially just going to basically do coordinate mapping for each dot that I output to my internal bitmap, and then blit that result to the target window.

-Thom

I don’t know the usecase well, but a typical scenario would “just” output the bitmap 1:1 into a GEM window, which allows scrolling and positioning. People with an original ST resolution could still use a "virtual screen enhancer" – or LaceScan, or Overscan ST. In any case I’d suggest to make the scaling optional.

Last edited by arf on Mon May 14, 2018 6:54 pm, edited 1 time in total.

The whole PLATO screen is intended to be displayed as a single visible screen, and would be quite jarring to have to pan around the screen.

These are pictures from PTerm, which runs on modern PCs, and renders a full 512x512 screen and scales up:

avatar.PNG

01_main_menu.png

irata_welcome_pterm.png

On the Atari 800, the cartridge scales drawing down to the target resolution of 320x192 (and the port I am doing to the Commodore 64, does the same),but since scaling the default font is processor intensive, there is a default font that is scaled 6x5 in the ROM to output directly, while custom fonts from the service are received and scaled directly into memory.

irata_welcome_atari.png

So this CAN be done on the ST. I am trying to get this done and provide a very unique online service for retro-computing users who now have internet connectivity on their devices, but very few places to connect to (much less even interesting).

(p.s. what can do output scaling? Could I just get away with bundling NVDI5 with my terminal? GDOS? I _really_ need this functionality.)

Or maybe I could talk one on one with an experienced ST developer to get a plan of action to write a terminal? I run a Jitsi meet for IRATA, and we can talk there.

(the resulting terminal will be released to the ST community, under the GPL3)

-Thom

You do not have the required permissions to view the files attached to this post.

tschak909 wrote:(p.s. what can do output scaling? Could I just get away with bundling NVDI5 with my terminal? GDOS? I _really_ need this functionality.)

NVDI 5 is commercial and copyrighted. Also, it needs to be installed and configured on each computer it runs on. NVDI bitmap scaling is OK, but slow and not suitable for realtime screen updates. I suggest you pre-scale the fonts and scale graphics output while rendering. This will be much, much faster (and better looking) than scaling the finished bitmap.