Lazarus for RISC OS

[StefanRISCOS]

about file/folder syntax in RISC OS:
Why not make a RISCOSify(path.filename) call for each file name that converts from UNIX to RISC OS style?

[TRon]

Why not make a RISCOSify(path.filename) call for each file name that converts from UNIX to RISC OS style?

Something like that, yes. But I'll have to see the bigger picture first before I know for sure that is (going to be) the right approach. There is also the matter of the other way around, and if it is at all possible, though I suspect it will as you also have a gcc compiler (and thus capable of using c file i/o functionality). I really need to have a closer look at those c-sources...

[micken]

@micken
If your FreePascal compiler is able to create executables that you (after patching) can run (up to a point) on riscos then imho an easier approach is to start a new program and implement the file functions (or any other function/object/class that gives you issues) one by one, matching the Fee Pascal RTL functions. That should be much easier to debug/patch and you can directly see/note where things go wrong. At least that is how I would most probably approach it. If the compiler complains about a missing unit then you can create it and place it next to your example program.

Not sure if I understand. Do you mean a standalone program? In C? Pascal?

I am implement syscalls as I go. It will work sooner or later.

I guess we can do a libc enabled port.. would make life a lot easier. unixib which is the library it would use implements most if not all functionality of a posix system.
I am going home tomorrow and will be able to run it on real hw,,, probably can be better results.

I will also give you a tar-ball of my source tree. I have probably done a lot of mistakes because of not knowing the sources well enough.

[micken]

I now face that fpc reads from stdin. I have implemented it using OS_ReadLIne32 (https://www.riscosopen.org/wiki/documentation/show/OS_ReadLine32 )
I attach a screenshot.

Bah I missed a branch in the read swi dispatcher .. so perhaps it doesn't do stdin. Will see.

Right.. no stdin

I attach a screenshot .. it ends with a stat on hellopas.pp
I don't actually do stat right now , only return 0x0. But for stat to work paths and sufixes needs to be sorted properly .. so that might be the logical next step.

[TRon]

Not sure if I understand. Do you mean a standalone program? In C? Pascal?

Yeah, a standalone program written in pascal, f.e.:

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

1. program hello;
2. begin
3.   writeln('hello world');
4. end.
5.  

Which is ofc the exaggeration of minimalistic test/example-code.

The startup-code for such a program is exactly the same as for the compiler (program startup, intialization by the system unit etc) though less dependent on other units (and their exposed/used functionality). The compiler is in that regards such a complex program and relies on much (other) functionality that such a simple example simply lacks. Additional functions to such minimalistic example can then be added (copy-paste from existing RTL (other platform that matches most) or implement a custom written version that works for riscos). That way you are able to test/verify specific functionality for debug purposes.

It that regards it is the same process that I have to do: try to get the compiler to produce something that is able to run on riscos without errors using a minimalistic RTL implementations. That allows for writing/testing other (RTL) functionality inside such a simple example so that in case of errors (source)code can be tested and adjusted when necessary.

I will also give you a tar-ball of my source tree. I have probably done a lot of mistakes because of not knowing the sources well enough.

Your endeavors so far are a really good indication for me as well as I would run into the exact same issues that you currently run into (there might be a few less, there might be a few more) so it would very much be appreciated if (in the end or whenever is convenient) you are able to share what you've encountered so that It is possible to apply the proper fix (not that I mind replicating what you did but that would make it possible to add support for riscos a bit quicker). Do note that I am still not at a convenient point with my progress, as soon as I have something going that is helpful I'll share so that you can work with that). As I told stefan (not sure if it was public or not), Officially I haven't even really started.

I guess we can do a libc enabled port.. would make life a lot easier. unixib which is the library it would use implements most if not all functionality of a posix system.

That is something that I can't decide for you as the userbase is the one who has to work with the final product. If it was up to me personally then I would opt for the easiest/quickest road (but that might proof to be the wrong choice on the long run, I can't tell due to lack of experience with/on riscos). If the c compiler also relies on these libraries then it would imho be the better/quicker choice. Note that for example there is also a minimalistic implementation for someone that would like to address old(er) amigas that allows for you to just bang your way around the hardware, so something like that is a possibility for riscos as well (the negative side-effect is as for any asm developer that you must supply most (if not all) your own routines to be able to accomplish certain tasks).

regards,

[StefanRISCOS]

Here is some background on the path syntax in RISC OS:
Comparison:
Windows    C:\progs\test\unit1.pas
Linux      /home/progs/test/unit1.pas
RISC OS    SCSIFS:4.$.progs.!test.unit1 (filetype pas)

In RISC OS the first part is the filesystm (eg. ADFS, IDEFS, SCSIFS, RAM, FAT32FS, CDFS, HOSTFS (RPCemu))
Second part is the drive number (0,1,2,3,4,5,6,7)
Third part is the root sign "$"
Following parts are the subfolder path.
Last part is the actual filename.
There is no extention in RISC OS for the file type. The file type is saved as part of the file info.
Sadly it is not possible to have same names with different extentions (file types) as files are not accessed with the file type just by the name that doesn't include the file type.
Also as standard in RISC OS there is no difference with upper or lower case names.
This can be activated but it is not the standard setting.

So for example for C the solution for this dilema is solved by subfolders that have the name "o","c"and "h".
So in case Pascal needs also different file types with same file name same convention might be used:
RISC OS    SCSIFS:4.$.progs.!test.pas.unit1

In RISC OS the (!) is used to represent a program folder that includes some set of files like:
!Boot     (file type "Obey")   This file is run by the OS when the (!) folder is seen first time.
                               This is used to setup paths for some files or sets file types.
!Run      (file type "Obey")   This file is run when the user starts the app by a double click.
                               Here normally the loading of modules is done or version numbers checked
                               before the actual !Runimage is started.
!Sprites  (file type "Sprite") In the image file the icon of the app is stored that is shown in the filer.
                               There is normally two files !appname (68 x 68 pixels) and
                               sm!appname (34 x 34 px) But the images can be bigger also like 140 x 68 px.
Sprites   (file type "Sprite") Here all the icons are saved that are used in the window definitions.
!Runimage (file type "Absolute")  This is the actual program code.
!Help     (file type can be text, PDF or basically any file)   This file is started when use the menu entry
                               "Help" in the filer of the selected file. It will start the program
                               associated with the file type and load the file.
Res       (file type "Resource")  In this file all windows, toolbars and menues are stored for the program.
                                  It can be edited by !ResEdit. !ResEdit looks actually very similar like
                                  the  window editor of Lazarus / Borland Delphi. But Lazurus is better         
                                  structured than !ResEdit.
                                  With this Resource files also an internationalization can be achieved by
                                  saving the files for different languages in a subfolder "resources".
 
The neat thing about the (!) Pling folders is that they hide all files that are not usefull for the normal user. So if the program needs some data it will be stored in !app.data .

[micken]

The startup-code for such a program is exactly the same as for the compiler

I need to look into this.. so far crosscompiler put wrong start code in the binary. when compiling test.

Thanks for your long reply. I think I will follow the suggested route with a testprogram , just need to figure how to make that work.
I have just started to add ppu's to my riscos compiler. I need to implement seek.. there is no such thing in riscos.. but I can do a dummy read from 0x0 and up to the desired offset. Then do the real read at the current file pointer. As for paths.. I do a directory , example "system" with a file "ppu" inside that makes riscos find system.ppu relativly to current dir.


If a libc can handle all low level stuff then I think you should try building it with gcc/libc. If you look in gccsdk/autobuilder there is a port of newer gcc. In the latest one malloc/free is handled  pretty well compared to gcc4.

[TRon]

I need to look into this.. so far crosscompiler put wrong start code in the binary. when compiling test.

You could try and replace the default used startup (compiled) object file with your own. In such a case you would have to recompile all units that rely on them though because FPC uses a checksum for ppu files (and refuses to continue when not recompiled).

I need to implement seek.. there is no such thing in riscos..

If I would have to take a stab at it (riscos internals noob) I would look at lseek implementation for the c compiler (https://www.gnu.org/software/libc/manual/html_node/File-Position-Primitive.html).

It is possible to either use libc alternative and/or implement in (native) Pascal. In case the latter there is no law against peeking how it could be implemented. Most basic (RTL) functionality (between c and pascal) is pretty much similar (sometimes there are small diffs such as order of parameters or some limitation/extension that can usually be accounted for. At the least the naming differs (most of the time)).

but I can do a dummy read from 0x0 and up to the desired offset. Then do the  real read at the current file pointer. As for paths.. I do a directory , example "system" with a file "ppu" inside that makes riscos find system.ppu relativly to current dir.

if I understood correctly the circumflex could be used for relative path schemes. What is unclear for me with what is mentioned in the user documentation is if that only applies to full path schemes, only applies to "current directory" (if there exist such a thing) and/or if it can be used multiple times in a pathname. The 255 character limit (as I understood there is might pose a problem but there are other platforms supported by FPC that have similar limitations (and work correctly). I have tried to locate the technical documentation for file (name) related handling but was unable to find it.

If a libc can handle all low level stuff then I think you should try building it with gcc/libc. If you look in gccsdk/autobuilder there is a port of newer gcc. In the latest one malloc/free is handled  pretty well compared to gcc4.

See also my answer regarding c implementation. That is also one of the things I meant with "the bigger picture" (that I mentioned in one of my previous posts). If we can get a small workable RTL working using our own code then we can continue to work from there. The only thing I am not sure of if that is feasible (though to your expertise seems to indicate it might be possible to come up with a small/quick RTL implementation). It also depends a little on how quick you/we wish for things to happen.


With regards to your "input" problem. How does your terminal/shell handle this situation ? I mean, a shell usually has some basic functionality with regards to files and piping to input/output handles. I have seen some shell functionality being mentioned in the online documentation (but I do not fully understand/grasp the implication wrt (other) os internals).

[TRon]

Here is some background on the path syntax in RISC OS:

Thank you for that extensive description stefan, it is very much appreciated as it adds some things in addition to what the user manual wrote (at least it makes me understand things a lot better).

So, am I correct to conclude that in that case it is not possible to have filenames with a dot in their name (as it is used for indicating a separation between directory/folder names) ?

If that is the case, then I have to assume that whenever you would for example download a file with an extention that the (OS?) filing system automatically takes care of such encounters ? How does that work in practice ? Is that (officially) documented somewhere ?

fwiw: I am familiar with filenames not indicating anything wrt file type. For example the Amiga uses file type descriptors based on internal byte-sequence recognition but it does allow for dots in their file/directory names. Often you can find there a filename such as mod.some_game_name.some_title.with.dots.some_author.with.dots but sometimes a user prefers to use  some_game_name.some_title.with.dots.some_author.with.dots.mod instead (some users are more familiar indicating some form of filetype with the last dot extention). Point being that the position of the dots themselves do not matter (but are allowed).

[micken]

@TRon

I found a seek replacement today, unfortunately the return value from my seek function gets corrupted , or I have some bug in my code. Both issues are possible.
 I also found a better way to alloc memory, but haven't implemented yet.

Is it possible to have printouts "volatile" , it seems like they are randomly not printed. Ofcource it can happen because of a crash, but I don't get why it happens before crash,

[TRon]

Is it possible to have printouts "volatile" , it seems like they are randomly not printed. Ofcource it can happen because of a crash, but I don't get why it happens before crash,

Sorry, I lost you there mate (perhaps it is me having an off day). Which printouts and what do you mean with volatile in that context (and speaking of which, what exactly is the context)

[micken]

Is it possible to have printouts "volatile" , it seems like they are randomly not printed. Ofcource it can happen because of a crash, but I don't get why it happens before crash,

Sorry, I lost you there mate (perhaps it is me having an off day). Which printouts and what do you mean with volatile in that context (and speaking of which, what exactly is the context)

Sorry!
I have sprinkled my code with Writeln. A lot f times the printouts doesn't happen. Is there a better way to print from compiler?

[StefanRISCOS]

Here is some background on the path syntax in RISC OS:

So, am I correct to conclude that in that case it is not possible to have filenames with a dot in their name (as it is used for indicating a separation between directory/folder names) ?

If that is the case, then I have to assume that whenever you would for example download a file with an extention that the (OS?) filing system automatically takes care of such encounters ? How does that work in practice ? Is that (officially) documented somewhere ?

On the normal RISC OS system files from other OS is correctly dispayed but with "/" instead of ".". The module that does it is MimeMap that can be found in !Boot.Resources.!Internet .
But it is not implemented in RPCemu so there you must manually set the file type. We have implemented a function in !CLfiler that does it automatically SHIFT+S for all selected files.
On RISC OS there is not to many programs that can process all filetypes that are available on Windows/Linux. So not for all extentions there exists file type definitions on RISC OS. FOr example JFIF and EXIF is set as JPEG. YOu can see that on the screenshot of !CLFiler.

[TRon]

I have sprinkled my code with Writeln. A lot f times the printouts doesn't happen. Is there a better way to print from compiler?

No need to be sorry. Now, I get it 

I don't know if your emulator and/or OS has some way to display (debug) output as that would be a better option then. For example the Amiga has some functionality in place for that and the FPC port also includes a sysdebugln function. It is basically a (pascal) subroutine that outputs text to an available output (device). So in case the OS/Emulator has provision for something like that then i would advise to use it.

Now that i know i also understand your volatile remark a bit better: try to use shortstrings e.g. var s: shortstring or var s: string[10]. The first denotes a (oldstyle) pascal string that is able to store max 255 characters while the latter allocates 10 bytes for such a string. Note though that pascal strings (whether shortstring or ansistring) always store their length in their zero indexed byte. see also https://www.freepascal.org/docs-html/ref/refsu9.html and if in case you wish to know about all available string types, see https://wiki.freepascal.org/Character_and_string_types

[TRon]

On the normal RISC OS system files from other OS is correctly dispayed but with "/" instead of ".". The module that does it is MimeMap that can be found in !Boot.Resources.!Internet .
But it is not implemented in RPCemu so there you must manually set the file type. We have implemented a function in !CLfiler that does it automatically SHIFT+S for all selected files.
On RISC OS there is not to many programs that can process all filetypes that are available on Windows/Linux. So not for all extentions there exists file type definitions on RISC OS. FOr example JFIF and EXIF is set as JPEG. YOu can see that on the screenshot of !CLFiler.

The important part for me to know if it is at all possible to represent a dotted filename in riscos so that it can be accessed in a similar way as other platforms do.

If that requires registering a filetype then so be it. There is simply need to be able to access files that have exactly the same filename but only differ in extention (that is something that can not be altered easily as all the file(name) related functionality depends on that behaviour).

So for example, the source of a Pascal unit is named myunit.pas (or .pp), the compiled unit is named myunit.ppu and the assembled object file is named myunit.o. See for example https://wiki.freepascal.org/File_extensions which list some of the extentions  that are used by the pascal/lazarus infrastructure (and their filenameonly part can all be the same, residing in the same location/directory).