Proposal for #FujiNet for H89 systems

[Thom Cherryhomes]

Hello, everyone.

I am the firmware engineer and public face of a project called FujiNet, which uses an ESP32 to provide an I/O coprocessor to 8-bit systems, such as the Atari 8-bit, Commodore 64, and Coleco Adam systems.

It provides networked disks, a virtual printer, a wi-fi modem, and a network adapter with tons of protocol offloading that supports TLS and built-in XML and JSON parsing, thus allowing the target computer to enjoy a nice clean I/O channel that it can deal with at its leisure. Because the I/O interface is clean and simple, and the goal is to strive for operating system integration in every case, it can be e.g. as simple as adding some BIOS calls in CP/M.

We started on the Atari 8-bit systems, and started reaching out to other systems as we got our hands on hardware and time. The goal is to bring #FujiNet to every single 8-bit computer and game console.

#FujiNet is entirely an open source project, and while we do make limited runs of units to cover our development costs (with the only intent of breaking even, this is a labor of love), we actively work with others who can make devices for their respective communities. We do this by releasing all hardware and software on Github for public consumption.

We do not ask for licensing or any other explicit compensation. To us, having people use what is made, is enough.

A few of us have been going back and forth on trying to figure out an interface for the ESP32, which has a lot of GPIO ports, a few UARTs, SPI, and oodles of other bits of I/O, and would love to hear everyone's thoughts on a potential bus interface. The two ideas we've basically had were to use high speed shift registers with latch, or to program a CPLD to handle bus arbitration.

[Joseph Travis]

That's fantastic news Thom!  For those in the group not familiar with FujiNet, it is an interface that allows vintage computers to easily access servers to run or download software over the internet. It breaths new life into vintage computers!

Have a look at the FujiNet fb group or google for more info.  This is very exciting!

Regards,

Joe Travis n6ypc

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/aeaf1dc4-32cd-48a7-88ff-9495e509f1a2n%40googlegroups.com.

[Mitchell Smith]

This sounds really fantastic! Imagine being able to connect my H8 to the outside world...

Mitch

kb3gkc

[Thom Cherryhomes]

There are a few ideas floating around in our discord: (https://discord.gg/7MfFTvD) involving e.g. using 74HCT595s as high speed parallel<->serial shift registers, but we could really use the hardware design experience from others to potentially come up with the best possible solution.

You can see a demo of the FujiNet, here: 

https://www.youtube.com/watch?v=izdCLDQ1ZxU

The main site is here:

https://fujinet.online/

Current hardware is here:

https://github.com/FujiNetWIFI/fujinet-hardware

Current firmware is here:

https://github.com/FujiNetWIFI/fujinet-platformio

There is also a 3 hour walk-through video of the entire firmware:

https://www.youtube.com/watch?v=-WhMVHUGoRE

-Thom

You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/JUzWjF1xhIE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b63748ff-b872-449c-af21-c5c55dfea0f8n%40googlegroups.com.

[Norberto Collado]

For the H8 we have something similar, but does not have the a virtual printer and a wi-fi modem. It just includes the networked disks via CP/Net. Same CP/net circuit can be applied to the H89.

 

Link: http://koyado.com/Heathkit/H8_CP_NET_SPI_Wiznet_Network.html

 

So FujiNet uses the ESP32 that has Wi-Fi and Bluetooth functionality through its SPI / SDIO or I2C / UART interfaces.

 

The ESP32 can only be added to the H8 CP/Net board as it uses the SPI bus for better performance.

 

I think it will be easier to teach our H8 CP/Net board to connect to the FujiNet users network for file transfers. I have my H8 transfer files between my home and Douglas’ home without any data integrity issues. At this time is only supported on CP/M and CP/M+.

 

Thanks,

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAPQyuQKhoV0vBc4NGE-BESCs0%3DE6V3hqpGrCF%2B3ZHUcBnMX3%2BQ%40mail.gmail.com.

[Douglas Miller]

CP/NET does allow for remote printing as well. The idea of a remote "modem" is a little odd - the modem is usually local, with the sites connected to being "remote" - and also CP/M does not have the concept of a standard modem built-in. As we've proven with the WizNET adapter, CP/NET fits smoothly into a device that supports low-level network (TCP/IP) APIs. I'm confident we can work other devices like modems into the scheme (the same way I worked network boot in) - CP/NET has a pretty flexible message format

This is why I was asking for more info on the software interface to FujiNet. I'd like to see what facilities are available, to better understand how CP/M (and CP/NET) can take advantage of them. Some sort of "datasheet" and interface document would be really handy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/E3E2CA9F-A7A4-4BC0-8D42-191215A31E65%40koyado.com.

[Douglas Miller]

I was studying the schematic for "FN32ROV-1.6" again. So this device has the ESP32 microcomputer, a USB bridge, microSD socket, in addition to networking. This leads back to my earlier questions (on another forum). I would assume that these devices are "exporting" the SDCard and USB devices to the host computer, and that is the "protocol" or "API" we'd want to check on. Direct access to TCP/IP sockets over the network is a simple adaptation of what we already do with the WizNET module. What I think would be worthwhile collaboration with FujiNet developers would be to help them produce firmware that is CP/NET compatible/capable. I'm still looking for documentation on the host-to-firmware interface.

[Thom Cherryhomes]

There's a lot more going on than simple TCP socket adaptation.

If you look in here: 

https://github.com/FujiNetWIFI/fujinet-platformio/tree/master/lib/network-protocol

You'll see a list of growing protocol adapters which take care of complex protocol interactions on the ESP32, and present a clean I/O interface to the target system. This already sets it apart from the Wiznet and similar solutions, because we're doing much more than simply offloading the TCP/IP stack. There is also code for XML and JSON parsing, and most importantly, the ability to handle encrypted endpoints (e.g. SSH and TLS), something that Wiznet can never do.

Because of all of this, the target system implementations are much simpler once the hardware coupling has been implemented.

The idea is to export the devices in lib/device/* over lib/bus/* for a target system..

There needs to be a host bus interface specified and implemented for each target system (in this case H89), and I work with each community to try and make that happen.

The ESP32 has a TON of available I/O, not only in the form of GPIO, but also SPI, I2C, and three separate UARTs. The dual-core CPU on the ESP32 runs at 240MHz, with the master clock at 40MHz.

Some things to think about...

For those who want a comprehensive walk-through, I hosted a talk last week where I went in depth with the firmware.

https://www.youtube.com/watch?v=-WhMVHUGoRE

-Thom

On Sun, Jan 16, 2022 at 8:57 AM Douglas Miller <durga...@gmail.com> wrote:

I was studying the schematic for "FN32ROV-1.6" again. So this device has the ESP32 microcomputer, a USB bridge, microSD socket, in addition to networking. This leads back to my earlier questions (on another forum). I would assume that these devices are "exporting" the SDCard and USB devices to the host computer, and that is the "protocol" or "API" we'd want to check on. Direct access to TCP/IP sockets over the network is a simple adaptation of what we already do with the WizNET module. What I think would be worthwhile collaboration with FujiNet developers would be to help them produce firmware that is CP/NET compatible/capable. I'm still looking for documentation on the host-to-firmware interface.

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/db33b722-baf9-4088-ab3c-fae67845e21an%40googlegroups.com.

[Douglas Miller]

I was hoping for a document to describe the interface. WizNET publishes a document for their W5500 controller (which we used for the H8 SPI WizNET adapter), which describes the physical interface (SPI) as well as software protocol and resources available to software (registers, commands, etc). Such a document is important to attract developers. Interpreting source code is not really an efficient way to learn the interface.

I would suggest a more-generic CP/M (CP/NET) interface that could be used on any CP/M system with an SPI interface/adapter. I assume you create custom firmware for each target, but in this case the target would be more generic, i.e. CP/M systems. No need to emulate a specific bus, like the Atari. No original CP/M system had an SPI interface, because it didn't exist. But, many systems (H8, RC2014, etc) have added SPI adapters.

On Sunday, January 16, 2022 at 9:27:34 AM UTC-6 thom.che...@gmail.com wrote:

There's a lot more going on than simple TCP socket adaptation.

If you look in here: 

https://github.com/FujiNetWIFI/fujinet-platformio/tree/master/lib/network-protocol

...

[Thom Cherryhomes]

That would be great, it would need to be defined. The ESP32 has built in support for talking over SPI (or even i2c), so this is a possibility.

Given this pin-out here, could we build up a prototype card so that I can start defining a bus interface?

The philosophy for FujiNet is to build a bus interface that makes the most sense for a target system, as we support more systems, more code can be re-used for future targets.

If someone can come up with a good hardware coupling, I can work on the firmware.

-Thom

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/37e30d23-609a-4593-b2f3-60d9b2c3af97n%40googlegroups.com.

[Douglas Miller]

I watched part of the video. For those inclined, be aware that the first 10+ minutes are spent trying to resolve audio issues, so you'll want to skip past that. It is a recording of a video conference. The part I've seen is basically a walk-through of the firmware code, preceded by a quick demo.

I've got a better idea of what this is now. What is needed is a definition of a target computer bus to use (I would think that high-speed SPI would suffice, in our case with a re-roll of the H8xSPI adapter). Then definition of the protocols used to access FujiNet resources from CP/M (and perhaps HDOS - if it's generic enough, shouldn't matter). And then someone to make the firmware.

It's tempting to think about an 8-bit parallel interface - if there are enough free pins on the ESP32 - but that may make it harder to interface to a variety of target computers. SPI seems to be something that many systems have adapters to(?).

I'd certainly be willing to participate in defining the software API. It would be good to re-use as much of the existing firmware as possible, and I don't have a full understanding of all it's capabilities (yet). I'm envisioning something to off-load as much as possible from CP/M - the same motivations that led to choosing WizNET. To that end, I would promote the idea of having the protocol capable of accepting CP/NET messages - either for pass-through to the network or use on local resources (at least printers). TBD would be whether to also build-in the ability to service CP/NET file/directory requests to local (ESP32) storage (SDCard or ???).

[Thom Cherryhomes]

Excellent. 

We have a few different approaches being tried (the guys working on the NEC PC-8801 version are basing a design around a set of 74HCT595s), so investigating SPI would be a good choice. The ESP32 can act either as an SPI bus master at 40MHz or as an SPI slave at 10MHz. 

-Thom

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/aa260786-0bb7-46ed-9464-c40344b07d4cn%40googlegroups.com.

[Douglas Miller]

Slave at 10MHz is borderline fast enough. The absolute maximum speed for the H8 is 16MHz right now, although most have set the max to 10MHz. We haven't settled on the speed for the (not yet finished) Z180 CPU board. Are there any ways to improve the slave speed? (the SPI adapter runs off the CPU speed)

[Thom Cherryhomes]

Not that I know of. This is the max that the code in ESP-IDF can operate. There are other considerations outlined here:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/spi_slave.html

-Thom

On Sun, Jan 16, 2022 at 8:15 PM Douglas Miller <durga...@gmail.com> wrote:

Slave at 10MHz is borderline fast enough. The absolute maximum speed for the H8 is 16MHz right now, although most have set the max to 10MHz. We haven't settled on the speed for the (not yet finished) Z180 CPU board. Are there any ways to improve the slave speed? (the SPI adapter runs off the CPU speed)

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/9ee94503-86dc-4ca9-8de8-e7a84eccd2f7n%40googlegroups.com.

[Norberto Collado]

The kit at Amazon, includes a camera and a cable for programming.

 

https://www.amazon.com/Freenove-ESP32-WROVER-Bluetooth-Compatible-Tutorials/dp/B09BC5CNHM/ref=sr_1_1_sspa?gclid=Cj0KCQiAoY-PBhCNARIsABcz770aJ8t-5EG_PE2Qu9j1e1stLpBs44XLznLjjfJi4LwvxRXprmSiQZcaAp73EALw_wcB&hvadid=238267521359&hvdev=c&hvlocphy=1024479&hvnetw=g&hvqmt=e&hvrand=11346122363259362476&hvtargid=kwd-394241354120&hydadcr=19102_9441098&keywords=esp32+wrover&qid=1642395355&sr=8-1-spons&psc=1&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUExNDg3R0dRMDkwRjk0JmVuY3J5cHRlZElkPUEwNzI1NDU3TlZJQ0ZVVEFBV0lVJmVuY3J5cHRlZEFkSWQ9QTA1NDA0NjQxSlA3NFFHQzkzUloxJndpZGdldE5hbWU9c3BfYXRmJmFjdGlvbj1jbGlja1JlZGlyZWN0JmRvTm90TG9nQ2xpY2s9dHJ1ZQ==

 

From: "se...@googlegroups.com" <se...@googlegroups.com> on behalf of Thom Cherryhomes <thom.che...@gmail.com>
Reply-To: "se...@googlegroups.com" <se...@googlegroups.com>
Date: Sunday, January 16, 2022 at 6:22 PM
To: "se...@googlegroups.com" <se...@googlegroups.com>
Subject: Re: [sebhc] Proposal for #FujiNet for H89 systems

 

Not that I know of. This is the max that the code in ESP-IDF can operate. There are other considerations outlined here:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/spi_slave.html

 

-Thom

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAPQyuQ%2BhKSK4SVmPxdrhCwg_sTYVOPDsmZXvWuhWF5rXmK7eQw%40mail.gmail.com.

[Thom Cherryhomes]

This particular device can be programmed using the fujinet-v1-4mb profile.

The Fujinet-v1 production hardware uses a WROVER-B (or WROVER-E) with 16MB of flash and 8MB of PSRAM. We chose this to maximize the amount of available space for future firmware. At present, the current firmware takes up roughly 1/3rd of the available flash space.

[Darrell Pelan]

Nice find. I've ordered one to try out. 

I already have several ESP32 projects. I am planning on trying a breadboard interface using a 74LVCA245A Octal Bus Transceiver to replace the H-17 card in the H-89. The 74LVA245A should handle the voltage difference between the H-89 and ESP32. My plan is to use eight of the GPIO pins to read the parallel data and build the byte one bit at a time in the ESP32. I'm hoping to use the I/O signals already on the bus to simplify the interface. Once I get the two talking, I can look at outside interfaces like Fujinet.

  Darrell

[Norberto Collado]

As I need to focus on the H89-Serial-USB board + the H8-HA-8-3 board + other boards, I will let you and Douglas drive this discussion related to schematics and bus interfaces for the H8 and H89.

 

I still think that we can use the same SPI bus that we have on the H8 to drive the CP/NET network for both systems.

 

Thanks,

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b2bb8de5-4996-4e72-addc-be6f41878b90n%40googlegroups.com.

[Douglas Miller]

Yes, Norberto, stay focused on those other things.

I also was wondering about a parallel interface rather than SPI. Since the ESP32 seems limited on SPI speed, we may want to consider a more-direct connection. I've got no idea what the ESP32 capabilities are, but it sounds like it has a DMA engine so perhaps it can service the H8 bus fast enough that we don't need to throttle the Z80 software - at least for the bulk transfer of bytes (i.e. wait for "ready" then execute Z80 block-I/O instruction).

Even if we decide to use SPI, I don't think we can re-use the H8xSPI/WizNET board without modification. There is the wire-wrap area where one could put the FujiNet module, but we still might need to worry about speed. I'm not sure anyone has run their H8 at 16MHz, but if that is possible then we may have to do something like we do for the H17, and drop the CPU speed during FujiNet operations (or at least during transfers).

The other aspect is just what the software interface is like. I would like to see some amount of support for CP/NET messages, as it would be nice to be able to access printers or the SDCard from CP/NET. But, there are details to be worked out, since CP/NET is a file/directory protocol and - I think - the access currently given to the SDCard is as a block (sector) device. I suspect one could add a FAT driver (if not already there) to the ESP32 firmware and then we'd have something similar to the VDIP1 (only not as limited).

I'm guessing CP/NET messages would be "wrapped" in some other protocol - whatever is "natural" for FujiNet. I'm not sure if we are starting from scratch with that, or should try to re-use some existing protocol.

[Thom Cherryhomes]

We would be starting from scratch on that.

-Thom

--
You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/JUzWjF1xhIE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/ad13ec5c-3149-41db-bca4-1d4996b7e3a2n%40googlegroups.com.

[Douglas Miller]

So I would guess we probably start with the physical interface, as that will inform some aspects of the software interface. For lack of a need for something more complicated, I'm thinking a "command / response" or "request / response" sort of exchange (from the target computer perspective). Might need asynchronous responses if there is a reason for the ESP32 to make unsolicited communications with the target computer.

For SPI we'd probably have to have some sort of byte-stream protocol whereby the end of a command is well-known, and then be able to switch read/write for the data payload.The assertion of /SCS can be used to mark the start of a command, and we might want to have the command itself be fixed length (seems to be common for many SPI protocols I've seen). The data, whether being read or written, ends with the deassertion of /SCS. Not sure, from the ESP32 side, how it can deal with a variable length data field. It may be necessary to separate the higher-level "command / response" from the low level SPI protocol - especially when the response may take awhile before being ready. So, the SPI protocol may be more of a "send command", "check for response", "get response" sort of thing. Perhaps modeled from the WizNET protocol (start a command, poll for "response ready", ...).

For a parallel interface we could be a bit simpler I think. Maybe defining a data and control/status port. The ESP32 could then assert a "ready" status once it has setup dma. The target computer could then send the command/request packet (possibly including data) and assert some "end" control bit. Probably also need a status bit to indicate the mode of the ESP32 - command/response sort of thing (not terribly different from the SASI protocol command/data bit). That would help detect getting out of sync, and adding a (protocol) "reset" control bit could help recovery from that.

[Thom Cherryhomes]

For the Atari 8 bit, we utilized the never-before utilized interrupt line to signal to the computer when network traffic is available, which cut down on the amount of traffic needed.

-Thom

--

You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/JUzWjF1xhIE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b252c3e9-8ebe-4817-8c34-8677718fcd82n%40googlegroups.com.

[Thom Cherryhomes]

How does the wiznet device appear to the H8/H89? I seem to remember being able to boot from it, when I saw it at VCF East?

-Thom

[Douglas Miller]

We are not using the interrupt output from the WIZ850io module, although I believe the latest schematics still show it connected. For CP/M (CP/NET clients) it's not really that helpful, because CP/M has nothing else to do but wait for the network response. For the MP/M server it might help, but that generally requires a custom XIOS and so would not be as universal. Having the option for using interrupts would be good. CP/NET was shipped as a layered product, and generally not dependent on custom (non-standard) features.

The WizNET W5500 SPI protocol is fairly straight forward. The chip internals are presented to software as "registers" (or FIFO memory), each with a unique address. The SPI command selects a starting address (offset), register bank, and "read" or "write". Then the data payload is either read or written until the end of the command (/SCS deasserted). There are certain "command registers" which one can poke a command into, and then watch for "command accepted". Other registers are just "watch live" - for example, waiting to receive a message (packet, frame) from the network involves watching the FIFO receive count for a non-zero value.

CP/NET booting was a feature I added, based on work I did back in 1983. That's a matter of defining some additional CP/NET message types (DRI only defined 8 out of 256), and adding code to the boot ROM and servers to handle those messages.

[Thom Cherryhomes]

So basically, from a firmware standpoint, we have the following commands:

lib/bus/h8/

    h8.cpp

These define the bus primitives needed to send and receive commands on the bus, and are used by the devices.

lib/device/h8/
   disk.cpp
   printer.cpp
   modem.cpp
   network.cpp
   fuji.cpp

Disk essentially has read block, write block, status, and special (for commands like formatting)

Printer has write, and status.
modem has read character, write character, status

network has open connection, close connection, read, write, status, and special (for things like setting channel modes and accepting server connections)

fuji is special, as it contains commands to do things like mounting disk images and setting network information

the fuji commands are documented here:

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/SIO-Commands-for-Device-ID-%2470

The network socket commands are documented here:

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/SIO-Commands-for-Device-IDs-%2471-to-%2478

-Thom  

--

You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/JUzWjF1xhIE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/607c4ce2-30ff-4092-851e-69bb9b3ee2a4n%40googlegroups.com.

[George Farris]

So minimum 10MHz is still 10Mbps which is pretty fast for a Z80,  That's the old 10base2 speed and at 40MHz is would be considerably higher.  Now I understand one never gets exactly that but the ESP32  SPI is rated at 80MHz max.

Do we need faster speeds that that? 

George

[Douglas Miller]

George, the issue is not that 10MHz isn't fast enough, but that the SPI hardware we're currently using runs at the CPU clock speed. The WizNET board hardware will all run faster than we could ever run the CPU in an H8, so there's no issue there. Because the ESP32 is doing the SPI in software (and perhaps other issues), it's not able to go any faster than 10MHz, so we are either requiring a change to the SPI adapter, forcing people to limit their CPU clock speed, or adding code to manipulate the CPU speed during FujiNet operations. It's just not ideal.

[George Farris]

Right ok yes got it, I didn't read carefully enough before.

Many thanks

George

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/8ed9c7ff-514c-4655-a007-12b4b10db8c3n%40googlegroups.com.

[Thom Cherryhomes]

Has anyone recorded a video of the wiznet board running? I'd love to see what's already been done.

-Thom

[Thom Cherryhomes]

Also looking at e.g. the H-88-1, that may be simple enough to simulate in software.

-Thom

[norberto.collado koyado.com]

Attached is a small movie and some pictures. It is very fast. When booting from it is fast as well. I'm very happy with the performance.

Norberto 

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Thom Cherryhomes <thom.che...@gmail.com>

Sent: Wednesday, January 19, 2022 10:08 AM
To: SEBHC <se...@googlegroups.com>

Subject: Re: [sebhc] Proposal for #FujiNet for H89 systems

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/2df79911-8f47-42c0-ad27-4094618ac601n%40googlegroups.com.

[Douglas Miller]

In an attempt to summarize what we're proposing here, this is what I think the FujiNet would give us:

1) TCP/IP socket network access, like WizNET but with WiFi instead of wired Ethernet. Not sure about the antenna situation inside the H8 cabinet.

2) Emulated printers. However, I'm not sure where that PostScript/PDF output ends up - i.e. what you need to do to get that out of the FujiNet. This may be landing at USB-attached "modern" printers, so would require external access to the USB port on FujiNet (USB extension cable out the back).

3) Block (sector) access to the microSD-card. This is similar to the SDCard addition that's in the works for the WizNET (H8xSPI) adapter. This is also similar to the existing solid-state storage solutions we have, like Z67-IDE and GIDE. As with all of these types of storage, removing/inserting media requires access inside the H8 cabinet (or a way to "remote" the socket).

4) Possible access to FujiNet network servers. Unclear exactly what is available in this area.

5) I would like to see the addition of CP/NET support, as appropriate. But I'm not sure what that would look like, yet.

All of the above requires new drivers for HDOS and CP/M.

There has been talk of making this device emulate (all) H8 I/O devices, which would then not require new drivers. However, I'm not yet convinced there are enough GPIO pins on the ESP32, or that it would be able to keep up with the H8 running at higher CPU clock speeds. As Norberto has seen with the Z67-SDC effort, timing issues are likely to impact the practicality of this idea.

So, probably need some sense of desire from the group for this effort, and in what direction to go.

[Thom Cherryhomes]

To clarify some points:

The printed output from the virtual printer can be picked up via the web interface that Fuji net provides. This is demonstrated in the 15-minute demo.

The block interface not only applies to the local SD card slot, but it also applies to network storage exposed over the tnfs protocol. Specifically, this applies to disk images stored on tnfs servers across the local and internet networks. Again, this was demonstrated in the 15-minute demo.

--
You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/JUzWjF1xhIE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/29c8fc92-9632-4a24-8516-869cb1419fb6n%40googlegroups.com.

[Thom Cherryhomes]

To give an example of what was implemented for the existing target systems:

For the Atari 8-bit:

* SIO bus protocol implementation was created.

* Emulations for the disk drive were implemented, and hooked up to the host/device slot implementation. 8 device (drive)  slots mapped to D1: to D8: on the Atari.

* The virtual printer was mapped to the P: device.

* The virtual WiFi Modem was mapped to the R: device, and commands added to facilitate loading of the device handler for it to simulate an Atari 850 interface.

* The virtual network interface was a totally new device, with SIO commands mapped for it. a CIO handler was written to create a new N: device that pass commands from the CIO to the SIO layer directly, with a mechanism to help inquire about which commands were available for a given protocol and their DCB settings.

* Example programs written showing how to use the network device using either SIO or CIO calls.

* Fuji control device implemented as device 0x70 with corresponding CONFIG program to map device slots.

For the Coleco Adam:

* AdamNet bus protocol implementation was created.

* Virtual disk slots were mapped to AdamNet devices 4, 5, 6, and 7. (4 device slots).

* The virtual printer was mapped to device 2 (the Adam Printer) with the ability to turn on/off

* A serial device was created for device 14, emulating the unreleased AdamNet serial device (which has support in Adam CP/M out of the box ironically)

* The virtual network device was mapped to devices 9, 10, 11, and 12.

* Example programs written to show how to use the network device using either SIO or CIO calls.

* Fuji control device, implemented as device 15, with corresponding CONFIG program to map device slots.

The Apple // bring-up is also proceeding along, and we're expecting to have to write (for the first time for any Apple // device) routines that use the until-now unused character mode calls to implement the fuji, printer, and network devices.

So I am expecting to do quite a bit of elbow grease to integrate this into the system in a way that makes the most sense for users.

-Thom

[Thom Cherryhomes]

As for timing issues, we CAN indeed suspend the entire RTOS scheduler for the ESP32 at any moment, for time critical code paths.

-Thom

[Douglas Miller]

Studying the ESP32 datasheet more, I see that it appears that many of the pins have multiple functions, which I assume are configured by software. In that case, assuming the required other pins can be kept as the necessary functions (SDCard, USB, WiFi, ...), there may be enough GPIOs for 8 bits of data, 8 bits of address, at least 2 controls (IOR/IOW), and 3-5 interrupt outputs.

It appears that the power of the FujiNet thus far has been from emulating original hardware, so that original ROMs and OSes never knew they were not talking to authentic hardware. It's still not entirely clear what I am looking at in the demos, though, as it appears that FujiNet may be intercepting keyboard input and overriding video output, or even suspending the native ROM/OS and taking over the hardware. I'm guessing it's an intricate dance between the target computer and the FujiNet CPU.

My timing concerns are more fundamental than being able to suspend the RTOS. Again, I'm not familiar with the ESP32, but an H8 Z80 at 16MHz would be generating a (approx) 150nS I/O request signal. I'm wondering how a 40MHz ESP32 can take an interrupt on the leading edge of that signal and do what's required by the trailing edge (end of I/O cycle). I suppose one could add some hardware assist to latch data and signals, but that still leaves the issue of handling a stream of I/O, such as done by the Z80 block I/O instructions (a more-relaxed 1.28uS/byte). Perhaps the IOR/IOW signals can be used as input to the DMA engine, if that's possible (I'm not finding a general-purpose DMA engine in the datasheet, though, that can be attached to GPIOs).

[Joseph Travis]

Based upon my experience with FujiNet on my Atari 800, the capabilities it offers is fantastic!  At power up, it initializes and connects to your WiFi network then displays a menu. The menu shows a list of TFNS servers near the top with a list of "drives" below.  The drives can be disk images on the SD card or one of the TFNS servers.  You can boot from either location and "it just works".  I believe the way my printer is configured on FujiNet, anything I want to print is converted to a PDF file and sent directly to my PC.  From there I can send it to my printer.

The real beauty of FujiNet is how well it integrates into vintage computers, both hardware and software.  Thom has done a phenomenal job at making it all work as I like to say, "automagically".

Regards,

Joe Travis n6ypc

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/29c8fc92-9632-4a24-8516-869cb1419fb6n%40googlegroups.com.

[Douglas Miller]

That sounds like what I was thinking is happening. The FujiNet is either overriding the ROM or is taking over control of the video and keyboard. Not sure that the same technique will work on the H8, or at least it is complicated by the variety of configurations.

[Thom Cherryhomes]

if we can work out the bus coupling, i'll be able to either make totally new devices, assuming we can't emulate what's existing. We're not overriding the ROM, we're trying to mimic what the system expects... for bus oriented systems, we'll have to simulate the behavior of existing cards.

-Thom

--
You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/JUzWjF1xhIE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/19bd97cc-3367-49b1-a0bd-81a92f1f498fn%40googlegroups.com.

[Thom Cherryhomes]

I mean, we're able to bit bang the apple // smartport protocol (which runs at 250kbps), and have plenty of juice left over for actual processing, so... I really do think we'll be able to simulate bus behavior. :)

-Thom

[Douglas Miller]

You know the CPU (much) better than me, but I'm not sure I follow your math. 250kbps is at least 32uS/byte (depending on the number of bits it takes to transmit one byte). A z80 at 16.384MHz (the max H8 speed) doing block I/O would be 1.28uS/byte. That's a pretty different target to reach. That's assuming you add hardware to latch the data rather than try to access the bus directly within 150nS. And there could be sequences where back-to-back (adjacent) I/O instructions are separated by only 670nS.

[Thom Cherryhomes]

The fastest possible transition we can do, using a direct register write is 50 nanoseconds.

-Thom

--

You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/JUzWjF1xhIE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/9221e217-09b8-42e0-ab6d-9b70045de532n%40googlegroups.com.

[Douglas Miller]

I'm not able to find any documentation on the ESP32 instruction set. The link in the datasheet only brings up a document about an ECO, and looking at their technical documentation folder doesn't show anything about instruction sets.

I'm still not convinced we're understanding each other. To me, toggling a GPIO in 50nS is not the same thing as emulating an H8 adapter I/O operation in 670nS, or even 1.28uS. It looks to me as though you've got a small number of instructions with which to deal with an I/O and be ready for another (worst case). And, if these I/O operations are handled asynchronously, you've got interrupt/context-switch overhead on top of it. I guess you've got two cores, and perhaps you'll have to dedicate one core to the H8 bus - and even then probably have to write that in assembly language.

[norberto.collado koyado.com]

Not sure if this link helps: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/get-started/index.html#get-started-build

Get Started - ESP32-S2 - — ESP-IDF Programming Guide latest documentation - Espressif Get Started¶. This document is intended to help you set up the software development environment for the hardware based on the ESP32-S2 chip by Espressif. docs.espressif.com

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>
Sent: Friday, January 21, 2022 5:02 PM

To: SEBHC <se...@googlegroups.com>
Subject: Re: [sebhc] Proposal for #FujiNet for H89 systems

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/13cb1e66-cb6e-49cb-9b6d-adfc3b49862fn%40googlegroups.com.

[Darrell Pelan]

The technical reference manual is at https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf

[Thom Cherryhomes]

You can suspend the scheduler completely for time sensitive code, this includes any context switches that would otherwise occur.

-Thom

You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/JUzWjF1xhIE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855D40595AE9E92147F1586F75C9%40SN6PR01MB3855.prod.exchangelabs.com.

[Douglas Miller]

It would appear that the ISA for the ESP32 is proprietary. I would assume that also means you cannot embed assembly language with their C/C++ compiler.

https://esp32.com/viewtopic.php?t=17549

There is mention of "the ESP32-C3 will have a RiscV ISA which is fully documented". I'm not sure of all the product labeling conventions, but it seems odd that something called ESP32 would have a totally different instruction set from the rest.

It seems odd that they would market a product that suggests it is for real-time applications when the developer does not have visibility into the exact timing of the code being written. Maybe there are other tools, that I'm not aware of, that can be used to measure the time consumed by various pieces of code. Or else I'm mistaken about the target market(s) for this product.

Thom, I'm still not getting my point across. At this point, we probably don't need to continue this line of discussion.

[Darrell Pelan]

When I looked at the schematic FN32ROV-1.6.dch, it looks like the signal interface uses a 74LS07 as a buffer. My understanding is the ESP32 does not tolerate 5v inputs well. Is the purpose of the MOSFETS to provide VCC_BUF at something less than 5v?

On Sunday, January 16, 2022 at 1:41:42 PM UTC-5 thom.che...@gmail.com wrote:

That would be great, it would need to be defined. The ESP32 has built in support for talking over SPI (or even i2c), so this is a possibility.

Given this pin-out here, could we build up a prototype card so that I can start defining a bus interface?

The philosophy for FujiNet is to build a bus interface that makes the most sense for a target system, as we support more systems, more code can be re-used for future targets.

If someone can come up with a good hardware coupling, I can work on the firmware.

-Thom

On Sun, Jan 16, 2022 at 12:09 PM Douglas Miller <durga...@gmail.com> wrote:

I was hoping for a document to describe the interface. WizNET publishes a document for their W5500 controller (which we used for the H8 SPI WizNET adapter), which describes the physical interface (SPI) as well as software protocol and resources available to software (registers, commands, etc). Such a document is important to attract developers. Interpreting source code is not really an efficient way to learn the interface.

I would suggest a more-generic CP/M (CP/NET) interface that could be used on any CP/M system with an SPI interface/adapter. I assume you create custom firmware for each target, but in this case the target would be more generic, i.e. CP/M systems. No need to emulate a specific bus, like the Atari. No original CP/M system had an SPI interface, because it didn't exist. But, many systems (H8, RC2014, etc) have added SPI adapters.

On Sunday, January 16, 2022 at 9:27:34 AM UTC-6 thom.che...@gmail.com wrote:

There's a lot more going on than simple TCP socket adaptation.

If you look in here: 

https://github.com/FujiNetWIFI/fujinet-platformio/tree/master/lib/network-protocol

...

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/37e30d23-609a-4593-b2f3-60d9b2c3af97n%40googlegroups.com.

[Thom Cherryhomes]

I had those questions too, and through a weird stroke of luck Teo Swee Ann (designer of ESP32, and CEO//Founder of Espressif) contacted me to compliment our project on the work we've done so far, so I took the opportunity to have a long discussion with him on a bunch of internals, and he stated, quite plainly:

* The ESP32's GPIO pins are long term +5v tolerant (they can read +5v just fine, and it does not impact the MTBF of the device).

* The consequence of this can be some forward biased readings from the nearby DAC

* The ESP32 does indeed assert GPIO at +3.3v.

As for the 74LS07, we needed an open collector driver to properly drive the Atari SIO bus when there are multiple peripherals connected, and it took Joe a few revisions to come up with a circuit that worked well. It isn't needed if the Fujinet is the only device on the bus. For the Apple2 Smartport version, it winds up getting in the way, for example, so we reverted to the 1.0 design that directly connects the SmartPort to the ESP32.

As for your last question regarding the MOSFETs, I believe so, but maybe Joe can elaborate more on this. (hop on the list?) hehe.

-Thom

You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/JUzWjF1xhIE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/721854df-0b0d-4851-8826-b7c88bd7ba28n%40googlegroups.com.

[Thom Cherryhomes]

Because it didn't make it to the list:

Joseph Honold

10:12 AM (15 minutes ago)

to me, sebhc

Those fets turn off the buffer when you turn off FujiNet which cuts off all the lines from the esp32 to SIO. We had interference noise when FujiNet was off and Atari was on. The esp32 was being back-powered through the gpio pins.

[Darrell Pelan]

Thank you! Opinions on the internet all over the map on 5v tolerance. I'm close to putting together a breadboard to test connectivity on my H-89 running at 6 MHz with Terry G's upgrade. My approach is based on my design for a PC bus interface from the 80's for a hard disk controller. I'll keep the group posted on progress.

The breadboard will use a 3.3v supply for the ESP32 and a power blocker for the USB connection to prevent the USB providing 5v to the ESP32 when it already has a 3.3v power supply. The documentation indicates bad things happen when you mix USB power and board power at different voltages.

  Darrell

[Darrell Pelan]

Thanks!

[Thom Cherryhomes]

Some examples of protocol adapter usage,  to edit a file on a web server directly over HTTP/S (WEBDAV):

Coleco Adam: https://www.youtube.com/watch?v=myDh3fTkWYI

Atari 8-bit: https://www.youtube.com/watch?v=FJ3mGF6RNwM

-Thom

[Darrell Pelan]

Testing is progressing on my H89 ESP32 interface. My original design used 74HCT573s as data latches to account for the speed difference between the two CPUs. I'm using a 74LVC245 buffer between the ESP32 and 74573s. The design is based on the Micronics Technology Interface to the WD hard disk controller. There are three 573s: Data In, Data Out, Status. My original thought was to connect the Data In output to the Data Out Input and Status Input lines. The data lines to the ESP32 are buffered with a 74LVC245. Testing revealed the Data In outputs were affected (mostly driven high) so that data from the H89 was mangled. I've attached a schematic for reference. What am I missing in terms of the data bus interference?

Data comes through fine if I remove the two output 573's. Since these are input connections, I didn't think they would affect the output from the Data In 573. At this stage, the output on these ICs is not enabled and the LE signal is kept high.

Regards,

   Darrell