Turbo Pascal PopolonY2k's Framework

@rolandve, you can find the official Turbo Pascal 3 manual from Borland, googling on internet. I bought this book in 2012 at Amazon and surprisingly it was brand new, I think that this book was well stored because there's no any old yellow pages marks. Here is the link I found googling http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/tur...

About the Inc procedure, it was added since Turbo Pascal 4 but could be added to Turbo Pascal3 writing code in Turbo Pascal or even in ASM through Inline call.

The Inc routine described by you could be written as described below:

Procedure Inc( Var nValue );
Begin
  Inline( $2A/nValue/      { LD HL, (nValue)  }
          $34              { INC(HL)          } );
End;

Try this code and it will work fine (for integer operands, for byte operands too but don't forget the limits of a Byte :) )

I'm used to assembly code using Inline calls directly in Turbo Pascal but after I discovered the excellent tool created by Hans Otten in 1986, known as INLASS, my life changed forever :).
INLASS is capable of assembly code written directly in ASM, generating Turbo Pascal Inline calls. This is very cool because you can create long jumps, relative jumps, conditional jumps in your ASM code easily and the INLASS can manage this perfectly well. I'm using INLASS since the last year and I'm really impressed with this tool. This is a kind of tool which you never can forget when you're creating things for MSX in Turbo Pascal.

Check about INLASS here http://msx.hansotten.com/index.php?page=msxpascal
The INLASS documentation can be found here http://pascal.hansotten.com/uploads/msx/inlass.pdf
A good web site with the complete Z80 instruction set can be found here http://nemesis.lonestar.org/computers/tandy/software/apps/m4...

[]'s
PopolonY2k

Everything is possible if you know how to code in assembly Until now, I ran in to the following issues:
- Mmmm, function doesn't exist is TP3, is there is Library that does the same thing (and where)
- Mmmm, that include file also has a function called XXXYZ and it behaves different from that library so you can't just mix libraries.
- Documentation of the library is not always up-to-standard. Popolony's libraries are OK, others are not, so you are forced to read the source (good luck, not always decently structured).
- Libraries are not consistent. For example (I believe its Kali's) code has a write to vram function where you can store blocks of data in vram by using (location, amount and character). Reading however: (location, amount and address).
- TP quits after 1 error, correcting the error, recompile and finding the next is really annoying.
- sometimes things are impossible if you do not speak assembly, because nobody ever had a need for that capability. (After all a library is made by someone when he/she has need).

This is not complaining: it comes with the fact that your trying to write code for 33 year old systems, but it is annoying and keeps people from programming because you spend more time debugging/collecting/finding/rewriting than doing your own coding. Thats when people either decide to quit or create a n' th version of a library. After all, when a hobby starts to hurt, people stop.There is a positive thing: the people here are really helpful

@AxelStone, thats one thing I haven't seen in MSX yet. The equivalent of DLL's.
Another thing, I will not see happen soon is being organised. Most people around here, have no intent to spend much time on MSX related business. They have their pet projects and thats it.

Having said that, I would contribute my time to creating new TP3 libraries for Pacal that combine and extend the currently available libraries.

@rolandve, about a feature like DLL, very soon will be possible to create things very close to a dll using my framework. I have coded a solution for this, not so open as Windows DLL or Linux SO (Shared Objects) but will help a lot when you're trying to create a non monolithic software with loadable modules, using better the memory area that is limited even when you're using extended memory devices like Memory Mapper or MegaRAM.

Another good technology which I already have implemented is the possibility to add support of to use Memory Mapper (and MegaRAM in the future). I already have ready here, implementations for using Mapper through the standard mapper functions and directly (this is the best way for me because is faster than stardard mapper functions).

[]'s
PopolonY2k

Hi Popolony2k,
DLL's can be implemented in simple ways or complex ways
The easiest way, I imagine in just the assembly, located at some address in memory. A load routine places it there, can be in a memory mapper of the current memory block, depending on the size

Because the loader routine knows, where the code is loaded, it can jump there. The jump routine is the routine where the user gives the memory address of the parameters expected by the routine and then the processor jumps to the loaded routine, knowing where to store its result and where to jump when done.

struct lib_parameters {
     register.a = &H3000
     register.x = &H13
}

Load_Library('a:\sdk\pascal\screen.lib',segment, address);
Call (@lib_parameters, address);

What is more problematic is:
- DLL's calling other DLL's. Something you should not do, because there is no guaranty that memory will not be overwritten. After all, the creator of the dll can do al kinds of nasty things..
- Versioning (aka as DLL hell) and associated upward compatibility
- Loading & unloading: since the compiler has no support for this (thus no dynamic), loading and unloading has to be done by the user.
- Message passing: the DLL probably does something and leaves a result. This result should be available to the calling code when the dll is done.

However, far more complex and large programs can be written, when external libraries of code can be called and executed on demand. I love to think with you. My assembly is non existent so I my practical value is 1/X.