On this thread of the Spanish web page Retrowiki, a guy has successfully connected several microcomputers to an ESP8266 WIFI module to try BBSs.

One of them is a BBC computer, connected through a RS423 serial port like the Enterprise has infra-utilised. 

I will try to do the same...

Just to note: I don't know details, but the ZX Spectrum Next project also seems like to use ESP8266, and it seems there is goal to write "Internet tools" as well. Among the "stretch goals" (the "dedicated developer"), but it seems the money is enough for that already and soon the 1 month of campaign is over:

https://www.kickstarter.com/projects/1835143999/zx-spectrum-next/

I just found that interesting, as they states the project will be open source, and even if it's a Spectrum project, it's still around the Z80.

The best for us is that the stock module comes with a firmware that emulates a modem, but it can be loaded with others, even a z80 emulator with CP/M...

There is an active Scene behind this module. Probably the Next will carry a modified firmware only for it.

I guess so, since somewhere I read that "reprogramming ESP8266 needs ..." or something like that. Anyway, it seems currently there is huge amount of project, code and doc on the module/chip itself, in contrast of its beginning when it was kinda a puzzle, especially to have only limited amount of info, and even that is in Chinese only ...

I know. I will use this circuit to feed the Wi-Fi module:

[ Guests cannot view attachments ]

[ Guests cannot view attachments ]

And this to rearrange the serial lines:



The first test made by "Gatuso" on the Spanish Retrowiki page has been done on a BBC micro, that also has a RS423 serial port:



Only that the BBC has -5v to +5v signals whereas the Enterprise returns -5v to +7v if the reference line is used.

I was wondered even by my own (without too much thinking or even trying) if it was possible to upload a new firmware (after all now even Arduino's IDE supports ESP8266 ...) using GPIO for communications somehow on a parallel way, without the problematic nature of serial bus. I am not sure if it's free to re-use all pins labelled as GPIO, but if does, there should be 8 pins for data, and let's say some of them for "signal" functions like, data direction (R/W), request validation, and such. Still there should be some usual ICs (eg from the 74xx family) for address decoding and well, maybe a bi-directional buffer from the kind of these 74xx stuffs powered from 3.3V but 5V tolerant inputs (afaik there are such). I am really not sure how hard would it to be, for logical level shifting it's certainly more easy only with two lines (uart, tx/rx) but after all having a parallel interface would work the extra job.

Yes, at the beginning there was no information on ESP8266 virtually, and the only little was given in Chinese. But as recently it seems there is a strong community behind this chip, documentation and even the event to support from Arduino IDE, now - I guess - it's much more easy to use a custom firmware which can avoid using serial things then. It was not so much an option at the beginning though because of the "unknown" factor I described above, so most things were even about trying to figure out the AT-like command set as the whole, and not even counting custom firmwares. And btw, since it uses (a kinda powerful) MCU, it may be even possible to include features like FPU operations as an accelerator, even if the MCU does not have a real FPU, it would be way faster to do it in software on the MCU than a Z80 can do ...

Yes I am working on a ESP8266-based module that will replace the WIZ network module on EPNET which already has 3.3v, RAM, ROM and memory/I/O decoding. I am using a xilinx CPLD to interface the z80 to the ESP as that is a 3.3v device with 5v compatible I/O like the WIZ module. I have written a UART in VHDL so I can talk to the ESP initially in its "native" way although SPI might also be a possibility once I get more experience with the ESP. But then so might just an even faster UART.

One thing, that this custom-firmware-parallel "hack" sounds nice, it's possible that it's not easy to do. The reason, that whatever fast the module's embedded MCU is, maybe it's not fast enough (in term of software of its firmware) to react on Z80 bus signalling in the given time constraints. So it's possible that UART works because it's slower and maybe the chip even has a FIFO inside for it, thus there is not so much an issue. For SPI, I don't know again ... SPI still would be better than the usual "uart-serial", that is you don't need to have a strict "speed" since it's done with the SPI clock line, so you are more free to do anything. But even here it's a question that it can be done sane way ie with custom firmware, and what is the requirement that SPI slave/master capability (ie who owns the clock generation for the data). Of course parallel would be the best, but see above ... But after all, at the other hand: if some want use a CPLD and eg address decoding / glue logic can be done (instead of discrete logic), of course it's not so much a problem to implement a very simple UART/SPI/whatever like entity there as well for interfacing with Z80 bus.