forum.defence-force.org

iss wrote: ↑Sun Feb 10, 2019 1:28 pmI spotted just one thing which seams like bug:
NL-branch.png
IMO the "+5" should be "+6", right?

iss wrote: ↑Sun Feb 10, 2019 1:28 pmThe source compiles fine under Linux with GCC (just 2-3 harmless warning - no problem at all) and the tool works nice.

Symoon wrote: ↑Sun Feb 10, 2019 2:19 pmIt seems I get this bug since the very beginning. Strange, how can it have not crashed when I was running the code on ROM 1.0? does the op code $13 act like a NOP ?

NekoNoNiaow wrote: ↑Tue Feb 12, 2019 1:13 am How long is the loader (in bytes)?

NekoNoNiaow wrote: ↑Tue Feb 12, 2019 1:13 am Could you store it in a darkened part of graphic memory and then wipe it entirely once the loading is done?

iss wrote: ↑Sat Feb 16, 2019 9:53 pmI'm still not familiar with the Novalight code - it's complex and requires lot concentration.

iss wrote: ↑Sat Feb 16, 2019 9:53 pmBut this 7 bytes should be needed only if the next part starts with the standard header, right?
I'm not sure but maybe it makes sense to have a kind of synchronization between parts... and 7 bytes are not so much

Symoon wrote: ↑Sun Feb 17, 2019 9:17 am Estimated time saving for Zorgons Revenge: from 14.5s, it would end around 13.7s. Quite good for 6 bytes!
Ok, just got to:
- modify the signal generation and confirm if it's a positive change

Chema wrote: ↑Sun Feb 17, 2019 9:22 pm almost black magic.

Jack_Free wrote: ↑Thu Feb 21, 2019 11:14 am It does not work under WIN7 64bit.
Is there a solution to work on this system?
Thank you.

error Access Denied

Symoon wrote: ↑Sun Feb 17, 2019 9:17 am I found something whose decoding could fit in 6 bytes/8µs: back to one of the starting ideas of Novalight which was bit compression.
The 1111 sequence is coded by 6 + 6 samples. The idea is to use 7 samples instead of 6+6.

Ok, just got to:
- modify the signal generation and confirm if it's a positive change
- remove the 7 bytes and see if it still works
- add the 6 bytes for decoding
- test

Symoon wrote: ↑Sat Feb 23, 2019 4:26 pm To sum it up, the best choice is the one where (removed_length - added_length) is maxmized. My main problem is that I don't know the added length since it depends on the choice of what I choose to remove.

Symoon wrote: ↑Sat Feb 23, 2019 1:20 pm Are there any mathematicians aroud? I think my dictionary in Novalight can be optimized.

Symoon wrote: ↑Sat Feb 23, 2019 1:20 pm What I'm doing now (the RLE compression has already been performed and the concerned bytes are ignored):
1- calculate the time taken by each uncompressed byte in the Novalight signal, which is: occurencies*encoding time. For instance, if "Z" lasts 19 samples, and is present 100 times in the TAP file, its total time is 19*100 = 1900
2- the dictionary has 14 entries, so I take the 14 highest "total times" calculated. This way I'm removing a maximum of time from the uncompressed signal.
3- in the dictionary, each entry will last a different time (between 9 and 16 samples), so I'm optimizing the dictionary assignation: among the 14 bytes, the bytes with the highest occurencies, will be assigned to the shortest new encoding time. This way, I'm minimizing the new time I re-insert in the signal.

Symoon wrote: ↑Sat Feb 23, 2019 1:20 pm For instance: in a TAP file, a byte "A" that lasts 22 samples is present 4 times, and another one "B" that lasts 12 samples is present 8 times.

Code: Select all

A: 22 *4 = 88
B: 12*8 = 96	total 96+88= 184

If I pick up "B", as it is the longest time in the signal (removing 96 samples insted of 88 if I had taken "A"), I get this in the final signal:

Code: Select all

4*8 = 32; 32 + 88 = 120 samples

But if I had taken "A", removing less time from the original signal, I get this in the end:

Code: Select all

4*4 = 16; 16 + 96 = 112 samples

Which is better!
So I save time with my method but it may not be optimal... But I really can't figure how to calculate the best result. What is the best way to do? Is there a magic formula, with 256 possibles bytes combined in 14 possible bytes of a dictionary?

 gain(A) = current_cost(A) - cost_if_encoded(A) = 88 - (4 * 4) = 88 - 16 = 72
 gain(B) = current_cost(B) - cost_if_encoded(B) = 96 - (4 * 8) = 96 - 32 = 64

A : 22 samples, present 4 times => cost(A) = len(A) * freq(A)
                                              22       4

gain(A) = cost(A) - cost_if_encoded(A)

cost_if_encoded(A) = encoded_len(A) * freq(A)

gain(A) = (len(A) * freq(A)) - (encoded_len(A) * freq(A))

gain(A) = freq(A) * (len(A) - encoded_len(A))

gain(A) = 4 * (22 - 4) = 4 * 18 = 72
gain(B) = 8 * (12 - 4) = 8 * 8 = 64

count * (nb_samples - nb_encoded_samples)

NekoNoNiaow wrote: ↑Fri Mar 01, 2019 4:56 am So in your case:

Code: Select all

gain(A) = 4 * (22 - 4) = 4 * 18 = 72
gain(B) = 8 * (12 - 4) = 8 * 8 = 64

So, just compute for each candidate, the value

Code: Select all

count * (nb_samples - nb_encoded_samples)

and take the one with the biggest value.

NekoNoNiaow wrote: ↑Sat Mar 02, 2019 6:13 pm Think about it this way:
The best choice for the first selection in the dictionary is the byte with the biggest gain, right?
This much is obvious. So the first choice is a no brainer.

In the end, if you have n bytes to put in the dictionary, then you only need to apply that method n times, no need to test every combination since you have a method that gives you the best choice at every step.

This is exactly how entropy coding works, if you sort bytes by their frequency * size in decreasing order, and give the corresponding place in the dictionary in that same order (with encoded length increasing progressively in the dictionary) then you have the most optimal encoding possible.

In any case: ditch the average computation, it does not work

Symoon wrote: ↑Sat Mar 02, 2019 9:37 pm

NekoNoNiaow wrote: ↑Sat Mar 02, 2019 6:13 pm Think about it this way:
The best choice for the first selection in the dictionary is the byte with the biggest gain, right?
This much is obvious. So the first choice is a no brainer.

You're right if you consider the gain as the time removed less the time added with the dictionary encoding. But you don't know this dictionary time yet since you don't know the position of your byte in the dictionary... So you can't know the exact gain at this first step, so you can't know if it's worth being selected for the dictionary

gain(candidate) = freq(candidate) * (length(candidate) - dictionary_length)

Symoon wrote: ↑Sat Mar 02, 2019 9:37 pm

In the end, if you have n bytes to put in the dictionary, then you only need to apply that method n times, no need to test every combination since you have a method that gives you the best choice at every step.

Yep but I just don't know how to calculate the 1st step; I may be misunderstanding you, but for me finding the real optimal choice forbids splitting the problem into different steps!
That's what I did 1st, and it showed I was wrong.

Symoon wrote: ↑Sat Mar 02, 2019 9:37 pm

This is exactly how entropy coding works, if you sort bytes by their frequency * size in decreasing order, and give the corresponding place in the dictionary in that same order (with encoded length increasing progressively in the dictionary) then you have the most optimal encoding possible.

Potentially wrong :p

Symoon wrote: ↑Sat Mar 02, 2019 9:37 pm Imagine you have A, lasting 10 and repeated 1000 times. That makes 10000. You'll consider it as a better choice than B lasting 90 and repeated 110 times (which is 9900).
So you select A. Imagine it's the 14th byte you selected (14th in the final decreasing order). So you drop B, no more room in the dictionary.
And then you have the new value for A, lasting 6. So you removed 10000, and now add 6*1000 = 6000. Gain = 10000-6000 = 4000.
What if you had chosen B ? Removing 9900, and adding 6*110 (660) = a gain of 9240 instead of 4000. That's much better, because your 1st step didn't take into consideration the real potential gain, but just what you removed, which is not always optimal.

Symoon wrote: ↑Sat Mar 02, 2019 9:37 pm

In any case: ditch the average computation, it does not work

It did give a better result with Zorgons Revenge by selecting a byte instead of another
To be honest I thought about this problem for about 2 or 3 days and changed my mind almost every hour I also found myself silly when I typed this "-13" in the code, but it did give a shorter loading time

NekoNoNiaow wrote: ↑Sat Mar 02, 2019 11:39 pm For every empty entry in the dictionary

Symoon wrote: ↑Sun Mar 03, 2019 12:12 am

NekoNoNiaow wrote: ↑Sat Mar 02, 2019 11:39 pm For every empty entry in the dictionary

Aaaah, this is the key that I missed! I kept willing to have the right order before assigning to the dictionary... Sorry it took so long to understand, I feel stupid
It all makes sense now, thanks a lot
I'll give it a try

normal_gain_over_two_entries = entry1_c1 + entry2_c2
inverted_gain_over_two_entries = entry1_c2 + entry2_c1

NekoNoNiaow wrote: ↑Sun Mar 03, 2019 3:46 am I must apologize again for insisting that my method was optimal when the data proves me completely wrong.

Symoon wrote: ↑Sun Mar 03, 2019 8:02 am

NekoNoNiaow wrote: ↑Sun Mar 03, 2019 3:46 am I must apologize again for insisting that my method was optimal when the data proves me completely wrong.

Please don't, this problem is evil (and I also tend to read a bit fast too as I work on short-spare-times).

Symoon wrote: ↑Sun Mar 03, 2019 8:02 am BTW, I also realize maybe I should have given more details of the real values with Novalight:
- each "normal" byte is encoded between 17 and 29 samples (actually 5+4*[3;6])
- each entry of the dictionary is encoded between 9 and 16 samples (actually [6;7]+[3;9])

So dictionary lengths are, from 1st to 14th position: 9, 10, 10, 11, 11, 12, 12, 13, 13, 14, 14, 15, 15, 16.
This way:
- we are sure any byte can be selected in the dictionary and be shorter
- maybe calculating with a two steps depth can be neglected as the gain would really be minimal with such dictionary lengths, which makes your 1st solution really good enough? (that's probably also why using an average seem to give good results, which would not with much more difference between the 1st and the last)

NekoNoNiaow wrote: ↑Mon Mar 04, 2019 12:35 amMay I ask what determine these sizes? Both the non encoded byte sizes and the sizes of dictionary encoded bytes.

Coding format in WAV signal:
Sinusoid 1 length in samples		Sinusoid 2 (and if required, 3, 4 and 5) length in samples
3	Stop
4	(unused)
5	Start normal byte		3	00 \			
	(Oric needs at least		4	01 |__ Four times to code a byte	
	 5 samples time to work)	5	10 |			
					6	11 /
					7	1111 -- replaces 6+6 samples for 1111 bits
6	Start byte from dictionary 1	[3;9]: byte position in dictionary
7	Start byte from dictionary 2	[3;9]: byte position in dictionary
8	Start repeat previous byte	RLE; for N repeats: (N-1)*3 + 4  (4 being for the last repetition)
9	End of program

Symoon wrote: ↑Fri Mar 08, 2019 6:07 am- try adding a memory relocation if a loading in page 1 is detected (actually, should I make it automatic of set up a user option to choose the memory page?)

Chema wrote: ↑Mon Feb 25, 2019 11:36 pm Well, in fact what I have is the first Atmos ROM version, which does the right thing, and it is not bugged It checks for errors and stops loading if it finds them. What the Oric people did, after realizing that there were loading errors still, was to remove the error checking altogether in the second version 1.1b!

That is what the small program does... sets the IRQ vector to point to a small routine that clears the error flag... good job guys!

iss wrote: ↑Sat Mar 09, 2019 5:03 pm For the poll: If it's not too difficult - detect and discard it during WAV generation.
Here is the quick disassembly of ALC.
It intercepts the IRQ and clears the error flag - so not useful (especially) with Novalight I think.

NekoNoNiaow wrote: ↑Sun Mar 03, 2019 3:46 am

Symoon wrote: ↑Sat Mar 16, 2019 1:54 amI tend to think we are close to perfection with your initial selection: frequency*gain (which means calculation for each dictionary entry), and with my final optimisation which is just sorting again by freqency the 14 selected items, avoiding this "do I switch my choice or not" step during the selection.

Symoon wrote: ↑Wed Mar 27, 2019 11:23 am PS: ISS, unless someone finds bugs, I don't plan to change Novalight anymore, not before a while I mean
So you can go for it with TapOric

Symoon wrote: ↑Sat Mar 16, 2019 1:54 am After a rest, I'm back to this dictionary matter.
[snip]
If you look at your Novalogic table BTW, it seems each time you choose to invert the selection order of two values, the 2nd one actually has more occurencies (is it just by chance, I don't know! Only exception is the last "TRUE" which I actually don't understand why it says "TRUE" ).

Symoon wrote: ↑Sat Mar 16, 2019 1:54 am You also can see that, from the new signal length point of view, it's obvious that it would be much better to use "I" (frequency 940) from 3rd or 2nd, to 1st position, than K (frequency 860)
=> 940*4+860*6=8920, is better than K 1st and I 2nd: 940*6+860*4=9080

=sum(large(D$2:D$16,1),large(E$2:E$16,2))-sum(large(D$2:D$16,2),large(E$2:E$16,1)) < 0

Symoon wrote: ↑Sat Mar 16, 2019 1:54 am So I wonder if the problem solution could not actually be simplified/optimized:
1- remove the biggest frequency*gain for the first 13 values: if a choice had to be inverted, it will be selected next anyway

Symoon wrote: ↑Sun Mar 31, 2019 5:46 pm To be honest, I tried all the solutions we talked about and always found a program which ended being slower
So after a full day/night spent on it for a difference of something like 0.005s, I ended up choosing to keep a simple code and make a break with this - really needed to.

I'm working on another optimization which, should it work, may save (I hope) about 1 second for Zorgons Revenge. And it changes the dictionary too :p

• 1 = simply take the best candidate at each round, that is explore only one branch of the combinatorial tree (1 over n! possible choices).
  This is simply the greedy strategy I initially recommended.
• 2 = explore two branches of the tree, that is explore n!/(n-2)! choices (for n = 100 that is 100 * 99 = 9900 explorations.
• 3 = explore three branches of the tree, n! / (n-3)! choices (for n = 100, = 100 * 99 * 98 = 970200)
• ...
• n = explore n branches of the tree : n! choices (for n=100 that's 9.33e+157 choices )

• a mix of c and c++ idioms
• untested, just written in an editor and a sheet of paper

struct S_Element {
  int id;   // uniquely identifies this element
  int freq;
  int size;
};
struct S_Examined {
  int id;   // comes from S_Element.id, is used to identify S_Element-s.
  int gain;
};
struct S_Chosen {
  int totalgain;
  std::list<S_Examined> elements;
};

// Ugly globals.
int DictionarySizes[] = { 4, 6, 9, 14, 21, 32, 48, 72 }; // replace with real values.
int DictCount         = 8;                               // replace with real values.
int UsedDictEntries   = 0;

int main(argc, argv)
{
  int maxWidth = atoi( argv[1] );  // run as "carrot.exe <width>"

  std::vector<S_Element> candidates;
  candidates.push_back( { /* A */ 0, 800,  50, /*bytes...*/ } ); // invalid syntax but you get the idea
  candidates.push_back( { /* B */ 1, 390, 180, /*bytes...*/ } );
  candidates.push_back( { /* C */ 2, 280, 160, /*bytes...*/ } );
  candidates.push_back( { /* D */ 3, 430,  10, /*bytes...*/ } );
  // and so on...

  if (maxWidth > candidates.size())
  {
    maxWidth = candidates.size(); // Do not explore more choices than exist.
  }
  if (maxWidth > DictCount)
  {
    maxWidth = DictCount; // No need to return more results than dictionary entries.
  }

  S_Chosen chosen = ChooseElements( DictionarySizes, &candidates[0], candidates.size(), maxWidth );

  double examinedCount = Factorial(maxWidth);
  examinedCount *= examinedCount; // Because we are re-examining all entries at each step.
  double totalCount = Factorial(candidates.size());
  totalCount *= totalCount;
  printf("Examined %.2f combinations out of a total of %.2f.\n", examinedCount);
  printf("Size reduction obtained: %d\n", chosen.totalgain);
  printf("Fill your dictionary with (in order):\n");
  for (auto it = chosen.elements.begin() ; *it ; ++it )
  {
    printf("id %d\n", (*it).id);
  }
}

long Factorial(int n)
{
  // Note: this might overflow, do not use too large values of width.
  double top = 1.f;
  for (int i = 2 ; i <= n ; i++ )
  {
    top *= (double)i;
  }

  return top;
}

bool CompareElements(S_Examined const& a, S_Examined const& b)
{
  return a.gain < b.gain; // Sort by increasing gain.
}

S_Chosen ChooseElements( const int* const dict, const S_Element* const candidates, int count, int width )
{
  S_Chosen chosen; // Will be returned with RVO so declared first is better.
  chosen.totalgain = ~0; // largest negative number, can also use std::limits<int>::Min() or something like that.

  if (count == 0 || width == 0)
  {
    chosen.totalgain = 0; // No candidates or dictionary entries, return an empty list.
    return chosen;
  }

  std::vector<S_Examined> examined;

  for (int c = 0 ; c < count ; c++)
  {
    // Compute the gain obtained by encoding this candidate in the first spot of the dictionary.
    S_candidate& cand = *candidates[i];
    int gain = ComputeGain(dict, cand);
    examined.push_back( { c, gain } );  // Add to vector for sorting.
  }

  // We sort by gain, this allows us to make the greedy choice of "best immediate candidate"
  // when we are asked to examine the minimum number of choices (width = 1).

  std::sort(examined, CompareElements); // Sort by gain, highest last.

  // Below is the loop where we examine "width" possible branches starting from the
  // current best gain candidate. If width is 1, then we only examine the first best
  // candidate, if width is 2, then we examine the two best candidates,
  // if width == count, then we examine all possible candidates.

  int index = count - 1;
  S_Examined current = examined.last();
  examined.pop_back();  // Remove from the array (since we are choosing it for the first iteration).

  do
  {
    // Obtain the rest of the entries to put in the dictionary (recursive call).
    std::vector<S_Element>&
    S_Chosen rest = ComputeGains( dict + 1, &examined[0], count - 1, width - 1 );

    // If this returned list has better or equal total gain than the current one, we choose it.
    if (current.gain + rest.totalgain >= bestTotalGain)
    {
      chosen.totalgain = current.gain + rest.totalgain;
      chosen.elements.swap(rest);
      chosen.elements.push_front(current);
    }

    // Get the "next current" and place the "current current" back into the vector in its place.
    S_Examined next = examined[--index];
    examined[index] = current;
    current = next;

  } while (width-- >= 0); // We do at least one run of that loop.

  return chosen;
}

int ComputeGain( int* dictionary, S_Element& element)
{
  // Note: this could be negative
  int gain = element.freq * (element.size - dictionary[0]);

  return gain;
}

Symoon wrote: ↑Mon Apr 22, 2019 6:36 am The decoding is probably too demanding, there's actually only a 3µs margin left on emulators, and I suppose real hardware doesn't cope with it. Hey, that's a difference between real machines and emulators

Symoon wrote: ↑Mon Apr 22, 2019 6:36 am That's too bad, it really was opening doors to new things, but I suppose it has to stop at some point! Also, this very last version put the whole interrupt in page 2 (to save a JMP, 3µs), which was already risky as version 1.1 showed.

NekoNoNiaow wrote: ↑Mon Apr 22, 2019 9:36 pm

Symoon wrote: ↑Mon Apr 22, 2019 6:36 am The decoding is probably too demanding, there's actually only a 3µs margin left on emulators, and I suppose real hardware doesn't cope with it. Hey, that's a difference between real machines and emulators

Is this the case for all emulators? Out of curiosity which ones did you try?
Also, I guess you could submit the issue to emulator writers since I suppose they would be happy to know when the emulators are not accurate.

NekoNoNiaow wrote: ↑Mon Apr 22, 2019 9:36 pm Have you implemented the combinatorial exploration algorithm I posted some time ago? It should definitely help create smaller files.

Symoon wrote: ↑Wed Apr 24, 2019 9:45 am Yes!

Symoon wrote: ↑Wed Apr 24, 2019 9:45 am Only drawback: it's apparently not working on Euphoric anymore.

NekoNoNiaow wrote: ↑Sat Apr 27, 2019 3:19 am

Symoon wrote: ↑Wed Apr 24, 2019 9:45 am Only drawback: it's apparently not working on Euphoric anymore.

Then tell F. Frances to fix Euphoric! If it works on real hardware and not emulators, the fault lies with the emulator, not your code.

And in any case, you should also tell the Oricutron guys to fix it as well if it does not behave like the actual hardware.
If the emulator was correct, you would have detected the issue while using it and it would have been much easier to debug.

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

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.

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.

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

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!

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.

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.

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...

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!

Symoon wrote: ↑Wed May 22, 2019 12:47 pm One of the ideas might be, instead of a dictionary for a whole program only, to use a part of the dictionary for a sub-disctionary for each page loaded. (...)
It has to be checked is if the loading time of those 6 bytes saves actually time with the gain thanks to this dictionary.

NekoNoNiaow wrote: ↑Wed Jun 12, 2019 12:41 am So many improvements one after another that I am now officially completely lost as to what the actual progression is.

Also, I still do not understand why you modify your code to also work with Oricutron, I think you should definitely not do so.

Symoon wrote: ↑Wed Jun 12, 2019 6:38 am

NekoNoNiaow wrote: ↑Wed Jun 12, 2019 12:41 am

Also, I still do not understand why you modify your code to also work with Oricutron, I think you should definitely not do so.

That's because it's a major debugging tool for me
Euphoric already doesn't work anymore, and without Oricutron I'd be blind to understand what happens in case of failure (even with it, it's not so easy )

NekoNoNiaow wrote: ↑Thu Jun 13, 2019 3:21 am

Symoon wrote: ↑Wed Jun 12, 2019 6:38 am That's because it's a major debugging tool for me
Euphoric already doesn't work anymore, and without Oricutron I'd be blind to understand what happens in case of failure (even with it, it's not so easy )

Can I strangle you? With all my love?
I understand that it is useful when the hardware and emulator behave the same, but when Oricutron is not accurate then your debugging is not either.

One thing that would solve it though: debugging the original hardware via a minimal hardware interface between your PC and the Oric.
On consoles (PS4, Xbox, Switch, etc.) we use devkits which allow to remote-debug and trace directly on the original hardware from our dev PCs, if the Oric expansion connector exposes the signals necessary to freeze the CPU, it should be possible to do the same with a relatively minimal hardware interface (an Arduino or a Raspberry PI would be more than enough).
And maybe Jede's current WIP expansion may be able to be used for that purpose?

Symoon wrote: ↑Thu Jun 13, 2019 6:47 am Ha ha, wait wait wait
I'm not talking about validating new improvements. For this, of course I use real Orics, about 5 of them!
I'm talking about debugging my code in which I often make mistakes in a new version
Novalight code is self-modifying, it's a real hell (for me) to follow on paper and change it being sure I'm not breaking anything, especially when I can only work on it half an hour every 8 days. So being able to reach any part of the code in a monitor and execute it step by step really saves time

Symoon wrote: ↑Thu Jun 13, 2019 6:47 am

One thing that would solve it though: debugging the original hardware via a minimal hardware interface between your PC and the Oric.
[...]
And maybe Jede's current WIP expansion may be able to be used for that purpose?

Well if there's something that can help me seeing the VIA state and stop the incoming WAV file after each instruction (so I can measure the time after each of them), I'd buy it

NekoNoNiaow wrote: ↑Tue Jun 18, 2019 1:12 pm

Symoon wrote: ↑Thu Jun 13, 2019 6:47 am Well if there's something that can help me seeing the VIA state and stop the incoming WAV file after each instruction (so I can measure the time after each of them), I'd buy it

I am not sure I correctly understand your needs, can you elaborate a bit?
To me, it seems that what you want is:
- assuming the wav file is represented by a stream of analog values sent to the VIA's input pin
- that this stream can be frozen at the same time as the CPU and VIA so you can inspect values (current time, etc.) while step-tracing through your code

Is this correct?

Symoon wrote: ↑Thu Jun 20, 2019 9:10 am Well I was describing what I'm doing with Oricutrion, which helps a lot: executing my new code step by step while it reads the WAV file I just produced with a beta version of Novalight.
The code can be wrong, but the WAV file too (I'm sometimes changing the signal).
I can't see how to do on real hadware, especially since the WAV file would carry on playing while I'd be watching a monitor.

Doing this helped me debugging, and optimizing, finding when I have spare execution time I could use (the goal being to minimize the time spent by the Oric "waiting" for the VIA to detect the next pulse). It also helps me understanding when I've been too optimistic on some treatments, which last too long and lead to information loss. Not forgetting that Oricutron is more optimistic than the real harware that requires more time.

Symoon wrote: ↑Sat Oct 26, 2019 7:53 pm Seems something's wrong between Pulsoids TAP version and Novalight.

Symoon wrote: ↑Fri Nov 20, 2020 9:46 amHope I can get back to it soon

iss wrote: ↑Sat Oct 21, 2023 3:54 pm

Symoon wrote: ↑Fri Nov 20, 2020 9:46 amHope I can get back to it soon

Any chance for 1.3 in 2023

iss wrote: ↑Sat Oct 21, 2023 3:54 pm FYI, aside joking, I'm playing with Novalight 1.2a trying to make it work in real-time....