Cette catégorie traite de développements récents destinés à nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!
__sam__ a écrit : ↑01 nov. 2019 20:18
Alors il y a un truc que je n'ai pas pigé. Ils affirment être cycle-accurate, mais vont 10x plus vite que l'original. Ca colle pas. Par contre cela donne la même vitesse de transfert que l'amiga, ce qui serait cohérent (c'est le même principe pour les deux tout compte fait.)
Non le 25ko/sec c'est un gars qui a modifié le firmware Pi1541 pour ses propres besoins en démo.
il dit dans le lien:
I decided to make my own Pi1541.
Ce qui démontre qu'une fois que l'interface matérielle est réalisée, les gens peuvent modifier simplement le firmware.
Pourquoi ne pas utiliser le matériel qui existe déjà et reste fonctionnel, les liaisons modems RTC passant pas trop mal par internet de nos jours.
je n'ai pas l'interface teletel et en plus il faut que d'autres personnes la possèdent.
ce qui est plus facile avec une interface universelle, quelqu'un qui la possède pour faire du SDDRIVE peut l'utiliser pour du teletel simplement en lançant un soft.
@Totor, je suis entièrement d'accord avec _sam_ sur la réactivité de l'Arduino comparé à la RPI.
Si tu veux utiliser le Linux de la RPI, alors oublie la RPI. Linux n'est pas temps réel. Il y a aura des fortes latences aux niveaux des interruptions et j'ai bien compris que le 6809 contrairement au Z80 n'a pas un signal qui lui permet de le faire patienter jusqu'à ce que on lui présente la donnée qu'il veut.
Même avec l'Arduino, je crains que la gestion par interruption ne suffise pas. J'imagine que Daniel utilise une boucle qu'il inspecte les signaux du 6809 et qui n'en sort qu'une fois la demande établie et que la donnée était préparée à l'avance pour être posté. Or il faut maintenir cette donnée pendant un certain temps. Et comme il n'y a pas de rétroaction, il faut établir avec précision le timing. Faire ça avec le RPI, ce n'est pas possible sauf à faire du bare metal et donc là plus de Linux.
totor a écrit : ↑01 nov. 2019 20:23
Ce qui démontre qu'une fois que l'interface matérielle est réalisée, les gens peuvent modifier simplement le firmware.
Oui sauf qu'il me semble que le Pi1541 n'utilise pas Linux et est bare metal.
Par ailleurs, il existe un projet qui implique une cartouche pour la Vectrex contenant un RPI Zero dans le but affiché de faire tourner un Mame adapté (Vectrex ou Atari) ou d'autre programme qui dessine vectoriellement : c'est la RPI qui pilote directement les composants du Vectrex.
Au départ, ils utilisaient Linux mais le dessin n'était pas stable. En passant au bare metal, ça s'est considérablement amélioré.
EDIT: le projet s'appelle PiTrex.
Dernière modification par hlide le 01 nov. 2019 23:29, modifié 1 fois.
Oui sauf qu'il me semble que le Pi1541 n'utilise pas Linux et est bare metal.
tu as entièrement raison, en poussant les recherches il n'y a pas l'OS entier.
Enfin tu dis qu'il n'y a pas Linux il y a quand même le kernel linux qui permet de booter.
Donc le RPI est pareil que l'Arduino sauf pour la RAM, le RPI permet de pré charger en RAM le contenu de la carte SD, ce que ne permet pas de faire l'Arduino. On est d'accord là dessus?
Cela dépend de l'Arduino
En fait, Arduino est une plateforme logicielle compatible avec différents matériels, de l'AVR 8 bits à l'ARM 32 bits avec une grande variété de périphériques, dont la RAM.
La quantité de RAM disponible est donc très variable.
Patrick a écrit : ↑01 nov. 2019 23:04
Cela dépend de l'Arduino
En fait, Arduino est une plateforme logicielle compatible avec différents matériels, de l'AVR 8 bits à l'ARM 32 bits avec une grande variété de périphériques, dont la RAM.
La quantité de RAM disponible est donc très variable.
Je trouve ces quantités de SRAM en Ko:
Carte SRAM EEPROM Flash
Uno 2 1 32 (0.5)
Leonardo 2.5 1 32 (4)
Mega 2560 8 4 256 (8)
DUE 96 1 512 (0)
Mini 2 1 32 (2)
Micro 2.5 1 32 (4)
Donc l'Ardunio DUE comprend 96 Ko de RAM, on ne peut mettre pas y mettre une face de disquette de 320ko.
Le RPI de base comprend 1Go de RAM.
totor a écrit : ↑01 nov. 2019 22:52
Enfin tu dis qu'il n'y a pas Linux il y a quand même le kernel linux qui permet de booter.
Je ne comprends pas. "bare metal" signifie qu'il n'y a pas d'OS, que l'application est un firmware et qu'il gère directement le hardware.
Ça a une implication très forte : il n'est pas possible de faire tourner plusieurs applications. En regardant le source, je ne vois rien qui a un trait à linux ou même à posix.
totor a écrit : ↑01 nov. 2019 22:52
Donc le RPI est pareil que l'Arduino sauf pour la RAM, le RPI permet de pré charger en RAM le contenu de la carte SD, ce que ne permet pas de faire l'Arduino. On est d'accord là dessus?
Pareil s'il est "bare metal". Arduino est toujours un "bare metal".
Si tu peux te contenter d'un "bare metal", certes.
L'utilisation RPI2/3 pour le Pi1541 est justifié par le fait que ni le RPIZ ni les Arduinos avaient la puissance pour gérer à la fois l'émulation de la partie IEC et de la partie CPU (6502, pour les démos qui l'exploite dans le lecteur).
This interface don't use Linux kernel, but is bare metal, so everything it is done from scratch starting without any O.S. support. All the code is in kernel.img in only 240kb, it holds also the Amiga setup software (and sounds and graphics). So it is only needed 7 second to power up the system and start the emulation. This choise was because the floppy disk interface needs real time response and Linux can't manage that without adding external hardware. Since this interface manages more than 1 drive (it can manage 4) and it is suppose the disk bus is shared eventually with external drives, several signals (as CHNG) need to be managed by software in real time (answers not after than 400 ns) and only a bare metal system, with optimized code, can manage that. You can find more info on timings here (example for Amiga floppy) and here (for generic PC floppy).
During SD operations like read or write an adf/adz disk image, the system can't manage the bus requests. In this case the full emulation is stopped and the system appears like without disks inserted (all the disks will be 'ejected'): in this way the hardware can directly manage the requests without generate errors or blocks. In this way the RPI is free to do something else. After these operations the emulation will start again and all the disks will be re-inserted in drives.
In order to manage the DKRD line (disk read) and have a full stream of data with exact timing (2us per cell) sent without any interruptions,holes or delays, the software uses the SPI interface in continuous mode: all the MFM data goes through the SDO pin while other SPI pins are not used and they are configured and treated as standard GPIO. In order to have a better shape for the DKRD line, the signal should stay low for less than 2 us (400ns should be good) so the signal was 'reshaped' by the resistor R15, the capacitor C3 and the diode D6, improving the compatibility with the Amiga software (really only few games are sensible to this timing). For the data in input, the DKWD line, indeed it was not possible to use SDI because without a clock or a PLL, errors will appear soon. The approach in this case was to take the times between the 0 cells (on the falling edge) and use these to obtain the data stream. So if between 2 zeros there are 4 us, the system recognizes a '10' sequence (the line is inverted), if there are 6 us the system recognizes a '100' sequence and if there are 8 us the system recognize '1000', as it's the MFM coding. To know more about MFM coding anyway and other useful stuff here there are lot of infos.
on trouve même un tutoriel complet sur la programmation bare metal des RPI :
Totor, tu ne regardes que les cartes Arduino "Arduino".
La carte ST Nucleo F767ZI par exemple dispose de 512 ko de RAM et 2 Mo de Flash et fonctionne à une fréquence de 216 MHz.
Les carte ST Nucleo H7 ont des caractéristiques encore supérieures.
Pour recentrer le débat sur le sujet, voici la description du cycle de lecture d'un bit avec SDDRIVE :
- Au milieu du cycle (500 nanosecondes) le signal E monte et fait descendre le signal d'horloge SCK
- Dans les nanosecondes qui suivent, la carte SD présente le bit sur sa sortie MISO
- Dans la deuxième moitié du cycle le 6809 lit le bit
- En fin de cycle (1000 nanosecondes) le signal E descend et le signal d'horloge SCK remonte
Avec ARDDRIVE c'est exactement pareil, sauf qu'il n'y a pas un bit, mais huit, et que la carte SD est remplacée par un dispositif extérieur. Je ne sais pas exactement de combien de nanosecondes dispose ce dispositif pour présenter l'octet sur le bus pour que le 6809 puisse le lire sans erreur. C'est forcément très court.
Il faut bien comprendre qu'il n'est pas possible, pour le 6809, de lire l'octet et de générer le signal d'horloge en moins de dix cycles. Il faut au minimum quatre cycles pour lire l'octet et huit cycles pour faire descendre et monter le signal d'horloge, c'est beaucoup trop long pour obtenir un débit de plus de 100000 octets par seconde. Le signal d'horloge doit obligatoirement être généré par le matériel. C'est la principale innovation de SDDRIVE par rapport à son prédécesseur CS91-280.
Il faut aussi comprendre qu'après l'envoi du signal le dispositif extérieur n'a pas une milliseconde de délai, ni une microseconde. Il a au plus quelques nanosecondes. La carte SD sait le faire. Le dispositif extérieur doit faire aussi bien que la carte SD. Avec l'Arduino c'est peut-être possible, mais j'ai un doute. Avec d'autres processeurs plus rapides on doit pouvoir y arriver. Avec Linux sûrement pas.
J'ai bien conscience des problèmes de timings, et c'est pourquoi j'insiste depuis le début sur une solution sans processeur côté périphérique, câblée ou à base de périphérique dédié, bien que cela nécessite que le format de volume soit géré côté Thomson, c'est gênant pour du streaming, mais accessoire pour de l'utilisation en mode "fichiers".
Dans le 8051, le périphérique de port série peut générer un signal d'horloge sur une broche supplémentaire, remplir et vider ses buffers pendant que les autres sont lus (deux paires sont utilisées alternativement en interne), générer une interruption quand les données sont prêtes, n'y a t'il pas un périphérique externe proposant ces fonctions pour le 8085? le 8250, le 8251 peut-être? Et côté "Motorola", en 68xx, il y a les ACIAs, ne sont-ils pas équivalents en terme de fonctionnalités?
Je ne parviens encore pas à lire les documents DJVU, donc, j'ai juste jeté un œil au Schéma MO5 sur ton site, c'est bien le port extension mémoire qui dispose de 12 lignes d'adresses, 8 de données, un signal horloge à 16MHz et quelques broches comme R/W, /E?
Avec le signal d'horloge dispo, nul besoin de faire générer le signal par le processeur, l'idée des registres à décalage aurait ceci d'intéressant d'un point de vue optimisation logicielle, que l'on lit le buffer d'entrée dans la même instruction que l'on écrit celui de sortie.
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
