rs

Salut,
J ai fait ma commande de cartes chez aliexpress, le prix indiqué est de 1 dollar, ce qui signifie qu il faut envoyer les fichiers gerber a l usine indiquee, il y a un devis en retour avec un numéro de projet et le montant. Il suffit de commander en "nombre de dollars" correspondant. Il y a un linimum de 5 cartes. J en ai eu pour une cinquantaine d euros a 10 euros la carte, sinon sur le site de mysilicium pour le meme sujet, ils ont trouvé un fabricant chinois ou on commande directement sur le site a 2 euros la carte
https://jlcpcb.com/
, il y a aussi un minimum de 5 cartes. Il faudra eviter les EEproms Windbond, qui ont un comportement bizzarre, les 27c512 avec le hublot marchent tres bien.

Merci beaucoup pour ce lien. C'est vrai que les tarifs de JLCPCB sont impressionnant. Je vais me mettre à Kicad, car à ce tarif, ça ne vaut pas le coup de se priver.
Il faudra que je me dessine un boîtier (pour une impression en rouge et noir), mais je ne vais pas retourner chez moi avant au moins un mois, donc pas d'imprimante 3D pour le moment... Ça me laisse le temps de commander les composants et faire les soudures. Par contre, avec le coronavirus, toutes les commandes sont retardées !

J'ai trouvé tout le matériel, mais j'ai une question concernant le 74LS73A : j'ai cherché les datasheet du 74LS73A et du 74LS73, mais pour le 74LS73, je suis à priori renvoyé sur la même... Y a-t-il une particularité nécessaire avec cette lettre A ?
Pour les cartes SD, les petites capacités sont de plus en plus difficiles à trouver. Est-ce que quelqu'un a essayé de prendre une plus grosse carte SD et de la partitionner avec une première (ou unique) partition de moins de 2 Go ?

Le "A" indique que le verrouillage se fait au front montant de l horloge et non pas a son etat haut.
Les cartes SD haute capacité "HC" n'ont pas le même format de gestion des blocs,  tout mon code est basé sur l'adressage des mémoires jusqu a 2gigas. Sur internet on en trouve de 128Mo jusqu a 2Go pour 2,5 Euros, on en trouve dans les vieux portables. De préférence, prendre une marque connue, j ai jeté les 3 SD venant de Chine qui etaient mortes des le départ. Pour l adaptateur SD=>microSD, si on veut eviter les mauvaises connections sur PC, j utilise une clé USB avec la petite fente pour la microsd qui est tres efficace.

Tout est commandé. J'espère surtout que j'ai commandé les bons composants et que je n'aurai pas de mauvaise surprise : pas certain de recevoir un 74LS73A...
Il ne reste plus qu'à attendre quelques mois.

Ces composants sont un peu speciaux, l alim passe par les pattes du milieu. A par ca, le reste est standard.

Salut Kenneth,

Erebus marche au top pour de nombreux jeux, mais il y a quelques exceptions, et un Oricien sur Facebook vient de tomber sur une incompatibilité: le jeu Harrier Attack (version Atmos). Je ne sais pas si tu l'avais testé, mais en fait le chargement se fige sur la page de chargement du jeu, peut-être qu'une routine spéciale de chargement est utilisée dans ce jeu?

Effectivement, avec Oric Explorer, on peut voir que le fichier TAP contient 3 parties:
- un loader ("*") qui se charge de $281 à $2BF
- un premier bloc de code "HARRIER" qui se charge de $540 à $850, et qui contient vraisemblablement la page de titre affichée durant le chargement, et sans doute une routine spécifique de chargement
- un second bloc de code "HARRIER" qui se charge de $900 à $3392, qui doit contenir le code du jeu en lui-même

Je n'ai pas regardé plus avant, mais il semble vraiment probable qu'il y ait du chargement spécifique, car il y a d'autres jeux Multipart comme l'Aigle d'Or qui se chargent eux sans problème...

________________

EDIT: en extrayant le 3e bloc du fichier .TAP et en le sauvegardant comme fichier "HARRIER2.TAP", j'arrive à charger le jeu avec l'Erebus, on arrive directement à l'écran de sélection du niveau de difficulté après un bruit d'explosion et une phase d'initialisation un peu longue (au début j'ai cru que ça avait planté...)

NB: j'ai du faire l'extraction avec Oric Explorer version 1, car malheureusement il y  a pas mal de bugs dans la v2 d'Oric Explorer, notamment elle n'affiche pas ce 3e bloc de code du fichier .TAP, et plante lorsqu'on essaie de sauver les parties individuelles comme fichiers .TAP  

PS - je joins un ZIP avec les 3 parties du fichier .TAP original séparées en 3 fichiers .TAP. C'est donc le 3e (HARRIER2.TAP) qu'il faut copier sur la carte SD de l'Erebus pour pouvoir jouer au jeu.

Normalement le loader n'empiète pas sur les paramêtres d Erebus, je vais étudier Harrier.

J'ai regardé le code du 2e programme, celui de la présentation il y a ceci:

Un saut en $84D, c est un classique, le programme part du début et fait un saut tout a la fin pour verifier l'intégrité du morceau, si un pirate a essayé de lire le code en coupant le chrargement du magnétophone avant la fin.

En $84D on a un saut vers $6A4, le programme principal.

En $6A4 on a ca:

$06A4 LDA #$00
$06A6 LDX #$FF
$06A8 STA $00,X
$06AA DEX
$06AB BNE $06A8

En gros cela signifie que toute la page zero est effacée, donc toutes les valeurs stockées par Erebus pour la cartographie de la carte SD disparaissent, la recherche du bloc suivant échoue...

Bien joué Kenneth pour l'analyse du code !!!
Mais pourquoi diable effacer toute la page zéro ??!!
Et que fait le programme après, juste un appel à la routine CLOAD en ROM?

Du coup, si on patche simplement la zone $06A4-$06AB avec des NOPs, ça devrait marcher avec Erebus ?

Note: problème similaire pour le jeu Chess d'IJK, qui bloque à l'affichage de l'écran titre et ne charge pas le 2nd bloc du fichier .TAP... En désassemblant avec Oric Explorer le 1er bloc, je vois une routine de déplacement d'un bloc mémoire au tout début du code, suivi d'appels en ROM pour CLOAD et autres routines (configuration du VIA, réautorisation des IRQs, etc.):

Code:


$0500  AD 6A 02   LDA $026A
$0503  29 FE      AND #$FE  
$0505  8D 6A 02   STA $026A
$0508  A9 00      LDA #$00
$050A  85 80      STA $80
$050C  85 82      STA $82
$050E  A9 06      LDA #$06  
$0510  85 81      STA $81
$0512  A9 B8      LDA #$B8
$0514  85 83      STA $83
$0516  A0 00      LDY #$00
$0518  B1 80      LDA ($80),Y
$051A  91 82      STA ($82),Y
$051C  C8         INY           .  
$051D  D0 F9      BNE $0518
$051F  E6 81      INC $81
$0521  E6 83      INC $83
$0523  A5 83      LDA $83
$0525  C9 C0      CMP #$C0
$0527  D0 EF      BNE $0518
$0529  AD F9 FF   LDA $FFF9
$052C  C9 C4      CMP #$C4
$052E  D0 03      BNE $0533
$0530  20 E0 BF   JSR $BFE0
$0533  20 E0 B8   JSR $B8E0
.../...
$0DEC  20 CA E6   JSR $E6CA
$0DEF  20 A8 E4   JSR $E4A8
$0DF2  20 04 E8   JSR $E804
$0DF5  4C 03 05   JMP $0503


J'ai pas regardé en détail car il est tard mais en lisant vite fait j'ai l'impression qu'il recopie les données de  l'écran-titre sur la mémoire écran et sans doute un bout de code aussi qui est appelé et doit contenir une protection quelconque qui fait foirer le chargement d'Erebus ensuite (le JSR à $BFE0  ou $B8E0 selon le cas)

retroric a écrit:
Mais pourquoi diable effacer toute la page zéro ??!!

Pour les jeux entierement en langage machine, la page zero qui contient les parametres de la gestion de l'interpreteur Basic ne sert plus a rien, donc, beaucoup de place disponible pour les variables du jeu et cela permet des calculs plus rapides. En plus, au niveau protection, la reaffectation de la page zero rends impossible le retour a l interpreteur Basic. On pourrait mettre des NOP pour preserver la page zero mais il faudrait etudier le jeu tout entier pour savoir si toutes ces valeurs nulles en page zero vont servir pour le jeu plus tard. J aurais pu planquer mes variables dans la pile (page 1) mais Erebus a besoin de la page zero pour les calculs rapides, ce qui lui permet de charger un gros jeu dans un delai raisonnable.

Ah oui OK, effectivement is on scratche toute la page zéro le retour à l'interpréteur doit mal se mettre, notmament pour TXTPTR et autres variables ou vecteurs importants....

Sinon, le gars sur Facebook qui a découvert le pb de chargement avec Harrier Attack m'a aussi remonté le même problème avec Defence Force... Je pense qu'il doit du coup y avoir un paquet de jeux incompatibles avec Eerebus pour lesquels il faudrait refaire des versions spéciales des .TAP...

Pour les incompatibilites il y a les cas suivants:

Les jeux multipart qui entrent dans deux categories:
-Jeux avec en-tete de protection comme Harrier, excepté les jeux qui utilisent la routine ALC, Erebus accepte cette protection ex: jeux Loriciels.
-Jeux avec en-tete animée ex: DefenceForce: L animation suggere une prise en charge du signal du magnétophone et donc, une attente de chargement par le cordon audio.

Les jeux monoparts qui utiliseraient l adresse $3F3 pour les entrees sorties. Comme le 6522 est traditionellement adressé entre $300 et $30F, a mon avis tous les jeux monoparts ne touchent pas a cette adresse et sont compatibles Erebus, perso, je n en ai pas vu qui plantaient avec l interface.
On pourrait faire sauter toutes ces protections et sauvegarder tout les jeux protégés en monopart, le problême, c est le respect de la creation artistique pour les jeux qui ont une intro pour faire patienter comme l'animation de Defence Force, pour contourner le problème de Defence Force on peut le sauvegarder en dizaines de petits bouts et faire defiler les couleurs entre les cessions...mais bon j aime pas trop modifier ce qui est magnifique au départ

NB J ai essayé Chess et Chess II, ca a l air de fonctionner avec l'Erebus...

Hello !
Le calcul de checksum des jeux créés avec The Quill semble également incompatible avec Erebus.

Une petite modif du TAP règle le problème, mais pour ma culture/curiosité: est-ce que le code de chargement de Erebus simule le chargement de l'en-tête K7 comme les routines de la ROM ? (qui, sur ROM 1.1, charge cet en-tête en $2A7 en RAM)

kenneth a écrit:On pourrait faire sauter toutes ces protections et sauvegarder tout les jeux protégés en monopart, le problême, c est le respect de la creation artistique pour les jeux qui ont une intro pour faire patienter comme l'animation de Defence Force, pour contourner le problème de Defence Force on peut le sauvegarder en dizaines de petits bouts et faire defiler les couleurs entre les cessions...mais bon j aime pas trop modifier ce qui est magnifique au dépar

Je suis d'accord, il y a déjà souvent plusieurs versions de tap : correctes ou non, modifiées ou non. Poursuivre dans cette voie est bénéfique pour la mise à disposition des logiciels historiques à la portée de tous mais nécessite de bien référencer les différentes versions dans une base de données ce qui est un travail colossal.
Il y a un certain temps, j'avais commencé à mettre de coté tous les fichiers, et sur la base de lexique tosec + tap validation de simon + quelques commentaires, j'ai 3318 fichiers oric qui me servent à repérer des doubles quand j'en récupère de nouveaux. je suis loin d'avoir controlé tous mes fichiers.

Je crois que je vais me faire la main sur la base des livres que je suis en train de revoir (cf ceo.oric.org et discussion sur defence-force). On verra après comment on peut s'attaquer efficacement à une base de données de logiciels

Symoon a écrit:Hello !
Le calcul de checksum des jeux créés avec The Quill semble également incompatible avec Erebus.

Une petite modif du TAP règle le problème, mais pour ma culture/curiosité: est-ce que le code de chargement de Erebus simule le chargement de l'en-tête K7 comme les routines de la ROM ? (qui, sur ROM 1.1, charge cet en-tête en $2A7 en RAM)

L en-tete n est pas chargé, comme le jeu est choisi dans la liste au départ, il n y en a pas besoin, il est possible que certaines protections vont scruter cette zone pour verifier l'integrité du processus de chargement. Après, l'idee de depart était de charger des fichiers "non exotiques" en compatibilisant les fichiers ALC pour couvrir un max de jeux, l étude de toute les procédés de chargement aurait encore retardé la sortie du produit, je devais choisir entre un délai pas trop long avec une compatibitité plutot satisfaisante, et un projet complet long a realiser qui tomberait aux oubliettes pour cause de démotivation sénile....

Merci Kenneth.
Pas de critique envers les choix, c'est juste pour cerner le fonctionnement

Symoon a écrit:Merci Kenneth.
Pas de critique envers les choix, c'est juste pour cerner le fonctionnement

C'est ce que j avais compris
Du coup, il va falloir que l'écrive "L Erebus décortiqué", pour que chacun profite de la bête au maximum, et du bout de code que j ai laissé dans l'Eprom qui permet de lire n'importe quel endroit de la carte sd...

La vidéo de The Retro Shack, à 9mn25s une présentation du bidule, la vidéo est très bien faite.

Issalig de Retrowiki nous propose un boitier imprimé en 3D.