Minimig PCB run - interest thread

[freqmax]

I checked the MCU firmware:
http://www.opencircuits.com/Minimig_Board_v1.0_mcu_firmware

And these changes seems to be needed in order to allow an harddisc emulation:
Define "struct adfTYPE dh0;"
Update User() to handle selection 'dh0' aswell. Current implementation decides you ALWAYS want 'df0' :-)

Make HandleFpgaCmd() to take more parameters and make them variable size per request.
Modify ReadTrack() such that it doesn't presume 11 sectors per track.
Make a SectorToFpga() function that don't stuff sector header formatting into the transfered sector.

The rest is to make the FPGA to present the SPI transfered sectors to appear magicly from the Gayle ide controller.
What part would impose a data rate limit faster than is currently available? Even hardware banging floppy loaders can't get around that each track-to-track move needs 3 ms. Which should allow one to send a harddisc sector in between if so required.

[freqmax]

Is /FPGA_SEL2 unused ..?
I can't find any use of it in either the FPGA or the MCU firmware.

[freqmax]

arnljot:
The url is: http://www.opencircuits.com/Minimig_Project
(just noticed the spelling :-) )

I think people will do whatever they feel is rewarding because of what can be achieved rather than any monetary gain.

As for USB, maybe it's possible to do some "USB Light" in verilog, invisable to the Amiga? (or a small soft cpu to do the data management).
After looking at what the FPGA ports can be configured into. It seems both USB-12Mbps and 10Base-T can be accomplished by directly connect said interfaces to 3-4 resp 4 io pins.

What I think should go into Minimig v1.1 are the issues mentioned below, to be solved and integrated:
http://www.opencircuits.com/Minimig_Board_v1.0_issues

I have added a lot of info on the minimig worthwhile for anyone interested in starting lowlevel bit poking in minimig. At present it looks like hardfile r/w support can be implemented by a simple modifications of verilog sources, and mcu firmware. Same goes for 10Base-T, as it happens user0+1 and user2+3 consist of two differential capable io's.

As for actually producing a minimig v1.1. I have component list and schematic. It's just the "pcb" program that don't seem to want to autoroute the board.

[freqmax]

My idea with usb was to exploit the User-I/O header. Connecting User0+User1 to D+ & D-. And let say User2 select pullup on one D line to indicate speed. Thus eliminating the need for any external PHY, and any resulting io consumption.

Also USB might save pins. The SD/MMC slot, Keyboard, Mouse, Joystick0, Joystick1 can be replaced.

Maybe replacing the MCU with an CPLD is a viable option?
That CPLD would then be fast enough to handle Ethernet, USB aswell as booting the system etc.. And it doesn't need a boot eeprom.
Another option with CPLD is FPGA reconfiguration via ethernet.. :-)

[freqmax]

Any better fpga than the XC3S500E would require the use of a BGA socket.

As for benefits of a soft 68k core one is that supply just won't end. So it might be worthwhile to make debug and refine it. But maybe wait with using it until non-bga FPGAs become cheap and dense enough to accomodate it.

[freqmax]

mongo wrote:
Wolfgang's 68K core will run up to about 17 MHz in a Spartan

How many % of the fpga logic does it use?
Which Spartan were used?, esp which speed grade -4 or -5 ?

Page 7 (of 208)
http://direct.xilinx.com/bvdocs/publications/ds099.pdf

[freqmax]

The 68306 product summary only says "Available in 5V". Looking in the datasheets there's no mention of 3.3V. I still fail to see the benefits besides address space. Any DRAM is better controlled by the FPGA where it can be used both as Chip and Fast ram.

If 'TobiFlex' succeeded to use sdram. It would be interesting to find out more in order to replace the 2M Async SRAM with 32-64 MB DRAM or more.

One possible setup is to have two FPGAs and one XCF02S configuration memory.
FPGA0 bootloads configuration from eeprom. And loads data from SD/MMC to configurate FPGA1. FPGA1 loads data from SD/MMC to re-configurate FPGA0. Both bootloaders are deactivated. And normal operation is initiated.
This could allow elimination of the MCU and allow one extra FPGA for m68k vhdl/verilog core. Aswell as plenty of I/O pins to play with.

[freqmax]

Looking at the core files, only LVCMOS33 is used. So using XC3S500E would be feasable. Any cons/pros of using LVTTL instead?
And 622+ Mbit/s operation is possible between FPGAs.
More config eeprom choices seems to translate into easier to source and lower price.

[freqmax]

The largest Xilinx Spartan-3 FPGA that has less than 400 pins (20x20 matrix) is the FG320 package:
http://direct.xilinx.com/bvdocs/publications/ds099.pdf
(FG320 XC3S1500 is also the largest FPGA with Webpack support)

The FG320 package is an 18x18 matrix with 1mm pitch:
http://www.xilinx.com/bvdocs/packages/fg320.pdf

Schmartboard 202-0026-01 is BGA 400 Pins, 1.0 mm Pitch:
http://www.schmartboard.com/index.asp?page=products_bga&id=110

Diagram of 202-0026-01:
http://www.schmartboard.com/schmartboard_pd_202-0026-01.pdf

It would be benefitial if someone can clarify this matter. I have noticed this company in the past. Debunk time? :-D

[freqmax]

I have one work-in-progress:
http://www.opencircuits.com/Minimig_Board_v1.0_components

[freqmax]

Belial6:
Well but HOW do you solder it. Because you won't be getting the soldering iron between the chip and the pcb.

ThomasML:
Check Mouser.com, Maplin.co.uk ..?
Try google aswell. Sometimes it works.
Which country or continent do you live in?

[freqmax]

yssing:
My impression when I got their brochure is that they sell mostly beginners kit and misc junk.
Seems my local branch doesn't have PIC18LF252, and they certainly don't have Xilinx stuff. My impression is that they suck.
Btw, their url of 1059 bytes doesn't impress me either.

Digikey have the PIC18:
http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=PIC18LF252-I%2FSP-ND

[freqmax]

Reichelt: http://www.reichelt.de/
I presume.

[freqmax]

I think a more sustainable model is by delivering a "kit" ie pcb + parts. This should also allow for lower prices, even if Xenepp took a small profit. That will allow people to concentrate on soldering. Some repair shops will do soldering work for pay aswell.

[freqmax]

The problem with soldering of bga is that you can't verify the soldering operation before applying power.
Unless you (ab)use an old radio tube with an HV supply as a x-ray source. And use ccd? as a image receiver (the principal way it's done in a professional enviroment).

So soldering is complicated, but verification is the hard stuff (unless blowing chips is acceptable).

[freqmax]

I have read the MCU firmware. And I don't see any reason as to why not it should be possible to do adf-write and harddisc-read/write operations. Only program memory could hinder it as I see it.
I don't see any reason to have a 65816. Both that and 6502 can likely be done in HDL.
Also there simple is NO free i/o for another CPU with XC3S400 and not likely XC3S500E either.