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