Migrating GameWork first Turbo Bridge to whatever platform other than DosBox

[dng8888g]

Playing Turbo Bridge a lot.  Hence thinking about upgrade its code so it can

- restart a bidding
- save a game for study and restart it
- and use more modern bidding systems (the g system used has migrated to 5 card major, SAYC then 2-over-1 etc. for online playing and I might add a UK bidding option as I played also real life in UK)

After reading the Turbo Tutor of 1980s and the Gamework book, I think these 3 will be doable and I am in the process of upgrade the old Turbo Pascal code (which code and compiled under Turbo Bridge 5.5 and work under DosBox; and via mount I can edit the files under Visual Code just compile and run using Turbo Pascal).

But ...

Before I go further, I wonder can one use a more modern approach (lazarus IDE) and even run it run say Windows or even MacOS as a console application using free Pascal?  Can the Turbo Pascal MTP switch help? OK let me see ...

After include BRIDGE.PAS as a simple command file I try to compile it and first issue (and guess will be many?) come up.  This is the curser setting and cursor finding use int 10.  Should I rewrite it somehow and any hint to do so (no idea at all about those screen programming).  Or ...

Should I give up?

Code: Pascal  [Select][+][-]

1.  
2. var
3.   Item : ScreenPositions;
4.  
5. var
6.   LastCursor : CursorRec;
7.  
8. { ================= begin cursor control module ================== }
9. procedure Cursor(On : boolean; var LastCursor : CursorRec);
10.  
11. procedure SetCursor(StartLine, EndLine : integer);
12.  
13. var
14.   RegPack : Registers;
15.   CXRegArray : array[1..2] of byte;
16.   CXReg      : integer absolute CXRegArray;
17. begin
18.   CXREgArray[2] := Lo(StartLine);
19.   CXREgArray[1] := Lo(EndLine);
20.   with RegPack do
21.   begin
22.     ax := $0100;  { cursor interrupt }
23.     bx := $0;     { page #           }
24.     cx := CXReg;
25.     intr($10, RegPack);
26.   end;
27. end; { SetCursor }
28.  
29. procedure GetCursor(var StartLine, EndLine : integer);
30. var
31.   RegPack : Registers;
32. begin
33.   with RegPack do
34.   begin
35.     ax := $0300;  { cursor interrupt }
36.     bx := $0;     { page #           }
37.     intr($10, RegPack);
38.   end;
39.   StartLine := Hi(RegPack.cx);
40.   EndLine := Lo(RegPack.cx);
41. end; { GetCursor }
42.  
43. begin { Cursor }
44.   if On then
45.   begin
46.     with LastCursor do
47.       SetCursor(StartLine, EndLine)
48.   end
49.   else
50.   begin
51.     with LastCursor do                    { save original cursor type }
52.       GetCursor(StartLine, Endline);
53.     SetCursor(32, 0);
54.   end;
55. end; { Cursor }
56. { ================= Cursor control module ================== }
57.  
58.  

[MarkMLl]

Please consider this to be more a placeholder than anything else, since there are definitely people more expert in this specific area than I am.

First, I think that your philosophy of sticking to a console-style program to start with is the correct one, but even there you will find that the Lazarus IDE will be very useful. You are likely to find that the internal console window is somewhat limited, but you should be able to start the program from a console ("shell session", "command prompt" etc.) and then attach to it (IDE's Run -> Attach to program... facility) which will give you a somewhat better debugging environment than you'd otherwise have.

You definitely want to purge all int 10h etc. references from the program.

From the documentation root at https://www.freepascal.org/docs.html look at "Run-Time Library (RTL) units reference manual ", and from there go to the Crt unit which should be a good interim starting point.

If you move on to trying to build it as a GUI program (i.e. Lazarus LCL-based application) you will definitely have a chunk of rewriting to do, and the first thing you will have to do is replace all the stuff that calls the CRT unit. A particular hint here (which might contradict anything you've read about porting a program to Delphi) is that you could put a keyboard handling loop at the end of the main unit in at least some versions of Delphi+VCL but I can say from experience that if you try doing the same to Lazarus+LCL you'll come unstuck.

So, keep at it and you're generally in a good place to ask questions... at least until you start targeting specific OSes.

MarkMLl

[jamie]

For a moment I thought the "Brooklyn Bridge" screen to screen on dialup was being talked about! 

That was a great piece of software and made me money where I didn't have to travel much to correct problems in old DOS days!

[dng8888g]

Please consider this to be more a placeholder than anything else, since there are definitely people more expert in this specific area than I am.

First, I think that your philosophy of sticking to a console-style program to start with is the correct one, but even there you will find that the Lazarus IDE will be very useful. You are likely to find that the internal console window is somewhat limited, but you should be able to start the program from a console ("shell session", "command prompt" etc.) and then attach to it (IDE's Run -> Attach to program... facility) which will give you a somewhat better debugging environment than you'd otherwise have.

You definitely want to purge all int 10h etc. references from the program.

From the documentation root at https://www.freepascal.org/docs.html look at "Run-Time Library (RTL) units reference manual ", and from there go to the Crt unit which should be a good interim starting point.

If you move on to trying to build it as a GUI program (i.e. Lazarus LCL-based application) you will definitely have a chunk of rewriting to do, and the first thing you will have to do is replace all the stuff that calls the CRT unit. A particular hint here (which might contradict anything you've read about porting a program to Delphi) is that you could put a keyboard handling loop at the end of the main unit in at least some versions of Delphi+VCL but I can say from experience that if you try doing the same to Lazarus+LCL you'll come unstuck.

So, keep at it and you're generally in a good place to ask questions... at least until you start targeting specific OSes.

MarkMLl

Thanks and will look into it.  But that reference is 2000+ pages.  I did scan through it and good it has samples.  It will be a long project look like.  Might be keep to Turbo Pascal + Visual Code (or Working Copy and its editor) would be a viable option, until I master all these new info.

Fun!

[TRon]

You might want to consider a complete GUI re-write because the game logic itself does not change.

There are actually quit a few problems with how the cursor is positioned and characters being drawn (I had to change my terminal encoding to IBM for example, and things are still not 100% as intended). There seem to be a lot of 1-off calculations which is more or less my trademark 

Oh, and the used colours are actually awful.

[dbannon]

Yes TRon, I'd vote for a GUI rewrite too.

Might not trigger all that nostalgia but you will end up with something that both works and looks nice. Especially as you are a Mac user now.

But do not approach this thinking either model will be easy. You will be able to copy and paste some of the game logic I expect but you will definityl need to come to grips with writing the GUI code.  I suggest you start by making a non-functional but correct looking GUI form. See how you feel about that.

Davo

[dng8888g]

Thanks and I know it will take quite a bit time.

I look at https://github.com/RetroNick2020/Channel-Code/tree/master/turbopascal/MS%20QBasic%20Reversi%20Port%20TP%20and%20FP one can see a relatively short "GUI" reverse game program that can run under tp7l.  I do not check in details the Free Pascal source, but one did note that the Free Pascal version is of a different source program, ... hope not that much work.  But he migrated all these from Basic and got a yt video on this I think.  Is he even moved to javascript from Pascal even.  Interesting and promising :-). 

That means I have an example for the future GUI rewrite  using Unit Graph under tp7.  That will involve all those display logic and cursor setting.  Giving all 3 programs under Gamework 4 can run under tp7, adding Unit Graph and then start coding seems at least feasible. 

But that GUI rewrite might be my third step. 

My first step is learn a bit more TP itself and upgrade the turbo bridge so that it is like turbo Chess can at least "save the board". The bridge can rebid but not replay.  I note some logic there about saving game state.  That would occupy me first.

Then the bidding part upgrade in TP is the second step. 

All these can be done under turbo pascal.  (Is it a mistake to do it under TP for this logic part I am not sure.  But never use Free Pascal but at least I did use turbo pascal in 1980s :-)).

And in the meant time as you said need to test a bit GUI to familiar with myself how tp and free pascal use the Graph Unit.

Got a plan!  Cheer!

***

Anyway should have started earlier, but I guess my confusion over Gamework 1 source does not help; I can run the program in the last few decades :-) then but the sources does not compile.  Now I know Gamework 4 source can run under tp5.5 and now tp7, all are different, it enables the migration.

Stay tuned ... may need your help on the Graph Unit under turbo pascal and free pascal I presume.   Hopefully not pascal itself :-).  Last time use Pascal (is that my imagination that is under Univac 1100 not MSDOS ?) for statistical calculation was before 1985.   it will take time to bush up and work this out.

Cheers :-)

[TRon]

I was actually referring to an LCL GUI, e.g. not drawing pixels on some other ancient dependency (though it might perhaps be an interesting exercise)

edit: And you can just as well use FPC for 'upgrading' parts of the code (*). The picture I had attached is the bridge program compiled with FPC running on Linux 64-bit in a terminal window. Now, there are a few things that go wrong but they are mostly related to the used characters (read code-page) which are not supported (at least not for linux).

The game-logic itself seems to work as intended, including saving the current game moves to a text file (which required me to make some minor adjustments because of the non cross-platform naming scheme that was in use).

(*) The free-pascal compiler is more than happy to compile 'old'-style Turbo Pascal code. As a bonus it is possible to make use of all the new language features if you wish to do so.

[dng8888g]

This 2 goals are related:

"- restart a bidding
- save a game for study and restart it"

After some struggling of de-dusting my pascal, these are done. 

---

Just wonder whether to have a new 2b i.e. upgrade it further to use PBN out and more important in so I can access those public PBN library ... but that might be a big job.  Wonder any Pascal PBN library available to study and adopt?

---

The 3rd goal of

"- and use more modern bidding systems (the g system used has migrated to 5 card major, SAYC then 2-over-1 etc. for online playing and I might add a UK bidding option as I played also real life in UK)" <<-- ACOL

would be hard job but given the success to read the code, it might be doable.  And it is important as whilst interest so far, the bidding system is too old for learning bridge.

---

As regards to a new 3b goal to upgrade its programming or interacting and use external program (AI?), the current logic is not too bad.  Probably unless I can upgrade it to run under Free Pascal (i.e. use Graph or as suggested by TRON) it might be pointless.  Also probably too hard to use like that and might start a new one.

---

In this regards, one option is see whether it is easier to use LUA / Love2D instead and hence probably not 3b.  But 2b might worth to try.

[dng8888g]

A surprise is that one can actually run the package by replacing the set cursor and find cursor via simple replacement.

After replacing those regpack with set cursor and whereX whereY, all now can be compiled under free pascal and run under macOS terminal.  And run perfectly still under DosBox.

Except for bidding which is just plain hard work as it is a mess (which I guess it is the nature of bidding anyway), I have

- have export and import capability of the PBN (still can be improved as using DOS command to supplement is change)
- program can be compiled and run

It is a  matter of time to fix the graphic character issue I hope (currently cannot see spade/diamond/heart/club and hence not really usable with the macOS windows); I do not mind the border becomes rubbish but really need to see the card suit.

I still struggle whether to do the upgrade of bidding.  But may be at least try to fit in some Stayman and Jacob transfer.

So far a surprise win. And whilst I think it is possible to do in 1989, the debugging is hard.  But at least I spent most of time (50% of the 2 week is on .... drum roll ... CRLF issues; surprisingly and scratch my head until I randomly saw one of the file even under DOS is created as LF ... it can't be ... and that always alert me as some bug does not make any sense).

May do a YouTube on this just for the fun of any future silly guy like me hack on an old bridge program.  But one of the joy is that whilst I am testing, most of the time I can still play bridge with the program.  Hence, it is mostly fun as a user of the program and as a hacker of the program.


 
Unfortunately there is some issue with those "character graphic" which I can ignore but the missing of the spade/heart/diamond/