I'm still wondering why it's so huge, if it's required only SRAM... Also, why there is additional LPT port?
Mask of Destiny wrote:Also, I was planning on adding some mechanism for piping data in and out of controller ports to BlastEm.
When I was thinking about my implementation of GEMS connection, I had few ideas. First, it would be best, if you could implement it as plugins (btw do you know how to make plugins in unix?), so anyone who wants his own protocol could implement some interface, and install ext-port as plugin. For example it can be abstract class with virtual methods: read, write.
Sockets / Pipes.
There is sync problem. You must understand that it is often situation when one side is working in loop of awaiting, and after condition is triggered, some modification happens right at that moment. I don't know how to describe... I just want to show why following setup is not good:
Code: Select all
PSEUDO-PSEUDO-CODE
// Client Side
Wire(byte b)
{
send(sock, b); // using locking mode
port = b; // update local port value
}
byte Read()
{
return port; // always up to date
}
// running somewhere in loop
if (len = recv(sock,&v,1)) // no locking mode
port = v; // updaring port
// Server Side
// COPY-PASTE ROFL
Wire(byte b)
{
send(sock, b); // using locking mode
port = b; // update local port value
}
................
Where is issue? This situation may and will happen:
1) Server write in port.
2) Client read from port.
3) Client recieve what Server wrote.
And client see some impossible situation so exception may happen.
Sockets / Pipes attempt two.
Sync must be strict. You can't achieve that by timestamps for example. You can't achieve that inside of connection, so you have to deal with it on some side. For example, let Server side do all sync work.
Code: Select all
PSEUDO-PSEUDO-CODE
// Client Side
Write(byte b)
{
send(sock, "write", val); // using locking mode
}
Read(byte b)
{
send(sock, "read"); // using locking mode
recv(sock, &v, 1); // using locking mode
return v;
}
// Server Side
Write(byte b)
{
port = b;
}
Read(byte b)
{
return port;
}
// running somewhere in loop
if (len = recv(sock,&type)) // no locking mode
{
if (type == "read")
send(sock, port); // locking mode
else
{
recv(sock,&v); // locking mode
port = v; // write port
}
}
It will work, but if Client running some check in loop, he will spam packets.
Sockets / Pipes attempt three.
You can try to implement Bus hold and Bus release over sockets, it will make all sync. But when it comes to BUS, it requires Bus Arbiter, and again, it will be one of sides
. So actually, it's same as previous one. For example, if arbiter is Server, then Client will send "server, stop operations now", and waits for his response "stoped", and after it, Client execute operation, after that, he is sending "server resume" without response. I don't know about performance, it may be slower.
Mask of Destiny wrote:Does that sound good to you?
I don't know. I don't get it what you said.