Zerosquare

 

It's a home-made MSX programmable cartridge.

Here are the pictures I took : http://zerosquare.free.fr/rgc_2010/

More pictures by other people : http://www.yaronet.com/last.php?s=136107

Huh ? It wasn't directed at you, just a remainder that it's OK to reuse this code, and that I'd like one line in the credits in return

I think I might steal this code.

As long as you don't forget to give credit, go ahead, that's what it's for

I've tested your program on a PAL Jaguar, with a 50/60 Hz switch, connected to LCD monitor. Both 50 Hz and 60 Hz mode work fine, and the picture is centered.

 

Good job

The docs say (Softref p16, object definitions) that the height field should be decremented by 1 per line for non interlaced, and 2 per line for interlaced modes... I'm getting it decremented by 1 per line when interlacing. This means it's drawing the whole bitmap each field, instead of every other line, with the result that it's twice as tall as it should be.

 

Any idea why this is, what's causing it, and how to fix it?

Yes. The doc is wrong ; in practice, the OP doesn't seem to care whether the display mode is interlaced or not, it always decrement the HEIGHT field by one per line.

 

One solution is to split your bitmaps into two different ones : one with the odd lines only, one with the even lines only. In your VBL interrupt routine, update the DATA field of your bitmap object with the address of the correct half-bitmap, according to the field which will be drawn next.

 

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.

Here we go, you can now register for the RGC 2010 !

This retro-and-alternative-themed week-end will take place on November 13th and 14th 2010, starting at 10 A.M., in Crégy-lès-Meaux's (France) function hall.

 

In addition to meeting and discussing with other enthusiasts, you will also hear about the latest soon-to-be released projects, thanks to numerous presentations :

- the Alice Team

- the Super Fighter Team

- Nightmare Buster on the SNES, with the collaboration of Super Fighter Team and PGR

- A never-released game on the Game Boy Color, with the collaboration of PGR

- Fast Striker on the Dreamcast

- An overview of the Demoscene.fr portal

- Pix'n Love books

The list is constantly evolving.

 

For those who are interested in good deals, rare gems or an occasion to swap their duplicates, the usual swapping/selling corner will be provided ; the sellers include the Otaku Store, 16/32 Systems (Nick Harlow will be visiting us from England) and many others...

 

This fourth edition will feature the acclaimed RGC tournament (limited number of participants) which will revolve around three retro video games, and award prizes to winners. Don't miss the Alice Team (Dreamcast homebrews) and the RayXambeR association (retrogaming-oriented magazines) booths, either!

 

The RGC 2010 will allow you to dive into retro-and-alternative gaming fun, thanks to the presence of a wide variety of gaming platforms, starting from the Pong machines. It is thus the perfect occasion to bring and show your own hardware and collection, but also to buy or sell it. Do not hesitate to tell us by filling the appropriate part in the registration form.

 

Prices and registration form :

http://www.yaronet.com/posts.php?s=135420

 

See you there!

Merci à tous

Hmm... do you remember how you came up with those values? I only ask because they're very very different from the defaults (as specified on techref page 1).

Also is just setting those values sufficient to enable interlacing? I would have expected to find some kind of "interlace enable" flag somewhere, but can't see one in the docs.

There's no real flag : if the total number of half-lines per video field is even (not the value of the VP register ; remember that the number of half-lines is VP plus one), the display is non-interlaced ; if it is odd, the display is interlaced.

 

However, changing VP alone is not sufficient to generate a correct interlaced screen in all cases. The values used by the boot ROM to initialize the video are slightly wrong (I recall that the number of sync pulses was not correct, and there may have been other inaccuracies) ; I suspect whoever wrote the code didn't understand the documentation fully, which is believable since it's not very clear... Additionally, there are two different versions of the boot ROM, plus the BJL ROM, and some values are different depending on the version.

 

All of this doesn't matter much for non-interlaced screens (the picture will just be offset slightly), but it is critical for interlaced screens, otherwise odd and even lines may be swapped with each other.

 

Oh, and the relationship between bit #11 from VC and whether the current field is "top" or "bottom" is indirect ; it just toggles on each field, on its own. So you can't switch from non-interlaced to interlaced whenever you want, otherwise you have a 50% chance of getting it wrong. This is why the code writes to VC and HC first, so that the video counters start from a known value.

 

So I decided to compute the correct values for the video registers using the official TV timings, the documentation, and (lots of) testing.

 

Do you mean horizontal resolutions? What would need to be changed? I'm thinking of a pixel divisor of 2 (for 665 overscanned pixels horizontally) specifically. Surely vertical resolution is determined by the PAL and NTSC standards?

I was thinking horizontal resolution ; although it's not directly related to interlacing, a single routine which would take care of everything would be good

 

There's also the special case of using a dividor of 1 : you have to init both VDB1 and VDB2 with different values.

The Atari Jaguar Europe Festival, "ejagfest" in short, takes place on 27th November of this year in Kaarst, Germany.

 

The Atari Jaguar Europe Festival is an annual festival for all Atari Jaguar and Lynx fans, developers and retailers. Open-minded fans of other video game systems are welcome, of course.

 

The „Atari Jaguar Europe Festival“, "ejagfest" in short, takes place on 27th November of this year in Kaarst, Germany (not far from Neuss/Düsseldorf). It’s a meeting of retro gaming fans from all over Europe.

The focus of attention is Atari and all consoles of the cult lable. All of you who would like to play systems like the Jaguar, Lynx, VCS 2600, 5200, 7800 or on a trusty homecomputer of the 80s, this is the right place.

 

Retro games, homebrew announcements / presentations, prototypes believed to be lost and demos of all kind can be experienced on the ejagfest.

Developers from all over Europe regularly take the opportunity to present their new developments on the festival, and sometimes even have exclusive items for sale. New VCS 2600 games such as “Rasterfahndung” and “Encaved” were shown. Starcat presented projects such as “Star Alliance”, an early tech demo of “Eerievale” and released a limited ejagfest edition of his Jaguar CD title “JagMIND: Bomb Squad”. Beta-Versions of the Jaguar puzzle game “Clicks” and “Impulse X”, the new game by Matthias Domin were presented. The impressive „Atariowl Project“ for the Jaguar was presented for the first time and early exclusive screenshots of the Lynx version of Iron Solider were shown.

 

Another highlight was the presentation of the only working “High-res Jaguar Virtual Reality Headset” in existence, which was shown on ejagfest in the year 2007.

 

Competitions such as “Club Drive” or “Kasumi Ninja” make sure everyone has a fun time. Next to these fun competitions, the official European championship in “Checkered Flag” for the Lynx is taking place each year.

To make the event complete there are retro game retailers to offer Jaguar/Lynx titles and a variety of other retro games and systems.

 

Additional highlights of this year

 

• An exclusive demo of the promising Action-RPG „Atariowl Project“, which sets new standards on the Jaguar will be presented.

• For the first time since the project’s revival, the Eerievale Team provides insight into the progress on the correspondent multiplatform graphic adventure.

• The well known Jaguar developer teams “Reboot” and “Jagware” will be present with their latest developments.

• Matthias Domin, developer of Jaguar titles such as „Double Feature“, „Clicks“ and „Impulse X“ announced his attendance.

• Gary Taylor shows his new custom overlays & boxes for the Jaguar and the already released Aircars 94 Beta.

• Nick Harlow of 16/32 Systems will have a wide variety of new and used atari games and systems for sale.

• Sijmen and Sandra of „The Atari Shop“ will be present with their Atari & Retro merchandise.

 

Competitions:

 

• Checkered Flag European Championship (Atari Lynx)

• Kick-Off NRW-Championship (Atari ST)

 

This list is nowhere complete, every visitor who has something to show is welcome to. Please let us know in advance if possible.

 

All of you who enjoy retro games and a nice chat with like-minded people are welcome to join us.

 

This year is the event‘s 10th anniversary and takes place for the 7th time in a row at the Bischofshof location in Kaarst.

 

Opening is on 27th November at 10:30am. Entrance fee is 5,00 Euro.

 

The exact address, directions and latest news can be found on:

http://www.jagfest.org/euro and on http://www.twitter.com/ejagfest.

Oh, and are there any more errors in the schematic I should be aware of, other than both joypad ports being for Controller 0?

Oops, missed that part. I don't remember seeing any error in the schematic, or at least nothing important. The only thing I can think of at the moment is that there a few places where there's a capacitor symbol that doesn't make sense (the controller-port-shielding to ground connection, for example).

 

Oh, by the way, while we're on the subject of carts : if you build your own PCB, make sure that the edge is beveled, like this :

It is very easy to damage the cartridge connector's contacts by accident otherwise.

Just a shame so much is in French, but that's mostly the old stuff.

Yes, we try to use English now. If you need help to understand an older topic, just ask

I might have to read the schematic to get this straight in my mind. Are you saying if you drive the bus low the IC sinks (5V*pullup resistance) internally, and if you drive it to 3.3V you have the pullups trying to pour (1.2V*resistance) into the output driver? How does this affect your Flash chips etc, or do you just buffer all the outputs?

It's 5V/R and 1.2V/R, but yeah, it's correct. The current is pretty low, but the real problem occurs when the IC tries to drive the pins to 3.3V. The internal ESD protection diode that's between Vcc and the output pin will be forward biased, which is not supposed to happen in normal usage. I don't know if it is actually destructive, but it's not recommended, so we buffered every signal on the Flash cart (we needed to anyways, since the Flash memory we use isn't 5 V-tolerant at all).

1) What happens to the cart bus when a cartridge asserts nRESET? I know it causes a 68k NMI but does the memory controller see it also? Does the bus freeze in its last state, get tristated, neither?

Sorry, I don't know. Maybe SCPCD knows

 

Can you hold the line low forever to keep it reset forever?

I think you can do this without problem, yes.

 

2) I know some of you use 3.3V devices on your custom carts (Zerosquare) - does the Jag accept 3.3V signalling or do you translate it? Obviously no problem to do either (or combine it in a bus tristate IC) but no point doing it if you don't need to bother.

The cartridge's data bus is internally buffered by 74ACT245s in the Jaguar. Since they're designed to be compatible with TTL levels, 3.3 V CMOS signaling should work fine. Beware that the bus is pulled-up to +5V with resistors, though, so both the inputs and the outputs of your 3.3 V devices must be 5 V-tolerant. (74LVCxxx chips are fine for this).

 

3) Does anyone have the section of the developer's manual (cartridge and expansion port) that's missing from Starcat's copy?

I don't, and I don't know anybody who does. You can try asking Curt Vendel, as he's got a lot of docs from Atari.

 

Thanks in advance, and no, there's nothing to see here

I don't believe you

Welcome Stone

I'll probably end up repeating what others have said, but anyways...

 

I don't believe I've ever spoken a bad word about Jagware in any public forum, despite the number of bad things said about me by certain of your members at forums such as Yaronet, so this treatment is particularly perplexing.

Which members, and which posts ? I don't believe any Jagware member has a problem with you, and I don't remember anything derogatory said about you either. If you have something specific in mind, please elaborate, and we'll try to sort it out.

 

you can't expect the rest of the world to come to a halt just because you make an announcement. If you wanted to let me know even two months ago then it would have been early enough to stop things.

But nobody wants, or even expects, you to stop making the Skunkboards. A lot of Jagware developers have one or several of them and find them very useful (I know that at least Fadest, SebRmv and Reboot use them for developing their games).

 

We don't intend our flash cart to compete with your Skunkboard. They're not made for the same use, and both have their place. While I can't tell people that you can't use our Flash cart for development or testing stuff, I've tried to make it clear it's not the primary use, and that a Skunkboard is a better choice in this case.

 

Regarding the timing, yes, it's unfortunate. We didn't know, and I honestly wasn't thinking you'd do a third run of Skunkboards, as your request for someone to fund it was a while ago, and nobody had responded (at least not publicly).

 

The only thing that disturbed me was that the block list wasn't public, but you explained why it is so on AtariAge. I still think that asking your game to be banned and refusing to admit it publicly is a pretty coward behavior, but if you have an agreement with those developers, the choice is not yours to make and I understand that. And I certainly won't blame you for wanting to avoid flamewars (believe me, I found myself trapped in enough of them back when we started discussing the JagCF).

 

I'll say it once more : I don't have any problem with you or the Skunkboard

Ah yes, that's a known Google Translate bug. I stumbled upon it a while ago

-When you can order?

Soon

Before the end of the year, we hope

 

-With the cartridge and 'THE INSTALLATION including the driver?

The software will be downloadable on our web site.

 

Matmook : c'est pour ça que j'ai pas parlé du CRY / RMW

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.

 

Mais comme tout est logiciel, peu de pixels sont concernés, sinon ça rame. Et c'est pourquoi il vaut mieux passer par la carte vidéo avec les sprite3D. Le concepteur de ce langage, que j'ai eu l'honneur de rencontrer en 2009, programme en assembleur, et pour arriver à faire de la transparence avec de la mémoire vive, il doit surement faire un calcul pour chaque pixel concerné.

Oui, mais l'alpha-blending logiciel n'a rien de compliqué, la formule de base est simple.

 

Pour la Jaguar, il y a 2 Mo, le Blitter et un DSP. Ces derniers gèrent très rapidement, plus vite que la mémoire encore, les données. Donc techniquement cette console à la capacité de gérer la transparence en hardware, et un petit peu en software (car peu de ram). Je suis sûr qu'un programmeur maitrisant l'assembleur sur ces composants, avec les schémas techniques précis de ces composants (comment sont assemblé les portes logiques)...

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

 

en faisant un tour sur les sites expliquant comment créer un moteur 3D, pour dénicher la formule mathématique miracle, il sera capable de faire de la transparence hardware.

La transparence n'a aucun rapport avec la 3D, la formule mathématique est simple, et ce n'est pas gérable en hardware.

 

En l'état actuel de mes connaissances, tout va dépendre du Blitter. Car contrairement au 68000, il a une position privilégié dans le système Jaguar (voir schéma page 29) :

 

Technical Reference v8.pdf page 65 :

 

nous avons donc dans notre Blitter, deux unités qui ne sont pas là juste pour faire jolie

Merci, mais nous aussi on a lu la doc

 

Sont-elles aussi présente dans le 68000 ? Non (j'espère ne pas me tromper, l'avis de kuk sera des plus précieux).

Primo ça ne veut rien dire, deuxio Kuk n'est absolument pas programmeur, contrairement à un certain nombre d'entre nous.

 

A la page 66, ils y a un tableau intéressant :

F02210 A1 step integer part

F02214 A1 step fractional part

 

F0221C A1 increment integer part

F02220 A1 increment fractional part

Ça concerne les zooms et rotations ça, aucun rapport avec la transparence.

 

l'idée est de détourner un peu les fonction 3D (qui peut le plus, peut le moins, comme disais mon prof d'électricité plein de sagesse), couplé au GPU via le Bus Master, les concepteurs de la machine lui ont donné le beau rôle : celui de magnifier le rendu --> transparence

C'est-à-dire ? Parce que là c'est très vague, je ne vois pas comment tu comptes faire.

 

http://www.mulle-kybernetik.com/jagdox/blitter.html

You can probably do collision detection on background colors, and transparent blits...

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