--
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.
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.
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.
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.
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.
There's a lot more going on than simple TCP socket adaptation.If you look in here:
...
--
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.
--
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.
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.
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.
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.
--
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.
--
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.
--
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.
--
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.
--
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.
--
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.
--
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.
--
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.
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.
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.-ThomOn 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:...
--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.
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.
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.
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/ac8d3163-df32-6072-fd0f-c12c5911b865%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/ac8d3163-df32-6072-fd0f-c12c5911b865%40gmail.com.
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.
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BN7PR01MB3844612669FE99A48A96575CF73D9%40BN7PR01MB3844.prod.exchangelabs.com.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b9a09d17-014a-1f30-759e-a874ca3d1707%40gmail.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.
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.
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.
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/4A92D1C7-EC84-4FFB-AA99-3FD9B3691D1D%40koyado.com.
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.