Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Shamus

Members
 View Profile  See their activity

  • Content Count

    698

  • Joined

  • Last visited

Posts posted by Shamus

  1. Posted

    No good emulators yet? Hmpf! :twisted: 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 :P)...

     

    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. 8)

  3. Posted

    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

  4. Posted

    If as an emulator author you have ANY special persuasive position over the Good-Jag maintainers, please try to persuade them to change .JAG to either .ROM or .AJR (Atari Jaguar ROM) or J64 (Jaguar 64) even maybe.

    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. :x

     

    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 :D).

     

    The files they list as ROMs (like Matthias' demos, Bastian's demos, the BadCoder demos etc..) which are actually for BJL, should be named to conform to this, and of course the distribution should credit the authors, and they're not PD, I don't think, they're generally copyright but free.

    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... :twisted: The problem, in my opinion, is a profound lack of knowledge on the part of the general public but that can be remedied. :D

     

    -- Shamus

  5. Posted

    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 :D (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

  6. Posted

    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

  7. Posted

    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? :D

  8. Posted

    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. 8) 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? :D

    pc_jagcrypt.zip

  10. Posted

    Well, it looks like jagenc2.zip is the real deal. :D 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. 8)

  11. Posted

    hmmm... i doubt virtual jag will run these.. :(

    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. 8)

  12. Posted

    1) Google offers a "In Cache"-link for such dead links.

    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). :P

    2) To make it more clear to you:

    Arkanna, Assassin and the JagFest-demo were released to the public, so no problem for me to share the desired info with you (if i have it).

    But the Scatologic-Music-demo was released only as part of a commercial product (yes, a demo-CD is a commercial product) and not released to the public, so i can't see why you ask for it's startaddress, it runs fine from the CD.

    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

  13. Posted

    Perhaps it would help you if you would download the files from the websites of the authors and not from warez-websites? Normally either the website states the loadaddresses or a README is included in the archives with the demos.

    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! :P

     

    At any rate, though, thanks for the info! 8) I appreciate it!

     

    -- Shamus

  14. Posted

    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! :P Demo/homebrew authors, do us all a favor and release in .jag format (in addition to .bin if you must)! :)

     

    -- Shamus

  15. Posted

    Problem solved. 8)

     

    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

  16. Posted

    Just looking at the code section you posted, it doesn't seem to make much sense. According to the manual, F02204 is a write only address, however, when you read 32bits from that address you will get both the Flags Register and F02208 (which is A1 Clipping size and also write only).

     

    Err, the difference between $F02208 and $F02204 is 4 bytes which is 32 bits... How would it pick up A1_CLIP as well? :?

     

    To then take these and write that to the A1 Pixel Pointer really doesn't make much sense. The next code then writes to the counter and then writes to the status register which is read only.

     

    Are you sure the code is disassembled correctly ? Reading from write only registers and writing to read only just seems a bit strange to me.

     

    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)...

     

    If this is what's happening, you'll need to supply a larger section of code, preferably a binary that can be loaded to the specific address and executed. Debugging GPU code is a nightmare, even with the Alpine board, but not impossible :)

     

    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

  17. Posted

    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!

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...