MSX WiFi via RS232?

Страница 3/4
1 | 2 | | 4

By dmr

Resident (37)

Аватар пользователя dmr

29-02-2020, 20:50

There is not a lot info available on this MT Telcom II. I'v read that it uses I/O ports 00 - 07 (the same as the MT Viditel cartridge? ... I must have one of those somewhere).

I know that it is based on the 8251/8253, I opened one to attach an ESP to it (see the picture in this thread, in 2018). But it does not comply to the RS232 standard, and it uses the ports differently, so porting BIOS or other software might not be straightforward.

With the built-in terminal program I've been able to talk with the ESP. So, it is usable... but I need to know more before I can write stuff for it (as there is no Fossil/UNAPI for now, and writing one is beyond my skills for now).

... never give up! ;-)

By Manuel

Ascended (16379)

Аватар пользователя Manuel

29-02-2020, 21:49

Well, people did make software for it, I think MOD and PhilTerm supported it. I've used the latter to get a whopping 1500 baud with it!

By dmr

Resident (37)

Аватар пользователя dmr

01-03-2020, 12:48

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                            
 

By dmr

Resident (37)

Аватар пользователя dmr

08-03-2020, 18:04

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?

By ducasp

Champion (273)

Аватар пользователя ducasp

08-03-2020, 21:24

dmr wrote:

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 ;)

By dmr

Resident (37)

Аватар пользователя dmr

12-03-2020, 23:31

HTTPS is now working...

ESP fetch https://www.bliekiepedia.nl

HTTP/1.1 200 OK
Date: Thu, 12 Mar 2020 22:24:04 GMT
Server: Apache/2.4.41 (Unix)
Last-Modified: Wed, 07 Aug 2019 19:39:39 GMT
ETag: "12f-58f8c1a12244d"
Accept-Ranges: bytes
Content-Length: 303
Content-Type: text/html

<?xml version="1.0" encoding="UTF-8"?>


... it is not yet robust - I have to improve my buffering in the ESP - but it is starting to work ;-)

By dmr

Resident (37)

Аватар пользователя dmr

15-03-2020, 11:27

ducasp wrote:

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 Wink

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)

By ducasp

Champion (273)

Аватар пользователя ducasp

15-03-2020, 18:24

Hi dmr,

My main concern over releasing the firmware for free is that people start selling cards with that firmware making a good profit on it (i.e.: an ESP8266 costs $1 or $2, a good enough CPLD + a PCB + extra components won't cost much more than $10, then seeing people building the project and selling for $50 and using a firmware/driver combination I've spent quite a few months engineering), it doesn't seem fair, on the other side, anyone that want to skip the engineering / software development on UNAPI and ESP UNAPI related stuff, I'm more than glad to offer that for a very reasonable price based on the selling price / profit of their project.

Now, about your own project, I'll be glad to help you in any way and with any questions during your development, although you are planning on using an ESP32 and I've used ESP8266, there is an Arduino IDE library for ESP32 as well which is very similar and I'm guessing that all I've learned so far might help you. It is probably the best way than using scripting languages, but hey, ESP32 is way more powerful so perhaps you might get through with good performance using scripts, but then I guess I won't be of much help to your questions as I've really focused on coding the ESP firmware using Arduino IDE as a basis.

https://msx.org/forum/msx-talk/hardware/msx-wifi-via-rs232?p...

There you have a post where you can see the code of the SM-X UNAPI Driver and that page has also information on how the "MSX" I/O interface that this driver is intended for works. The VHDL code implementing the interface is available for free as well in SM-X source code repository:

https://gitlab.com/victor.trucco/sm-x

In src\sm-x you have WiFi.vhd which is basically the VHDL implementation of that interface, and it uses UART.vhd and FIFO.vhd as well, so basically WiFi is the logics tying UP the MSX bus to the UART/FIFO, and UART/FIFO is connected to ESP8266 TX/RX. My guess is that it should not be difficult to put this in a CPLD, perhaps you might have to lower the FIFO or find some other way to implement the FIFO as the CPLD might not be as generous with memory blocks as a FPGA. Regarding the firmware itself, if you look through the driver code, will see it works on a very simple, lean and stupid protocol, basically receiving the UNAPI function an the parameters and doing mostly all the rest in the ESP. The only thing I didn't do inside ESP was the DNS, which has part of the code in z80, I don't even remember why, perhaps I was trying to get the best possible out before SM-X were produced so I've decided to lower the risk by not porting the DNS stuff completely to the ESP side.

Anyway, questions are always welcome and my e-mail address is available in the header file of most files in my github, I'll be glad to assist you on your engineering/software development proccess. ;)

By Manuel

Ascended (16379)

Аватар пользователя Manuel

15-03-2020, 18:48

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...

By ducasp

Champion (273)

Аватар пользователя ducasp

15-03-2020, 19:30

Manuel wrote:

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... Wink

Страница 3/4
1 | 2 | | 4