ST-Oldie
-
Content Count
29 -
Joined
-
Last visited
Posts posted by ST-Oldie
-
-
Hi,
i have recieved a mail last day and i am No. 134
Best regards
Michael
-
2
-
-
Hi,
Hello Michael, CJ doesn't do any of those things with his ST "ports", he does:
4. take ST game and tickle it until the Jaguar finds it agreeable - the process is briefly outlined on our site.
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.
I think (not at all sure, lol) this thread was designed to give CJ some suggestions for getting ST games working on the Jaguar this way. Of course, the problem there is, everyone has their own favourite ST games but many are not suitable and CJ probably already knows more about ST games than anyone still active on Atari given what he's been up to for the last 25 years or so... so there's little point in listing games this way, best people just wait and see what appears. Although it does help show what a wealth of decent titles the "lowly" ST has.
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,
Really? I'll have to look into that then, cuz I'm sure that's not what I've been doing

I wouldn't call this emulation either, emulation implies that you just pass any old binary from the emulated machine and it'll run. That most certainly isn't what's happening here.
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,
you got it wrong!
sorry ....
I would like Cyrano converts these games atari st
would be greatDid 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,
Also forgot to mention GFA-Basic for the ST was breifly considered. I did get an e-mail about that.
However, reverse engineering the entire package is a lot of work to say the least and although it is all rebuilt from the ground up, a large percentage of it is still not fully understood and documented. GFA for the ST was quickly ruled out as a candidate.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,
It's a bit of a shame that GLES isn't just a one-line change in the .pro file, but it isn't a disaster. It would be fairly simple to add a GLES renderer in the GUI and some #defines to control compilation. I do have a RPi kicking around, so maybe I'll have a chance to do some testing there.
Fine. I expect a nice small paltform for Virtiual Jaguar.
If you (or anyone!) want to write a patch to support GLES, feel free, and I'll make sure it gets supported by VJ.

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,
Well, the doco is slightly out-of-date.
If you're building from GIT sources, you will need Qt5 as you discovered. 
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 don't know if Qt supports GLES; I would be quite surprised if it didn't as it's meant to work on tablets and phones now. Virtual Jaguar's use of OpenGL is quite minimal and I would suspect that supporting GLES would require nothing more than fixing some definitions inside the virtualjaguar.pro file. If I get a chance I'll look into it to see what's required.
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
Thank you for the updates, and sorry for this late reply.
No problem, we have no time pressure.
I have tried with your new package and just got 2 errors (on the ALN.UI file by example), errors different from the previous ones.
"maximum token number exceeded without further..."
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've tried UDO with your files but was not able to generate PDF or Rtf files. I'm using UDO 7.03 on Windows (command line) and I just got errors whatever the formats selected.
Most of the errors are related to "too many words..." or "items ignored...", but please could you generate one or two PDF and/or Rtf files at your side? To see how it looks like.
If you can also send me your options used in the command line, it will be useful, just in case of.
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,
Thank you very much for this information. Your work was unknown to me and I'm glad to know someone did OCR actions before.
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've tried UDO with your files but was not able to generate PDF or Rtf files. I'm using UDO 7.03 on Windows (command line) and I just got errors whatever the formats selected.
Most of the errors are related to "too many words..." or "items ignored...", but please could you generate one or two PDF and/or Rtf files at your side? To see how it looks like.
If you can also send me your options used in the command line, it will be useful, just in case of.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.
And, I'm probably too old fashioned when it is about documentation - PDF or Word files have my preferences.
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-
1
-
-
Hi,
I have done an OCR action on one of them (Technical Overview) ...
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
-
2
-
-
Hi toarnold,
Like many other Jaguar owners I got my Skunkboard last week. 'Cause I'm familar writing C and 68000 ASM code, I think the 'hello' sample is a good place to start.
After reviewing the source code I thought using the blitter is a good topic to dive into the jag.
Clearing the main screen was easy with the blitter, but after that I tried to copy the characters using the blitter. A char is 8x 8bit monochrome, but the screenbuffer isn't.
All my attemps results in an 8x8 pixel black hole :-(
Has anybody done this before?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
-
2
-
-
Hi,
There is also a skunkgui for windows.
Need to check there was one for linux aswell can't find the link right nowMabe 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,
Atari changed the names... in my triangle demo arc (from the Jaguar Source Code Collection), the names are n3d.h and n3dintern.h. I don't know which is older, but you can PM for a copy of the arc, or you could just try to use the two files. Note that the names of structures in the files use N3D in front, like N3DOBJECT.
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 wanted to compile the Atari 3D demo but I miss the following files in my archive
#include "tri.h"
#include "triintern.h"Does anyone has these missing files ?
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
-
3
-
-
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,
EMUTOS can run from cart (skunk) or other cart, can be loaded from CD.
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.
I find it an interesting project. TOS on ST is about 512Kb so would leave 1.5Mb free of RAM.
Yes, i think also it is a interesting project. And if it works, it can inspire other to projects with EmuTOS as a base.
This is one of those things like JagOS functionality not much people would maybe use it but its to interesting to let it die.
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 have seen a TOS cartridge in the past that never made it to production, the idea was nice to see TOS running on the Jag with mouse (kbd) could be aswell...
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.
When EMUTOS has a ramdisk like the build version has now and it could be use input from mouse/kbd (not implemented yet) it would be nice, atleast for me and a few others.
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.
Its a free (no cost) project so why be negative on someone who has fun doing this...
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.
While there are plenty other and more comfortable options these days to code for Jaguar, this one seems to be actually the only one to code natively on Jaguar , no ?
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.
Still, without a keyboard, entering all code through the gamepad ...

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.
Wasn't there ever a way to attach some sort of keyboard to jag ?
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
This all just started giving me errors that it wasn't giving me 10 minutes ago.
C:\jaguar\SOURCE\hello>make /f makefile Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. smac -fb startup.s startup.s[82]: Warning: GPU/DSP code outside of absolute section vc -DJAGUAR -O2 -c -o jag.o jag.c warning 208 in function "__main": suspicious loop vlink -brawbin1 -Ttext 0x4000 startup.o jag.o -L/jaguar/lib -lvbcc -o jag.bin C:\jaguar\SOURCE\hello>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,
Thanks!
:-) 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.
The sample isn't mine
I am aware of this. I started the same way. I found some small examples and try to compile them.
I just want a dev environment that is simple to use.
I'll want to see if I can use the jag header under both windows and linux.
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).
Quick question - is this head the one that I would use to make a cartridge or CD?
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'm open to suggestions. How do you compile (or assemble) and link your Jaguar games if you don't use make?
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
-
1
-
-
Hi,
I found a sample "Hello world" jaguar program, and I got it to compile. The makefile generated a jag.bin file. I want to run it in Virtual Jaguar, but all I get is a blank screen. Is anyone familiar with this hello world sample?
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
-
1
-
-
Hi,
Surely there must be some assembly library out there for a fake printf kinda deal. Right?
For my part I looked over Michael Hills C dev tools 1.0 and in particular the hello.c example. I was hoping to find a borrowed assembly library for character output. No dice. I could have missed it being an extreme newb, though.
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
-
1
-

Another World Jaguar Pre-Order
in Atari Jaguar
Posted
Hi,
I received the game as an "answer" to my payment a few days later.
Best regards
Michael