CASDuino recording functionality

Champion (371)

14-10-2021, 18:53

RvS wrote:

The noise was caused by a ground loop (my mistake...) and csave, bsave and ascii seem to work.
Even 2400 bps works, although this is near the detection limit. 1200 bps is more robust. If anyone wants to give it a try, please do!
Next step, integration in casduino and see if it still fits in the 32k of flash...

There will need to be a few changes to what you have already. I'll have to see if I can adjust the original hardware design and add the input to A5 rather than A0 then of course there is other factors like switching between Play and Record modes. With a bit of luck it can be squeezed in but it might have to go on a bigger chip.

Van CASDuino

Champion (371)

17-10-2021, 18:22

Just to add. 2400 baud recording is unnecessary as the CASDuino will speed up the playback anyway if it is selected. Better to record at 1200 baud for accuracy.

Van CASDuino

Champion (371)

18-10-2021, 22:19

Made my own CAS Recorder to see how it works using existing hardware.

Unfortunately because A0 is already used and A6 is not a proper analogue pin the current firmware is not compatible with the CASDuino hardware but it's hopefully a good start.

Van Danjovic

Champion (355)

19-10-2021, 04:25

Have you considered to use the same algorythm provided by MSX BIOS to read the tape? They are much less CPU demanding and can adapt to differences in bit rate withih a great range.

Regarding the hardware, the ATMega328 provide an analog voltage comparator that can be very useful to deal with noise.

Regardless of the method used, the ability to record is a cool feature for such a tape emulator. Congratulations for your work and soecially for sharing it!

Van CASDuino

Champion (371)

19-10-2021, 21:56

@RvS Is there any explanation of the error codes?

I've tried recording a few pieces but gotten error codes.
This is from an Elite Save

Ready
Signal detected, 1200bps, threshold [au]:1876
Filename:RECORD03.CAS
header
Writing time [µs]:6523912
Error:19
Error:16

All that was recorded was the header.

I also loaded the Intro from Journey to the center of the earth (Written in BASIC) and tried to save that.

Ready
Signal detected, 1200bps, threshold [au]:1905
Filename:RECORD05.CAS
header
Writing time [µs]:6522980
Error:20
header
Writing time [µs]:1252
Error:18
Write time [µs]:156
header
Writing time [µs]:4008
Write time [µs]:8380
Error:20
Error:16
Write time [µs]:4516
File closed
Signal detected, 1200bps, threshold [au]:2372
Error:16
Signal detected, 1200bps, threshold [au]:2267
Error:16
Signal detected, 1200bps, threshold [au]:2138
Error:16
Signal detected, 1200bps, threshold [au]:2273
Error:16

Some of the data was saved but not the same as the original

Original

1F A6 DE BA CC 13 7D 74 D3 D3 D3 D3 D3 D3 D3 D3 
D3 D3 69 6E 74 72 6F 20 1F A6 DE BA CC 13 7D 74 
0F 80 0A 00 95 90 8D 0E 2C 06 3A 90 95 00 1F 80 
14 00 BD 12 2C 0F 0F 2C 0F 0D 3A C5 13 00 91 80 
1E 00 BE 22 73 34 62 6D 31 32 37 2C 31 30 62 64 
31 30 6C 6C 6C 6C 6C 6C 67 6C 6C 6C 6C 6C 6C 6C 
67 6C 6C 6C 6C 6C 67 6C 6C 67 6C 6C 6C 67 6C 67 
67 67 67 64 64 67 64 64 67 64 64 64 67 67 64 67 
64 67 64 64 64 64 64 67 64 64 64 64 64 64 67 64

Saved

1F A6 DE BA CC 13 7D 74 1F A6 DE BA CC 13 7D 74 
FF 00 00 00 00 00 00 00 1F A6 DE BA CC 13 7D 74 
0F 80 0A 00 95 90 8D 0E 2C 06 3A 90 95 00 1F 80 
14 00 BD 12 2C 0F 0F 2C 0F 0D 3A C5 13 00 91 80 
1E 00 BE 22 73 34 62 6D 31 32 37 2C 31 30 62 64 
31 30 6C 6C 6C 6C 6C 6C 67 6C 6C 6C 6C 6C 6C 6C 
67 6C 6C 6C 6C 6C 67 6C 6C 67 6C 6C 6C 67 6C 67 
67 67 67 64 64 67 64 64 67 64 64 64 67 67 64 67 
64 67 64 64 64 64

Could be my electronics that are the issue of course.

Van RvS

Expert (95)

19-10-2021, 22:23

It might sound a bit weird, but I was actually quite surprised that it worked
It started just as 'it would be nice if an 8 bit arduino could do real-time signal processing'.
I am also testing other methods for recording, but I believe that the SDFT method delivers the best result with the fewest additional components.
The bios counts zero-crossings if I remember correctly and in the MSX is a comparator that 'digitizes' the signal. The circuit from a few posts here above does exactly the same and can be used with any (digital) input pin.
In theory, the zero-crossing method can also be used with the A/D converter, but the tape signal is very small and noise can add 'false' zero-crossings.
The internal comparator of the 328p might also be an option, but I initially discarded it because of the large input offset voltage. Typical it is <10mV, but the maximum is 40mV. That is the entire signal, so this would require some sort of offset trimming and this would add components.
I still intend to test and publish all the methods above just for the fun of learning.
Is there any reason why you would not want to use the SDFT method? It uses ~50% of the CPU, but only if you are recording. Any method that needs the A/D converter needs an analog pin. That is not something I can change.

Van RvS

Expert (95)

19-10-2021, 22:44

Quote:

@RvS Is there any explanation of the error codes?

I've tried recording a few pieces but gotten error codes.
This is from an Elite Save

Yes, they are listed in the source code:
19 -> stopbit error (no valid stop bit within time)
16 ->header time-out (no valid header within time)

Quote:

I also loaded the Intro from Journey to the center of the earth (Written in BASIC) and tried to save that.

18 -> start bit error (no valid startbit within time)
20 -> invalid bit (not a valid 0 nor a valid 1)

I do see a massive delay for opening a file (the first writing time value). That is ~ 6 seconds. That cannot be right.
This weekend I will double check the code and repeat what you have done to check.

Van CASDuino

Champion (371)

19-10-2021, 23:42

I've ordered some PCBs of the circuit for the input which will get rid of my bad soldering as an issue.

I'm impressed at how far you've gotten so far. Further than me.

I'm wondering how reliable SD.h is compared to SDFat which is what I normally use and can handle higher class SD cards (I was using a 16GB Class 10)

I was using a Philips VG-8235 and the only thing I changed in the code was the CS Pin to 10 which is the normal CS pin for CASDuinos.

This is what a normal Elite save converted to CAS should look like.

1F A6 DE BA CC 13 7D 74 36 44 55 4E 43 41 4E 00 
00 00 00 00 00 4A 5A 48 02 53 B7 37 03 B4 F1 FE
4F 00 00 02 03 46 04 01 01 80 80 01 01 01 01 01
00 80 8F 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 C0 03 16 02 00 00 00
00 00 00 00 00 00 00 00 00 01 00 00 40 16 16 00
00 00 00 00 AF

Van RvS

Expert (95)

20-10-2021, 20:57

Quote:

I was using a Philips VG-8235 and the only thing I changed in the code was the CS Pin to 10 which is the normal CS pin for CASDuinos.

I used the 8245, so that is similar. Changing that pin should not make a difference.
Could you check the results with the standard SD.h library?
And a photo of the set-up? That will help to debug.
The only components needed are a 3.5mm jack socket, 2 resistors and one capacitor.
If the wires are short and nothing else is connected to the 3.3V output, that should work.
I see partial (correct) data coming in, so something is working. My first suspect would be the sdfat library given the long initial write time.

Van CASDuino

Champion (371)

20-10-2021, 22:02

I am using the standard SD.h. I was wondering if that could be the issue or not with the Class 10 card. Literally all I changed in the code was The CS pin for 4 to 10, everything else is the same.

Using an Arduino Nano with my standard board design for the CAS/TZXDuino so that I can use the board again for a customer.