Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Darrin on December 22, 2008, 12:52:40 AM
-
OK, all Minimig v1.1 owners prepare to weep like children! Our resident genius Yaqube has just posted a demonstration of Hardfile support on the Minimig v1.1 with his ARM extentension board.
Follow this link to see his post and then click on his link to go to uTube and watch the 6 minute demonstration of his machine booting into what looks like Workbench 3.0/1, running Sysinfo and then playing several hard drive installed games:
http://www.minimig.net/viewtopic.php?f=7&t=11&p=153#p153
You might also note that this Minimig has the following:
68000 @ 25MHz (should help with those flight sims)
1.5MB Slow RAM
2.0MB Chip RAM
4 x Floppy drives (df0, df1, df2 and df3)
1 x 512MB Hardfile showing as a FFS SCSI drive
Brilliant work! This really is a complete expanded A500 replacement suitable for most people.
-
Ummmm, my normal minimig only has 2MB on the board, I take it this one has new ram or something, or does the ARM contain RAM that configs as well ?
According to the Youtube comments, Ram was "Piggy Backed", you cannot just plop on two more chips and have them work surely ?
I thought you would at least need to separate them via Address lines ?
-
whiteb wrote:
Ummmm, my normal minimig only has 2MB on the board, I take it this one has new ram or something, or does the ARM contain RAM that configs as well ?
According to the Youtube comments, Ram was "Piggy Backed", you cannot just plop on two more chips and have them work surely ?
I thought you would at least need to separate them via Address lines ?
I've no idea. I've posted the question and I'll be interested to see the answer. :-)
Edit: and here's how, plus a picture:
http://www.minimig.net/viewtopic.php?f=3&t=27
-
To piggyback a RAM chip, just separating the most significant bit address will suffice.
-
I see from the link Darrin supplied he is using the Extra I/O plug to (I think) route signals to the new chips no doubt a couple of address lines. That is Soldering FAR IN ADVANCE of my own.
[edit] actually, that could VERY WELL be it.
From memory, the 68882 occupied *A LOT* of the same signals that the 68xxx occupied, You just had to select the specific address lines that the chip used. I do not know the pin outs of the chip, it looks like one pin may be bent up, and wire'd, maybe a "CS" (Chip Select) line, with the rest coexisting signals that both chips use ?
[edit2] Yeah, if that is indeed pin 6 in the picture, that is CE (Chip, Enable input). You just disable that pin on the FPGA, the Existing chips will NEVER receive CE, and it will ignore EVERYTHING ELSE (or how i understand it).
-
My soldering skills are zero too, but I'm sure I can pay someone local to do it when the exact instructions are published.
-
Great stuff Jakub! :-)
-
if that ram chip piggy backing thing works then why aren't manufacturers doing it to save on sockets and stuff?
-
weirdami wrote:
if that ram chip piggy backing thing works then why aren't manufacturers doing it to save on sockets and stuff?
Probably because your average PC motherboard has plenty of room for extra sockets and your average PC user doesn't want to piddle around with a soldering iron when he upgrades his RAM. :-)
-
Looki ng at other news on this thread, what that demo really needs is AmigaSYS installed on that Hardfile. :D
-
WOW :-D This is brilliant - Even running WHDload - As I consider other Amiga clones a joke -Well done yaqube!(http://eab.abime.net/images/smilies/xmas.gif)
-
awesome stuff :-)
idea... how difficult would it be to have a minimig with an A500 compatible sideslot/edgeconnector?
-
weirdami wrote:
if that ram chip piggy backing thing works then why aren't manufacturers doing it to save on sockets and stuff?
Sockets are used for ease of putting in/Taking out.
This trick is done, to *DISABLE* the existing chip, in favor of the new chip. Also, given the nature of the board, its *FRAGILE !!!!!*. I have tried to desolder a damaged minimig, and lifted the pads in the process (hey, it was damaged), so you just solder over the top of the existing one, and just re-route the 'Chip Select' line.
This way it is ONE or the other, not both. If it was to use BOTH ram, then you would need independent addressing (At least).
-
Darrin wrote:
Looki ng at other news on this thread, what that demo really needs is AmigaSYS installed on that Hardfile. :D
Is there one for A500/A600's ? I think the lowest Amigasys for classic is A1200/4000 etc (AGA).
Unless you mean ClassicWB, they all need 68020+.
-
darksun9210 wrote:
awesome stuff :-)
idea... how difficult would it be to have a minimig with an A500 compatible sideslot/edgeconnector?
Larger FPGA (more I/O), larger board.
-
whiteb wrote:
This trick is done, to *DISABLE* the existing chip, in favor of the new chip. Also, given the nature of the board, its *FRAGILE !!!!!*. I have tried to desolder a damaged minimig, and lifted the pads in the process (hey, it was damaged), so you just solder over the top of the existing one, and just re-route the 'Chip Select' line.
This way it is ONE or the other, not both. If it was to use BOTH ram, then you would need independent addressing (At least).
Ah so this was a "safer" way to replace the existing RAM chips without having to remove them?
-
Clever idea by yaqube with the piggy backing. But he is not disabling the original 2 MB SRAM on the board - he adds an extra 2 MB (making up these 4 MB total). The CS1-pin (nr 6) are used to choose what half of the 2 MB that will be used. All other pins are connected in parallel - that is normal and should be like that. Even on a standard 2 MB MiniMig, all pins except of CS1 are connected in parallel. The core of the FPGA has been modified to provide four chip select signals instead of just two.
Someone complained about the amount of free space at my MiniMig design - here is a reason to fill it up... these mods will keep me busy changing the design all the time. I hope there will be a final so I can make the Ultimate Mini-ITX MiniMig. I would be nice to put that ARM thing right on the motherboard too...
-
Darrin wrote:
Ah so this was a "safer" way to replace the existing RAM chips without having to remove them?
Precisely. Solder the chips directly on to the old ones, and route the new CS signal over the Spare I/O.
The new chips are 10ns too, so that alone makes the Minimig compatible with that 1943 clone :)
-
whiteb wrote:
Is there one for A500/A600's ? I think the lowest Amigasys for classic is A1200/4000 etc (AGA).
Unless you mean ClassicWB, Lite can run on 2MB, ADV needs 4MB/030, 3.9 needs 6MB ram and 030.
Bugger! I tried putting OS3.9 on an expanded 68000 A2000, but the install failed to work so without a 68020 or better then the only option for a "pretty" workbench will be an installation of New Icons.
-
whiteb wrote:
Precisely. Solder the chips directly on to the old ones, and route the new CS signal over the Spare I/O.
The new chips are 10ns too, so that alone makes the Minimig compatible with that 1943 clone :)
Fantastic! That makes this news even better! Cheers for that info. :-)
-
Illuwatar wrote:
Clever idea by yaqube with the piggy backing. But he is not disabling the original 2 MB SRAM on the board - he adds an extra 2 MB (making up these 4 MB total). The CS1-pin (nr 6) are used to choose what half of the 2 MB that will be used. All other pins are connected in parallel - that is normal and should be like that. Even on a standard 2 MB MiniMig, all pins except of CS1 are connected in parallel. The core of the FPGA has been modified to provide four chip select signals instead of just two.
Someone complained about the amount of free space at my MiniMig design - here is a reason to fill it up... these mods will keep me busy changing the design all the time. I hope there will be a final so I can make the Ultimate Mini-ITX MiniMig. I would be nice to put that ARM thing right on the motherboard too...
It must be getting frustrating for you - every time you think you have your design finsihed then another good idea comes along. :-)
-
whiteb wrote:
This trick is done, to *DISABLE* the existing chip, in favor of the new chip. Also, given the nature of the board, its *FRAGILE !!!!!*. I have tried to desolder a damaged minimig, and lifted the pads in the process (hey, it was damaged), so you just solder over the top of the existing one, and just re-route the 'Chip Select' line.
This way it is ONE or the other, not both. If it was to use BOTH ram, then you would need independent addressing (At least).
As long as there are separate Chip Select lines, there is absolutely no reason why you couldn't use both RAMs.
As a matter of fact, unless the Minimig has extra, unused address lines going to the RAM (which I doubt) then you have to use both RAMs to gain any benefit.
-
Illuwatar wrote:
Clever idea by yaqube with the piggy backing. But he is not disabling the original 2 MB SRAM on the board - he adds an extra 2 MB (making up these 4 MB total). The CS1-pin (nr 6) are used to choose what half of the 2 MB that will be used. All other pins are connected in parallel - that is normal and should be like that. Even on a standard 2 MB MiniMig, all pins except of CS1 are connected in parallel. The core of the FPGA has been modified to provide four chip select signals instead of just two.
Are you sure ? The signal is a CS (Chip Select), its one OR the other. CS means one or the other, not both. And if the chips were to be used concurrently, they would need separate address lines. (Read, not enough I/O on the FPGA).
Whats stopping us from putting higher density with the same trick ?
-
For anyone who is going to buy a Minimig now (after this great work done by Jakub) please remember that if you want a case for it, I have only got 20 left of the second batch (arriving in the middle of January).
email: amigarulez@hotmail.com
Thank you :-)
-
TheDaddy wrote:
For anyone who is going to buy a Minimig now (after this great work done by Jakub) please remember that if you want a case for it, I have only got 20 left of the second batch (arriving in the middle of January).
email: amigarulez@hotmail.com
Thank you :-)
Do you have the email addresses of your case customers? Ever considered doing a monthly newletter to keep them up to date on developments?
-
Good idea, although it might take a bit to sort all the emails out :-)
-
whiteb wrote: Are you sure ? The signal is a CS (Chip Select), its one OR the other. CS means one or the other, not both. And if the chips were to be used concurrently, they would need separate address lines. (Read, not enough I/O on the FPGA).
Whats stopping us from putting higher density with the same trick ?
Yes - I'm sure. That's the whole idea with Chip Select - to select what chip to read/write. Also, if you look at the pictures in the linked thread - the piggy backed parts are 512 x 16 (1 MB), so there is no way they alone makes up the total 4 MB. He needs the two other ones too. The two wires added to the FPGA spare ports are the new CS-signals, giving the design a total of four CS signals, one for each SRAM chip. Internally, inside the FPGA, there is an address decoder, converting the two most upper addresses (not seen externally) to these four CS signals (don't know the exact implementation, but two address lines gives you four CS).
Higher density = more address lines = more pins and different pin layout (needs a new PCB). The next step is 1024 x 16 (2 MB) SRAM and they don't fit (I use these on my Mini MiniMig to save space).
-
Great demo! Minimig is starting to become a real prospect for replaceing real Amiga hardware. 020 and AGA along with everything shown here and it will be on my shopping list!
-
I figured i might as well post this here instead of starting a new thread for it. is there any possible way to get actual floppy drive support on the minimig with the existing hardware? I am planning a minimig laptop (in the event i can somehow get a minimig for undet 150USD shipped) and mainly wanted the floppy drive for the novelty of being able to use the original disks.
-
Triton199 wrote:
I figured i might as well post this here instead of starting a new thread for it. is there any possible way to get actual floppy drive support on the minimig with the existing hardware? I am planning a minimig laptop (in the event i can somehow get a minimig for undet 150USD shipped) and mainly wanted the floppy drive for the novelty of being able to use the original disks.
To be honest, I can't see where you could hope to attach one on the current design.
In theory the C-One design could take a Catweasel in the PCI slot, but it still means that someone would have to write the code to make it work.
I don't see that happening any time soon if at all.
-
Darrin wrote:
In theory the C-One design could take a Catweasel in the PCI slot, but it still means that someone would have to write the code to make it work.
I don't see that happening any time soon if at all.
No need for a catweasel, the C-One has a floppy drive connector.
Regards,
Frederic
-
FrenchShark wrote:
No need for a catweasel, the C-One has a floppy drive connector.
Regards,
Frederic
Ah, thanks. I'm really looking forward to using my C-One as an Amiga and C64 replacement. I just hope that someone manages to release a core that takes advantage of some of the extra ports on the motherboard. While a real floppy drive support would be handy for making ADFs from real disks, I'd like to see the IDE hard drive port enabled, the A1200 clock ports for expansion cards like the Subway USB controller, printer support and (ultimate wet dream) PCI graphics card RTG support via CGX.
Personally, I'd be happy with just hard drive or hard file support on the C-One. :-)
-
I have some questions about these mods. Does jakub post here ? or is there a website with more elaborate details ? Core available for download ?
first thing, about RAM hack. What did he change in the core to access the new RAM ? just assigning extra IO pins to Address bus is ok ?
the 25 MHz 68000 hack. Is this softcore 68000 ? or did he overlock existing 68000 ?
And finally the HDD. Is this available with an extra SD slot ? (SD card dedicated as a HDD) or is it a hardfile on the SD slot of the minimig ? If the latter, is there anything that prevents normal minimig users to use this ? (is it dependent on the ARM board ?)
-
Please read the postings on minimig.net (link in Darin's 1st post). Also take a look at the high quality youtube video to find out more answers to your questions :-)
Facts are:
There are no 25MHz available but 28.37Mhz - Sysinfo is not state of the art. As long as the CPU is in sync with the OCS/ECS chipset the clock rate is a multiple of 7.xx MHz or in other words a divider of the 28 MHz source clock.
A file called "Hardfile.bin" is present on the existing SD card in the original SD slot. Jakub inplemented an A600/A1200 GAYLE IDE interface to make it accessable.
(This may only be possible by using the PIC replacement board.)
The original 68SEC000 CPU is able to operate at nearly 30MHz. Also the existing Spartan3 FPGA is not big enough to take the TG68k softcore made by Tobias.
-
Looks interesting..
My soldering skills are top-notch..where can I get this stuff..??
Rich
ny
-
what are the specs of the ARM used? How much connectivity does it have to the FPGA? Could one also run a 68000 emulator on it? :idea:
-
This ARM module is just a PIC replacement. The ARM cpu has more power and room for bigger firmware and HDF support. Jakub made his own experimental board afaik. NO 68k simmulation can run on it, the PIC socket only provide a simple SPI bus to the FPGA.
Compatibility: 100% - depending on programming.
-
boing4000 wrote:
This ARM module is just a PIC replacement. The ARM cpu has more power and room for bigger firmware and HDF support. Jakub made his own experimental board afaik. NO 68k simmulation can run on it, the PIC socket only provide a simple SPI bus to the FPGA.
Compatibility: 100% - depending on programming.
Even the cheapest ARM available is much much more powerful than the most powerful 68k ever made. If a more powerful ARM were used, one could run a 68020 emu to replace the 68000... That is a more elegant solution :-)
-
The ARM chip is already a cpu by itselfs and in your way of thinking it had to emulate the 68k (0x0) cpu. That would male it much much slower then the real calculating speed. ARM is in fact faster but still just a microcontroller with an embedded cpu, ram and (flash)rom. So no way to simulate the TG68k core!!
See it as an extendet PIC with more resources.
Also the last thing in "minimig mind" is to emulate something! The whole thing is programmed hardware and want/need to stay that way. Everything else would make it to an UAE rebuild.
-
boing4000 wrote:
Also the last thing in "minimig mind" is to emulate something! The wohole thing is programmed hardware and want/need to stay that way. Everything else would make it to an UAE rebuild.
Exactly. The Minimig v1.1 is an A500 replacement and not a next-generation classic PC.
The achievable goals for the Minimig v1.1 are:
68000 @ 28MHz - already done
Extra RAM - done
Floppy drives - done, df0-df3
Hard Drive support: done, IDE HD emulation via hard file
Firmware update from USB/SD Card - planned
Also, the serial port can be used to link the Minimig to a PC to access the PC printer (and other devices).
All in all, I think this makes for a good replacement A500.
Now, if we want to talk about pushing the envelope and developing a more advanced Amiga then the C-One motherboard has some serious potential with more room for softcore processors, a real processor slot, PCI card for expansion cards, 2 x Amiga clock ports, IDE headers, floppy connector, CF Card slot and parallel port. Of course the cost is much higher. It's a case of what are you prepared to pay for. For classic gaming with a few old applications the Minimig v1.1 is more than enough.
-
To me Minimig is a very native Amiga(500/1000) rebuild with many modern features.
Thanks to Dennis's open source Amiga chipset all kind of new expansions and development is possible :-)
In the future this project will grow, surely to different platforms and goals.
-
Firstly, the TG68 is a hardware map for an FPGA emulation of the 68000... That's not what I want at all.
There are plenty of 68k emulator for the ARM, I used to use PocketUAE on my old PDA... I'm pretty sure there is an ST emu that has a JIT too...
My goal is threefold:
1) I want to get rid of the real 68k (the only chip we have no control over).
2) I want to have 020 compatibility.
3) I want to reduce the component count.
My point is that the current ARM used might only be a microcontroler, but updating that chip to a more powerful chip could allow it to do its current job and 680x0 emulation too, and with only a small cost increase (if you include the loss of the 68k)... There was no chance of doing that with the old PIC that was there before.
-
I ask again: How could a microcontroller act like another cpu?
In Minimig one will need a real (simulated) cpu to be used as in a real Amiga model too. Or just try it in any Amiga 500 to let an ARM chip act as MC68000. If this works fine, it could also work in Minimig.
But still this would be another way of thinking. It would be Emulation and not Simulation.
Therefor UAE (on any platforms) is available. In our case we want to simulate and act as real hardware. Emulation is a complete other thing.
If a bigger FPGA (say Spartan 3E with 1.5mio gates) is used, the whole ECS (even AGA) and a 68020 cpu could fit in. This is the right way to act :-)
-
What Boing4k said, exactly.
And sorry, but there's nothing in emulation getting close to "a more elegant solution". If you like it that way, just use some UAE and please leave MiniMig out of this. Quite simple.
-
@bloodline
Perhaps you would be better of with an OpenPandora (http://www.youtube.com/watch?v=KwuI6_zCjxY) and UAE4ALL (http://www.gp32x.com/board/index.php?showtopic=44100)
The Minimig is an A500 cycle exact (nearly) device.
-
I'm curious about one little detail on the accelerated Minimig.
What speed-grade is the 68k used in the video? It seems that the 16MHz part is the most easily available from Digikey, and that's what I got. I'd be surprised to see it going all the way up to 28MHz!
Also, what 68k grade do the amigakit Minimigs ship with?
-
68000's are HIGHLY overclockable, and they dont need heat sink's :)
The default 68000's in the Minimig's are 16Mhz clocked by the core to 7Mhz.
-
Right, Dennis also told me some time ago that this SEC000 are very "overclock friendly" and even the 16MHz 68k should also work fine at 28Mhz.
-
hehe my only question is when will the board available...
i can not wait :P
-
The Minimig in the video is equipped with 20 MHz 68SEC000 (the price difference between 16 and 20 MHz version was marginal). The speed gain of the CPU run @ 28 MHz over standard A600 is only 2.91 due to memory running at 7 MHz and being shared with custom chips. I have also made some tests with memory run @ 14 MHz (requires faster memory chips) and achieved speed gain of 5.05.
I have made some tests to find out what the maximum operational frequency of the 68SEC000 rated at 20MHz is and mine is able to run at 39 MHz. But without equally fast memory access the speed gain is very small (SysInfo reports 3.03 times the A600 speed).
I do not expect the 16 MHz rated parts to be much slower.
-
yaqube wrote:
The Minimig in the video is equipped with 20 MHz 68SEC000 (the price difference between 16 and 20 MHz version was marginal). The speed gain of the CPU run @ 28 MHz over standard A600 is only 2.91 due to memory running at 7 MHz and being shared with custom chips. I have also made some tests with memory run @ 14 MHz (requires faster memory chips) and achieved speed gain of 5.05.
I have made some tests to find out what the maximum operational frequency of the 68SEC000 rated at 20MHz is and mine is able to run at 39 MHz. But without equally fast memory access the speed gain is very small (SysInfo reports 3.03 times the A600 speed).
I do not expect the 16 MHz rated parts to be much slower.
So you don't foresee any problems with the 16MHz chip being run at 28 Mhz?
Are you planning a new core release for the unmodified v1.1 anytime soon (bug fixes, df1:, etc)?
-
Darrin wrote:
So you don't foresee any problems with the 16MHz chip being run at 28 Mhz?
That's my expectation. Actual tests will reveal if it runs or not.
Are you planning a new core release for the unmodified v1.1 anytime soon (bug fixes, df1:, etc)?
Yep, I have already rewritten some parts to make the Minimig more cycle exact (it's not 100% exact and will never be) and now some games and demos work in the same way as run on a real Amiga.
But there are still some others that do not run correctly and I would like to find out why and fix the problems if feasible.
After implementing upgrades from SD-Card for the ARM controller board I will port the firmware to the PIC (most of it has been already done). The FPGA core will be the same for the ARM and the PIC (only the former will allow to have 4 floppy drives and hard disk support).
-
yaqube wrote:
That's my expectation. Actual tests will reveal if it runs or not.
I'll let you know if my Minimig melts. :-D
Yep, I have already rewritten some parts to make the Minimig more cycle exact (it's not 100% exact and will never be) and now some games and demos work in the same way as run on a real Amiga.
But there are still some others that do not run correctly and I would like to find out why and fix the problems if feasible.
After implementing upgrades from SD-Card for the ARM controller board I will port the firmware to the PIC (most of it has been already done). The FPGA core will be the same for the ARM and the PIC (only the former will allow to have 4 floppy drives and hard disk support).
Excellent news. Cheers. :-)
-
Does it mean that on an unmodified 1.1, we will still get HDD support and multiple floppy drive emulation?
-
Everblue wrote:
Does it mean that on an unmodified 1.1, we will still get HDD support and multiple floppy drive emulation?
No and yes, just the updated bug-fixed core with df0: and df1: support, but it will be "expansion board ready" should they become available.
-
Ah cool. So the current minimig will be perfectly compatible (hardware-wise). This through a hardware upgrade and some soldering.
-
Yep, that's the plan. If I understand correctly, the new core will require a PIC update and provide the bug fixes, df1: support and probably the 28MHz CPU.
If you want the extra HD support and df2: and df3: then just replace the PIC with the ARM board.
If you want the extra RAM then you'll need to do (or have someone else do it) some soldering.
-
1. 28MHz CPU - with the current CPU on board?
2. To replace PIC with armboard (for HD Support), it wont involve soldering right?
3. I would like to be able to install run WHDLoad - will that need extra RAM to be installed for all (working games) to er, work?
-
Everblue wrote:
1. 28MHz CPU - with the current CPU on board?
Yep.
2. To replace PIC with armboard (for HD Support), it wont involve soldering right?
Basically no soldering. The ARM board is a plug-in replacement for the PIC. 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.
3. I would like to be able to install run WHDLoad - will that need extra RAM to be installed for all (working games) to er, work?
I can't answer this question because I haven't done any such tests. I expect that with the base memory of 1.5 MB chip RAM those games which require 1MB of any or chip memory should run. But this is not confirmed.
-
Thanks a lot!
-
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?
-
Probably that would be a problem to some games? Just a very wild guess.
-
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.
-
Darrin wrote:
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?
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.
-
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 (http://www.amiga.org/userinfo.php?uid=16713)
project page (http://web.comhem.se/illuwatar/project_pages/minimig/minimig.htm)
illuwatar, what are your thoughts on this ?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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
-
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
-
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.
-
@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 :-)
-
@Loriano
I will talk to you before the final board design will be completed. We should design it in an enclosure-friendly way.
-
@yaqube
>>I will talk to you before the final board design will be completed. We should design it in an enclosure-friendly way.
That sounds promising, I can't wait to start working on the next gen Minimig ;-)
-
What exactly is the limiting speed factor of the hardfile implementation? We just finished an internal version of the Minimig core for the C-One with harddrive support, working on a real harddrive (in my case, on a DeLock IDE flash module). Without optimization, our performance is 545k per second (see pictures on www.c64upgra.de/c-one ) - a good 20% faster than what's shown in the Youtube video.
There might be room for improvement as we speed up the CPU, but I don't expect much more, as the CPU is just a plain, 68000, sharing the bus with the chipset and another 68000 CPU.
Minimig on the C-One now has 11 megs of ram and a harddrive. An RTC might be an idea now :-)
Jens
-
Schoenfeld wrote:
What exactly is the limiting speed factor of the hardfile implementation? We just finished an internal version of the Minimig core for the C-One with harddrive support, working on a real harddrive (in my case, on a DeLock IDE flash module). Without optimization, our performance is 545k per second (see pictures on www.c64upgra.de/c-one ) - a good 20% faster than what's shown in the Youtube video.
There might be room for improvement as we speed up the CPU, but I don't expect much more, as the CPU is just a plain, 68000, sharing the bus with the chipset and another 68000 CPU.
Minimig on the C-One now has 11 megs of ram and a harddrive. An RTC might be an idea now :-)
Jens
Bloody hell! That's good news! I certainly don't mind using one of my spare 2.5" IDE hard drives on my C-One if it works! Only a couple more days until I get home and then I can finally mount that C-One in a case and start testing it. :-)
RTC would be nice, but I'll tell you want would really get me going... being able to access those clockports. If you could manage that then the C-One Minimig could have a Subway USB device attached.
RTG via a PCI graphics card would be the ultimate wet dream. :-)
Are you still beta-testing that core with hard drive support or has it been released?
Cheers,
Darrin
Edit: I just found your post on Yahoo quoted on Minimig.net and I'll be happy to wait for your CF support like you suggest, rather than risk my C-One board to any reflashing or soldering.