Thank you for being understanding, John. If we get to do ethernet, it will be integral to the UltraQ board and will be fitted to every UltraQ made. There would probably be a standalone board too, because it would be a horrible limitation to have to buy UltimIDE plus the UltraQ upgrade just to get ethernet - if for example you already have a SGC.
Here are the physical/dimensional constraints: SuperRAM will initially be sold as a thru-conn interface for the QL. When the UltimIDE is released, it will have a riser to accept SuperRAM and, eventually, UltraQ. The riser version of SuperRAM will have a pin header facing down, instead of a DIN connector facing right. Same for the UltraQ. Converting a thru-conn SuperRAM to a daughtercard SuperRAM means removing the DIN connector to add the turned pins facing down, and adding a single solder bridge on the power supply (the riser feeds regulated 5v power.) UltimIDE will be sold with or without SuperRAM, and with or without UltraQ when that becomes available. Thus, a bare 0k or SuperRAM 896K equipped UltimIDE can be upgraded to a 4MB UltraQ with ethernet later, and the SuperRAM can be adapted for use in a BBQL, sold to someone with a bare UltimIDE, or possibly traded in for credit. *As currently planned*, the UltimIDE sticks out of the QL case a very small amount - about 20mm. The UltraQ will stick out slightly further, about 40 or 50mm. *This might change.* However, this creates a very low profile expansion and a not overly-long QL. This set-up can also be used in cased backplane systems. The intention is for the ethernet port to face backwards from the rear left corner of the UltraQ board. The floppy would face rearwards to the right of it. Both connectors would be mounted on the lower side of the PCB. LEDs would be on the top side of the PCB facing up, visible through a small slot in the black ABS cover. I hope to show veroboard mock-ups of the two boards in a few weeks, once SuperRAM is released. I have no preference for any chip, or hesitancy about any of the candidates. They're just chips that would have a schematic done then be incorporated onto a PCB that I'd assemble. I'm not going to be doing the drivers, it's all just hardware to me. The chip doesn't matter to me at all. It matters to whoever has to code for it. That's why I turned it over to you, humble code-tweakers. Which device is most likely to have code written for it that gets it to a useful state, be it a 'driver' or SuperBASIC routines that peek and poke their way to victory or assembly or whatever? Dave On Tue, Apr 15, 2014 at 5:34 PM, John Alexander <acontractor...@yahoo.co.uk>wrote: > Several different designs there but the majority of the chips used are > 5V tolerant I/O. I'm glad some one appreciates the thought just > wondering why > there's such a problem putting a single chip Ethernet port on a computer > that it's > taken 30 years to do it. > > Any way the IPv4 stack and more importantly the Apps will consume more > effort than the > physical interface and as said previously you can always test on a SLIP > connection > > On 15/04/14 23:24, Dave Park wrote: > >> That device, while cheap, has no 5v tolerance. The level translation, >> while >> simple to do, is relatively expensive in terms of components + board >> space. >> In the end, it erases most of the cost benefit. Also, it doesn't fit >> within >> the package profile of how UltimIDE and UltraQ will pair together to just >> have this extra board and connector sticking out somewhere. The components >> and socket would need to be integrated into the form factor. >> >> I do appreciate the thought, and for most other uses this would be the >> right choice. It just doesn't work for this specific application. It's >> hard >> to set out all the parameters that put boundaries on this up front, >> because >> if I explained every design goal and restriction and 'desired element' >> there really wouldn't be any choices left. Whatever is chosen, there will >> be some compromises and some people will be unhappy. I can just try to >> make >> an informed decision. In this case, an informed decision is the decision >> that most gives prospect of a usable QL ethernet system. >> >> Dave >> >> >> On Tue, Apr 15, 2014 at 5:13 PM, John Alexander >> <acontractor...@yahoo.co.uk>wrote: >> >> Could save a lot of dev effort and choose any one of the following >>> >>> http://www.ebay.co.uk/sch/i.html?_from=R40&_sacat=0&_nkw= >>> arduino+ethernet&_sop=2 >>> >>> Then your contribution is the base board to interface the Ethernet board >>> to the QL. Idea been start from a cheap known good solution testable on >>> another platform >>> then work back to the QL with minimum outlay in dev gear >>> >>> >>> On 15/04/14 22:45, Dave Park wrote: >>> >>> Please add the CP2200 to the list of devices under consideration. >>>> >>>> I did just look it up and it is comparable in features to the CS8900A. >>>> With >>>> a brief search, I might be able to buy CS2200-based ethernet cards and >>>> harvest all the components needed off them quite economically, for >>>> example. >>>> >>>> I am a little disheartened that ethernet on the Qx0 is not used by any >>>> QDOSMSQ* versions. >>>> >>>> Dave >>>> >>>> >>>> >>>> >>>> On Tue, Apr 15, 2014 at 4:18 PM, Graeme Gregory <gra...@xora.org.uk> >>>> wrote: >>>> >>>> On Tue, Apr 15, 2014 at 10:29:23PM +0200, Marcel Kilgus wrote: >>>> >>>>> Wiznet: >>>>>> >>>>>> + TCP/IP included. Implementation of socket API for QL probably pretty >>>>>> >>>>>> easy. >>>>> >>>>> + Reliefs slow 68008 main processor. But then I seriously question >>>>>> what >>>>>> original QL owners are going to do with this thing anyway. >>>>>> - Only 4 parallel connections. That's 4 more than QLs usually have, >>>>>> but still not exactly many. >>>>>> - IPv4 only with no way to upgrade if it is ever deemed necessary. >>>>>> >>>>>> All in all I'd say a real Ethernet chip would be much more >>>>>> future-proof... if you can get the software for it working. >>>>>> >>>>>> Of course the W5300 is also a proper ethernet chip as well, linux >>>>>> has >>>>>> >>>>> a driver for it not using the internal stack! >>>>> >>>>> G >>>>> >>>>> _______________________________________________ >>>>> QL-Users Mailing List >>>>> http://www.q-v-d.demon.co.uk/smsqe.htm >>>>> >>>>> >>>>> >>>> _______________________________________________ >>> QL-Users Mailing List >>> http://www.q-v-d.demon.co.uk/smsqe.htm >>> >>> >> >> > _______________________________________________ > QL-Users Mailing List > http://www.q-v-d.demon.co.uk/smsqe.htm > -- Dave Park Sandy Electronics, LLC d...@sinclairql.com _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
