VIA "networking"

This is the right place to discuss on how to implement hardware vsync, adding a VIA or AY chipset, puting multiple roms, or how to design a new flash expansion card.
Post Reply
User avatar
Dbug
Site Admin
Posts: 2746
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

VIA "networking"

Post by Dbug » Fri Sep 14, 2018 6:30 pm

I was thinking about the communication between multiple Oric, and when looking at what we had already in the machine, I checked the VIA 6522 datasheets (http://archive.6502.org/datasheets/mos_ ... v_1977.pdf) and in particular the first part of the document left me thinking:
The MCS6522 Versatile Interface Adapter (VIA) provides all of the capability of the MCS6520. In addition, this device contains a pair of very powerful interval timers, a serial-to-parallel/parallel-to-serial shift register and input data latching on the peripheral ports. Expanded handshaking capability allows control of bi-directional data transfers between VIA's in multiple processor systems.

Control of peripheral devices is handled primarily through two 8-bit bi-directional ports. Each of these lines can be programmed to act as either an input or an output. Also, several peripheral I/O lines can be controlled directly from the interval timers for generating programmable-frequency square waves and for counting externally generated pulses. To facilitate control of the many powerful features of this chip, the internal registers have been organized into an interrupt flag register, an interrupt enable register and a pair of function control registers.
In the Oric, the PORT-A is used to control the printer and the soundchip, PORT-B is used to scan the keyboard, check the printer status and control the relay switch.

Without any additional circuitry, is it possible to use any of these to communicate between the various machines, like for example using the printer port or the keyboard?

Basically, on the master machine, all we really care is the keyboard, sound generator and expansion bus, we don't care about the printer.
On the slave machines, we don't care about the printer, and we don't need the keyboard either, and the expansion bus is probably no necessary either (except maybe to plug something like a speech synthesizer :D).

I wish I was as comfortable with hardware as I am with software... but unfortunately not!

User avatar
iss
Squad Leader
Posts: 696
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: VIA "networking"

Post by iss » Fri Sep 14, 2018 7:38 pm

I have exactly the same in my mind! I planed to connect the 4 Orics printer ports with simple ribbon cable, of course STB and ACK wires should be crossed. Interesting is how the master will talk to any particular slave #1,#2 or #3. IMO this can be done fully in software using kind of packet protocol starting with 'address mark' or with hardware then the transfer can be 4-bit (bits0...3) and using bits4..6 to activate specific slave.
The are even more options with the printer port, for instance to make it work like SPI (I have sources for this).
What I'm not sure is: do we need 2-way communication (i.e. slave to talk to master)?

PS. I have already nice solution how to enumerate slaves just little patience :).

User avatar
Dbug
Site Admin
Posts: 2746
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: VIA "networking"

Post by Dbug » Fri Sep 14, 2018 8:51 pm

Cool :)

Do you think it's possible to transfer from the master to all three slaves at the same time (for example for doing a parallel transfer of the common data) ?

Regarding communication back, hard to say, but that would allow things like using one machine as a co-processor for example to compute 3d coordinates while another one does the computation of the lines to draw on screen, or to distribute the calculation of fractals over multiple machines.

Something else I just thought about, Symon has managed to do super fast loading using the tape interface with a special encoding, maybe that would work nicely between the Orics? Have the TAPE-OUT of each machine connecte to each TAPE-IN of all the other machines, and have some mini-protocol that says "This is for machine %0001, to load at address XXXX, lenght of data is YYYY"

Regarding machine enumeration, we could also just patch the ROM with a unique value containing 0, 1, 2 or 3 somewhere in the copyright message :D

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: VIA "networking"

Post by Symoon » Fri Sep 14, 2018 9:56 pm

Dbug wrote:
Fri Sep 14, 2018 8:51 pm
Do you think it's possible to transfer from the master to all three slaves at the same time (for example for doing a parallel transfer of the common data) ?
This could be easily done with the tape port (one Oric "saving", the others loading), but I'm not sure this is what you're looking for - standard tape transfer requires to freeze the Orics.
Something else I just thought about, Symon has managed to do super fast loading using the tape interface with a special encoding, maybe that would work nicely between the Orics? Have the TAPE-OUT of each machine connecte to each TAPE-IN of all the other machines, and have some mini-protocol that says "This is for machine %0001, to load at address XXXX, lenght of data is YYYY"
Ah, the SAVING doesn't exist on Oric for Novalight speed. Building the signal requires computing statistics of most used bytes (to optimize and build a dictionnary), and so on... All this being done on the PC that makes the WAV file.

About direct tape link, there's no reason it should not work on a software point of view; but I'm still very cautious about hardware (would the sound level be high enough?). BTW Bleu-Ciel Informatique had a tool called "Dialogue" based on such a link.
And adressing could be easy if you say that machine 1 waits for a program called "M1", machine 2 "M2" and so on, the Master would just have to save the program with the right names for the destination machine.

I'd say anything could be done, but not at Novalight speed, and as long as you are OK for Orics to be frozen during data transfers. Orics could process other things, but that would mean a slow data transfer speed (like the standard "fast" tape speed for instance).

User avatar
Dbug
Site Admin
Posts: 2746
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: VIA "networking"

Post by Dbug » Sat Sep 15, 2018 7:22 am

Thanks Symoon.
I guess the master machine could load from disk stuff which is already in the right "novalight" format to send, but then I guess that would be huge and not fit in memory!

I was discussing with Jede on IRC yesterday, maybe tome interesting alternative would be all these super cheap (5-10 euros) SPI based Ethernet modules, apparently some people even managed to get that to work with the VIA:
http://www.6502.org/users/andre/csa/spi/index.html

Basically we could send or receive data to the Oric directly from the PC using a ethernet cable, that could give interesting features, like the ability to remote debug on the real machine, send or receive files, etc... not sure how easy to do that is...

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: VIA "networking"

Post by Symoon » Sat Sep 15, 2018 7:50 am

Dbug wrote:
Sat Sep 15, 2018 7:22 am
I guess the master machine could load from disk stuff which is already in the right "novalight" format to send, but then I guess that would be huge and not fit in memory!
Yes, and it would also require a perfect 44kHz WAV player ;)
Basically we could send or receive data to the Oric directly from the PC using a ethernet cable, that could give interesting features, like the ability to remote debug on the real machine, send or receive files, etc... not sure how easy to do that is...
I don't have the programming skills (and time) good enough on PC but I still think an audio link could also be possible. I once managed to type on my Atmos keyboard and see the letters being displayed in Euphoric ;) But that was not reliable because of my program I think, some information was lost.
Anyway probably not what you're after: it's not so easy, nor efficient (but the most "hardware-less" solution).

User avatar
iss
Squad Leader
Posts: 696
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: VIA "networking"

Post by iss » Sat Sep 15, 2018 10:02 am

This is one possible solution which I can do in "no-time" :).
D0,D1,D2 are lines from Master printer port and together with STB (not shown on sketch) will route Master's Tape-Out to particular Slave's Tape-In. Bonus is that we can send data to one, two or to all three Slaves :).
Additionally tape connections will be direct (i.e. bypassing all analog parts) so it's expected to have 'ideal' link.

It will be very helpful if someone patch the standard Atmos ROM for Slave machines, so it executes automatically CLOAD"" after power-on. Meanwhile I'll do my blacksmith work...
tapelink.jpg

User avatar
Dbug
Site Admin
Posts: 2746
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: VIA "networking"

Post by Dbug » Sat Sep 15, 2018 10:14 am

iss wrote:
Sat Sep 15, 2018 10:02 am
It will be very helpful if someone patch the standard Atmos ROM for Slave machines, so it executes automatically CLOAD"" after power-on. Meanwhile
That's actually a very good idea!

If the slaves have a patched ROM, it can even do things like default to black paper and ink, so nothing is merged in the output by default (ie: we still only see the master oric screen data), and the actual stuff starts to happen on when the CLOAD receives something.

The only important thing about that, is that we want the hardware VSYNC to work, so maybe it should be redirected to something else than the tape input, or we need to make sure that VSYNC is disconnected when the tape relay is enabled.

User avatar
iss
Squad Leader
Posts: 696
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: VIA "networking"

Post by iss » Sat Sep 15, 2018 10:31 am

Dbug wrote:
Sat Sep 15, 2018 10:14 am
The only important thing about that, is that we want the hardware VSYNC to work
Good point! Count it as DONE!
Else, possible patches are:
- set the NMI vector to CLOAD routine - we will have manual control too for every Slave.
- change JMP to 'CLOAD' instead of print 'Ready'
... some many things to exploit :).

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: VIA "networking"

Post by Symoon » Sat Sep 15, 2018 6:32 pm

At one point I thought about adding, during the system interrupt, a listen to the VIA to see if something happened on the tape port, and if so, then stop and wait for a short specific synchro code (like 3 of 4 bits). If matching, then a program is about to begin => CLOAD. If not, it was just noise, go back to normal.
That would allow CLOADing without having to type any instruction. Not sure if it makes sense with your ideas.

User avatar
NekoNoNiaow
Flying Officer
Posts: 149
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: VIA "networking"

Post by NekoNoNiaow » Sun Sep 16, 2018 6:09 am

Dbug wrote:
Sat Sep 15, 2018 10:14 am
iss wrote:
Sat Sep 15, 2018 10:02 am
It will be very helpful if someone patch the standard Atmos ROM for Slave machines, so it executes automatically CLOAD"" after power-on. Meanwhile
That's actually a very good idea!

If the slaves have a patched ROM, it can even do things like default to black paper and ink, so nothing is merged in the output by default (ie: we still only see the master oric screen data), and the actual stuff starts to happen on when the CLOAD receives something.

The only important thing about that, is that we want the hardware VSYNC to work, so maybe it should be redirected to something else than the tape input, or we need to make sure that VSYNC is disconnected when the tape relay is enabled.
Loading the same program on all three machines Is a nice idea but now the issue remains to have each machine identify its role properly in the "ULA chain" so that it can output the proper part of the produced images. I guess this could also be done directly through the ROMs which would also dispense them all of the need to communicate: if they all run the same program, and know which graphics they have to generate, and are properly reset at the same time for the synchronization then they do not need to talk to one another.

User avatar
Dbug
Site Admin
Posts: 2746
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: VIA "networking"

Post by Dbug » Sun Sep 16, 2018 8:33 am

NekoNoNiaow wrote:
Sun Sep 16, 2018 6:09 am
Loading the same program on all three machines Is a nice idea but now the issue remains to have each machine identify its role properly in the "ULA chain" so that it can output the proper part of the produced images. I guess this could also be done directly through the ROMs which would also dispense them all of the need to communicate: if they all run the same program, and know which graphics they have to generate, and are properly reset at the same time for the synchronization then they do not need to talk to one another.
We have full control of the hardware, it's not going to be a mix-and-match together random Orics: They will be as one solid unit, sharing the same power, clock, reset, etc... so defining who's the master machine and who's secondary, tertiary, etc... is trivial: At boot time each Oric will know where they are in the pecking order :)

For the synchronization, we have both the VSYNC and the free running VIA timer, so that should not be a problem: We can assume that all our 6502 are in exact clock stepping, and will not drift apart.

What would be cool is to be able to expose a few bytes of shared memory, accessible in page 3 by all the four machines at the same time, and then use some small synchronization protocol to define who's talking now and to whom, then use a single byte load/store to do fast data transfer :)

User avatar
kenneth
Flying Officer
Posts: 185
Joined: Fri Nov 26, 2010 9:11 pm
Location: France PdD
Contact:

Re: VIA "networking"

Post by kenneth » Fri Sep 28, 2018 12:49 pm

The VIA chip is very useful in many protocols in the serial mode, but the used channels are CB1 CB2, unavailable on the printer port, in spite of this, we can connect all Orics on the parralel bus, and connect a little EPROM interface on the expansion port like Fabrice-F PCB with an 'almost' same BASIC ROM to recognize the other Orics with, for example, a random way to start the routines that will choose the master and the slaves of the network. :wink:

Post Reply