Next phase... I can now fetch files via HTTP on my MSX:
All sources will be updated on Github: MSX-wifi sources
BTW: just to show how simple this is in code... it requires only the following additional lines:
elseif (string.find(data, "http ") ~= nil)
then
local uri = string.sub(data, 6)
local code = nil
uri = trim(uri)
if (uri ~= nil)
then
http.get("http://" .. uri, nil, function(code, data)
if (code < 0) then
print("HTTP request failed")
else
uart.write(0,data)
uart.write(0, EOT)
end
end)
end
I have updated HTTP client. The response is buffered in the ESP. The MSX can check the size of the buffer and read it, either one character at the time or the whole buffer at once.
Please see an example of fetching www . msx . org:
The hard part is done within the ESP. The MSX is just a "dumb" endpoint.
Just a thought: this could be made UNAPI compliant. However, UNAPI is low level in the sense that it requires more from the MSX whereas I think that the ESP is more capable of handling the heavy stuff (it is all in there). What do you think?
And... is anyone interested in this solution at all?
I have updated HTTP client. The response is buffered in the ESP. The MSX can check the size of the buffer and read it, either one character at the time or the whole buffer at once.
Please see an example of fetching www . msx . org:
The hard part is done within the ESP. The MSX is just a "dumb" endpoint.
Just a thought: this could be made UNAPI compliant. However, UNAPI is low level in the sense that it requires more from the MSX whereas I think that the ESP is more capable of handling the heavy stuff (it is all in there). What do you think?
And... is anyone interested in this solution at all?
It is completely feasible, and to be honest, in some ways yes, protocols like SMTP, FTP, Telnet, need to be implemented at software level using UNAPI, but those protocols aren't really heavy and even http works pretty good with the revision of Konamiman client that sped up transfers, or MSX HUB (I'm owing a fix for my updated version as it seems it fails on files with just a few bytes). If you think about the baud rate you can achieve, probably performance will be strained by it and not by z80 running any protocols... I would say that this (UNAPI) is the way to go as far as keeping it working with current and most future MSX Internet applications, but in the other hand, if you wish to use something that hasn't been implemented yet, it will be much more easier to implement it at ESP level (be it using a lua scripted firmware or a C implementation)
This is a two edge sword, as both have benefits and drawbacks, so I tend to think that you should follow the path you'll enjoy the most developing, as this is what keep good projects like this alive ;)
This is a two edge sword, as both have benefits and drawbacks, so I tend to think that you should follow the path you'll enjoy the most developing, as this is what keep good projects like this alive 
Ofcourse you're right: UNAPI should be the target. I started reading, but it may be a long while before I really grasp it. It is very impressive, and Konamiman deserves no less than respect (in addition to his highest grade for the thesis ;-).
You mentioned that you do not (yet?) plan to publish your ESP-firmware and I understand completely your motivation. Please note that I am in no way thinking about money when it comes to MSX, neither making it nor do I mind losing it (limited obviously by my bank's risk appetite ;-).I am just enthusiastic about MSX; I have been for ages (*). I want to make a wifi interface, and if I succeed, I want to show what I did and how I did it, software and hardware published in the open. And whenever possible, work together with others so as to combine efforts.
Would you be willing to describe more about the interface with the ESP, both "hardware" and "software"? I myself plan to make an interface based on a few components, connecting a NodeMCU (ESP12 or ESP32) directly to an I/O port using an mcp23008 to "translate" between parallel and SPI for address bus and maybe also for the databus... and for the control bus the usual 74xxx suspects. I don't know if it can be done with mcp23008, but I'll give it a try.
(*) My first MSX was a Philips VG-8020 together with a D6600/60P cassette recorder, back in 1985. My first MSX2 was - and still is - a Philips VG8235 which I upgraded to 7MHz and a DSDD drive; this one is still my workhorse (although I own a few more... there is a list somewhere on this forum)
There's hardly any profit if you include the time needed to assemble hardware, right? Also, do you think someone really makes serious money on MSX stuff? There's only a few hundred sales at most...
Wouldn't it be better if we could just help each other out?
Anyway, just a thought...
I respectfully disagree that there is little or no profit (as a whole, not as general rule), there are plenty of current MSX hardware (both closed design as well as open design) that sells for considerably more than what is spent on components and manufacturing (and I'm in no way judging, this is the way the things should be, someone offers a service, you have the choice to like it or not, buy it or not, or build it yourself if it is open hardware)...
I'm not even remotely saying that anyone make big bucks on this or that it is not fair, but as you consider fair that someone gets an open project, build and sell with profit (after all they had the trouble ordering components, testing, etc), I also think that the author of the original or a considerable part of the project could receive a part as well, which unfortunately is not the case most of the times (and that is fine, they have chosen to open the project).
Different line of toughts, so let's agree to disagree...
