OPCRT

[joho]

Is anyone aware of any OPCRT (from TurboPower) ports for console mode / text mode FP applications? I know it exists for VirtualPascal, but I haven't been able to see any for FP.

[marcov]

Hmm, familiar name .....  Keep the front doors open!

Anyway, which targets ? 

If you let FPC walk the VP traject what is the problem ? (since I assume that avoids most of the assembler also?)

Afaik people experimented it with porting in FPC 1.0.x targets, but the assembler and calling conventions in FPC 2.0 and later were changed to align more with delphi, which may affect old assembler code. I haven't heard much people seriously working on porting old TP code to FPC in recent years.

If you want windows as target, a Delphi port would be the best starting point.

[joho]

 

I haven't been digging too deeply into it as of yet. I realize I won't get a 1:1 port of OPCRT (or similar), which will most likely result in me writing something similar or ditch the full screen text interface completely.

My primary goal is not to create a Windows console mode application, or Linux, or ... it's to get everything compiling/building under FP since it seems to be one of the few viable alternatives for me at the moment (short of doing it all in C/C++ of course).

The build target right now is a Windows console mode application. Or anything else that can run under Windows 10 without forcing me to re-design the entire UI and add graphical elements

[marcov]

I did a quick investigation of the situation:

1. the original TPCRT sources seem to have an ifndef windows, and are full of unportable code (asm, direct segmented memory access, trying to hook into exist crt)
2. the FPC crt unit doesn't export a virtual screen, so one can't quickly implement the missing functionality of opcrt relative to the existing crt unit.
3. the opcrt that I found(https://github.com/OS2World/DEV-PASCAL-UTIL-OBJPRFVP/blob/master/opcrt.pas) , seems to  use mem[] to access the screen, which is not really usual in Windows.

If the vp unit works in win32, one could investigate how that works, and that might be fairly easy. However if not, then it gets more difficult.

FPC always kept crt for compatibility and moved virtual screen usage to unit video, hence that the Crt unit was never expanded beyond is constrained, but compatible and fairly portable.

Unit video (and associated units mouse and keyboard) are the units the textmode IDE uses for textmode console underpinnings of TV/FV. This unit however only implements the virtual screen, and needs explicit commands to write the differences out to the system (because doing it too often slowed down to much on some targets)

Implementing a crt unit over the virtual screen in unit video has been suggested several times, but has never been done to my knowledge, and quite some work.

[joho]

Indeed. Since I started doing PC coding around 1985, I was hit by the entire "You need to cheat to do direct CRT I/O on the PC good" and it seems I have to something with it once again, until I accept my fate and either do only text stdout or dig into proper gui mess

Funny you should mention the FP IDE, because I was just looking through that code to see how it handled the problem. In this particular case, speed is probably not the main issue, but rather the ability to create "windows", scrolling content, direct positioning, and what not. Maybe the IDE way of doing it might work.

But I'm a few hundred units away until I get to that part ... 

[marcov]

Indeed. Since I started doing PC coding around 1985, I was hit by the entire "You need to cheat to do direct CRT I/O on the PC good" and it seems I have to something with it once again, until I accept my fate and either do only text stdout or dig into proper gui mess

The problem is that while Crt works, extensions really fast become unportable. We also had that with the IDE/turbo vision driver underpinnings, and since TV is also not based on
Crt in TP, kept that difference in FPC too, but made the console (screen, keyboard,mouse) support in our Turbo Vision system in separate units (to split out platform dependent FV/TV drivers unit code from the main code body into a set of separate units outside of FV). The textmode IDE also works on Linux with some limitations (not all keyboard combinations are possible on all terminals, and there are some issues with the "output" window too. Some of that works on a physical Linux textmode terminal login, but not in ssh/xterm etc)

So the problem is not that you should go GUI, but more that maybe rethink what the minimal abstraction is that you need.

If you only use gotoxy() write('rewrwe)  like sequences you might not require all the line wrapping stuff (which, with unicode and older East Asian character sets workarounds is quite involved)

Funny you should mention the FP IDE, because I was just looking through that code to see how it handled the problem. In this particular case, speed is probably not the main issue, but rather the ability to create "windows", scrolling content, direct positioning, and what not. Maybe the IDE way of doing it might work.

It will work, the IDE does it doesn't it? And on Windows quite well.

The only problem is that that code factored out of TV (units video/keyboard/mouse) are real driver units, and miss some easy to use  layer on top of them.

But I'm a few hundred units away until I get to that part ... 

What I'm suggesting is writing a small subset interface of whatever you need on top of those units to bridge the gap between the virtual screen emulation and your code. I've played with that in the past, and could help you here and there.

Some of my past experiments (fairly old, think 2000-2003) are in the FPC demoes, the textmode console games fpctris and samegame, and a start for a list.com clone called "lister". If you have a standalone FPC (not lazarus) install, they are in c:\fpc\<version\demo and then mainly the graph\ and lister\ directories. Seems that the makefile is broken due to upgrade to make 3.82 or changes in the makefile generator, so build by hand (make sure gameunit.pp doesn't define "usegraphics", edit if necessary)

These programs worked at some time, but  I haven't seriously looked at them since 2005, YMMV

The only thing that might be a bit difficult is that the TV code needs an explicit command to update the screen from the virtual buffer. You can force  that on every write, but that is slow for complicated screens

[joho]

Thanks for responding. I am sure I will need help with this part.

The basic requirements are

- Windows (saving what's underneath)
- Absolute positioning of windows, and of output in windows
- Colors
- Scrolling content in windows

It's not an hysterical amount of data that needs to be scrolled / written in the main application. There is a message editor that obviously does screen updates every time you scroll a line or enter text, etc. And there's a terminal emulator with similar needs. But one thing at a time.

[Thaddy]

http://rvelthuis.de/programs/console.html is imho cutting your teeth.
If it does not port right away, I have a working version.

[marcov]

Thaddy: Like FPC crt, no support for read.

[Thaddy]

Marco, with console the read support is in buffers, Not on the actual console.

[marcov]

If you need to do win32 specific calls to read, there is no need for console, iow I don't see what "console" improves over regular FPC crt.

[Thaddy]

crt buffers. As does Rudy's console unit. What I am trying to say is, don't parse the screen, parse the buffers. On Windows it is limited to 10.

[joho]

I will certainly look. It seems like "everyone" is more or less doing things the same way (FP, VP, etc), which I guess is a good indication.

It'd be nice if VIDEO supported code to "scroll the buffers" and drawing "windows" using the buffers.

(I realize I can do that myself, before I get shot down ...)

It looks like those platform implementations I've looked at (of VIDEO I mean) all use the same methods ... is it then safe to manipulate the buffer(s) directly?

Oh, and also, why doesn't ClearScreen use the currently active text attribute / color?

[marcov]

I think I tried to in the lister  program. But that stopped worked.

That said, the whole point of video is to manage windowing for Turbo Vision, so it was pretty much designed for that (but with explicit draw/sync commands) The updatescreen(true) should forcedly sync the screen

[joho]

I played around a bit with VIDEO yesterday to test my "psuedo-ported" unit and noticed some odd (but expected) behavior when I re-sized the console window. It would be nice if one could hook a "console window resize" event (if there is such a beast) and at the minimum re-draw. Even if the re-draw would produce a somewhat incomplete screen, it, at least, would not be blank and/or scrambled.

The display did, however, appear to "reset" itself correctly when one or more updates were forced.