Jump to content

Tursi

Members
  • Posts

    76
  • Joined

  • Last visited

Posts posted by Tursi

  1. Thanks Zero, that actually makes a lot of sense. Published carts have no real need of a serial number. The flash cart feature could have it painlessly, though I see your reasoning for not doing it.

     

    Fadest, successfully here in Paris, though it'll be a couple days till I am settled. Not sure how complex meeting would be and I wouldn't want you to drive an hour each way just for a lunch meet. ;) But up to you.

  2. Yup, but there's no real protection forbidding anyone from reflashing it with anything. So I think it would be pretty pointless.

     

    It's statements like that which make people think you guys are condescending -- I offered something I'd already done as a suggestion, and your response is that it is a pointless thing to do - implying that I wasted my time. I'm sure you didn't mean it that way.

     

    While there's nothing stopping people from reflashing the Skunkboards either, people appreciate the fact that the boards are serialized -- both the content creators and the users like it. It's a silly little thing, yes, but if people like it, what the hell, eh? So far as I know, nobody's bothered to write a new BIOS for the Skunkboard either. ;)

     

    I live near Orléans (a little more than 100 km from Paris).

    Maybe we could try to schedule something during the week-end ?

    When will you be in France ?

     

    Leaving in 6 hours, be there in 24 or so. I'll be there through the 23rd, I think it is, staying near the Moulin Rouge. Will try to check back if I have internet access out there. ;)

     

  3. Tursi : the Flash chip we're using doesn't include a serial number or any other unique identifier (we couldn't use the Atmel chip you used in the Skunkboard, because it is no longer manufactured).

     

    Ah, interesting. We knew it was out of production, but it's not too hard to get still. We were shopping around for parts two weeks ago. :)

     

    You could just burn it into the BIOS like we did if your users demand it.

     

    Any of you guys near Paris? I'll be out there next week. ;)

     

  4. I don't have a JagCD, but if you want to send me what you have, I will look and see if I can see anything obvious.

     

    But the nature of the CD chipset is that either the JagCD /or/ the cartridge is mapped into the Jag's memory. If you can see the CD BIOS, then you can't see the Skunkboard. :)

     

    I know the write that changes from CD to cartridge, but I have to admit I don't know how to switch back. I will study the JagCD BIOS, I think I saw it in there for certain things.

     

     

     

  5. Thanks GT. I have my own forums for my private work. ;)

     

    I don't know why you think people wouldn't be interested in talking about your ST stuff, or any of the other projects. Why does it have to be Jaguar centered. If it does, then that just reinforces my points.

     

    Two years ago, Jagware made a huge deal about /this/ forum and invited all developers to come share in the discussions. I came, honestly I was looking forward to a technical forum. But there isn't any discussion to share in. Your reasons for that are reasonable and strangely oft-repeated but look at it from the other side - you're inviting people with a promise that is not being fulfilled.

     

    Fadest, I was a licensed Lynx developer in '95, I eventually sold my manual off to people on the net, and these days I wish I'd kept it. I never got a project off the ground due to financing, but it was a lovely little machine and I spent a lot of time in the reference manual. :) None of your information, ideas, routines, etc, is visible here, though.

     

    "Most people don't come here or do not even think to subscribe because this is mostly a developper forum" - that might be what a developer is looking for, you think?

     

    That's fine, though. I appreciate your hearing me out and giving your feedback wrt explaining the status. Ultimately, it's a matter of trust. I will have to keep looking.

     

  6. Not to be mean, as I've tried very hard not to feel slighted here, but there /is/ no important stuff being posted publically. In any given month, the only posts made publically are birthday announcements. Once every 2-3 months we may see an actual post about something jag related.

     

    Even when you guys are doing releases, like Jagcode, you don't talk about it publically here. I raised that point at the time since I was really surprised that nobody said /anything/.

     

    So either there really is /nothing/ going on, or you are not really aware of what forums are available publically. In the first case, I'm not really sure there's any value to having invited developers here.

     

     

  7. I think that I have found why it doesn't work :

    you set the GPU's DMA priority mode when it starts, but this means that the GPU run always at DMA priority, so all external acces of the GPU core break the bus :

     

    This is a good theory - in that I didn't think of it at all. But have you run the program and looked at the results? They do not look like any kind of OP interruption at all, it is very clearly only the memory buffer that is being impacted. It's extremely consistent. The OP is, in my experience, a sensitive little bugger, and doesn't like to be trifled with, doing all kinds of screwy things that usually result in an empty screen. ;)

     

    I will give your suggestion a try and see if it makes a difference. ;)

     

    (edit) And now I have done so. This is very interesting... you are right that it clears up the buffer corruption.

     

    I can't say that I understand why, though. The interference is extremely odd. It boils down to:

     

    -Having DMAEN set

    -While the GPU is reading VC and manipulating BG

    -While the OPL is processing the display list with a bitmap object

    -Causes STOREP to behave incorrectly on a GPU-processed CPU interrupt during vertical blank

     

    Note that the STOREs work fine. Confirmed that it doesn't matter if DMAEN is enabled while writing G_HIDATA, that register still gets the correct value. Also confirmed it's not just the OPL screwing up on transparent phrases (walk the lion and you can see that the bytes which are cleared during the animation sequence stay cleared until the keyframe is reloaded.)

     

    Very strange, but thanks for helping to narrow the cases a bit further.

     

     

  8. If this doen't work, It would be impossible to use interrupts when a code use the BANK1 and I use always the bank1 for the main part and bank0 for interrupts and save states and it works perfectly (for exemple for the demo FACTS)

     

    I can confirm that I do a lot of GPU interrupt work and have never had trouble with putting the flag restore in the delay slot. Another note to remember is that (I can't remember where it says this), the manual also notes there is a 3 cycle stall after a jump - this is while it reloads the pipeline. This gives the flags instruction lots of time to propegate through the pipeline. (Here we are, p62 where it is listing all the stalls:)

     

    after a jump or jr (three clock cycles if executing out of internal memory).
  9. Yeah, the OP is running (though the machine is in VBlank and so it should only be executing branch and stop objects). It's actually just my JagLion code except I changed the initialization of the GPU to set DMAEN, and the only place that uses STOREP is the buffer clear function. Instead of clearing it I got a regular pattern.

     

    If you want to try it, the latest version went on my site today (just a lot of little bugfixes to improve stability, and I was using it as a test base for my project). http://harmlesslion.com/software/jaglion

     

    You'll find the line for setting DMAEN commented out in CALCMAND.S on line 240.

     

    Of course, if you find a bug in my work there that'd be great to clear that pending issue. Or even if you confirm it. :)

     

  10. The documentation isn't a good reason not to experiment. :) We know it's got a lot of flaws.

     

    If the OP is not running or is processing only stop and branch objects, then the condition can't occur. I used the blitter high priority mode very successfully by running it during an OP GPU Interrupt, while the OP was halted. This particular case was an experiment and the experiment didn't work, but I think it's a good idea to document any known odd behaviour. Sometimes you can exploit odd behaviour in unexpected ways. ;)

     

  11. GPU DMAEN bit and STOREP doesn't work.

     

    When DMAEN is set on the GPU, the high data register does not appear to be written to external memory on a STOREP (or it appears to write a fixed value but not the value in the high register - disabling DMAEN resumes normal operation.)

     

    Didn't test LOADP.

     

    Also, it doesn't work to overlap your OPL and your animation buffer. ;)

     

  12. Hehe... so with JagCF you didn't really choose whether it was masculine or feminine, you just went with what the Compact Flash was already set as in the language.

     

    This is something I've always wondered since I was a kid, is how new words to the language get classified. :)

     

  13. This is a completely unrelated language question, but...

     

    Une Jaguar c'est ... bof.

    Un Jaguar CD c'est ... Classe !

    Une JagCF c'est ... ULTIME !

     

    Jaguar is feminine, Jag CD is masculine, and JagCF is feminine. I always wondered how those are decided? :)

     

×
×
  • Create New...