New batch of pdp8 OMNIBUS to USB interface! Please Read and react!

[Alan Hightower]

Perhaps I was unclear. It is not a direct port. It was inspired by your
board during a road-trip to VCF-E to make an easier-to-assemble design.
There is obviously no FT245 support. And just about any implementation
of logic responding as a KL8E would look very similar. The code is
available under MAIN.pld on the previous link. 

The design uses a UART and can be run up to 230 Kbps and tested up to
460 Kbps. It runs faster than the original hardware. The UART design
certainly has limitations as you point out. But it is still an
improvement on the original DEC serial hardware which most people still
use. The design goals of this board are not the same as yours. 

It was designed to be easy to assemble without SMT. While I personally
agree with your SMT comments, most people do have problems soldering
.5mm pitch leaded components - as evidenced by the number of new-run
orders you have taken. The ATF1508 was chosen after noticing it's data
sheet revealed it could source the current requirements of the omnibus;
a rare thing. 

> Using traditional RS232 somewhere in between is just stupid bullshit. It completely spoils the beauty of the idea. But why should one make another design? Through hole parts?!?
> 
> They just should have asked me about cooperation :-)

After your reaction, clearly... Look, no one is trying to step on toes.
It's an alternative project and fully open source. I do not belive it's
existence is harming you or the community. After reviewing the code, if
you still believe there is an outstanding IP credit issue, we will
resolve it. It is clearly NOT a derived work and does not warrant a
derived license. 

Thanks Phil, 

-Alan 

On 2017-02-15 08:55, Philipp Hachtmann wrote: 

> On 02/15/2017 12:45 AM, Alan Hightower wrote: 
> 
>> Not sure if you are aware, but FYI - Malcolm MacLeod with some
>> involvement from Kyle Owen, Jack Rubin, and others ported your code to a
>> ATF1508 CPLD with a minimal test board.
> Oh, ah! I looked into their github and the README.md.
> There is a copy of the GPLv3 and as it looks no source code. And no hint that they used code from me.
> 
> That would NOT be ok!!!
> 
> Even if I have disclosed the source code, I have not licensed it under GPLv3 or put it into the public domain. It's a copyrighted work and I am the author. And the code is currently not licensed to anyone. And nobody but me has the right to license that code or parts of it to anyone.
> 
> That rant only to be clear... How something like that should happen:
> 
> 1. Ask the author to license the stuff under a free license like GPL
> (I probably would do that!)
> 
> 2. Start own project, copy and reuse as much or little as desired.
> The new project's license *must* be compatible to the license of the used other code.
> You have to mention the original author ("based on ... by...", "in parts based on ... by ...").
> 
>> I believe the longer term plan
>> was to make a full featured community project from it, but it's stalled
>> a bit atm.
> 
> Why?!? To have a single board KL8E replacement? Which it actually is.
> 
> OmniUSB's strong points are the following:
> 
> - HIGH speed
> - No baudrate setting
> - Direct USB connection
> - Special instructions to use really tight loops.
> - USB FIFO solution implicitely double buffered AND locked on both sides: As long as you obey the teleprinter flag on the 8, you cannot create a buffer overrun and lose data. On the PC's side you access the device with usual blocking I/O. You can't write more data when the PDP8 has not read from the FIFO. Therefore no single byte lost without thinking about it.
> Example: PDP8 does a disk dump. PC program is stopped. The pdp8 waits.
> Example: PC is sending a huge block of data to the pdp8. It just writes as fast as possible. The pdp8 is stopped for an our during the transmission. No byte is lost.
> 
> Using traditional RS232 somewhere in between is just stupid bullshit. It completely spoils the beauty of the idea.
> 
> Of course one could add an FTDI 240x FIFO (NOT!!! NOT!!! UART!!!!) to the design - then it would be equivalent to OmniUSB.
> 
> But why should one make another design? Through hole parts?!? We're living in the 21st century! The company where I want to bring the stuff for soldering just told me that they usually don't stock that old and clumsy 0805 components by default...
> 
> Soldering a 200 pin TQFP is easier than doing some wire wrap connections and takes 4 minutes if you are UNexperienced. SMT soldering is easier than THT if you have done it for more than one half hour! (Of course with SMT you're on the way to really difficult stuff, but that's not part of the discussion)
> 
> They just should have asked me about cooperation :-)