Michael
-
Posts
13 -
Joined
-
Last visited
Posts posted by Michael
-
-
Hi Rene,
I will be there, anyone else ?Yes, i would come. So we can have some talks about EmuTOS and VR Basic.
Best regards
Michael
-
Hi Seb,
The variable BSS_E is generated by madmac and is declared global. Cannot you use it from vbcc?I made a short test:
extern char BSS_E[]; int main(int argc, char *argv[]) { unsigned long sbrk_ptr; sbrk_ptr = (((unsigned long)BSS_E+7L) & (~7L)); for(;;); /* Infinite Loop. Alpine users can delete this. */ return(0); }And got the result:
michael@netix: /tmp/Jaguar/firstmichael@netix:/tmp/Jaguar/first$ make vc -DJAGUAR -O2 -c -o main.o main.c warning 208 in function "main": suspicious loop vlink -brawbin1 -T../cfg/bjl.link -nostdlib -L/usr/local/jaguar/lib -ljc -ljag -ltos -ljagutil /usr/local/jaguar/lib/crt0.o main.o -o first.bin bin2jag -s 0x4000 first.bin if [ ! -h /tmp/test.jag ]; then ln -s /tmp/Jaguar/first/first.jag /tmp/test.jag; fi
So i can access BSS_E from vbcc. I think, i have removed BSS_E because i did not ind anywhere the declaration. And i did not know that this is automatically generated.
So i think your code should also work with vbcc.
Best regards
Michael
-
Hi Seb,
PPS: where can I get vbcc?You can get the vbcc ready for linux from http://www.hillsoftware.com/files/atari/jaguar/
Download the file jaguardevlnx.tar.gz
The vbcc was located under the path jaguar//jaguar/bin
Best regards
Michael
-
Hi Seb,
Actually, I think it is gcc vs vbcc issues.The code generated by gcc calls the function __main from main. So the crt0.s does not need to call it itself.
(see http://gcc.gnu.org/onlinedocs/gccint/Initialization.html the part on __main)
Maybe we can tweak something with #ifdef so that the "same" code works with gcc and vbcc.
Is there a macro variable defined by VBCC that indicates that VBCC is the current compiler? I know for sure gcc defines _GNUC_
The official documentation at http://www.compilers.de/vbcc.html says, VBCC defines __VBCC__
I have checked this and i was able to identify vbcc with the define __VBCC__
Best regards
Michael
-
Hi Seb,
.globl _video_height .globl _a_vdb .globl _a_vde .globl _video_width .globl _a_hdb .globl _a_hde .globl _vblPerSec
Sorry, I still don't get this part.
I just said that in the original crt0.s I provide with jlibc, these variables are declared global and are visible from any other module.
So, what is the issue with these? Is it just a matter of naming?
I renamed the variables for my use. I used different names because i like the camel convention from Pascal. And i like a prefix which indicates, what part of the system belongs to this. So my names for this variables all start with Vid because they describe the video parameters. There is no need to rename your variables.
You can ignore this part of my patch.
Best regards
Michael
-
Hi Seb,
Ok, I understand. Actually, I think it is gcc vs vbcc issues.The code generated by gcc calls the function __main from main. So the crt0.s does not need to call it itself.
(see http://gcc.gnu.org/onlinedocs/gccint/Initialization.html the part on __main)
Ok, i did not know this and was wondering, why the code did not call the initialization.
Maybe we can tweak something with #ifdef so that the "same" code works with gcc and vbcc.Is there a macro variable defined by VBCC that indicates that VBCC is the current compiler? I know for sure gcc defines _GNUC_
I have to check this.
Regarding the defined variables (width, height, ...), I don't really understand your point since I declared globl the following ones in crt0.s:.globl _video_height .globl _a_vdb .globl _a_vde .globl _video_width .globl _a_hdb .globl _a_hde .globl _vblPerSec
And these are accessible from C as any other global variables (and are used in rmvlib for instance).
It is my personal name convention. So you can ignore this part of my patch.
The variable BSS_E is generated by madmac and is declared global. Cannot you use it from vbcc?As far as i remember, i got an error. I can check this again.
Best regards
Michael
-
Hi Seb,
what was wrong with crt0.s in jlibc? I don't think I understood the reason why you changed it.Your crt0.s calls _main which is main() in C. Your init function of start.c is __main() which is ___main in assembler. So the init function of the jlibc is never called automatically. Instead your startup code jumped directly to the main function of a user.
I let crt0 call the init function of start.c ___main in assembler and __main() calls main(). You can instead call main() from crt0.s I don't know, what is the usual way. But usually the initialization of the c lib is done automatically from the startup code and not from the user.
I made also some other modifications. The ctr0.s was derived from the startup examples from Atari. This code defines a object list with 1 bitmap an initializes the graphic system. The initialization of the graphics system set some variables e.g. screen width and screen height. I have used global variables which i can access from C (leading _) and modified the name. So i was able to initialize a object list with the same bitmap than the Atari examples from C in my main() function. Your crt0.s hides these values. This is more important for my own code. But i think, to make these variables visible to other functions is also useful for others. We can check, if the other Jaguar libraries like the raptor lib or the removers lib uses these variables.
For the memory management i made also a modification. I have a variable _end which was used inside start.c for set get the address of the unused memeory ínstead of BSS_E. This is also vbcc specific.
PS: I just backported some of your patches to github repo, thanks again for your work. (https://github.com/sbriais/jlibc)thank you :-) So my work was useful for others.
Just for my information, is it the case that vbcc does not support- constructions like *(x++) = y and
I think, this should not be a problem. My test program did not generate a compiler error. But i often like to split such statements. Sometimes for debugging. I am not a friend of very short statements which are possible in C. For me it is more easy to understand the statements if they are not to short. And i think it is the task of the compiler to make such optimization.
My test software was:
----- ><8 -----
{ char buf[40], *p;
p = &(buf[0]);
*(p++) = 'a';
----- 8>< -----
- variable declarations anywhere else than at the beginning of a block?It seems yes. vbcc allows variable declaration only at the beginning of a block. Otherwise i got an compiler error:
----- ><8 -----
warning 216 in line 17 of "main.c": illegal use of keyword <int>
>int i;
warning 216 in line 17 of "main.c": illegal use of keyword <int>
>int i;
error 82 in line 17 of "main.c": unknown identifier <int>
>int i;
warning 54 in line 17 of "main.c": ; expected
>int i;
error 82 in line 17 of "main.c": unknown identifier <i>
----- 8>< -----
PPS: where can I get vbcc?I had to search. I collect all (for me interesting) software for the jaguar and Jaguar development over the last years. And forget to notice the URL. I think, i got at the start of last year many new tools which includes also the vbcc. I have installed them on my netbook before i travel toe the EJag Festival in Duisburg.
Best regards
Michael
-
Hi Seb,
That's interesting. I'll have a look at your patches to see if some can be integrated to jlibc directly. (remove C++ comments, ...)I think, it is possible to add some of the changes which are not really compiler specific. Maybe it is also possible to make the build process depending on a define for the compiler gcc/vbcc in the makefile to make the decision, which files to buidl.
If you want to glue the jaguar startup code together with start.c and main() depends on your taste. I'd like this idea for my projects.
Regarding the memcpy done by blitter by default, I don't think it is a good idea. This is funny because I had a talk with Matmook at the latest RGC and we agreed that implicit calls to blitter are never a good idea.I think it's better if the programmer has the complete control on how he manages the blitter. Imagine for example that you call a GPU rendering routine that uses the blitter, and that concurrently your m68k code calls memcpy: with your approach, this will fail.
Ok, this is a good reason. I have used the blitter because it was in an example from Atari itself.
If you like to make your lib working with gcc and vbcc feel free to ask me for testing with vbcc.
Regards
Michael
-
Hello,
i tried to make use of my SkunkBoard and write some small software for the jaguar under Linux. After try out gcc and vbcc i was first successful with vbcc, so i go ahead with vbcc. GroovyBee has a nice description about Developing in "C" in windows xp which can be used as a guide. I have used the config files for the linker from his description and used the same directory tree for my source files:
+-- cfg
+-- jlibc-0.5.10
+-- first
+-- jaglib
On the Linux development environment it was not necessary to change the directory structure inside the jlibc. But some modifications are needed:
- I have added the long arithmetic functions from vbcc to the jlibc
- Some C++ comments must be replaced by C comments
- Some macros in stdlib.h (isgigit, ...) are replaced by functions.
- memcopy functions are done by blitter (taken from Atari source)
- increase the alignment of malloc from 8 (Phrase) to 16 (Page). Otherwise my Jag did not display a object list located in dynamically allocated memory.
To allow the usually way to link a C program (crt0 (startup code), main(), objects, libs) i made some additional changes:
- crt0.s is very close to the startup.s from Atari and many other examples. This startup did not contain a object list to allow the user to choose a library he likes. The startup code jumps to __main() from start.c
- start.c makes all initializations for the jlibc and then jumps to main() Note: this version did not pass any arguments to main()! This version did also not take care of the difference between running from cartridge or running from ram (by skunk). This can be added in the same way than described in the description from GroovyBee.
My patch can be retrieved from my Homepage: vbcc patch for jlibc-0.5.10
I have also a small first.c for show, how to integrate the jlibc: first.c
The creation of the object list for my first.c was put in a small library: jaglib. My small lib was no replacement for the removers lib or the raptor lib. So the handling of the object list in first.c can also be done with the use of a more powerful lib.
My make use also a tool written by me for add/remove the jag header: Some jag Tools
I hope, some find my patches useful for its work.
Happy hacking and best regards
Michael Bernstein
-
Hi,
We do have already a TOS for the Jaguar
only this version needs to be changed a little bit.Do you speak about the TOS from Matthias Domin for the TJE card?
Yes, it is a running TOS and only some patches must be modified. But i think, not all BIOS functions are fully functional. The hardware is different. I expect, that some BIOS channels will not work. Maybe some other features had the same problem.
Video mode, now uses 2 screens in st-medium resolution, must be patched to use st-low, st-medium in 1 screen can be done, I have seen high resolution modes done already...- add JagCF support
- ramdisk support (was already implemented in this TOS)
- serial/midi support
I would suggest to take a different way. The patches of the TOS, Matthias has used, had to be modified for the JagCF card. E.g. the bios functions for access tracks on mass storage are patched for the IDE port on the TJE card and they should also be modified for the CF card. For other bios functions, like serial support new patches are needed. In think, it is more easy to add this modification to the EmuTOS project. The same with the video driver. I expect, replacing the VDI screen driver in EmuTOS is much more easy than assemble the right patches for a TOS from Atari.
I think, we should ask the developers of EmuTOS if we can add another hardware target (Jaguar) and then add changes for the Jaguar hardware to the EmuTOS source tree. EmuTOS is a free (GPL) TOS replacement, based on the sources which ar publiched caldera.
Best regards
Michael
-
Hi,
BIOS and XBIOS can be rewritten for the Jaguar, ...Yes, i dont expect much problems in write a BIOS and XBOS for the jaguar. The point is, that there is not really a choice of porting TOS or MiNT. To run MiNT, a TOS with BIOS and a few GEMDOS functions to process the auto folder is needed. MiNT is nearly hardware independat. There is no need in MiNT to take care of the jaguar hardware. This should be done in the hardware drivers which are part of the BIOS and XBIOS in a TOS port.
I expect most of the work in write a BIOS and XBIOS (and vdi drivers which take care of the jaguar hardware capabilities) and not in porting MiNT.
under JagCF system, we got additionnal memory ram, mouse and keyboard support, so we can rewrit it without a lot of problems,Nice, i can write jaguar software on the jaguar, maybe emulate the jaguar cd, ...
Best regards
Michael
-
Hi,
because MiNT is mainly a replacement for GEMDOS, you need also a BIOS/XBIOS (hardware driver) to run MiNT. A MiNT on my TT runs on top of TOS and uses the BIOS and XBIOS of TOS. So you have to start with a port of TOS. You can start with EmuTOS which is a free replacment for TOS. But if you want to run GEM on top of MiNT, you need also a AES replacement like N.AES, XAAES or MyAES and video drivers for the jaguar video system.
I think, a port of MiNT is not difficult. I think, most of the work is writing a BIOS and XBIOS for the jaguar hardware. But because of not much RAM i see not much sense in use a multitasking TOS like MiNT. It is only usefull, if you want to use the driver system and(or networking (xif, xdd, xfs)
Best Regards
Michael Bernstein
RLN
in Development
Posted
H Orion,
I think, your C Code has a variable which is part of the data segment because it is a initialized global variable. Your assembler variable is in a different segment. So it was no problem for the linker to have the variable twice, one i the data segment and one in the bss segment. I noticed this problem many years ago with a different compiler.
Best regards
Michael