Minimig user feedback required

[tonyyeb]

Atheist wrote:
Ethernet port on a 7MHz device? Won't that use up all the CPUs time or flood it with data??? Isn't 2 * 56K max ports beter?

Well I run wifi on my A1200 fine, and that is only a 14mhz CPU (Minimig can do 25mhz).

[Atheist]

What's with all the closed mindedness in the Amiga community?

I think it would increase the flexibility by leaps and bounds.

Who needs 65536 channels in an ethernet connection componding the complexity of what's a simple peer to peer transfer on a 25 MHz device?!?

Running 100 K SW rather than 2 Megs.

[kolla]

Atheist wrote:
at least 1 56 K modem RJ25 jack

What is 56 K modem? What is RJ25 jack?

Would really like:
4 or 8 Megs chip ram (as well as 8 megs Fast.)
Second modem jack for ring or star lan.

More than 2MB chip is not supported by AmigaOS, so no point with that. Modem jack for ring or star lan? Jack? Token Ring? ArcNet? Ethernet? What?  :-?

[Belial6]

When it comes to attaching new devices to the MiniMig, I would still like to see an Ethernet port added, but instead of using it directly, build all other ports into the FPGA, and tunnel them over the Ethernet.  This would allow access to any device that could be built in the FPGA and emulated on the network (including a network card).  The beauty is that for anyone wanting a real device attached to the MiniMig, all they have to do is build a small board that receives the tunneled data, and passes it to a real port.

So, if you wanted an IDE drive, you would build a virtual IDE connection in the FPGA core so that the as far as the software is concerned, it is a real IDE port.  This gets tunneled over the Ethernet port.  You then either run an emulated MiniMig IDE drive on your server (which could be a share, a disk image, or an entire drive) or you build a small board that has the sole purpose of receiving the tunneled data and converting it to be used with the real IDE connector on the board.

This approach would solve a lot of problems.  Namely:

* The number of spare pins would no longer be an issue, as once the Ethernet was hooked up, all other device connections would be on the single Ethernet port.
* Improvement to the MiniMig would have the hardware and software upgrades decoupled.  Something like scanner support could be added via software/firmware only by making it connect to a server, and then if an industrious hardware developer wanted to make it stand alone, a board could be built after the fact.
*USB devices would be accessible to the MiniMig.  By attaching the devices to a server, the server side emulation layer could take the entire load of the USB stack, and present the MiniMig with access to the device as something as simple as a serial device.
* Any device could be turned into a wireless device with the addition of a standard off the shelf wireless bridge.

Given the nature of the MiniMig, being able to add devices without having to build a physical board, and only building the physical port if there is enough demand, would be a huge benefit.

[weirdami]

If you had found any games causing problems or not working at all please tell me their names.

I think someone on here posted about a compatibility list already being made.

[tonyyeb]

weirdami wrote:

If you had found any games causing problems or not working at all please tell me their names.

I think someone on here posted about a compatibility list already being made.

Well i've taken the Open Circuits list and made it into a search able database over at www.aukug.co.uk

[bloodline]

@Belial6

Not that clever an idea... It simply isn't worth using a MiniMig then, just use UAE...

[yaqube]

Darrin wrote:

So which of your arms do I need to twist to get hold of an ARM controller?  :-D

No need to do this. There is one already waiting for you.  :-D

[Darrin]

yaqube wrote:

Darrin wrote:

So which of your arms do I need to twist to get hold of an ARM controller?  :-D

No need to do this. There is one already waiting for you.  :-D

PM sent.  ;-)

[yaqube]

mahen wrote:

If the subdirectories support is not done soon, maybe in the meantime there could be a way to scroll through the filelist faster ? (one page at a time instead of one line at a time

I have increased scrolling speed through the file list but it seems to work faster only on my ARM micro. It seems that the PIC is too slow to traverse through directory entries any faster.

You are refering to a "genlock" required to "sync with the line frequency". Do you mean it would require an extra hardware component ?

I only mean that I wasn't able to implement it at my first try. I don't say it's impossible using current hardware. I must think about it to tell you more.

[B00tDisk]

Put room for an 030 in the design! :-D :-D :-D

(sorry, couldn't resist)

[Fransexy_]

kolla wrote:
More than 2MB chip is not supported by AmigaOS

On Winuae, Workbench detect and use without any problem the 8 MB chip ram configuration  :shrug:

[whiteb]

My guess is that Kolla has not even loaded Winuae

[Belial6]

bloodline wrote:
@Belial6

Not that clever an idea... It simply isn't worth using a MiniMig then, just use UAE...

Why?  I don't see any connection...

[Dwyloc]

I think we are getting kind of off topic here as the original topic of this thread was what software enhancements would people like to see for the minimig not what hardware people want the for a later generation Minimig.

And the most popular answers seem to be:

1. Second Floppy disk drive emulation support
2. Support for folder to help organise adf images.
3. Harddisk emulation using existing SD card hardware.
4. CPU speed setting in software
5. Selectable PAL/NTSC emulation from menu.

[yaqube]

@Dwyloc

Thank you for your feedback.
Let me add few words of comment.

1. Second Floppy disk drive emulation support

It's already done.

2. Support for folder to help organise adf images.

This is requested by many people and I may implement this sooner than I intended.

3. Harddisk emulation using existing SD card hardware.

If you meant the existing PIC micro controller it won't be done.

4. CPU speed setting in software

Already done.

5. Selectable PAL/NTSC emulation from menu.

I have already thought about this but the OSD menu is displayed using the same video mode as the Amiga chipset uses. If you change to PAL and your monitor doesn't support 50Hz vertical sync you will end up with no display and won't see an OSD menu to change it back. But I understand that with KS1.3 there is no easy way to switch between video modes before running a game so this option might be added.