Page 2 of 11

Re: OricExos - making the impossible

Posted: Mon Oct 08, 2018 5:30 pm
by ibisum
Yeah, this really, really rocks.

You know what is going to be awesome? Hearing all of those sound chips in sync.

EDIT: can you please do videos, sir, for those of us who haven't yet got the druthers to build the Exo- rig .. yet ..

Re: OricExos - making the impossible

Posted: Mon Oct 08, 2018 6:26 pm
by Dbug
Cool :)

So, in this version, how did you merge the outputs, is it the RGB ladder thing, or pure signal ORing, or???

Re: OricExos - making the impossible

Posted: Mon Oct 08, 2018 11:51 pm
by iss
Here we go:


And screen closeup:
first-demo.jpg
Oric #0 is with PAPER7 which acts like alpha-plane :).
Master loader and slave code in attached zip-file.

The video mixing is "direct connect" like OR-ing but it's not exactly.
In next demo I'll use more colors horizontal+vertical bars then will see what will happen.

Unfortunately the 4-th Oric can't CLOAD by unknown reason - with the original PROM it works fine, but with the UV EPROM it fails :shock: The same UV EPROM works in the other 2 slaves. Anyway, I will switch the bad slave with the master :).

Re: OricExos - making the impossible

Posted: Tue Oct 09, 2018 11:17 am
by Chema
This is astonishing :shock:

I am really excited by the things that beast can do graphically speaking, but I also agree hearing the 4 Orics playing with their AY's together should rock! Literally :) 2 to the left channel, 2 to the right, and all playing different instruments or chords so up to 12 different channels... Uau.

Re: OricExos - making the impossible

Posted: Tue Oct 09, 2018 11:23 am
by Dbug
Chema wrote: Tue Oct 09, 2018 11:17 am hearing the 4 Orics playing with their AY's together should rock! Literally :) 2 to the left channel, 2 to the right, and all playing different instruments or chords so up to 12 different channels... Uau.
Regarding the stereo, I think what would work better (from experience on Stereo YM on the Atari ST and Amiga modules) would be to have 2 chips playing in the center, one playing left, and one playing right.

Pretty much all the Amiga song you can listen on Youtube have been remixed to have some of the right merged to the left and vice versa, because pure stereo separation is just plain horrible in many cases.

(Also, something to remember is that to play 8 bit quality sample sound, you need the volume to be consistent, splitting the voices with different volume results in the log correction tables to not work as expected, and the digit becomes very grainy)

Re: OricExos - making the impossible

Posted: Tue Oct 09, 2018 7:25 pm
by Dbug
I've demo example for you, could you try that:

Code: Select all

10 ID=2^PEEK(#EDB0)
20 IF ID>8 THEN END
30 HIRES:PAPER 0:INK ID
40 CURSET 120,100,3
50 FOR I=1 TO 99 STEP 5
60   IF C AND ID THEN CIRCLE I,2
70   C=C+1
80 NEXT I

Re: OricExos - making the impossible

Posted: Tue Oct 09, 2018 9:24 pm
by iss
Thanks for the idea!
Two things need to be changed:
- PEEK(#EDB0) returns #60, #31, #32, #33 respectively for master, slave1, slave2, slave3 - use mask 0x03;
- the patched ROM can't execute BASIC programs - use C :twisted:

Here is the code (uploaded OricExos github):

Code: Select all

// Original code Dbug

// 10 ID=2^PEEK(#EDB0)
// 20 IF ID>8 THEN END
// 30 HIRES:PAPER 0:INK ID
// 40 CURSET 120,100,3
// 50 FOR I=1 TO 99 STEP 5
// 60   IF C AND ID THEN CIRCLE I,2
// 70   C=C+1
// 80 NEXT I

#include <lib.h>

static unsigned char oric_id,id,c;
static int i;

void main(void)
{
  oric_id = 0x03 & peek(0xEDB0);
  id = 1 << oric_id;
  if(id<8)
  {
    hires();
    paper(0);
    ink(id);
    curset(120,100,3);
    for(c=0,i=1; i<99; i+=5,c++)
      if(c & id)
        circle(i,2);
  }
  
  for(i=0; i<oric_id; i++)
    printf("\n");
  
  printf("Oric #%d halted", oric_id);
  while(1);
}
This is the final result with 3 Oric:
circles-demo.jpg
... and of course the video:

Re: OricExos - making the impossible

Posted: Wed Oct 10, 2018 12:42 pm
by iss
Simple try to achieve more colors. The idea was mixing this 4 screens:
bars.jpg
to get different levels in brightness but only 2 shades are visible.
bars-demo.jpg
Obviously this "direct RGB connection" is usable only when the goal is speed i.e. the screen will be divided in 4 areas and every Oric will paint its part. Sources are in github.

And here is the video:

BTW, sorry for the bad video quality, I'll try to improve it with DIY PAL encoder and USB capture device...

Re: OricExos - making the impossible

Posted: Wed Oct 10, 2018 6:02 pm
by Dbug
Cool :)

Sorry, did not realize that it did not run BASIC, was just an idea i had and I tried it!

Could you explain exactly what you did with the weird alpha/overbright/shades thingy when you have the master display white and also slaves writing on the same pixels?

Re: OricExos - making the impossible

Posted: Wed Oct 10, 2018 6:56 pm
by Symoon
This is becoming very interesting even for non-hardware guys ;)
Getting rid (more or less ;) ) of attributes headache... and colours! Would red and yellow be orange or plain red?

Keep up the good work guys, real fun here ;)

Re: OricExos - making the impossible

Posted: Wed Oct 10, 2018 10:14 pm
by iss
The soup-opera continues with new episode... more color bars :)
Mixing horizontal and vertical bars:
morebars.jpg
morebars.jpg (11.16 KiB) Viewed 8389 times
... and adding 3rd layer solid color:

Sources updated in github.

@Dbug: it's really weird - if 2 Orics output white then the 3rd become invisible no matter which color it displays, the explanation is that the white signal level from 2 outputs is over the maximum and adding more voltage doesn't make changes. Next I'll make the R-2R thing and then I expect to have really many nice colors.

@Symoon: Do you think it's possible to make F16 compatible CSAVE routine? This will speed up significantly the "networking".

Re: OricExos - making the impossible

Posted: Thu Oct 11, 2018 7:38 am
by Dbug
iss wrote: Wed Oct 10, 2018 10:14 pm The soup-opera continues with new episode... more color bars :)
(...)
@Dbug: it's really weird - if 2 Orics output white then the 3rd become invisible no matter which color it displays, the explanation is that the white signal level from 2 outputs is over the maximum and adding more voltage doesn't make changes. Next I'll make the R-2R thing and then I expect to have really many nice colors.
Would also be interesting to know if we are still in the valid range of what can be displayed by all TVs, SCART to HDMI convertors, beamers, etc...

Still, nice to have some new colors, as long as we can predict them :D

Reasonably, without complex circuitry, what is actually doable?
You already made the base system that allows to bypass the constraints by having any of the oric participate in the final color by setting one of the components, so now we need to figure out how to exploit the fact that two, three, or all four motherboard output a value for this particular component of this particular pixel, which means, as you said, that the voltage gets over the normal color value.

Is it possible in hardware to detect that the voltage is over a threshold, and use an alternate combining mode, or maybe use the 4th motherboard values has a way to describe how to mix the three other machines (ORing vs Ladder vs ... ?)

Just thinking out loud :)
@Symoon: Do you think it's possible to make F16 compatible CSAVE routine? This will speed up significantly the "networking".
What about modifying the ROM so any byte received on the CLOAD is immediately also sent back on the TAPE out, that would not speed up things, but that would make the loading parallel. (Or I guess having the input connected to the four machines at the same time for the initial load :D ?)

Re: OricExos - making the impossible

Posted: Thu Oct 11, 2018 11:50 am
by Symoon
Great demo ! Amazing new colors ;)
iss wrote: Wed Oct 10, 2018 10:14 pm @Symoon: Do you think it's possible to make F16 compatible CSAVE routine? This will speed up significantly the "networking".
Mmmh, that's fun I was thinking yesterday on how to accelerate this.
So far my tape signals are generated on PC, so I'm inexperienced on generating the signal with the VIA (I painfully made tests a few years ago and put it aside to work on high speed loading - all the papers docs and tests I made were stolen last June). Anyway, it actually depends on the Via, but yes it should be doable, maybe a bit slower than F16 but much faster than the original speed for "1" bits.
Actually the work would be: locate in the ROM where the timing is set when saving "1" bits, and make it faster!

My idea yesterday was more: could it be possible to have a "common" part, and "specific for each slave" part? It should even be possible to tell which byte is for which machine (using a different length for the start bit), but I think this would be complicated in terms of program design - so forget the idea.

Actually, how does that work: you are loading a full program on each machine, one after the other? Each machine waitng for its own program? I suppose the programs are different?

Re: OricExos - making the impossible

Posted: Thu Oct 11, 2018 1:17 pm
by Chema
And I guess that simply bit-banging through a digital output in the printer port to a digital input in the slave is not possible... Bit duration could be made as large as necessary. Some kind of serial protocol would be needed, but if clocks are in sync it cold be quite reliable (if noise is not a problem, that is).

Re: OricExos - making the impossible

Posted: Thu Oct 11, 2018 3:57 pm
by ibisum
Jaw-droppingly great progress! I can't wait to see what you'll do with it in terms of creative hi-res/hi-color modes .. man. Things like this make me wish Twilighte was still with us, I'm sure he'd be burning pixels like mad...