SCPCD

Top Delire !

Un seul mot : GENIAL !!!!

 

Ca va vraiment permettre de faire du debuggage hyper facilement !

 

Je n'arrive même pas a imaginé ce que l'on pourrait réaliser pour la Jag avec tout nos projets....

 

 

 

C'est l'anée du GROS changement !

Il y a aussi la possibilité de faire des générateurs de niveaux aléatoires ?

 

Après ca depend du type du jeu....

Bon boulot !





euh...

Si, juste un petit peu quand même....

Il faut faire attention, je ne sais plus trop mais je crois qu'il y a des bugs dans le blitter pour le clipping dans certains cas.

Pour ce qui est des docs pour les processeurs, il existe en fait qu'une qui les regroupes tous (sauf le 68000) et en pdf. Mais le hic c'est qu'elle est mal fichu et donc on passe le plus clair de son temps a lire, relire, rerelire ... toute la doc pour trouver ce que l'on cherche. Et généralement, il faut aussi faire des tests a la main car il est écrit un truc du genre : 'avec ce processeur on peut faire ca, et ca et puis ca' mais aucune explication sur la configuration a faire....

Le seul processeur qui serait capable de faire ca, je pense, serais le GPU car lui, il a un accés 32bits voir 64 dans la RAM (utilisation des instructions loadp et storep) et il a un accés direct au blitter (donc sans utilisation de la bande passante de la RAM) qui lui posséde des fonctionnalités pour la 3D (Zbuffer et aussi je crois du remplissage) mais je n'ai jamais fait de 3D polygoné donc je ne sais pas trop comment il faut faire pour utiliser le blitter pour le faire.

 

 

 

Pour l'histoire des float, il faut faire une petite librairie.

 

Mais il y a une seul instruction GPU/DSP : MTOI qui permet d'extraire la 'mantissa' d'un float signé IEEE 32 bits et de le convertir en entier signé.

OOUUUUAAAA !!!!

 

Trop nickel !!!

 

 

 

T'es TROP FORT !!

 

 

 

Y a pas à dire, c'est l'année où tout va changer pour la Jaguar !!

 

 

 

Pour l'instant j'ai pas d'idée sur ce que l'on peut rajouter...

 

 

J'ai oublié ce point.....

Et avec les splines ?

 

 

 

Comme sa on prend des points particuliers des objets et la spline represente l'approximation de la forme de l'objet.

 

Il suffit alors de verifier si il y a intersection des splines des objets et le tours est joué.

 

 

 

Il faut prendre les splines les plus simples : les splines cubiques normalisées relaxées qui ce calcul facilement. On les calcul au chargement par exemple et voila !

 

 

 

ensuite, il suffit de faire une premiere verification pour pouvoir choisir les bonnes parties des splines a tester et ensuite on verifi si il y a intersection ou non.

 

 

 

L'avantage c'est qu'avec tous les types de prog 2D sa fonctionne.

Hi !

 

 

 

I have found informations about those lines in reading CDBOOT code and Jerry netlists files :

 

 

 

 

When the i2sen bit (bit 0 of SMODE) is set to 0, the SCK and WS lines are inputs. (see jerry I2S netlist)

 

When Jerry is used to received data from the CD player, SMODE is initialised to $14 (see asamp code).

 

So, with this settings, i2sen is cleared and the SCK and WS lines from Butch are used for the 16bits input mode (left/right).

 

 

Is it possible to enable/disable those lines with the use of butch registers :

 

 

; Butch's hardware registers

 

;

 

;

 

BUTCH equ $DFFF00 ;base of Butch=interrupt control register, R/W

 

;

 

; When written (Long):

 

;

 

 

 

; bit0 - set to enable interrupts

 

 

-> this bit enable/disable EINT0 output

 

[code]

 

; bit1 - enable CD data FIFO half full interrupt

 

; bit2 - enable CD subcode frame-time interrupt (@ 2x spped = 7ms.)

 

; bit3 - enable pre-set subcode time-match found interrupt

 

; bit4 - CD module command transmit buffer empty interrupt

 

; bit5 - CD module command receive buffer full

 

; bit6 - CIRC failure interrupt

 

;

 

; bit7-31 reserved, set to 0

 

;

 

;

 

; When read (Long):

 

;

 

; bit0-8 reserved

 

;

 

; bit9 - CD data FIFO half-full flag pending

 

; bit10 - Frame pending

 

; bit11 - Subcode data pending

 

; bit12 - Command to CD drive pending (trans buffer empty if 1)

 

; bit13 - Response from CD drive pending (rec buffer full if 1)

 

; bit14 - CD uncorrectable data error pending

 

;

 

;

 

; Offsets from BUTCH

 

;

 

DSCNTRL equ 4 ; DSA control register, R/W

 

DS_DATA equ $A ; DSA TX/RX data, R/W

 

;

 

;

 

;

 

I2CNTRL equ $10 ; i2s bus control register, R/W

 

;

 

; When read:

 

;

 

; b0 - I2S data from drive is ON if 1

 

; b1 - I2S path to Jerry is ON if 1

 

 

-> it seems that the bit1 enable/disable the I2S output of butch to the I2S input of Jerry.

 

[code]

 

; b2 - reserved

 

; b3 - host bus width is 16 if 1, else 32

 

; b4 - FIFO state is not empty if 1

 

;

 

;

 

;

 

;

 

SBCNTRL equ $14 ; CD subcode control register, R/W

 

SUBDATA equ $18 ; Subcode data register A

 

SUBDATB equ $1C ; Subcode data register B

 

SB_TIME equ $20 ; Subcode time and compare enable (D24)

 

FIFODAT equ $24 ; i2s FIFO data

 

I2SDAT2 equ $28 ; i2s FIFO data (old)

 

 

And I think that, as it is mentioned in your previous post, those lines are tristates when are disable.

 

 

 

 

 

 

Is it scheduled to have a BJL compatible uploader to upload datas to the CF or just to the DRAM because all ATARI have not CF reader and the uploader could give the possibility to add levels to an encrypt CF for example.

 

 

 

Regards,

 

SCPCD.

Tu peux utiliser les objets GPU dans la liste des objets a des endroits strategiques (qui lancent une interruptions au GPU) comme sa tu peux deja savoir un peu plus précisement ce qui a dans la Line Buffer...

 

En plus, dans la Technical Reference Manual de Tom & Jerry, dans la section LBUFF ils disent qu'il y a une zone adressable en 32bits pour justement que le GPU puisse aider le pross d'objet a faire du traitement sur l'affichage.

 

De plus, c'est du double buffer donc un sur la ligne en cours et l'autre sur la ligne precedente : comme sa, tu peux toujours verifier sur la ligne precedente alors que l'OP travaille sur la ligne suivante.

 

 

 

Mais il faut donc faire un code vraiment hyper rapide comme tu dis

Hi !

 

 

 

Thanks for your help.

 

I hope that we will have more informations about those lines.

 

It will be great if we could chose between CF serial data or the CD serial data when the CF reader will be connect to the CD player

 

 

 

Regards,

 

 

 

SCPCD.

Sinon, il y a ptet moyen (mais compliqué) en couplant le GPU avec le OP (verification de ce qu'il fait dans la Line Buffer a des moments stratégiques ?)

Hi !

 

 

 

Yes, everything (normaly) will be finished for christmas. (including routines, and samples codes)

 

 

 

I'm not a member of UGD so if you could ask these questions it could help me.

 

 

 

Thanks,

 

SCPCD.

Hi !

 

 

 

The feature to send data directly to the DSP will be available.

 

I have questions :

 

- the WS signal from Jerry, Is it controled by Jerry when Jerry send/received data from the CD player ? or by the CD player ?

 

I know that the SCK signal is controled by the CD player (see in audio sample source)

 

- Is the CD player tristates the EINT0, SCK, WS, RXD when the CD player is not used (cartridge in his socket) ?

 

Could these signals tristates in software separately ?

 

 

 

To increase the bandwidth of the CF, I'm making a CF controller directly in the FPGA (which replace the actual CPLD) so I could use it as a 32bits cache to send data at the theorically speed of 4Mo/s of the bandwidth of the Expansion connector.

 

Instead of controlled by the Jag as actually and the actual 16bit connection.

 

 

 

For the protection, I will make the encryption/unlock by the FPGA so nobody could

 

retrieve the encryption process.

 

 

 

I think that the CF will be 100% finished for Christmas !!! .

 

 

 

Regards,

 

SCPCD.

Ptet avec le blitter ?

 

En faisant un mask et en lui faisant tester pixel par pixel ?

Hi !

 

 

 

I'm making modifications to the CF adaptator to made a bigger bandwidth.

 

So I could tell you that with these modifications the CD is the past !

 

 

 

I couldn't say why now but more informations will arrive when these works.

 

 

 

I couldn't say the real price of the prototype because of these modifications, but I could say that the price will be very lower than a CD player.

 

 

 

Regards,

 

 

 

SCPCD.

Yes, this features will be possible with the Flash.

Si tu trouves (et comprend) les routines de transfert du prog que je t'ai conseillé, sa pourrait servir pour faire une version de ce prog pour Windaube.

essay l'adresse mail qui a sur ce site :

 

http://www.monlynx.de/jaguar/

 

(remplace (at) par @)

Thanks for your encouragement and for your help.

 

 

 

Regards.

The CF card as an integreted protected system which use an password of 32 bytes.

If you don't give the good password, it's impossible to read data after each power on.

We will made also an encryption algorithm to generate the password and to crypt datas.





I think because CF is a Flash system. So you have about 100000 times write cycle for very best card (bad card is 10000) and so the CF is better for past used as data read or stockage.

With 2 weeks reads/writes tests we have no reads/writes failures.

Maybe also because we use cash on the board for each directions to safe the correct timing.

Est-ce que tu as fini le TGA : car j'ai quelques images TGA qui ne passe pas...

Welcome to all new english members !!!