Wednesday, 22 March 2017

TZXMaple Progress.

It's been a while since I've published anything on my progress on converting things to the Maple Mini so I thought I'd keep you up to date.

I have converted TZXDuino to the Maple Mini and it is working but not properly. For some reason, even though it is using the same values as the Nano the frequency of the output is higher. So much so that fastloaders cannot be recognised and TAP and simple TZX cannot all register with the Spectrum. Oddly this would indicate that a microsecond for the Maple Mini is different to the microsecond for the Arduino Nano, yet the files play for a similar length of time.
It's all highly confusing and I've put the project on the back burner for a while so I can concentrate on working any errors out of the CAS/TZXDuino Shield PCB.
The good news being that when I was trying to figure out what was going wrong I noticed that TZX2WAV which we had been using as a benchmark to test our coding actually has a typo in it a decodes slower than the TZX standard which is why there has been a slight speed up to the TZXDuino code.

Anyhoo, that's all there is to report for now.


  1. This comment has been removed by the author.

  2. Hi again Duncan, I am waiting for a Maple Leaf as I'm also interested various aspects of this project (I was always fascinated by analog to digital transmission methods since I was a kid and heard the first "loading sounds" from my ZX-81 tapes) and possibly extending it: it would be nice (even if not that appealing to everyone) to be able to also SAVE programs back to the maple/duino old fashion style. Naturally this can be done by hooking up the output of the ZX to any soundcard on laptop or PC with already available apps, but it would be even cooler to have a dedicated "portable" system, compact and light even if more "classic" (for the real nostalgic!). It can be a 2 step process, first sampling the wav file (which even the UNO can possibly handle from what i have investigated using the timer and single sample ADC) saving directly to SD then converting to tzx or possibly converting on the fly to TZX format, which would require more processing power which is why I was looking at the more powerful STM32 MCU (though I am not sure it is fast enough to jump from sampling to analysis and back to sampling). Just my thoughts so any feedback is welcome!

    1. We are looking into it although we're not entirely sure as to how to do it. Tapuino has the function to save as a TAP file for the C64 so it is possible it can be done but the difficulty will be the relatively low input voltages from the various systems so extra hardware my be required. Andrew was looking at a chip where as I was looking at a self powered sine wave to square wave converter. Having said that I still think we are over complicating things and it may be quite simple.

      Like you I think the potential of the STM32 boards could quite easily make an all in one device possible but I must admit that this timing issue I'm having is defeating me at the moment and I am well and truly stuck.
      I really do need to work on using the SDCard for settings rather than an emulated EEPROM.

    2. Yes I read about it on the st32duino forum. Unfortunately I don't have a maple mini yet so I can't run some tests and look further into it but as soon as I get mine I'll certainly give it a go. Regarding the shorter timings on the maple mini well it really depends on how the timer library is ported or interpreting the various settings that trigger the timer interrupt. Need to look into this too. I've seen that using the Arduino IDE these timings aren't always so precise if some other timers are enabled as they add to the clock cycles and can skew the timing.
      Regarding the SDfat issue, well IDE 1.8.0 had a bug in the modified SD headers making it fail with any recent SD card (but not smaller older ones). I bumped into that one too last month after I updated from 1.6.9 and I was lucky enough I still had 1.6.9 on my laptop and found the culprit. They released an update in 1.8.1 now - in any case the SDfat library works fine on all my cards with longfilename support.
      On a side note I tried creating a tzx file with OTLA and trying to load it from TZXDuino but I get an error (ID? 15 and 3F - L:0) on any file created with OTLA so I suppose it's looking for some descriptor in the header which probably is missing.

    3. The SD card issue was down to the card reader I was using and that's all sorted.

      ID15 is a TZX ID that will never be available on TZXDuino as it's a CSW file type and too complex for the Nano.
      The timings are supposed to use microseconds as it's basis and whilst TZXDuino uses the timings correctly compared to a TZX2WAV wav file there is something strange going on with the Maple Mini where the pulse lengths are shorter but the playing length of the file is about the same.
      I look forward to you getting your mini as I could really do with the help.

    4. So it was a 5V to 3.3V and viceversa level shifting problem?
      From your description apparently there is some different behaviour in the pulse timing which depends on how the timing is handled (evidently the pulse "counts" are shorter than what they are supposed to be vs the "block" size, a sort of PWM where the wavelength is fixed hence totale length of the file is about right but duty cycle too short = too short pulses). I will need to investigate this taking a look at the timers and how they work on the STM platforms.
      I see ID 15 the "Direct recording" block (CSW is ID 18)? I guess this isn't supported on TZXDuino obviously (plus it's supposed to playback at 44.1KHz) - never going to work on the 328P and neither on the Mega 2560 that I'm running it on!

    5. Sorry. I get confused and have nightmares over some TZX IDs. Lol

      Yeah. HardwareTimer is a difficult one to get my head around. Just when I think I get it it decides to not work how it's supposed to.

    6. No worries, I get mixed up too often! I was looking into adding "Direct recording" support (ID15) to the code as it should be feasable as it's just a 22/44KHz "direct" output (to try OTLA files) - the only thing missing apparently is the correct timer setup and routine for the "direct bit pushing". I will take a look at it more in depth when I have some time this week. The Direct recording scheme is just sampled "bits" into single bytes (so not as typical VOC files where every sample is a byte value of the ADC at that instance) which makes the whole recording at max 1/8th of the size of a VOC file at the same rated sampling frequency. If you have any comments or feedback (maybe you already tried) just let me know!

    7. That would be great if you can do it. I know the timing on TZXMaple is messed up at the moment but you can get the last version of it from here!vBkEASrJ!TRST-UKebTQqeDvIgPa_9SU_6NTp0-P-13DBK1QBKVE
      If you manage to get it at least coded and an audio output going that would be amazing, might even be able to go to the Nano but I doubt it.
      Any help you can give with the maple is appreciated.

    8. I was referring to the current TZXDuino Nano code (well I use it on my 2560 Mega with LCD+Keyboard Shield) code as at the moment I haven't any Maple Mini (which I am waiting for). Regarding your timing issues on the ported Maple Mini version probably something is off due to the hardware ISR timer routines vs the ATMega ones - but that will need to be invesigates as I said. At the moment I was curious to implement the ID15 blocks which OTLA uses for the non standard higher baud rates decoded by it's custom loader.

    9. That's even better. If you can get ID15 to work on a Nano then that will be great. there's someone who has it working on a 1306 OLED which will be another interesting development as we tried this a while ago but lost too much memory to the libraries.