ਮੈਂ ਚੁੰਬਕੀ ਟੇਪ ਤੋਂ ਇੱਕ ਅਗਿਆਤ ਫਾਰਮੈਟ ਵਿੱਚ ਡੇਟਾ ਕਿਵੇਂ ਮੁੜ ਪ੍ਰਾਪਤ ਕੀਤਾ

prehistory

Retro ਹਾਰਡਵੇਅਰ ਦੇ ਪ੍ਰੇਮੀ ਹੋਣ ਦੇ ਨਾਤੇ, ਮੈਂ ਇੱਕ ਵਾਰ UK ਵਿੱਚ ਇੱਕ ਵਿਕਰੇਤਾ ਤੋਂ ZX Spectrum+ ਖਰੀਦਿਆ ਸੀ। ਕੰਪਿਊਟਰ ਦੇ ਨਾਲ ਹੀ, ਮੈਨੂੰ ਗੇਮਾਂ ਦੇ ਨਾਲ ਕਈ ਆਡੀਓ ਕੈਸੇਟਾਂ ਪ੍ਰਾਪਤ ਹੋਈਆਂ (ਹਿਦਾਇਤਾਂ ਦੇ ਨਾਲ ਅਸਲ ਪੈਕੇਜਿੰਗ ਵਿੱਚ), ਅਤੇ ਨਾਲ ਹੀ ਵਿਸ਼ੇਸ਼ ਨਿਸ਼ਾਨਾਂ ਤੋਂ ਬਿਨਾਂ ਕੈਸੇਟਾਂ 'ਤੇ ਰਿਕਾਰਡ ਕੀਤੇ ਪ੍ਰੋਗਰਾਮ। ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਹੈ ਕਿ 40 ਸਾਲ ਪੁਰਾਣੀਆਂ ਕੈਸੇਟਾਂ ਦਾ ਡਾਟਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪੜ੍ਹਨਯੋਗ ਸੀ ਅਤੇ ਮੈਂ ਉਨ੍ਹਾਂ ਤੋਂ ਲਗਭਗ ਸਾਰੀਆਂ ਗੇਮਾਂ ਅਤੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਦੇ ਯੋਗ ਸੀ।

ਹਾਲਾਂਕਿ, ਕੁਝ ਕੈਸੇਟਾਂ 'ਤੇ ਮੈਨੂੰ ਰਿਕਾਰਡਿੰਗਾਂ ਮਿਲੀਆਂ ਜੋ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ZX ਸਪੈਕਟਰਮ ਕੰਪਿਊਟਰ ਦੁਆਰਾ ਨਹੀਂ ਬਣਾਈਆਂ ਗਈਆਂ ਸਨ। ਉਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਸਨ ਅਤੇ, ਜ਼ਿਕਰ ਕੀਤੇ ਕੰਪਿਊਟਰ ਤੋਂ ਰਿਕਾਰਡਿੰਗਾਂ ਦੇ ਉਲਟ, ਉਹ ਇੱਕ ਛੋਟੇ ਬੇਸਿਕ ਲੋਡਰ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਏ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਸਾਰੇ ਪ੍ਰੋਗਰਾਮਾਂ ਅਤੇ ਗੇਮਾਂ ਦੀਆਂ ਰਿਕਾਰਡਿੰਗਾਂ ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ।

ਕੁਝ ਸਮੇਂ ਲਈ ਇਸ ਨੇ ਮੈਨੂੰ ਪਰੇਸ਼ਾਨ ਕੀਤਾ - ਮੈਂ ਸੱਚਮੁੱਚ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਉਹਨਾਂ ਵਿੱਚ ਕੀ ਛੁਪਿਆ ਹੋਇਆ ਸੀ. ਜੇਕਰ ਤੁਸੀਂ ਆਡੀਓ ਸਿਗਨਲ ਨੂੰ ਬਾਈਟਾਂ ਦੇ ਕ੍ਰਮ ਵਜੋਂ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅੱਖਰਾਂ ਜਾਂ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦੀ ਖੋਜ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਸਿਗਨਲ ਦੇ ਮੂਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਪੁਰਾਤੱਤਵ-ਵਿਗਿਆਨ ਦੀ ਇੱਕ ਕਿਸਮ।

ਹੁਣ ਜਦੋਂ ਮੈਂ ਸਾਰੇ ਤਰੀਕੇ ਨਾਲ ਚਲਾ ਗਿਆ ਹਾਂ ਅਤੇ ਕੈਸੇਟਾਂ ਦੇ ਲੇਬਲਾਂ ਨੂੰ ਖੁਦ ਦੇਖਦਾ ਹਾਂ, ਮੈਂ ਮੁਸਕਰਾਉਂਦਾ ਹਾਂ ਕਿਉਂਕਿ

ਜਵਾਬ ਮੇਰੀਆਂ ਅੱਖਾਂ ਦੇ ਸਾਮ੍ਹਣੇ ਹੀ ਸੀ
ਖੱਬੇ ਕੈਸੇਟ ਦੇ ਲੇਬਲ 'ਤੇ TRS-80 ਕੰਪਿਊਟਰ ਦਾ ਨਾਮ ਹੈ, ਅਤੇ ਨਿਰਮਾਤਾ ਦੇ ਨਾਮ ਦੇ ਬਿਲਕੁਲ ਹੇਠਾਂ ਹੈ: "ਯੂਐਸਏ ਵਿੱਚ ਰੇਡੀਓ ਸ਼ੈਕ ਦੁਆਰਾ ਨਿਰਮਿਤ"

(ਜੇ ਤੁਸੀਂ ਸਾਜ਼ਿਸ਼ ਨੂੰ ਅੰਤ ਤੱਕ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਵਿਗਾੜਣ ਵਾਲੇ ਦੇ ਹੇਠਾਂ ਨਾ ਜਾਓ)

ਆਡੀਓ ਸਿਗਨਲਾਂ ਦੀ ਤੁਲਨਾ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਆਓ ਆਡੀਓ ਰਿਕਾਰਡਿੰਗਾਂ ਨੂੰ ਡਿਜੀਟਲਾਈਜ਼ ਕਰੀਏ। ਤੁਸੀਂ ਸੁਣ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਕਿਹੋ ਜਿਹਾ ਲੱਗਦਾ ਹੈ:

ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ZX ਸਪੈਕਟ੍ਰਮ ਕੰਪਿਊਟਰ ਤੋਂ ਰਿਕਾਰਡਿੰਗ ਆਵਾਜ਼ਾਂ:

ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਰਿਕਾਰਡਿੰਗ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਅਖੌਤੀ ਹੁੰਦਾ ਹੈ ਪਾਇਲਟ ਟੋਨ - ਇੱਕੋ ਬਾਰੰਬਾਰਤਾ ਦੀ ਇੱਕ ਆਵਾਜ਼ (ਪਹਿਲੀ ਰਿਕਾਰਡਿੰਗ ਵਿੱਚ ਇਹ ਬਹੁਤ ਛੋਟਾ <1 ਸਕਿੰਟ ਹੈ, ਪਰ ਵੱਖਰਾ ਹੈ)। ਪਾਇਲਟ ਟੋਨ ਕੰਪਿਊਟਰ ਨੂੰ ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਤਿਆਰ ਕਰਨ ਲਈ ਸੰਕੇਤ ਕਰਦਾ ਹੈ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਹਰੇਕ ਕੰਪਿਊਟਰ ਸਿਗਨਲ ਦੀ ਸ਼ਕਲ ਅਤੇ ਇਸਦੀ ਬਾਰੰਬਾਰਤਾ ਦੁਆਰਾ ਸਿਰਫ ਇਸਦੇ "ਆਪਣੇ" ਪਾਇਲਟ ਟੋਨ ਨੂੰ ਪਛਾਣਦਾ ਹੈ।

ਸਿਗਨਲ ਦੀ ਸ਼ਕਲ ਬਾਰੇ ਹੀ ਕੁਝ ਕਹਿਣਾ ਜ਼ਰੂਰੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ZX ਸਪੈਕਟ੍ਰਮ 'ਤੇ ਇਸਦਾ ਆਕਾਰ ਆਇਤਾਕਾਰ ਹੈ:

ਜਦੋਂ ਇੱਕ ਪਾਇਲਟ ਟੋਨ ਦਾ ਪਤਾ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ZX ਸਪੈਕਟ੍ਰਮ ਇਹ ਦਰਸਾਉਣ ਲਈ ਸਕ੍ਰੀਨ ਦੀ ਸੀਮਾ 'ਤੇ ਲਾਲ ਅਤੇ ਨੀਲੀਆਂ ਬਾਰਾਂ ਨੂੰ ਬਦਲਦਾ ਹੈ ਕਿ ਸਿਗਨਲ ਨੂੰ ਪਛਾਣਿਆ ਗਿਆ ਹੈ। ਪਾਇਲਟ ਟੋਨ ਖਤਮ ਹੁੰਦਾ ਹੈ ਸਮਕਾਲੀ ਨਬਜ਼, ਜੋ ਕਿ ਕੰਪਿਊਟਰ ਨੂੰ ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਛੋਟੀ ਮਿਆਦ (ਪਾਇਲਟ ਟੋਨ ਅਤੇ ਬਾਅਦ ਦੇ ਡੇਟਾ ਦੇ ਮੁਕਾਬਲੇ) ਦੁਆਰਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ (ਚਿੱਤਰ ਦੇਖੋ)

ਸਿੰਕ ਪਲਸ ਪ੍ਰਾਪਤ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਕੰਪਿਊਟਰ ਸਿਗਨਲ ਦੇ ਹਰੇਕ ਵਾਧੇ/ਪਤਨ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ, ਇਸਦੀ ਮਿਆਦ ਨੂੰ ਮਾਪਦਾ ਹੈ। ਜੇਕਰ ਮਿਆਦ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੀਮਾ ਤੋਂ ਘੱਟ ਹੈ, ਤਾਂ ਬਿੱਟ 1 ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ 0. ਬਿੱਟਾਂ ਨੂੰ ਬਾਈਟਾਂ ਵਿੱਚ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ N ਬਾਈਟ ਪ੍ਰਾਪਤ ਹੋਣ ਤੱਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ। ਨੰਬਰ N ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਡਾਊਨਲੋਡ ਕੀਤੀ ਫ਼ਾਈਲ ਦੇ ਸਿਰਲੇਖ ਤੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਲੋਡਿੰਗ ਕ੍ਰਮ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ:

1. ਪਾਇਲਟ ਟੋਨ
2. ਸਿਰਲੇਖ (ਸਥਿਰ ਲੰਬਾਈ), ਵਿੱਚ ਡਾਉਨਲੋਡ ਕੀਤੇ ਡੇਟਾ ਦਾ ਆਕਾਰ (N), ਫਾਈਲ ਦਾ ਨਾਮ ਅਤੇ ਕਿਸਮ ਸ਼ਾਮਲ ਹੈ
3. ਪਾਇਲਟ ਟੋਨ
4. ਡਾਟਾ ਆਪਣੇ ਆਪ ਨੂੰ

ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਡੇਟਾ ਸਹੀ ਤਰ੍ਹਾਂ ਲੋਡ ਕੀਤਾ ਗਿਆ ਹੈ, ZX ਸਪੈਕਟ੍ਰਮ ਅਖੌਤੀ ਪੜ੍ਹਦਾ ਹੈ ਸਮਾਨਤਾ ਬਾਈਟ (ਪੈਰਿਟੀ ਬਾਈਟ), ਜੋ ਕਿ ਲਿਖਤੀ ਡੇਟਾ ਦੇ ਸਾਰੇ ਬਾਈਟਾਂ ਨੂੰ XOR ਕਰਕੇ ਇੱਕ ਫਾਈਲ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਵੇਲੇ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਦੇ ਸਮੇਂ, ਕੰਪਿਊਟਰ ਪ੍ਰਾਪਤ ਕੀਤੇ ਡੇਟਾ ਤੋਂ ਪੈਰਿਟੀ ਬਾਈਟ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ ਅਤੇ, ਜੇਕਰ ਨਤੀਜਾ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਗਏ ਨਾਲੋਂ ਵੱਖਰਾ ਹੈ, ਤਾਂ ਗਲਤੀ ਸੁਨੇਹਾ "R ਟੇਪ ਲੋਡਿੰਗ ਗਲਤੀ" ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਸਖਤੀ ਨਾਲ ਕਹੀਏ ਤਾਂ, ਕੰਪਿਊਟਰ ਇਸ ਸੰਦੇਸ਼ ਨੂੰ ਪਹਿਲਾਂ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ ਜੇਕਰ, ਪੜ੍ਹਦੇ ਸਮੇਂ, ਇਹ ਇੱਕ ਨਬਜ਼ ਨੂੰ ਨਹੀਂ ਪਛਾਣ ਸਕਦਾ (ਖੁੰਝ ਗਿਆ ਜਾਂ ਇਸਦੀ ਮਿਆਦ ਕੁਝ ਸੀਮਾਵਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ)

ਇਸ ਲਈ, ਆਓ ਹੁਣ ਵੇਖੀਏ ਕਿ ਇੱਕ ਅਗਿਆਤ ਸਿਗਨਲ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਇਹ ਪਾਇਲਟ ਟੋਨ ਹੈ। ਸਿਗਨਲ ਦੀ ਸ਼ਕਲ ਕਾਫ਼ੀ ਵੱਖਰੀ ਹੈ, ਪਰ ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਸਿਗਨਲ ਵਿੱਚ ਇੱਕ ਨਿਸ਼ਚਤ ਬਾਰੰਬਾਰਤਾ ਦੀਆਂ ਛੋਟੀਆਂ ਦਾਲਾਂ ਨੂੰ ਦੁਹਰਾਉਣਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। 44100 Hz ਦੀ ਨਮੂਨੇ ਦੀ ਬਾਰੰਬਾਰਤਾ 'ਤੇ, "ਪੀਕਸ" ਵਿਚਕਾਰ ਦੂਰੀ ਲਗਭਗ 48 ਨਮੂਨੇ ਹੈ (ਜੋ ~ 918 Hz ਦੀ ਬਾਰੰਬਾਰਤਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ)। ਆਓ ਇਸ ਅੰਕੜੇ ਨੂੰ ਯਾਦ ਕਰੀਏ।

ਆਉ ਹੁਣ ਡੇਟਾ ਦੇ ਟੁਕੜੇ ਨੂੰ ਵੇਖੀਏ:

ਜੇ ਅਸੀਂ ਵਿਅਕਤੀਗਤ ਦਾਲਾਂ ਵਿਚਕਾਰ ਦੂਰੀ ਨੂੰ ਮਾਪਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ "ਲੰਮੀਆਂ" ਦਾਲਾਂ ਵਿਚਕਾਰ ਦੂਰੀ ਅਜੇ ਵੀ ~ 48 ਨਮੂਨੇ ਹੈ, ਅਤੇ ਛੋਟੀਆਂ ਦਾਲਾਂ ਦੇ ਵਿਚਕਾਰ - ~ 24 ਹੈ। ਥੋੜਾ ਜਿਹਾ ਅੱਗੇ ਦੇਖਦੇ ਹੋਏ, ਮੈਂ ਕਹਾਂਗਾ ਕਿ ਅੰਤ ਵਿੱਚ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ 918 ਹਰਟਜ਼ ਦੀ ਬਾਰੰਬਾਰਤਾ ਨਾਲ "ਸੰਦਰਭ" ਦਾਲਾਂ ਫਾਈਲ ਦੇ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਲਗਾਤਾਰ ਚੱਲਦੀਆਂ ਹਨ. ਇਹ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਡੇਟਾ ਸੰਚਾਰਿਤ ਕਰਦੇ ਸਮੇਂ, ਜੇਕਰ ਹਵਾਲਾ ਦਾਲਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਵਾਧੂ ਪਲਸ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ ਬਿੱਟ 1 ਮੰਨਦੇ ਹਾਂ, ਨਹੀਂ ਤਾਂ 0।

ਸਿੰਕ ਪਲਸ ਬਾਰੇ ਕੀ? ਆਉ ਡੇਟਾ ਦੀ ਸ਼ੁਰੂਆਤ ਨੂੰ ਵੇਖੀਏ:

ਪਾਇਲਟ ਟੋਨ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਡੇਟਾ ਤੁਰੰਤ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ, ਕਈ ਵੱਖ-ਵੱਖ ਆਡੀਓ ਰਿਕਾਰਡਿੰਗਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਇਹ ਖੋਜਣ ਦੇ ਯੋਗ ਹੋ ਗਏ ਕਿ ਡੇਟਾ ਦਾ ਪਹਿਲਾ ਬਾਈਟ ਹਮੇਸ਼ਾ ਇੱਕੋ ਜਿਹਾ ਹੁੰਦਾ ਹੈ (10100101b, A5h)। ਕੰਪਿਊਟਰ ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ।

ਤੁਸੀਂ ਸਿੰਕ ਬਾਈਟ ਵਿੱਚ ਆਖਰੀ 1 ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਪਹਿਲੀ ਸੰਦਰਭ ਪਲਸ ਦੀ ਸ਼ਿਫਟ ਵੱਲ ਵੀ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹੋ। ਇਹ ਇੱਕ ਡਾਟਾ ਮਾਨਤਾ ਪ੍ਰੋਗਰਾਮ ਦੇ ਵਿਕਾਸ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਬਹੁਤ ਬਾਅਦ ਵਿੱਚ ਖੋਜਿਆ ਗਿਆ ਸੀ, ਜਦੋਂ ਫਾਈਲ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਸਥਿਰਤਾ ਨਾਲ ਪੜ੍ਹਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਸੀ.

ਹੁਣ ਆਉ ਇੱਕ ਐਲਗੋਰਿਦਮ ਦਾ ਵਰਣਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਜੋ ਇੱਕ ਆਡੀਓ ਫਾਈਲ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰੇਗਾ ਅਤੇ ਡੇਟਾ ਲੋਡ ਕਰੇਗਾ।

ਡਾਟਾ ਲੋਡ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਪਹਿਲਾਂ, ਆਓ ਐਲਗੋਰਿਦਮ ਨੂੰ ਸਧਾਰਨ ਰੱਖਣ ਲਈ ਕੁਝ ਧਾਰਨਾਵਾਂ ਨੂੰ ਵੇਖੀਏ:

1. ਅਸੀਂ ਸਿਰਫ WAV ਫਾਰਮੈਟ ਵਿੱਚ ਫਾਈਲਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਾਂਗੇ;
2. ਆਡੀਓ ਫਾਈਲ ਇੱਕ ਪਾਇਲਟ ਟੋਨ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਸ਼ੁਰੂ ਵਿੱਚ ਚੁੱਪ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ
3. ਸਰੋਤ ਫਾਈਲ ਦੀ ਨਮੂਨਾ ਦਰ 44100 Hz ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, 48 ਨਮੂਨਿਆਂ ਦੇ ਸੰਦਰਭ ਦਾਲਾਂ ਵਿਚਕਾਰ ਦੂਰੀ ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਹੈ ਅਤੇ ਸਾਨੂੰ ਇਸਦੀ ਪ੍ਰੋਗ੍ਰਾਮਿਕ ਤੌਰ 'ਤੇ ਗਣਨਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ;
4. ਨਮੂਨਾ ਫਾਰਮੈਟ ਕੋਈ ਵੀ ਹੋ ਸਕਦਾ ਹੈ (8/16 ਬਿੱਟ/ਫਲੋਟਿੰਗ ਪੁਆਇੰਟ) - ਕਿਉਂਕਿ ਪੜ੍ਹਦੇ ਸਮੇਂ ਅਸੀਂ ਇਸਨੂੰ ਲੋੜੀਂਦੇ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਾਂ;
5. ਅਸੀਂ ਇਹ ਮੰਨਦੇ ਹਾਂ ਕਿ ਸਰੋਤ ਫਾਈਲ ਨੂੰ ਐਪਲੀਟਿਊਡ ਦੁਆਰਾ ਸਧਾਰਣ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਨਾਲ ਨਤੀਜੇ ਨੂੰ ਸਥਿਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ;

ਰੀਡਿੰਗ ਐਲਗੋਰਿਦਮ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੋਵੇਗਾ:

1. ਅਸੀਂ ਫਾਈਲ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਪੜ੍ਹਦੇ ਹਾਂ, ਉਸੇ ਸਮੇਂ ਨਮੂਨਾ ਫਾਰਮੈਟ ਨੂੰ 8 ਬਿੱਟਾਂ ਵਿੱਚ ਬਦਲਦੇ ਹਾਂ;
2. ਆਡੀਓ ਡੇਟਾ ਵਿੱਚ ਪਹਿਲੀ ਪਲਸ ਦੀ ਸਥਿਤੀ ਦਾ ਪਤਾ ਲਗਾਓ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਐਪਲੀਟਿਊਡ ਦੇ ਨਾਲ ਨਮੂਨੇ ਦੀ ਗਿਣਤੀ ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਸਰਲਤਾ ਲਈ, ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ ਵਾਰ ਹੱਥੀਂ ਗਣਨਾ ਕਰਾਂਗੇ। ਚਲੋ ਇਸਨੂੰ prev_pos ਵੇਰੀਏਬਲ ਵਿੱਚ ਸੇਵ ਕਰੀਏ;
3. ਆਖਰੀ ਪਲਸ ਦੀ ਸਥਿਤੀ ਵਿੱਚ 48 ਜੋੜੋ (pos := prev_pos + 48)
4. ਕਿਉਂਕਿ ਸਥਿਤੀ ਨੂੰ 48 ਤੱਕ ਵਧਾਉਣਾ ਇਸ ਗੱਲ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਅਗਲੀ ਸੰਦਰਭ ਪਲਸ (ਟੇਪ ਦੇ ਨੁਕਸ, ਟੇਪ ਡਰਾਈਵ ਵਿਧੀ ਦਾ ਅਸਥਿਰ ਸੰਚਾਲਨ, ਆਦਿ) ਦੀ ਸਥਿਤੀ 'ਤੇ ਪਹੁੰਚ ਜਾਵਾਂਗੇ, ਸਾਨੂੰ ਪਲਸ ਪੋਜ਼ ਦੀ ਸਥਿਤੀ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਡੇਟਾ ਦਾ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਟੁਕੜਾ (pos-8;pos+8) ਲਓ ਅਤੇ ਇਸ ਉੱਤੇ ਅਧਿਕਤਮ ਐਪਲੀਟਿਊਡ ਮੁੱਲ ਲੱਭੋ। ਅਧਿਕਤਮ ਦੇ ਅਨੁਸਾਰੀ ਸਥਿਤੀ ਨੂੰ pos ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇਗਾ। ਇੱਥੇ 8 = 48/6 ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤੀ ਸਥਿਰਤਾ ਹੈ, ਜੋ ਗਾਰੰਟੀ ਦਿੰਦੀ ਹੈ ਕਿ ਅਸੀਂ ਸਹੀ ਅਧਿਕਤਮ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਾਂਗੇ ਅਤੇ ਨੇੜੇ ਦੇ ਹੋਰ ਪ੍ਰਭਾਵ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਾਂਗੇ। ਬਹੁਤ ਮਾੜੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਜਦੋਂ ਦਾਲਾਂ ਵਿਚਕਾਰ ਦੂਰੀ 48 ਤੋਂ ਬਹੁਤ ਘੱਟ ਜਾਂ ਵੱਧ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਨਬਜ਼ ਲਈ ਇੱਕ ਜ਼ਬਰਦਸਤੀ ਖੋਜ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਲੇਖ ਦੇ ਦਾਇਰੇ ਦੇ ਅੰਦਰ ਮੈਂ ਐਲਗੋਰਿਦਮ ਵਿੱਚ ਇਸਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਾਂਗਾ;
5. ਪਿਛਲੇ ਪੜਾਅ 'ਤੇ, ਇਹ ਜਾਂਚ ਕਰਨਾ ਵੀ ਜ਼ਰੂਰੀ ਹੋਵੇਗਾ ਕਿ ਹਵਾਲਾ ਨਬਜ਼ ਬਿਲਕੁਲ ਲੱਭੀ ਗਈ ਸੀ. ਭਾਵ, ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਅਧਿਕਤਮ ਦੀ ਭਾਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਇਸ ਗੱਲ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਹੈ ਕਿ ਇਸ ਹਿੱਸੇ ਵਿੱਚ ਪ੍ਰਭਾਵ ਮੌਜੂਦ ਹੈ। ਰੀਡਿੰਗ ਪ੍ਰੋਗਰਾਮ ਦੇ ਮੇਰੇ ਨਵੀਨਤਮ ਅਮਲ ਵਿੱਚ, ਮੈਂ ਇੱਕ ਹਿੱਸੇ 'ਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਐਪਲੀਟਿਊਡ ਮੁੱਲਾਂ ਵਿੱਚ ਅੰਤਰ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹਾਂ, ਅਤੇ ਜੇਕਰ ਇਹ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਮੈਂ ਇੱਕ ਪ੍ਰਭਾਵ ਦੀ ਮੌਜੂਦਗੀ ਨੂੰ ਗਿਣਦਾ ਹਾਂ। ਸਵਾਲ ਇਹ ਵੀ ਹੈ ਕਿ ਜੇਕਰ ਰੈਫਰੈਂਸ ਪਲਸ ਨਾ ਮਿਲੇ ਤਾਂ ਕੀ ਕੀਤਾ ਜਾਵੇ। ਇੱਥੇ 2 ਵਿਕਲਪ ਹਨ: ਜਾਂ ਤਾਂ ਡੇਟਾ ਖਤਮ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਚੁੱਪ ਹੋ ਗਈ ਹੈ, ਜਾਂ ਇਸਨੂੰ ਰੀਡਿੰਗ ਗਲਤੀ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਅਸੀਂ ਐਲਗੋਰਿਦਮ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਲਈ ਇਸ ਨੂੰ ਛੱਡ ਦੇਵਾਂਗੇ;
6. ਅਗਲੇ ਪੜਾਅ 'ਤੇ, ਸਾਨੂੰ ਇੱਕ ਡੇਟਾ ਪਲਸ (ਬਿੱਟ 0 ਜਾਂ 1) ਦੀ ਮੌਜੂਦਗੀ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਇਸਦੇ ਲਈ ਅਸੀਂ ਖੰਡ ਦੇ ਮੱਧ ਨੂੰ ਲੈਂਦੇ ਹਾਂ (prev_pos;pos) Middle_pos ਬਰਾਬਰ ਮੱਧ_pos := (prev_pos+pos)/2 ਅਤੇ ਖੰਡ (middle_pos-8;middle_pos +8) 'ਤੇ ਮੱਧ_ਪੋਸ ਦੇ ਕੁਝ ਆਂਢ-ਗੁਆਂਢ ਵਿੱਚ ਆਉ ਵੱਧ ਤੋਂ ਵੱਧ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਐਪਲੀਟਿਊਡ ਦੀ ਗਣਨਾ ਕਰੀਏ। ਜੇਕਰ ਉਹਨਾਂ ਵਿਚਕਾਰ ਅੰਤਰ 10 ਤੋਂ ਵੱਧ ਹੈ, ਤਾਂ ਅਸੀਂ ਨਤੀਜੇ ਵਿੱਚ ਬਿੱਟ 1 ਲਿਖਦੇ ਹਾਂ, ਨਹੀਂ ਤਾਂ 0. 10 ਪ੍ਰਯੋਗਾਤਮਕ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤੀ ਇੱਕ ਸਥਿਰਤਾ ਹੈ;
7. ਮੌਜੂਦਾ ਸਥਿਤੀ ਨੂੰ prev_pos (prev_pos := pos) ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰੋ
8. ਕਦਮ 3 ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ ਉਦੋਂ ਤੱਕ ਦੁਹਰਾਓ ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਪੂਰੀ ਫਾਈਲ ਨਹੀਂ ਪੜ੍ਹ ਲੈਂਦੇ;
9. ਨਤੀਜੇ ਵਜੋਂ ਬਿੱਟ ਐਰੇ ਨੂੰ ਬਾਈਟਾਂ ਦੇ ਸੈੱਟ ਵਜੋਂ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਿਉਂਕਿ ਅਸੀਂ ਪੜ੍ਹਦੇ ਸਮੇਂ ਸਿੰਕ ਬਾਈਟ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਿਆ, ਇਸ ਲਈ ਬਿੱਟਾਂ ਦੀ ਗਿਣਤੀ 8 ਦੇ ਗੁਣਜ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਅਤੇ ਲੋੜੀਂਦਾ ਬਿੱਟ ਆਫਸੈੱਟ ਵੀ ਅਣਜਾਣ ਹੈ। ਐਲਗੋਰਿਦਮ ਦੇ ਪਹਿਲੇ ਲਾਗੂ ਕਰਨ ਵਿੱਚ, ਮੈਨੂੰ ਸਿੰਕ ਬਾਈਟ ਦੀ ਮੌਜੂਦਗੀ ਬਾਰੇ ਨਹੀਂ ਪਤਾ ਸੀ ਅਤੇ ਇਸਲਈ ਔਫਸੈੱਟ ਬਿੱਟਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਸੰਖਿਆਵਾਂ ਨਾਲ ਸਿਰਫ਼ 8 ਫਾਈਲਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਗਿਆ ਸੀ. ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਸਹੀ ਡੇਟਾ ਸੀ। ਅੰਤਮ ਐਲਗੋਰਿਦਮ ਵਿੱਚ, ਮੈਂ ਬਸ A5h ਤੱਕ ਦੇ ਸਾਰੇ ਬਿੱਟਾਂ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹਾਂ, ਜੋ ਮੈਨੂੰ ਤੁਰੰਤ ਸਹੀ ਆਉਟਪੁੱਟ ਫਾਈਲ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ

ਰੁਬੀ ਵਿੱਚ ਐਲਗੋਰਿਦਮ, ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲਿਆਂ ਲਈ
ਮੈਂ ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਲਈ ਰੂਬੀ ਨੂੰ ਭਾਸ਼ਾ ਵਜੋਂ ਚੁਣਿਆ, ਕਿਉਂਕਿ... ਮੈਂ ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ ਇਸ 'ਤੇ ਪ੍ਰੋਗਰਾਮ ਕਰਦਾ ਹਾਂ। ਵਿਕਲਪ ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵਾਲਾ ਨਹੀਂ ਹੈ, ਪਰ ਪੜ੍ਹਨ ਦੀ ਗਤੀ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਤੇਜ਼ ਕਰਨ ਦਾ ਕੰਮ ਇਸ ਦੇ ਯੋਗ ਨਹੀਂ ਹੈ.

# Используем gem 'wavefile'
require 'wavefile'

reader = WaveFile::Reader.new('input.wav')
samples = []
format = WaveFile::Format.new(:mono, :pcm_8, 44100)

# Читаем WAV файл, конвертируем в формат Mono, 8 bit 
# Массив samples будет состоять из байт со значениями 0-255
reader.each_buffer(10000) do |buffer|
  samples += buffer.convert(format).samples
end

# Позиция первого импульса (вместо 0)
prev_pos = 0
# Расстояние между импульсами
distance = 48
# Значение расстояния для окрестности поиска локального максимума
delta = (distance / 6).floor
# Биты будем сохранять в виде строки из "0" и "1"
bits = ""

loop do
  # Рассчитываем позицию следующего импульса
  pos = prev_pos + distance
  
  # Выходим из цикла если данные закончились 
  break if pos + delta >= samples.size

  # Корректируем позицию pos обнаружением максимума на отрезке [pos - delta;pos + delta]
  (pos - delta..pos + delta).each { |p| pos = p if samples[p] > samples[pos] }

  # Находим середину отрезка [prev_pos;pos]
  middle_pos = ((prev_pos + pos) / 2).floor

  # Берем окрестность в середине 
  sample = samples[middle_pos - delta..middle_pos + delta]

  # Определяем бит как "1" если разница между максимальным и минимальным значением на отрезке превышает 10
  bit = sample.max - sample.min > 10
  bits += bit ? "1" : "0"
end

# Определяем синхро-байт и заменяем все предшествующие биты на 256 бит нулей (согласно спецификации формата) 
bits.gsub! /^[01]*?10100101/, ("0" * 256) + "10100101"

# Сохраняем выходной файл, упаковывая биты в байты
File.write "output.cas", [bits].pack("B*")

ਇਸ ਦਾ ਨਤੀਜਾ

ਐਲਗੋਰਿਦਮ ਅਤੇ ਸਥਿਰਾਂਕਾਂ ਦੇ ਕਈ ਰੂਪਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਬਹੁਤ ਹੀ ਦਿਲਚਸਪ ਚੀਜ਼ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਖੁਸ਼ਕਿਸਮਤ ਸੀ:

ਇਸ ਲਈ, ਅੱਖਰ ਦੀਆਂ ਤਾਰਾਂ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਸਾਡੇ ਕੋਲ ਗ੍ਰਾਫਾਂ ਨੂੰ ਪਲਾਟ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਹੈ। ਹਾਲਾਂਕਿ, ਪ੍ਰੋਗਰਾਮ ਟੈਕਸਟ ਵਿੱਚ ਕੋਈ ਕੀਵਰਡ ਨਹੀਂ ਹਨ। ਸਾਰੇ ਕੀਵਰਡ ਬਾਈਟਸ ਦੇ ਰੂਪ ਵਿੱਚ ਏਨਕੋਡ ਕੀਤੇ ਗਏ ਹਨ (ਹਰੇਕ ਮੁੱਲ > 80h)। ਹੁਣ ਸਾਨੂੰ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ 80 ਦੇ ਦਹਾਕੇ ਤੋਂ ਕਿਹੜਾ ਕੰਪਿਊਟਰ ਇਸ ਫਾਰਮੈਟ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦਾ ਹੈ.

ਅਸਲ ਵਿੱਚ, ਇਹ ਇੱਕ ਬੇਸਿਕ ਪ੍ਰੋਗਰਾਮ ਦੇ ਸਮਾਨ ਹੈ। ZX ਸਪੈਕਟ੍ਰਮ ਕੰਪਿਊਟਰ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਲਗਭਗ ਇੱਕੋ ਫਾਰਮੈਟ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਟੇਪ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ। ਬਸ ਮਾਮਲੇ ਵਿੱਚ, ਮੈਂ ਇਸਦੇ ਵਿਰੁੱਧ ਕੀਵਰਡਸ ਦੀ ਜਾਂਚ ਕੀਤੀ ਮੇਜ਼. ਹਾਲਾਂਕਿ, ਨਤੀਜਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਕਾਰਾਤਮਕ ਸੀ.

ਮੈਂ ਉਸ ਸਮੇਂ ਦੇ ਪ੍ਰਸਿੱਧ ਅਟਾਰੀ, ਕਮੋਡੋਰ 64 ਅਤੇ ਕਈ ਹੋਰ ਕੰਪਿਊਟਰਾਂ ਦੇ ਬੇਸਿਕ ਕੀਵਰਡਸ ਦੀ ਵੀ ਜਾਂਚ ਕੀਤੀ, ਜਿਸ ਲਈ ਮੈਂ ਦਸਤਾਵੇਜ਼ ਲੱਭਣ ਦੇ ਯੋਗ ਸੀ, ਪਰ ਸਫਲਤਾ ਤੋਂ ਬਿਨਾਂ - ਰੈਟਰੋ ਕੰਪਿਊਟਰਾਂ ਦੀਆਂ ਕਿਸਮਾਂ ਬਾਰੇ ਮੇਰਾ ਗਿਆਨ ਇੰਨਾ ਵਿਸ਼ਾਲ ਨਹੀਂ ਸੀ।

ਫਿਰ ਮੈਂ ਜਾਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਸੂਚੀ, ਅਤੇ ਫਿਰ ਮੇਰੀ ਨਜ਼ਰ ਨਿਰਮਾਤਾ ਰੇਡੀਓ ਸ਼ੈਕ ਅਤੇ TRS-80 ਕੰਪਿਊਟਰ ਦੇ ਨਾਮ 'ਤੇ ਪਈ। ਇਹ ਉਹ ਨਾਮ ਹਨ ਜੋ ਮੇਰੇ ਮੇਜ਼ 'ਤੇ ਪਈਆਂ ਕੈਸਿਟਾਂ ਦੇ ਲੇਬਲਾਂ 'ਤੇ ਲਿਖੇ ਹੋਏ ਸਨ! ਮੈਂ ਇਹਨਾਂ ਨਾਵਾਂ ਨੂੰ ਪਹਿਲਾਂ ਨਹੀਂ ਜਾਣਦਾ ਸੀ ਅਤੇ TRS-80 ਕੰਪਿਊਟਰ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਸੀ, ਇਸ ਲਈ ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਸੀ ਕਿ ਰੇਡੀਓ ਸ਼ੈਕ ਇੱਕ ਆਡੀਓ ਕੈਸੇਟ ਨਿਰਮਾਤਾ ਜਿਵੇਂ ਕਿ BASF, Sony ਜਾਂ TDK ਸੀ, ਅਤੇ TRS-80 ਪਲੇਬੈਕ ਸਮਾਂ ਸੀ। ਕਿਉਂ ਨਹੀਂ?

ਕੰਪਿਊਟਰ ਟੈਂਡੀ/ਰੇਡੀਓ ਸ਼ੈਕ TRS-80

ਇਹ ਬਹੁਤ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਪ੍ਰਸ਼ਨ ਵਿੱਚ ਆਡੀਓ ਰਿਕਾਰਡਿੰਗ, ਜੋ ਮੈਂ ਲੇਖ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਉਦਾਹਰਨ ਦੇ ਤੌਰ ਤੇ ਦਿੱਤੀ ਸੀ, ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਕੰਪਿਊਟਰ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਸੀ:

ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਇਹ ਕੰਪਿਊਟਰ ਅਤੇ ਇਸ ਦੀਆਂ ਕਿਸਮਾਂ (ਮਾਡਲ I/Model III/Model IV, ਆਦਿ) ਇੱਕ ਸਮੇਂ ਬਹੁਤ ਮਸ਼ਹੂਰ ਸਨ (ਬੇਸ਼ਕ, ਰੂਸ ਵਿੱਚ ਨਹੀਂ)। ਧਿਆਨ ਯੋਗ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਜੋ ਪ੍ਰੋਸੈਸਰ ਵਰਤਿਆ ਸੀ ਉਹ ਵੀ Z80 ਸੀ। ਇਸ ਕੰਪਿਊਟਰ ਲਈ ਤੁਸੀਂ ਇੰਟਰਨੈੱਟ 'ਤੇ ਲੱਭ ਸਕਦੇ ਹੋ ਬਹੁਤ ਸਾਰੀ ਜਾਣਕਾਰੀ. 80 ਦੇ ਦਹਾਕੇ ਵਿੱਚ, ਕੰਪਿਊਟਰ ਜਾਣਕਾਰੀ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਸੀ ਰਸਾਲੇ. ਇਸ ਵੇਲੇ ਕਈ ਹਨ ਇਮੂਲੇਟਰ ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਕੰਪਿਊਟਰ।

ਮੈਂ ਇਮੂਲੇਟਰ ਡਾਊਨਲੋਡ ਕੀਤਾ ਹੈ trs80gp ਅਤੇ ਪਹਿਲੀ ਵਾਰ ਮੈਂ ਇਹ ਦੇਖਣ ਦੇ ਯੋਗ ਸੀ ਕਿ ਇਹ ਕੰਪਿਊਟਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਬੇਸ਼ੱਕ, ਕੰਪਿਊਟਰ ਕਲਰ ਆਉਟਪੁੱਟ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਸੀ; ਸਕ੍ਰੀਨ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਸਿਰਫ 128x48 ਪਿਕਸਲ ਸੀ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਐਕਸਟੈਂਸ਼ਨ ਅਤੇ ਸੋਧਾਂ ਸਨ ਜੋ ਸਕ੍ਰੀਨ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਨੂੰ ਵਧਾ ਸਕਦੀਆਂ ਸਨ। ਇਸ ਕੰਪਿਊਟਰ ਲਈ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਤੇ ਬੇਸਿਕ ਭਾਸ਼ਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਵਿਕਲਪ ਵੀ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਸਨ (ਜੋ ਕਿ ZX ਸਪੈਕਟ੍ਰਮ ਦੇ ਉਲਟ, ਕੁਝ ਮਾਡਲਾਂ ਵਿੱਚ ROM ਵਿੱਚ "ਫਲੈਸ਼" ਵੀ ਨਹੀਂ ਸੀ ਅਤੇ ਕਿਸੇ ਵੀ ਵਿਕਲਪ ਨੂੰ ਫਲਾਪੀ ਡਿਸਕ ਤੋਂ ਲੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ, ਜਿਵੇਂ ਕਿ OS ਖੁਦ)

ਮੈਂ ਵੀ ਲੱਭ ਲਿਆ ਉਪਯੋਗਤਾ ਆਡੀਓ ਰਿਕਾਰਡਿੰਗਾਂ ਨੂੰ CAS ਫਾਰਮੈਟ ਵਿੱਚ ਬਦਲਣ ਲਈ, ਜੋ ਕਿ ਇਮੂਲੇਟਰਾਂ ਦੁਆਰਾ ਸਮਰਥਿਤ ਹੈ, ਪਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮੇਰੀਆਂ ਕੈਸੇਟਾਂ ਤੋਂ ਰਿਕਾਰਡਿੰਗਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਸੰਭਵ ਨਹੀਂ ਸੀ।

CAS ਫਾਈਲ ਫਾਰਮੈਟ ਦਾ ਪਤਾ ਲਗਾਉਣ ਤੋਂ ਬਾਅਦ (ਜੋ ਕਿ ਮੇਰੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਟੇਪ ਤੋਂ ਡੇਟਾ ਦੀ ਇੱਕ ਬਿੱਟ-ਬਾਈ-ਬਿਟ ਕਾਪੀ ਸੀ, ਇੱਕ ਸਿੰਕ ਬਾਈਟ ਦੀ ਮੌਜੂਦਗੀ ਵਾਲੇ ਸਿਰਲੇਖ ਨੂੰ ਛੱਡ ਕੇ), ਮੈਂ ਇੱਕ ਬਣਾਇਆ. ਮੇਰੇ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਕੁਝ ਬਦਲਾਅ ਅਤੇ ਇੱਕ ਕਾਰਜਸ਼ੀਲ CAS ਫਾਈਲ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਨ ਦੇ ਯੋਗ ਸੀ ਜੋ ਏਮੂਲੇਟਰ (TRS-80 ਮਾਡਲ III) ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਸੀ:

ਮੈਂ ਪਰਿਵਰਤਨ ਉਪਯੋਗਤਾ ਦਾ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਪਹਿਲੀ ਨਬਜ਼ ਦੇ ਆਟੋਮੈਟਿਕ ਨਿਰਧਾਰਨ ਅਤੇ ਇੱਕ GEM ਪੈਕੇਜ ਦੇ ਤੌਰ 'ਤੇ ਹਵਾਲਾ ਦਾਲਾਂ ਵਿਚਕਾਰ ਦੂਰੀ ਦੇ ਨਾਲ ਤਿਆਰ ਕੀਤਾ ਹੈ, ਸਰੋਤ ਕੋਡ ਇੱਥੇ ਉਪਲਬਧ ਹੈ GitHub.

ਸਿੱਟਾ

ਜਿਸ ਮਾਰਗ 'ਤੇ ਅਸੀਂ ਸਫ਼ਰ ਕੀਤਾ ਹੈ ਉਹ ਅਤੀਤ ਵਿੱਚ ਇੱਕ ਦਿਲਚਸਪ ਯਾਤਰਾ ਬਣ ਗਿਆ, ਅਤੇ ਮੈਨੂੰ ਖੁਸ਼ੀ ਹੈ ਕਿ ਅੰਤ ਵਿੱਚ ਮੈਨੂੰ ਜਵਾਬ ਮਿਲਿਆ ਹੈ। ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਵਿੱਚ, ਮੈਂ:

• ਮੈਂ ZX ਸਪੈਕਟ੍ਰਮ ਵਿੱਚ ਡਾਟਾ ਸੇਵ ਕਰਨ ਲਈ ਫਾਰਮੈਟ ਦਾ ਪਤਾ ਲਗਾਇਆ ਅਤੇ ਆਡੀਓ ਕੈਸੇਟਾਂ ਤੋਂ ਡਾਟਾ ਬਚਾਉਣ/ਪੜ੍ਹਨ ਲਈ ਬਿਲਟ-ਇਨ ROM ਰੁਟੀਨ ਦਾ ਅਧਿਐਨ ਕੀਤਾ।
• ਮੈਂ TRS-80 ਕੰਪਿਊਟਰ ਅਤੇ ਇਸ ਦੀਆਂ ਕਿਸਮਾਂ ਤੋਂ ਜਾਣੂ ਹੋ ਗਿਆ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦਾ ਅਧਿਐਨ ਕੀਤਾ, ਨਮੂਨਾ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਮਸ਼ੀਨ ਕੋਡਾਂ ਵਿੱਚ ਡੀਬੱਗਿੰਗ ਕਰਨ ਦਾ ਮੌਕਾ ਵੀ ਮਿਲਿਆ (ਆਖ਼ਰਕਾਰ, ਸਾਰੇ Z80 ਮੈਮੋਨਿਕਸ ਮੇਰੇ ਲਈ ਜਾਣੂ ਹਨ)
• ਆਡੀਓ ਰਿਕਾਰਡਿੰਗਾਂ ਨੂੰ CAS ਫਾਰਮੈਟ ਵਿੱਚ ਬਦਲਣ ਲਈ ਇੱਕ ਪੂਰੀ ਸਹੂਲਤ ਲਿਖੀ ਹੈ, ਜੋ ਉਸ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹ ਸਕਦੀ ਹੈ ਜੋ "ਅਧਿਕਾਰਤ" ਉਪਯੋਗਤਾ ਦੁਆਰਾ ਮਾਨਤਾ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੈ

ਸਰੋਤ: www.habr.com