[MZ-SD2CMT] GitHub link
Re: [MZ-SD2CMT] GitHub link
EN:
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.
FR:
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.
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.
FR:
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.
Re: [MZ-SD2CMT] GitHub link
I added display markers in the MZ code to check the progress and I checked the signal on my DSO oscilloscope and the signal is really bad. Even at 2500 us, some bits are missing.
Re: [MZ-SD2CMT] GitHub link
What a lot of hassle! The good news is I managed to make that quick transfer. I was so focused on the curve of the SENSE signal that I didn't try to check MOTOR's signal. The latter finally responds well to the change of the SENSE signal and offers a square signal. I don't count the hours spent looking for what was blocking synchronization in the loader or transmitter - it's even worse than playing with mutex deadlocks.
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:
Where I am rather happy is that this fast transfer is done in the state machine and benefits from the update of the progress bar as well as normal loading.
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.
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.
Re: [MZ-SD2CMT] GitHub link
Since WAV and MZF files are the most used file for the MZs, I'm thinking to deprecate LEP files. I didn't try WAV file because I knew Arduino was not able to output 44.1KHz WAV file - well, that's true if you try to set a pin for each 44.1KHz tick. I realize that with 1200 baud or even 2400 baud, it may not be unrealistic to read a WAV file by counting the low signal period and the high signal period to output them as one pulse. Reading words until a period is reached and when both low and high periods are reached, just fire a one-shot pulse. The elapsed time between two pulses doesn't matter since only the pulse period needs to be accurate.
Re: [MZ-SD2CMT] GitHub link
Using faster I/O port access marginally improves the speed from 22s to 19s for ROLL SIDE -F-. Reading SD card, updating the GUI has no real impact (still 19s with a direct loop and without them). It also shows that the quick transfer is taking 13,2s. Turbo mode for MZF file is not really useful.
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.
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.
Re: [MZ-SD2CMT] GitHub link
WAV files can be now played as the same way as the LEP files. To play them, they are some restrictions though:
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.
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.
Re: [MZ-SD2CMT] GitHub link
I finally fix the bug which prevents from a WAV file with a big size to be loaded safely. Now I can load a 45KByte game (F-RollSide) and run it with no issue. Man, 12 minutes to load it though.
Re: [MZ-SD2CMT] GitHub link
I had trouble getting the my Mega2560 to detect the SDcard, until I checked the Arduino documentation for SPI. It seems that the README file in
https://github.com/hlide/MZ-SD2CMT
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.
https://github.com/hlide/MZ-SD2CMT
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.
--
Torfinn
Torfinn
Re: [MZ-SD2CMT] GitHub link
Issue tab is now added to SHARPENTIERS/MZ-SD²CMT.
Re: [MZ-SD2CMT] GitHub link
Today I'm compiling (or trying to) mz-sd2cmt with Arduino IDE 1.8.7. But I'm getting errors:
and I don't understand why, because this is the same code that I successfully compiled a few days ago (ok, on another machine, and probably a different version of the Arduono IDE. I'll check when I get home tonight). Git repository info
I must be doing something wrong. any hints?
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
--
Torfinn
Torfinn