FreddyV wrote on 2024-08-17, 20:58:

Yes, this is it, it is on purpose. The uSD and USB connectors are too close from the PCB. These kind of connectors did not exist […]
Show full quote

lausvi wrote on 2024-08-16, 14:36:

I meant the red line in the attached pictures: the board is not parallel to the bracket: […]
Show full quote

I meant the red line in the attached pictures: the board is not parallel to the bracket:

The attachment bracket.jpeg is no longer available

This is how I plan to install the audio output jack:

The attachment 20240816_173028.jpg is no longer available

Yes, this is it, it is on purpose.
The uSD and USB connectors are too close from the PCB.
These kind of connectors did not exist at the ISA time

Ah, now I see, the problem is the metal between slots on the PC cover that blocks the SD-slot (as it sits so close to the PCB). Sorry I didn't understand the issue at first 😊
This seems to vary between cases. I 3D-printed my own bracket with the PCB straight, and tested on my Pentium I case; the SD-slot just clears the case so it might work, depending of the case's tolerances. I'll need to test on another case to see if this was just lucky exception.

I now have another question! I have a Commodore PC-I (https://www.zimmers.net/cbmpics/cpci.html), which I think would really benefit having a PicoMEM: it only has one ISA-slot (and only by using an external adapter: https://autumnhippo.com/products/pc1-xt) and it's very low-end XT clone. Having a hard disk, AdLib and networking on it would be a really neat treat (also no need for the bracket, hah).

I installed the PicoMEM on my PC-I and it does work (hard disk, AdLib and networking tested so far) BUT there is a somewhat random issue where sometimes (most of the time actually) the machine freezes at "PicoMEM Boot: Press A to boot from floppy , B for BASIC/ROM 1". The count-down at the end of the line stops at 1 or 2. At this point the internal floppy-drives's light is on, and when the boot halts, the light stays on (when it boots succesfully, the floppy drive light goes off after the hard disk boot has started). If I keep resetting the computer, I eventually get it to boot succesfully either by just not touching the keyboard at all, or bashing keys on the prompt and it just proceeds normally. I had no issues with the PicoMEM itself as I tested it on a loose 386 motherboard.

I noted some mentions of a timing issue with Commodore PC-10, could this be something similar (what was the issue on that machine?). Or as mentioned in a recent issue on the GitHub (https://github.com/FreddyVRetro/ISA-PicoMEM/issues/41) perhaps a power issue? Are there any easily reachable spots on the PicoMEM PCB to add additional capacitor for testing?

I did see couple of times an error about config not being saved/SD card not accessible, could this be a power issue as well? (The SD card is new and freshly formatted, although a cheap 4GB one).

lausvi wrote on 2024-08-23, 17:17:

I installed the PicoMEM on my PC-I and it does work (hard disk, AdLib and networking tested so far) BUT there is a somewhat random issue where sometimes (most of the time actually) the machine freezes at "PicoMEM Boot: Press A to boot from floppy , B for BASIC/ROM 1". The count-down at the end of the line stops at 1 or 2. At this point the internal floppy-drives's light is on, and when the boot halts, the light stays on (when it boots succesfully, the floppy drive light goes off after the hard disk boot has started). If I keep resetting the computer, I eventually get it to boot succesfully either by just not touching the keyboard at all, or bashing keys on the prompt and it just proceeds normally. I had no issues with the PicoMEM itself as I tested it on a loose 386 motherboard.

I noted some mentions of a timing issue with Commodore PC-10, could this be something similar (what was the issue on that machine?). Or as mentioned in a recent issue on the GitHub (https://github.com/FreddyVRetro/ISA-PicoMEM/issues/41) perhaps a power issue? Are there any easily reachable spots on the PicoMEM PCB to add additional capacitor for testing?

I did see couple of times an error about config not being saved/SD card not accessible, could this be a power issue as well? (The SD card is new and freshly formatted, although a cheap 4GB one).

Hi,
It looks like you added PREBOOT on the config.txt
Sometimes, the timer and keyboard are nto configured in the preboot phase, you need to remove it.

FreddyV wrote on 2024-08-26, 14:39:

It looks like you added PREBOOT on the config.txt
Sometimes, the timer and keyboard are nto configured in the preboot phase, you need to remove it.

I don't have a config.txt on the card at all.

The first prompt (setup/continue) works everytime (countdown and keys work) but the PicoMEM Boot -prompt most of the time freezes at 3.

lausvi wrote on 2024-08-26, 16:00:

I don't have a config.txt on the card at all.

The first prompt (setup/continue) works everytime (countdown and keys work) but the PicoMEM Boot -prompt most of the time freezes at 3.

The code is the same for both part 🙁
So I have no idea.
Maybe try to remove the config file (the other one) sometimes it help solving strange problem

FreddyV wrote on 2024-08-28, 19:35:

The code is the same for both part :( So I have no idea. Maybe try to remove the config file (the other one) sometimes it help […]
Show full quote

lausvi wrote on 2024-08-26, 16:00:

I don't have a config.txt on the card at all.

The first prompt (setup/continue) works everytime (countdown and keys work) but the PicoMEM Boot -prompt most of the time freezes at 3.

The code is the same for both part 🙁
So I have no idea.
Maybe try to remove the config file (the other one) sometimes it help solving strange problem

Is the base config.txt file available up on the Github? I would pre-load the MicroSD card with one with the right configuration.

That said, heads up on using the RP2350 for the next PicoMEM iterations: You'll want to wait until they get a RP2350-A3 (or -B0) stepping out due to a rather nasty bug in it's pull-down behavior.

I was talking about the picomem.cfg file, not config.txt

I saw the bug thing, I don't know if it will affect the boards I putchased (Pimoroni pico plus 2)

It use the B chip

Yoghoo wrote on 2024-06-29, 16:02:

birnwieapfel wrote on 2024-06-29, 15:25:

Hello! […]
Show full quote

Yoghoo wrote on 2024-06-28, 13:54:

... Only wireless networking is not working correctly for some people (including me).

Hello!

Which network driver are you using? I had issues with the PM2000.COM driver and MTCP, but then I switched to the NE2000.COM driver and new everything works fine!

Regards

I did the same as PM2000.COM didn't work for me as well. But with NE2000.COM I can do DHCP requests but can't really use it as it's not stable at all. Even with an open case and 1 meter from an access point it's dropping half the packages etc. So not usable atm. Strange thing is that the PicoMem detects a strong connection. Thought it was maybe related with the pico (in combination my acces point) but I tested a standalone pico with C and also Python and it's rock solid. So somewhere the timings or something else is not working correctly in the PicoMem.

Well, now I feel silly. I spent two days with PM2000.COM trying to figure out why my network wasn't working, without trying NE2000.COM!

It almost seems like PM2000.COM has trouble responding, or at least I could use Telnet to login to MTCP's FTPSRV, but I wouldn't see any response.

After switching to NE2000.COM, it sort of works. I can login to FTPSRV, look around, but file transfers hang up.

Transient wrote on 2024-09-13, 22:39:

Well, now I feel silly. I spent two days with PM2000.COM trying to figure out why my network wasn't working, without trying NE20 […]
Show full quote

Yoghoo wrote on 2024-06-29, 16:02:

birnwieapfel wrote on 2024-06-29, 15:25:

Hello!

Which network driver are you using? I had issues with the PM2000.COM driver and MTCP, but then I switched to the NE2000.COM driver and new everything works fine!

Regards

I did the same as PM2000.COM didn't work for me as well. But with NE2000.COM I can do DHCP requests but can't really use it as it's not stable at all. Even with an open case and 1 meter from an access point it's dropping half the packages etc. So not usable atm. Strange thing is that the PicoMem detects a strong connection. Thought it was maybe related with the pico (in combination my acces point) but I tested a standalone pico with C and also Python and it's rock solid. So somewhere the timings or something else is not working correctly in the PicoMem.

Well, now I feel silly. I spent two days with PM2000.COM trying to figure out why my network wasn't working, without trying NE2000.COM!

It almost seems like PM2000.COM has trouble responding, or at least I could use Telnet to login to MTCP's FTPSRV, but I wouldn't see any response.

After switching to NE2000.COM, it sort of works. I can login to FTPSRV, look around, but file transfers hang up.

About the same problem as I am having indeed. Unfortunately Freddy is mostly busy with Tandy stuff at the moment and after that probably playing with Pico 2 stuff. So the changes that this is going to be solved in the foreseeable future is pretty slim.

Hopefully he keeps his word and finally releases all the sources when the Tandy stuff is done. With the partial code that is released it's not really possible to debug it.

Yoghoo wrote on 2024-09-13, 23:11:

Transient wrote on 2024-09-13, 22:39:

Well, now I feel silly. I spent two days with PM2000.COM trying to figure out why my network wasn't working, without trying NE20 […]
Show full quote

Yoghoo wrote on 2024-06-29, 16:02:

I did the same as PM2000.COM didn't work for me as well. But with NE2000.COM I can do DHCP requests but can't really use it as it's not stable at all. Even with an open case and 1 meter from an access point it's dropping half the packages etc. So not usable atm. Strange thing is that the PicoMem detects a strong connection. Thought it was maybe related with the pico (in combination my acces point) but I tested a standalone pico with C and also Python and it's rock solid. So somewhere the timings or something else is not working correctly in the PicoMem.

Well, now I feel silly. I spent two days with PM2000.COM trying to figure out why my network wasn't working, without trying NE2000.COM!

It almost seems like PM2000.COM has trouble responding, or at least I could use Telnet to login to MTCP's FTPSRV, but I wouldn't see any response.

After switching to NE2000.COM, it sort of works. I can login to FTPSRV, look around, but file transfers hang up.

About the same problem as I am having indeed. Unfortunately Freddy is mostly busy with Tandy stuff at the moment and after that probably playing with Pico 2 stuff. So the changes that this is going to be solved in the foreseeable future is pretty slim.

Hopefully he keeps his word and finally releases all the sources when the Tandy stuff is done. With the partial code that is released it's not really possible to debug it.

I was looking at the code for those two (NE2000.ASM and PM2000.ASM). It looks like PM2000.ASM can be compiled into either PM2000.COM or NE2000.COM, so I'm not 100% sure which code produced the NE2000.COM binary on Github. If the Makefile is correct, then it should have been NE2000.ASM as one would expect.

I'm not great with assembler, but it looks well commented, at least. I noticed a section for a pause_ macro which includes a note about it being ineffective on a machine with fast cache. I do have cache, although I'm not sure what qualifies as "fast cache".

Transient wrote on 2024-09-14, 02:38:

Yoghoo wrote on 2024-09-13, 23:11:

Transient wrote on 2024-09-13, 22:39:

Well, now I feel silly. I spent two days with PM2000.COM trying to figure out why my network wasn't working, without trying NE2000.COM!

It almost seems like PM2000.COM has trouble responding, or at least I could use Telnet to login to MTCP's FTPSRV, but I wouldn't see any response.

After switching to NE2000.COM, it sort of works. I can login to FTPSRV, look around, but file transfers hang up.

About the same problem as I am having indeed. Unfortunately Freddy is mostly busy with Tandy stuff at the moment and after that probably playing with Pico 2 stuff. So the changes that this is going to be solved in the foreseeable future is pretty slim.

Hopefully he keeps his word and finally releases all the sources when the Tandy stuff is done. With the partial code that is released it's not really possible to debug it.

I was looking at the code for those two (NE2000.ASM and PM2000.ASM). It looks like PM2000.ASM can be compiled into either PM2000.COM or NE2000.COM, so I'm not 100% sure which code produced the NE2000.COM binary on Github. If the Makefile is correct, then it should have been NE2000.ASM as one would expect.

I'm not great with assembler, but it looks well commented, at least. I noticed a section for a pause_ macro which includes a note about it being ineffective on a machine with fast cache. I do have cache, although I'm not sure what qualifies as "fast cache".

That seems to be the problem. I disabled all cache on my system and now FTPSRV works flawlessly. I did have to use the default MTU size of 576 with MTCP.

STrRedWolf wrote on 2024-08-29, 11:43:

That said, heads up on using the RP2350 for the next PicoMEM iterations: You'll want to wait until they get a RP2350-A3 (or -B0) stepping out due to a rather nasty bug in it's pull-down behavior.

This bug only affects projects that aim at interacting with high impedance sources. ISA bus has own pullups and wont trigger bad behavior.

>>After switching to NE2000.COM, it sort of works. I can login to FTPSRV, look around, but file transfers hang up
> I disabled all cache on my system and now FTPSRV works flawlessly.

35 years later same problems as developers of Wing Commander 😁
https://github.com/FreddyVRetro/ISA-PicoMEM/b … ASM#L46C1-L46C7
pause_ implements additional IO instruction to induce delay and will defeat any cache effects. You could try adding another 'in al, 61h' in there and re-test.
BUT this delay was needed on a real NE2000 and shouldnt affect PicoMEM. PicoMEM might be hurting due to ISA clock being too fast for example.

rasz_pl wrote on 2024-09-14, 04:07:

This bug only affects projects that aim at interacting with high impedance sources. ISA bus has own pullups and wont trigger bad […]
Show full quote

STrRedWolf wrote on 2024-08-29, 11:43:

That said, heads up on using the RP2350 for the next PicoMEM iterations: You'll want to wait until they get a RP2350-A3 (or -B0) stepping out due to a rather nasty bug in it's pull-down behavior.

This bug only affects projects that aim at interacting with high impedance sources. ISA bus has own pullups and wont trigger bad behavior.

>>After switching to NE2000.COM, it sort of works. I can login to FTPSRV, look around, but file transfers hang up
> I disabled all cache on my system and now FTPSRV works flawlessly.

35 years later same problems as developers of Wing Commander 😁
https://github.com/FreddyVRetro/ISA-PicoMEM/b … ASM#L46C1-L46C7
pause_ implements additional IO instruction to induce delay and will defeat any cache effects. You could try adding another 'in al, 61h' in there and re-test.
BUT this delay was needed on a real NE2000 and shouldnt affect PicoMEM. PicoMEM might be hurting due to ISA clock being too fast for example.

ISA clock on my board is set to 8 MHz, unless the documentation is wrong.

I am using a Pentium 90 with a VESA Local Bus motherboard, so maybe something unique with that.

I had the same thought about increasing the delay in pause_. I'll try getting a build environment going and see what happens.

Transient wrote on 2024-09-14, 08:09:

ISA clock on my board is set to 8 MHz, unless the documentation is wrong. […]
Show full quote

rasz_pl wrote on 2024-09-14, 04:07:

This bug only affects projects that aim at interacting with high impedance sources. ISA bus has own pullups and wont trigger bad […]
Show full quote

STrRedWolf wrote on 2024-08-29, 11:43:

That said, heads up on using the RP2350 for the next PicoMEM iterations: You'll want to wait until they get a RP2350-A3 (or -B0) stepping out due to a rather nasty bug in it's pull-down behavior.

This bug only affects projects that aim at interacting with high impedance sources. ISA bus has own pullups and wont trigger bad behavior.

>>After switching to NE2000.COM, it sort of works. I can login to FTPSRV, look around, but file transfers hang up
> I disabled all cache on my system and now FTPSRV works flawlessly.

35 years later same problems as developers of Wing Commander 😁
https://github.com/FreddyVRetro/ISA-PicoMEM/b … ASM#L46C1-L46C7
pause_ implements additional IO instruction to induce delay and will defeat any cache effects. You could try adding another 'in al, 61h' in there and re-test.
BUT this delay was needed on a real NE2000 and shouldnt affect PicoMEM. PicoMEM might be hurting due to ISA clock being too fast for example.

ISA clock on my board is set to 8 MHz, unless the documentation is wrong.

I am using a Pentium 90 with a VESA Local Bus motherboard, so maybe something unique with that.

I had the same thought about increasing the delay in pause_. I'll try getting a build environment going and see what happens.

Increasing the delay in pause_ didn't help. I also double checked my motherboard settings and ISA clock is 8 MHz.

However, I found a solution to the problem.

In NE2000.ASM, there's write_loop, specifically for 8086/8088 CPU. There's also a separate write_186 for 186 and later CPUs. This 186 code is problematic on my system.

I modified NE2000.ASM to always use write_loop. Additionally, I introduced pause_ inside the loop.

Now my FTP transfer is 100% stable. I get around 9.6 KiB/sec transfer rate download from FTPSRV, which is slow, but uploads are better at 68 KiB/sec.

Why are you having to use the default MTU size? 576 is an ancient number chosen for compatibility ... almost anything you will find now can use the full MTU size of 1500 bytes.

If you are dealing with gateways that support ArcNet, Token Ring, SLIP, PPP, etc. then a smaller MTU size might be needed. But for Ethernet straight through 576 is small and will hurt your performance.

mbbrutman wrote on 2024-09-16, 18:47:

Why are you having to use the default MTU size? 576 is an ancient number chosen for compatibility ... almost anything you will find now can use the full MTU size of 1500 bytes.

If you are dealing with gateways that support ArcNet, Token Ring, SLIP, PPP, etc. then a smaller MTU size might be needed. But for Ethernet straight through 576 is small and will hurt your performance.

The short answer is I don't. With the patched NE2000 code, my connection works fine with a MTU size of 1500 bytes. And yes, performance is somewhat improved by doing so.

The underlying problem is actually with PicoMEM and that write loop being too fast, at least on my system.

I'll have to wait for FreddyV to release the firmware source before I can take the investigation further.

Yoghoo wrote on 2024-09-13, 23:11:

Transient wrote on 2024-09-13, 22:39:

Well, now I feel silly. I spent two days with PM2000.COM trying to figure out why my network wasn't working, without trying NE20 […]
Show full quote

Yoghoo wrote on 2024-06-29, 16:02:

I did the same as PM2000.COM didn't work for me as well. But with NE2000.COM I can do DHCP requests but can't really use it as it's not stable at all. Even with an open case and 1 meter from an access point it's dropping half the packages etc. So not usable atm. Strange thing is that the PicoMem detects a strong connection. Thought it was maybe related with the pico (in combination my acces point) but I tested a standalone pico with C and also Python and it's rock solid. So somewhere the timings or something else is not working correctly in the PicoMem.

Well, now I feel silly. I spent two days with PM2000.COM trying to figure out why my network wasn't working, without trying NE2000.COM!

It almost seems like PM2000.COM has trouble responding, or at least I could use Telnet to login to MTCP's FTPSRV, but I wouldn't see any response.

After switching to NE2000.COM, it sort of works. I can login to FTPSRV, look around, but file transfers hang up.

About the same problem as I am having indeed. Unfortunately Freddy is mostly busy with Tandy stuff at the moment and after that probably playing with Pico 2 stuff. So the changes that this is going to be solved in the foreseeable future is pretty slim.

Hopefully he keeps his word and finally releases all the sources when the Tandy stuff is done. With the partial code that is released it's not really possible to debug it.

Hi,

PM2000 source is available since lot of time already, and of the difference is between PM2000 vs NE2000, the solution should be there.

I took extreme care to change only the detection code, so Like this, not looking at the code, I don't understand why both behave differently 🙁

Also, Maybe you use a diferent version of NE2000 that the sources I used for PM2000, this may better explain the problem.
Be removing the picomem declaration in the source, it should go back to original code

Transient wrote on 2024-09-14, 02:38:

Yoghoo wrote on 2024-09-13, 23:11:

Transient wrote on 2024-09-13, 22:39:

Well, now I feel silly. I spent two days with PM2000.COM trying to figure out why my network wasn't working, without trying NE2000.COM!

It almost seems like PM2000.COM has trouble responding, or at least I could use Telnet to login to MTCP's FTPSRV, but I wouldn't see any response.

After switching to NE2000.COM, it sort of works. I can login to FTPSRV, look around, but file transfers hang up.

About the same problem as I am having indeed. Unfortunately Freddy is mostly busy with Tandy stuff at the moment and after that probably playing with Pico 2 stuff. So the changes that this is going to be solved in the foreseeable future is pretty slim.

Hopefully he keeps his word and finally releases all the sources when the Tandy stuff is done. With the partial code that is released it's not really possible to debug it.

I was looking at the code for those two (NE2000.ASM and PM2000.ASM). It looks like PM2000.ASM can be compiled into either PM2000.COM or NE2000.COM, so I'm not 100% sure which code produced the NE2000.COM binary on Github. If the Makefile is correct, then it should have been NE2000.ASM as one would expect.

I'm not great with assembler, but it looks well commented, at least. I noticed a section for a pause_ macro which includes a note about it being ineffective on a machine with fast cache. I do have cache, although I'm not sure what qualifies as "fast cache".

Hi,
The ne2000 present on the github is what I compiles with the ne2000.asm I modified, so this is the "the same" revision as pm2000

Transient wrote on 2024-09-17, 00:44:

The short answer is I don't. With the patched NE2000 code, my connection works fine with a MTU size of 1500 bytes. And yes, perf […]
Show full quote

mbbrutman wrote on 2024-09-16, 18:47:

Why are you having to use the default MTU size? 576 is an ancient number chosen for compatibility ... almost anything you will find now can use the full MTU size of 1500 bytes.

If you are dealing with gateways that support ArcNet, Token Ring, SLIP, PPP, etc. then a smaller MTU size might be needed. But for Ethernet straight through 576 is small and will hurt your performance.

The short answer is I don't. With the patched NE2000 code, my connection works fine with a MTU size of 1500 bytes. And yes, performance is somewhat improved by doing so.

The underlying problem is actually with PicoMEM and that write loop being too fast, at least on my system.

I'll have to wait for FreddyV to release the firmware source before I can take the investigation further.

Hi,

Nice find, thanks,

Can you send me the patched version ? so that I can put it on the GitHub

Regards,
FreddyV

FreddyV wrote on 2024-09-17, 13:09:

Hi, […]
Show full quote

Transient wrote on 2024-09-17, 00:44:

The short answer is I don't. With the patched NE2000 code, my connection works fine with a MTU size of 1500 bytes. And yes, perf […]
Show full quote

mbbrutman wrote on 2024-09-16, 18:47:

Why are you having to use the default MTU size? 576 is an ancient number chosen for compatibility ... almost anything you will find now can use the full MTU size of 1500 bytes.

If you are dealing with gateways that support ArcNet, Token Ring, SLIP, PPP, etc. then a smaller MTU size might be needed. But for Ethernet straight through 576 is small and will hurt your performance.

The short answer is I don't. With the patched NE2000 code, my connection works fine with a MTU size of 1500 bytes. And yes, performance is somewhat improved by doing so.

The underlying problem is actually with PicoMEM and that write loop being too fast, at least on my system.

I'll have to wait for FreddyV to release the firmware source before I can take the investigation further.

Hi,

Nice find, thanks,

Can you send me the patched version ? so that I can put it on the GitHub

Regards,
FreddyV

Sure, no problem. I'm happy to share.

When you have time, it may be worth looking at the PicoMEM side to see what happens there when the the data is written too fast.

Hi,

Thanks a lot,

The data can't really be written too fast.
The NE2000 emulation move IOCHRDY to slow down the bus, and ISA is limited in bandwidth, below the ne2000 capability.
Also, the warning you saw in the code is for ne2000, not picomem.

It look like a CPU bug ? How is ti possible to write "Too fast" on ISA ? 😀

Also, to see what is happening, I need a PC to be able to reproduce the problem...