When you add this bit, please can you include setting it to read/write and mounting on the Amiga side? I do this and it allows me to update the version of Emu68 without taking the card out. I'm not in front of my machine right now, but I'm happy to contribute the steps if you want.

I set it all up, with AmiTCP. It only connected to outside once, dont know how. However it pings router all day long. Very annoying.

Plan to add command line info. As I do same thing, PCMCIA to amiga, then update PS files.

Before making this video, please watch (this section) as you'll get an idea of the issue....

Amiga 4000: Is the Fastlane Z3 the best home for a BlueSCSIv2 Upgrade?

When I filmed that, I had to post process it A LOT to increase its brightness to acceptable levels for this video. I had assumed that the issue was to do with the RGB to SCART cable (unlikely) or that my trusty SAMSUNG LED with SCART was on its way out (more likely).

However, today, I tested this by plugging in my A500, and the video looks bright and clear, as I remember it. So, A4000 has a problem  .

Calling on the ancient wisdom of the Amiga collective. Would anyone know what this is a symptom of?

My guess, if I were someone else, would be that capacitors were going down the swaney, and providing too low voltage. However, I had this machine re-capped just last year. So its very unlikely this is the issue. However, the recap was because of some leakage in the video area, however, I was lucky in that it seemed to be early days. I have cleaned that area, so Im surprised if its on-going corrosion.

Anyway, over to you guys. Wondering if Christ Edwards lurks here, as I would assume he might recognise the issue...

Could be the Video DAC.

Worth a look here:

https://www.amigawiki.org/doku.php?id=en:parts:video_dac

It maybe a corroded trace from the Caps leakage.

That's the impression that I got reading the 68000 datasheet and noting that the Amiga has no actual M6800 peripherals.
Definitely.
That's a point.  Currently /VMA is unconnected on the PCB (and per the schematic), I guess there's an internal pullup...? What's the consequence of the short E pulse?
I did not find the pound sign (#) in the list of standard boolean operators.  What did you mean?
I'm not familiar with the .D and .T notation.  What did you mean?  ETERM and EDTACK symbols are connected to what?
I found a dedicated divider part that will generate the proper frequency E pulse in under 1ns.  That will definitely get it working, at least on par with the unmodified 14MHz accelerator.  I like the fact that it keeps with the minimalist spirit of the original project in OP.  But latching with the rising edge of the 7MHz clock is definitely something that I can do.  I also found a decade counter that would let me generate it from the 7MHz reference.
Yeah, I had a hunch about that, are you able to quantify what is affected by the pulse width?
Nice project, useful toward "Amiga-like computer from scratch" projects that don't use any original Amiga components (which will be my final goal, eventually).  Thanks for providing the code.  I wouldn't mind learning that type of PLD syntax/notation.  I'm more fluent with VHDL and Verilog.

So the unmodified 14MHz accelerator has a problem I noted a while back.  I have an ide68k+mem68k sandwich, and it does not work at all with the 14MHz accelerator, I get flashing colors when I power on the machine.  At 28MHz I get a black screen with this peripheral.  Unfortunately I don't have them separately so I don't know which of them has the problem, I got this peripheral with one of my A1000.  It does work properly with the stock 7MHz 68000.  Do you have any idea what could be the issue?  I might give it a closer look next week to see which signals are connected so I could eliminate some factors.  I will be building two kinds of IDE interface, so need to put together BOMs for that.

I need to gather parts lists from multiple projects, then I'll be able to continue with this.  I like to build large carts to save on shipping.  I really like the lists feature on DigiKey as it lets me keep BOMs for projects.

Sorry, about the confusion on the logic equations: .R is the standard Boolean syntax for a registered output and + for a logical OR (CUPL syntax uses .D and # respectively). .T was the correct standard Boolean syntax for a Tri-State output. 

I have not used standard Boolean syntax in many years because CUPL is what Commodore used and it offers some more advanced features which can simplify the logic equations.

Regarding the signal names, these are new signals created and referenced to run the E clock cycle outside of the CPU. You mentioned that /VMA was not connected? That's strange because the 8520 CIAs won't respond to a cycle without /VMA asserted.

Regarding the duty cycle performance issue, that is well explained on the linked thread. It all comes down to wait states. The responding device becomes active and completes it's cycle when the E clock is high.

If you are highly motivated and you have the spare time, you can build everything you like with standard TTL logic and counters. But I'm much too lazy and I prefer to use GALs and CPLDs. Good luck.    
   

Here are the steps I took to be able to browse using the new WiFiPi wireless network driver, and Miami DX.

Version 0.1: First version to document my experiences - still finding and fixing typos

Downloads:
Emu68Tools from 23 April: https://github.com/michalsc/Emu68-tools/releases/download/nightly/Emu68-tools-20240423-75ea45.zip
Emu68 release 1: https://github.com/michalsc/Emu68/releases
Prism2v2: https://aminet.net/driver/net/prism2v2.lha
MiamiDX (demo): https://aminet.net/comm/tcp/MiamiDx10cmain.lha and https://aminet.net/comm/tcp/MiamiDx10c-MUI.lha (I already had this up and running with a 3COM PCMCIA card)

The info for where to copy the files is based on Michal Schultz's post: https://www.patreon.com/posts/wi-fi-alpha-102261532

Set up the Wireless network driver
1: Unpack Emu68 tools
2: Copy file Emu68-WiFi/Devs/Networks/wifipi.device to DEVS:Networks
3: Copy the whole folder emu68/WiFi/Devs/Networks/Firmware to Devs: (so you end up with Devs:Firmware containing a series of txt, bin and clm_blob files) NOTE: I didn't have the Devs:Firmware folder to start with but some of you might)
4: Unpack Prism2v2.lha you can choose to run the installer or copy some files manually

IF MANUAL
5: Copy Wirelsssmanager to C:
6: Create a text file in Envarc:sys/ called wireless.prefs
7: Add the lines
network={
     ssid="<name of your wireless network>"
     psk="<your network passphrase>"
}
8: Save the file
9: Reboot

IF USING THE INSTALLER:
5: Use expert mode
6: Choose 'No' when asked to install firmware for the Hermes chipset
7: Choose 'Yes' to set wireless preferences
8: Enter you wireless network name and password when prompted
9a: Choose whether or not to start WirelessManager automatically (it's up to you - see 'Observations' at the end)
9b: Finish the install and reboot

What's the difference between the two?
The process using the installer creates an encrypted version of the wireless password and uses that instead of the open text version. Handy if you don't want your password saved in plain text on your Amiga.
My personal experience is that I couldn't connect after setting up the wireless.prefs file manually, I would just get a timeout. Users Lemaru and Shaytam on the PiStorm discord assured me it should work without the encrypted PSK, so I uncommented the plain text line and commented out the encrypted line, rebooted and it then worked. The timeout was probably not related to the setup method I used (I have an old house with thick brick internal walls and Wifi can sometimes drop).

STARTING THE NETWORK
10: If you chose to use the installer and start automatically, and all being well, the wifipi.device should have been initialised on reboot.
11: If you have chosen the manual route open up a Shell and enter 'Wirelessmanager wifipi.device' - after a few seconds you hopefully get confirmation that you are associated with a MAC address, key negotiation is completed and CTRL-EVENT-Connected ie you're connected to the access point.

Configuring MiamiDX (Note I already use MiamiDX with a PCMCIA card and copied the original settings)
12: If not already done, install MiamiDX
13: Run and open up Hardware > New
14: Give it a name e.g. WiFiPi
15: Type of driver should default to SANA-II driver (if not change it to that)
16: In Driver enter DEVS:Networks/wifipi.device
17: Open SANA-II parameters
18: Choose 'Query Device' - the settings should auto-complete.
19: Choose OK to close the SANA-II parameters screen and again to close the Hardware Definition Screen
20: Choose Interfaces from the MiamiDX menu
21: Choose 'New'
22: My settings are:
 - Name: eth1
 - Alias: WiFiPi
 - Type: Ethernet
 - Hardware: (whatever you called the interface in step 14)
 - Priority: 10
 - IP type: Static
 - IP Address: something relevant to my network
 - Netmask Type: Static
 - Netmask: 255.255.255.0 (pretty common)
 - Gateway Type: static
 - Gateway: ip address of my router
 - Multicasts: disabled
 - Multicast pri: 0
 - Control panel: ticked
 - GUI default: unticked
 I don't have any Auto-connect/disconnect settings or Manual routes/aliases
TCP/IP settings:
 - Use ICMP: ticked
 - Fake IP: unticked
 - Get dynamic hostame, priority: 0
 - Get dynamic DNS servers: Ignore
 - Preferred offline state: Suspended
 - Get time: unticked
 - DHCP Enable: Ticked
 - Send hostname in request: Ticked
 - Host Name: Something you want to identify your Amiga on if looking in your router interface
23: OK to close the Interface TCP/IP Settings Window and again to close the Interface Definition Window
24: Right-click and choose 'Save' from the Settings menu

Now to test:
25: In MiamiDX, and the Interfaces section, select your newly created Interface and select 'Online'

Observations:
I Use Tinymeter and as soon as I run wirelessmanager the CPU drops to around 30%-33% free, so I'm going to continue to run this manually for now, only when I want to go online.
If you make any changes to the wireless.prefs file reboot for them to take effect.

Before making this video, please watch (this section) as you'll get an idea of the issue....

Amiga 4000: Is the Fastlane Z3 the best home for a BlueSCSIv2 Upgrade?

When I filmed that, I had to post process it A LOT to increase its brightness to acceptable levels for this video. I had assumed that the issue was to do with the RGB to SCART cable (unlikely) or that my trusty SAMSUNG LED with SCART was on its way out (more likely).

However, today, I tested this by plugging in my A500, and the video looks bright and clear, as I remember it. So, A4000 has a problem  .

Calling on the ancient wisdom of the Amiga collective. Would anyone know what this is a symptom of?

My guess, if I were someone else, would be that capacitors were going down the swaney, and providing too low voltage. However, I had this machine re-capped just last year. So its very unlikely this is the issue. However, the recap was because of some leakage in the video area, however, I was lucky in that it seemed to be early days. I have cleaned that area, so Im surprised if its on-going corrosion.

Anyway, over to you guys. Wondering if Christ Edwards lurks here, as I would assume he might recognise the issue...