STrRedWolf wrote on 2024-03-02, 12:23:

FreddyV wrote on 2024-03-02, 11:19:

SPI BUS is fast, so the more we add on it, the less reliable it will be. (PSRAM is accesses at 120MHz)
4Mb is really good for XT 😀

I was about to say "I saw Pimoroni had 16Mb models" but it turns out it was flash, not PSRAM.

Still, 4Mb of LIM EMS? I'll be worth it.

4Mb or even 6Mb is possible.
What is limitting is that the PicoMEM emulate the Lotech board, having 4*8bit registers, so 4Mb maximum.
I don't have hardware spec for another board, so I emulated this one, it was more simple.

FreddyV wrote on 2024-03-05, 07:45:

There is a low reaction on my project for the moment here, yes, but when more popular youtuber will release their video and more boards will be available, it will surely change.

Ordered one today. 😀 But I don't think a lot of Vogons users are aware of the state of this project and that you could order one (think it will be closed soon/today?) as most of the updates are only on Discord (and Twitter I believe). So that maybe explains the low amount of reactions.

Thank you for all the clarifications @FreddyV. I understand better the limitations of the RP2040 here.

FreddyV wrote on 2024-03-05, 07:45:

I don't understand what you mean about the DMA, The Pico can access the SD and still response to all the ISA bus request. Then, the Pico read SD sectors while the PC Copy the previous sector to the program at the same time.

I understood that the bus was locked during SD card reading. My bad. It is good to know both access can be done independently.

FreddyV wrote on 2024-03-05, 07:45:

I May add one ISA DMA Channel in another revision of the board and Emulated DMA is possible (For Sound Blaster support for example)

With such a project it could be possible to emulate all sort of expansion cards including uncommon ones. And having access to a DMA channel is always a good thing as drivers may require it to work. I know nothing about emulated DMA. Are they false DMA only here to satisfy the software? Because the goal of DRQ/DACK lines is to allow direct access to memory independently from what the CPU is doing, consequently improving performance or allowing the hardware to just work as expected. Correct me if I am wrong.

FreddyV wrote on 2024-03-05, 07:45:

I Will release the firmware code, it is just a matter of time, so if somebody want to add CD or whatever later....

Great news. Thank you 😁

@STrRedWolf
About the EMS memory, is a maximum 4 MB a real limitation? Remember that most of the EMS ISA cards at the time were between 1 and 4 MB. Of course it would be better to have 16 MB, but does any software can uses this amount of memory anyway?

Yoghoo wrote on 2024-03-05, 11:46:

Discord

Yes, discord doesnt count like posting something on the internet. Nobody can link to it, no search engine crawls it, its a black hole.

does the picomem have any DOS utilities to configure it at runtime? say, to change the floppy disk image?

megatog615 wrote on 2024-03-05, 16:27:

does the picomem have any DOS utilities to configure it at runtime? say, to change the floppy disk image?

Not yet, but I will do it, it is in the pipe.
The more complex part are often code Interface, file list and so on, not the actual emulation.

Datadrainer wrote on 2024-03-05, 12:27:

I understood that the bus was locked during SD card reading. My bad. It is good to know both access can be done independently.

With such a project it could be possible to emulate all sort of expansion cards including uncommon ones. And having access to a DMA channel is always a good thing as drivers may require it to work. I know nothing about emulated DMA. Are they false DMA only here to satisfy the software? Because the goal of DRQ/DACK lines is to allow direct access to memory independently from what the CPU is doing, consequently improving performance or allowing the hardware to just work as expected. Correct me if I am wrong.

The Pico is dual Core.
If we count the PIO Cores, in total, there are 5 Cores plus a DMA running at the same time for emulated Disk Access.
PC CPU + 2 ARM Code + 2 PIO Core + DMA
Disk access "saturate" the ISA BUS, most of the time, it is "REP MOVSW"

Emulate DMA is simply use interrupt and a code doing the copy to the "Shared" RAM.
Does it block by block and update the DMA Controller registers in the TSR... (Like 16 Bytes per 16 bytes)

It is slower than real DMA, but faster than use a Timer IRQ for Sound Blaster emulation on a slow machine for example.

Yoghoo wrote on 2024-03-05, 11:46:

But I don't think a lot of Vogons users are aware of the state of this project and that you could order one (think it will be closed soon/today?) as most of the updates are only on Discord (and Twitter I believe). So that maybe explains the low amount of reactions.

Is there a discord link available? I'd happy follow along over there to stay in the loop

FreddyV wrote on 2024-03-05, 18:53:

The Pico is dual Core. If we count the PIO Cores, in total, there are 5 Cores plus a DMA running at the same time for emulated D […]
Show full quote

Datadrainer wrote on 2024-03-05, 12:27:

I understood that the bus was locked during SD card reading. My bad. It is good to know both access can be done independently.

With such a project it could be possible to emulate all sort of expansion cards including uncommon ones. And having access to a DMA channel is always a good thing as drivers may require it to work. I know nothing about emulated DMA. Are they false DMA only here to satisfy the software? Because the goal of DRQ/DACK lines is to allow direct access to memory independently from what the CPU is doing, consequently improving performance or allowing the hardware to just work as expected. Correct me if I am wrong.

The Pico is dual Core.
If we count the PIO Cores, in total, there are 5 Cores plus a DMA running at the same time for emulated Disk Access.
PC CPU + 2 ARM Code + 2 PIO Core + DMA
Disk access "saturate" the ISA BUS, most of the time, it is "REP MOVSW"

Emulate DMA is simply use interrupt and a code doing the copy to the "Shared" RAM.
Does it block by block and update the DMA Controller registers in the TSR... (Like 16 Bytes per 16 bytes)

It is slower than real DMA, but faster than use a Timer IRQ for Sound Blaster emulation on a slow machine for example.

Thank you for the explanation. I understand how it work now 😀
The limitations of the components mean that you constantly have to arbitrate to make things work "well enough". And this is also the point of the challenge!
In complement, I take a look at the very interesting video made by Rodrik where he demonstrate it working.

Nice,

I share it again.
https://youtu.be/urBkxpwz69Q?si=tIUAS8N-n0UMThMo

In march, more Videos should appears.

Datadrainer wrote on 2024-03-05, 12:27:

@STrRedWolf
About the EMS memory, is a maximum 4 MB a real limitation? Remember that most of the EMS ISA cards at the time were between 1 and 4 MB. Of course it would be better to have 16 MB, but does any software can uses this amount of memory anyway?

4MB was the LIM EMS v3.2 limitation. LIM EMS v4.0 expanded this to 32MB.

STrRedWolf wrote on 2024-03-12, 00:40:

Datadrainer wrote on 2024-03-05, 12:27:

@STrRedWolf
About the EMS memory, is a maximum 4 MB a real limitation? Remember that most of the EMS ISA cards at the time were between 1 and 4 MB. Of course it would be better to have 16 MB, but does any software can uses this amount of memory anyway?

4MB was the LIM EMS v3.2 limitation. LIM EMS v4.0 expanded this to 32MB.

LIM 4 is one of the magic unicorns that makes everything in DOSland better,

Sadly it’s rare/uncommon a project like this one could use one of the better LIM 4 solutions to emulate

rmay635703 wrote on 2024-03-12, 01:19:

LIM 4 is one of the magic unicorns that makes everything in DOSland better,

Sadly it’s rare/uncommon a project like this one could use one of the better LIM 4 solutions to emulate

It was asked to me multiple time already 😀
Later, when the source will be published, somebody can try to do it.
I did not search if a better EMS emulation exist somewhere. (DOSBOX or other)

Hi,

If you want to discover or know more about the PicoMEM, RetroErik released a video :
https://youtu.be/PwSLWsxip00?si=Ehzuv5D_560-ekXy

FreddyV wrote on 2024-03-22, 10:06:

Hi,

If you want to discover or know more about the PicoMEM, RetroErik released a video :
https://youtu.be/PwSLWsxip00?si=Ehzuv5D_560-ekXy

Nice! Any time line when it will be available? I signed up for the board but didn't hear anything yet.

Yoghoo wrote on 2024-03-22, 10:52:

Nice! Any time line when it will be available? I signed up for the board but didn't hear anything yet.

I sent 30 new boards to production.

This time I asked JLC to solder even the Pico, so I hope it will work.

rasz_pl wrote on 2024-03-05, 12:29:

Yoghoo wrote on 2024-03-05, 11:46:

Discord

Yes, discord doesnt count like posting something on the internet. Nobody can link to it, no search engine crawls it, its a black hole.

Amen. Projects locking away their coms in a Discord is a terrible trend.

I have an interest in retro hardware and have been experimenting with replicating the original 8088 based PC on a set of PCBs for my own fun and education.

This is a very interesting card, in that I understand that it can replicate the floppy drive?

My design is simplified in that I did not implement DMA, as I felt it unecessary. The Tandy1000 also omits DMA and was nevertheless able to read and write data from/to the floppy disk controller IC (and was the inspiration). Unfortunately I have run into problems trying to get floppy I/O to work.

Again I get the impression that this card doesn't have DMA, so I wondered if the "virtual" floppy was accessed via I/O ports?

Sorry if my assumption is way off base(!), but if the "virtual" floppy doesn't use DMA, then presumably use of this card would need a custom BIOS or possibly an option ROM (which I again assume that it can emulate) to allow the INT13 floppy/HDD routines.

I just wondered if this card might be a way to help me get my hardware to boot DOS? I have my own minimal BIOS so I can change the floppy disk code if there was some alternative I/O based way of accessing the floppy hardware. I was already thinking about doing something similar to give me an I/O based floppy interface, speed is not an issue for me, possibly using a Teensy in a similar way. But there's no need to re-invent the wheel!

Again apologies (I found information unclear), but what bus speed does this card support? Does it stall the CPU using RDY/wait to extend bus cycle for faster CPUs?

Many years ago I figured a way to use a PIC to emulate a small specialised ROM chip which was no longer available and I had to find a way to return the data quickly enough for it to be read correctly. Thankfully the ROM it replaced was quite slow. I get the impression that the PICO must be doing something similar, but emulating both RAM and ROM and I/O ports?

Perhaps I should join the discord?

Anyway I think it is a fabulous project and yet another clever way of using modern cheap hardware to emulate parts (possibly unobtainable or expensive) of a retro computer. I am sorry to hear that the author was disappointed at the lack of initial enthusiasm from the retro community.

Very very cool project. Following. Good job 😀

kingcake wrote on 2024-03-23, 03:18:

rasz_pl wrote on 2024-03-05, 12:29:

Yoghoo wrote on 2024-03-05, 11:46:

Discord

Yes, discord doesnt count like posting something on the internet. Nobody can link to it, no search engine crawls it, its a black hole.

Amen. Projects locking away their coms in a Discord is a terrible trend.

We use discord to work together, not to communicate.

The reception I have is really low on Vogons, when I did post on Mod Master XT, there was a full community behind me here.

The "Sound" part of the forum is really more active.