forum.defence-force.org

Amazing indeed! And totally crazy

Well done!

11KB/s with full broadcast mode, that's kind of cool

I guess I will have to come up with some additional PictConv modes optimized to support split rendering or multi-color.

This greyscale demo is amazing. Very smart example of a new usage!

Annoying RAM Overlay (MAP signal) failure - interesting moments to watch are 00:02:50 and 00:04:40:


While Oric #3 is rock solid, after some time Oric #1 and #2 start to give errors when accessing addresses in the enabled RAM Overlay.
The explanation is clear - things get hot and this changes the timing of the MAP signal. I will add trimmers for easy adjusting so all work properly in (at-least) 24h burn test .

One conclusion here:
Any device which need to work with the RAM Overlay with any Oric should allow adjustment of the MAP signal (period).

iss wrote: ↑Thu Apr 18, 2019 9:47 pm One conclusion here:
Any device which need to work with the RAM Overlay with any Oric should allow adjustment of the MAP signal (period).

Is that maybe what the Microdisc RV1 is for?

Dbug wrote: ↑Fri Apr 19, 2019 8:20 amIs that maybe what the Microdisc RV1 is for?

Yes, exactly in Microdisc RV1 does the job.

If it is linked with the system warming, I would look for capacitors which could start to fail, or simply it is one of the RAM chip which is starting to fail.

You should test these ORICes independently with a long memory test to check if there is no chip that is on the verge of failing

Wow, @Godzil welcome back!

It's not the RAM - the same test runs for hours without errors when accessing low addresses (i.e. 0000-C000), only if MAP is active then after some period of time fails start to happen. I'm using 74LS123 and the Cext are new and stable tantalum capacitors.
But as I said - adding trimmers solved the problem. Interesting is also that changing randomly CPU, RAM, ULA one can achieve working configuration, but this is just 'private case' solution - that's why I said in my previous post - for universal solution there should be a trimmer (or something with the same functionality ... more in my next HW project ).

Could you briefly explain what a "trimmer" is in this context? I assume it's not related to cutting branches on trees or making one's facial hair looking nice

It's trimpot or trimmer potentiometer

Well, the OricExos has its emulator!
Thanks to @Xeron for the well made Oricutron source code it was relatively easy to make it emulate OricExos.

Ready to use binaries can be downloaded from HERE.
Usage: unpack and start oricexos executable, press F1 for menu, '0' (zero) to select any dsk image from examples in 'disks' sub-directory ... sit back, relax and enjoy!

The modified emulator sources are available in OricExos github repo.
Soon there will be an update:
- 'virtually connect' the master tape-out to slaves's tape-in (this will allow to run the first series of examples);
- implement the 'R-2R thing' mixer;
- audio mixer (?).

So, now everyone can contribute with demos and examples!
Any feedback and comments are highly anticipated and appreciated! Be active...

Ahahah, crazy stuff, I love it! Great effort.

iss wrote: ↑Mon Apr 29, 2019 11:07 pm Well, the OricExos has its emulator!
(...)
So, now everyone can contribute with demos and examples!
Any feedback and comments are highly anticipated and appreciated! Be active...

Damn you, I was planning to spend 1st of may finishing my batch of Oric floppy labels!

Which reminds me that I wanted to have a custom logo for the Exos, maye that could just be the normal Oric logo, but with 3 shadows, one in each primary color (or gradients), to indicate it has 4 times the Oric power?

So, regarding this emulator build, it is not a new "exos mode" in Oricutron, it's actually a dedicated version of Oricutron that always boot in Exos mode, correct?

I downloaded the emulator and played a bit with your demos.

Two things I'm wondering about:
- It looks like the hard reset (F4) does not reset the three slave machines, so you get some fancy multiprocessing happening with the tesseract demo continuing to move in the background, overlaid on whatever you do on the main machine (DIR, LIST, ...)
- It looks like the default mode is "half bright" (with "OricExos" 123 shown on top) so normal Oric applications look much darker, is there some value to poke somewhere to enable the OR mode with normal intensity?

Dbug wrote: ↑Tue Apr 30, 2019 6:44 am So, regarding this emulator build, it is not a new "exos mode" in Oricutron, it's actually a dedicated version of Oricutron that always boot in Exos mode, correct?

Absolutely correct - it's OricExos dedicated version and I think this the right way to go - no need to "damage" main Oricutron sources.

Dbug wrote: ↑Wed May 01, 2019 9:36 am - It looks like the hard reset (F4) does not reset the three slave machines, so you get some fancy multiprocessing happening with the tesseract demo continuing to move in the background, overlaid on whatever you do on the main machine (DIR, LIST, ...)

True! And this is just like the real hardware works - we have 2 resets - first one is common for the 4 Orics and it ensures they run synchronized just after power-up. The 2nd one is only for the master Oric and comes from Cumulus! So we can have 3 slave Orics running "in background" and independent master for user interactions! .

Dbug wrote: ↑Wed May 01, 2019 9:36 am - It looks like the default mode is "half bright" (with "OricExos" 123 shown on top) so normal Oric applications look much darker, is there some value to poke somewhere to enable the OR mode with normal intensity?

Well spotted! For now I modified only the file render_sw.c and only for 32bpp (later will add support for 16bpp (if needed?)).

The related portion of code is mix32(...) and I added a function above it mix32_correction(...) to make "artificially" result more brighter for better visibility - this is different from real hardware, where it is just: You can experiment with different values (the current one are taken from the void ).
Actually, this is what I'm doing now - thinking is it worth to make a "non linear amplifier" for the real machine.
The idea is (speaking only(!) for 'direct' mix mode which is the default after boot)
to rise the brightness of lower values so the image is more visible like this:

Here is the simulation (green middle bottom trace) - it looks complex but it will be easy to implement.

And one more detail when making demos: in emulator the master Oric boots from disk and loads main program lot faster than with real cumulus, so one need to put a delay(1-2 seconds) at very beginning of the code to allow 3 slave Orics to make their full memory test.