I have the same shape with a time in micro-second and not in milliseconds hence my astonishment of the graph obtained.
For information, I measured 22,4us of period for the MOTOR signal and half for the SENSE signal.
j'ai la même forme avec un temps en micro-seconde et non en millisecondes d'où mon étonnement du graphe obtenu.
Pour information, j'ai mesuré 22,4us de période pour le signal MOTOR et la moitié pour le signal SENSE.
Concretely, I ended up combining two ideas:
- use SENSE and WRITE for handshaking,
- retrieve a READ bit for each MOTOR edge change - not just for fall-edge or just for rising-edge.
Here is a picture:
Code: Select all
_________ CS _____/ \____ : Arduino changes SENSE value so MZ can retrieve the current bit _____ ____ PC4 \_________/ : MZ watches PC4 edge changes set by Arduino _ __ _____ __ ____ PC5 _><__*_____><__*____ : MZ retrieves PC5 (*) at each PC4 edge change set by Arduino _________ PC1 ________/ \_ : MZ acknowledges Arduino so the latter can send the next bit ________ _ DI \_________/ : Arduino watches DI edge changes so it can send the next bit
I tried with SIDEROLL-F- and AEGIA which are both 44544 bytes (without the 128 bytes header): total time rounding up to 22s. Let's say the normal loading of the fast loader is around 4s, so the quick transfer is about 18s with 148480 bytes/min or 19797 baud.
After succeeding a quick transfer, I tried without WRITE signal synchronization (using only READ and SENSE signal) to make the MZ loader code faster (fewer instructions in a loop). It also works but the best I got is 24s (after tuning) instead of 22s so I think it may be the Arduino that we need to make faster.
I'm keeping the WRITE signal for synchronization as it makes the fast loading portable to the MZ-80 K family.
LEP files are now back and can play. Turbo x4 is still unstable for a long program so I think the timings of pulses are probably too tight. Well, with the Ultra-fast mode, not a big deal to drop it.
WAV files may be the next task I will try. It is quite similar to LEP file but bigger in size.
1) no fancy compression,
2) only mono channel,
3) only 8-bit samples
On the other hand, it can handle any sample rate (the most standard being 44.1 KHz).
Nonetheless, there may be some bugs. I was able to a small program like RAMTEST in WAV file but wasn't able to load bigger files converted into WAV files.
has the MISO and MOSI pins swapped, so I created an issue for it: https://github.com/hlide/MZ-SD2CMT/issues/2
after fixing this, my Mega2560 talks nicely to the SD card.
I still need to connect it to my MZ-721.
Code: Select all
/home/tingo/doc/Sharp/projects-sharp/MZ-SD2CMT/Arduino/mz-sd2cmt/mz-sd2cmt.ino: In function 'void selectPressed()': mz-sd2cmt:788:25: error: 'playLEP' was not declared in this scope playLEP(); ^ mz-sd2cmt:790:13: error: 'playWAV' was not declared in this scope playWAV(); ^ mz-sd2cmt:792:25: error: 'playMZF' was not declared in this scope playMZF(); ^ exit status 1 'playLEP' was not declared in this scope
Code: Select all
tingo@kg-bsbox:/zs/tingo/doc/Sharp/projects-sharp/MZ-SD2CMT/Arduino$ git remote -v origin https://github.com/SHARPENTIERS/MZ-SD2CMT.git (fetch) origin https://github.com/SHARPENTIERS/MZ-SD2CMT.git (push) tingo@kg-bsbox:/zs/tingo/doc/Sharp/projects-sharp/MZ-SD2CMT/Arduino$ git rev-parse --short HEAD 312c46b