ST-Oldie

Hi, I received the game as an "answer" to my payment a few days later. Best regards Michael

Hi, i have recieved a mail last day and i am No. 134 Best regards Michael

Hi, Thank you for the link to the description. This gives a good overview how CJ converts the games. So CJ does a mix of patching the game and add some emulation parts. It looks like this is also a hard way to get the games run. I play a little bit with EmuTOS. If i add the GPU code which converts from ST screen to Jaguar "screen" maybe there is a chance of run some games on the jaguar under EmuTOS. Maybe. But if i read "port a game", i usually think in source code which makes it more easy to make a port. And i think, there are not much people who can or want to convert a ST game to Jaguar like CJ does. Best regards Michael

Hi CyranoJ, I think, you havbe missunderstand what i want to say. I talk about 3 different things: 1. have no souce code and rewrite from scratch. I did not call this emulator! 2. have the source code and port it which means to rewrite parts 3. run the the existing binary with an emulator. And mainly i asked the people who asks for ports, if they first could find a source for sourcecode. Ok, sourcode for modern PC is to differnet. This is also a big work to port a modern game to the jaguar. Best regards Michael

Hi Daniele, Did you have the source code? I see from time to time questions for a game from other systems. But nearly always without links to sources. Without source code it is a complete new developement, a remake. All graphics and sounds must be generated. The game logic must be reinvented to match the original. Much work, it is a complete new deveopment. With existing source (in a high level language, not assembler) parts (e.g. the game logic) can be reused. Graphics can be used or converted. This can save some time. Try to run a binary from different hardware needs always an emulator. Also if the CPU is the same because other hardware parts are much different. As an example take a look at http://dmweb.free.fr/?q=node/851 There is a remake of Dungeon Master and Chaos Strike Back from Atari ST for Debian Linux. He has disassembled the original game and then converted this to C++. And this was a fulltime job for 6 months! But with his source code and the original data files there was a base for port this games to the Jaguar (and back to Atari ST). Because the data are from Atari ST, the graphic resolution (not the color depth) mach the resolution of the Jaguar. So there is no conversion needed. Regards, Michael

Hi, I remember the disassemble project for Atari ST GFB Basic. Some years ago i got the source code for the planned GFA Basic 4.00, written in C with the use of ACS Pro. A few years later i had contacrt with someone interested in GFA Basic. He took a look in the source code for GFA 4.00 and told me, there was a disassemble project. The goal was to understand whya GFA basic was so fast and (maybe?) build a successor which is as fast then the original interpreter. As far as ai know, the token code (.GFA files) ist fully understand. So im am pretty sure there is no need to disassemble the old GFA interpreter. I would say, with the knowledge of the token code it is possible to write a interpreter whihc is (nearly'?) as fast as the original. Best regards Michael

Hi, Fine. I expect a nice small paltform for Virtiual Jaguar. I did not have any knowledge about QT and OpenGL. I write software at work for embedded system which dont have a GUI. Otherwise i would have published a pacth with my question. But so i had to wait for someone with mor knowledge. Best regards Michael

Hi Shamus, But it compiles with my changes also with Qt4. Does it really need Qt5? I had to change only the include files, Qt4 needs other include files (found with help from google). And there are one file which uses the standard paths of the applications which should also be changed. I used the help of google and it found, Qt supports also GLES. It seems, my repeository has a Qt with GLES support instead of GL. Maybe this is because my device is a ARM based SBC and more like a embedded system than a powerfull PC. I am afraid it needs more than fixing some definitions in the .pro file. There are functions like glBegin and glEnd not declared. A short google seaqrch indicated, that drawing vertexes must be made with a different approach than currently present in virtualjaguar. Sadly i have not knowledge with GL and GLES (and qT), so i did not try to modify the source. If you would like to solve this problem, i can try to help you with my limizted knowlwdge about GUI development. Best regards Michael

Hi, i tried to build the virtual jaguar from git clone for my Beaglebone Black. After some problems with compile and a hack on EJag Fest i now tried to search for the clean solution. The INSTALL file said, i need QT >= 4.7.3 but not QT5. This is not right. With the help of google i found, the include files will only work for QT5 but not for QT4. The same with the class for file locations. I changed the include statements to allow to compile the source with QT4 and with QT5. The output with the diffs from git are attached. If someone will give me access to the repository, i can commit my changes. There is also a problem with QtOpenGL on my system. It seems, it support only OpenGLES. OpenGL was also present on my system. If i changed the Makefile (define for include and lib gl instead of gles i can compile and link the code. But i did not know if this will work. A test did not show any output. My knowledge of QT and OpenGL is very limited (nearly 0). But if someone will help me, i can try to change the code to suport also OpenGLES. Best regards Michael

Hi No problem, we have no time pressure. Maybe i did not see this error because of the warnings about "!short". I dont know if i have time left before christmas to take a look at this. If you like to look for it, feel free to do this. Best regards Michael

Hello, I made a test with UDO 7.03 on Windows and got one error and UDO stops to convert the text. After some digging i found 2 bugs with begin_node/end_node (chapter depth). It seems, the handling of errors is different in UDO 6 which i have used in the past and the actual UDO 7. I made a bugfix in the UDO source files. Now it converts fine. I got many warnings withj UDO 7 about "short is deprecated" but this can be ignored. I made my conversion to a test rtf without bitmaps. So i got also error about missing bmp files. To convert the udo source, first the right pictures should be copied into the folder with the udo source. For rtf the pictures must also converted to windows bmp format. I created the udo source on Atari ST. If the udo source is converted on an other platform than TOS, a "!code_source TOS" may be a good idea. This leads UDO to expect Atari ST Codepage for the input source. I did not see any other errors or warning with my test. Maybe there is a problem with the case of the filenames? I made an update of the source and also of the test rtf on my homepage. Best regards Michael

Hi, My work was not announced in any forum because at the time i download the scan and made ma OCR someone claims the right for publish the scans. And over the time i forgot to make this more public. I use udo 6.4 on Atari, but with UDO-Shell. And i use the defaults from UDO-Shell. I dont know which parameters tis gui use. I did not get this problems. I can check with a newer version of UDO, maybe on a different system. I made a rtf with my UDO system, but without images, you can get it at http://www.mbernstein.de/download/jaguar/jdm.zip The output is different from your work because you try to rebuild the original format, but as text instead of a image. UDO did not take care of this, so it looks different. The same for me. But because i started with Atari Computers, some old Atari document formats are more common to me (at this time). PDF and RTF are to modern and not so common. PDF always did not work as well than on PC. But ST-Guide help system and html was much more interesteing. HTML also for online. Best regards Michael

Hi, Nice to have the documents available as a text instead of pictures. This is much better. But did you know my package at http://www.mbernstein.de/download/jaguar/jdm.lzh? I have done a OCR over this documents in the past. I had send the package also to the guy who published the scaned Manuals. It seems he did not make much use of my work. The difference to your work is the file format. I had convert the files to the UDO format which is a meta format and can be converted to many other formats. Maybe this will help you to avoid some work. Best regards Michael

Hi toarnold, Text output was also the first software i made after i got my skunkboard. But i have reused some example code from Atari. You can take a look at http://www.jagware.org, there is a thread about usefull tools and examples under "development" (http://www.jagware.org/index.php?s=e1b7f1f49a2b17d7e00ddeeadb1c5d9e&showtopic=836) You should take a look at "jagfiles" (http://www.jagware.org/jag_uploads/dev/curt_vendel_jagfiles/) If you download jagfiles-1.zip, ... , jagfiles-12.zip you find in jagfile-9.zip the folder "Jag util sources" which contains text output with blitter. You will find also other usefull examples, many from Atari. Best regards Michael

Hi, Mabe http://www.mbernstein.de/download/jaguar/skunkgui.tar.gz ? This is a small tcl/tk script which realises a gui similar to the windows skunk gui. Linux jcp is also needed. Console output did not work (not implemented). The output from jcp is in some cases malformatted because it uses for progress a some like "rotating" chars which replaced old values. Instead you see this one after another. Regards Michael

Hi, This is a good hint. I found these include files also in my example. I agree with you to make a try with n3d.h and n3dintern.h instead of tri.h and triintern.h. A short look inside indicates, that there may be not much changes. Best regards Michael

Hello, I dont have them in my examples, so i expect, nobody has them. They are missing in teh 3d example. But it should be possible to recreate them. Put the prototypes for each "non-static" function from tri68.c in tri.h Then you see, which data types are missing. They can be recreated if you check, which members of each data type is used in tri86.c. For the type of the member you should examine the context in wich the member is used. The tri.s exports only 2 C functions: /* functions sin() and cos() */ /* arg passed in units of PI/1024 - no range limits */ short sin(short a); short cos(short a); There is only the question, what should be in triintern.h Usually there are definitions which are not exported to the public but used in more than one file of a library. Best regards Michael

Hi, a few years ago we had a VR prototype from Atari for the Jaguar on the EJag Fest. See: http://www.youtube.com/watch?v=MFZCgNBxkcM Regards Michael

Hi, Yes, you can. But EmuTOS allown is not so usefull on the Jaguar for most of the people. And i think, it will be not possible to use it for playing Atari games. The hardware and also screen layout is to different. Matthias Domin told me, the GPU was not fast enough to convert "on the fly" the plane format of ST low resolution to a non-plane bitmap on the jagar. Yes, i think also it is a interesting project. And if it works, it can inspire other to projects with EmuTOS as a base. I think, most of the jaguar owners will not use EmuTOS. Only if it comes together with something usefull. Maybe other people got some interesting ideas how to use EmuTOS if it available. Is there the danger, that this project will die? I remeber the TOSonJag Catridge which was published (but not developed) from Matthias Domin. It was a old project with IDE and PS/2 ports. There was also a CF card adaptor which was never published. But i did not know if this card has connectors for mouse and keyboard. I think, the ramdisk is really needed to "customize" the system. It allows EmuTOS to boot and load drivers or add software without the need of another "standard mass storage" or a modified EmuTOS. Load drivers from the ramdisk will allow you to have one EmuTOS for the Jaguar without changes in the source code for different projects and hardware. Is there someone negative about this project? I only think, it is not so interesting for most of the jaguar owners. It is a little bit special. It should be possible to use the existing development system from Atari for Atari computers together with EmuTOS on the jaguar itself. But then you need a additional mass storage. All parts of the development system together are to much for a ramdisk with enough ram unused to start a program. But on the other side it is possible to use the VDI for graphics and AES for a user interface. So you have a graphic lib with EmuTOS. And if the VDI uses the GPU, it can be a fast graphic lib. But the VDI screen driver can only write to the screen, not to bitmap. Having 2 bitmaps, one displayd and one which is drawn is not possible with the VDI without modifications. So there are enough room for interesting ideas, but there is also always a little bit work needed to realize the ideas. Maybe it is possible to have a virtual keyboard like smartphones and tablets have. If this keyboard injects the keys into the VDI or AES ... The only problem is, the application with the top most window get all events. But i expect nobody will edit huge amount of text with such a virtual keyboard because you must use the gamepad as a pointing device for select a key. What about the never released CF card cartridge? Does this device has connectors for a keyboard? Together with a mass storage (and maybe a ne2000 clone nic) it was a very nice base for EmuTOS. Regards Michael

I think, EmuTOS is a little bit to big for the Jaguar startup EPROM. The space reserved in the addres space was only 64KB. I remember i discussion about a OS for the (never released) CF card adaptor. EmuTOS can be used as a file browser and starter of CF based games and can also provide a API because every CF based game can lay on the presence of this API. EmuTOS can also expanded to start a .jag from CF card. I see more use of EmuTOS for hardware extensions.

As far as i remember, JagOS contains also some functions which can be called from a Jaguar binary. Not really a full OS but like a first step.

Hi The second is ok and right, you can ignore them. If you look into the souce you see, that there is a comment that there should be a infinite loop. Jaguar games never terminate! You never come back to something like a OS, so this is ok. The first one looks like the "standard" startup which i also used. I think, the warning is generated because the code access the register of the GPU which is outside of the code. So the warning is correct but you can ignore them. Best regards Michael

Hi, :-) No problem, i expect to get help in this forum if i need some. So i am also willing to share my informations to help others. I am aware of this. I started the same way. I found some small examples and try to compile them. Thats also the reason why i wrote my small tools. I got a small binary which i can call from make. So my make gives as a result the format i want to have. It looks like you have some experience with write software. So i think, it should be not problem for you to compile my tools for windows. I compile them only for linux and use them in linux and compile them for Atari TOS. You must take care, that the structs which are written to the file, are packed (word aligned). No. The header was used in a homebrew(?) development system called jagserver. This was a hardware connected to a computer and allow to load software in the jaguar. If you want have more information please use google. I don't have this environment. All jaguar games (cartrige and CD) are linked to a fix address. There is no relocation information like in binaries for operation systems. So the jagserver adds 2 additional headers. The inner header gives information on how to use the binary. Thé outer header gives information about the address for which the binary was linked. The outer header format was derived from the Atari GEMDOS header format. You can see this if you look in my source code. I wrote my Jaguar software on a linux system with a Makefile. So i don't have a different solution. As fas as i have seen, nearly all IDEs use internal something like a makefile. On most systems it is possible to add some "post-operations" where you can add tools like my bin2jag and define the compiler you use. Best regards Michael

Hi, I am not so familiar with the develpment system you use. But if i look in your makefile i think, you generate a binary without header. The startaddress is set to 0x4000 whih is ok. To run this file in Virtual Jaguar you need to generate a .jag file which is your binary with a additional header. A easy way to do this is to get my tools from: http://www.mbernstein.de/download/jaguar/jaghdr.tar.gz This source package contains a tool bin2jag which can add such a header. You can add a call like bin2jag -s 0x4000 jag.bin to the makefile and get a jag.jag as a result. This file can be stored in the software directory of virtual jaguar. I do this in my development for the jaguar and it works pretty well. Best regards Michael

Hi, If you really want to make character output on the Jag screen i can provide a lib which is derived from some Atari example code. To use this lib i have to set up a object list with one object which covers the whole screen and works like a screen memory for the character output. So my part for character output goes hand in hand with my part for set up a initial object list. You can go to my homepage in the Jaguar download section http://www.mbernstein.de/download/jaguar/index.htm and download jaglib. This library includes the code for character output (font) which is derived from Atari code. I have als a additional library which hides a few paramters of this library and which i use for test. This lib uses my jaglib, but hides some internals and provides functions similar to the TOS API. But this lib is not yet available for download. Best regards Michael