Jump to content


  • Content count

  • Joined

  • Last visited

Posts posted by Tyrant

  1. You could always test yourself by making a 1-day tertisish game :)

    I would, if I didn't have another 4000-odd words to write by next week, and a juggling convention to attend this weekend.


    Just think though, while you guys will be staring at monitors and playing old games, I'll be out in a field swinging burning objects round my head. But I think one thing is for sure: alcohol and good times will be had by both groups :)

  2. I will make some test with a logic analyzer this week-end, I don't know extacly the comportement of the OP with zoomed object.

    Thanks, that would indeed be very useful, and I don't have the faintest idea how to go about using a logic analyser (or the time to learn right now).


    Oh, and if, while you're doing that, you have time to test RMW objects too (both unscaled and scaled) it would be very useful to me.

  3. Ah, I get it now.


    Thank you both.




    I suppose the reason 960 into 1702 doesn't go is because I wasn't accounting for the time taken to fetch the data (or fetch / process the two object definitions).


    But then again, the OP is supposed to be able to fetch data (at 2 ticks per fetch if there isn't a column select involved) while it's busy expanding the data it's already got. At 16bpp unscaled, it takes it two ticks to write out one phrase, so if it can fetch stuff exactly in the background, it reads as fast as it writes.


    I don't entirely get it.


    Also while this isn't exactly a stress test, the 68k shouldn't be interrupting anything since the OP hangs onto the bus while it's running, and the graphics are in main ram, so the OP can have all the time it needs.

  4. I used the horizontal period register value as a basis, but forgot that it was the duration of a half-line, not of a complete line.

    Hmm... interesting.


    My calculations were Video Clock (techref p.5) divided by framerate divided by number of scanlines.


    (26.5939 * 10^6) / 50 / 625 = 851.0048


    (26.590906 * 10^6) / 60 / 525 = 844.15575...


    Also today I ran a simple test, creating a short object list of one 640 wide 16bpp bitmap, and one 80 wide 16bpp bitmap scaled to 640, and found I was getting occasional flicker on the display (the scaled object was getting a line chopped out of the (vertical) middle, at a non-constant position) which I took to mean the OP was running out of time but only just.


    When we do the maths, we find it should take: (640 * 0.5) + (640 * 1) = 960 ticks to draw that, assuming ideal conditions. If we only had 851 ticks (I only tested under pal) that would seem to make sense to me in a way that 1702 does not.

  5. 851 for PAL mode, 845 for NTSC mode :)


    They are system clock cycles ; if you want to compute timings on the 68k, divide that number by two since its clock frequency is only half of the rest of the system. If you use RAM and/or other processors, you have to take into account bus priorities issues and RAM latency & refresh time as well to know how much code you can run during the duration of a video line.

    That's what I got, but I assumed it couldn't be that simple. :unsure:

  6. Hiya, a late-night thought has got me thinking about how much time there really is in a Jaguar, and specifically how many clock cycles there are per scanline of video (for the main chips, I know the 68k is at one-half the clock rate).


    I did some incredibly crude calculations (that didn't account for blanking time) and came out with a value of approximately 850, but I'm sure I'm wrong, so can anyone give me a better answer for how many clock cycles there are per scanline?

  7. Or maybe you know a way to start from the CD even when there's a cartridge in the JagCD slot, in which case I'd be very interested to know how ! ;)

    Just a thought but what would happen if you insert the cartridge after the CD has already started running?

  8. In the end I still couldn't work out what it was. Everything was aligned to even addresses except a couple of byte-sized fields, my object list spacing was fine, everything was fine. So I reverted to the last checkpoint and I'll add the extra stuff back in when I have time. Right now I've got more pressing matters to deal with but I thought I should update this thread anyway to say thanks for helping.


    Alpines and wdb are lovely tools when they work, but when they crash and the debugging link locks up, they're rather frustrating.

  9. I've just spent an entire day trying in vain to chase down a bug in my code relating to alignment. I still haven't got it so I'm hoping someone more knowledgeable than I can help. I've managed to find several places where, if I insert one or more nop's, the entire system (68k/op, no risc) locks up and my alpine won't even respond to the halt button (but reset works). I'm pretty sure all the sections that require proper alignment are aligned right (op list entries, bitmap data).


    I think I saw somewhere someone complaining that ALN moves things round in an arbitrary way and doesn't necessarily put things in the order they're given to it on the command line, but that wouldn't go so far as to re-arrange allocations within a file, would it? I'm really stumped at this point as to wtf is going on, as I've been through everything, I think.


    I have had before the problem of trying to read a word from an odd-aligned address, in which case the 68k throws an address error and that's fine, but this is a case of it locking up rather than giving any kind of error, so I don't think it's that. I'm thinking it's probably an OP problem, but like I said, every object I'm making is aligned properly with .qphrase directives.


    I guess I'm really looking for general advice on what to do in a situation like this. I've tried the usual one of slapping writes to the background colour register all over the place, but that just broke my test case by pushing the alignment back into something that works. I'm also having a hell of a time trying to single step through my code since so much of it is opl-generating, and writing out half an object causes the op to dance a fandango on core when the link address isn't set right.


    Any thoughts would be welcomed at this point.

  10. When I said "drawing" I didn't necessarily mean displaying. I think what's happening is that the vertical count doesn't reset quite as quickly as it should, and so you re-create the object at the start of the vertical blanking period, and the op "draws" 6 lines of it (while the beam is shut off so nothing reaches the screen) before VC resets to being less than the height of the object. Part of that drawing process is of course to reduce the height by a line and increase the data pointer by a line, meaning that when it starts up again it continues from where it left off before.


    Edit: another quick fix solution might be to just add 12 (6 * 2) to the line on which you fire the VBL interrupt.

  11. It is probably that you're missing the branch objects and it thus starts drawing 6 lines before it should (I'm guessing the OP doesn't reset VC until it gets to VDB, therefore it starts drawing those 6 lines with the old VC which was at the bottom of the screen).


    However, you should also check to make sure that your bitmap data is phrase aligned.

  12. Another possibility is to keep the bitmap data as it is, but double the value of the DWIDTH field. This will cause the OP to skip every other line when drawing. In your VBL interrupt routine, update the DATA field with either your bitmap's address (to show lines #0, #2, etc.) or your bitmap's address + one line (to show lines #1, #3, etc.), according to the field which will be drawn next.


    In both cases, remember that you're only drawing half the number of lines per field, so the HEIGHT field value should be divided by two, compared to a non-interlaced screen.

    Arrgh! Sometimes I really hate this cat!


    Further to the above advice, I would add (for anyone else foolish enough to do a high res game), that if you want smooth movement in the y direction, you will additionally have to consider the case when you want to draw an object on an odd line boundary. Softref says (p16, object definitions) that YPOS gives "the value in the vertical counter (in half lines) for the first (top) line of the object. ... If the display is interlaced the number is even for even lines and odd for odd lines." This, as with most of the OP's interlace support, is broken, and the value must always be even*.


    In order to get objects to draw on odd lines, you must do a similar trick as zerosquare described: For odd-aligned objects, on even fields of the display, add IWIDTH to DATA, and add 1 to YPOS. This is getting so confusing that I made myself a reference image to keep it all straight. I hope it proves useful to someone.


    *if it's not even, it will display on the next line drawn, i.e. it will round up until it is even.


    EDIT: My original post gave an incorrect workaround, suggesting to just add iwidth on even rows, and subtract 1 on odd rows. It has now been corrected, and a new image uploaded.


  13. Your problem seems to be like a misalignement somewhere or an error on the compute of the OP list.

    With a clear head and a bit of "change the background colour to see how long it takes" timing of things shows me (I think) that the error is simply that it's not making it all the way through list creation by the time the OP starts to chew through the list. Hopefully double-buffering the list should make that problem go away, and I can get on with seeing quite how much I can put on screen at once.


    Thanks for your help.

  14. Hiya, has anyone got any statistics for what kind of performance the OP can be expected to give, in terms of how many objects per frame?


    Right now I've got it displaying one big background (640x480 interlaced) image, with 64 sprites (16x16 4-bit transparent bitmaps) over the top, and it's behaving strangely.


    In some arrangements of the images, it displays them just fine... but if I change their locations / arrangement, all I get is a black screen.


    From my experiments, it seems it will display all 64 on one line with no problem, 32x2 also no problem, 16x4 sometimes but not always, and never an 8x8 grid of them. My list isn't broken into sections by height (yet, I'm considering it but I'm not sure the best way to do it), so the sprite objects are just laid out left to right, top to bottom. I thought at first it was an issue with the number of objects per line, but since I can fit all 64 on one line, but cannot fit 8 on each of 8 lines, that doesn't make sense. I'm completely at a loss to explain it.


    Also, when I re-arrange them into a grid of 4x16 (top to bottom, left to right) it displays fine, but if I try 4x16 (left to right, top to bottom) or 16x4 (top to bottom, left to right) it gives me a black screen.


    Does anyone have any idea what's going on here, or in a more general sense, what kind of performance I can expect to get from the OP?

  15. How's this project coming along? I'd love to get my hands on a couple of these carts right now, and then a big batch of them sometime down the line.


    When will you be able to give us a better estimation of the cost of them? Also I believe something was mentioned about cart shells, would be nice to get more details on that too.



  16. Picture seems good. I just don't see the left part of the picture (but it's the same wit all my jaguar games so ... and this TV doesn't allow horizontal tuning ...).

    That's what I get with my TV, on this and most (all?) other jaguar games. That's really why I asked people to test this for me, because I don't trust my TV.


    If I can ask one more thing, could you see the whole image (apart from a bit off the left), The white diagonal lines go to the edge of the image, could you see all of them on all sides? Also was the TV PAL or NTSC natively?