Shamus

So let me get this straight--you're complaining about how there are no "good" Jaguar emulators when you don't really use or give a rip about them? Whatever. In a perfect world we'd all have Jaguar PCI cards that we could plug into our late model PCs and there'd be no need for emulation. But, since we don't... I'm really glad that you still have yours. Really. I hope it lasts you a long time. But not everyone is as fortunate as you.

Have you tried VJ? If not, then how can you know whether or not it runs the vast majority of software (I think it can handle around 90% of cartridge based software--CDROM is a different story)? It seems to me that what you're calling "good" sounds to my ear like "nearly perfect." Virtual Jaguar certainly isn't anywhere near the "nearly perfect" category but I think it's definitely in the "good" category and on its way towards "great" (in my not-so-humble opinion ). I'm going to start posting binaries of CVS builds on icculus (for Win32 at least--if you can't compile it on linux, there's something seriously wrong with your set up!) on a semi-regular basis, so why don't you give it a try? You could be a real help if you could try it out on your favorite games and let us know how it works for you. If you're willing to do this, keep in mind that we're going for compatibility first, and speed second. But constructive criticism is always welcome.

Hmm... Icculus seems to be down at the moment... But yes, it works on OSX (and Linux, BeOS, and Win32). I personally would only be able to supply Win32 and Linux binaries if I decide to do nightly (or whatever) CVS builds. I'll have to get hold of our Mac developer to see if he would be willing to do so... Anyway, Native works fairly well with the latest CVS, but not so well with the last official release (1.0.6). (It probably has to do with timing in the DSP. *sigh*)

No good emulators yet? Hmpf! I beg to differ! Virtual Jaguar is coming along quite well, and is at version 1.0.6! Compatibility has gotten a lot better with the upcoming 1.0.7 version (which is really just the current CVS )... I'm thinking about releasing nightly (or otherwise semi-regular) builds of CVS so that those who don't want to build it from scratch can still cruise on the bleeding edge. Check out the screenshots on the webpage if you're curious to see where CVS is at.

Amazing! I'm sure I can make good use of it... Is it possible that the Jaguar BIOS source is somewhere waiting to be discovered as well? Great job and thanks for finding and providing this! (I have to wait until I get home to look at it tho... ) -- Shamus

This may be a silly question, but then again, maybe not. I'm curious to know if any of you Jaguar developers out there know what the 68K in the Jaguar does when it hits an "official" illegal instruction (i.e., $4AFC). Does it fetch the next instruction or does it hang on it or does it halt the processor? -- Shamus

I wish I did have influence over that, but, unfortunately, I don't. The next best thing I can do is enforce certain extensions through the emulator which, along with the documentation, will hopefully raise awareness enough so that they'll take notice (assuming of course VJ is popular enough). I wouldn't hold my breath, though. As far as those extensions go, I think I like .J64 best (actually, I like .ROM best, but there are so many different systems out there ). Here again I think a little awareness can go a long way, but waiting for Cowering to change his DB, well, that's another story... The problem, in my opinion, is a profound lack of knowledge on the part of the general public but that can be remedied. -- Shamus

Thanks for clearing things up JustClaws! I suppose it would be safe to say that a headerless .abs file isn't really an .abs file at all (and as such, no assumptions about load/run addresses can be made). If you don't mind, I'd like to use the information in your post in the VJ documentation. Maybe I can help reduce some of the confusion by making VJ conform to the standards you outlined above... I think the reason that there is so much confusion about file formats is that there is no place to get that information. I'm pretty sure that the Jaguar FAQ doesn't mention anything about file formats. -- Shamus

I'm not so sure this is true--I've run into at least three different types of .abs files. Two of them have parsable headers (nice ) and one of them doesn't (which I assume always loads/runs at $802000--if true, also nice ). -- Shamus

My completely uneducated guess is that Phase Zero was designed as an NTSC cart, hence the large black bar at the bottom of your screen. But, of course, I could be completely mistaken since I haven't really looked all that closely at it... If this is indeed the case, then it wouldn't be the first. I think that SD's Asteroids demo was coded strictly for a PAL Jaguar. Care to weigh in Sinigord?

OK y'all, here's the PC version of jagcrypt for your edification and enjoyment. This version should be considerably easier to use than previous versions, as the public and private keys are built in. It also has the capability of creating a single ROM cart image as well (via the -u switch). Maybe this will inspire someone to C-ify the CDROM version? pc_jagcrypt.zip

Curt is most definitely the man. For those of you who still doubt, I've put up a copy of the "encrypted" Phase Zero ROM image up on Virtual Jaguar's webspace. Check it and see for yourself.

Well, it looks like jagenc2.zip is the real deal. I used it to "encrypt" the ROM image of Phase Zero and it passed the BIOS check with flying colors. Here are the steps I followed: First, I stripped off the 8K of $FFs in front of the ROM image so that I was left with the raw binary image that loads/runs at $802000. Then, I put the PRIVATE.KEY on a floppy and ran the JAGENX.PRG (it's an ST program, and runs faster than the JAGEN.PRG version). It'll ask you if you want to use a precomputed key (which, if you haven't run JAGENX yet, won't exist) to which you'll say no. It will then ask for a floppy with PRIVATE.KEY on it. Once it reads the key, it will ask you which format to write out. Select option "1", 4 ROMs. Then it will ask you where the ROM image file is (you did put it on the ST hard disk, didn't you? ). Once you tell it where the ROM image file is, it goes to work crunching the data. Once this is over, you should have some files called FOO.U1, FOO.U2, FOO.U3 and FOO.U4 (where FOO is the name of the ROM image file). These files contain the "encrypted" ROM image with .U4 holding the Most significant bytes, .U3 holding the Next Most significant bytes, .U2 holding the Next Least significant bytes, and .U1 holding the Least significant bytes. Combining .U1-4 into a regular ROM dump is left to the reader as an exercise. One other thing: You'll want to run JAGENX.PRG in either medium or high resolution, otherwise you won't be able to see the whole text screen.

As they are now, with the current version of VJ? No. But .abs format seems simple enough to grok that it may find its way into 1.0.7. Hmm... Of course, in the meantime, you can use filefix and create your own .jag files.

And I am well versed in the ways of the Google cache. I defy you to find one that links to Stormworks (they probably were never indexed directly in the first place and even if they were, you'd just get the page and nothing that it links to). Let me make something clear to you. Just because I have a copy of the Music Demo does not make me a "Warez D00d." I honestly couldn't tell you where it came from. I found a copy and thought it would be nice to see what it does. Sheesh! And as for a demo being a "commercial product" it seems to defeat the purpose (i.e., as an advertisement for something). Why are you so indignant about it? How does this affect you personally? It seems that I've obviously touched on a nerve. -- Shamus

This is, of course, usually the case (and that's how I found most of the run addresses for those programs that came in .bin only format), but just try to find a website or a link to those homebrew programs that I listed. For example: Arkanna Demo Stormworks Interactive, Jeff Nihlean You can find some links on Google for SI, but all the links point to a 404 page. So it's not a matter of getting these program from "warez" pages but a matter of the original pages being gone! At any rate, though, thanks for the info! I appreciate it! -- Shamus

OK, I know someone has to know the run addresses to these homebrew programs: Arkanna Demo Assassin Demo, The Part 1 (1999) Assassin Demo 1.0 Release 2 JagFest Demo (2001) Music Demo (2002) (ScatoLOGIC) Google turns up nothing useful on these goodies. And to the person who said that .jag format is useless, I say like heck it is! Without it, unless you're clairvoyant, you have no way of knowing where to load/run the raw binary! Demo/homebrew authors, do us all a favor and release in .jag format (in addition to .bin if you must)! -- Shamus

Problem solved. It seems that by reading from $F02204 it was actually reading from $F0220C. My guess is that the blitter ignores the lower three bits on that address block ($F02200-F0220C) and simply returns the value at $F0220C. random hypothesis> I'm sure I'll have more questions in the near future... Thanks! -- Shamus

Err, the difference between $F02208 and $F02204 is 4 bytes which is 32 bits... How would it pick up A1_CLIP as well? The code is correct. What's in question here is not the GPU but the blitter. Apparently the JTRM wasn't telling the whole story about some of the locations in the blitter, since that GPU code was using the supposedly WO location $F02204 as a base address for another blit. I'm pretty sure whoever wrote that snippet of GPU code either stumbled on to something or was privy to some insider knowledge (my guess would be the former--I've seen a fair share of code that only works "by accident" because the developers misunderstood something)... You wouldn't have to debug any GPU code, you'd just have to write a little 68K code that set up the blitter (a few different cases) and then examine $F02204 afterward to see what the blitter is offering at that address (I could write a small routine for you if you'd like ). My suspicion is that the blitter pushes (or mirrors) something that keeps track of an internal address, and so we have the read from a supposedly "write only" register. -- Shamus

Moderators: If this is the wrong forum, I apologize in advance. Hi all, I've been helping develop the portable Virtual Jaguar emulator (the one that grew out of David Raingeard's source code posting) and I've run up against something that is completely undocumented. Since I'm sure there's at least some of you out there that have access to a development Jaguar system, I was wondering if someone could help with the demystification. What the deal is is this. There is a certain program that reads from the blitter's A1_FLAGS ($F02204) register (even though it's supposedly read only) after it does a blit and then uses it as A1_PIXEL ($F0220C) for a following blit. Here's the relevant GPU code: F03824: MOVEFA R14, R02 [NCZ:010, R14(alt)=00F02200, R02=FFC070C7] -> [NCZ:010, R14(alt)=00F02200, R02=00F02200] F03826: ADDQ #4, R02 [NCZ:010, R02=00F02200] -> [NCZ:000, R02=00F02204] F03828: LOAD (R02), R01 [NCZ:000, R02=00F02204, R01=00F03840] -> [NCZ:000, R01=00073820] F0382A: ADDQ #8, R02 [NCZ:000, R02=00F02204] -> [NCZ:000, R02=00F0220C] F0382C: SUB R03, R01 [NCZ:000, R03=00000000, R01=00073820] -> [NCZ:000, R03=00000000, R01=00073820] F0382E: STORE R01, (R02) [NCZ:000, R01=00073820, R02=00F0220C] F03830: MOVEFA R11, R01 [NCZ:000, R11(alt)=00F0223C, R01=00073820] -> [NCZ:000, R11(alt)=00F0223C, R01=00F0223C] F03832: BSET #16, R00 [NCZ:000, R00=00000028] -> [NCZ:000, R00=00010028] F03834: STORE R00, (R01) [NCZ:000, R00=00010028, R01=00F0223C] F03836: MOVEFA R10, R00 [NCZ:000, R10(alt)=00F02238, R00=00010028] -> [NCZ:000, R10(alt)=00F02238, R00=00F02238] F03838: MOVEI #$41802801, R01 [NCZ:000, R01=00F0223C] -> [NCZ:000, R01=41802801] F0383E: STORE R01, (R00) [NCZ:000, R01=41802801, R00=00F02238] ; BLIT #2 The value you see it getting from A1_FLAGS is pretty much what was stuffed in there previously, but it's definitely not (and I'm 99.999% sure about this) what you're supposed to get. I can't figure out why this particular program should be doing this, but there you go. What would really help (please, please! ) is if someone with a development system could probe that location for me--do some blits and read the value in A1_FLAGS after the blitter is done. This would really help not only in documenting the Jaguar hardware better, but it would be a shot in the arm for the Virtual Jaguar emulator as well (you will, of course, get credit for your discovery)! -- Shamus Yeah, I used to have a real live Jaguar, but gave it away long before I started working on VJ. D'oh!