The first version manual looks very extensive, but ofcourse I have some remarks
1) page 20/26 the NETBLOAD example is copy/pasted from the previous NETGETPORT example.
2) Instead of calling NETSETHOST, NETSETPORT, NETSETPATH and NETSETNAME, why not give NETBLOAD four (optional) parameters that do these calls for the user: CALL NETBLOAD("hostname", 80, "/some/path", "filename.rom"). When loading a second file from the same location: CALL NETBLOAD(,,, "otherfile.rom"). It will make enduser life a lot easier.
3) page 23/26 the NETRCHKS format is copy/pasted from a previous NETLDBUF command
4) chapter 2.2 describes UDP and RAW packages but only for sending and not receiving like the TCP/TCS pair. Is it possible to receive an UDP packet after sending?
@Patsie - thank you very much - corrected, new version is uploaded. Let me know if you find something else. These entities - host name, path and file name are used in some other commands separately; they can be relatively long (31, 255, 31 characters respectively), and I deliberately wanted to have BLOAD as short as possible breaking long line command into "setup steps". I would rather run 4 commands, getting OK after each being sure that every thing is setup properly rather than run one long which return error spending time why it does so.
@Prodatron - card is W5100 based, TCP/IP stack is implemented in the chip (so you can say it is "hardware"), and only 2 sockets because other 2 are used for system purposes (DHCP/DNS, TELNET and BLOAD), and I want them to be separate so that you can bload having files open at the same time. Probably not the best decision, but to change that I need clear requirement for having 4 simultaneous sockets.
@edoz - compatibility is defined by the implementation of UNAPI? If yes, then I did not start its implementation yet. There're things which do not allow me - for example function ETH_IN_STATUS which is expected to return "Bytes 12 and 13 of the oldest available frame", which in my implementation may be useless because it is not defined what these bytes actually mean.
@msxholder - unfortunately it is not so easy as it seemed to. Currently I have 5V-3V3 implementation of the W5100, and I would say it is not at the reliability level I want it to be. I am redesigning full 3V3 redesign, it should have FPGA, and implementation of SCC should not be a problem given I already have it implemented it for GR8BUS master board.
Thank you all for your comments and suggestions.
How cool, I didn't recognized, that it is W5100 based! How is it possible to access the register memory and the RX/TX buffer memory? Is it I/O based or memory slot based? If you can tell me these little details, I can probably write a SymbOS network driver very quickly.
Cool! Prodatron is communicating with the W5100 directly! . so it would be easy to get it running with the new network deamon in SymbOS!! I love to order this one!!! as i need it to test the network applications
Can’t you allocate the sockets dynamically only when they’re used, so that normally the full 4 sockets are available? Reserving seems a bit wasteful of such a sparse resource, I think limiting the number of sockets to just 2 may make it more difficult or prevent to implement some interesting applications such as HTTP or BitTorrent, etc. But really, it’s hard to say now what applications will arise.
For Synthesix for example (MIDI synthesizer), if I would want to support RTP-MIDI there’s probably one or two connections per MIDI device. Then if I would want to add an online patch repository browser as well, it would run out of connections quick. Implementation-wise it would be troublesome to disconnect the MIDI keyboard while the patch browser is open, and from a user perspective he wouldn’t be able to audition the patches with his MIDI keyboard.
If it’s W5100 based, you may find it useful to look at the DenYoNet UNAPI driver source code. SymbOS is an entire OS, so it’s got its own driver system.
@Grauw: Konamiman uses one one "static" socket for DHCP/DNS as well, so there are "only" 3 left for applications. In a single tasking environment 2-3 connections are probably enough in most cases with the exception what you described.
Maybe it's even possible to exchange the MSX-DOS-based software between GR8NET and DenYoNet? (using W5100 UNAPI driver for GR8NET and using the GR8NET software for DenYoNet?)
If there are no issues with a SymbOS driver for this device all 4 sockets will be supported anyway
Please help me. I am looking for the RJ-45 connector which will fit into konami casing. Most RJ-45 connectors are soldered on the top of the board, and they are ~13 mm high + 2mm boards and pins = 15 mm in total, but internals of the cartridge is ~13 mm.
I found the following devices:
TE connectivity - not produced any more, can not buy
Sullins - same
Hsuan mao - have strange length of the pins (1mm - given that board thickness is 1.5mm at least).
If you will find anything like this, I will be very glad for reference. Thank you!
[/code]Design is still missing RJ-45 connector to the top left.
@Yobi: thank you. This jack has height between top and board as 8.65 mm. It will not fit into the cartridge box which has 6 mm from one side of PCB to the casing and 5 mm from another side of PCB to the casing.