»

[Darrin]

yaqube wrote:
But unfortunately the original Minimig board design imposes a limitation on the maximum communication speed with an SD/MMC card. To overcome this problem you need to short two pads of two resistors (very simple soldering task). Otherwise the emulated hard disk transfer speed is limited to ca 200 KB/s.

Does that mean that with the ARM and the pad shorted you could implement a "turbo floppy mode" where the read/write speed to the ADF images is accelerated?

[Everblue]

Probably that would be a problem to some games? Just a very wild guess.

[Darrin]

Everblue wrote:
Probably that would be a problem to some games? Just a very wild guess.

Probably. It would have to be optional as in WinUAE.

[yaqube]

Darrin wrote:

Does that mean that with the ARM and the pad shorted you could implement a "turbo floppy mode" where the read/write speed to the ADF images is accelerated?

Nope. The "turbo floppy mode" doesn't need the ARM board at all. But with the ARM the turbo mode is faster. Now I can't tell how fast the floppy turbo mode is when using the PIC but with the ARM basic transfer speed is ca 30 KB/s and in turbo mode ca 60 KB/s. No need to short the pads but it's advised since the overall system speed is higher.

[countzero]

yaqube, there's a swedish guy here which makes Mini-Itx minimig boards. Is it possible to get rid of the PIC in the design and put ARM directly ? I mean it should definitely be possible, but what should he keep in mind while making the changes ?

this is the guy : illuwatar
project page

illuwatar, what are your thoughts on this ?

[denli]

As what I can tell from previous threads Illuwatar is keeping his design 100% compatible with Dennis v1.1 design. Thus you can use both the original PIC or the ARM addition.

[mikej]

Yaqube, could you clarify which pads needs to be shorted and why?

"But unfortunately the original Minimig board design imposes a limitation on the maximum communication speed with an SD/MMC card. To overcome this problem you need to short two pads of two resistors (very simple soldering task). Otherwise the emulated hard disk transfer speed is limited to ca 200 KB/s."

I would like to make sure the FpgaArcade dev board I have developed can run at the faster speed. It uses an AVR rather than a PIC and dual SPI controllers so I can suck a block fro the SD card while sending the last one to the FPGA. It won't help if I am limited to 200KB however..

Thanks,
Mike.

[boing4000]

Possible that SPI_CLK (over R50, R51 = SD > CLOCK) is also set to a higher frequence...? But this is just a simple rectangle pulse signal without any data spread.
Currently this signal is clocked at aproc. 1.2MHz that is much faster then the DIN/DOUT data signal flow.

[yaqube]

mikej wrote:
Yaqube, could you clarify which pads needs to be shorted and why?

Dennis had problems with his MMC card because it was still active even when its _CS line was held high. So he gated the MMC clock line with very simple solution: he put the R51 (1K) in series with the R50 (270R) and shorted the connection between them to VCC (with the PIC RA0 pin) whenever the MMC card was inactive.

The drawback of this solution is that there is a huge impedance between the source of the clock (the PIC) and the MMC card effectively limiting rising/falling edge speed of the CLK signal. I have modified the program not to disable the MMC clock and it works with all mine MMC and SD cards (I have only tested about ten different types). Bypassing these two resistors allows to run an SD card with 24 MHz clock. This solution isn't perfect but relatively simple.

The best solution would be to put a series source-terminating resistor to match the PCB trace impedance (60-90 Ohm) and have proper clock routing topology.

[mikej]

Great, thanks for the info. I remember talking to Dennis about this a while back actually. That was the other reason I went for a dedicated SPI connection to the SD card with a source terminated clock so I shouldn't have this problem. The (slightly out of date) schematics are up on line if you want to have a look.

I remember another issue somebody mentioned that if you were doing a mode change from MMC to SD then you needed to reboot the SD card. This would require a FET on the power supply to the SD card which I would rather not add. Anybody come across a need for this?

Cheers,
Mike.

[mikej]

ah, I found the power cycling issue, it was from my mate Arnim from Opencores. If you switch the card from SD mode to SPI mode then you can only switch back to SD/MMC mode by power cycling the card. This is not an issue for us as both the FPGA and the boot controller both talk SPI.

/Mike

[Sig999]

This is great news! I was hoping things would go in this direction, it could probably replace my aging 2000. As much as I thought the project was very cool, for me playing games was only half the fun of my old system - if I could fire up devpac and a couple of other goodies and play I would buy one in a heartbeat.

Hopefully this bit 'o kit will eventually be incorporated into a buyable product - my soldering skills are OK.. but I wouldn't trust them enough for the ram soldering.

I realise that space on the board is limited - but I was thinking wouldn't it be possible to put some kind of socketed ram board off the main (a la kickstart switchers)?

eh, what do I know? I'm a software guy :P

[wolfchild]

I hope this is not too late for inclusion in the LPC2388 version...

Since this ARM controller has a dedicated RTC module on chip, I'd like to suggest placing a CR2032 lithium battery with holder on the piggyback module/new PCB. This is the type used on PC motherboards and generally known to be leak free.

I don't know what it involves in terms of software/FPGA coding, but it would be a nice touch having files with correct time stamps. Always if the Amiga OS is Y2k compliant, anyway.

Edwin

[yaqube]

The LPC2388 is planned to be used in the next generation of Minimig. The RTC with battery back-up is on the list.

The PIC replacement version is based on the AT91SAM7S256 and has no RTC. But can be used in any Minimig V1.1 board (designed by Dennis).

I have talked to Peter about a possibility of including the ARM controller on the Minimig-ITX board. It's seems to be feasible.

[TheDaddy]

@Jakub,

Don't forget to inform me when the next generation Minimig is ready, I would love to make a case for it and continue the family tree :-)