Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by phoboz

  1. phoboz

    Jaguar Bomberman

    The PC engine main CPU was indeed an 8-bit CPU, just like the Atari main CPU is a 16-bit CPU (the same main CPU as in the Genesis) However, the PC Engine hade a 16-bit graphics system more similar to the 16-bit arcade mahines (482 different colors on the screen at the same time). Just like the Jaguar has the 64-bit object processor (65536 different colors in the screen at the same time) My point is, how do you really define the number of bits a system has? Do you take the highest number of bits of any part of the system, or does it have to be the bits of the main CPU? To this day there has only been one pure 64-bit system, and that is the DEC Alpha (as mentioned above). Today PCs are not even pure 64-bit, because in the x86_64 most of parts are 32-bit or less, at least half of it is 16-bit, some 8-bit parts, and some part is 4-bit (it's really only the address space that is 64-bit). It's not even a RISC CPU, like the Jaguar co-processors, and the DEC Alpha. So how do they achevie speed on the PC, they just crank up the clock frequency crazy (e.g. giga hertz) I have tried Linux on a DEC Alpha (the only pure 64-bit) running at a couple of hundreds of megahertz (compared to the gigahertz of a PC), an it runs like a blast. Imagine how fast that could be if they would crank up the clock speed of the DEC Alpha to several gigahertz? But having such high frequency is really an energy bandit, so imagine how much resources we waste just becuase the didn't make the PCs pure 64-bit, and RISC (e.g. smarter), running at a few hundreds of megahertz instead...
  2. The controls are very similar to Contra. We have started to work on a boss that uses similar animation techniques as in the later games of that series.
  3. phoboz


    Interesting, but I think the theoretical section trying to compare the performance between a RISC processor and a CISC processor (the 68000) using the benchmark MIPS (million of instructions per second) is a little bit like comparing apples and pears. Because a RISC processor is targeting to execute one instruction per clock cycle (if the pipeline is kept full at all times), while on a CISC processor an instruction can take a variable ammount of clock cycles to execute. We also know that due to bugs, the pipeline of the RISC processor needs to be cleared, or filled with junk instructions, which makes the MIPS comparison even more complex. So perhaps something can be gained when running a very tight loop on the RISC CPU, and the Jaguar really doesn't do anything meaningfull, but as soon as you start to use the object processor, and the blitter (otherwise you won't see anything on the screen). The bus will be occupied by these resources as well, so the question is really how much you would gain by disabling the 68000 when many other system resources still needs to use the bus?
  4. phoboz


    I didn't know that. I thought it was only ports of ST and Amiga stuff that used it. Yes, and probably also a good option for Genesis/Megadrive ports However, no program on the Jaguar can do without the 68000. It is the main CPU of the Jaguar, the other ones are co-processors which can only be given tasks by the 68000. So the co-processors cannot do anything by themselves, unless they are told what to do by their manager (If I got it right, please correct me if I am wrong?) Usually you don't need super high performance for game logic, so in many cases the game logic is executed on the 68000. The nice thing is that it can do some game logic in parallel with the GPU, as it focuses on handling the graphical stuff at the same time. So the combination of this gives better performance than to put it all on one RISC CPU.
  5. I could not find a link to it online, someone sent me the ROM as a PM because I asked for it here. It is not known it it is possible to share the ROM publically...
  6. I learned that the ROM for a game (prototype) like this seems to be available. Please check this video out:
  7. Because if you socket the EPROM you won't be able to close the cartridge shell. The EPROM with sockets are usually to high, at least that is my experience with cartridges for several consoles. (but I haven't tried it for the Jaguar, as the DIP-42 socket is quite hard to find these days, DIP-48 is much more common, but it's to big) Yes, of course you had the Alpine (SRAM) development board for testing, and today there is the Skunk board (Flash ROM). However, if you want to make a prototype to bring to another place for demonstration (for example to a fair), it is more handy to bring it as a loose cartridge than to bring the complete development rig.
  8. For a developer to use EPROMs for a prototype is a very cost efficient solution. (I have done it for all my games before release) To make a mask ROM (that the original Atari cartridges have) is accosiated with a very high one time cost. But once you make 1000s of them, you benefit. So I would see it as a very likely scenario that the developers made a prototype cartridge using EPROMs, rather than spending a lot of money on making just a few mask ROMs. I doubt that a fab. would even take on such a task?
  9. This seems to be an unique prototype that you have got your hands on, congratulations. I don't know about non destructive cartridge dumping devices. I have managed to de-solder intact Jaguar ROMs using a professional desoldering station (which uses a vacuum pump to suck up excess solder). However, there is no guarantee with such operation... Anyway, I am glad that you able to enjoy something unique... Please let us know if you find a way to dump the ROM in the future?
  10. No what I mean is that the only one I find on atarimania is Tiny Toon Adventures - Plucky Duck in Hollywood Hijinks [Prototype] This one does not even look like the one on the pictures here. This is a completely different game, where you can only walk forward, and backward, nothing more. - Does anyone know where to find the ROM for the Tiny toons prototype in the pictures above? (not the one in the picture below)
  11. The one I find on atarimaia is the other Tiny Toons prototype, where you only can walk forward, trough everything. This one looks like you can jump, and do a lot more stuff.
  12. Looks like a fun game. Does anyone know where to find the ROM for this prototype, I want to try it out? It must be available somewhere, if some person was able to burn it on EPROM.
  13. Maybe we do a BOSS that utilises some cool effects? Can we expect to see some sprite scaling, and rotational effects in Odynexus for the Atari Jaguar?
  14. Exactly, no need to care about palettes, and a very large BOSS can also take advantage of using many colors. If you use pre-rendered sprites, it a great advantage to be able to use more colors as well. For tile maps, I don't think that there is anyone who can that take much advantage of more than 256 colors. For that, it's probably better to use a large image instead.
  15. On the Jaguar, this is all what you program it to be. The object processor is capable of drawing a large number of arbitrary sized sprites, with selectable color depth (e.g. pseudo color, 1,2,4, or 8 bpp, indexed palette mode out of a 256 color palette, with arbitrary start index), or high color (65536 direct colors), and I think the Jaguar even supports 24bpp (16,777,216 colors) So we programmed the GPU to draw a tile map using a large number of sprites (e.g. 20*12 = 240 individual 16x16 pixels sprites), in this case 8bpp out of a 256 color palette. The high color sprites, are on top of that, plus the parallax background. However, unlike the NeoGeo (which is actually 2 separate computers with completely separated memory spaces), on the Jaguar all system resources share the same bus. So if you blast way to much graphical data trough the bus, the audio will be suffering (because the DSP has lower priority than the object processor) So everything had to be tuned, like the sample rate of the audio, and what color depths to use for the different layers, and sprites. Also I wanted flexibility for the game sprites, so that's why I choose to use high color (direct color, e.g. no palette) for these. Another solution is to use only one very large sprite for the tile map, and have the blitter copying the individual tiles to that sprite. However, we didn't mange to get good performance on that, because the blitter blocks the system for each and every tile to be drawn, unless you can find an intelligent way to do whole screen in one blitter job. PS. We did manage to get good performance using the blitter by drawing only new columns, or new rows as the map scrolls. However, scrolling could occur only in the vertical direction, or in the horizontal direction for one loaded map. However, it turned out to be very difficult to be able to scroll both in the horizontal, and vertical directions (with different speeds) on the same map. This was a requirement for Kings of Edom, and now also used in Asteroite.
  16. Currently sprite scaling is used for the explosions (e.g. see the drone crash sequence). First some smaller explosions, with random placement, and size appear on the drone, then it falls down down, and a larger explosion is displayed when it hits the ground (or a wall). It saves quite a lot of cartridge space to only have one explosion animation that can be displayed at arbitrary sizes
  17. The nice thing with the Jaguar is that it is possible to mix hi-color (65536 direct colors) sprites, and pseudo color (256 indexed colors) graphics in the same display. So the tile map foreground layer uses a 256 color palette, but since the sprites use hi-color (65536 direct colors), I don't have to care if different palettes are used on different levels in the game, the same sprites can be used on all levels independent of the palette. Also I can fade in/fade out the tile map, while the sprites are unaffected by the fade. There are a lot of other nice effects you can use besides than palette fades (look at the intro screens of Kings of Edom), which dissolves the images, and gradually reveal them. In my opinion, I think that palette fades are a little bit over-used on the regular 16-bit consoles, since they are so easy to implement.
  18. No palette fades possible as the sprites are hi-color (65536 colors, and no 256 color palette) However, what is not captured properly in the video is the flashing/blinking animations (most of the time the sprites just disappear in the video capture) So the effect when the enemies disappear, just like when you have been hit, is that the sprite appears fainter because it is flashing very fast.
  19. A new video, mainly to showcase some new music and artwork by Krauser. Also thank you to @SlidellMan for the "loading sector" dialog.
  20. Currently the GD seems to be available only for a select few. Sine we don't have access to that, it will be very hard to make something for it...
  21. Yes, as described in post 133 PS. Trying to answer some previously unanswered questions earlier in this thread.
  22. Yes I have also seen some games that have a combination of both, for example, when you have a town with houses etc. you most likely want them to end up in the same place every time. This is a good reason for having pre-defined maps. Also you can draw much more nice looking environments using pre-defined maps (however, some games can actually draw quite nice random maps as well), but it will never be at the same level as if you have a completely pre-defined map. Asteroite (which is a completely different game) have pre-defined maps, but it takes very much more time to make a complete game using pre-defined maps. So this approach will be exercised for the next project, which will take much longer before there will be a release.
  23. There are actually a few messages that use all 5 rows of text, so these would become unreadable with a smaller console. Also, in some menus, all 5 rows are needed (e.g. if you are under the influence of hunger, poison, burn, freeze, bleed, and curse at the same time, in addition to an indication that a crown is near), so yes, this game does provide some text that is intended to aid you on your journey. You can see it as 80% graphical adventure, and 20% text adventure. Just a side note to the other viewers (you already know about this @agradeneusince you are the guilty one) I remember that someone asked if the monsters can cast spells also, and now there is such an evil magician in the game. He is also not easily wounded by magic himself, but more receptive to melee strikes. However, his staff might curse you if you stay to close to him.
  • Create New...