[MZ-SD2CMT] GitHub link

hlide
Posts: 159
Joined: Thu Jan 25, 2018 9:31 pm

Re: [SD2MZCMT] GitHub link

Post by hlide » Fri Jun 01, 2018 9:39 am

FR:

Attention pour MiSTer, il s'agit de faire une recréation des MZ avec la possibilité d'avoir en option les améliorations tel que le PGC par exemple - qui soit le plus proche des vrais en terme de hardware que ceux des émulateurs par voie logicielle. On verra si j'arrive à relever le défi.

Ouah ! il est beau le WAv2MZF, on peut paramétrer les durées des créneaux sur la partie graphique ?

Concernant MZF2WAV (procédé inverse, en ligne de commande, dont mon MZF2LEP est une version dérivée), j'ai noté quelques bugs (enfin c'est difficile à dire...). Par exemple, il a jouté un long pulse à la fin de je ne sais plus quoi exactement dans l'entête qui faisait que je ne pouvais pas lire le header puis le data d'un seul trait sans relancer une deuxième relecture. Dernièremement, je retrouve ce comportement avec le MZ-80 K pour lire un misérable programme (RAMTEST) qui doit faire moins de 400 octets en dépit du bug que j'avais corrigé pour le MZ-700 donc j'ai pas mal de doute. Je pense qu'il va falloir que je récupère tous les sources des monitors de chaque MZ pour vérfier qu'il n'y pas un pulse de moin ou de trop...

Idéalement, je souhaiterais placer un petit circuit entre le connecteur tape de la carte-mère et le connecteur du lecteur de cassette dont le but et de pouvoir "sélectionner" le dispositif de lecture. Si on appuis sur PLAY/RECORD le lecteur de cassette, l'Arduino passe la main au lecteur pour la transmission des signaux (bypass mode). Si on lance PLAY depuis l'Ardinuo alors c'est l'Arduino qui communique à la place du lecteur. Je n'ai pas encore très bien en tête comment faire ça proprement - tu aurais une idée à me proposer ?

Et enfin je voudrais la possibilité de se servir de ces signaux dans un mode ultrafast qui pourrait servir à lire ou écrire des MZF - pour cela, il faut que le code de lecture/écriture soit intégré quelque part - dans la ROM? créer un OS comme system7 qui prendre en charge ce protocole?

J'ai des NVRAM que je verrais bien utiliser pour remplacer la ROM et la CGROM avec en tête de pouvoir sélectionner la ROM d'origine européènne/japonaise ou customisée et pareil pour la CGROM. Mais il me faudra certainement des circuits avec la possibilité de "switcher" sur les "ROM" voulues. Un peu de réflexion donc...

Bref, j'ai plein d'idée mais par super bien armée côté électronique, si l'électronqiue n'est pas ton talon d'achille, peut-être que l'on pourrait se mettre à deux pour développer des projets. T'en penses quoi ?

EN:

Warning regarding MiSTer, it is a matter of making a recreation of the MZs with the ability to have the optional improvements such as the PGC - which is the closest to the real ones in terms of hardware than those of the software emulators. We'll see if I can meet the challenge.

Wow! WAv2MZF is beautiful the, one can parameterize the durations of the slots on the graphics part?

Regarding MZF2WAV (reverse method, command line, my MZF2LEP is a derivative version), I noticed some bugs (well it's hard to say ...). For example, it added a long pulse at the end of something I do not remember what was exactly in the header that I could not read the header and the data in one go without relaunching a second replay. Lastly, I find this same behavior with the MZ-80 K to read a miserable program (RAMTEST) that must be less than 400 bytes despite the bug that I corrected for the MZ-700 so I have a lot of doubts. I think that I will have to get all the sources of the monitors of each MZ to make sure there is not a pulse of less or too much...

Ideally, I would like to place a small circuit between the tape connector of the motherboard and the connector of the cassette player, the purpose of which is to be able to "select" the reading device. If you press PLAY / RECORD on the tape deck, the Arduino hands over to the player for signal transmission (bypass mode). If you start PLAY from the Arduinuo then the Arduino communicates instead of the player. I do not have very much in mind how to do it properly - do you have an idea to propose me?

And finally I would like the possibility to use these signals in an ultrafast mode that could be used to read or write MZF - for that, it is necessary that the code of read/write is implemented somewhere - in the ROM? to create an OS like system7 that support this protocol?

I have NVRAM that I would use to replace the ROM and the CGROM with the head to select the ROM of European / Japanese or customized and the same for the CGROM. But I will certainly need circuits with the ability to "switch" on the "ROM" wanted. A bit of reflection so ...

In short, I have plenty of ideas but I am not super well armed on the electronic side. If the electronics is not your Achilles heel, maybe we could get together to develop projects. What do you think?

User avatar
Pacman
Posts: 46
Joined: Mon Feb 05, 2018 2:59 pm

Re: [SD2MZCMT] GitHub link

Post by Pacman » Sat Jun 02, 2018 6:48 am

FR :
Oui j'avais bien compris l'intérêt du FPGA : recréer le circuit afin de simuler le matériel.
L'émulateur logiciel que je met au point, utilise déjà pas mal de techniques qui pourrait t'intéresser : Z80, 8255, 8253 (mais non complet encore), PCG700, SFD700

Pour WAV2MZF, on peut faire des profils paramétrables et tous les temps sont modifiables : temps haut, période et point de lecture pour chaque bit.
J'ai repris du site, les temps de références données pour 3 configurations types : MZ700, MZ800 et MZ80B.

Pour MZ2TAPE, la lecture sur un vrai sharp mz-700 fonctionne parfaitement : j'ai eu une erreur d'un bit a un moment donné, mais je l'ai corrigé. pour l'instant je n'ai pas encore développé les turbo x2, x3, ... mais ça viendra. Donc on lit comme autrefois, avec le même temps d'attente.. :(

J'ai aussi comme projet de créer une interface se branchant sur le bus du sharp. Et je viens de recevoir les connecteurs 50points (pratiquement introuvable) pour ça. Le projet avance : j'ai l'intention d'y connecter une EPROM pour pouvoir directement l'utiliser sous moniteur sur l'adresse $F000 car sur le moniteur 1Z-013A lorsqu'on utilise la commande F il va scruter cette adresse ($F000 = 0) et lance le programme sous forme d'un vecteur stocké en $F001 (C3 xx xx en langage machine).
L'électronique ne me fait pas peur (j'ai une formation de physicien appliqué) et je fabrique mes cartes avec une fraiseuse.

Pourquoi pas développer ensemble ce genre de projet, ce serait super interressant :D

PS : Il y a quelques anées j'avais fait une interface parallèle qui transférer déjà les données vers un PC...

EN:
Yes I had understood the interest of the FPGA: recreate the circuit to simulate the hardware.
The software emulator that I develop, already uses a lot of techniques that could interest you: Z80, 8255, 8253 (but not complete yet), PCG700, SFD700

For WAV2MZF, one can make parametrizable profiles and all times are modifiable: high time, period and reading point for each bit.
I took from the site, the reference times given for 3 typical configurations: MZ700, MZ800 and MZ80B.

For MZ2TAPE, reading on a real sharp mz-700 works perfectly: I had a bit error at one point, but I corrected it. for now I have not yet developed turbo x2, x3, ... but it will come. So we read as before, with the same waiting time .. :(

I also like project to create an interface plugging on the bus of sharp. And I just got the 50point connectors (practically not found) for that. The project is progressing: I intend to connect an EPROM to be able to use it directly under monitor on the address $ F000 because on the monitor 1Z-013A when using the command F it will scan this address ( $ F000 = 0) and runs the program as a vector stored in $ F001 (C3 xx xx in machine language).
The electronics do not scare me (I have an applied physicist training) and I make my cards with a milling machine.

Why not develop together this kind of project, it would be super interesting: D

PS: A few years ago I made a parallel interface that already transfer data to a PC ...
carte_parallele.jpg
Interface parallele

hlide
Posts: 159
Joined: Thu Jan 25, 2018 9:31 pm

Re: [SD2MZCMT] GitHub link

Post by hlide » Sat Jun 02, 2018 11:08 am

Pacman wrote:
Sat Jun 02, 2018 6:48 am
le moniteur 1Z-013A lorsqu'on utilise la commande F il va scruter cette adresse ($F000 = 0) et lance le programme sous forme d'un vecteur stocké en $F001 (C3 xx xx en langage machine).
Hummmm... laisse moi vérifier le code...

C'est plus complexe :
1) au démarage, si tu as appuié sur CTRL, il passe en DRAM $D000-FFFF, copie 5 octets à partir de l'adresse $FFF0 puis saute à cette adresse. La séquence ainsi copiée est :

Code: Select all

OUT (0Eh),A ; set DRAM $0000-0FFF
JP  0000h  
Donc au saute en début de RAM à $0000.
Ca peut-être intéressant pour laisser l'Arduino faire ceci par exemple :
- activer le RESET sur le Z80
- présenter deux requètes I/O $E0 et $E1 pour passer toutes les adresses en DRAM
- écrire dans la DRAM les programmes (un MONITOR d'origine, japonais ou personnalisé), le programme que l'on souhaite lancer à la vitesse éclaire, etc.
- libèrer le RESET.
Après ça, deux possibilités :
- le RESET remet le mapping mémoire par défaut : on revient donc sous le prompt du monitor en ROM, mais si on combine l'appui du bouton RESET à l'arrière de la machine et l'appui sur le bouton CTRL, on lancera alors ce que l'Arduino a transféré en RAM.
- le RESET ne remet pas le mapping mémoire par défaut : on exécute directement le code en RAM (mais là je vois des complications car il faudrait au moins repasser $D000-$FFFF en VRAM, I/O, ROM pour que le monitor en RAM continue de fonctionner correctement).

2) si CTRL n'était pas appuyé, l'invite s'affiche et fait BEEP. A ce moment là, il tente d'écrire $01 à l'adresse $E800 pour relire à cette adresse et vérifier si l'octet lu est $00. Si c'est le cas, il saute à cette adresse : c'est là que l'on trouve une extension du MONITOR pour gérer le QDD par exemple.
3) autrement le prompt apparaît et il faut appuyer sur F : il effectue le même test que pour l'adresse $E800 (le code est partagé en fait) pour savoir s'il doit sauter en $F000.

Donc, on le choix entre deux emplacements : $E800 (automatique) et $F000 (par l'appui sur 'F').
Pacman wrote:
Sat Jun 02, 2018 6:48 am
Pourquoi pas développer ensemble ce genre de projet, ce serait super interressant :D
Je ne demande que ça : la synergie des compétences. J'espère que tu n'es pas contre l'open source parce que je suis assez agacé de voir des projets concernant des ordinosaures (Commodore/Amiga en particulier) très intéressants mais purement mercantiles.

User avatar
Pacman
Posts: 46
Joined: Mon Feb 05, 2018 2:59 pm

Re: [SD2MZCMT] GitHub link

Post by Pacman » Sat Jun 02, 2018 8:31 pm

Entièrement d'accord sur le fonctionnement du moniteur.
L'idée de l'arduino prenant le contrôle est une super idée que l'on peut mettre en oeuvre assez facilement en définitive.

Pas de souci pour l'open source si on a au moins partage du code, distribution et modification possible par un tiers afin de faire évoluer le projet.

hlide
Posts: 159
Joined: Thu Jan 25, 2018 9:31 pm

Re: [SD2MZCMT] GitHub link

Post by hlide » Sat Jun 02, 2018 9:12 pm

Si le principe du "Pull Request" rebute, il est possible de créer une organization sur GitHub, par exemple, les "SHARPENTIERS" (souvenir souvenir). D'y créer les projets, d'inviter les développeurs pouvant accéder à ces projets via l'organisation en tant que membres de confiance et de les modifier sans passer par les "pull requests". Ces projets seront publiques. Si un tiers veut cloner, il pourra le faire et modifier à sa convenance - s'il veut contribuer, il pourra faire un pull request qui permettra aux membres de l'organisation d'accepter ou de refuser après revus. Après, s'il est un contributeur sérieux et de confiance, il pourrait intégrer comme membre. A mon lieu de travail, on travaille toujours par "pull request" parce que ça permet de faire des revues de paires avant d'accepter ou demander des corrections ou très rarement de rejeter.

Pour exemple, j'avais créé cette organisation psce4all où il y a deux membres (dont moi) qui peuvent archiver directement. Ca ne devrait pas poser de problème pour toi si on procède ainsi ?

hlide
Posts: 159
Joined: Thu Jan 25, 2018 9:31 pm

Re: [SD2MZCMT] GitHub link

Post by hlide » Sun Jun 03, 2018 7:45 pm

Back to the topic.

I decided to reverse-engineer the monitor source to understand some weird behaviors I had even with legacy SHARP PWM system.

In fact, I saw you only need to read 100 short pulses for a GAP preceding a TAPEMARK. But if I do so, it doesn't work: I need to play the legacy file thrice to be able to run. So I gradually increase that number of short pulses until I reach 4000 and it works. Ok, I have 21 cycles for a short pulses and WAV resolution tells me it is above 2s - wait! let's reread that MONITOR MOTOR code: there is an active loop 255 x 7ms -> 1,7s!

So when calling MONITOR MOTOR, you must wait for 1,7s until you can emit those GAPs of 100 short pulses!

Now, suppose you are doing turbo x4, you need more than 4000 short pulses to be able to pass that uncompressible 1,7s!

In fact, there is 3,4s that you cannot compress whatever the speed. So I must handle those delay by pausing Arduino transmission for 1,7s after signal MOTOR is toggled to 1, which should work for any speed.

Because I don't want to struggle too much, I decided the pause would be 2s and the GAP would be 128 short pulses.

User avatar
Pacman
Posts: 46
Joined: Mon Feb 05, 2018 2:59 pm

Re: [SD2MZCMT] GitHub link

Post by Pacman » Mon Jun 04, 2018 7:30 pm

I did the same thing on mz2tape, 2s of wait + 100 bits of GAP, for the header and the program. ;)

ps: No problem for github ... :D

sharpmz
Posts: 19
Joined: Wed Feb 07, 2018 4:41 pm

Re: [SD2MZCMT] GitHub link

Post by sharpmz » Wed Jun 06, 2018 6:46 am

hlide wrote:
Sun Jun 03, 2018 7:45 pm
In fact, I saw you only need to read 100 short pulses for a GAP preceding a TAPEMARK.
Same as the MZ monitor does:
A GAP contains up to 22,000 short pulses but the monitor reads and counts only the first 100 pulses ( see the subroutine GAPCK at location $0FE2 ). The remainig pulses are not counted but skipped.

sharpmz
Posts: 19
Joined: Wed Feb 07, 2018 4:41 pm

Re: [SD2MZCMT] GitHub link

Post by sharpmz » Wed Jun 06, 2018 6:56 am

hlide wrote:
Sun Jun 03, 2018 7:45 pm

So when calling MONITOR MOTOR, you must wait for 1,7s until you can emit those GAPs of 100 short pulses!
My idea
Why not eleminating this? Put the monitor into the RAM, modify it and run it (by a tiny program).

hlide
Posts: 159
Joined: Thu Jan 25, 2018 9:31 pm

Re: [SD2MZCMT] GitHub link

Post by hlide » Wed Jun 06, 2018 8:31 am

sharpmz wrote:
Wed Jun 06, 2018 6:56 am
hlide wrote:
Sun Jun 03, 2018 7:45 pm

So when calling MONITOR MOTOR, you must wait for 1,7s until you can emit those GAPs of 100 short pulses!
My idea
Why not eleminating this? Put the monitor into the RAM, modify it and run it (by a tiny program).
yes, I already have it in mind that I can patch it to reduce to the minimum but only for the turbo mode because the turbo loader is loaded in normal speed then when launched it copies the monitor into the ram in the same address then patches the delay of the read point. So I can also patch the MOTOR call. I think reading the turbo loader was taking 7s as the minimum (2s+0.5s header, 2s+0.5s loader, 2s + N s real data). So you could say, you cannot compress those 4s because the patch is done after launching turbo loader. The turbo loader with then call RDDA which should be able to read this 100-unit GAP without waiting for 2s.

So in the end, I'm just saving 2s.

Supposedly I reintroduce a special turboloader which does almost the same but returns to the prompt without getting back the MONITOR ROM, so when you press L, it can load a binary the necessary time minus 4s (2s header + 2s data). But if I made the maths, you still gain nothing because in total there is always 5s. So you need to patch the MONITOR ROM to remove those 2s.

Post Reply