Tape routines: mess in SLOW mode

[Symoon]

Little game for people having an Atmos with ROM 1.1a (the only Oric ROM that checks loading errors during the synchronization of a tape loading).

1- plug the Oric
2- CSAVE"WHATEVER",S (so basically almost saving nothing but synch and header)
3- try loading again with CLOAD"",S

You should ALWAYS get "Errors Found" with ROM 1.1a in slow speed. You can use the attached ROM 1.1a, and try with Euphoric and its hardware tape system (producing WAV files), that's the same although 100% digital.

ROM_Atmos_v1.1a.zip

(12.63 KiB) Downloaded 106 times

Actually, the slow speed (only) tape routines are bugged for the synchro, always producing an error at the beginning (if the signal is read correctly of course ). I'm currently going deep into details hoping to write an explanation, but it's rather tricky to sum up.
I wonder, tough, if it's not the reason why loading errors check is disabled in ROM 1.0, and had to be post-fixed with ROM 1.1b replacing ROM 1.1a.

[iss]

Little game for people having an Atmos with ROM 1.1a ....

This are all people with Pravetz-8D !
Very very interesting!

[Dbug]

Is the ROM version actually written anywhere?
I remember 1.0 and 1.1, but I don't remember having seen on boot 1.1a or 1.1b

[Symoon]

This are all people with Pravetz-8D !
Very very interesting!

I'd be interested if anyone with the real hardware could confirm, since for the moment it's all theory and Euphoric-based test

Is the ROM version actually written anywhere?
I remember 1.0 and 1.1, but I don't remember having seen on boot 1.1a or 1.1b

No it's not. As far as I know, it's the way Fabrice called them when he released Euphoric, and they've been identified in the .ROM file name this way, and referred as such in many discussions. But it's been a silent change from Oric, only the code had been modified.
I haven't checked if it's printed on the ROM itself though.

[Chema]

Yep. I think we made some nice findings when debugging the turbo loading version of Skooldaze. 1.1a (mine) checks for errors but, while it works when loading the actual contents, fails many times detecting errors in the sync signal (or something like that). This is quite frustrating, as loading fails at the end, and many times even if the program was loaded correctly.

To solve this annoying issue, 1.1b is patched to clear the error flag after loading is finished. No error messages. Problem solved.

Which is never a good idea, of course.

[Symoon]

Actually there's, IMO, a bug in a specific slow-speed part of the routines.
At some point in the synch code (for the $16 $16 $16 $16 bytes), the programmers seem to forget that unlike fast speed, in slow speed, a single tape signal period is not a bit, but a fragment of a bit. So they skip two simple signal periods thinking they're skipping a parity bit and a stop bit, when they actually carry on reading the parity bit (which value is always zero for a $16 byte), which messes the synchro and leads to setting an error afterwards.
And luckily, even though they skip the byte reading on tape while they set an error, they read back in zero page the value or the previously read byte, which luckily was a $16 as it's the synch - almost a happy end returning the expected value!

So there you go: bug in code messing synch, mess in reading, setting a synch error, and by luck (or let's say bug) return the right byte value even if nothing was read. What's funny it that they even set a loop to skip stop bits (value 1) but it does nothing as they are still reading a zero bit.
That's in $E745, $E748 and $E74B.
Modifying the BCS in $E74B by a BCC (to actually loop and end the parity bit reading) fixed the loading error with Euphoric ^^

There are also strange things later in the code, I hope to get all this detailed within a week or two (working at it in French so far though, translation will require more time).

EDIT: the comments in l'Oric à Nu also state that the code starting in $E745 is there to skip bits, which is probably the intention, but wrong

[Chema]

Actually there's, IMO, a bug in a specific slow-speed part of the routines.
...

Oh, that is indeed interesting! So this does not affect the fast loading?

So why all the errors in fast loading that ended up with the total removal of the error check?

I could try to test for you, but don't have an easy way to setup something where I can save/load from audio. I will have a look (I have my Oric at the office since my wife decided to paint and add new furniture to the room I was using :/ )

[iss]

In regard of differences between 1.1a vs. 1.1b here they are:

(i.e. no change in the welcome message)
and first part at #E4B6 disassembled:

[Chema]

If I am not wrong that STX $02B1 is what clears the error flag (X is 0).

[Symoon]

Oh, that is indeed interesting! So this does not affect the fast loading?

For this part yes, slow speed only - but I'm not saying all is fine with fast speed - I focused on the synch part while I was studying a special loading routine, and dug this slow part because the comments in l'Oric à Nu felt strange to me. You know the deal: looking for a problem brings another one, and another one...

So why all the errors in fast loading that ended up with the total removal of the error check?

Well that's what I wonder: was it actually really the fast speed errors that lead to this removal, or was it because they realised there were ALWAYS errors in slow mode? (which could explain why they missed it at first). Mmmmh, what I'm saying is a bit stupid maybe, I hope if they noticed the mistake in the slow speed, they would have fixed it

I could try to test for you, but don't have an easy way to setup something where I can save/load from audio.

Don't bother too much, I will search for an Atmos with the right ROM - not sure I got one though, I will have to test.
ISS showed us that a ?PEEK(#E4B8) will give 32 for ROM 1.1a and 2 for ROM 1.1b

[Symoon]

Little game for people having an Atmos with ROM 1.1a (the only Oric ROM that checks loading errors during the synchronization of a tape loading).

1- plug the Oric
2- CSAVE"WHATEVER",S (so basically almost saving nothing but synch and header)
3- try loading again with CLOAD"",S

You should ALWAYS get "Errors Found" with ROM 1.1a in slow speed.

Ok, I have tested on a real Atmos with ROM 1.1a, and...
Everything worked fine

I'll have to go back to my studies I'm afraid

[Symoon]

So, I did the following test:
1- on a real Atmos ROM 1.1a, did CSAVE"RIEN",S and recorded on a PC
2- on Euphoric, did CSAVE"RIEN",S

Loaded test 1 on the real Atmos and on Euphoric: no Errors Found
Loaded test 2 on the real Atmos and on Euphoric: Errors Found!

So my guess is that the slow speed routine code is bugged, but that it might be luckily avoided by the real tape signal form.

I've never been quite sure, on a real Oric, when the emission of a period begins, and when it is read exactly (when is the "positive edge detected" triggered?). This can affect the decoding when a 0 follows a 1, or a 1 follows a 0, meaning that the emitted period doesn't have the same lenght. It had been one of my problems for the slow speed decoding tool, just like shown below:

(the "writing" beginning is just a guess, to show how it can affect the reading afterwards)

EDIT: here's what I see on a real signal:

Cassette_debut_periode.png (8.61 KiB) Viewed 2063 times

Now, just got to go back to heavy thinking

[Dbug]

The edge detection on the real hardware is probably different on the different Oric, some have different output/input volumes because of different resistors values, and the aging capacitors may also change how long it takes to go from low to high to low again.

[iss]

... here's what I see on a real signal ...

What you see is absolutely close to the ideal - good!
Even it's noticeable that the amplitude of the first 3 periods grows 'til input capacitor saturates.
Here is the Tape-in circuit with some sample signal forms - showing how "thing are working":

(imho, the C19 capacitor introduced with MOD#56 is useless).

EDIT: In common, relative to the very input signal it's "zero cross" detector schematic,
so the "positive edge" is detected when the signal rises above 0V .

[Symoon]

Thanks a lot for the translation of the electronics

What you see is absolutely close to the ideal - good!

Cool, but actually what you show in your picture is that it is supposed to go up first?

EDIT: In common, relative to the very input signal it's "zero cross" detector schematic,
so the "positive edge" is detected when the signal rises above 0V .

Does that mean it should be rather early when the signal goes "up again"? (knowing that, like Dbug said, it could depend on each machine). That would be fine with the example where I wondered where it began: it seems the earlier it is, the closer to the writing it is.