rcmolina / maxduino Goto Github PK

I've build 2 PCB's with a Atmel 328p and am having an issue when I press the play button it plays but then a millisecond later it pauses. (Almost like a switch debouce but this is not the case)

After I press the play button again I can pause/play without experiencing the issue again.

At first I thought it was a debounce issue so increased the debounce value to 100ms which had no effect.
Also as this only happens on first play its most likely not a debounce issue.

Any ideas as to what the problem is? I've build 2 boards both with the same issue so don't think its a hardware issue.

I don't have problems with any of the other buttons and everything else seems to work fine

Hello there,

I am getting quite a few errors of this type:

"MaxDuino_v1.67:2023:9: error: 'class SdFile' has no member named 'cwd'" - it happens on quite a few places.

I'm using v1.67 with Arduino IDE v1.8.13, and have already tried several versions of the library SDFat (2.0.7, 2.0.5 and even went as far back as 1.1.4.

Any ideas on how to resolve this please?

Thanks.

Im using the 1602 lcd display, when i go into a folder it goes back to the root of the sd card but displays the folder on the top line but the second line displays the root of the sd card so i cant select any game images as it only shows folders.)
I can only select a game file if it is in the first folder of the sd card.

Would be quite easy to take the filename, reduce to 10 characters (pad with space if necessary, and remove characters outside of the 32-127 range), and send that as part of the writeHeader2() function

This worked for my 1306 display :

Updated Display.ino to include this on line 357 - 364

#endif
#ifdef UNROTATE

    //sendcommand(0xA0 | 0x1);      //SEGREMAP   //Rotate screen 180 deg 0xA1
    sendcommand(0xA0);

    //sendcommand(0xC8);            //COMSCANDEC  Rotate screen 180 Deg /* c0: scan dir normal, c8: reverse */
    sendcommand(0xC0);

Added in userconfig.h on line 56:

#define UNROTATE 1

edited Line 55 :
//#define OLED_ROTATE180 1

Saw this in the code. Feels like it must be an old bug. I dunno if anyone has a P8544 device or builds MaxDuino for it.

in SetPlayBlock: below is missing timer compatibility i.e. only works with Timer1, so presumably it wouldn't support STM devices (guessing compile error?)

if (!casduino) {
currentBlockTask = READPARAM; //First block task is to read in parameters
Timer1.setPeriod(1000); //set 1ms wait at start of a file.
}

If a file is not recognised by checkForExt, it is always assumed to be .tzx file (regardless of extension).
As a result, any file extension not already recognised will always be handled by ReadTZXHeader() function, and always display the error "Not TZXTape" (assuming the contents doesn't match a TZX header).
Would it make more sense to ignore files with unrecognised extensions (e.g. display error "Not recognised", rather than fall through to "Not TZXTape" error)

Is it possible to support TRS-80 CAS files? Not TRS Color ones, the TRS-80 seems to be 250/500/1500 bauds.

Examples https://www.classic-computers.org.nz/system-80/software_cassette_archive.htm

Hi, I developed the TZXduino-Uploader tool to make it easier to update, maybe I should develop one for Maxduino. Could you communicate?

Currently does not support HQ (High Quality) UEF files which uses extended chunks see http://electrem.emuunlim.com/UEFSpecs.htm Chunk &0104 Chunk &0111 etc.

Buenas tardes Rafa,

Adquirí en Alliexpress hace unas semanas un kit de audio con ESP32, equipado con 8 pulsadores, una salida de audio stereo, tarjeta SD, entre otras mas cosas por menos de 15€. Me preguntaba como de complicado sería adaptar maxduino, para compilarlo en esta placa, ya que tan solo habría que conectar una pantalla LCD, y sería genial para montar MaxDuino rapidamente.

Esta es la placa. https://docs.ai-thinker.com/en/esp32-audio-kit

Espero tus comentarios.

Muchas gracias, y mi agradecimiento por tu excelente trabajo.
Un cordial saludo.

I tried to upgrade my unit to the latest Version 1.76 (from version 1.56) but when I press the Menu button I get Garbage on the display (see picture).

This is probably a pretty old bug. When you play a file, and then hit Stop button, MaxDuino never displays "Stopped".
From the code, it looks like it's supposed to, and maybe it used to in the past, but it doesn't do that now. This is because "Stopped" is only displayed by the stopFile function if "start==1", and start will always be zero at that point because stopFile already called TZXStop which sets start to 0.
Furthermore, TZXStop not only sets start to zero, but also calls seekFile(), which ensures that the filesize is redisplayed on the top line (instead of Playing).

So, this seems intentional in some way. Personally, I would prefer to see the filesize (as current behaviour) instead of "Stopped", after stopping a file (it would be obvious it has stopped). But it also means P8544 users never see the STOP icon. So it must be a bug.

Question is, what is the fix that people want? Proposal: keep the current behaviour (show filesize, not "Stopped", when stopping a file), but fix it so that P8544 users see the icon. And remove the printtextF(PSTR("Stopped")) (to save a few bytes since it never gets displayed)

Hi,

Not sure if here is the correct place to write ...

Maybe a little tutorial to setup with Mega2560 Pro Embed?

Looking the new code and my MegaDuino project design ... my pins are:

#define btnUp         A0            //Up button
#define btnDown       A1            //Down button
#define btnPlay       A2            //Play Button
#define btnStop       A3            //Stop Button
#define btnRoot       A4            //Return to SD card root
#define btnDelete     A5            //Optional Function
#define btnMotor      6             //Motor Sense (connect pin to gnd to play, NC for pause)
#define scrollSpeed   250           //text scroll delay
#define scrollWait    2500          //Delay before scrolling starts

 // pinMode(btnUp,INPUT_PULLUP);  // Not needed, default is INPUT (0)
// digitalWrite(btnUp,HIGH);
// Analog pin A0
PORTF |= _BV(0);

// pinMode(btnDown,INPUT_PULLUP);  // Not needed, default is INPUT (0)
// digitalWrite(btnDown,HIGH);
// Analog pin A1
PORTF |= _BV(1);
  
// pinMode(btnPlay,INPUT_PULLUP);  // Not needed, default is INPUT (0)
// digitalWrite(btnPlay,HIGH);
// Analog pin A2
PORTF |= _BV(2);
  
// pinMode(btnStop,INPUT_PULLUP);  // Not needed, default is INPUT (0)
// digitalWrite(btnStop,HIGH);
// Analog pin A3
PORTF |= _BV(3);

// pinMode(btnRoot, INPUT_PULLUP);  // Not needed, default is INPUT (0)
// digitalWrite(btnRoot, HIGH); 
// Analog pin A4
PORTF |= _BV(4);

// pinMode(btnDelete, INPUT_PULLUP);  // Not needed, default is INPUT (0)
// digitalWrite(btnDelete,HIGH);
//Analog pin A5
PORTF |= _BV(5);

// pinMode(btnMotor, INPUT_PULLUP);  // Not needed, default is INPUT (0)
// digitalWrite(btnMotor,HIGH);
// Digital pin 6
PORTH |= _BV(3);

#define outputPin 23

Thanks a lot for your work!!!!!!!

There has been an update of MakeUEF to version 2.4 there is a long standing bug where the parity 8n1 8e1 where swapped over, but has now been fixed but this fix breaks MaxDuino and other similar units for any UEF file that uses parity 8n1 8e1 in newly created UEF files.

If you step into an empty directory, the screen doesn't update and the device seems to lock up. Pretty sure it gets stuck in an infinite while loop trying to step through and find the 'next' file in that folder.

Old bug in AY handling. Fixes are included in #43

hi i've just updated my firmware but can no longer access the menu to control the motor and other opitons.
i have flashed back top 1.49 and menu is fine again.

thanks
Gavin

I recently started to see these artifacts on screen on a Maxduino Slim (see the right side), which don't go away with a reset. I tried old firmwares and different user configs but they still show up. Can it be that the reset doesn't happen correctly?
I replaced the OLED as well but it still happens with a new one (SSD1106 as well).
Any suggestions on what may happen?
The only similar issue I've seen is this: https://forum.arduino.cc/t/how-to-get-rid-of-the-white-line-on-the-right-side-of-my-oled/492264
I wonder if anyone else has seen similar issues.

Thanks.

Hi !

I have two questions...

• Is there a way to save the settings e.g. for "Motor CTRL" ?
• Is there some sort of manual for maxduino... Maybe with best practice settings for CPC, Spectrum and so on...?

Thanks
Mathias

checkForExt incorrectly stops at the first "." symbol found nearest the start of the filename (rather than working backwards from the end of the filename, which is what TZXDuino does). As a result, checkForExt incorrectly fails to recognise a file named like "Tokimal_v1.0.tap" as a valid tap file, because it sees the "." and thinks the extension is "0.tap".
Should be an easy fix.

Not exactly an issue:
Somebody already try to port to ESP8266 or ESP32?
Or is not possible?
Main issue is that TimerONE is not supported on ESP.
Esp8266 has similar functions in ticker.h that i hope that work but at the moment i have crashes due to not enough safe GPIO.
ESP32 unfortunately ha not something similar to timerOne.
Will be insterest to use an ESP to have less noises with OLED screens (both works at 3.3v)
And is much faster so maybe will be possible play Antonio Villena cargando leche files.

Chunk &0117 - data encoding format change

This chunk contains a 16 bit unsigned value and is used to select the new data encoding format. Upon opening a UEF, the "1200 baud" data encoding format described below should be adopted. If the value is 300 then the "300 baud" data encoding format is selected. From henceforth a '0' bit should be encoded as 4 cycles at the base frequency and a '1' bit as 8 cycles at twice the base frequency. If the value is 1200 then the "1200 baud" data encoding format is selected. From henceforth a '0' bit should be encoded as 1 cycle at the base frequency and a '1' bit as 2 cycles at twice the base frequency. All other values have undefined effect.

Last changes from 6th of April are OK: bfe22a9

Testing changes from 7th to isolate the issue with Dragon, MSX loads OK.

This one breaks Dragon loading:
save a byte of vars, and some code, by combining casduino and dragonm