I'm going to buy one of the SAM7S512 boards mentioned in my blog post and port the code across (I need one of these anyway so this is a happy coincidence )

As JTAG should be accessible for live debugging purposes, I'm hoping this is of some help to those that want to develop alternative firmware for the board, specifically for the support of alternative cores.

Hey this looks very interesting!As long as it works without trouble (freez or data damage) it will be an alternative for the original ARM board

If you still want to use the original board, you may take a look at this www.a1k.org thread.I know, it german but english always is welcome as well.

Hi,

It seems to work 100%. I am busy creating a newly formatted card with hardfile etc. and I am going to give it a thorough testing.The only concern is that RST is not mapped to the dev. board. Using the dev. board's reset button seems to work, but I am not sure of the consequences.I can add the reset functionality by mapping a pin from JTAG port, just haven't got around to it.

I did have an issue with a corrupt hardfile when I was building this, but I believe that was due to a bad connection (this is why I am trying with a fresh card).

I will report back my findings.

I was trying to read the German thread on a1k you posted, but even with google translate I was a bit lost?They are offering bare PCB kits? At any rate I have the 'proper' ARM controller as well. This was a test to see if it could work and also to provide JTAG as an option for devs that need it.-(e)

Much testing later (if I never see HDToolbox again, it will be too soon ):

The dev. board seems fairly stable, however using HDF files > 4000MB seems to cause an issue when partitioning.Creating a partition of around 4000MB on a 4GB (real 4GB size, not HDD manufacturer rounded off size) caused the install31.adf file to become corrupt!There would seem to be some kind of overflow issue in the firmware? Or possibly some FAT32 issue when nearing the final border of FAT32 file size?

Further: cutting the HDF file down to 4000MB and then partitioning prevents this issue.However I cannot create partitions which will correctly format when then partition size is > ~1900MB in size.(I tried MANY different sizes from about 1990MB down to 1950MB, then 1900MB succeeded).

I need to do a side-by-side comparison with my other stock minimig to see if this is an issue.I am assuming some kind of problem with FFS / the 3.1 disk formatter as once a stable partition is created I have no issues.I tested the 1900MB partition with a full 3.1 install and all seems good.

Am I running into known issues here? Are there some disk test programs or other tests I could run?Any other suggestions from the experts?

AmigaOS has its limits.Those are: 4GB (4096MB) of HDD/HDF size and a maximum of 2GB (2048MB) partition size.Everythine larger will cause a number overflow. This is due to the 32Bit number system and filesystem "could" have negative size.

Only OS3.9 would help out but this will require a 68020 cpu and some more (fast)RAM.

______________________________________________JMP $00000BED ; will guru-meditation until next morning

The dev. board seems fairly stable, however using HDF files > 4000MB seems to cause an issue when partitioning.Creating a partition of around 4000MB on a 4GB (real 4GB size, not HDD manufacturer rounded off size) caused the install31.adf file to become corrupt!There would seem to be some kind of overflow issue in the firmware? Or possibly some FAT32 issue when nearing the final border of FAT32 file size?

...

Am I running into known issues here? Are there some disk test programs or other tests I could run?Any other suggestions from the experts?

Hi!

What software/hardware did you use for the formatting?

There's a bunch of limitations with HDF files > 4GB, starting with the SD card FAT32 filesystem, where a 4GB - 1 byte is the maximum file size. If you want bigger disks, you'd probably be better of with a SD card partition.

You must also be careful what software you use - make sure you are using HDTooolBox and use quick format. You can also upgrade your scsi.device driver for better compatibility with larger drives.

A partition must be only 2048MB in size. Any larger part. will cause a numberic overflow in the filesystem and data damage.

I think 4GB HDF should be enough for any Minimig since this already is very much for an Amiga500/600 alike system

I can't get closer to 2048 MB than 1990MB which is weird. I also don't understand how the adf corruption occurred.That a potential numeric overflow could affect an adf would seem to indicate some kind of missing gate condition in the firmware.With 'safe' values everything seems stable.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum