belboz

No. It is (V)olker (B)arthelmann's compiler (vbcc) It is a C compiler. Highly portable and easy to build. http://www.compilers.de/vbcc.html

Thanks everyone for all the great comments. Thank you sgrddy for the donation to the server funds. My hosting renewal is coming up next month, so it will help with that. Most appreciated. Been seeing quite a bit of activity on the downloads for the live CD's. Everyone please give me feedback if you see any problems with any of the tools. The OS X toolset is probably the least tested, so let me know if you find any problems. If anyone thinks of some other tools, samples, or anything to add to any of the toolsets, let me know. I am going to be releasing an update to the Windows version of my toolset here in the coming days. It will be a installer like the previous version that upgrades the original install, or does a fresh install if needed. New things on it will be newer versions of vbcc,vasm,vlink, and jcp. We are pretty covered now OS wise. We have C/asm toolsets for Windows, Linux, and OS X!

Also since I am on a roll I have just released an archive for OS X users (x86 only for now). The archive contains the VBCC compiler suite, smac, sln, jcp , a sample you can compile and download to your Jaguar, and various Atari samples and documentation. So now OS X users can get going on Jag development! If there is any interest in PPC binaries I can look into it. But for now you need an x86 OS X machine.

Also I just released an archive for existing linux users. It contains all the tools, examples, docs etc that are contained on the live cd's. So if you are already using Linux this is a nice archive. If you already have the dev tools setup on your Linux box, you can still grab this archive for the VBCC compiler contained in it. Enjoy.

Everyone, Posting this here since I want everyone to see it. Even those these two CD's are good for developers, they also have benefit to just the hobbyist too. Today I just officially released two ISO images of live bootable CD's of my Jaguar development setups. One is text only based and geared towards systems with low memory. You need at least 48MB to boot it. The second is a full blown graphical user interface that needs 256MB of memory. Both load entirely from CD and use only your RAM. No files are installed on the hard drive. You can however access your hard drive(s) partitions if you wish. So why might you need these? Well if you have a Windows 2K/XP system and are having trouble with the Atari tools running properly, or you have an older system you want to use with a skunkboard, but only have an old Windows 9X installation on it, these CD'c can prove useful. If you just don't want to go through the setup and configuration of a developers setup it might just be for you. So what do you get when you boot from these? Here is what the text mode live CD offers. All setup and working. Linux GCC compiler (so you can compile linux console based programs) GCC for 68K VBCC for the 68K (I offer both compilers so you have your choice on what you want to use) mac (atari macro assembler) aln (atar linker) smac and sln (SubQ's version of the above two tools) jcp (for downloading and flashing either rev skunkboard) Removers Library and Jaguar Library (Seb's libraries that really make getting into C programming for Jag developers easy) Seb's rmvjcp (custom version of jcp that works with seb's library above) converter (Seb's image converted utility) wdb/rdbjag (Atari's debuggers for Alpine users) bjl downloaders (for BJL users who wish to send code to their Jaguar) unrar/unzip/wget/minicom/midnight commander/sshfs,hexdump (and much more basic linux stuff) wget mentioned above is a nice little console app to let you download things from the internet or local net without needing a browser sshfs mentioned above lets you mount secure file systems on other system Now the GUI version (my favorite version) contains all the above plus. Programmers editor. This is a nice syntax highlighting editor that I have customized to allow you to build your projects, download to your skunk, bjl jag, or alpine from the editor, and reset your Jaguar from the editor. The editor also lets you jump automatically to the line with an error during compilation or assembly. Makes for an awesome development environment. Also other gui based apps on here. Firefox for browsing website (flash is installed) Filezilla (ftp client) X-Chat 2 (irc client) Transmission (bittorrent client) VNC Viewer and server picture viewers gui hex editor k3b ( nero like burning software) cdrecord (this isn't a gui, but can be used for burning CD's for Jaguar encryption) Microsoft RDC app All the benefits you get from a GUI (graphic file system browser, network browser, calculator, etc,etc) Both CD's should detect most PC hardware. So your wired network port, sound card, video card, wireless network card, etc should all be detected unless you have some real weird piece of hardware. The text based CD doesn't look for sound card, graphic video modes, since it doesn't use them. Even if you have no desire to develop for the Jaguar these CD's offer some benefits. If your PC ever has trouble (virus's, hard drive crash, windows won't boot, etc) you can boot this CD and be able to use your skunk, alpine, etc. If you want to play with beta rom's out there, or recompile something someone posted source to, you can just fire this CD up and go at it. Besides booting this CD on your PC, you could also boot it with a virtualization program like VMware Player. So if you have a Windows XP/2K box and you don't want to reboot to use one of these CD's, you can boot the CD under XP/2K with VMWare Player and use it develop for the jaguar. Vmware will even virtualize your parallel port and allow you to run wdb, rdbjag, or bjl under the virtual machine. Booting the livecd will be the best method in my opinion, but you have options. So how do you get them? Go to my website at http://www.hillsoftware.com and go to the download section and look in the Jaguar category. Also I did two videos showing both CD's in action.. The links are at my website , but I will link to them below also. I have had a couple people inquire about paying me to make these CD's and while I appreciate the offer, it is not needed. If you wish and you find these live cd's useful you can click on the donate button on my website and give whatever you want that will be used towards my web hosting fees. But that is not required. Video demoing text based live linux cd Video demoing GUI based live linux cd You can view the videos full screen to get a better view of them. I like vimeo because you can also download the video with a link on the bottom right of the page. If you like to download videos for offline viewing I recommend getting it within a week of this post. Vimeo keeps my original version on their server for 1 week. After that the download option downloads the slightly lower quality version you see in your browser. The videos are nothing fancy, and I didn't prepare a script or anything. They are pretty much off the cuff, and my microphone kept getting lose and sliding down (but you get to hear me breathing some that way!). If you play with these CD's or just liked the videos, let me know. Enjoy!

I have an update almost ready for the Windows version, and an initial release for Linux. If you want to test the linux version just drop me a PM. If there are any OS X users still interested let me know. (I know some did earlier, but let me know again! also let me know if your wanting a PPC or x86 build of the tools or both)

Thats cool. Nice little feature. I do know some of the documentation on the web for building SIO2PC cables specify RI, some DSR. I remember using that old Atari810 sio2pc software on Windows and having to change the configuration from DSR to RI for one of my old SIO2PC circuits.

If I remember right some interfaces use DSR for the command signal, and some CTS. So you might want to add a configuration option to select which signal is being used for their interface(RI/DSR/RTS). I will bet fletch's hardware is using DSR. Also fletch if your hardware allows it you can try switching to RI mode to see if that fixes it.

In his first post mellis links to the thread where I showed the cheap little ft232r board I used on my OS X and Linux machines. It worked great with the original command line version code I sent mellis. And it has worked great with his in development versions where he has taken that quick hacked source of mine, and taken it to new levels with more features, and a nice GUI. So it should work fine with your OS X machine (which was the main target for this). I haven't had a chance to check out the latest beta, but will do so soon on an old iMac G4 and a MacBook also. mellis has done a great job taking this way beyond what my quick little command line version could do. Can't wait to see it get released to the masses! That little board I found from Sparkfun is great. Easy to use to make your own sio interface. You just need the board, a mini usb cable, and an sio interface cable. Just solder the sio to the board (it has solder points for this) and add a jumper to put the board into 5V mode, and your done. Very simple board to make. Hope to hear of lots of success from people using the board and the software!

If you get a JagCD unit off ebay or wherever you can download my BJL CD image and burn it. You can boot it and then download code to the RAM on the Jaguar. You still need the BJL cable which isn't too hard to make, but you don't need to go in and modify your Jaguar. www.hillsoftware.com is my site (as Tursi mentioned above) I didn't see your mention of being a Mac user. BJL requires a parallel port. So if your using a Mac and running Windows under Parallels or Virtualbox the printer port could prove to be a problem .

Just so people know where this is coming from, it was pointed out in the P1 discussion thread. Here is the screenshot from the title screen of the game.

So the forum rules state. But Promethea (ggn), and Mr. Morden (cyranoj) decided to break this rule. My question is why? Clearly the mod's need to delete all these accounts since it is against forum rules. But I have to ask. Why the deception?

Actually I was referring to the deception from you guys from the beginning. Don't try to change the point. Your two accounts (Mr. Morden and CyranoJ) posted messages in the same threads acting like you were two different people. This was in the beginning. Before any other stuff went down. I just don't understand why the need to come into the scene with the fake accounts when you already had accounts established. The only logical thing is you wanted to stir up trouble and wanted to distance yourself from your original accounts. So no matter what you want to say about Gorf he was right that you guys were members of dbug. You tried to disguise that fact. I try to stay out of the battles and drama that go on around as much as I can, but it is very disappointing the deception you guys entered the scene with. So my question is again. Why the need for deception?

So why the need for the fake accounts? You posted with your original accounts in threads supporting your other fake aliases and acting like they were different people? Why the need to lie to the community like that? It really makes all the trouble you guys started with Gorf and others look very planned.

Congrats on the release Seb. Looks good!

SubQ has addressed this pretty much already better than I can. But yes if an author had specifically asked for protection I am sure Tursi/kskunk would have taken care of them, and it is easy enough for any new title to be written by the developer to detect the skunk and not run on it. It has been awhile since this was discussed on the JagCF but I believe something similar was going to be done. But as I tried to state earlier and the whole point of my original post in here was that the skunk shouldn't be the one Reboot developers problem with testing his ROM code. The skunk is definitely "developer" friendly just as the Alpine and even an Atari Flash cart. Much more developer friendly than a BJL setup for instance. It is a great tool for developing RAM/CD/ROM based titles.

And just to further repeat some of my previous statements. The Skunk was not limited or made crippled because of any commercial title. It wont run a few commercial titles because of a request from those author(s), but that check against those titles is done by the bios and does not limit developers in anyway. The $800000 - $81ffff range of memory is not available to skunk developers, but it is also not avaible to Atari made Flashcarts, it is not made available to the Alpine users unless you boot into a special mode that loads the stub into low memory. As a developer the skunk gives you all you need to make your ROM based title and flash it to the Skunk and run it. When you are happy with that code and want to release it onto a real jag cart you can run the encryption tool and have a ROM image with encryption header in the $800000 - $81ffff range. The only issues a developer would have with running ROM stuff on the Skunk is if they need 32bit access to the ROM space, or they specify 32bit access mode in their code while running on the skunk. Also just some more detail on what SubQ has stated. I think the jcp tool will strip the header off the ROM image before flashing (it might do this for full 4MB images only). But as he states it is best to strip any encryption header when working with the skunk, it isn't needed.

Lots of mis-information and assumptions in this topic (not singling you our Morden. just addressing some of the things in your below posts. There are a couple things different about the skunk and a normal Jag cart. Things done not to cripple it, but to simplify the design and costs (although kskunk and Tursi could chime in with better info). 1) It is 16bit and not 32bit. I believe they chose a 16bit part because it was commonly available and cost was decent. A common issue here is a program that writes to MEMCON1 and assumes 32bit mode. If you write to MEMCON1 and specify 32bit mode your ROM isn't going to work on the skunk. I have seen this problem numerous times. Just set it to 16-bit mode. 2) The fact that 800000 - 801fff isn't available is not to deter running ROM images, but because the Skunk needs to boot its own bios code on boot up (so it needs a valid encryption header to do this, and it doesn't allow you to flash over this area). This is no different than the Atari Flashcart or even an Alpine (although the Alpine can be forced to load into low memory, but remember the Alpine has a special rom in the Jaguar itself. The skunk doesn't have that luxury). Now if a developer wanted an existing title(s) of theirs not to run on the Skunk the skunk's bios can detect that and not run that title. But that has nothing to do with the above items, and does not effect any one elses ability to develop on the Jag. Tursi and ksunk would have to add the ability for the bios to detect those ROM images and not run them. All you have to do as a developer is develop your ROM code and target for 802000. Remember even a commercial title does this. 800000 - 801fff is for the encryption header and not the games code. Then just take that ROM image targeted for 802000 and flash it to your skunk. No need to encrypt first. Finally if you have a "finalized" ROM image and you want to take it to an actual cart then just run the cart encryption on it and you have ROM image you can burn to PROMs for an actual cart. The only caveat being if your messing with MEMCON1 you need to set accordingly depending on if your targeting the skunks 16bit mode or a 32bit actual cart. Hopefully that clears a few things up. And Morden if you still have trouble with getting your code to run ROM wise on the skunk, I would be happy to check it out for you.

From what I remember and what I have read, Atari was prepared to ink the deal at CES (might have been a different show) and some Atari execs saw Coleco running Donkey Kong on a Coleco Adam computer. They were furious since they had computer rights. Supposedly this upset Ray Kasar (Tramiel wasn't around yet) and the deal wasn't inked before he was ousted from Atari. Then new management (which at that point could have been Tramiel and company, but I think it was still Warner) couldn't ink a deal and eventually Nintendo decided to go it alone. I don't think Tramiel was around until about a year later. Just checked Wikipedia (take it for what its worth). They have that CES show I mentioned above as June of 1983. They mention in July of 1983 the famicon had a successful enough launch in Japan that they decided to go it alone in the US and forget about Atari. They list Tramiel as coming in in July of 1984.

Maybe. No way to know how the 7800 would have been accepted. Atari wasn't in the strongest position anymore after the crash. The benefit to selling the Nintendo hardware would have been access to all those Japanese titles too. Plus it has never been about who had the superior hardware in the console or the computer market. It always seemed to be about who had the best games/software. Followed by price. But whats done is done. Shame Atari ended up the way it has. I have a lot of good memories of my 2600/8-bit/ST/Lynx/Jaguar systems. If the one guy from Germany finishes his ST on a board FPGA (looks very close), I may finally have my STE console that I can connect to a PC monitor and play all those great ST titles.

Been quiet in this thread since I think by 1993 it was too late for Atari no matter what they did. But I think a critical mistake in their history was back when they were in talks with Nintendo about selling the NES in the United States. Obviously that would have been huge for them, but Atari backed out. I think that was 1983 or early 1984. If they would have gone with that deal things might have been different. I do like the one idea of Atari releasing a console based off of Falcon or even STE technology (obviously this would be years before the Jaguar release). There were a ton of great games for the ST/STE and many people had no idea because people just didn't have Atari computers (or even Amiga systems) and were suffering with the joys of their PC CGA/EGA games, and their Mac games. Then Atari could have followed that up with a proper Jaguar done right a few years later. But short of the Nintendo NES partnership getting them back to respectable status in the Video game world I don't think anything would have saved them. But to answer the Question of this thread. If it was 1993 and I was in charge of the Jag. I would have seen the writing on the walls that Atari was dead no matter what I did. So I would have started casting hot chicks for American Hero 2, 3, and 4. Had as much fun as possible before the doors closed.

Always nice to see new stuff on the Jag! As vi mentioned I have a new C compiler that works with 2000/XP/Vista. I include SubQ's smac and sln also. Assuming your project is compatible with smac you could possibly build your project without the need for dosbox. From your website it looks like your first project is purely assembly, so if smac is compatible with your project, you should be good to go. If sln poses a problem I also have vlink which is a pretty robust linker too.

I have a sample in \jaguar\jhello that shows vlink usage. basically for a simple text/data/bss at 4000 x x it is like this. vlink -brawbin1 -Ttext 0x4000 OBJECTFILES -o filename.bin

I was under the false impression that things like surrounded were done in pure assembly files and not embedded into C code asm("") statements. I fail to see what vlink or aln have to do with gpu main. That is my point. aln was not written with gpu main code in mind. My understanding is your GPU main code is massaged in assembly source form. Be it in pure assembly files or be it embedded into C code. That is then assembled or compiled into an object file or files which are then linked. So my question is what is unique about aln or how you use it in regards to gpu main code? Have you hacked or modified aln for this purpose? actually I don't believe gcc calls smac for embedded assembly inside C. If you look in the dev bin folder you will see a AGPU and M68K directory. Inside each of those is as.exe which is an assembler for each architecture. I am pretty sure those are being used to handle assembly code embedded into C for each architecture. smac is only used when you call it yourself on standalone files.

What do you mean with the sentence I quoted below? Do you mean you need the 68K C compiler to support embedding GPU code inside asm(""); calls? If so that is completely a new one to me. Don't think I have ever heard of anyone doing that before. Originally you were talking about vlink supporting GPU main code. Which I don't think either sln or vlink need to worry about as long as smac does its job (or you do your job by hand as you have done in the past). You were hand coding your gpu in main stuff with mac and assembling and linking with aln. Should be the same with vlink, sln, or aln.