Upcoming Jaguar Game Drive Cartridge

[madperry]

Stephen what preorder list?

Yes, please explain. Anyone. Thought there was no preorder yet?

[racerx]

[SuperDork3000]

I dont find that original carts need cleaning much at all, as they have gold plated contacts -- this will be the same for the JagSD. So really, it will be the same as any other cart. The only difference is, you will never need to remove this one (ok, apart from the Reboot carts!)... just take out the SD card from the top if you need to add any more games.

 

The only time I will be removing the sd cart, is to play Another World and Painter SE, as well as any other Jag game that have not been dumped yet

[+af0l]

Yes, please explain. Anyone. Thought there was no preorder yet?

 

 

You are absolutely correct. There isn't.

[m2carb]

I certainly want to get on the preorder list, when it is available, but last I knew, it did not exist

[bbuchholtz]

I'd personally much rather prefer having people ask me constantly on how to get onto a preorder list, than there not being any interest at all...

 

It might be good to start finding out how many people want one, to start planning out quantities for production... especially if any of the parts are hard to source. Obsolete consoles often require obsolete components. It's sounding like the BoM is pretty well worked-out and most of the remaining effort is software and PCB revisions.

 

-Brian

[racerx]

Man...if only SainT had any experience with this sort of release...

[Krip316]

I know when I get mine (I'm already on the pre-order list)

Good one Stephen.... Good one. Hook, line, and sinker.

[SainT]

especially if any of the parts are hard to source. Obsolete consoles often require obsolete components. It's sounding like the BoM is pretty well worked-out and most of the remaining effort is software and PCB revisions.

 

You dont have to use obsolete components if you're interfacing with old hardware, you just do it right and use appropriate interfacing logic to handle the interface between the old and the new. In-fact the large majority of the chips on the board are for this purpose.

 

I produce things in batches of 100 at a time, and I reckon I can shift more than 100.... probably within a day.... so I'm not too worried about numbers. Until it's finished and tested to my satisfaction, I wont worry about any sort of pre-orders. It's getting closer all the time, but man alive, little glitches are ridiculously time consuming!! With the Jaguar you never can be sure if its the Jaguar hardware at fault, my own hardware, or software. When everything is in flux it's bloody hard going!

[sh3-rg]

With the Jaguar you never can be sure if its the Jaguar hardware at fault, my own hardware, or software. When everything is in flux it's bloody hard going!

 

This seems entirely consistent with everything I've seen and heard in the past.

 

Keep keeping on - you're doing it right.

[LinkoVitch]

 

With the Jaguar you never can be sure if its the Jaguar hardware at fault, my own hardware, or software. When everything is in flux it's bloody hard going!

 

Ah! Make sure you have your Jaguar correctly aligned with local lay-lines, you should be able to consult with your local midlevel shaman to get a proper alignment aspect for optimal 64bitness, if you are off slightly you end up with etherial eddybits and only sub 64bit powa being possible before the thaumic charge dissipates and it all goes octareen!

 

(Personally I use short power words, of roughly 4 letters in length and threats of violence in the general direction of any electronics that might be listening)

[leech]

Ah! Make sure you have your Jaguar correctly aligned with local lay-lines, you should be able to consult with your local midlevel shaman to get a proper alignment aspect for optimal 64bitness, if you are off slightly you end up with etherial eddybits and only sub 64bit powa being possible before the thaumic charge dissipates and it all goes octareen!

 

(Personally I use short power words, of roughly 4 letters in length and threats of violence in the general direction of any electronics that might be listening)

Like 'work!' It is a four letter word, and we all know the worse ones end in K.

[phoenixdownita]

Like 'work!' It is a four letter word, and we all know the worse ones end in K.

It depends on which end side you happen to be, take for example "[f|l|s]uck".

[m8z3r0]

When preorder starts,please put me on the list.

Edited April 19, 2018 by m8z3r0

[SainT]

When preorder starts,please put me on the list.

 

Just to be clear, there is no pre-pre-order list either...

 

(It will be done in a similar way to the NGP, you will just register yourself)

Edited April 19, 2018 by SainT

[SainT]

A question for the Jag developers here. I'm having some real weirdness reading GPU memory from the 68k. It seems if when I start the GPU and I do a wait loop on GO bit, then I seem to be able to read ok from the GPU RAM. If I dont do this, reads from the GPU space come back either with odd data (like the top byte or two of a longword is corrupt) or it reads at an odd offset, like -4 from where I want.

 

With the CD BIOS, I'm not in control of how the GPU is started and my reads from GPU RAM are returning bollocks. So, in general, what the hell is up with that?! Is there something magic I need to do to not get corrupt values from the GPU RAM? Is there a "dont bugger things up" flag bit I'm missing?

[SainT]

For instance reading from GPU RAM for the CD load ptr is returning $01008000 whereas when I write out the ptr from the GPU into cartridge space I get $8000, which is the correct value. Its causing reads to terminate incorrectly as the returned address is larger then the end address and the code rightly thinks the read is complete.

 

Seriously, wtf?

[SainT]

Holy crap. The read result changes depending on how many nops I put before the read...

 

move.l (a0),a0 ; Get current address
move.l (a1),a1 ; Get error address

gives different results to

nop
move.l (a0),a0 ; Get current address
move.l (a1),a1 ; Get error address

Not sure if this is related to the address of the 68k instruction, the relative CPU / GPU cycle offsets, or what? What I do know is, it scares the hell out of me.

 

Can anyone make this sound any saner?

[Glen's Retro Show]

Saint. Only you are the Jedi

[SainT]

Eurgh, depending on which clock (26mhz system or 13mhz cpu) and which edge you register the interrupts, it seems to change the behavior of the reads from the GPU memory on the 68k. Similarly to adding nops. Jesus.

[GroovyBee]

Pages 31, 36 and 37 of Tech Ref Manual 2.4, chapter Tom & Jerry explain how the 68K should access the GPU memory.

[SainT]

Pages 31, 36 and 37 of Tech Ref Manual 2.4, chapter Tom & Jerry explain how the 68K should access the GPU memory.

 

Unfortunately there's nothing out of the ordinary in there.

 

I think it's something to do with interrupts and exactly when they are generated. Although I'm not sure how or why yet.... I can certainly vary the behavior of the GPU fetch unit accessing local GPU RAM from the CPU by changing when and for how long the interrupt line is held high.

 

Very odd....

[vintagemoose]

 

Unfortunately there's nothing out of the ordinary in there.

 

I think it's something to do with interrupts and exactly when they are generated. Although I'm not sure how or why yet.... I can certainly vary the behavior of the GPU fetch unit accessing local GPU RAM from the CPU by changing when and for how long the interrupt line is held high.

 

Very odd....

 

Yeah the docs seem to suggest that the address might be a little odd if the GPU Interrupt code hasn't run. But I think that's fairly well known

[SainT]

It's really really weird. If it was to do with reading while interrupts were in service on the GPU then I would expect the issue to be there always in a tight polling loop reading GPU RAM, but if I sync the CPU & GPU by testing the GO bit, then I can happily poll away for millions of reads. It's SOMETHING to do with interrupts, as I can vary the broken-ness I am seeing by changing the EXTINT1 line, but I cant seem to find anything that makes the reads stable. I thought maybe only generating interrupts while the bus was not active in any way, or limiting the interrupt frequency, or limiting the high time for the interrupt would sort it... but it just makes it broken in different ways.

 

I really dont get it. There is NO guarding code or anything in the CD_ptr code... it just looks like this:

ptr:
move.l PTRLOC,a0 ; Get address of data
move.l a0,a1 ; Get address of error
add.l #8,a1
move.l (a0),a0 ; Get current address
move.l (a1),a1 ; Get error address
rts

And there is nothing touching the GPU, other than to setup the streaming code location and ISR jumps. Eurgh. Hopefully it will come to me while I sleep....

[GroovyBee]

Is your memory move instruction setting A1 high to get the MSW first and then A1 low for the LSW? Some 68K instructions do it LSW first and then MSW which the GPU latching RAM scheme won't like.