Is it worth bothering with other menu/window frameworks?

On Aug 11, 2:12 pm, Marco van de Voort <mar...@stack.nl> wrote:
> Note that IIRC, TV allows to stream dialogs to file, to avoid having to have
> code in the binary to create dialogs. (with a lot of dialog, the streaming
> code is way smaller than the dialog creations-in-code)

Now that is something I never knew. Hopefully the Turbo Vision manual
will cover it?

On Aug 11, 2:56 pm, "Sv. Broholm" <sbroh...@gmail.com> wrote:
> > > With the overlay analyzer, PSA from Turbo Analyst (Turbo Power
> > > Software), you can fine tune units izes and see which overlays get
> > > called alot and which is only called a few times.
>
> > Unfortunately, Turbo Power has neglected to opensource their pascal
> > offerings, only their C/C++ offerings. Is there any way to obtain
> > PSA? (If not, I can comb through .MAP files, but it would be really
> > nice to have a pre-written utility to do that for me)
>
> It should be in your mailbox!

Thank you sir!

On 11 Aug., 21:56, "Sv. Broholm" <sbroh...@gmail.com> wrote:
> On 11 Aug., 19:41, Jim Leonard <MobyGa...@gmail.com> wrote:
>
> > On Aug 11, 11:42 am, "Sv. Broholm" <sbroh...@gmail.com> wrote:
>
> > > If size matters (<64 kB) - and I assume you have much available memory
> > > - then use the overlay manager as you already have done, and copy the
> > > overlaid units to either EMS- or EXT-ram. That will not harm
>
> > EMS is not available on the target platform.
>
> > Some details are probably needed at this point: *I am writing a
> > discovery and benchmarking program specifically targeted toward very
> > old PCs, for a growing hobbyist community around these old machines.
> > I am trying to keep the code size to 360K (to fit onto a single 5.25"
> > disk, which is sometimes all these old machines have),
>
> If codesize should be less than 360 kB then use PKLITE to reduce the
> compiled EXE-size.
> Shriks normally to around 40 % of org.size.
>
> >and memory usage to around 80K of (to work on machines with 128MB RAM).
>
> With 128 *MB* RAM you have no problems *;-)
> Turbo3 compiles to tiny COM-files and can use overlays as well. Limits
> to 64 kB load image. But you shall write your own interface :-(
>
> I understand that the loadsize of the program must not be larger than
> approx 80 kB - incl overlay buffer ? I suggest approx 100 kB incl.
> overlay buffer around 50 kB. It must be larger than the biggest
> overlaid unit (codesize).
>
> > The code (TV not withstanding!) is very large, as it contains a lot of
> > routines to detect various graphics cards, processors, and speeds.
> > Since only 1% of these routines will ever get run on any one machine
> > (e.g. the Pentium/CPUID routines never run if the CPU gets detected as
> > a 386, etc.), they don't all need to go into memory at once, so I will
> > definitely be using the overlay manager for those. *My concern is
> > whether or not TV elements can also be overlaid. *I assume trying to
> > overlay the mouse routines would be disastrous, as they are interrupt-
> > driven, but is there anything else I should definitely NOT overlay?
>
> Units that contain interrupthandlers (mouse-unit) and
> Units that loads BGI-fonts and BGI-drivers must never be overlaid.
>
> > > With the overlay analyzer, PSA from Turbo Analyst (Turbo Power
> > > Software), you can fine tune units izes and see which overlays get
> > > called alot and which is only called a few times.
>
> > Unfortunately, Turbo Power has neglected to opensource their pascal
> > offerings, only their C/C++ offerings. *Is there any way to obtain
> > PSA? *(If not, I can comb through .MAP files, but it would be really
> > nice to have a pre-written utility to do that for me)
>
If your application must run on a DOS-computer with max 128 Kb RAM you
are in big problems using TurboVision!

Installed RAM 128 kB
- for DOS -45 kB
- MouseDriver -5 kB
Available for app. 75 kB

I have used FILEVIEW.PAS and TVDEMO.PAS to see how much memory is
required for a minimal overlaid TV-application.

Even if you fine tune stacksize and use maximum number of TV-units in
overlay, it is difficult to reduce loadsize (Use EXEMOD to determine
actual loadsize = RAM required to run your application) much below 75
kB for a stripped down TV-application. When you add you own code you
get stuck in a very short time.

Bottomline : You can't get your proposed TV-application running with
only 128 kB installed RAM. At least 64 kB extra is required. I still
believe your program can be distributed using a 5.25" floppy with only
360 kB.

If you insist of using only 128 kB RAM then my best idea is using
Turbo3 with overlay's and shoehorn it down using your own simple text
user interface - but it is time consuming - and not rewarding.

On Aug 12, 5:03 am, "Sv. Broholm" <sbroh...@gmail.com> wrote:
> I have used FILEVIEW.PAS and TVDEMO.PAS to see how much memory is
> required for a minimal overlaid TV-application.

That is an excellent suggestion. Doing the same, and more importantly
checking TVRDEMO (note the "R", which denotes a size-optimized
overlaid version), I have confirmed there is no way I can meet a 128KB
computer (~96KB free) as a target. TVRDEMO, using overlays, required
162KB just for initialization, and when I "touched" every function, it
ended up using 174KB (but the disk swapping was almost prohibitive).
Even a basic (non-overlaid) myapp.init/run/done used 56K, which is
hopeful, but I wouldn't want to start adding functionality only to
find that I have surpassed my target.

Being as it is not a word processor or anything that *needs* a strong
interface, I'll write my own.

> Bottomline : You can't get your proposed TV-application running with
> only 128 kB installed RAM. At least 64 kB extra is required. I still
> believe your program can be distributed using a 5.25" floppy with only
> 360 kB.

I concur.

For the curious, there is *one* machine that is *required* to run this
benchmark, only because it has the unique distinction of being the
only IBM machine *slower* than the original PC: The PCjr. One of the
questions this benchmark is supposed to answer is exactly how much
slower it was. Most PCjrs are 128KB so I will make that my target.

> If you insist of using only 128 kB RAM then my best idea is using
> Turbo3 with overlay's and shoehorn it down using your own simple text
> user interface - but it is time consuming - and not rewarding.

I disagree with this, because Turbo3 actually produced bigger and
worse code than Turbo7. Turbo7 has a lot of compiler optimizations.

On 14 Aug., 23:25, Jim Leonard <MobyGa...@gmail.com> wrote:
> On Aug 12, 5:03 am, "Sv. Broholm" <sbroh...@gmail.com> wrote:
>

>
> Being as it is not a word processor or anything that *needs* a strong
> interface, I'll write my own.
>
> > Bottomline : You can't get your proposed TV-application running with
> > only 128 kB installed RAM. At least 64 kB extra is required. I still
> > believe your program can be distributed using a 5.25" floppy with only
> > 360 kB.
>
> I concur.
>
> For the curious, there is *one* machine that is *required* to run this
> benchmark, only because it has the unique distinction of being the
> only IBM machine *slower* than the original PC: *The PCjr. *One of the
> questions this benchmark is supposed to answer is exactly how much
> slower it was. *Most PCjrs are 128KB so I will make that my target.
>
So you skip TV-interface and carry on with your own, simple user
interface and overlaid units using up to 96 kB free RAM and TP7 ?
Remember buffersize, stack and heap + codespace should all sum up to
less than 96 kB. I estimate following:
Buffersize 25 kB "large" buffer to reduce disk trashing on a
slow computer.
Stack size 10 kB
Heap 7 kB
Overlay manager 3 kB
Total 45 kB

Thus code and data space is 96 kB - 46 kB = 50 kB

It will be tough!. Keep us posted.

> > If you insist of using only 128 kB RAM then my best idea is using
> > Turbo3 with overlay's and shoehorn it down using your own simple text
> > user interface - but it is time consuming - and not rewarding.
>
> I disagree with this, because Turbo3 actually produced bigger and
> worse code than Turbo7. *Turbo7 has a lot of compiler optimizations.

The initial overhead to produce a small TP3 application (includes
SYSTEM, DOS, and CRT-unit) is 10 kB COM-filesize compared to 4 kB EXE-
filesize compiled with TP7. But for larger programs this differences
changes in favour of TP3, because TP3 produces code to tiny memory
model - thus references to registers are smaller.
Keep us posted !

On Aug 18, 12:20 pm, "Sv. Broholm" <sbroh...@gmail.com> wrote:
> So you skip TV-interface and carry on with your own, simple user
> interface and overlaid units using up to 96 kB free RAM and TP7 ?
> Remember buffersize, stack and heap + codespace should all sum up to
> less than 96 kB. I estimate following:
> Buffersize 25 kB "large" buffer to reduce disk trashing on a
> slow computer.
> Stack size 10 kB
> Heap 7 kB
> Overlay manager 3 kB
> Total 45 kB
>
> Thus code and data space is 96 kB - 46 kB = 50 kB
>
> It will be tough!. Keep us posted.

It will be easier than that :-) I wrote an OOP music composition
program more complex than my current project and it was still under
those numbers (http://www.oldskool.org/pc/MONOTONE if you're curious,
full source included).

> Keep us posted !

Will do :-)

I am going through the TV tutorial in the TV programming guide. It is
very slow going, but I am interested in how TCollection works because
I have to maintain a small database. I was going to write my own
routines (linked list, text-based flat file) but if TCollection
already does that then I will just look at that.

If I can understand TV enough (already the status line and menu build
linked lists nested levels are irritating me) I might go ahead and
write the entire thing in TV, then write a smaller utility program
that does the basic system identification/benchmarking and writes it
to a file that the larger program can then import.

On 2008-08-19, Jim Leonard <MobyGamer@gmail.com> wrote:
>
> I am going through the TV tutorial in the TV programming guide. It is
> very slow going, but I am interested in how TCollection works because

IIRC TCollection is roughly Delphi's TList, which means it is a simple array
of pointers wrapped in a class. Not the best for scalability, but for you
that's less of a problem.

TCollection is part of Objects, thus the base RTL, and not TV btw.

> If I can understand TV enough (already the status line and menu build
> linked lists nested levels are irritating me) I might go ahead and
> write the entire thing in TV, then write a smaller utility program
> that does the basic system identification/benchmarking and writes it
> to a file that the larger program can then import.

I'm gearing up to do some FV/TV work in the FPC ide. (letting a listbox
popup on an outline); so keep asking questions. I do have some TV books,
but the main one I use is Dutch. (the TV reference guide of BP7 is
ultimately resource but more of a reference than a tutorial. The Dutch book
is better)

"Marco van de Voort" <marcov@stack.nl> wrote in message
news:slrngal0e7.2va4.marcov@snail.stack.nl...

> TCollection is part of Objects, thus the base RTL, and not TV btw.

Not strictly true. OBJECTS.PAS is part of TV and Object Windows, so is not
part of the BP7 RTL. However, one can use OBJECTS.PAS without dragging in
any of the UI units of either Turbo Vision or OWL.

Jay
--

Jason Burgon - author of Graphic Vision
http://homepage.ntlworld.com/gvision

On 2008-08-26, Jason Burgon <jaynews@ntlworld.com> wrote:
>
>> TCollection is part of Objects, thus the base RTL, and not TV btw.
>
> Not strictly true. OBJECTS.PAS is part of TV and Object Windows, so is not
> part of the BP7 RTL. However, one can use OBJECTS.PAS without dragging in
> any of the UI units of either Turbo Vision or OWL.

My bad. It is in the RTL in FPC.

There the RTL is loosely defined as "anything the compiler needs to
bootstrap". And since 1.0.x was objects based, it is in the RTL. (and I just
tested, 2.0 still has an objects dependancy where it interfaces the (TV)
textmode IDE. The main objects are Delphi classes based though).

The visual<-> non visual unit is where I would have intuitively put the border
too.