It would be a very simple project to build a side-car board that provides the 8-bit part of a PC/104 stack. You could then add a commodity PC/104 card that only uses 8-bit transfers - pretty much any I/O card other than IDE/CF such as extra serial ports, enhanced parallel port, Ethernet NIC, etc. The same card could also take in a barrel connector from a wall-wart or brick, step down the 12V DC to the various power rails and diode or it into the side car connector for more juice. The main draw back is the side car shroud wouldn't fit. But at least the PC/104 part would just be copper traces on the board and that's it.
I started making a similar board for the Tandy EX/HX since the form factor and stacking height of Tandy Plus+ cards is nearly identical to PC/104 minus the smaller 16-bit C/D header.
The other badly needed option is to just make a side-car NIC. I don't think it would be too tough. Since nearly everyone who's ever bought a jrIDE has wanted me to solder it for them anyway (except Hargle!), I'd prefer to do it SMT if I'm the one building them. Much faster.
New side car idea - PC/104 stack and aux power
Re: New side car idea - PC/104 stack and aux power
The PC/104 stack sounds functionally equivalent to my ISA bus adapter. I'm not too familiar with PC/104 except for the basics, but are 8 bit cards for it that common? I would expect that there are vastly more 8 bit cards out there available using ISA.
I'd love a NIC sidecar. Existing packet driver support would be really, really nice. My x86 is reasonable and I know where to steal code from, but doing a packet driver from scratch (or near scratch) would be a bit more challenging than what I've done with the networking code. But man, getting rid of the Xircom or the kludgy ISA bus adapter that I use would be sweet!
I am going to speculate there would be a lot of room left over. Are there semi-modern parallel port chipsets out there we could use? Even with just a re-implementation of the original TTL logic there would be plenty of room left over.
(I soldered my own jrIDE and did not find it that bad. If SMT is needed I'll live with it, but that means you're building mine too.)
I'd love a NIC sidecar. Existing packet driver support would be really, really nice. My x86 is reasonable and I know where to steal code from, but doing a packet driver from scratch (or near scratch) would be a bit more challenging than what I've done with the networking code. But man, getting rid of the Xircom or the kludgy ISA bus adapter that I use would be sweet!
I am going to speculate there would be a lot of room left over. Are there semi-modern parallel port chipsets out there we could use? Even with just a re-implementation of the original TTL logic there would be plenty of room left over.
(I soldered my own jrIDE and did not find it that bad. If SMT is needed I'll live with it, but that means you're building mine too.)
Re: New side car idea - PC/104 stack and aux power
I was thinking of something like a Microchip ENC424J600 Ethernet MAC. There isn't current DOS support. But it offers a lot of offloading of packet handling, lots of internal buffer space, and could easily be memory mapped. Most ISA NICs require DMA to get packets off quickly. It's also a current production chip so no need to goto brokers.
Just thinking out loud though. There would be a lot of space left over. Not sure what to do with it. Multi I/O is probably doable.
Just thinking out loud though. There would be a lot of space left over. Not sure what to do with it. Multi I/O is probably doable.
Re: New side car idea - PC/104 stack and aux power
If it has decent application notes it can be made to work - there are more than enough of the old packet drivers that are open source to borrow and steal the DOS specifics from.
My good (high performance) ISA NICs don't use DMA - just memory mapped buffers. The slower ones (3C503) have buffer memory but it's not exposed to the CPU, so they are doing PIO to get the data to the host.
Offloading the TCP checksumming would be a hoot - checksumming is one of the largest overheads I have found in the code. (Which is why I've spent so much time doing the checksumming code in fairly well optimized ASM, complete with loop unrolling.) Getting rid of checksumming on the host by offloading it could be worth 10 to 30% off of the basic socket handling.
MIke
My good (high performance) ISA NICs don't use DMA - just memory mapped buffers. The slower ones (3C503) have buffer memory but it's not exposed to the CPU, so they are doing PIO to get the data to the host.
Offloading the TCP checksumming would be a hoot - checksumming is one of the largest overheads I have found in the code. (Which is why I've spent so much time doing the checksumming code in fairly well optimized ASM, complete with loop unrolling.) Getting rid of checksumming on the host by offloading it could be worth 10 to 30% off of the basic socket handling.
MIke
Re: New side car idea - PC/104 stack and aux power
The Microchip ENC424J600 has a hardware checksum engine. I doubt the packet driver interface has support for HW accelerating that since it likely only deals with frames. It would have to be some sort of custom extension. The DMA engine on the ENC424J600 does the checksum calc. I don't believe it supports a scatter/gather mechanism. So each frame would have to remain in on-die memory until the complete IP packet is assembled. The chip has 24K of SRAM that is essentially managed by the host. You tell the MAC where it should DMA newly received frames into that memory space. You can also use the DMA engine to fast copy blocks of data around. In theory you could do all your packet reconstruction in device memory without having to move the result into PC memory until a full IP packets or even sub-sets of the payload like FTP or NFS buffers. It's just the 1980's and 1990's DOS interface weren't written to be that sophisticated since the hardware wasn't. This chip is intended to make TCP/IP stacks on small micro controllers easy to implement. Microcontrollers which are generally many times more powerful than vintage PCs like the Jr.
Re: New side car idea - PC/104 stack and aux power
If there is extra room in a side car NIC, and the translation isn't a nightmare, a Keyboard port either PS/2 or physically USB. I say physically USB since it could be a keyboard only port. Maybe another port, PS/2 or USB, for a mouse.
-PCjr (1989)-DOS 3.3, Racore Drive II, jrIDE-128 MB DOM, jrExcellerator, Tandy Mod, Serial Card, Combo v2, Config Plus, IBM Parallel Port, Megaboard, Xircom PE3-10BT
-PCjr (2001)-DOS 3.3, jrIDE-128 MB DOM, NEC v20, Parallel Port, Comswap, Xircom PE3-10BT
-PCjr (2001)-DOS 3.3, jrIDE-128 MB DOM, NEC v20, Parallel Port, Comswap, Xircom PE3-10BT
Re: New side car idea - PC/104 stack and aux power
Oh, I know a bit about the packet driver spec. ; - 0
I was expecting that if we have advanced hardware then the packet driver spec would be slightly subverted to extend it or go around it. And that is very easy to do. In the case of checksum offloading I would probably just have the packet driver use a unique name and let the applications key off of that. In this particular case, mTCP would detect "Oh - super dooper packet driver that I know does TCP checksums". And that would short circuit the TCP/IP code that computes the checksum again. Assuming the hardware just computes the checksum and puts it in the right place, all that the TCP/IP code would have to do is the quick check for 0000s.
The packet driver spec also allows for querying a card to see what advanced or performance features it might have. That would have to be extended, but I'm not too worried about possible collisions/conflicts at this point ... nobody else is crazy enough to be thinking about things like this.
IP fragments are rare in practice. I'd just be happy if it supported non-fragmented packets.
I was expecting that if we have advanced hardware then the packet driver spec would be slightly subverted to extend it or go around it. And that is very easy to do. In the case of checksum offloading I would probably just have the packet driver use a unique name and let the applications key off of that. In this particular case, mTCP would detect "Oh - super dooper packet driver that I know does TCP checksums". And that would short circuit the TCP/IP code that computes the checksum again. Assuming the hardware just computes the checksum and puts it in the right place, all that the TCP/IP code would have to do is the quick check for 0000s.
The packet driver spec also allows for querying a card to see what advanced or performance features it might have. That would have to be extended, but I'm not too worried about possible collisions/conflicts at this point ... nobody else is crazy enough to be thinking about things like this.
IP fragments are rare in practice. I'd just be happy if it supported non-fragmented packets.
Re: New side car idea - PC/104 stack and aux power
I guess my point is to do the checksum'ing like you have in mind, you would copy frames from the NIC and assemble the full IP packet somewhere in host memory. When you collected all the fragments, you would then need to copy the result back to NIC memory and run the checksum. That will work, but the NIC offers you a way to be even more efficient. If you ear-mark some of the NIC's on chip RAM for IP packet assembly, you never have to copy anything off the card until it's fully validated. But a traditional packet driver interface isn't that sophisticated.
Maybe a good alternative would be to develop a packet driver for the inefficient 100% compatibility case then a different direct use model for your IP stack and utilities that would allow things like FTP to run pretty blazingly fast (faster than any 8-bit ISA NIC could possibly run and perhaps faster than some 16-bit).
Take a rough look at the programming manual and see if that chip makes sense as a basis. There are ISA chip set NICs even available new on Digikey. However I'm not sure how well they would work or even if they would work in a non-DMA 8-bit PIO mode only. But they would be an easier way to create a sidecar NIC with no extra software development at all.
Maybe a good alternative would be to develop a packet driver for the inefficient 100% compatibility case then a different direct use model for your IP stack and utilities that would allow things like FTP to run pretty blazingly fast (faster than any 8-bit ISA NIC could possibly run and perhaps faster than some 16-bit).
Take a rough look at the programming manual and see if that chip makes sense as a basis. There are ISA chip set NICs even available new on Digikey. However I'm not sure how well they would work or even if they would work in a non-DMA 8-bit PIO mode only. But they would be an easier way to create a sidecar NIC with no extra software development at all.
Re: New side car idea - PC/104 stack and aux power
This is a case where a whiteboard would help ...
On the ones with TCP offloading that I remember, the host leaves the checksum fields alone when it sends a packet to the hardware, and the hardware fills those in before sending it down the wire. I can't remember what happened on incoming packets (it's been six years) but the hardware either filled in the checksum before passing it to the host, or it held the checksum in a register somewhere.
Fragments were a problem, but fragments are rare. Generally one TCP/IP packet fits in one Ethernet packet. The hosts are doing MTU path discovery and making the MSS (maximum segment size) so that a TCP packet fits in the smallest MTU discovered. So it's possible to get fragments, but not likely.
I'll look at the programming manual over the weekend. I have the luxury of owning everything in the stack except the packet driver, so even custom builds that use a completely different interface to the hardware are not a problem.
Mike
On the ones with TCP offloading that I remember, the host leaves the checksum fields alone when it sends a packet to the hardware, and the hardware fills those in before sending it down the wire. I can't remember what happened on incoming packets (it's been six years) but the hardware either filled in the checksum before passing it to the host, or it held the checksum in a register somewhere.
Fragments were a problem, but fragments are rare. Generally one TCP/IP packet fits in one Ethernet packet. The hosts are doing MTU path discovery and making the MSS (maximum segment size) so that a TCP packet fits in the smallest MTU discovered. So it's possible to get fragments, but not likely.
I'll look at the programming manual over the weekend. I have the luxury of owning everything in the stack except the packet driver, so even custom builds that use a completely different interface to the hardware are not a problem.
Mike
Re: New side car idea - PC/104 stack and aux power
It sounds like you are talking about the optional Ethernet frame CRC. Sure most hardware can fill that it and/or validate it. I'm talking about the IP packet checksum. It's been my experience writing IP stacks most data transfer protocols never attempt to size to the MTU. I always get fragments constantly as there is less overhead that way. If a data transfer protocol auto-sizes to the MTU, it's protocol overhead gets counted towards every frame.