forum.defence-force.org

Ha ha, thanks for the explanation

Chema wrote: ↑Sun Apr 28, 2019 7:42 am In the last version I included a Press Key To Start just to avoid that, not sure if you tried and old version or pressed a key.

There is the "press a key" at start indeed! Not sure what happened there, anyway the loading probably wasn't 100% good so it could be anything
EDIT: actually it was probably loaded 100%, but Novalight was waiting for one or two last sinusoids, which it got when I pressed an Oricutron key. And then Oricium carried on the same way with the sound input (the initial message being actually "insert vsync cable or press a key").

BTW Oricium's scrolling on a CRT screen is really a killer.

Ok, back to Novagliht 1.3. Corrected a few bugs:
- a new threshold for v1.3 wasn't correctly set for real machines
- making "start-stop-bit" shorter required an additional wait between the two last loaded parts

Facing other problems now:
- on real machines, the 4-bits compression ('1111' compressed by 7 samples) seems too long now when ending a byte, still because "start-stop-bit" is shorter in v1.3. Works fine with Oricutron though. Got to see if I remove it when ending a byte, or if I can find another optimisation (don't think I can, I really already changed many things to save as much time as possible)
- got a "?SYNTAX ERROR" with Oricutron when using the standard speed for the loader (works fine on real Atmos and Oric-1!). This one is tough to find why, so far.

Symoon wrote: ↑Sat Apr 27, 2019 8:37 am Also, Euphoric might not be working because I'm using an old computer with XP (not plain DOS), and the difference may be due to slowdowns... As we're talking about 1 or 2µs differences, it might be the problem.

This would still quality as a bug of the emulator, it should work fine even if it is not capable of emulating at full speed.
That is, the timing of the host machine should have no influence on the timing of the guest machine.

Symoon wrote: ↑Sat Apr 27, 2019 8:37 am

NekoNoNiaow wrote: ↑Sat Apr 27, 2019 3:19 am Oh, and by the way, have you published the sources to 1.2?

Of course, I don't release the thing without sources
Good luck reading them though, sorry for that

I tried to get them on the Sourceforge site, but I always get lost on Sourceforge, their organization is such a mess.
Could you post a link to them? Thanks!

NekoNoNiaow wrote: ↑Tue Apr 30, 2019 2:52 am

Symoon wrote: ↑Sat Apr 27, 2019 8:37 am

NekoNoNiaow wrote: ↑Sat Apr 27, 2019 3:19 am Oh, and by the way, have you published the sources to 1.2?

Of course, I don't release the thing without sources
Good luck reading them though, sorry for that

I tried to get them on the Sourceforge site, but I always get lost on Sourceforge, their organization is such a mess.
Could you post a link to them? Thanks!

Just get the ZIP package, the sources are inside
This is Sourceforge's download link (I had to wait for a few seconds before it begins):
https://sourceforge.net/projects/euphor ... p/download

Symoon wrote: ↑Sun Apr 28, 2019 9:13 am Facing other problems now:
(...)
- got a "?SYNTAX ERROR" with Oricutron when using the standard speed for the loader (works fine on real Atmos and Oric-1!). This one is tough to find why, so far.

Ok, I should write more things in my source code. I spent days finding again what I had already found last year:
viewtopic.php?f=19&t=1360&start=120#p17738

The problem is that apparently, when loading a WAV file, Oricutron stops reading the WAV right at the end of the last byte... But doesn't read all the last stop bits that follow this last byte.
So, when it starts reading again the WAV, Oricutron begins by reading apparently the last stop bit, before reading the next program.
So when Novalight begins to load after the standard loader, Oricutron reads the remaining "standard fast speed" stop bit, and it means something else for Novalight, hence the strange behaviour.

I suspected then that on real machines, this didn't happen because the WAV kept playing, hence Novalight would start reading after those standard stop bits have been played. I'm not quite sure of this anymore, but it does work on real machines - it could be what I thought, or simply luck that gives a non-error timing!
I think the real solution would be to set only ONE stop bit for the last standard byte, before the Novalight singal begins (NekoNoNiaow, you were right when saying I should have done something more robust here. Lack of room for code sadly).

Ok, at the moment, playing with stop bits of the last "standard speed byte", I have solution that works on Oricutron but not on real Oric, or on real Oric but not Oricutron.

I sure don't see myself asking Oricutron to keep the WAV file playing like a real tape players does. In fact, I want to sort things out, there's a timing thing on my side as it works fine (luck again?) with F16 speed, but not with standard speed.

Symoon, about the issue with Oricutron turn off both options "Turbo tape" and "VSync hack".
Else keep in mind that Oricutron emulates the raw tape in "granularity" of CPU instruction lengths,
i.e. it's possible that somehow short pulses (with length less than current instruction cycles) are missed.
I'm working now exactly on this problem related to OricExos and I have an idea for a "high precision" emulation mode ,
but this will take some time...

iss wrote: ↑Thu May 02, 2019 11:18 am Symoon, about the issue with Oricutron turn off both options "Turbo tape" and "VSync hack".
Else keep in mind that Oricutron emulates the raw tape in "granularity" of CPU instruction lengths,
i.e. it's possible that somehow short pulses (with length less than current instruction cycles) are missed.
I'm working now exactly on this problem related to OricExos and I have an idea for a "high precision" emulation mode ,
but this will take some time...

Thanks! I should have thought about that; actually, playing with "turbo tape" is bringing more headaches
At the moment, I'm empirically trying to understand what happens. I got a signal that works on Oricutron but not real Oric, and I don't really understand why yet - it should work.
So it brings interesting questions anyway!

Ok, so the problem was that, after a standard speed program, the transition to Novalight wasn't working on Oricutron because of the stop bits (I haven't figured out why it worked with F16 speed actually, probably luck )

=> I tried to remove the stop bits on the very last byte of the "standard speed" program: it worked fine on Oricutron, but failed on real Orics. Still haven't unerstood why: the last parity bit wasn't correctly decoded though the timing on this last bit was correct (see picture below). => I added ONE standard stop bit to this last byte, and it worked again on real Orics... But not on Oricutron anymore

So I finally made a risky optimisation in the code: at the beginning of Novalight decoding, instead of initialising the interrupts and so on, I assume the interrupt flag is set (since Novalight is supposed to always begins with "stop pulses", it should be ok). This saved room allows to begin with TWO initial pulses reading that are trashed, instead of one. This way, the last stop bit is read but not processed, so real Orics and Oricutron are all happy now!

I still don't understand everything clearly but it seems to work fine so far. In the process, I found another 4-bytes possible optimisation (no real timing gain though, but useless code complexity)

Symoon wrote: ↑Sun May 05, 2019 6:07 amSo I finally made a risky optimisation in the code: at the beginning of Novalight decoding, instead of initialising the interrupts and so on, I assume the interrupt flag is set (since Novalight is supposed to always begins with "stop pulses", it should be ok). This saved room allows to begin with TWO initial pulses reading that are trashed, instead of one. This way, the last stop bit is read but not processed, so real Orics and Oricutron are all happy now!

Well, real Orics are actually randomly happy!
This is becoming tiresome, I will switch back to the previous code I think. Anyway Oricutron doesn't require standard speed loading. And actually, the problem could be elsewhere as, still when playing the WAV at 43500Hz, it all runs fine again. Very strange.

You've done a thorough research here, and tried many many different options to squeeze every little bit of loading time. Your work is incredible and I really think gaining yet another 0.001% is not worth it. Unless you are having a really good time by trying

I always thought that Fabrice's tap2CD was the fastest speed possible, but for compression (and your smart trick with encoding 1s and 0s the other way around based on statistics), and you've gone much further.

I find your work here incredible and praiseworthy. Save your energy for other projects, please

Congratulations indeed.

Thanks a lot Chema

The "problem" is that new ideas keep popping up! That, I think, will solve the problems. I got another new one now
Would it be for 0.001, sure, I'd give up. But one full second... It keeps being tempting. One last try maybe

BTW, that still makes me laugh Hey maybe that could be a way to control something (though just one button is not much!)

Lol that's the price to add support for the sync hack... never again

1st successful loading with Novalight 1.3!
Oricium now loads in 15.3 seconds (instead of 16.3 with Novalight 1.2).

Some options are still broken and need to be fixed, and testing on a single file is not enough, so I'm being carfeul with the "happy register" so far. But I'm glad it finally worked, with a significant speed improvement.