Hello again,

What`s the best set-up to enable good hard drive access for fpgaMinimig?

I have a 5GB seagate with ata33 cable and also ata133 cable if needed.
Thanks guys,

Roger

At 08:46 01.04.2009 +0000, you wrote:
>Hello again,
>
>What`s the best set-up to enable good hard drive access for fpgaMinimig?
>
>I have a 5GB seagate with ata33 cable and also ata133 cable if needed.
>Thanks guys,

Cables don't really make a difference, as the
Amiga uses fairly slow PIO modes (and so does the
C-One Minimig implementation). Use any IDE cable
that you have in your abandoned-cables-box, just
make sure it's not too long. ata33 seems right,
but ata133 won't hurt. It doesn't make it faster either :-)

Since you're trying to use a large harddrive, you
may want to either only format 4 gigs or less, or
use a 64-bit addressing mode. A loooong time ago,
I have written this article about TD64 and how to install it on an Amiga:

http://icomp.de/t/bin/howto/etd64.htm

Always keep in mind that the (unpatched) Amiga
has a DOS limit of 2GB per partition.


ciao,
--
Jens Schönfeld

Hi,

i have the same problem. I can start the "Newboot preview" but after
selecting the "Bigboot classic" option my system hangs with blank monitor.
I have tried several EDO and FPM simms but the result was always the
same. Only once the switch back to Bigboot Classic was successful but i
couldn't repeat this again.
My board was nacked without any extension or sdram an is was flashed
with bigboot 1.0 / boot-rom 1.3. All my installed cores (cpc, c64,
symbios, vc20) runs without any problems.

Anybody has a tip for further steps?

Greets
Frank Kosanke


Bo Zimmerman schrieb:
>
>
> Hello all,
>
> I've an unhappy situation.
>
> No NewBoot for me.
>
> I prepared a new 8GB cf card with the newboot 2.01 image on it. No
> devices were attached except for a silversurfer on the clock port,
> keyboard, monitor, mouse.
>
> The system booted, and I selected the newboot-preview core. The Newboot
> screen came up with no problems. So far so good right?
>
> So I tried the BigBoot Classic option from newboot in order to test it
> out. The screen went black, the monitor sensor led stayed green, showing
> it was receiving a signal, but the screen stayed black. So, as
> instructed, I tried other 60 and 70ns simms, ranging from 4mb - 16mb.
> Luckily I had a nice collection of these; different brands and such. The
> same behavior occurred with all of them. :(
>
> For what it's worth, I did something similar with the SDRAM Test option.
> Watching it bring up a screen of scrambled graphics made me believe
> something might be wrong with the SDRAM card, so I, again, swapped it
> for numerous variations to no avail, eventually settling back with my
> original one.
>
> Any advice is appreciated,
> Bo Zimmerman
>

Ahh nice! I mananged to fix the problems! The "problem" with the
Pacman-Cartridge was self-inflicted when comparing to the original I replaced
one character in the "CBM80" sequence to be able to both have PacMan in memory
and still boot with the prompt.. but this not my main problem either.

The Main memory of the C64 was, and is still in 0.27, created as:

type testMainRamDef is array(16383 downto 0) of unsigned(7 downto 0);

which makes the memory be instanciated backwards so to speak. This is not a
problem when starting with empty memory, but will become troublesome when/if
trying to start with some initialized memory. Either one has to init the memory
backwards or..

By switching it to:
type testMainRamDef is array(0 to 16383) of unsigned(7 downto 0);
everything works like a charm. Thanks Mikael (friend offlist) for pointing this
out to me! I had been staring a little bit too long on the lines to see it..

So now my SID-example is sound great! One smaller problem now is that everything
executes just a tad too fast so this is the next problem to fix. By looking at
the readme's for newer versions of FPGA-64 cores it seems like this has been
fixed, is that correct?

The infrastructure of FPGA-64 seem to have changed quite alot between 0.20 and
0.27 (especially concerning vicii) and the file 'fpga64_xess_xsa3s1000.vhd' that
I use as basis for porting FPGA-64 to my hardware-setup seem orphaned (not
updated). Is there any plans on updating that file or has anyone already done
it? I will try it myself but it is a little bit of a guessing game.. A bigger
question might be, will there be any more open source for FPGA-64 now that 0.28
became closed?

Thanks, Best Regards
Magnus

--- In cone_cores@yahoogroups.com, "Peter" <pwsoft@...> wrote:
>
> Hi,
>
> --- In cone_cores@yahoogroups.com, "Magnus Wedmark" <magnus.wedmark@> wrote:
> >
> > Hi all,
> >
> > I'm using a Digilent/Xilinx Spartan-3E 1600E MicroBlaze Starter Kit card
together with my own Extender card dubbed ArcadeExtender and trying to get
FPGA-64 rolling on it. Hope this doesn't rule me out from this community or
makes this post be off-topic.. otherwise tell me!
>
> VHDL/FPGA check
> FPGA-64 check
> C-One  no check
>
> So it is 2/3 on topic ;-) More on topic as most off-topic posts ehh never
mind..
>
> > It is working out quite well with FPGA-64, the 64 is booting BASIC and an
example PacMan-cart (In VHDL form) that I've got from Peter also work! Thanks
Peter! It uses a soft-SID that I've incorparated into the FPGA which I found on
the net. How do you guys normally handle SID, hard-SID?
>
> Your welcome!
> We (C-One owners) can put a real SID chip on the C-One board.
>
> > I'm mapping 64 KByte of BRAM into the C64 as usual, also having the
PacMan-cartridge where cartridges go: $8000. As it is mapped just now it doesn't
actually autostart, I just start it with "SYS 33696" from BASIC so that also
works!
>
> Then your mapping is not 100%. As the ROM should autostart. Could it be that
it is invisible for a while due to a bug in $0000/$0001 I/O mapping or the
memory emulation (the kernal will look for a "CBM80" identification in the 8000
area very early in the startup). Reading at $8000 till $9000 will read from ROM.
Writing will write to the ram below it. With the registers at $00/$01 you can
switch the ROM in and out of the memory space. Details are in the C64 reference
manual (or somewhere on the internets). I think somebody typed (or OCRed) the
C64 ref man as I have a .txt version. Try to google for it.
>
> > It also maps Kernal+Char+BASIC as a usual C64 but using BRAM.
> >
> > Now I want to be able to test more stuff (read programs/games/demos) easily
and my setup does not really make use of the SD-Card today... I've written a C#
program to convert a given *.PRG file to a VHDL file that can be used to
exchange the main RAM in the VHDL. Then this is used when rebuilding the FPGA-64
and should make it boot with the particular program loaded into memory but it
does not work as expected. As I understand, there maybe a problem with Bank
switching
>
> Ok in a PRG the first two bytes are the load offset (normally $01 and $08) you
need to strip those of the file and place the rest of the data at $0801 onwards.
When the kernal loads a file from disk in also updates a bunch of pointers and
such that tell the basic interpreter the begin and end of the program. If that
isn't done you won't see anything with LIST, but if it is a assembler program
you can still type the "SYS <addr>" yourself to let it run.
> That would be sys 2061 in your example.
>
> >that makes the memory NOT be placed correctly. I've tried a small
SID+Graphics-demo I found on the net located at $0801 of which I would like to
be at least be able to hear the output from.. The PRG-file works when dropped
into VICE but does not seem to be mapped correctly when using FPGA-64. What
happens in VICE when you drop a file on it? What happens in the real 64 when you
load a PRG-file? It seem to autostart in VICE.. How do I get the FPGA-64 to use
RAM at $0800 and forward? As I recall didn't the BASIC interpreter start using
mem at $0800 so maybe the program starts with a SYS.. IN the binary the program
seem have the char "2061" within itself..
> >
> > I've tried to Google it and find out what is missing/clicking but for now I
don't know where to look. I can supply the exact PRG.file if anyone want try it
out!
>
> Studying the ROM disassembly of the tape/disk load and save routines in the
kernal might help. Though it requires some 6502 assembly knowledge to follow.
>
> > I'm using FPGA-0.20 as this was the version that was available when I looked
at the project before.
>
> It is kinda old, but should be able to run most programs. Keep in mind that
some games require the read-only registers of the SID. They use the SID as
random number generator if these are missing it won't work. I did at one time
implement a emulation of these registers. It should be in 0.20 search for
sidrandom. If the soft-sid you use has them you don't need the emulation
ofcourse.
>
> >
> > Hope you guys have any idea to get my FPGA-64 get going with Bank switching
and the Soft-SID! That would be great!
>
> You can also send a mail to pwsoft at syntiac dot com (thats me) with specific
questions about fpga-64.
>
> >
> > Keep up the good work done here! I would love to give back anything if there
is anything I could do or share?
> >
> > Best Regards
> > Magnus
> >
>
> Hope it helps,
> Peter
>

Hi Magnus,

--- In cone_cores@yahoogroups.com, "Magnus Wedmark" <magnus.wedmark@...> wrote:
>
> Ahh nice! I mananged to fix the problems! The "problem" with the
Pacman-Cartridge was self-inflicted when comparing to the original I replaced
one character in the "CBM80" sequence to be able to both have PacMan in memory
and still boot with the prompt.. but this not my main problem either.

Ok.

>
> The Main memory of the C64 was, and is still in 0.27, created as:
>
> type testMainRamDef is array(16383 downto 0) of unsigned(7 downto 0);
>
> which makes the memory be instanciated backwards so to speak. This is not a
problem when starting with empty memory, but will become troublesome when/if
trying to start with some initialized memory. Either one has to init the memory
backwards or..

And it is only 1/4 of the necessary memory needed for a complete C64 emulation.
But that was the biggest block that I could fit into the 3s1000 fpga. You should
really switch to using external memory to get the full 64k.

>
> By switching it to:
> type testMainRamDef is array(0 to 16383) of unsigned(7 downto 0);
> everything works like a charm. Thanks Mikael (friend offlist) for pointing
this out to me! I had been staring a little bit too long on the lines to see
it..

I will make the same change in my archive to help future users.

>
> So now my SID-example is sound great! One smaller problem now is that
everything executes just a tad too fast so this is the next problem to fix. By
looking at the readme's for newer versions of FPGA-64 cores it seems like this
has been fixed, is that correct?

Yes, but that is a C-One specific fix. The C-One lacks any PLLs or DCMs to scale
the clock. I've created a little circuit that does fractional clock division.
The result however is a clock with a lot of jitter. Not a real problem for the
CPU, but it is for the video. So I've also added a new scandoubler (called
fpga64_scanconverter) that can 'un-jitter' the video signal. Some people
reported problems with this however. Some TFT screens don't like the resulting
video signal (it is not VGA compliant). It steals a few pixels from each
scanline to have some spare time at the end to compensate for the time creep
caused by the jittered clock.

You probably have a newer FPGA on your board so you should use PLLs/DCMs to fix
the speed properly and keep using the simple scandoubler.

>
> The infrastructure of FPGA-64 seem to have changed quite alot between 0.20 and
0.27 (especially concerning vicii) and the file 'fpga64_xess_xsa3s1000.vhd' that
I use as basis for porting FPGA-64 to my hardware-setup seem orphaned (not
updated). Is there any plans on updating that file or has anyone already done
it? I will try it myself but it is a little bit of a guessing game.. A bigger
question might be, will there be any more open source for FPGA-64 now that 0.28
became closed?

Most are cosmetic changes in the signal names. What did change is the way the
bus is switched between the VIC and CPU. The VIC has an extra signal that tells
when it needs the bus. This fixes a weird graphic artifact in some DMA-delay
effects.

I've made a gentleman agreement with Jens not to release any fixes I do on the
VIC-II emulation until the Chameleon cartridge is available on the market. This
forced me to make FPGA-64 closed sourced for the last bug-fix release. But the
whole project starts to get obsolete now we have decided to release a Chameleon
core for free for the C-One plus extender-board. I try to keep as much open as
possible. I did for example release the 800x600 test core under LGPL license.
And a sdram controller example for the extender-board is underway.

If you run into problems stitching the new code into your obsolete 0.20 tree let
me know. I probably can help explaining why and how pins have changed. But
comparing the cone_top between 0.20 and 0.27 should give all the answers in
principle.

Peter

>
> Thanks, Best Regards
> Magnus

Hi group,

I have made a small patch to the Minimig's PS/2 handler. When the OSD
menu is displayed, it's now possible to use the regular cursor up/down
keys to highlight a menu item, and use the Enter key to select it. The
regular method of Page Up/Down and Home still works of course.

I think it's much nicer to use the cursor keys, and besides I really
NEED to because I use the new tiny Apple aluminium keyboard [1] with
my C-One and it does not feature Page Up/Down etc keys. I would like
to use the Fn key instead, but so far I haven't had much luck. It
doesn't look like this key is included in the PC AT set.

Incidentally the Apple keyboard is almost exactly the same width as a
C-One board, so if you're thinking about making a custom wedge case
with a built-in keyboard, this might be what you're looking for...

A patch against v1.26 is attached. Jens & Tobi, you're of course free
to include this in your next release. I'm still very inexperienced in
VHDL, so please go easy on me if there's a better way to accomplish
this :)

Kind regards,
Carsten Sorensen

[1]
http://store.apple.com/dk/product/MB869Z/A?fnode=MTY1NDA1Mg&mco=NDIwOTQ2OQ&p=1&s\
=topSellers


[Non-text portions of this message have been removed]

On Sun, Apr 5, 2009 at 15:31, Carsten Sørensen <cso@...> wrote:
> to include this in your next release. I'm still very inexperienced in
> VHDL,

*cough* brain/fingers... you know what I mean :)

/Carsten

At 15:31 05.04.2009 +0200, Carsten Sorensen wrote:

>I have made a small patch to the Minimig's PS/2 handler. When the OSD
>menu is displayed, it's now possible to use the regular cursor up/down
>keys to highlight a menu item, and use the Enter key to select it. The
>regular method of Page Up/Down and Home still works of course.

Thanks for your effort! Unfortunately, Yahoo has
removed your attachment, but if you send it to me
or directly to Tobias, we'll include it in the next release.

>  I would like
>to use the Fn key instead, but so far I haven't had much luck. It
>doesn't look like this key is included in the PC AT set.

The Fn key is usually an internal key that
re-maps a few other keys, but it is not reported
to the outside world. There is no chance that the
C-One or any other computer can use the Fn key as
a regular button. This would require a change in
the keyboard's microcontroller, but you probably don't want to go that far :-)

ciao,
--
Jens Schönfeld

> The Fn key is usually an internal key that
> re-maps a few other keys, but it is not reported
> to the outside world. There is no chance that the
> C-One or any other computer can use the Fn key as
> a regular button. This would require a change in
> the keyboard's microcontroller, but you probably don't want to go that far

mmmh on my laptop atleast pressing fn+ some other key generates different
keycodes.

--

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ftp.pokefinder.org

Homes for the homeless, jobs for the jobless, neverthe for the nevertheless.

At 19:21 06.04.2009 +0200, Groepaz wrote:

>mmmh on my laptop atleast pressing fn+ some other key generates different
>keycodes.

That's what I was saying: Fn is kind of an internal shift-key, but
the key alone won't do you any good unless you press another key.

This is different qith the other qualifiers: Although you don't
notice in everyday life, there's a possibility to say when shift, alt
or ctrl are pressend and released. This is not the case for the Fn key.

ciao,
Jens

On Mon, Apr 6, 2009 at 19:48, Jens Schoenfeld <jens@...> wrote:
> At 19:21 06.04.2009 +0200, Groepaz wrote:
>
>>mmmh on my laptop atleast pressing fn+ some other key generates different
>>keycodes.
>
> That's what I was saying: Fn is kind of an internal shift-key, but
> the key alone won't do you any good unless you press another key.
>
> This is different qith the other qualifiers: Although you don't
> notice in everyday life, there's a possibility to say when shift, alt
> or ctrl are pressend and released. This is not the case for the Fn key.

Hmm ok, when I tested this particular keyboard on Linux (dumped the
raw codes), the Fn key did have it own distinct extended code though.
When used with a USB->PS/2 converter in AT set mode, it produces
nothing. Combinations that otherwise work in OSX also produce nothing.
*shrugs* I'm not too bothered since I can now use the keyboard with
Minimig anyway, although not the way I was originally hoping for.

I'll mail you the patch, it's pretty small. I'm thinking bigger for my
next learning project :)

Kind regards,
Carsten Sorensen

On Montag 06 April 2009, Jens Schoenfeld wrote:
> At 19:21 06.04.2009 +0200, Groepaz wrote:
> >mmmh on my laptop atleast pressing fn+ some other key generates different
> >keycodes.
>
> That's what I was saying: Fn is kind of an internal shift-key, but
> the key alone won't do you any good unless you press another key.
>
> This is different qith the other qualifiers: Although you don't
> notice in everyday life, there's a possibility to say when shift, alt
> or ctrl are pressend and released. This is not the case for the Fn key.

ah yes, thats true. fn alone doesnt even generate keydown/keyup

--

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ftp.pokefinder.org

"Virtual" means never knowing where your next byte is coming from.

> And it is only 1/4 of the necessary memory needed for a complete C64
emulation. But that was the biggest block that I could fit into the 3s1000 fpga.
You should really switch to using external memory to get the full 64k.

OK i just copied the row I had from 0.20 to get the correct reference for you.
On my card I actually used (65535 downto 0) by because of I missed the
connection of the MSB it only mapped 32767 of those.. after fixing that the BRAM
wasn't big enough both for RAM+BASIC+KERNAL+CHAR+PACMAN but that was correct..

> I've made a gentleman agreement with Jens not to release any fixes I do on the
VIC-II emulation until the Chameleon cartridge is available on the market.

OK no problem! I understand and are grateful for ALL code that actually are open
already!

I though I would give feedback to partly good result! I managed to squeeze in
47104 bytes of RAM together with BASIC+Kernal+Char ROM's into my Spartan-3E
1600E based card which makes a more complete C64 although some memory is
missing. 100% of BRAM used but about 17% of the logic.

After testing some games the small game H.E.R.O. booted and worked great. I've
been trying out the C64DTV-fixed games as these come in easily translated
PRG-files which suits my C64 that is missing secondary storage right now.

The clock problem could be me connecting the clock in/out incorrectly on the DCM
I've used (thanks Mikael) so I'm just rebuilding to try and fix that problem.
The strange thing is that it still gives me VGA-picture?? but after looking at
the Hz-info on the monitor it gives me 49.5Khz-80Hz so maybe that explains the
whole clock problem! :-)

I got my C-One extender the other day, hooked it up, no issues, and booted
up a WB 3.1 based NTSC Amiga system with no issues.  I installed a 4GB hard
drive, partitioned it into 1GB partitions and formatted each of them with no
problems.  I installed WB 3.1, booted fine, and all looks well ... but...

I came into something odd.  I was trying to unextract things from CLI using
LHA, and everytime I do, it would get a few files unextracted and then
lock.  Of course, when I reboot the Amiga validates the HD to see if
anything was wrong.

So I tried something different.. I just *copied* files from dir to dir from
CLI and lock.

Wondering if it was just the HD or something else, I tried using WB itself
(via icon) to move files around.  No problems at all.  I tried a large
amount of files and it worked great.  However, instead of moving them, I
tried copying them and it locked up.

I'm about to try another HD, but I was curious if anyone else had issues.


[Non-text portions of this message have been removed]

Hi all!

After trying more then 30 EDO/FPM ram modules i have found one which
worked mostly when i switched back from newboot to big boot classic.

In the following i have flashed newboot but this is going wrong. Now my
c-one does nothing.
Anybody knows a way how i can recover my c-one an bring it back to life?

Thanks and Greets
Frank

Hi,
which Version/files do you use for flashing?
What show the screen during the flashing?
What is now inside the Flash?
Is a extender board inside the c-One?

Please try this:
Delete all files (not folders!) except expander.rbf(Bypasscore) from the root.
Copy all files from a c1dcores/VC20 direktcore(NewbootV201.zip) into the root.
The V20 core need only the RAM/Cpu Card to start - no EDO no SDRAM.
Can you see the VC20 screen after this?

TobiFlex

>
> Hi all!
>
> After trying more then 30 EDO/FPM ram modules i have found one which
> worked mostly when i switched back from newboot to big boot classic.
>
> In the following i have flashed newboot but this is going wrong. Now my
> c-one does nothing.
> Anybody knows a way how i can recover my c-one an bring it back to life?
>
> Thanks and Greets
> Frank
>

At 11:32 22.04.2009 -0500, Brian Green wrote:

>I'm about to try another HD, but I was curious if anyone else had issues.

This sounds like the usual MaxTransfer problem -
lower the MaxTransfer value to 0xfffc or even
0x7ffc in order to deal with small buffer sizes of the harddrives you're using.

ciao,
--
Jens Schönfeld

I've tried switching out HDs, and setting the MaxTransfer on all partitions
to the below specs (as well as all sorts of other ones that I've found on
the net) and to no avail.  It still locks up.  I switched out the 4GB with a
"newer" 30GB and made a few 1GB partitions.   Unfortunately, it does the
same thing.  Other thoughts?  It's weird that it will boot WB just fine but
have issues unextracting (or writing?) files.

On Thu, Apr 23, 2009 at 3:47 AM, Jens Schoenfeld <jens@...> wrote:

>
>
> At 11:32 22.04.2009 -0500, Brian Green wrote:
>
> >I'm about to try another HD, but I was curious if anyone else had issues.
>
> This sounds like the usual MaxTransfer problem -
> lower the MaxTransfer value to 0xfffc or even
> 0x7ffc in order to deal with small buffer sizes of the harddrives you're
> using.
>
> ciao,
> --
> Jens Schönfeld
>
>
>


[Non-text portions of this message have been removed]

At 20:38 23.04.2009 -0500, Brian Green wrote:

>I've tried switching out HDs, and setting the MaxTransfer on all partitions
>to the below specs (as well as all sorts of other ones that I've found on
>the net) and to no avail.  It still locks up.  I switched out the 4GB with a
>"newer" 30GB and made a few 1GB partitions.

Please make sure to have a 64-bit filesystem and
patch the scsi.device of the Amiga to be 64 bit.
The OS only comes with a 32-bit version, which
has a limit of 4G per drive, and the OS has a
limit of 2G per partition. Read more about 64-bit
addressing of mass-storage on the Amiga in the TD64 tutorial of my website:

http://icomp.de/t/bin/howto/etd64.htm

Also, keep cables short (if you have, use DMA133
cables), make sure that your power supply can
support all the parts that you have connected.
Grounding is always a good idea - metal cases
should have direct connection to the ground
protection wire (normally through the power
supply), and keep in mind that screws in the
casing are not only for mounting, but also for
proper ground connection of all parts, which is
cruicial for any computer's stability.

You may experience problems with the copy-command
- if that's a version from a different OS
version, it appears to work, but trashes target
data. This applies to versions of the copy
command V38.x. I recommend to replace the copy
command with version 40.x or higher.

ciao,
--
Jens Schönfeld

Though I've used lots of large drives in Amigas (as long as I didn't go past
the first few gigs on the drive), I gave this a shot.  No go.  Here's what I
tried today ....
Replaced all the RAM on the board
Installed TD64 and reformatted 2 drives (a 4GB, and a 30GB).  The 4GB will
allow me to install WB 3.1, but any files I try to lha crashes if its more
than 5 or 6 files in the archive.  The 30GB dies while installing 3.1.
Both drives work fine on my A4000T and A3000 w/Xsurf
I replaced the cable - twice.  UltraATA cables, standard cables, doesn't
matter.
I tried both the PAL and NTSC cores, nothing changed.
The power supply is a 400W and is only running this drive and the C-One.

At the end of the day, is still doesn't work.


On Fri, Apr 24, 2009 at 1:56 AM, Jens Schoenfeld <jens@...> wrote:

>
>
> At 20:38 23.04.2009 -0500, Brian Green wrote:
>
> >I've tried switching out HDs, and setting the MaxTransfer on all
> partitions
> >to the below specs (as well as all sorts of other ones that I've found on
> >the net) and to no avail. It still locks up. I switched out the 4GB with a
> >"newer" 30GB and made a few 1GB partitions.
>
> Please make sure to have a 64-bit filesystem and
> patch the scsi.device of the Amiga to be 64 bit.
> The OS only comes with a 32-bit version, which
> has a limit of 4G per drive, and the OS has a
> limit of 2G per partition. Read more about 64-bit
> addressing of mass-storage on the Amiga in the TD64 tutorial of my website:
>
> http://icomp.de/t/bin/howto/etd64.htm
>
> Also, keep cables short (if you have, use DMA133
> cables), make sure that your power supply can
> support all the parts that you have connected.
> Grounding is always a good idea - metal cases
> should have direct connection to the ground
> protection wire (normally through the power
> supply), and keep in mind that screws in the
> casing are not only for mounting, but also for
> proper ground connection of all parts, which is
> cruicial for any computer's stability.
>
> You may experience problems with the copy-command
> - if that's a version from a different OS
> version, it appears to work, but trashes target
> data. This applies to versions of the copy
> command V38.x. I recommend to replace the copy
> command with version 40.x or higher.
>
> ciao,
> --
> Jens Schönfeld
>
>
>


[Non-text portions of this message have been removed]

Just a quick observation - the issue seems to happen when the file is 14K or
larger.  If it's smaller, I can copy files all day long.  If it's 14K or
larger, it locks.

On Fri, Apr 24, 2009 at 8:51 PM, Brian Green <ice@...> wrote:

> Though I've used lots of large drives in Amigas (as long as I didn't go
> past the first few gigs on the drive), I gave this a shot.  No go.  Here's
> what I tried today ....
> Replaced all the RAM on the board
> Installed TD64 and reformatted 2 drives (a 4GB, and a 30GB).  The 4GB will
> allow me to install WB 3.1, but any files I try to lha crashes if its more
> than 5 or 6 files in the archive.  The 30GB dies while installing 3.1.
> Both drives work fine on my A4000T and A3000 w/Xsurf
> I replaced the cable - twice.  UltraATA cables, standard cables, doesn't
> matter.
> I tried both the PAL and NTSC cores, nothing changed.
> The power supply is a 400W and is only running this drive and the C-One.
>
> At the end of the day, is still doesn't work.
>
>
> On Fri, Apr 24, 2009 at 1:56 AM, Jens Schoenfeld <jens@...> wrote:
>
>>
>>
>> At 20:38 23.04.2009 -0500, Brian Green wrote:
>>
>> >I've tried switching out HDs, and setting the MaxTransfer on all
>> partitions
>> >to the below specs (as well as all sorts of other ones that I've found on
>> >the net) and to no avail. It still locks up. I switched out the 4GB with
>> a
>> >"newer" 30GB and made a few 1GB partitions.
>>
>> Please make sure to have a 64-bit filesystem and
>> patch the scsi.device of the Amiga to be 64 bit.
>> The OS only comes with a 32-bit version, which
>> has a limit of 4G per drive, and the OS has a
>> limit of 2G per partition. Read more about 64-bit
>> addressing of mass-storage on the Amiga in the TD64 tutorial of my
>> website:
>>
>> http://icomp.de/t/bin/howto/etd64.htm
>>
>> Also, keep cables short (if you have, use DMA133
>> cables), make sure that your power supply can
>> support all the parts that you have connected.
>> Grounding is always a good idea - metal cases
>> should have direct connection to the ground
>> protection wire (normally through the power
>> supply), and keep in mind that screws in the
>> casing are not only for mounting, but also for
>> proper ground connection of all parts, which is
>> cruicial for any computer's stability.
>>
>> You may experience problems with the copy-command
>> - if that's a version from a different OS
>> version, it appears to work, but trashes target
>> data. This applies to versions of the copy
>> command V38.x. I recommend to replace the copy
>> command with version 40.x or higher.
>>
>> ciao,
>> --
>> Jens Schönfeld
>>
>>
>>
>
>


[Non-text portions of this message have been removed]

At 21:10 24.04.2009 -0500, Brian Green wrote:

>Just a quick observation - the issue seems to happen when the file is 14K or
>larger.  If it's smaller, I can copy files all day long.  If it's 14K or
>larger, it locks.

How about a MaxTransfer value of 12K then? Try 0x2ffc for
MaxTransfer. It seems weird, but it may help.

Another idea might be a memory test. I have the original Commodore
2058 test-disk flying around, will collect it and upload to the page,
so you can make sure that the memory on your C-One is OK. This would
test the memory chip on the FPGA extender.

ciao,
Jens

The MaxTransfer set to 12K appears to have no effect.
Please let me know if/when you put the A2058 disk online.  I grabbed one
from the Amiga Hardware Database, made a disk (since it was in .DMS format)
on my A1200, then turned that disk into an ADF for the C-One.  When I try to
'insert' it on the C-One, it tells me 'More Than 8 Fragments' and ignores it
(whatever that means).

On Sat, Apr 25, 2009 at 2:21 AM, Jens Schoenfeld <jens@...> wrote:

>
>
> At 21:10 24.04.2009 -0500, Brian Green wrote:
>
> >Just a quick observation - the issue seems to happen when the file is 14K
> or
> >larger. If it's smaller, I can copy files all day long. If it's 14K or
> >larger, it locks.
>
> How about a MaxTransfer value of 12K then? Try 0x2ffc for
> MaxTransfer. It seems weird, but it may help.
>
> Another idea might be a memory test. I have the original Commodore
> 2058 test-disk flying around, will collect it and upload to the page,
> so you can make sure that the memory on your C-One is OK. This would
> test the memory chip on the FPGA extender.
>
> ciao,
> Jens
>
>
>


[Non-text portions of this message have been removed]

There are two relevant versions out:
1.29 - no hardware patch needed with a software emu for the irq signal from the
ide device. It works only with a LBA with 28 Bits (max. 120GB harddisk). But if
I read about the HD Problems I think the emu is buggy.

1.28 - hardware patch needed. irq is hardwired but an old SDRAM controller is
included.
If anybody need i can create a new version with the new SDRAM controller from
the version 1.29. If the hardware patch done the new version can use the TD64.

Best
TobiFlex



>
> At 20:38 23.04.2009 -0500, Brian Green wrote:
>
> >I've tried switching out HDs, and setting the MaxTransfer on all partitions
> >to the below specs (as well as all sorts of other ones that I've found on
> >the net) and to no avail.  It still locks up.  I switched out the 4GB with a
> >"newer" 30GB and made a few 1GB partitions.
>
> Please make sure to have a 64-bit filesystem and
> patch the scsi.device of the Amiga to be 64 bit.
> The OS only comes with a 32-bit version, which
> has a limit of 4G per drive, and the OS has a
> limit of 2G per partition. Read more about 64-bit
> addressing of mass-storage on the Amiga in the TD64 tutorial of my website:
>
> http://icomp.de/t/bin/howto/etd64.htm
>
> Also, keep cables short (if you have, use DMA133
> cables), make sure that your power supply can
> support all the parts that you have connected.
> Grounding is always a good idea - metal cases
> should have direct connection to the ground
> protection wire (normally through the power
> supply), and keep in mind that screws in the
> casing are not only for mounting, but also for
> proper ground connection of all parts, which is
> cruicial for any computer's stability.
>
> You may experience problems with the copy-command
> - if that's a version from a different OS
> version, it appears to work, but trashes target
> data. This applies to versions of the copy
> command V38.x. I recommend to replace the copy
> command with version 40.x or higher.
>
> ciao,
> --
> Jens Schönfeld
>

its pretty wuiet in here since a month. for normally this means jens is busy as
hell ;) .
i'm just impatient, so i need to ask:

iirc, the original minimig core has been updated last week, is there a chance
for us to get in touch with those?

any news from the chameleon?

pleeeaaase give us a sign of life
nils

At 07:19 14.05.2009 +0000, Nils wrote:

>its pretty wuiet in here since a month. for normally this means jens
>is busy as hell ;) .

I'm always busy, right :-)

>iirc, the original minimig core has been updated last week, is there
>a chance for us to get in touch with those?

Last time I talked to Tobias, he was on a new version of the CPC
core, so Minimig might not be his highest priority at the moment.

>any news from the chameleon?

Working on it :-) Seriously, Peter and I will publish some news
within the next four weeks. I'm finalizing the schematics of the
pre-production version, this will probably take until the end of next
week. When the pre-production board has given the first sign of life,
we'll reveal the reasons why we have kept you waiting for so long.

ciao,
Jens

>
> iirc, the original minimig core has been updated last week, is there a chance
for us to get in touch with those?
>

It was a long way from the Minimig core to the C-One core.
I is not possible to replace the old minimig source file with the new ones.
Thats why I must go the long way from the new Minimig core source to the C-One
core again. But i don't know if i really will go this way again.

Best,
TobiFlex

Hello,

I have noticed that c-one.net is not available ->
http://downforeveryoneorjustme.com/c-one.net which is bad...
I know there is more documentation (as on the website of fpga64),
but still... wouldn't it be a good idea to put the wiki on a (google)
team site or group?

and also, is it possible to use a Terasic USB Blaster on the FPGA
Extender? I think I have seen a photo
(http://www.c64upgra.de/c-one/pics/c1extender_final3.jpg)
with one connected... at the moment I do not own one, since the USB
Blaster I have is integrated into the DE1 board. Is there a good
distributor which can sell it easily (Terasic charges a lot of money
for shipping to the Netherlands and Digikey charges the VAT at
delivery [for about 50 euro's the shipping is also not cheap]).

thanks,


Gerard

Oops.  I had to buy a new router (again) and forgot to set up the port
forwarding.  I'll get that as soon as I get home this evening.

I have been hosting the wiki at home until I had a chance to upgrade to TikiWiki
2.x.  I've got mods to 1.9 that need to be ported and I just haven't had time. 
Once I get it updated to 2.x then I'll move it to my hosting service.

--- In cone_cores@yahoogroups.com, "Gerard Braad" <gbraad@...> wrote:
>
> Hello,
>
> I have noticed that c-one.net is not available ->
> http://downforeveryoneorjustme.com/c-one.net which is bad...
> I know there is more documentation (as on the website of fpga64),
> but still... wouldn't it be a good idea to put the wiki on a (google)
> team site or group?
>
> and also, is it possible to use a Terasic USB Blaster on the FPGA
> Extender? I think I have seen a photo
> (http://www.c64upgra.de/c-one/pics/c1extender_final3.jpg)
> with one connected... at the moment I do not own one, since the USB
> Blaster I have is integrated into the DE1 board. Is there a good
> distributor which can sell it easily (Terasic charges a lot of money
> for shipping to the Netherlands and Digikey charges the VAT at
> delivery [for about 50 euro's the shipping is also not cheap]).
>
> thanks,
>
>
> Gerard
>

At 17:49 29.05.2009 +0000, Gerard wrote:

>and also, is it possible to use a Terasic USB Blaster on the FPGA
>Extender? I think I have seen a photo
>(http://www.c64upgra.de/c-one/pics/c1extender_final3.jpg)
>with one connected...

The extenders are shipped without the JTAG installed, but you can
solder that to the board pretty easily.

If you have a computer with a parallel port, I can sell you a
ByteBlaster MV (multi-volt version) pretty cheaply, and I can even
give you a low shipping rate for the Netherlands. Contact me off-list
for the ByteBlaster - and anyone else who wants one as well. I got
tons of them in stock, and I'm happy to support everyone who wants to
get into developing for the C-One.

ciao,
Jens