Zerosquare

What are you up to ?

 

1) Are TxD on B49 and RxD on B50 just attached directly to the same pins as on the external network port, and can you talk to them using normal Jag networking code? Do you need to use SCK/WS with it or are they unrelated?

TXD and RXD are the I²S data pins for audio, and are directly connected to the same pins on the DSP port ; they're used by the JagCD to stream audio tracks, for example. Together with SCK and WS, they form a synchronous, full-duplex serial port ; SCK is the bit clock (its frequency is equal to the baud rate) while WS is used to identify which bit is the MSB and which channel (left or right) is being transmitted.

 

There's a detailed timing diagram of how I²S works in the datasheet for the audio DAC.

 

Those signals are not related to the UART used for networking.

 

Also, what are UARTO and UARTI for?

UARTO is the output (TXD) of the UART, and UARTI is the input (RXD). They're the same signals than those on the DSP port, which are used by the JagLink, etc.

 

2) Am a bit unclear on ROM1 (pin A20) - is this /CS for the cart memory ICs? Can I just leave it tied low on the cart and unconnected on the cart port or is it actually used? (am running out of level translator pins )

Yes, this is the chip select for the cartridge space ; you can't get rid of it, sorry !

 

3) Likewise /EOE1 (pin B22) and /EOE0 (pin B23) - Matthias has B23 as OE for the high word and B22 as OE for the low word, is this correct or is it backwards?

/EOE1 (pin B22) is active for read accesses to bits 31..16, /EOE0 (pin B23) is active for read accesses to bits 15..0.

 

I assume they always change state together in 32-bit accesses anyway so I may be able to get away with just one…once you've told the memory controller to run in 32-bit mode are all bus accesses always 32bit from then on even if you use mv.w?

AFAIK, yes, it's correct.

 

4) A0 and A1 are always low for 32-bit accesses, correct? (so I only need A2 - A23 hooked up to the memory - A2 on cart port to A0 on my memory IC)

Correct ; if your cart is 32-bit, you don't need to connect A0 and A1.

 

5) How do you use /EWE0, /EWE2 and ERW?

/EWE0 is low during write accesses to bits 7..0, so it should be connected to /WE if you've got RAM or Flash memory on your cart, etc. /EWE2 is the same thing for bits 23..16.

ERW indicates whether the current bus cycle is a read or a write, but I don't remember the polarity. Ask SCPCD

 

6) /RESETI is for when the cart wants to reset the Jag, but how does /RESET work? Is it just active for a few ms on powerup or does it fire under software reset (*+#) also?

Pressing * and # together doesn't do anything particular on the hardware side ; the game has to detect and handle in software.

/RESET is active only on power up (it's longer than a few milliseconds, but I don't remember how much ; that's another thing for SCPCD to answer), when the cart asserts /RESETI, or when you press the reset button if you've added one

It may be a little difficult to get... Try eBay and the "sales" areas on Atari forums/websites.

You can also build you own cable is you know how to use a soldering iron, but the video connector is hard to find.

In which country are you located ?

Well, according to the law, you don't have the right to download a ROM image even if you own a physical copy, you're supposed to dump it yourself

 

Actually I wrote it for someone who had an Atari flashcart and thought there was a beta of a game on it, but it turned out that it was bit-identical to the released version. And maybe, one day, someone will find something rare that hasn't been dumped already...

 

It can also be useful if you're testing hardware, or, say, developing a flash cart or something like that yourself

Ah yes, with development hardware/software you can do some neat tricks ; I was talking about the "stock" system

Now, who's gonna code a Portal-like game for the Jaguar ?

Here are my pictures : http://zerosquare.free.fr/ac_2011/

Thanks for releasing that ; that's the kind of program which is really useful to have in your "toolbox"

Tyrant :

 

Thanks, it's working now.

Nope, still doesn't work

 

Does it work for you if you logout from Facebook ?

I get an error page that doesn't say much ("the content is currently unavailable", blah blah). Maybe a Facebook account is required ?

 

(BTW, to those using Facebook to host photos : please stop doing this ; some people would like to see your pictures without needing to subscribe to a clunky website with dubious ethics . Thank you.)

 

Thanks.

So then, who's going to be first to upload photos?

I wanna see what I missed.

There are plenty of them here

I've been too busy to upload mine yet, but I'll do it soon.

 

Wow ! Nice work !

Don't apologize, we all make mistakes, especially when playing with new stuff. Your posts may be useful to someone else having the same problem

I hope you all had a great time this weekend. Special thanks to sh3, LinkoVitch and Mug UK for coming from far away !

 

PS : this Cadbury chocolate stuff tastes really good ; thanks again for that

 

Very nice game

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

PAL:

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

NTSC:

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

Ah, you've made a small mistake

625 (or 525) is the number of lines per frame, but 50 Hz (or 60 Hz) is the field frequency. As a frame is made of two fields, there's a 2x factor you have to include.

 

Another way to get the result is to consider the horizontal video period : 64 µs for PAL, 63.555... µs for NTSC.

That gives us (26.5939 * 10^6) * (64 * 10^-6) = 1702.0096 for PAL (rounded to 1702), and (26.590906 * 10^6) * (63.555... * 10^-6) = 1689.98503083 (rounded to 1690).

 

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.

For OP time calculations, SCPCD is the person to ask

You're right, it's not that simple, I made a mistake Sorry ! (thanks to SCPCD for noticing it).

 

It's actually 1702 cycles for PAL, and 1690 for NTSC. 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.

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.

Happy birthday to both of you

Happy birthday pmdata !

In theory, it should work.

In practice, the system and the cartridges were not designed to be hot-plugged like this, so there's a risk it would damage the cartridge and/or the console (which is why I did not mention it).

 

Interestingly, the fact that some cartridge pins are longer than others is a good hint hot-plugging was considered at some point. But since the Jaguar shuts down if there's no cartridge inserted, and there's no documentation on this, it's better to be safe than sorry.

Yes, but when a cartridge is inserted into the JagCD, it starts even if there is a CD in the drive. So there's no way of running the dumping program from the CD, unless you have the BJL ROM installed.

 

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 !

I just tested it again on PT 0.95 and you're right, it does work fine ! My memory is failing me...

 

Actually, this is very interesting, because RMW doesn't work correctly in PT for most other games (for example, the floating logos in Do The Same have a transparent background, instead of translucent)...