Zerosquare

Transparence uniforme, tu veux dire soit 0%, soit 100%, comme les fichiers GIF ? Si oui, pas besoin de bricoler pour ça : c'est supporté en hardware, il y a un bit à activer dans la description du sprite pour rendre la couleur n°0 transparente.

Bon, une petit remise au point s'impose Tu as l'air de mélanger un peu tout. Sans vouloir te vexer, personnellement ça va bientôt faire 5 ans que je développe sur Jaguar, et certains sur ce forum le font depuis encore plus longtemps. Donc je pense qu'on connaît un peu mieux la machine que toi. Oui, mais l'alpha-blending logiciel n'a rien de compliqué, la formule de base est simple. Désolé mais ça ne veut rien dire. Il n'y a pas d'alpha-blending hardware, point. C'est faisable en software, mais au prix d'un usage intensif du GPU. De plus la distinction sprite software / sprite hardware dont tu parlais plus haut n'a pas cours sur la Jaguar, qui a une architecture mémoire unifiée (il n'y a pas de mémoire vidéo dédiée). La transparence n'a aucun rapport avec la 3D, la formule mathématique est simple, et ce n'est pas gérable en hardware. Merci, mais nous aussi on a lu la doc Primo ça ne veut rien dire, deuxio Kuk n'est absolument pas programmeur, contrairement à un certain nombre d'entre nous. Ça concerne les zooms et rotations ça, aucun rapport avec la transparence. C'est-à-dire ? Parce que là c'est très vague, je ne vois pas comment tu comptes faire. C'est de la transparence "simple" (on/off) qu'il s'agit ici, pas d'alpha-blending.

Tût tût, je te vois venir, au prochain post tu vas demander une version Neo Geo aussi Ceci est un forum Jaguar

Ah oui d'accord, je vois ce que tu veux dire. Cette distinction n'existe pas sur Jaguar. La transparence "simple" (soit un pixel est totalement opaque, soit il est totalement transparent) est supportée, mais pas l'alpha-blending. 256x256 on peut, mais seulement en PAL (en NTSC le maximum c'est environ 240). Et il ne faut pas perdre de vue que sur une télé cathodique, l'image sera partiellement coupée sur les bords, donc il ne faut mettre d'éléments critiques pour le gameplay (score, etc.) trop près des bordures.

Jolis graphismes Par contre, attention à ne pas être trop gourmand question technique : il vaut mieux se limiter à du 240x240 (un mode 480 lignes est possible, mais il n'est pas officiel, et ce n'est pas encore suffisamment mûr pour être utilisé dans un jeu facilement), l'alpha blending n'est pas géré en hardware, la taille totale des graphismes et sons sera limitée, et je ne sais pas vraiment ce que tu veux dire par "sprites 3D", mais la 3D temps réel est tellement limitée qu'il vaut mieux l'oublier. Il y a plus de détails sur ce qui est possible ou pas dans ce topic : http://www.jagware.org/index.php?showtopic=795.

Bienvenue ! Hélas, ce que tu décris n'est que la partie émergée de l'iceberg qu'est "l'industrie" vidéoludique actuelle...

AlexH : as a matter of fact, my job is designing hardware too, so I think I'll manage. But thanks for the help proposal anyways CJ : thanks, I'll definitely include your bypass code.

The "BJL emulation" part is already planned. Check the FAQ for details I thought about the CD-bypass feature too ; I'm not sure if we'll have enough space to include it (we only have a few kilobytes for the code), but if we can we'll do so

Yes, in reality the prices will be lower, because we will be manufacturing much more than 10 cartridges. The price I gave above is a maximum We know it can add up to a lot of money in total. One solution is to ask for prepayment, or at least a money deposit, for preorders. That way you'll know how much persons are going to order, and you'll have some money from the start

Yes. 1.5 euro per board would be nice, but unfortunately, there's no way we can get those prices

Not at all, I think we misunderstood each other there There's something I'm not sure I understand. Do you have an independent serial number in the BIOS in addition to the flash chip unique number ? I thought you used the flash chip number only, since it identifies the hardware directly and it's hard to counterfeit. Or maybe the BIOS number is generated from the flash chip number in some way ? I should have been more clear in my reply. The crux of the matter is that your Skunkboard and our flash cart have different design philosophies, and things that are justified for one of them may not be so for the other : If I'm not mistaken, the Skunkboard is primarily a development tool. Serialized Skunkboards make sense because the hardware supports it natively, and this feature can be useful for developers who want to release betas versions to a few persons, without the risk of their game being released without their consent. On the other hand, our cart has been designed as a way for developers to make it easy to release cartridge games. We added support for using it as a "generic flash cart" because it didn't cost anything extra, but it's not the primary use, and it's not really intended as a development tool either. Reflashing will probably be slower than on the Skunkboard (because it uses parallel port communication instead of USB, and I think the flash chip we use takes longer to erase -- I'll have to compare the datasheets), and the Skunkboard's USB port is definitely more convenient. One of the consequences is that we never intended to support serialization, and the design choices reflect that. The flash chip doesn't include a serial number, and there is no safe place to store a self-created unique number. Of course it would be possible to include one in the BIOS, but : - it wasn't designed to be secure, so anyone can overwrite it. We may even release the source, which makes security-by-obscurity pretty moot. - it wasn't designed to be protected, or even present : developers may want to write the standard header (or their own code) in this area. Additionally, it can be corrupted / erased if the flashing process fails for some reason, such as power loss (and sector locking is not possible, because we'd like to be able to use both "top-boot" and "bottom-boot" devices, as stocks of both variants tend to fluctuate). This means that even in "normal usage", it's easy to end up with the serial number being erased, with no way of knowing what it originally was. To sum it up, while serializing is useful for the Skunkboard, I don't think it's relevant for our flash cart. And I prefer no to offer it at all, instead of using a implementation I consider flawed But if developers really want this feature, we could implement it.

Yup, but there's no real protection forbidding anyone from reflashing it with anything. So I think it would be pretty pointless. Neither SCPCD nor I are, unfortunately, but maybe someone else from Jagware will be

Yes, it should be possible. Thanks. I'll look into that. That's another option in case the solution above doesn't work for some reason.

I've checked the EEPROMs' documentation, and it appears that the 2 kilobytes ones are not directly compatible with the 128 bytes ones, after all The problem is that I thought all of them had the same number of address bits, and that higher bits were just ignored for smaller devices. But it's not the case : the number of address bits to send depends on the size of the EEPROM. It's easy to fix in new programs, but it means that older games won't work with larger EEPROMs.

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). Starcat : yes, the EEPROM chip is the standard 128-byte one. But compatible chips with the same pinout and sizes up to 2 kilobytes exist, and they're not very expensive. That means we could offer a version with more memory, if there is enough interest ; or maybe we could only manufacture this version, if the standard Atari EEPROM code is compatible with larger devices (I don't know what happens in this case, we'll have to test it). Larger (up to 128 kilobytes) EEPROM chips also exist, but they're not directly compatible, so it's not something we will look into unless there is considerable demand.

Maybe Matmook and Reboot can offer some advice there ?

Happy birthday Fredifredo !

External links : Freescale 68K series page Freescale (formerly Motorola) is the manufacturer of the 68000 processor in the Jaguar. You'll find the official technical documentation on this page. Matthias Domin's Jaguar page Very complete webpage with extensive information about the hardware aspects of the Jaguar. Includes the Jaguar hardware schematic, cartridge schematics, and information about BJL and other hardware modifications, the JagLink and compatible devices, analog controllers, light guns, mice, rotary controllers, CD encryption, cartridge EEPROMs, and more. Jag-UDG Dumps of various system ROMs and special cartridges (boot ROM, JagCD ROM, Stubulator, Flash cartridge and Memory Track), and information about making Jaguar CDs. Sinister Developments Jaguar Development Resources Sources of Sinister's MOD files player, and of the game Painter. Bastian Schick's homepage Home of the BJL development kit. Includes the BJL ROM image, uploader programs for DOS, Linux and the Atari ST/TT/Falcon, and various demos with sources. Hill Software (local mirror) You can find the original Jaguar SDK here, as well as ready-made development environment for Windows, Linux and MacOS X. There is also a CD version of the BJL ROM and a GUI frontend for the Skunkboard tools. The Removers Development environment and support libraries to create Jaguar programs easily in C, with examples. Swap d0's development tools Jaguar development suite for BeOS, with sources : BJL loader, assembler, debugger and disassembler. There's also an image compression routine. ray's 16/32 bits Atari page CRY image viewer for the ST (look in the 'Miscellaneous' part). There is also a lot of code which is not Jaguar-specific but nonetheless very interesting (data packing, wavelet image compression, 3D algorithms, etc.). Reboot projects Universal Loading System (convert any BJL program into a self-bootable CD in just a few minutes), CD encryption with the Skunkboard, Atari ST version of the BJL uploader patched to work correctly with large files, Jagtopia (CD-based encryption bypass). LinkoVitch Atari Jaguar's page Detailed guide (with photos) on how to install the BJL ROM into your Jaguar. There's also a Jaguar CD repair guide. How to do the BJL Mod Another BJL modding guide. Atari Museum - Jaguar section Cartridges and CDs encryption tools, cartridge mechanical drawings, sources of the CD BIOS and VLM, information on unreleased projects (JagModem, MPEG decoding board, Atari 2600 emulator, Jaguar 2, Panther). The Jaguar Underground Documentation The first independent attempt at documenting the Jaguar. Pretty much obsolete now that the official docs are available, but you never know... The Jaguar Server home page As the title says, this is the home page for the old Jaguar Server computer-to-Jaguar link. It's been superseded by BJL for a long while, and the link is provided for historical purposes. Else Engineering's JagLink II Information about the JagLink II, and how to program for it. No Fragments 9: Jaguar Freeware Random public Atari Jaguar files, some are development-related. The whole CD is also available as an ISO image. Project Tempest A pretty fast Jaguar emulator, but not very accurate. It is no longer developed. Note : if something doesn't run with Project Tempest 0.95, try the 0.5 version from this page instead : it works better in some cases. Virtual Jaguar (Windows binaries) A more accurate but much slower Jaguar emulator. Still developed, but not updated often. Jagulator Another emulator ; it was considered abandoned since 2001, but a new version has been released by its author in June 2011. Skunkboard home page Home page for the Skunkboard cartridge, where you can find the latest BIOS and software, as well as a support forum. Robert Demming's Atari page Jaguar CD Creator (program to make creating Jaguar CDs easier), information on how to convert a standard JagCD into a developer JagCD, and an illustrated guide for installing a switch to support 5 different boot ROMs. JagMod Jaguar Cinepak Tools for Windows (a GUI program to create Cinepak video CDs). SubQMod's Console and Emulator Development Home of SMAC and SLN (open-source replacements for ALN and MAC). Patched version of SLN by DrTypo Fixes some bugs in the original version of SLN. The cartridge boot process Info and disassembly of the cartridge boot code. JiFFI Tool to convert Jaguar programs from and to different formats (Jaguar Server, BJL, ROM, CD). WinFLASH Windows tool for uploading software to the official Atari Flash carts. Templates for manuals, boxes and overlays For those who want to make games that fit on the shelf next to the official ones Replacing the Jaguar cartridge port by OMF For people who break their cartridge port like Zerosquare The Favard Jaguar development kit An early homebrew development kit that was made by the Favard brothers. RMAC / RLN Reboot's open-source replacements for MAC and ALN. JRob's SPU A sound library that supports CD audio mixing. U-235 LinkoVitch's sound engine, graphics converter and RISC disassembler. Fujiology - Jaguar section An archive of Atari-related files collected by Lotek Style of TSCC. Lots of stuff, but mostly mirrors of what's available elsewhere.

Don't bother GT, I dealt with it (see the original post) My reply : We would need to see what the Flash version looks like, of course, but it's very probable it can be ported to the Jaguar. You can tell him to read this topic (in French) for more info.

"Jagtopia is a system for booting CDs. It will allow you to boot both unencrypted & encrypted Jaguar CDs. There are two versions, one is CD-based & the other is a binary. The CD version is an encrypted disc that will boot, allow you to swap the disc for another, then boot it. The binary can be run from your skunk or BJL Jaguar & boots either type of CD. Check the site http://reboot.atari.org to learn more & grab the download that suit you best." (sh3-rg)

The German gaming website neXGam just published a pretty in-depth and well-illustrated interview of the Reboot gang. The interview has been published in both German and English. Here it is.

Great and informative post, Tyrant The Jaguar needed more testing for sure, but I'm willing to bet the reason why they removed that diode was to save a few cents on each controller Matthias Domin's Impulse (which should be released soon) is going to support mice and rotaries controllers, too. Yes, on the ST(E)/TT/Falcon, the keyboard processor does count the pulses for you ; you can simply ask it how much the mouse has moved. Yes, they're totally different. The controllers supported in BSG are analog joysticks, and only work on early Jaguars that included the ADC chip. The rotary controllers supported by Tempest 2000 are, well, rotary things which you can rotate endlessly in both directions, and work on all Jaguars. Done I've also merged Fadest's topic about rotary controllers, and an old topic by GT Turbo about detecting teamtaps.

OK, since Tyr of the Arcana asked me about it, I think it's better for me to release the info I have rather than wait until it is finished (which may never happen, since I seem to be involved in too many projects ) First, some basic facts about interlacing (with a few simplifications to make it easier to understand) : - a standard TV picture is interlaced. That means that the lines are not refreshed in sequence (0, 1, 2, 3...), but alternatively : first the even ones (0, 2, 4...), then the odd ones (1, 3, 5...), then the even ones again, etc. A set of lines, either odd or even, is called a field. A complete picture, made from two consecutive fields, is called a frame. Consequently there are 50 (60 in NTSC) fields displayed per second, but only 25 (30 in NTSC) frames. - the Jaguar, like almost every console before it, outputs non-interlaced video by default, since it's easier to generate and generates less flicker for sharp graphics. It means that instead of alternating between and even lines, it only outputs fields containing even (or odd) lines. In this case, each frame is made of a single field. So you get twice as many frames per second (50 or 60), at the expense of half the vertical resolution (since you only use every other line). - unfortunately, there's no definitive agreement on how the lines should be numbered ; depending on the book/website, the convention used isn't always the same. In particular, the lines you call "even" may be called "odd" (and vice-versa) by someone else. To avoid confusion, instead of using those terms, I'll call the field which contains the first (from top to bottom) line of the picture top field, and the other bottom field. Now, the code. This stuff is old, and I'd need to delve into it again to understand exactly how it works. I'll try to post an example program when I have time. First you need to enable interlacing by rewriting some video registers (the ones the Atari documentation tells you not to touch ) : move.w CONFIG, d0 andi.w #16, d0 bne.s Init60HzI Init50HzI: move.w #0, HC move.w #1, VC move.w #624, VP move.w #614, VEB move.w #619, VS move.w #4, VEE move.w #40, VBE move.w #614, VBB move.w #850, HP move.w #1749, HS move.w #787, HEQ move.w #600, HVS move.w #1709, HBB move.w #153, HBE bra.s Suite Init60HzI: move.w #0, HC move.w #1, VC move.w #524, VP move.w #512, VEB move.w #518, VS move.w #5, VEE move.w #30, VBE move.w #512, VBB move.w #844, HP move.w #1743, HS move.w #780, HEQ move.w #595, HVS move.w #1697, HBB move.w #118, HBE Suite: stop #$2700 This code should really be rewritten to accept different resolutions, but it should be enough to start testing. From now on, you can test whether the current field is the top one or the bottom one by testing bit 11 of the VC register : - if it's clear : top field - if it's set : bottom field If you use the 68K VBL interrupt, you also need to dynamically alter the value of the VI register, otherwise the interrupt won't trigger : - for top field : VI must have bit 0 cleared (even value) - for bottom field : VI must have bit 0 set (odd value) Remember that when the VBL interrupt triggers, the next field hasn't begun yet. So you have to set VI correctly for the next field, not the current one. Which means that at the start of your VBL interrupt, you should set VI to an even value if bit 11 of VC is set, set it to a odd value otherwise. I'll try to add additional information when I find time, and probably a test program. Anyways, feel free to ask questions in the meantime !