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

[norberto.collado koyado.com]

Can you explain what the schematics are trying to achieve?  What is the goal of such schematics? 

Norby

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Darrell Pelan <pel...@gmail.com>
Sent: Tuesday, February 22, 2022 8:50 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/f20d8438-8dcb-4f31-b433-4657cfbcc7c0n%40googlegroups.com.

[Darrell Pelan]

Hopefully the attached block diagram helps.  I intend to use the H-17 connector to drive three data latches to communicate with an ESP32 microcontroller. This will allow my H-89 to connect to my local network and access disk images (eventually). The data latches are: Data In (H89 to ESP32), Data Out (ESP32 to H89), and Status (ESP32 status for data transfer). The software would be similar for what I did for the Western Digital Hard disk controller in the 80's.

 Darrell

[norberto.collado koyado.com]

I think you want to invert the output of U11 pin 12 to control the /OE on pin 1 of U2 to avoid bus contention or better to add a flip-flop that the ESP32 can clear later.  

Or use the "WAIT_L" signal to stop the Z80 CPU until data is ready and buffers are in the correct state controlled by the ESP32 I/O pins. 

Thanks,

Norby

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Darrell Pelan <pel...@gmail.com>

Sent: Tuesday, February 22, 2022 12:05 PM

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7e3db49e-47d8-4795-9e2e-e3242575eb00n%40googlegroups.com.

[norberto.collado koyado.com]

Perhaps something like this that is in sync with the CPU clock to control buffers direction:

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of norberto.collado koyado.com <norberto...@koyado.com>
Sent: Tuesday, February 22, 2022 12:43 PM

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385522B4BCEA18CA8F6BC83BF73B9%40SN6PR01MB3855.prod.exchangelabs.com.

[Darrell Pelan]

Thanks for the tips! I'll keep you posted on progress.

  Darrell

[Douglas Miller]

Just my $0.02, that nobody asked for. But, it seems to me you can just use U2,U3,U4 as an "isolation chamber" between the H89 and the ESP32, and eliminate U7. The "left side" of U2,U3,U4 is under the H89 control, and the "right side" is under ESP32 control. No timing problems.

I'm guessing U7 exists to provide a way for the ESP32 to read-back what it wrote to U3,U4? That might not be worth the effort. Or else, use something else like an 8255 or Z80-PIO so that you can read-back without having to double-up on the outputs.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385537827A37EF396A0FBF56F73B9%40SN6PR01MB3855.prod.exchangelabs.com.

[Darrell Pelan]

I still have quite a bit of testing to accomplish. I agree U7 is probably not needed, but the first breadboard version killed the H89 data bus and U7 solved that problem. I probably should keep better notes as I go along (any notes would be an improvement :-)  ) Once I get reliable data flowing in, I'll look at removing the unneeded buffers. I still don't understand the conflict between U2, U4, U4 that U? (now U8) resolved.

[norberto.collado koyado.com]

Just keep U7 to read and write to the other buffers by controlling the direction with a flip-flop circuit. That should be best solution. Right now, you have contention between the read/write buffers driving by two different circuits not in sync with each other. Use the same circuit on the H89-Z37 Floppy Controller.

http://koyado.com/Heathkit/H89-Z37_files/H89-Z37-CORVUS-FULL-BOARD-LAYOUT.pdf

Think about everything after U7 to be like a floppy controller.

H89 Bus <-> U7 (with direction control) <-> ESP32 logic (New floppy controller)

Norberto

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Darrell Pelan <pel...@gmail.com>

Sent: Tuesday, February 22, 2022 1:59 PM

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/330e51f6-bf45-4a4e-b6bb-f6b2565af517n%40googlegroups.com.

[norberto.collado koyado.com]

Also, when the floppy read and write signals are asserted, it needs to trigger an interrupt to the ESP32. Reading data from the H89 (Z80 write cycle) bus will be easy. Writing to the H89 bus (Z80 read cycle) needs more attention.  When the floppy read cycle is asserted the flip flop needs to trigger the "WAIT_L" signal. Then the ESP32 can write to the output buffer and when done it clears the flip-flop wait state to complete such process. If the ESP32 is fast, it could be a hit of 1 wait state cycle or less.

Norby

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of norberto.collado koyado.com <norberto...@koyado.com>

Sent: Tuesday, February 22, 2022 3:08 PM

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855F68D13E1CADA52D2C748F73B9%40SN6PR01MB3855.prod.exchangelabs.com.

[Douglas Miller]

You need to be very cautious about using /WAIT states, especially when the thing driving the /WAIT is a computer. You must guarantee that /WAIT is deasserted very soon, especially on an H89 where the CPU is actually doing RAM refresh.

I still think it would be wise to forget trying to make this look like a floppy controller. It is not a floppy controller, it is a computer that is more powerful than the H89. A properly designed interface between the two computers should be simple and reliable, and not require special timing or /WAIT states. The MMS 77422 Network/co-processor board was essentially this - in that case a 4MHz Z80, DMA, and high-speed SIO. It used an AM2950 "bi-directional parallel port" and a couple tri-state buffers for status to connect the H89 to the internal Z80. simple, reliable, zero timing issues.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385501C30D856B8782155C3CF73B9%40SN6PR01MB3855.prod.exchangelabs.com.

[norberto.collado koyado.com]

In this case Darrell can benefit from the MMS 77422 schematics. Do we have them?

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>
Sent: Tuesday, February 22, 2022 3:37 PM
To: se...@googlegroups.com <se...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/913e0728-42f1-f2bb-01b4-05093b2a2192%40gmail.com.

[Douglas Miller]

I managed to trace partial schematics when I had one of those boards briefly. See page 5 for the H89 interface. Again, this is a partial schematic created by "ringing-out" the board and from memory. I think the original is lost to time. The internal Z80 used DMA to read/write the H89, and I do not show the internal side of the AM2950.

I have not tried, but I suspect the AM2950 is no longer available. However, I suspect there are modern equivalents. Basically, it contained two 8-bit latches with tri-state outputs, a pair of flip-flops for flow-control, and some misc other logic. I've attached an old datasheet for reference.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38557ADA36E3D502D82AC9BDF73B9%40SN6PR01MB3855.prod.exchangelabs.com.

[Norberto Collado]

Douglas,

 

Found your schematics but it is not complete and I appended them here. Do you have a complete schematic for the MMS 77422 board with the Z80 + AM2950, + etc.?

 

Thanks,

 

Norberto

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?

 

--

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38557ADA36E3D502D82AC9BDF73B9%40SN6PR01MB3855.prod.exchangelabs.com.

[Douglas Miller]

Is my email getting lost in spam folders? I did send out this same schematic earlier.

It is the only schematic I have, as far as I know the originals are lost. I had a 77422 board briefly a few years ago, and traced part of the schematic while it was in my possession. This is all there is, unless someone can contact Brad Gjerding to get a scan of the originals - if they still exist. Mark Garlanger has the only two 77422 boards I know to exist - but I would not ask anyone to try and recreate full schematics from them. This is a very crowded, dense, PCB.

I don't recommend copying this, or any other, H89 interface exactly. It is just an example of a computer-to-computer interface that is simple and does not suffer from timing differences between the two sides. An H89-ESP32 interface has different requirements and constraints (e.g. no DMA) and so warrants something a little different.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/802C8733-7213-4203-B2C0-D325A607C459%40koyado.com.

[Thom Cherryhomes]

This is awesome. As soon as something stabilizes, I will immediately add a target in fujinet-platformio and we can start on firmware. :)

(FWIW, there is an s100-spi target that has been set aside for somebody making an s100 card.)

-Thom

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/ac8d3163-df32-6072-fd0f-c12c5911b865%40gmail.com.

[Mark Garlanger]

Attached is the photo of the front of the 77422 and the cable for it. I'll send a separate email with the back, since it was too big to send it all in one email, and I didn't want to reduce the quality in case someone wanted to really zoom in.

Mark

On Wed, Feb 23, 2022 at 6:34 AM Douglas Miller <durga...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/ac8d3163-df32-6072-fd0f-c12c5911b865%40gmail.com.

[Mark Garlanger]

Here is the back of the 77422.

Mark

[Norberto Collado]

Hello Douglas,

 

Your email was logged in the SEBHC Groups email server. Sometimes it doesn’t send a copy, so I did not get such email..

 

This was logged:

 

 

From: "se...@googlegroups.com" <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>
Reply-To: "se...@googlegroups.com" <se...@googlegroups.com>
Date: Wednesday, February 23, 2022 at 4:34 AM
To: "se...@googlegroups.com" <se...@googlegroups.com>
Subject: Re: [sebhc] Proposal for #FujiNet for H89 systems

 

Is my email getting lost in spam folders? I did send out this same schematic earlier.

[Glenn Roberts]

H89 for dummies question: What does the MMS 77422 board do?

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.

--

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAAjkm78hMCHQ39fbGoiZ0CC6at9WpsaXf59EOnYx554-X-xPXg%40mail.gmail.com.

[Douglas Miller]

I'm glad you asked! But you may not be ;-)

It was originally designed as a network controller, and served that purpose for at least a short time inside MMS. It could be jumper-configured to run in several different modes:

1) Network interface to H89 or other computer (usually running CP/NET or MP/M-CP/NET-server)
2) Network printer server (RS-232 printer attached) to CP/NET clients
3) Diskless workstation (RS-232 Terminal attached) running CP/NOS
4) (non-network) Co-processor to enhance H89 CP/M

For option 4, it provided a way to run at 4MHz with a huge TPA (I think maybe 63K) and used "function shipping" to send all BDOS and BIOS operations to the H89 CP/M. We even ran MP/M by adding the extended RAM (256K) option.

The board that Mark showed was one I actually used in my own workstation at MMS, and then it was sold to a customer as a co-processor and then ultimately ended up on e-bay. I had it briefly before sending on to Mark, and traced the partial schematics and tested it out. It was actually trying to locate other nodes on the network port, so appears to be working. I believe Mark also has one more, so he could potentially setup a MMS Network, albeit pretty small.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/030701d82984%241abf34b0%24503d9e10%24%40gmail.com.

[norberto...@koyado.com]

I still think, that will be easier to layout the H8 CP/NET SPI WIZNET Network Card into an H89 size board to access files over the internet and use the floppy I/O signals to select it.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/11e2f8e4-cffc-6676-6e5b-b671d1e89caa%40gmail.com.

[Douglas Miller]

Again, I'm not proposing any existing interface to be used exactly as-is for the ESP32. The 77422 is just an example of a simple, high-speed, parallel, computer-computer interface that worked. I'm not keen on SPI unless it is absolutely necessary.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/00a201d8299d%2486990850%2493cb18f0%24%40koyado.com.

[norberto.collado koyado.com]

Does the ESP32 supports interrupts?

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>

Sent: Thursday, February 24, 2022 8:51 AM

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7eefe384-537c-5a53-ed67-dac8b154902a%40gmail.com.

[Thom Cherryhomes]

Yes.

-Thom

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BN7PR01MB3844612669FE99A48A96575CF73D9%40BN7PR01MB3844.prod.exchangelabs.com.

[Douglas Miller]

Just to re-iterate something we already talked about related to SPI. Unlike the WizNET, SDCard, and NVRAM devices that we've been using with SPI, the ESP32 SPI interface has a speed limit of "10MHz". So, I'm not sure if it will be reliable at 10.24MHz, but certainly won't run at 16.384MHz. I believe that the SPI slave port is running basically under software control, which limits the speed (or else there's some other reason for speed limit).

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

[pel...@gmail.com]

I’m using interrupts in my current design. I was using 74HC573 buffers and trying to have the ESP32 mimic a parallel port, but got inconsistent results. The attached timing diagram shows about 23us between the interrupt signal from a write to H89 port 7C (channel 2) and the ESP32 responding (channel 4/5). I’m using an 8MHz H89 (thanks Terry) and Turbo Pascal to drive the interface for testing. Channel 0 is the H89 8MHz clock. Channel 3 is a 74LS74 triggered by the H89 and reset by the ESP32 when the data read is complete.

 

I’m starting to test using 74HC595s (serial to parallel) for ESP32 output and a 74HC165 (parallel to serial) for input. I’m hoping this will speed up the ESP32 response since I won’t be doing the code gymnastics in the ESP32 to mimic a parallel port.

 

The nice part is the over the air update capability of the ESP32 code.

 

   Darrell

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BN7PR01MB3844612669FE99A48A96575CF73D9%40BN7PR01MB3844.prod.exchangelabs.com.

[Douglas Miller]

I'm not clear how switching to serial is going to help timing, but perhaps I've missed something. The H8xSPI adapter clocks the serial (SPI) data at CPU clock speed, and so we can guarantee that the Z80 won't overrun it (no status checking, block I/O instructions). But, you may not be able to do that unless the ESP32 can respond fast enough. That also requires that the ESP32 side be able to handle serial data at the host CPU clock speed. Serial or parallel, you seem to still need to provide status both directions so that neither side overruns the other.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/013901d829bf%24cb35e970%2461a1bc50%24%40gmail.com.

[Darrell Pelan]

I'm not using the SPI interface on the ESP32 for the H89. I'm saving that for possible expansion for SD cards or other devices.

 Darrell

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b9a09d17-014a-1f30-759e-a874ca3d1707%40gmail.com.

[Darrell Pelan]

Soapbox on

I really detest a bad data wire in a breadboard. Bit 2 on the data bus was stuck high. All the wires test out with an ohm meter. I replaced the breadboard wire. No change. I finally ran a jumper wire from the data bus on the H89 to the breadboard. Problem solved. Many hours lost.

Soapbox off

Good news. I now am able to send data from the H-89 to the ESP32. I expect the testing to move along much faster now that the raw data is fixed. I attached a picture of the test breadboard.

The clear LEDs on the left are for static testing and not currently connected. The blue LED is an "I'm alive blinker". Data is coming in through a 74HCT165 parallel in/serial out register. I'll start testing the 74HCT595 serial in/ parallel out registers for sending data from the ESP32 to the H-89 tomorrow. The address decode logic uses a 74LS32, 74LS08, and 74LS155.

  Darrell

[norberto...@koyado.com]

I’m impressed and congratulations in getting such board up and running. WOW!

 

Norby

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fb7a348a-686e-4170-b9f5-ed89914f98a4n%40googlegroups.com.

[norberto...@koyado.com]

Also, can I get the updated schematics?

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/02ca01d82ecb%2491b7f2e0%24b527d8a0%24%40koyado.com.

[Glenn Roberts]

That’s quite the testbed Darrell. Nice work!

Sent from my iPad

On Mar 2, 2022, at 11:13 PM, Darrell Pelan <pel...@gmail.com> wrote:

Soapbox on

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fb7a348a-686e-4170-b9f5-ed89914f98a4n%40googlegroups.com.

[Darrell Pelan]

Thanks! Do you want the current schematic? I still need to add bypass capacitors and layout the PCB. I'm also planning on adding an SD card module.

  Darrell

[Darrell Pelan]

Thanks!

   Darrell

[Thom Cherryhomes]

I definitely would, will post it in the #FujiNet discord.

https://discord.gg/7MfFTvD

-Thom

[Darrell Pelan]

The current schematic is attached. Debugging is still on going, so it might not be final.

Darrell

[Douglas Miller]

I see now, the ESP32 is in charge of the shifting, so the H89 only latches data or reads the current shift register output. So, H89 output/input routines would be checking status and then IN/OUT data when "ready".

One question: how do you insure that the H89 does not read the status shift register while the ESP32 is shifting data into it?

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/c24f8d54-733f-4933-b422-7bd8f44eac85n%40googlegroups.com.

[Darrell Pelan]

An excellent question. I'm working on the reliability of data in and data out process. I think I would be better served with a 74HCT241. I only need  two control  signals to handle traffic control. The Status 595 is overly complicated and adds too much overhead for the purpose, to your point. The 74HCT241 would let me simply set two outputs with two digitalWrite() function calls.

Thanks,

  Darrell

[Darrell Pelan]

Thank goodness for a logic analyzer to make sense of bad results. A couple of crossed wires, a bad IC ground, and a couple of major design changes brought me to the latest design.  Turns out I needed to buffer all data bus connections to the H89. Only the Data Out IC, U4, remains to be tested. Currently, I am able to send data from the H89 to the ESP32 and get status from the ESP32 to the H89. After a short vacation, I'll reengage.

   Darrell

[Douglas Miller]

I hadn't been thinking about how you need to do level-translation from 5v to 3.3v. That certainly influences/constrains your choice of parts. The 74LVC245 seems heavy for a uni-directional level translation, but whatever works. It appears to be a nice and simple (low-level) protocol between the H89 and ESP32.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7ae9bfe2-6a3d-46f4-a409-2d8642596245n%40googlegroups.com.

[Darrell Pelan]

The 74LVC245 is also intended to isolate the latched data from the H89 from the 74HCT273 latch used by the ESP32. The eight data lines need to be reset from input to output to send data to the H89. Hopefully, the testing will be quick when I return, and I can get started on fleshing out the software handshaking to transfer data between the two systems.

  Darrell

[Douglas Miller]

Yes, I was talking about the 74LVC245 at U9. The one at U7 is certainly needed to isolate/drive the H89 databus. Although, using 74HCT273 there you may still have an issue when the status register is enabled. Are '373/'374 not available? I guess you lose the CLR/MR option then.

It will be interesting to see the software protocol you come up with. I guess you have plenty of GPIOs and extra status bits in case you need something to indicate more context, like SASI did with the CMD/DAT or MSG bits.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/23bf6960-6dd6-47db-b2fa-cbf4a75541b4n%40googlegroups.com.

[Norberto Collado]

Darrel,

 

Please wait for me so that we can have a quick vacation! 😊

 

Norby

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/23bf6960-6dd6-47db-b2fa-cbf4a75541b4n%40googlegroups.com.

[Darrell Pelan]

I might have more time to reply. The weather is looking iffy in FL for diving 😞

I'll take a look at the 373/374 ICs. I'm not using the clear function on the 273 IC. The Status register and Input 273 (I need to add the label) are working nicely now. The 273 only latches data when the H89 writes to port FC. The Status register is enabled when the H89 rads port FD.

U9 is required to deconflict U3 and U4. I need U3 &U4 to hold data until the other CPU is ready to do something with the data. The ESP32 has to change the data pins from input to output depending on the need. When they are output, I don't want U3 driving the data lines on U4.

It looks like the ESP32 has a lot of available GPIO pins, but many are dedicated to other functions and don't play well with other uses. I wasted a lot of time trying to use SD2, SD3, and CMD. At the moment, I only have two more GP pins that can only be used for input and the GPIO I'm using for my "I'm Alive" LED available for something else in this design.

  Darrell

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/4A92D1C7-EC84-4FFB-AA99-3FD9B3691D1D%40koyado.com.

[Norby]

I got last night to Florida from Denver.

Sent from my iPhone

On Mar 9, 2022, at 3:19 PM, Darrell Pelan <pel...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAKhgrKs5q9NZWpGG0RsJDwkai_buE-CoUH-TpbXwpVfGpWL0mg%40mail.gmail.com.

[Darrell Pelan]

Hi,

Success! My H89 and ESP32 are talking nicely to each other. Next step is to add an SPI micro-SD card reader for additional storage. It was quite an adventure to find the right ESP32 pins to use.

Darrell