Creating a new 020 accel board for A600 (eventually to A500 too)

[Zetr0]

@Reef

indeed there very lust-worthy cards irrespective of thier *issues* with heat ;)

Taking the legal things aside, copying the Apollo is more than just the hardware and the board, this would be simple, but some of the chips contain programs, this software cannot be read directly out of the chips as they have *safe guards* these can be written and run from but not read as.

so since the programming (firmware) code has to be written the team here have looked at the existing projects on the net, from established resources, add a good helping of skill the development of new hardware begins :)

[rkauer]

Competitions tasks:

-me: giving the block diagrams/sketches to Dimmy (special signals and sidenotes will accompanying);

- Dimmy: decipher my handwriting, hard work on the schematics, board routing; :cheese

- Stedy: we need to MSN to swap some more ideas, m8; ;)

- Zetr0: drool all over the place and more hints/useful documents.

Interface Dimmy/Stedy, since those two guys are the GODS in their areas. :)

*upgrade: parts decided, partial BOM, interfacing signals almost complete.

To do: decide what pins of the PLD will connect to where: chat with Stedy + Dimmy + Big Z. What about Wednesday, 20h00 GMT?

I hear someone saying "More two weeks"? ;) :lol :cheese

[Zetr0]

8pm GMT for chin waggery on MSN, I am there, i shall bring the beer :)

[rkauer]

Did someone mentioned beer?http://www.amigabr.org/uploads/smil47d450b36c0d4.gif :cheese

[Dimlow]

Ill send you a beer now if you send me the schematics now ! Fair Trade ?

How was the holiday ?

[Akira]

Did someone mentioned beer?http://www.amigabr.org/uploads/smil47d450b36c0d4.gif :cheese
Be ready for disappointment:
Gringos não saben beber cerveja bem gelada xD

[Stedy]

Hi,

I may not make the 8 o'clock start as I have been working late this week, I normally arrive home by 8PM.

9PM on wednesday may be better for me.

[rkauer]

9PM, then.

@Dimmy, since I updated my PC this week, I'm still out the scanner drivers, will correct this tomorrow and send you the sketches first. Just need to know what time I can live chat you. ;)

[Dimlow]

8 is good for me 9 is also ok

[Dimlow]

Been doing some work on this.
http://eab.abime.net/picture.php?albumid=135&pictureid=724
We need to play connect the dots

CPLA made from Stedys Post of this ..
FC0, FC1, FC2,
A1-A6, A16-A23,
D12-D15
7 MHz clock
BGACK
BG_68020
AS_68020
DS_68020
RnW
AS_68000
BG_68000
Eclk_out
nVPA
nVMA
UDS, LDS,
DSACK0, DSACK1
SIZ0, SIZ1
nRESET
nRAS0-3
nCAS0-3
nMA0-1
PD1-4

[rkauer]

http://eab.abime.net/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABwAAAAOCAYAAAA8E3wEAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH1QUUDyoqJjAqRwAAAN1JREFUOMu1lMkVwyAMBYe0JGpCNUFNVk3k4AUwxPGS+ILxkzX8jyTH/Sfu9nrmJ3cXlnMASyWRPwd2d5XlHCBZn1BthcbRAdxTZQDI8k3mQzg11rhF+QZ9jdNOcQib6GFQYJYgCFucSRf6GsLU6wEY5yubTFqF2yq1vRwr3INXdQUWG+je1pELX4ED1wDyRAR0WfuAA9gloITyvsFMIMgYInYRqF6rO9Sqz9qkO5ilyo0o3YBwJ+6vrdQonxWUQllhXeHcb/wabMPkP2n81ocAIoLZrMqn/4y2RwP8DcQ+d6rT9ATiAAAAAElFTkSuQmCC


Been doing some work on this.
http://eab.abime.net/picture.php?albumid=135&pictureid=724
We need to play connect the dots

CPLA made from Stedys Post of this ..
FC0, FC1, FC2,
A1-A6, A16-A23,
D12-D15
7 MHz clock
BGACK
BG_68020
AS_68020
DS_68020
RnW
AS_68000
BG_68000
Eclk_out
nVPA
nVMA
UDS, LDS,
DSACK0, DSACK1
SIZ0, SIZ1
nRESET
nRAS0-3
nCAS0-3
nMA0-1
PD1-4

BG_020 not connected (it is needed if we add a PPC onto the design...) :cheese

BgAck_020 : given directly from BG_000, no need interfacing

DSack0/1 : "0" is controlled by the PLD, introducing a wait state @ every 4th cycle to match mobo timings, otherwise it is always @ high level. "1" is also controlled by the PLD to exercise different functions;

nReset: you mean PLD reset? Not connected, just grounded to avoid de-programming;

A0~A15 on 000 are connected to same addresses on 020 (!), think "coprocessor"...

D0~D15 from 000 are connected to D16~D32 on 020 side;

Other pins I need to take from my notes before reply.

[amiga600user]

any more info on this?

/popcorn

[Dimlow]

There is still work going on in the background, but i guess it will be slow as we all have our real lives to live!

Yesterday Some schematics went to stedy.

[Argus]

Are you guys planning on including the cpu on the board or just a socket and let the end-user add the chip themselves? A lot of people probably have 68020s lying around or easily come by from old macs & such. 72-pin simms are probably also the best bet as they are cheap.

You might want to also consider contacting/working with Mika Leinonen (sp?), user mrmkl over at amiga.org as he has a working design for adding ide to the a500/a1000 and is working on adding 8mb. Maybe taking some cues from his work you could create a simple 8mb 68020 accelerator with ide for the A500. That would seem to be a better market as Individual Computers already has an A600 accelerator design near completion.

Also, any thoughts on using/updating the Lucas 020 board project. I think the schematics for that are public domain.

[Predseda]

That would seem to be a better market as Individual Computers already has an A600 accelerator design near completion.


I though Jens already gave up that project due the unbreakable design problems?

[gklinger]

I've been away for more than two weeks and this thing still isn't ready? ;)

[cosmicfrog]

and ist rkauer band for a month, sorry

[gklinger]

and ist rkauer band for a month, sorry :shocked

[Stedy]

Hi,

@Argus

The CPU will be a TQFP 68020 soldered to the board. It is cheap :)
SIMM socket(s) are in the design, I need to work on the VHDL for the RAM controller soon.

Another feature or two may be added, see how I get on with the basic design.

I have been working on the schematics this weekend and made some good progress. Don't expect a final product soon, it'll take Dimlow a while to build a prototype ;)

Bye,

Ian

[ruttolomeo]

Really interesting :D
I'll buy one for my A500,sure.

Good work!

R.

[rkauer]

and ist rkauer band for a month, sorry

Funny how a month can run this kick. ;)

[AmigaFriend]

Funny how a month can run this kick. ;)


Too much beer rkauer?

Um chopinho bem geladinho é o que há de melhor pro corpinho! :cheese

[gklinger]

Nice to see you again, rkauer. I was worried there for a bit.

So, what is the status of this project? No pressurizing, just curious. :)

[Dimlow]

the Status is: In progress. its not dead yet

[Shadowfire]

I don't know whether or not this will help, but I have an IDE controller project that I've abandoned (for the time being at least, as I am out of a job) for the CDTV. Utilizing the PIC32MX360F256 microcontroller, the hardware is done but the first prototype hasn't been built yet (I have proto'ed the IDE controller portion on the Microchip PIC32 prototype boards and confirmed that it does inquire about drive parameters and successfully reads & writes blocks with PIO on an old 500mb laptop hard disk I have lying around), the firmware is about 30% done (basically only the IDE handshake code & inquire/read/write commands have been written and debugged).

I have done the first layout for a 4-layer board (it includes headers to attach external joystick ports and the device can switch between CDTV IR & external ports). I ended up using a Xilinx XC9572 CPLD for 68000 <-> SRAM glue logic & a 16K SRAM chip for buffer storage & interrupt handling. The schematic, layout & routing was done in PADS2007.1, the CPLD program was done in ISE 10.1, and the PIC32 software was done in MPLAB with the PIC32 C compiler. I'll upload the files to the zone, you may be able to rip out the PIC32 and use it for the IDE interface on your board, since the hardware/software for device access is already complete.

Warning: DO NOT attempt to have this board made unless you are prepared to work out the remaining kinks in it & write the software.

[Shadowfire]

Well, it seems I no longer have access to the Zone. If someone wants to host the file (it is 55 megs rar'd) please give a URL where I can upload it.

[Zetr0]

@Shadowfire

thats some great work there, let me fangle some details for you to upload to my server for use with this project, I can say that a lot of A500 / 68k DIP owners will certainly be thanking you!

[Graham Humphrey]

Well, it seems I no longer have access to the Zone. If someone wants to host the file (it is 55 megs rar'd) please give a URL where I can upload it.

http://eab.abime.net/faq.php?faq=vb_faq#faq_thezone_faq_item

I think that file will be too big anyway though.

[Shadowfire]

Email information in my profile wasn't correct. Updated. The Zone has a 6mb limit on files.
Edit: I cut out a lot of information (datasheets, PADS directories, etc) and basically left the schematic and firmware there. The CPLD schematic is in a separate file in the zone.

[Zetr0]

Awesome!!!

now building a wikie.... wow thats a lot of wikkies in a week i have made...

[Shadowfire]

NO offense, Stedy, but you said that a 68020 was cheap. Define "cheap." Digikey & Newark both have these chips but they start at $40USD (68020 33mhz, 132-pin PQFP package) and they only go up from there. Do you have an alternate source of these chips?

Mouser has the http://www.mouser.com/Search/ProductDetail.aspx?qs=sGAEpiMZZMvu0Nwh4cA1wbHBpJl%2fV4fQr4vrCvZPngE%3d 68EC020 25mhz but that has no MMU/FPU support, IIRC, and that is $26.50 a pop.

[rkauer]

Our dear friend Zetr0 have an almost endless source of PQFP EC020s dirty cheap.

For the PGA version, the user must provide the CPU.

[Zetr0]

The PQFP EC020 I am fortunate enough to get quite cheap indeed, (gotta love them chinese resellers), the only drawback is these chips are reclaimed, but it takes only 80 seconds to reclaim and clean them.... but at $2 a piece its worth the hassle!

Compared this to $26+ thats a HUGE saving from digikeys, Also Amiga-Digital has offered his help in obtaining these chips as he has a large cache of them, still to negotiate a final price but I am sure it wont be anything like Digi-keys rip-off prices.

I would love to source soime full core 030@25 QFP's but there bloody expensive! I have a handfull for testing, may be able to get a prototype or two out of them.

[rkauer]

That's why I love to make a PGA version of the design: PGA 030 are common as mud and easier to obtain than PLCC/PQFP units. :)

[Amiga-Digital]

The PQFP EC020 I am fortunate enough to get quite cheap indeed, (gotta love them chinese resellers), the only drawback is these chips are reclaimed, but it takes only 80 seconds to reclaim and clean them.... but at $2 a piece its worth the hassle!

Compared this to $26+ thats a HUGE saving from digikeys, Also Amiga-Digital has offered his help in obtaining these chips as he has a large cache of them, still to negotiate a final price but I am sure it wont be anything like Digi-keys rip-off prices.

I would love to source soime full core 030@25 QFP's but there bloody expensive! I have a handfull for testing, may be able to get a prototype or two out of them.

hi sure i have still 600 pcs of the a1200 020/16mhz cpu's and the price are about 3 us-dollar for 1 020/16mhz cpu and the cpu's are all new

maybe hi can make a daul 020 running on 25/30/32mhz

[rkauer]

A-D friend: 25MHz, surely no. 20MHz, yes.

PQFP don't accept too much of overclock. PGA ones do because the "built-in" metal heatsink.

[Dimlow]

All i say is make your bloody minds up and stick with it please!

Also, i need more info, i cant route a board without it.

[DoogUK]

A-D friend: 25MHz, surely no. 20MHz, yes.

PQFP don't accept too much of overclock. PGA ones do because the "built-in" metal heatsink.


I have a an 030 PQFP @ 28mhz running stable at 42mhz

[Stedy]

Hi,

@Dimlow,
Patience, I'm working on the schematics.

I personally prefer the PQFP package, it takes less PCB space and should be easier to break out the signals than a PGA package.

There is not a great deal of physical room inside the A600, so anything we can do to save space will help.

@thread

@thread

I have been reading the 68020 User manual, anything running above 25 MHz will require a heatsink. Allowing for a 40C ambient in the case, a 33 MHz PQFP 68020 will have a junction temperature of 104C, the limit is 110C. Too close for comfort. For the PGA device, the junction temperature will be 85C. I need to factor in how the approx 30C rise in PCB temperature will affect the part.

In terms of clock rate, running the part at either 14 MHz, 21 or 28 MHz will be best as it reduces the number of wait states when accessing the 7 MHz 68000 bus of the A600.

I am looking at this design from the viewpoint of a design that could be manufactured in batches of 50/100 units by a commercial assembler. Surface mount wins here.

Should the part be a 68020 or 68EC020?
Depends on availability.
From a schematic point of view, I do not care at this time.

Looks like we can get the 68EC020 cheap from China or from Amiga Digital. Personally I would prefer to use New Old Stock (NOS) rather then reclaimed items for long term reliability.

The 68EC020 limits us to 8 MB of RAM, 4 MB if PCMCIA is used. This will be Fast RAM so will speed up the system by some margin. Smaller capacity SIMMS use less power, another good bonus.

Finally, at the end of April 2009, I will have to stop work on this project. Another project of mine is ramping up and as it is more important, it will get all little available free time.

Providing we can agree what parts to use and get a PCB underway, which is achievable, this project can progress.
@Amigadigital

Can you quote the full part number for the 68EC020s you have please?

[Amiga-Digital]

Hi,

@Dimlow,
Patience, I'm working on the schematics.

I personally prefer the PQFP package, it takes less PCB space and should be easier to break out the signals than a PGA package.

There is not a great deal of physical room inside the A600, so anything we can do to save space will help.

@thread

@thread

I have been reading the 68020 User manual, anything running above 25 MHz will require a heatsink. Allowing for a 40C ambient in the case, a 33 MHz PQFP 68020 will have a junction temperature of 104C, the limit is 110C. Too close for comfort. For the PGA device, the junction temperature will be 85C. I need to factor in how the approx 30C rise in PCB temperature will affect the part.

In terms of clock rate, running the part at either 14 MHz, 21 or 28 MHz will be best as it reduces the number of wait states when accessing the 7 MHz 68000 bus of the A600.

I am looking at this design from the viewpoint of a design that could be manufactured in batches of 50/100 units by a commercial assembler. Surface mount wins here.

Should the part be a 68020 or 68EC020?
Depends on availability.
From a schematic point of view, I do not care at this time.

Looks like we can get the 68EC020 cheap from China or from Amiga Digital. Personally I would prefer to use New Old Stock (NOS) rather then reclaimed items for long term reliability.

The 68EC020 limits us to 8 MB of RAM, 4 MB if PCMCIA is used. This will be Fast RAM so will speed up the system by some margin. Smaller capacity SIMMS use less power, another good bonus.

Finally, at the end of April 2009, I will have to stop work on this project. Another project of mine is ramping up and as it is more important, it will get all little available free time.

Providing we can agree what parts to use and get a PCB underway, which is achievable, this project can progress.
@Amigadigital

Can you quote the full part number for the 68EC020s you have please?

Sure i will post this week the full part number of the 68ec020 chip

[kipper2k]

this sounds like a nice project, would love to see it get to fruition . My preference would be NOS, if you're going to do it then why risk using recycled chips. could cause timing issues, freezing etc, plus NOS would be better for the testing phase so that any hardware issues are not compounded.

[Amiga-Digital]

so here i'am

the part number of the cpu's that i have here are

MC68EC020FG16 1E13G CPHSW9542 thats the number thats on the cpu

[rkauer]

@A-D: seems a QFP (PLCC?) unit. If so, hold it until the design is done.;)

[Amiga-Digital]

@A-D: seems a QFP (PLCC?) unit. If so, hold it until the design is done.;)


Hi RKauer

the cpu's that i have here are the QFP that are use in the A1200 i have 600 of then new here the cpu's are never use

cheers

[rkauer]

Save those babies!!!:shocked:shocked:shocked;):D:blased:cool

I love to make 600 units of our board. Name a price of trade it for some useful gear.

Donations are good, too!:cheese

[Amiga-Digital]

Save those babies!!!:shocked:shocked:shocked;):D:blased:cool

I love to make 600 units of our board. Name a price of trade it for some useful gear.

Donations are good, too!:cheese

hahaha

ok but i will not sell all the 600 pcs. i need alot of them for repair some a1200 board's

but 1 package still unpackt and got 330 pcs of the 020 cpu's

i will keep it im stock here for the 020 card so that you can build 330 pcs of them ;)

[rkauer]

Only 330 accelerators?:blased

[mfletcher]

Ummm.... two more weeks?:blased:agree:shocked:D

[Stedy]

@Amiga-Digital

How much would you want for say 5 units for prototypes?
PM if necessary so that we can make a deal.

@Thread

The schematics are progressing reasonable. Sorting out the details of the SIMM interface. One consequence of using a 68EC020 is that we are limited to 4 MByte of RAM with PCMCIA or 8 MB without PCMCIA. I have a scheme that should make this easy to do and support 'downsizing' of larger SIMMs to fit the available memory window.

A 68EC020 @ 14 MHz, may not sound much on paper but with Fast RAM it will be 3-4x faster than a stock A600. I have looked into faster 680(EC)20 devices but we need to watch the heat inside the small A1200 case, especially with a SIMM onboard.

I recently purchased a Xilinx Coolrunner-II CPLD starter kit, this has allowed me to play with PLDs again :) We won't be using the Coolrunner-II devices as they cost $14, compared to the $3 for the XC95xx series devices.

That's all for now.

Ian

[mfletcher]

@Stedy,

Even with only four megs of ram, still and improvement and would allow majority of whdload games to run jsut fine. Thanks!

[rkauer]

Also remember: only the physical board design must be changed for a PGA 020 (and maybe a 030) and so it can accept even over 128Mb of memory (not that anything over 32Mb is necessary on a humble A600).

But this is a major rework over the PLCC board version: more addresses lines and a slightly complicated PLD code.

Things for the future.

[Amiga-Digital]

Also remember: only the physical board design must be changed for a PGA 020 (and maybe a 030) and so it can accept even over 128Mb of memory (not that anything over 32Mb is necessary on a humble A600).

But this is a major rework over the PLCC board version: more addresses lines and a slightly complicated PLD code.

Things for the future.

no problem you can make a pcb with a pga sockel and make a little pcb for the 1200 cpu to pga so that you can use the a1200 cpu into your 020 pcb last time i have see an pcb for the 1200 cpu that it fit into a pga

[Amiga-Digital]

@Amiga-Digital

How much would you want for say 5 units for prototypes?
PM if necessary so that we can make a deal.

@Thread

The schematics are progressing reasonable. Sorting out the details of the SIMM interface. One consequence of using a 68EC020 is that we are limited to 4 MByte of RAM with PCMCIA or 8 MB without PCMCIA. I have a scheme that should make this easy to do and support 'downsizing' of larger SIMMs to fit the available memory window.

A 68EC020 @ 14 MHz, may not sound much on paper but with Fast RAM it will be 3-4x faster than a stock A600. I have looked into faster 680(EC)20 devices but we need to watch the heat inside the small A1200 case, especially with a SIMM onboard.

I recently purchased a Xilinx Coolrunner-II CPLD starter kit, this has allowed me to play with PLDs again :) We won't be using the Coolrunner-II devices as they cost $14, compared to the $3 for the XC95xx series devices.

That's all for now.

Ian

i can send you 5 pcs of the 020 cpu with shipping for 14 us-dollar for your proto types

and if you need a tester for one of the proto i have 2 versions of a 600 here with a ide-2-cf card zo that i can test the proto type with os 1.3 2.0 2.04 3.0 3.1 3.5 3.9

no problem

[rkauer]

no problem you can make a pcb with a pga sockel and make a little pcb for the 1200 cpu to pga so that you can use the a1200 cpu into your 020 pcb last time i have see an pcb for the 1200 cpu that it fit into a pga

I saw those commercial PGA-to-PLCC converters. They have a lovely price, don't you think?:shocked:banghead

The same for the PLCC-to-PGA...:crying

over 580USD each!!!

[Amiga-Digital]

I saw those commercial PGA-to-PLCC converters. They have a lovely price, don't you think?:shocked:banghead

The same for the PLCC-to-PGA...:crying

over 580USD each!!!

580 usd dollar ?????

then you can make it ?????

[rkauer]

It is doable, but they are hard to made (say a major PITA) and with very low offer/seek, hence that nice robbery... :(

EDIT: price 69.59USD for a piece with 2 units as MOQ. Anyway, too damn expensive for our needs

[Amiga-Digital]

It is doable, but they are hard to made (say a major PITA) and with very low offer/seek, hence that nice robbery... :(

EDIT: price 69.59USD for a piece with 2 units as MOQ. Anyway, too damn expensive for our needs

haaa thas bad

but if you make a 020 pga turbo there are not many 020 pga's on the net to buy and i have here only the 1200 version of the 020 300pcs that i can sell for this project

but if you make a 020 turbo that use the 1200 cpu then let me no i can offer you 300pcs of them

[rkauer]

I know that. :)

What I mean is: if we make a mk2 version, it will be PGA, so a next version can be upgraded to 030 instead... :spin

[Shadowfire]

Hey, I finally got around to getting a logic analyzer and hooking it up to my IDE controller.
Unfortunately, there are issues with the current design. Primarily with the speed.
The microcontroller in the design is a 3.3V part and the SRAM is a 5V part. Due to technical issues with the microcontroller (not all lines are 5V tolerant), I decided to insert a 10K resistor in the SRAM <> microcontroller data lines (this would limit dissapated current on the microcontroller to .5mA/2.5mW on each line (16 data lines, and 2 control lines). I wrote an SRAM verification subroutine which failed, hence the need to hook up the analyzer.

The issue is signal rise/fall times. The SRAM has a 10pF capacitance, which makes a 100ns RC constant. After I hooked up my logic analyzer I saw that it was taking an excess of 540ns for some of the I/O lines to settle (and that's just what the analyzer sees... I don't currently have access to a digital storage scope to get the whole picture).

I was designing the controller with the intent of it being the fastest available for 68000 based systems, but that will not be happening with the current design. A part of my problem is the current prototype is wired by hand, not a PCB design, but I don't believe that the PCB will fix everything (yes, it will make the signals better, but not *that* much better).

The system will work if I introduce delays in my microcontroller code, but at this point I doubt it will even be breaking the 1MB/s barrier.

I've taken some time to think about my options and here they are.

1. Continue with this design, and finish up the SRAM <> 68000 glue logic debugging. (This will require me to spin a prototype board and purchase more parts. $130 for the proto board at pcb-pool.com, plus another $60 for parts that I need.)

PRO's: Over 60% of the work is already done. Once the prototype is built and debugged, the only thing left is driver work.

CON's: This design will not be nearly as fast as I originally intended.

2. Modify the design to include level shifting with an Altera CPLD. I didn't realize it at first, but the CPLD only (on the Amiga side) has to drive /XRDY and /INT2 lines, which are open-collector output. Hence, I really don't need 5V output on the CPLD. The SRAM is a 5V part but accepts 3.3V input signals natively. Freed from the perceived need to drive 5V, I am able to choose from any CPLD that has 5V tolerant I/O, and the Alterra MAX2 series has some 100-TQFP CPLD's for $7 - $14 each. I could route the 18 lines through the MAX2 as well as the SRAM R/W signal and it can do all the level shifting (as well as the SRAM <> 68000 handshaking that the XC9536 does in my current design).

PRO's: Eliminates the RC delay on the I/O lines, the SRAM can be driven much faster. Altera's CPLD software is a heck of a lot easier to use than ISE. The CPLD will introduce some delay, but eliminate the RC delay. How much timing slack will be gained is not specifically known at this time, as I would need to do the bulk of the CPLD design and run it through the simulator to figure out what my delays will be.

CON's: A nontrivial amount of redesign will need to occur. A new PCB schematic needs to be drawn up, a new CPLD selected (datasheet rummaging, entering old design into new CPLD and adding tristate buffers for level shifting on new I/O pass-thrus, generating pinouts, entering the new CPLD footprint/pinout into PADS, etc), I will need to scrap the firmware I ported to program the Xilinx CPLD and port the Alterra code.

3. Modify the design to include level shifting with a Xilinx CPLD. This is the same as option #2, but without the need to rewrite the CPLD programming code, and using the archaic Xilinx ISE software. The XC9572XL (TQFP-100) costs < $4 per piece.

Heh, now that I actually wrote those options down, the Altera options doesn't seem like a good compromise.

Since this is likely to go into your accelerator (oh, btw, there have already been some minor modifications to the schematic), I would like your opinion.

Edit: Forgot to add - my current design is to load up the SRAM with a ROMTAG and routines for autobooting, which means that I need to have the SRAM filled before the Amiga's processor scans it during powerup. This may be an issue with a 68020 based design, as it potentially could start executing code before the SRAM code is completely loaded, or miss it completely.

[rkauer]

Just add some delay to the handshaking code (making the BGAck signal wait enough) and problem solved.

Remember that PGA/(C)PLD is pure parallel computing. Yay!:spin

[NovaCoder]

Any cons with option 3?

[Shadowfire]

Nova: same cons as option 2, I would need to rewrite/compile CPLD schematic, change the PCB schematic and spin a new board. Only differences between 2 & 3 is nicer Altera software vs. rewriting code to upload the CPLD configuration.

OK. I will continue along the current lines. Progress will be halted on the hardware due to personal finances, but I can complete what I have done. Going to work a bit on optimizing the IDE bus access routines. I'm sure whenever I get the next prototype done I'll be able to revisit the timings and tighten them up, as there won't be 30 gauge wire in a neat mess, there'll be a ground plane to minimize trace inductance, etc.

Note: The rise time issues are with SRAM <> microcontroller communications. I haven't done the final prototype yet (the one which actually plugs into the 68000 socket) but from where I currently stand it has a really good chance of having 0 wait state access from the 68000 side (unless, of course, the microcontroller is accessing that same memory location already, in which case it would be delayed until the microcontroller finishes its operation. I've designed it so that situation should never occur, but made allowances for it.)

rkauer: you can make synchronous CPLD designs, johnson counters make it easy to add wait states. it's all in how you code the logic and whether you use latches or flipflops.

[Stedy]

@Shadowfire

Use ordinary diodes to fix the 3.3V/5V conversion problem. Tie the anode to 3.3V and the cathode to the signal, then if the signal rises above approx 3.9V, the diode limits the signal amplitude. Most devices can take 1V above supply for a short period of time, maybe 10ns without long term damage. Diode clamps are used to connect 3.3V PCI cards to a 5V PCI bus.

The other option is to use a level translator device, take a look at this page on the Texas Intruments website, http://focus.ti.com/logic/docs/translationselection.tsp?sectionId=458

What Xilinx software are you using?
The Webpack ISE V10 software is quite good, especially if you install Modelsim XE :)

You mentioned a settling time about 5x longer than you expected, sounds like you have a signal integrity problem. Add 33 ohm series resistors between the output pins of the PLD and the IDE cable to reduce reflections.

With the XC95XX family you can set fast or slow output slew rates in the software, try 'slow' and see if this helps.

Out of interest, what is the microcontroller doing in your design?

@Thread,

I have 5 x 68EC020 devices now, suppose I need to put some more effort into the design.

[Shadowfire]

Stedy - can't use the diodes. 18 I/O lines are affected, some of which (INT*, BUSY*) spend almost 100% of the time high. Also, the I/O lines are switched in software and remain high for far longer than that.

The level translator, however, looks like it's the perfect solution. SN74AVCH20T245 looks like a good match at first (I will look into these).

The rise/fall times I am referring to are for I/O lines on the SRAM <> Microcontroller lines, not the microcontroller <> IDE lines (although I did some optimization on the IDE handshaking code and now am having issues due to the tighter timing. I will add the 33 ohm resistors to match impedance on the next prototype and have another go at faster timings then.

Insofar as the slew rates are concerned, I don't have a storage scope at my disposal right now, so they may or may not be an issue. I'm thinking its more my hand-wired prototype without any ground-plane, would be a factor here. Also, this prototype consists of a PIC32SK, the PIC32 IO expansion board, and two PICTAIL prototype boards (one with the IDE interface and RS232 level shifter, and another with the SRAM interface). I didn't plan on attaining ideal speeds with the first prototype (for obvious reasons). The RC delay seems to be the biggest contributor to delay here though.

The targeted microcontroller is a PIC32MX360F256L, although I'm currently using the 512K flash version on the development board. It is an 80Mhz MIPS32-core microcontroller with most of the usual Microchip onboard devices (really only lacks PWM outputs).

[Shadowfire]

OK. The 20-line part isn't 5V tolerant, but the 16-line part is. I was able to use the 16-line part, and route the two remaining lines to 5V tolerant inputs on the microcontroller. Things are starting to look good. I don't even need to change my software, I just tap into the SRAM CE and RW lines to drive the level converter as well.

[Shadowfire]

Just sent the layout files to the board house to have the prototype PCB made.
This is the BOM for the prototype. The final editition won't need several of the components (C6-C9, C14, J4, J5, JP1-3, U5, J2, J7, and LA1-3) as they only for bringing out UART debug IO, attaching my logic analyzer, and conveniences for debugging.

Also, costs can be cut by using standard 0805 SM resistors instead of RN1-RN4 (I am using these to cut down on the size of the board as I had to place headers for my logic analyzer on this one, and keep the board under 4"x4" and tap into traces without having them go all over the board, but ATA termination could easily be done with two rows of 0805 resistors).

Putting the schematic and the .GWK files into the zone if you want to peruse the work done so far, as well as a snapshot of the current microcontroller firmware (at the moment its a bit of a mess but it compiles and works, includes code for PIO control of the hard disk as well as the code to read/write to SRAM and SRAM connection diagnostics.)

The XC9536 logic is done, but has not been tested. That will change once I get the board and assemble it. Note that it should be possible to use the XC9536XL equivalent with some minor modifications to the board (I originally didn't realize it was only going to be driving open-collector output lines to the motherboard).


|--------------------------------------------------------------------------------------------------------|
|Bill Of Materials for Embedded IDE Controller PROTO 1.sch on Mon Jun 01 12:00:52 2009 |
|--------------------------------------------------------------------------------------------------------|
|Item|Qty |Reference|Part Name |Manufacturer |Description |Part Number |
|----+----+---------+--------------+--------------+-----------------------------+------------------------|
|1 |1 |C11 |CAP1210,100uf,|Panasonic/ECG |SM CAP 1210 100uf 6.3V |Digikey PCC2267CT-ND |
| | | |20% |ECJ-4YB0J107M | | |
|2 |1 |C10 |CAP-ELECTAA, |Panasonic/ECG |SM CAP 0805 10uf 10V |Digikey PCC2233CT-ND |
| | | |10uf,-20% +80%|ECJ-2FF1A106Z | | |
|3 |2 |C1 C5 |CAP-ELECTAA, |Panasonic/ECG |SM CAP 0805 10uf 6.3V |Digikey PCC2400CT-ND |
| | | |10uf,10% |ECJ-2FB0J106K | | |
|4 |5 |C6-9 C14 |CAP-ELECTAA, |Panasonic |SM CAP 0805 1uf 16V |Digikey PCC2249CT-ND |
| | | |1uf,10% |ECJ-2FB1C105K | | |
|5 |14 |C2-4 |CAP0805MIL,.1 |Yageo |SM CAP 0805 .1uf DECOUPLING |Digikey 311-1245-1-ND |
| | |C12-13 |uf,20% |CX0805MRX7R7BB| | |
| | |C15-23 | |104 | | |
|6 |1 |J3 |CONN-DIP64-900|Samtec |2x BOARD TO BOARD |Digikey SAM1003-32-ND |
| | | | |BBL-132-T-F |INTERCONNECT 64-pin DIP | |
| | | | | |.100/.600 | |
|7 |1 |U4 |CY7C025 |CYPRESS |DUAL PORT SRAM |Digikey 428-2093-ND |
| | | | |CY7C025-25AXC | | |
|8 |1 |J4 |DB9 |Norcomp |SURFACE MOUNT DB9 CONNECTOR |Digikey 190-09FA-ND |
| | | | |190-009-263R00| | |
| | | | |1 | | |
|9 |2 |J5-6 |HDR2_100 |Samtec | |Digikey SAM1003-32-ND |
| | | | |BBL-132-T-F | | |
|10 |3 |JP1-3 |HDR3_100 |Samtec | |Digikey SAM1003-32-ND |
| | | | |BBL-132-T-F | | |
|11 |1 |J1 |IDE_40PIN_CONN|3M |HEADER 40 PIN IDE |Digikey MSH40ECT-ND |
| | | |ECTOR |D2540-6V0C-AR-| | |
| | | | |WH | | |
|12 |2 |LED1-2 |LED |Rohm |LIGHT EMITTING DIODE |Digikey 511-1292-1-ND |
| | | | |SML-211UTT86 | | |
|13 |1 |U6 |LM3940IMP-3.3 |NATIONAL |5V to 3.3V LDO Voltage |Digikey |
| | | | |SEMICONDUCTOR |Regulator |LM3940IMP-3.3CT-ND |
| | | | |LM3940IMP-3.3/| | |
| | | | |NOPB | | |
|14 |1 |U5 |MAX232 |MAXIM |+5V POWERED RS-232 |Digikey MAX232CSE+-ND |
| | | | |MAX232CSE+ |DRIVER/RECEIVER | |
|15 |1 |U2 |MC68000 |Mill-Max |64-pin DIP900 SOCKET FOR |Digikey ED90061-ND |
| | | | |110-44-964-41-|MC68000 16-/32-BIT | |
| | | | |001000 |MICROPROCESSOR | |
|16 |1 |U1 |PIC32MX3XX/4XX|MICROCHIP |PIC32 Microcontroller |Digikey |
| | | | |PIC32MX360F256| |PIC32MX360F256L-80I/PT-N|
| | | | |L-80I/PT | |D |
|17 |2 |R2 R7 |RES0805,1.65K,|Vishay/Dale |SM RES 0805 1.65K |Digikey 541-1.65KCCT-ND |
| | | |1% |CRCW08051K65FK| | |
| | | | |EA | | |
|18 |3 |R1 R3 R6 |RES0805,10K,1%|Vishay/Dale |SM RES 0805 10K |Digikey 541-10.0KCDKR-ND|
| | | | |CRCW080510K0FK| | |
| | | | |EA | | |
|19 |1 |R5 |RES0805,4.7K, |Vishay/Dale |SM RES 0805 4.7K |Digikey 541-4.70KCCT-ND |
| | | |1% |CRCW08054K70FK| | |
| | | | |EA | | |
|20 |1 |R4 |RES0805,5.6K, |Vishay/Dale |SM RES 0805 5.6K |Digikey 541-5.60KCCT-ND |
| | | |1% |CRCW08055K60FK| | |
| | | | |EA | | |
|21 |1 |J2 |RJ45-SMTYCO |Tyco |RJ45 Jack Surface Mount |Digikey A99305CT-ND |
| | | | |1-338086-3 | | |
|22 |1 |U7 |SN74LVC16T245D|TI |Voltage Level Shifter, |Digikey 296-20631-1-ND |
| | | |GGR |SN74LVC16T245D|Bidirectional, 16-line | |
| | | | |GGR | | |
|23 |1 |J7 |TEKMINI40PIN |Sullins |SM 40-pin .050 header |Digikey S9091-ND |
| | | | |SBH31-NBPB-D20| | |
| | | | |-ST-BK | | |
|24 |1 |LA1 |TEKP6444_CLOCK| | | |
| | | |HDR | | | |
|25 |2 |LA2-3 |TEKP6444_DATAH| | | |
| | | |DR | | | |
|26 |4 |RN1-4 |VSSR-RN-8,33, |Vishay |SM RN 33ohm 5% tolerance |Digikey VSSR16-33-JI-ND |
| | | |5% |VSSR1603330JUF| | |
|27 |1 |U3 |XC9536VQ44 |XC9536-7VQ44C |Xilinx CPLD 5V XC9536 |Digikey 122-1170-ND |
|--------------------------------------------------------------------------------------------------------|

[rkauer]

Can you edit the BOM into a "code" window for better comprehension?

[Shadowfire]

EAB isn't using a fixed-width font, and removed the whitespace, so it looks terrible. The BOM is included in the zip file I uploaded in the zone, open it in notepad and it looks much nicer.

[TCD]

rkauer means the and tags Shadowfire. You should try them :)

[Dimlow]

Seeing as Shadow has edited his post i have deleted my listing of the code here!

[rkauer]

Thanks, Dimmy!:great

[Amiga-Digital]

I saw those commercial PGA-to-PLCC converters. They have a lovely price, don't you think?:shocked:banghead

The same for the PLCC-to-PGA...:crying

over 580USD each!!!


i have found a site with PQFP and TQFP to PGA adapers fir a good price lower then 80 dollar better then over 580usd

here are the link http://www.epboard.com/eproducts/protoadapter1.htm#TQFP_LQFP_PQFP_VQFPtoDIPAdapter this pages got also other plcc-to-dip adapters for a great price

Cheers

[Shadowfire]

http://img520.imageshack.us/img520/3672/cdtvideprotofront.th.jpg (http://img520.imageshack.us/my.php?image=cdtvideprotofront.jpg)

Problems with this board:

Electrical:
Missing bypass capacitors for J7. (bypass caps for U3, U4 and some of U1 are on the back side of the board) This is a schematic error, not a layout error.
Missing all traces for address line A12 to/from SRAM. (Error when entering part data, A12 is on a line "NC[5]", its a no-connect on the 4Kx16 part, never went into the schematic, and I didn't catch the problem within my code until I went to test out SRAM interrupt mailboxes today. Jumper wires added to prototype.)
INT* from the SRAM... doesnt actually go to an IRQ line on the PIC32, just a plain old I/O port. Oops!
Termination resistors have wrong value on dedicated input/output lines; pullups & pulldowns at wrong location on DMARQ & IORDY (should be attached to the series termination resistor on the IDE port side, not the driver side).

Physical:
J4 missing two alignment holes for DB9 connector; also the existing holes should be plated, to solder the DB9 tabs to the board.
Forgot to put a copper pour under U6 & connect it to ground tabs & ground plane for heat dissipation. (Technically not needed as the package can dissipate the power this unit is drawing, but good for a reliability standpoint.)

Silkscreening:
LA2/LA3 subdescriptors exchanged (LA2 is JTAG, LA3 is SRAM)
U5: descriptor should be moved outside the outline.
Most of the caps (especially around U5) aren't actually polarized; should have used nonpolarized silkscreen.

[Zetr0]

@Shaodowfire

Mmmmmm nice!!!!!

[Shadowfire]

Spent about 4 hours at home soldering stuff. Everything is in place, except for the 2 bypass caps I forgot to put in for the voltage shifter. I'm taking a break, thats a lot of soldering to do without a pick'n'place, reflow oven, or wave machine, and I need to solder to some .010" legs for the bypass caps. Nope, just checked my layout: I have conveniently located vias near the pins I can use, phew.

Board is electrically sound, and passes all diagnostics written so far. Also, I was able to remove all software delays for SRAM access with the new prototype, and it is now running at near maximum speed.

1. Debug JTAG CPLD programming routine [supplied by Xilinx... already ported over... should mainly just be adjusting delay times. Header for my logic analyzer is already on this board.]
** completed june 13 2009 (Xilinx code did not work with XC9536, slight editing to prevent TCK cycling during delay times)

2. Debug 68000 <> SRAM interface [my CPLD code appears correct per the Amiga HW Reference manual, but if there are issues I'll likely need to spin a 68000 breakout board for my logic analyzer, and probably wait for the new DSO I ordered, too]
** june 16: completed lab tests of CPLD. CPLD firmware seems to be complete and correct. ordering some dip64 sockets from digi-key to stack so I can fit it in the machine.
** june 19: bypass caps on the SRAM voltage shifter, were NOT optional, data line D8 on the PIC was experiencing issues with the system up and running. Put bypass caps on both 5V inputs, only managed to put a bypass cap on one of the 3.3V supply inputs to it [the other one would be a pain in the ass to attach because the via is closed up], but that seems to be enough to resolve the issues, so for the time being I won't attach the other cap. The master schematic has been updated to have them all for the final spin of the board.
** completed june 23 2009

3. Amiga device driver - code on the microcontroller is essentially complete (it can read/write/inquire to the hard disk, and read/write from SRAM), the amiga <> microcontroller communications scheme is trivial to implement (commands & command completions passed with interrupt requests in both directions). No work has been done on the Amiga device driver aside from research (going over device driver articles, etc) & setting up a development environment on WinUAE, and I anticipate that this is the biggest piece left to do.
** june 19 - need access to a better Machine Language monitor to do low-level debugging. posted request in Coder's Heaven section along with gory details. I will eventually write diagnostics for the Amiga side but would like to check and make sure that the Amiga can read/write to SRAM correctly.
** june 29 - in the process of implementing & debugging command passing from amiga <> microcontroller. no snags yet (knock on wood). found a suitable ML monitor on Aminet to do manual memory modifications on Amiga to test PIC code, and using MonAM to debug my Amiga diagnostic software.
** july 6 - had to stop and do a flowchart(!) for program execution to make sure i was dealing with I/O errors correctly.
** july 15 - basic mountlist-style device driver seems is functional, works, and doesn't crash the amiga any more, although it has not yet been tested in-depth

4. Autoboot - already have an idea of how this will be done on my hardware (going to upload a ROMTAG in the SRAM & let the OS find it during powerup, possibly streaming the rest of the device driver from PIC32 flash if it ends up being > 16K long).

5. Optimizations (optional) - I'm hoping that I can crank the SRAM & IDE bus faster with the new layout & level shifter. I've had to insert timing delays & forego some optimizations in a lot of sections of my code to allow lines to settle on my handwired prototype.
** as noted at the beginning of the post, SRAM delays fixed with proto #1 (first PCB spin)

[NovaCoder]

Nice work Shadowfire :)

What's next...a zero wait-state 030 board for 1200's?

;)

[rkauer]

Sometimes I struggle in something interesting: to use a 030 instead the 020 on the board is just a matter of some pull-up resistors...:spin

But first, a working 020...

[Zetr0]

Looking at this from a projects development angle..

an A600 EC020 + 8MB ram, is a great start, from this a range of simple upgrades can be made.

a simple signal revision for use with DIP based 68k chips is very easy to implement and will provide a wide range of uses in A500/A600/A1000/A2000/CDTV and this added together is probably the largest Amiga User Base is.

from this the project could go in two directions.

EC030 implementation OR Full Core 020 implementation

The EC030 would be a small stepping stone, playing with the 030 architecture and signal providing requirements.

for me atleast I would like to see this step transpire, there may not be a need to make this for EVERY amiga, but 68k DIP would certainly provide some cash influx for the next project development.

from that a full core 030 with memory managemnt upto 128MB should be implemented for the 68k DIP / PLCC, keeping it simple to 72pin SIMM for memory.

this could then be revised for the A2000 CPU port and signal revision for the A1200, perhaps even CD32.

theres still work to be done though, the code exists to exploit the A500/CDTV and A1000/A2000 for IDE on top of the current projects. this will be a really HUGE seller I think.... an 030 + Fast RAM + IDE ... huston... we have lift off..

once this level is complete I would like to play around with 040 / 060 accelerators for these machines.

[xc8]

Looking at this from a projects development angle..

an A600 EC020 + 8MB ram, is a great start, from this a range of simple upgrades can be made.
...

Do you mean a 'new' project (020 card+8mb) or a 020 card that would fit over the 'currrent' 8MB RAM card?

[Shadowfire]

Today is the big day that I hook the board up to actual CDTV hardware. Everything looks O.K. on my logic analyzer (had a last minute change to the CPLD logic because I forgot to invert an input), my digital storage oscilloscope has arrived (so I can check signal integrity), and a couple of DIP64 socket from Digikey (so I can stack them up under the proto board and actually plug it into the mainboard) should be here today. The only elephant in the room is the CDTV power supply, I think that I should be OK on power for the controller itself (it draws up to 160mA on the 5V line, and I haven't done any power management or driven the CPLD unused lines low yet.), but I am not sure how well it will go over with a 2.5" hard disk on the 5V rail as well, since I don't know how much headroom there is. I guess I'll start off by powering the hard disk separately, then scoping out the 5V rail before and after applying the hard disk. I can't help but think that spinup power draw might stress the PSU, and it may be better to have a high capacity 12V -> 5V converter and draw the power off the 12V rail. Guess I'm going to find out.

I'm going to do compiling work on WinUAE, and need to get code over to the CDTV. Any suggestions? I currently plan on using Amiga Explorer to send over prebuilt executables, has anyone else attempted this sort of setup and if so, how did you do it? (I'm looking for something more efficient).

[Zetr0]

Do you mean a 'new' project (020 card+8mb) or a 020 card that would fit over the 'currrent' 8MB RAM card?

sorry to confuse you about this xc8,

the 8mb Card that I am responsible for building has been designed and developed by LVD of Nedo PC,

the card designs here are are by Shadow Fire, Rkauer, Steady and DimLow.

I am just here to make the party look pretty :D ;) :D ;)

[Shadowfire]

http://img31.imageshack.us/img31/4681/ideprotoinstalledandpow.th.jpg (http://img31.imageshack.us/i/ideprotoinstalledandpow.jpg/)

Installed in the CDTV, confirmed does not interfere with CDTV operation, and microcontroller is operating OK. CDTV boots and plays Turrican 2 (off of built-in CD).

5V rail (sampled at prototype board) varies peak-peak a max of 250mV. I discovered that my keyboard will not work with the CDTV (old style A3000 keyboard, new mini-din connector on CDTV, and an AT->ATX converter won't physically fit). I have put a bid in an auction on Ebay for some A500/A2000 hardware... if I win it, I won't bother hacking together an A3000 -> CDTV keyboard converter, i"ll do most of the testing on the A500.

going to do a bit more research here.

edit: hacked up a A3000 -> cdtv cable anyways. good thing I decided to trace out signals before building the adapter. I found out that NONE of the pinouts anywhere on the net for the A3000 OR CDTV keyboard ports are correct [taking into account mirroring, too!]... not even the power lines! I guess its not very common to do converters for either of these machines.

edit: Got the A500 but it's a 1.2 machine. the A2000 was upgraded to 2.1 and they put the original rom back into the antistat, I will check that one & see if its 1.2 or 1.3, but first the machines need to be cleaned up.

[Zetr0]

@Shadow Fire

Looks LOVELY!!!!

damn I LOVE High Quality hardware pr0n :D

[NovaCoder]

I love your work Shadowfire :)

[Shadowfire]

jun 22: mini-disaster. accidentally hit the voltage control on my power supply and fried the pic32mx microcontroller I/O lines. internal clamps no longer working, letting 5V from the Xilinx through onto the 3.3V power rail. a few minutes later the chip died.

fortunately, I had 6 more suitable replacements on hand. took a better part of a day to reflow, clear off the board, and verify I/O lines. PDIAG* on the IDE bus isn't working, and I can't see why, but at the moment I don't even use the line in my code, and I can't see a short or open, although there must be one somewhere.

jun 23:

Hardware is 100% complete, tested and verified. The 68000 can see, read, and write to the SRAM. Reads and writes to the mailboxes on both sides generate and clear interrupts in both directions. I don't actually have INT2* and XRDY* hooked up yet (I am currently running them to 10K pullups to +5V so I can verify functions on my logic analyzer). A smattering of tests with the ML monitor showed I was able to do all of the above.

jun 28:
ordered a cheap 10x/30x stereoscopic microscope with back and stage lighting, as well as a cheap hot air station (better than what I was using before - a Milwaukee Heat Gun [which is kind of like a hair dryer with 2 power settings, low which barely melts lead solder, and high which will burn the board if you arent exceedingly careful and fast], and an 8x magnifying glass). Hopefully I can see where the PDIAG* problem is when I get the new kit in.

It's time to move onto creating the Amiga device driver, and implementing it on the controller.

[NovaCoder]

All great projects need at least one major disaster, it will give you something to talk about in years to come ;)

[yaqube]

PDIAG* on the IDE bus isn't working, and I can't see why

_PDIAG is asserted only by the SLAVE drive during initialization to inform the MASTER drive that it's ready. Do you have both drives connected?

What's the point of having the MCU between the CPU and the HDD? Any additional data buffering will have performance penalty.

[Shadowfire]

Actually, the /PDIAG failure was an I/O output test from the PIC32 with nothing attached to the IDE cable but my logic analyzer.

There were several reasons to use a microcontroller:

1. PIO handshaking on a 68000, even when assisted with a CPLD, isn't exactly fast. The microcontroller handles all the hairy details of IDE access and drive geometry translation while the 68000 runs away at something else, at full speed. Also, the design is double-buffered for disk I/O (i.e. the Amiga can setup a request for a second IO while first IO is running).

2. As designed, the 68000 has zero wait states when accessing SRAM, which is mapped into 68000 address space. This makes the actual sector data transfer look like MOVE.W (A0)+, (A1)+ and a DBNE instruction [which will trigger loop mode on a 68010+].

3. By stuffing the SRAM with code, I can do early-startup routines such as autoboot. Without a microcontroller, I would need a CPLD with integrated flash memory modules and more I/O lines to do this, and/or extra components on the board.

4. By using a microcontroller, code updates to the microcontroller, CPLD, and 68000 autoboot code can be performed with one piece of hardware: a Microchip PIC32 programmer.

5. The design originally included a 10Mb twisted pair ethernet transceiver, but it was eventually cut due to inability to route the RJ45 to a reasonably accessible external position.

[AB Positive]

Shadowville - if you get this running and make working models I'll *drive* to you to pick one up. This is exciting stuff here!

I wish I was knowledgable enough to help, but instead I'll keep waving my pom-poms :)

[Zetr0]

AB_Positive ->

Gimmie 'n "S"....... Gimmie 'n "H"........ Gimmie 'n "Oh shit it just burnt out!"...

@Shadow Fire
sorry to hear of the casualty there Shadow Fire, glad to read you have replacements, if you do get caught short jut gimmie a PM have a lot of IC's floating that may help.

[rafgc]

Will the 020 accelerator schematics be ever available for the public like LVDs v2007 memory expansion or is it a closed project. I mean those LVDs epansions are so hard to obtain that i had to do one by meyself thanks to LVDs open source schematics (and his help). Will be 020 accelerators more available than 8MB expansions?

[Zetr0]

@rafgc

a good couple of questions, I believe that this 020+8mb Fast is an open project. I believe once the sources have been worked out the group will disseminate it for people to build thier own or to revise it for thier useage.

theres a lot of work in this project, from component and signal layouts, which I have seen the rudimentary schematic as such. so the progress is moving on. alas theres so much to do, considering a lot of the older components are no longer available and have to be substituted, this can play a lot on signal lengths and times.

the code is underway but is slow going as the above is being finalized, the basic concepts are there, its now a matter of time,

on another note hopefully in a week or two I will open up Batch No.2 for processing the LVD A608 cards. I will post more details on www.a608-amiga.co.uk

[Amiga-Digital]

so i will sell myn 250 pcs of the 68ec020/16mhz cpu's ( a1200 cpu type )
for 2 us-dollar for 1 cpu and for all the 250 for a good price of 1 us-dollar pro cpu chip with the shipping cost

be vast

Thanks

[rafgc]

What is required for other CPU to take over the system? How does it disabling main CPU?

[Shadowfire]

I beileve it was already stated in this thread (and probably others): The accelerator asserts BR*, waits for BG*, asserts BGACK*, but never lets them go. It works as long as you don't have Zorro-2 or Zorro-3 DMA transfers in your system, and account for custom chip/8520 accesses in your interface.

Also: Still working on the Amiga software stack. Taking a bit of time as I have to re-familiarize myself with Exec, *and* dig a lot deeper into device tasks/messages/iorequests/drivers/structures, something which I never did before (as last time around I was a software-only type of guy and was primarily using intuition/dos/graphics libraries, only using exec for memory allocations and library functions). If I had to guess at the moment I'm 30% done with a basic device driver and 15% done overall with the Amiga software.

[Stedy]

Hi,

@rafgc

The schematics, PCB and firmware will be available, when the design is complete.
I am looking into the option of assembled units, see how thing progress first though.

Progress has been slow due to the demands of my day job.

Ian

[Shadowfire]

Minor status update on the IDE interface:

Basic driver work ~50% done. I have to go back and touch up my PIC32 code a bit (I changed my command queue structure a little bit to make the driver on the Amiga side much neater, and also deal with possible nastiness dealing with multiple queued commands and PIC/Amiga response times. Also I need to knock off a little bit more firmware to send an IDE flush cache command (that should be easy though).

So basically, the hardware is done, and the software is (as usual) taking 4x as long as the hardware.

[Zetr0]

@Shadowfire

I am waving my proverbial Imperial Flag !!!!!

[Shadowfire]

idedisk/Init: called
idedisk/md_taskMsgPortPtr=389294
idedisk/InitRoutine, unitmsgport= 5F0AE, taskcb=5E74E
idedisk/Init: About to add task, taskcontrolblock=5E74E
idedisk/Init: device=5E6FC
idedisk/Open: called
idedisk/InitUnit: called
idedisk/InitUnit: reading device 0
idedisk/InitUnit: Device enumerated by PIC
idedisk/InitUnit: Device initialized by PIC
idedisk/Open: Open succeeded.
idedisk/BeginIO - IORequest received!
idedisk/BeginIO -- unit=0, iorequest=D228, device=5E6FC, command number=$F
idedisk/BeginIO -- Task not ready!
idedisk/PutMsg: Port=5F0AE Message=D228
idedisk/BeginIO_End
idedisk/Task_Begin
idedisk/Task_Begin - about to AllocSignal for interrupt
idedisk/Task_Begin - about to add interrupt server
idedisk/Task_Begin - about to AllocSignal for message port
idedisk/TaskSignalBit=30, IntSigBit==31 Device=5E6FC Task=5E74E
idedisk/Task_StartHere: ++Wakeup
idedisk/Task:Queues are available.
idedisk/Task_NextMessage: about to GetMsg() port=5F0AE
idedisk/GotMsg iorequest=D228
idedisk/PerformIO -- command=$F iorequest=D228 device=5E6FC
idedisk/TermIO, ReplyMsg() iorequest=D228 device=5E6FC
idedisk/Task:Queues are available.
idedisk/Task_NextMessage: about to GetMsg() port=5F0AE
idedisk/GotMsg iorequest=0
idedisk/++Sleep
idedisk/BeginIO - IORequest received!
idedisk/BeginIO -- unit=0, iorequest=D228, device=5E6FC, command number=$2
idedisk/PutMsg: Port=5F0AE Message=D228
idedisk/Task_StartHere: ++Wakeup
idedisk/Task:Queues are available.
idedisk/Task_NextMessage: about to GetMsg() port=5F0AE
idedisk/GotMsg iorequest=D228
idedisk/PerformIO -- command=$2 iorequest=D228 device=5E6FC
idedisk/RdWrt len 512 offset 0 data $51950

... at which point I reset. So, it appears that message passing is working fine, and work is moving along. estimated 65% done on "basic" (mountlist-style) device driver.

[Shadowfire]

idedisk/Init: called
idedisk/InitRoutine, unitmsgport=$6B00E, taskcb=$6A6B2
idedisk/Init: About to add task, taskcontrolblock=$6A6B2
idedisk/Init: device=$6A65C
idedisk/Open: called
idedisk/InitUnit: called
idedisk/InitUnit: reading device 0
idedisk/InitUnit: Device enumerated by PIC
idedisk/InitUnit: Device initialized by PIC
idedisk/Open: Open succeeded.
idedisk/BeginIO - IORequest received!
idedisk/BeginIO -- unit=0, iorequest=$D2D0, device=$6A65C, command number=$F
idedisk/BeginIO -- Task not ready!
idedisk/BeginIO -- PutMsg() Port=$6B00E Message=$D2D0
idedisk/BeginIO_End
idedisk/Task_Begin
idedisk/Task_Begin - about to AllocSignal for interrupt
idedisk/Task_Begin - about to add interrupt server
idedisk/Task_Begin - about to AllocSignal for message port
idedisk/TaskSignalBit=30, IntSigBit==31 Device=6A65C Task=6A6B2
idedisk/Task: Check if a command is waiting for a queue.
idedisk/Task: No pending command.
idedisk/Task_NextMessage: about to GetMsg() port=$6B00E
idedisk/Task_NextMessage: GotMsg iorequest=D2D0
idedisk/Task: Calling PerformIO.
idedisk/PerformIO -- command=$F, iorequest=$D2D0, device=$6A65C
idedisk/TermIO, ReplyMsg() iorequest$=D2D0, device=$6A65C
idedisk/BeginIO - IORequest received!
idedisk/BeginIO -- unit=0, iorequest=$D2D0, device=$6A65C, command number=$2
idedisk/BeginIO -- PutMsg() Port=$6B00E Message=$D2D0
idedisk/BeginIO_End
idedisk/Task: Returned from PerformIO.
idedisk/Task: Check if a command is waiting for a queue.
idedisk/Task: No pending command.
idedisk/Task_NextMessage: about to GetMsg() port=$6B00E
idedisk/Task_NextMessage: GotMsg iorequest=D2D0
idedisk/Task: Calling PerformIO.
idedisk/PerformIO -- command=$2, iorequest=$D2D0, device=$6A65C
idedisk/RdWrt len 512 offset 0 data $50C78
idedisk/RdWrt-- data pointer is even.
idedisk/RdWrt-- Offset is on sector boundary (512 bytes).
idedisk/RdWrt-- data did not have 32-bit overflow.
idedisk/RdWrt-- data did not exceed device size.
idedisk/RdWrt-- end address is on sector boundary.
idedisk/RdWrt-- about to submit the command.
idedisk/Submit: command=$1, bytestoxfer=512, amigamemaddress=$50C78
idedisk/Submit: blockhi=$0, blocklo=$0, read*/write=0
idedisk/Submit: device=$6A65C, iorequest=$D2D0, unit=0
idedisk/Submit: TMP_REMAINING_SECTORS=1
idedisk/Submit: Check for available queue
idedisk/Submit: Using queue #0 to build up command queue.
idedisk/Submit: commandbank=0, cbaddress=$EF3C00, sectoraddress=$EF0000, QSDaddr
ess=$EF3F80
idedisk/Submit: Building command slot # 0, slotaddress=$EF3C00.
idedisk/Submit: 512 or fewer bytes left.
idedisk/Submit: LastIssue: blank out any remaining commands.
idedisk/Submit: Remaining slots blanked. About to dispatch current queue.
idedisk/Submit: Calling DISPATCH_QUEUE on queue # 0.
idedisk/Dispatch: Bank # 0, CommandBankStatusAddress=$EF3F80
idedisk/Dispatch: Write value $8000, PICMAILBOX address=$EF3FFE
idedisk/Submit: Returned from DISPATCH_QUEUE. Exiting Submit_Command.
idedisk/RdWrt-- Command successfully queued.
idedisk/Task: Returned from PerformIO.
idedisk/Task: Check if a command is waiting for a queue.
idedisk/Task: No pending command.
idedisk/Task_NextMessage: about to GetMsg() port=$6B00E
idedisk/Task_NextMessage: GotMsg iorequest=0
idedisk/++Sleep
idedisk/Task_Wait sanity check: stackpointer=$6B006
idedisk/Task: Wait()ing on signal mask $C0000000
idedisk/Task: Woke up to signal mask $40000000
idedisk/Task: Check if a command is waiting for a queue.
idedisk/Task: No pending command.
idedisk/Task_NextMessage: about to GetMsg() port=$6B00E
idedisk/Task_NextMessage: GotMsg iorequest=0
idedisk/++Sleep
idedisk/Task_Wait sanity check: stackpointer=$6B006
idedisk/Task: Wait()ing on signal mask $C0000000
idedisk/Task: Woke up to signal mask $80000000
idedisk/Task: IRQ Handler Signal received - service queues.
idedisk/Handle_IRQ: Bank #0 ready.
idedisk/Handle_Queue: QSD Bank=$EF3F80, Commandbank=$EF3C00, Sectorbank=$EF0000,
device=$6A65C
idedisk/HQ_CheckNextSlot: All slots checked, no errors.
idedisk/HQ_ParseCommands: command #0, slotaddress=$EF3C00
idedisk/HQ_ParseCommands: command is in slot.
idedisk/HQ_ParseCommands: TARGETAMIGAADDRESS=$50C78, sectorbuffer=$EF0000, trans
fer length=512, IO_ACTUAL=$200
idedisk/HQ_ParseCommands: Read operation, copying data to memory.
idedisk/HQ_ParseCommands: command #1, slotaddress=$EF3C20
idedisk/HQ_ParseCommands: command #2, slotaddress=$EF3C40
idedisk/HQ_ParseCommands: command #3, slotaddress=$EF3C60
idedisk/HQ_ParseCommands: command #4, slotaddress=$EF3C80
idedisk/HQ_ParseCommands: command #5, slotaddress=$EF3CA0
idedisk/HQ_ParseCommands: command #6, slotaddress=$EF3CC0
idedisk/HQ_ParseCommands: command #7, slotaddress=$EF3CE0
idedisk/HQ_ParseCommands: All commands processed.
idedisk/HQ_ParseCommands: ReplyMsg iorequest=$D2D0, device=$6A65C
idedisk/HQ_Free_Queue: Mark queue as freed & return from subroutine
idedisk/Handle_IRQ: Exiting subroutine.
idedisk/Task: Check if a command is waiting for a queue.
idedisk/Task: No pending command.
idedisk/Task_NextMessage: about to GetMsg() port=$6B00E
idedisk/Task_NextMessage: GotMsg iorequest=0
idedisk/++Sleep
idedisk/Task_Wait sanity check: stackpointer=$6B006
idedisk/Task: Wait()ing on signal mask $C0000000

Diagnostics come from mounting an FFS partition. The computer hangs after the filesystem reads sector 0 (which I have blanked out to all 0's). This is going to take a bit more work yet to figure out why, but I'm getting pretty close to completion here. The Amiga Task -> PIC -> IRQ -> Task communications are functioning within the device driver.

[Shadowfire]

As I type this, the Amiga is formatting a mountlist-mounted partition the size of a floppy disk. It is incredibly slow due to all the debug info spitting out the serial ports of both the Amiga and the PIC32 microcontroller, but it does indeed seem to be working. There seems to be some issues with command slot population, which I will need to investigate a bit further, but I think I'm going to call it a night, and deal with it in the morning.

[Zetr0]

@shadowfire

Very VERY VERY exciting!!!!!!

[Shadowfire]

First stable rev of the device driver, all debug info turned off.
No optimizations in place. Stock 7mhz CDTV, plus an ancient 200mb laptop 2.5" hard disk.

Diskspeed 4.2 gives writes of 25k-30k / sec, and reads of 40k-76k/sec (depending on buffer size). Cpu availability on all ops between 47%-90% when word or long aligned transfers (43%-77% on byte aligned transfers)

Going to pull out a 60gig drive later & see how that changes things.

Edit: Diskspeed results for a 60gig laptop hard disk [this should remove any current bottlenecks]

MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 34.0 Normal Video DMA
Device: dh0: Buffers: <information unavailable>
Comments: DiskSpeed 4.2

CPU Speed Rating: 136

Testing directory manipulation speed.
File Create: 15 files/sec | CPU Available: 37%
File Open: 31 files/sec | CPU Available: 32%
Directory Scan: 73 files/sec | CPU Available: 42%
File Delete: 31 files/sec | CPU Available: 33%

Seek/Read: 74 seeks/sec | CPU Available: 36%

[snip... no fast memory tests]

Testing with a 512 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 38012 bytes/sec | CPU Available: 44%
Write to file: 40508 bytes/sec | CPU Available: 45%
Read from file: 40572 bytes/sec | CPU Available: 46%

Testing with a 4096 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 60287 bytes/sec | CPU Available: 71%
Write to file: 66048 bytes/sec | CPU Available: 74%
Read from file: 66560 bytes/sec | CPU Available: 74%

Testing with a 32768 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 71208 bytes/sec | CPU Available: 71%
Write to file: 80580 bytes/sec | CPU Available: 77%
Read from file: 81583 bytes/sec | CPU Available: 77%

Testing with a 262144 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 73381 bytes/sec | CPU Available: 71%
Write to file: 81495 bytes/sec | CPU Available: 77%
Read from file: 82782 bytes/sec | CPU Available: 77%

Testing with a 512 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 38332 bytes/sec | CPU Available: 45%
Write to file: 40572 bytes/sec | CPU Available: 45%
Read from file: 40764 bytes/sec | CPU Available: 46%

Testing with a 4096 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 60287 bytes/sec | CPU Available: 70%
Write to file: 66048 bytes/sec | CPU Available: 74%
Read from file: 66560 bytes/sec | CPU Available: 74%

Testing with a 32768 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 71346 bytes/sec | CPU Available: 71%
Write to file: 80412 bytes/sec | CPU Available: 77%
Read from file: 81078 bytes/sec | CPU Available: 77%

Testing with a 262144 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 73498 bytes/sec | CPU Available: 72%
Write to file: 81352 bytes/sec | CPU Available: 77%
Read from file: 82634 bytes/sec | CPU Available: 77%

Testing with a 512 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 34621 bytes/sec | CPU Available: 39%
Write to file: 21374 bytes/sec | CPU Available: 48%
Read from file: 34941 bytes/sec | CPU Available: 40%

Testing with a 4096 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 40536 bytes/sec | CPU Available: 47%
Write to file: 23453 bytes/sec | CPU Available: 54%
Read from file: 41128 bytes/sec | CPU Available: 48%

Testing with a 32768 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 41037 bytes/sec | CPU Available: 49%
Write to file: 23830 bytes/sec | CPU Available: 54%
Read from file: 41912 bytes/sec | CPU Available: 49%

Testing with a 262144 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 40642 bytes/sec | CPU Available: 49%
Write to file: 23758 bytes/sec | CPU Available: 54%
Read from file: 42223 bytes/sec | CPU Available: 49%

Average CPU Available: 58% | CPU Availability index: 79

[Shadowfire]

The most recent, debugged files are posted in the Zone. Current Amiga device driver & source, final schematic diagram, current PIC32 firmware, and final Xilinx CPLD configuration.

I can attach and mount partitions on either drive, format, read and write without any corruption, etc. Be aware that I still consider this beta software, as up to about 3 hours ago I was still fixing obscure bugs (move.w instead of move.l, resulting in commands going to unit #0 instead of unit #1, etc).

The hardware (schematic diagram & CPLD logic), however, I consider to be "done", so if you want to model some PCB's with it added, it should be ok to do so.

[crabfists]

This is awesome. :) I just want to say I think it's brilliant people like you are still developing hardware for the Amiga.

[Shadowfire]

All of the obvious, low-hanging-fruit type of optimizations that I could find in the last day are done. Pretty much all the improvements were done on the PIC32 side of things. Oh, and I added byte swizzling to the sector transfers, so I lost some of my gains there. I think that 100k/sec isn't a bad transfer rate for a stock 7mhz system.

I know I can squeeze more performance out of the 68000 side, but it will require a nontrivial rejiggering of the device driver and PIC32 command queue.

At this point, I think I'll work on SCSI-direct emulation, so that HDToolBox will work for partitioning the drives. After that, I'll dig in a little further and attempt some scsidirect -> ATAPI translation for cdrom drive support.


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 34.0 Normal Video DMA
Device: dh0: Buffers: <information unavailable>
Comments: DiskSpeed 4.2

CPU Speed Rating: 136

Testing directory manipulation speed.
File Create: 15 files/sec | CPU Available: 40%
File Open: 37 files/sec | CPU Available: 27%
Directory Scan: 80 files/sec | CPU Available: 39%
File Delete: 42 files/sec | CPU Available: 24%

Seek/Read: 81 seeks/sec | CPU Available: 33%

[snip... no fast memory tests]

Testing with a 512 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 37564 bytes/sec | CPU Available: 47%
Write to file: 40060 bytes/sec | CPU Available: 48%
Read from file: 45179 bytes/sec | CPU Available: 42%

Testing with a 4096 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 59776 bytes/sec | CPU Available: 74%
Write to file: 65768 bytes/sec | CPU Available: 78%
Read from file: 78680 bytes/sec | CPU Available: 74%

Testing with a 32768 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 68074 bytes/sec | CPU Available: 76%
Write to file: 77024 bytes/sec | CPU Available: 82%
Read from file: 95707 bytes/sec | CPU Available: 78%

Testing with a 262144 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 70958 bytes/sec | CPU Available: 76%
Write to file: 78384 bytes/sec | CPU Available: 82%
Read from file: 98095 bytes/sec | CPU Available: 79%

Testing with a 512 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 38332 bytes/sec | CPU Available: 47%
Write to file: 39868 bytes/sec | CPU Available: 48%
Read from file: 45435 bytes/sec | CPU Available: 42%

Testing with a 4096 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 60040 bytes/sec | CPU Available: 74%
Write to file: 65536 bytes/sec | CPU Available: 78%
Read from file: 79024 bytes/sec | CPU Available: 74%

Testing with a 32768 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 68208 bytes/sec | CPU Available: 76%
Write to file: 76863 bytes/sec | CPU Available: 82%
Read from file: 95707 bytes/sec | CPU Available: 79%

Testing with a 262144 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 70741 bytes/sec | CPU Available: 76%
Write to file: 78251 bytes/sec | CPU Available: 82%
Read from file: 98457 bytes/sec | CPU Available: 79%

Testing with a 512 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 34485 bytes/sec | CPU Available: 41%
Write to file: 22590 bytes/sec | CPU Available: 48%
Read from file: 38012 bytes/sec | CPU Available: 36%

Testing with a 4096 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 40536 bytes/sec | CPU Available: 49%
Write to file: 24777 bytes/sec | CPU Available: 54%
Read from file: 45054 bytes/sec | CPU Available: 46%

Testing with a 32768 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 40620 bytes/sec | CPU Available: 51%
Write to file: 25022 bytes/sec | CPU Available: 55%
Read from file: 46533 bytes/sec | CPU Available: 47%

Testing with a 262144 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 40588 bytes/sec | CPU Available: 52%
Write to file: 25005 bytes/sec | CPU Available: 55%
Read from file: 46882 bytes/sec | CPU Available: 47%

Average CPU Available: 59% | CPU Availability index: 80

[ppill]

:bowdown

Amazing, simply amazing... my hat goes off to you, good sir :)

[AGN]

Shadowfire, please elaborate a bit about "High compatibility with compact flash cards" subject.
Thanks.

[Shadowfire]

Are you sure you are asking the right person? I don't remember saying anything about flash cards anywhere.

However, as long as the flashcards can attach to a standard 40-pin IDE header (or whatever header they eventually decide to put on the board), respond to PIO mode commands, and report their geometry with an IDENTIFY_DEVICE command, there's no reason you shouldn't be able to use them on the controller. The SCSI-direct emulation layer I'm working on should spoonfeed apps like HDToolbox the drive's geometry information, taken directly off the IDENTIFY_DEVICE information.

I'm currently rewriting the queuing mechanism on both microprocessors (rewrite needed to add skeletal SCSI-direct support), and implementing multisector transfers on the microcontroller, in the hopes of gaining some more performance.

I'm pretty much shooting in the dark on this, though, as I know of no profiling software for the PIC32 which would be able to tell me where most of my time is being spent, and my profiler on the Amiga side needs to launch the software being profiled (which doesn't work out too well with device drivers, which are launched by the system) (and probably wouldn't profile the task I create that does most of the work, anyways).

[AGN]

Are you sure you are asking the right person? I don't remember saying anything about flash cards anywhere.
First of all. My question wasn't offensive in any way.
Second I'm pretty sure that lots of people will try to use CF card instead heavy, hot, noisy, big and power hungry 2,5" hdd.

So, it might be cool to say something like that:
Dear Amiga community. I have great news for You. My CF card works fine with hdd interface.However, as long as the flashcards can attach to a standard 40-pin IDE header (or whatever header they eventually decide to put on the board), respond to PIO mode commands, and report their geometry with an IDENTIFY_DEVICE command, there's no reason you shouldn't be able to use them on the controller. The SCSI-direct emulation layer I'm working on should spoonfeed apps like HDToolbox the drive's geometry information, taken directly off the IDENTIFY_DEVICE information.

As You probably know there are lots of CF devices around. Some of them behave very strange.
Achieving better success rate than A600/A1200 ide (http://eab.abime.net/showthread.php?t=25274) might be good project goal.

What joe user can do to help this project? Maybe CF donations to You for getting better compatibility?

[webhead]

i dont care if its cf friendly i just want 1 right now for my poor little hdless cdtv please can i have 1 pleeaseeeeeee.

how much is it going to cost me,please update im all excited.

[Stedy]

@Shadowfire

Nice work.

I've downloaded the design files and started to review them.
I'm planning to use the XC9572 in the 100 pin package on my design so I should be able to absorb your design at a later date.

I may have some more questions once I finish studying the design.

With regard to your profiling issues, the Microchip REAL ICE might help but it is expensive. A cheaper more practical solution is to use the spare I/O pins, of which you have a few, to make an R/2R digital to analogue converter. When the software enters a function, it outputs a different binary code, which in turn gives a different analogue voltage. By measuring the resultant waveform on an oscilloscope, you can gauge what functions are used most often and for how long.

I would also like to see support for Compact flash cards.

Bye,

Ian

[Shadowfire]

Stedy - I have the REAL ICE. It does not, in and of itself (or in conjunction with MPLAB) support profiling, as far as I can tell.

REAL ICE and the PIC32 does support hardware trace, but it just dumps a disassembly of the execution path as a file. No profiling. (Also, I am using the I/O lines that the hardware trace uses for other functions.)

The Xilinx code is asynchronous, but I can get away with it because of the 68000 setup and hold times (and its asynchronous design). On a 68020 board, you should be able to drive the SRAM with minimal waitstates at the higher bus speed.

There has been a rewrite of parts of the device driver and PIC32 driver since I posted. The command passing queues have gone away, I only pass 1 command per queue now. Also, I am extending the driver to do simple SCSI-direct emulation.

Testing compact flash cards would require that I acquire more hardware [and having been unemployed since March, this means that I have to sell off some of my stuff to do so]. There is a CFA_ command set in the ATA spec, but it seems that it is geared for filesystems that understand about flash memory. From what I can see (and I could be wrong but the spec seems to say this), CF cards are required to suport READ_SECTORS, WRITE_SECTORS, and IDENTIFY_DEVICE, which is what I have already implemented.

Edit: I have ordered some compact flash -> IDE adapters off of ebay, as well as some compact flashcards: a Kingston Elite Pro 2GB, a generic Elite Pro 2GB, a Canon 32MB card, and a Lexar 256MB card. They are all probably coming on a Slow Boat From Hong Kong (tm), though, so it will probably be 2-3 weeks before I can begin testing on that stuff.

[Shadowfire]

This seems to be where final performance will lie, without either a redesign of the hardware or better profiling tools.

Edit: I am mistaken. I found significant improvements. I need to verify system reliability before I post more numbers.


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 34.0 Normal Video DMA
Device: dh0: Buffers: <information unavailable>
Comments: DiskSpeed 4.2

CPU Speed Rating: 136

Testing directory manipulation speed.
File Create: 19 files/sec | CPU Available: 33%
File Open: 39 files/sec | CPU Available: 25%
Directory Scan: 84 files/sec | CPU Available: 37%
File Delete: 47 files/sec | CPU Available: 19%

Seek/Read: 84 seeks/sec | CPU Available: 31%

[snip... no fast memory tests]Testing with a 512 byte, MEMF_CHIP, LONG-aligned buffer.

Create file: 43579 bytes/sec | CPU Available: 41%
Write to file: 46267 bytes/sec | CPU Available: 42%
Read from file: 47867 bytes/sec | CPU Available: 41%

Testing with a 4096 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 71743 bytes/sec | CPU Available: 70%
Write to file: 78848 bytes/sec | CPU Available: 75%
Read from file: 82257 bytes/sec | CPU Available: 75%

Testing with a 32768 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 84432 bytes/sec | CPU Available: 73%
Write to file: 94557 bytes/sec | CPU Available: 80%
Read from file: 99502 bytes/sec | CPU Available: 79%

Testing with a 262144 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 85948 bytes/sec | CPU Available: 73%
Write to file: 96494 bytes/sec | CPU Available: 81%
Read from file: 102300 bytes/sec | CPU Available: 80%

Testing with a 512 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 44091 bytes/sec | CPU Available: 42%
Write to file: 46267 bytes/sec | CPU Available: 42%
Read from file: 47483 bytes/sec | CPU Available: 42%

Testing with a 4096 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 71886 bytes/sec | CPU Available: 70%
Write to file: 79024 bytes/sec | CPU Available: 75%
Read from file: 82083 bytes/sec | CPU Available: 75%

Testing with a 32768 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 84609 bytes/sec | CPU Available: 73%
Write to file: 94375 bytes/sec | CPU Available: 80%
Read from file: 99695 bytes/sec | CPU Available: 79%

Testing with a 262144 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 86582 bytes/sec | CPU Available: 74%
Write to file: 96105 bytes/sec | CPU Available: 80%
Read from file: 102300 bytes/sec | CPU Available: 80%

Testing with a 512 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 39036 bytes/sec | CPU Available: 35%
Write to file: 24958 bytes/sec | CPU Available: 44%
Read from file: 40124 bytes/sec | CPU Available: 35%

Testing with a 4096 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 46301 bytes/sec | CPU Available: 44%
Write to file: 27362 bytes/sec | CPU Available: 52%
Read from file: 48336 bytes/sec | CPU Available: 44%

Testing with a 32768 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 47185 bytes/sec | CPU Available: 46%
Write to file: 27579 bytes/sec | CPU Available: 53%
Read from file: 49151 bytes/sec | CPU Available: 46%

Testing with a 262144 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 47373 bytes/sec | CPU Available: 46%
Write to file: 27497 bytes/sec | CPU Available: 53%
Read from file: 49775 bytes/sec | CPU Available: 46%

Average CPU Available: 56% | CPU Availability index: 76

[Shadowfire]

Webhead - I am not involved in the actual production of the boards. I only did two prototypes (1 very rough one as a proof of concept which doesn't do an awful lot, and one board spin for debug purposes, which is too tall to close the top cover of the CDTV as I had to put a lot of extra headers on it for debugging the hardware & firmware). I'm thinking that once Stedy gets an A500-style board done and the bugs are worked out, I can take the schematic and spin a board that will actually FIT inside the CDTV, and have the ram and '020. The CDTV is laid out quite differently than an A500/A2000 and doesn't have a lot of headroom between the PCB and the top cover.

The reason I would like to do that, is that the CDTV only has 1MB of memory. After mounting a 256MB hard disk partition and booting Workbench 1.3, the system only has 713032 free memory (the CD drive is mounted by the system as device CD0: and requires its own filesystem and buffers). So, if you want to do stuff like WHDLoad, there simply isn't enough memory left over.

Also, the minimum run of boards would probably be 50, and I'm not in a position to finance that, neither do I know anyone that would do so. So for just a bare IDE controller, the circuit board alone runs about $150 ($110, actually, plus $40 for international express shipping) 4-layer board) in single quantities. Then (once again, in single quantities) the IC components run about $60. Then, somebody has to solder .4mm pitch 100-pin TQFPs and a 40-pin TSSOP surface mount chip, capacitors, socket, header strips etc. (I have the facilities and skill to do thiis all, but I don't have the cleaning solutions needed to clean the PCB properly...) Once that is done correctly, the firmware gets flashed with the diagnostic firmware, which flashes the CPLD, the board gets tested, then it is flashed with release software and is ready for service.

If things go over well, I'll have a discussion with Zetr0 about who he used for making the PCB, assembling the PCB, his feedback about them, and from there we can decide if we want to go ahead and put the effort into making a board that will fit into the CDTV. It *can* be done, I'm sure.

If I decide to go ahead and spin another iteration anyways, I'll let you know along with the costs for hardware involved.

[Shadowfire]

Here it is, revised again. I optimized my SRAM block copy and PIO block transfer routines to skip some unnecessary checks, and rolled the I/O up into the block functions to avoid any stack overhead. It's a real eye-opener to see how much of a penalty hitting the stack is on the MIPS32 platform (OR the Microchip C32 compiler is crap, I can't tell since this is the first time I've done a project in C or on the MIPS32), even if the stack is in 0 wait state RAM. Now, I'm fairly certain there won't be further improvement without profiling. :)

Performance is going up, and cpu availability is going down.


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 34.0 Normal Video DMA
Device: dh0: Buffers: <information unavailable>
Comments: DiskSpeed 4.2

CPU Speed Rating: 135

Testing directory manipulation speed.
File Create: 24 files/sec | CPU Available: 14%
File Open: 47 files/sec | CPU Available: 9%
Directory Scan: 119 files/sec | CPU Available: 13%
File Delete: 53 files/sec | CPU Available: 6%

Seek/Read: 110 seeks/sec | CPU Available: 11%

[snip … no fast memory tests]

Testing with a 512 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 64951 bytes/sec | CPU Available: 15%
Write to file: 69367 bytes/sec | CPU Available: 15%
Read from file: 70455 bytes/sec | CPU Available: 15%

Testing with a 4096 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 148992 bytes/sec | CPU Available: 42%
Write to file: 177152 bytes/sec | CPU Available: 49%
Read from file: 181760 bytes/sec | CPU Available: 48%

Testing with a 32768 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 213958 bytes/sec | CPU Available: 37%
Write to file: 282624 bytes/sec | CPU Available: 47%
Read from file: 292462 bytes/sec | CPU Available: 46%

Testing with a 262144 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 226544 bytes/sec | CPU Available: 36%
Write to file: 305422 bytes/sec | CPU Available: 47%
Read from file: 317750 bytes/sec | CPU Available: 45%

Testing with a 512 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 65527 bytes/sec | CPU Available: 16%
Write to file: 69623 bytes/sec | CPU Available: 14%
Read from file: 70455 bytes/sec | CPU Available: 15%

Testing with a 4096 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 148480 bytes/sec | CPU Available: 42%
Write to file: 177287 bytes/sec | CPU Available: 49%
Read from file: 181760 bytes/sec | CPU Available: 48%

Testing with a 32768 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 213958 bytes/sec | CPU Available: 37%
Write to file: 282624 bytes/sec | CPU Available: 47%
Read from file: 293700 bytes/sec | CPU Available: 46%

Testing with a 262144 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 225624 bytes/sec | CPU Available: 36%
Write to file: 305422 bytes/sec | CPU Available: 47%
Read from file: 317096 bytes/sec | CPU Available: 45%

Testing with a 512 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 54009 bytes/sec | CPU Available: 12%
Write to file: 35581 bytes/sec | CPU Available: 22%
Read from file: 55417 bytes/sec | CPU Available: 12%

Testing with a 4096 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 68462 bytes/sec | CPU Available: 19%
Write to file: 41808 bytes/sec | CPU Available: 28%
Read from file: 71528 bytes/sec | CPU Available: 19%

Testing with a 32768 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 70637 bytes/sec | CPU Available: 20%
Write to file: 42909 bytes/sec | CPU Available: 28%
Read from file: 74561 bytes/sec | CPU Available: 20%

Testing with a 262144 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 71279 bytes/sec | CPU Available: 20%
Write to file: 42684 bytes/sec | CPU Available: 28%
Read from file: 75019 bytes/sec | CPU Available: 20%

Average CPU Available: 29% | CPU Availability index: 39

[NovaCoder]

Very impressive speeds, better than my 1200 now :(

[AGN]

Shadowfire, could You repost current pic32 code?
I have crazy idea about performance boost and I would like to make concept patch about it.

[Shadowfire]

Uploaded to the zone. Work-in-progress on implementation of the PACKET command (just put the code in last night, untested, yada yada, but its not hooked up yet anyways).

Start your search in idecommands.c in ExecuteCommand()

[AGN]

Ok, here is my idea. It is about reading sectors, but might be used to write them too.

In "ide-commands.c" file we have "ExecuteCommand" function with "case IDECMD_READ:" block where we have two independent parts:
- data is pulled from hdd to buffer (error = _IDE_Read_Sectors(&ide_block_buffer[0], (un...", then
- data is copied from buffer to SRAM (CopySectorToSRAM(&ide_block_b...)

First step is to drop "ide_block_buffer" and push words from hdd directly to SRAM.
This will add some spaghetti to the code and probably won't make it any faster.

But stay cool for now.

After above change we could perform some magic.
In function "_IDE_PIO_GetBlock" there is "while (PORTReadBits(_IDEPORT_IORDY,_" which waits for next word from ide.
Just before that while we could push word (which was read earlier) to SRAM.

What?

We are reading first word from IDE. Then, we ask for another one. Now we should wait for it just like for first one.
But instead waiting we push our first word to SRAM. After that we should wait in this "while" to get next word.
Our "while" will eat less time because when ide was getting next word we were busy with copying to SRAM our first one.

Beware, patch below is only to show what I was thinking about.
It breaks some functions which are called elsewhere.


diff -ur FIRMWARE-20090722/ide-commands.c FIRMWARE-20090722-AGN/ide-commands.c
--- FIRMWARE-20090722/ide-commands.c 2038-01-19 04:14:07.000000000 +0100
+++ FIRMWARE-20090722-AGN/ide-commands.c 2009-07-22 19:33:55.000000000 +0200

! Our "_IDE_PIO_GetBlock" won't use block_buffer anymore

@@ -125,7 +125,7 @@
return IDERESPONSE_OK;
}

-unsigned short _IDE_PIO_GetBlock(unsigned short* block_buffer)
+unsigned short _IDE_PIO_GetBlock(unsigned long SRSectorBufferAddress)
{
unsigned short wordcount;
unsigned char statusregister, errorregister;

! Read first word by hand, then in loop perform our trick
! also remember to push last word to SRAM

@@ -181,14 +181,23 @@
_Negate_DIOW;
_Negate_DMACK;

- for (wordcount = 0; wordcount < 256; wordcount++)
+// read first (0) word from ide - no loop
+
+ _Assert_DIOR;
+ while (PORTReadBits(_IDEPORT_IORDY,_IDEPIN_IORDY)==0); // wait for IORDY line
+ word_from_IDE = (unsigned short)PORTReadBits(IOPORT_D, 0xFFFF);
+ _Negate_DIOR;
+
+ for (wordcount = 1; wordcount < 256; wordcount++)
{
- // Copied/optimized from ReadATARegister16() to reduce stack overhead
- _Assert_DIOR; // assert DIOR
+ _Assert_DIOR;
+ function_which_push_our_word_to_SRAM(SRSectorBufferAddress+(wordcount-1),word_from_IDE);
while (PORTReadBits(_IDEPORT_IORDY,_IDEPIN_IORDY)==0); // wait for IORDY line
- block_buffer[wordcount] = (unsigned short)PORTReadBits(IOPORT_D, 0xFFFF);
- _Negate_DIOR; // finished driving data on bus
+ word_from_IDE = (unsigned short)PORTReadBits(IOPORT_D, 0xFFFF);
+ _Negate_DIOR;
}
+ function_which_push_our_word_to_SRAM(SRSectorBufferAddress+wordcount),word_from_IDE); // our last word
+
return IDERESPONSE_OK;
}


! send SRAM address

@@ -613,7 +622,7 @@
}

// pull blocks in from the hard disk
-unsigned short _IDE_Read_Sectors(unsigned short* block_buffer, unsigned long lba_address, unsigned char targetdevice, unsigned char sectorcount)
+unsigned short _IDE_Read_Sectors(unsigned short* block_buffer, unsigned long lba_address, unsigned char targetdevice, unsigned char sectorcount, unsigned long SRSectorBufferAddress)
{
_LED_ACTIVITY_ON; // Turn on activity LED
_LED_ERROR_OFF;
@@ -673,7 +682,7 @@
WriteATARegister(_REG_COMMAND_REGISTER, _CMD_READ_SECTORS); // Tell device to cough up some data
for (currentblock = 0; currentblock < sectorcount; currentblock++)
{
- error = _IDE_PIO_GetBlock(&block_buffer[currentblock << 8]); // Get a sector of data via PIO
+ error = _IDE_PIO_GetBlock(SRSectorBufferAddress+(currentblock*256)); // Get a sector of data via PIO
if (error != IDERESPONSE_OK) // Did command complete normally?
{
#if __DEBUG
@@ -1039,7 +1048,7 @@
PRINT("\r\n");
#endif
*/
- error = _IDE_Read_Sectors(&ide_block_buffer[0], (unsigned long) commandblock->CB_BLOCK, (unsigned char)commandblock->CB_TARGETDEVICE, (unsigned char)commandblock->CB_LENGTHINSECTORS);
+ error = _IDE_Read_Sectors(&ide_block_buffer[0], (unsigned long) commandblock->CB_BLOCK, (unsigned char)commandblock->CB_TARGETDEVICE, (unsigned char)commandblock->CB_LENGTHINSECTORS, SRSectorBufferAddress);
if (error != IDERESPONSE_OK)
{
#if __DEBUG

! we already copied to SRAM during IDE fetch data

@@ -1053,12 +1062,6 @@
#endif
return;
}
- tempSBAddress = SRSectorBufferAddress;
- for (count = 0; count < commandblock->CB_LENGTHINSECTORS; count++)
- {
- CopySectorToSRAM(&ide_block_buffer[count << 8], tempSBAddress);
- tempSBAddress += 256; // advance 256 words to next sector buffer
- }
commandblock->CB_RESPONSE = error;
return;
case IDECMD_WRITE:


Oh, and most important thing. We should call this with some catchy name.
Interleave isn't cool so maybe 'warp 1' because as we all know star trek is better... ;p

[cv643d]

My friends...

Amazing work, I need to pre-order one! :)

[Shadowfire]

AGN - I'll hook up my logic analyzer and find out if there is, in fact, any time to reclaim there. I suspect there is nothing to be had there (most hard drives are not slouches at posting data from their internal buffer, and most hard drives prefetch the next sector), but I'll do a timing analysis tomorrow and check to see how long the PIC is actually waiting for the next word. It's a good idea, but only will help if the PIC is waiting for more than a few cycles for the data.

[Shadowfire]

Just did some timing analysis. The hard disk I'm testing with never actually de-asserts IORDY, and the data is put on the bus in <<40ns (my logic analyzer shows DIOR low and the data driven on the bus in the same 40ns timeslice) when DIOR is pulled low. ATA spec states that I have to wait for IORDY to be asserted. If I remove that check, I'll probably gain a little, but someone somewhere is going to have a device that wants to delay, and it will blow up for them.

So, essentially, there is no free time there, the controller only executes the delay check once.

On the other hand, seeing that timing information leads me to believe I can recode that section in MIPS32 assembler. But, that is a job for another day - right now, more work on SCSI-direct emulation. HDToolBox is almost running, just got to get it to read drive parameters.

[Shadowfire]

Update: SCSI-direct emulation support for HDToolBox [1.3, 2.0 version] is complete. Partitions can be created within HDToolBox, although the firmware currently lacks RDB support.

[AGN]

So, essentially, there is no free time there, the controller only executes the delay check once.
My first assumption was that HDD is slower than SRAM so we should wait for it.
Alternative plan: SRAM is slower than HDD so we could do same thing in inverted scenario.

But after checking updated code I'm seeing that "CopySectorToSRAM" is now optimized and won't use "WriteDPWord" and his "wait for the busy signal to go away". So our pic32 is slower than SRAM and do not require any waits. Right?

Looks like everything connected to pic32 is fast enough.

...

I'm not good at schematics. Do You have 2 free pins on pic32?
Here is another plan (logic analyzer required):
--- FIRMWARE-20090722/ide-commands.c 2038-01-19 04:14:07.000000000 +0100
+++ FIRMWARE-20090722-AGN2/ide-commands.c 2009-07-23 19:52:31.000000000 +0200
@@ -1039,6 +1039,7 @@
PRINT("\r\n");
#endif
*/
+ set_our_free_pins_to(1,1);
error = _IDE_Read_Sectors(&ide_block_buffer[0], (unsigned long) commandblock->CB_BLOCK, (unsigned char)commandblock->CB_TARGETDEVICE, (unsigned char)commandblock->CB_LENGTHINSECTORS);
if (error != IDERESPONSE_OK)
{
@@ -1053,6 +1054,7 @@
#endif
return;
}
+ set_our_free_pins_to(0,1);
tempSBAddress = SRSectorBufferAddress;
for (count = 0; count < commandblock->CB_LENGTHINSECTORS; count++)
{
@@ -1060,6 +1062,7 @@
tempSBAddress += 256; // advance 256 words to next sector buffer
}
commandblock->CB_RESPONSE = error;
+ set_our_free_pins_to(0,0);
return;
case IDECMD_WRITE:
/*I'm interested in:
- assume that from "11" to "00" is 100% time,
- how much time (in %) pic32 is sitting between "11" to "01"?

Now please try add "inline" flag to these functions:
- _IDE_Read_Sectors
- _IDE_PIO_GetBlock
- CopySectorToSRAM
and tell if it change anything.

Thanks.

[Shadowfire]

SRAM has a 35ns access time [with a 10ns rise/fall time], and more time is spent diddling with the handshake lines than actually reading/writing data. There are no delays in SRAM access, just a check for collisions (The SRAM will assert BUSY* when both devices try to access the same address).

[Shadowfire]

Put the core timer read routines in, and suspended the timing while waiting for the ATA BSY* line. Times are in system clock cycles/2 (80mhz core, 40mhz core timer).



Begin: Interrupt_Received: 0x00000000 <-- core timer initialized
BEGIN:Evaluate_Commands(0) 000002A0 <--- $2a0 cycles to get to Evaluate_Commands(0)
BEGIN:IDE_READ/WRITE_SECTORS(0) 00000022 <--- 34 cycles for evaluating switch
BEGIN:COPY_SECTORS_TO_SRAM(0) 0000454B <---- ReadSectors took this long
END :COPY_SECTORS_TO_SRAM(0) 00007E28 <--- CopyToSRAM took this long.
BEGIN:Evaluate_Commands(1) 00000000
BEGIN:IDE_READ/WRITE_SECTORS(1) 00000000
BEGIN:COPY_SECTORS_TO_SRAM(1) 00000000
END :COPY_SECTORS_TO_SRAM(1) 00000000
END :Interrupt_Received() 00000528
Sector count bank 0 = 0001, bank 1 = 0000 <---- above was for 1 sector read
[snip... post size]
Begin: Interrupt_Received: 0x00000000
BEGIN:Evaluate_Commands(0) 0000029F
BEGIN:IDE_READ/WRITE_SECTORS(0) 00000022
BEGIN:COPY_SECTORS_TO_SRAM(0) 00000A54 <--- wtf? I don't think so!
END :COPY_SECTORS_TO_SRAM(0) 0003F080 <-- copy to sram time
BEGIN:Evaluate_Commands(1) 00000534
BEGIN:IDE_READ/WRITE_SECTORS(1) 00000022
BEGIN:COPY_SECTORS_TO_SRAM(1) 0001CBE6 <-- this is more believable
END :COPY_SECTORS_TO_SRAM(1) 0003F08B <--- copytosram time
END :Interrupt_Received() 000003E2
Sector count bank 0 = 0008, bank 1 = 0008 <---- 8 sectors each queue


Anyways, the copytoSRAM part was initially taking $4f000 cycles for 8 sectors, so (fluky readings aside) I twiddled with the code (bringing a line toggle outside a loop, adding another variable that didn't need casting in the function, etc) and brought it down to $3F000 cycles for 8 sectors. It also has the byte-swizzling code in it, and I suspect that is why it takes so much longer than the PIO read code. The results of the optimization as follows (I moved the controller to an A2000 so I would have a mouse... it has fast RAM, which results in ~4% better speeds than on the CDTV)....


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 34.0 Normal Video DMA
Device: dh0: Buffers: <information unavailable>
Comments: DiskSpeed 4.2

CPU Speed Rating: 139

Testing directory manipulation speed.
File Create: 25 files/sec | CPU Available: 12%
File Open: 48 files/sec | CPU Available: 6%
Directory Scan: 127 files/sec | CPU Available: 7%
File Delete: 55 files/sec | CPU Available: 3%

Seek/Read: 115 seeks/sec | CPU Available: 6%

[snip... fast RAM tests... almost the same as CHIP tests anyways]

Testing with a 512 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 65847 bytes/sec | CPU Available: 11%
Write to file: 72630 bytes/sec | CPU Available: 10%
Read from file: 74614 bytes/sec | CPU Available: 9%

Testing with a 4096 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 154624 bytes/sec | CPU Available: 40%
Write to file: 183808 bytes/sec | CPU Available: 46%
Read from file: 202322 bytes/sec | CPU Available: 42%

Testing with a 32768 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 221184 bytes/sec | CPU Available: 35%
Write to file: 293700 bytes/sec | CPU Available: 45%
Read from file: 348160 bytes/sec | CPU Available: 36%

Testing with a 262144 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 233874 bytes/sec | CPU Available: 34%
Write to file: 317096 bytes/sec | CPU Available: 45%
Read from file: 382087 bytes/sec | CPU Available: 34%

Testing with a 512 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 67511 bytes/sec | CPU Available: 12%
Write to file: 72438 bytes/sec | CPU Available: 11%
Read from file: 75318 bytes/sec | CPU Available: 8%

Testing with a 4096 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 154296 bytes/sec | CPU Available: 40%
Write to file: 183808 bytes/sec | CPU Available: 47%
Read from file: 203343 bytes/sec | CPU Available: 42%

Testing with a 32768 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 221184 bytes/sec | CPU Available: 35%
Write to file: 293080 bytes/sec | CPU Available: 45%
Read from file: 346686 bytes/sec | CPU Available: 36%

Testing with a 262144 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 233874 bytes/sec | CPU Available: 34%
Write to file: 317096 bytes/sec | CPU Available: 45%
Read from file: 382831 bytes/sec | CPU Available: 34%

Testing with a 512 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 55673 bytes/sec | CPU Available: 9%
Write to file: 36860 bytes/sec | CPU Available: 17%
Read from file: 58296 bytes/sec | CPU Available: 6%

Testing with a 4096 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 68462 bytes/sec | CPU Available: 15%
Write to file: 43006 bytes/sec | CPU Available: 21%
Read from file: 74082 bytes/sec | CPU Available: 12%

Testing with a 32768 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 70637 bytes/sec | CPU Available: 16%
Write to file: 43080 bytes/sec | CPU Available: 23%
Read from file: 76702 bytes/sec | CPU Available: 13%

Testing with a 262144 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 71604 bytes/sec | CPU Available: 16%
Write to file: 43448 bytes/sec | CPU Available: 23%
Read from file: 77351 bytes/sec | CPU Available: 13%

Average CPU Available: 26% | CPU Availability index: 36



So, you can see, the optimizations in the SRAM resulted in a gain from 320K to 380K/second.

It seems like I will need to rewrite all these routines in assembler if I want to hit some big numbers. At this point, I think I need to get an RCS system, since some of the optimizations are hit-and-miss.

[AGN]

... I can't tell since this is the first time I've done a project in C or on the MIPS32 ...
Silly question.
Is "-O2" compiler flag set (-O0 is default)?

[Shadowfire]

Can't set that on the free version. Well, not after 60 days, anyways. Will find another machine & do an install to see if that helps. (I totally forgot about the optimization flags, read it when I installed it 8 or 9 months ago...)

Edit: compiled on a newly installed box with -O2. Damn, I'm impressed. 500k/sec is about half way to where I guestimated I would end up on the transfer rates. Still, it is an 80MHz single-cycle-issue RISC chip, and I should be able to get a bit more out of it.


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 34.0 Normal Video DMA
Device: dh0: Buffers: <information unavailable>
Comments: DiskSpeed 4.2

CPU Speed Rating: 139

Testing directory manipulation speed.
File Create: 25 files/sec | CPU Available: 11%
File Open: 49 files/sec | CPU Available: 4%
Directory Scan: 133 files/sec | CPU Available: 3%
File Delete: 55 files/sec | CPU Available: 2%

Seek/Read: 119 seeks/sec | CPU Available: 3%

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 65911 bytes/sec | CPU Available: 13%
Write to file: 72886 bytes/sec | CPU Available: 11%
Read from file: 79862 bytes/sec | CPU Available: 4%

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 169984 bytes/sec | CPU Available: 34%
Write to file: 208384 bytes/sec | CPU Available: 41%
Read from file: 241633 bytes/sec | CPU Available: 32%

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 254862 bytes/sec | CPU Available: 27%
Write to file: 354138 bytes/sec | CPU Available: 36%
Read from file: 443690 bytes/sec | CPU Available: 21%

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 272215 bytes/sec | CPU Available: 25%
Write to file: 390773 bytes/sec | CPU Available: 35%
Read from file: 502311 bytes/sec | CPU Available: 17%

Testing with a 512 byte, MEMF_FAST, WORD-aligned buffer.
Create file: 69475 bytes/sec | CPU Available: 9%
Write to file: 75126 bytes/sec | CPU Available: 8%
Read from file: 79350 bytes/sec | CPU Available: 4%

Testing with a 4096 byte, MEMF_FAST, WORD-aligned buffer.
Create file: 171008 bytes/sec | CPU Available: 34%
Write to file: 207360 bytes/sec | CPU Available: 41%
Read from file: 238050 bytes/sec | CPU Available: 33%

Testing with a 32768 byte, MEMF_FAST, WORD-aligned buffer.
Create file: 253413 bytes/sec | CPU Available: 27%
Write to file: 354843 bytes/sec | CPU Available: 36%
Read from file: 443690 bytes/sec | CPU Available: 21%

Testing with a 262144 byte, MEMF_FAST, WORD-aligned buffer.
Create file: 271714 bytes/sec | CPU Available: 25%
Write to file: 390773 bytes/sec | CPU Available: 35%
Read from file: 502311 bytes/sec | CPU Available: 17%

Testing with a 512 byte, MEMF_FAST, BYTE-aligned buffer.
Create file: 56376 bytes/sec | CPU Available: 8%
Write to file: 38716 bytes/sec | CPU Available: 13%
Read from file: 60920 bytes/sec | CPU Available: 3%

Testing with a 4096 byte, MEMF_FAST, BYTE-aligned buffer.
Create file: 72038 bytes/sec | CPU Available: 12%
Write to file: 45054 bytes/sec | CPU Available: 18%
Read from file: 79024 bytes/sec | CPU Available: 8%

Testing with a 32768 byte, MEMF_FAST, BYTE-aligned buffer.
Create file: 75165 bytes/sec | CPU Available: 12%
Write to file: 46079 bytes/sec | CPU Available: 19%
Read from file: 81920 bytes/sec | CPU Available: 9%

Testing with a 262144 byte, MEMF_FAST, BYTE-aligned buffer.
Create file: 75134 bytes/sec | CPU Available: 13%
Write to file: 46058 bytes/sec | CPU Available: 19%
Read from file: 82495 bytes/sec | CPU Available: 9%

Testing with a 512 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 65911 bytes/sec | CPU Available: 11%
Write to file: 72566 bytes/sec | CPU Available: 11%
Read from file: 79478 bytes/sec | CPU Available: 4%

Testing with a 4096 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 168448 bytes/sec | CPU Available: 34%
Write to file: 204800 bytes/sec | CPU Available: 41%
Read from file: 237538 bytes/sec | CPU Available: 32%

Testing with a 32768 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 255366 bytes/sec | CPU Available: 26%
Write to file: 354138 bytes/sec | CPU Available: 35%
Read from file: 442755 bytes/sec | CPU Available: 20%

Testing with a 262144 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 271714 bytes/sec | CPU Available: 24%
Write to file: 389950 bytes/sec | CPU Available: 33%
Read from file: 497544 bytes/sec | CPU Available: 16%

Testing with a 512 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 68599 bytes/sec | CPU Available: 10%
Write to file: 75254 bytes/sec | CPU Available: 7%
Read from file: 79350 bytes/sec | CPU Available: 4%

Testing with a 4096 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 168960 bytes/sec | CPU Available: 34%
Write to file: 205824 bytes/sec | CPU Available: 41%
Read from file: 237026 bytes/sec | CPU Available: 32%

Testing with a 32768 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 255366 bytes/sec | CPU Available: 25%
Write to file: 354843 bytes/sec | CPU Available: 35%
Read from file: 438693 bytes/sec | CPU Available: 20%

Testing with a 262144 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 271714 bytes/sec | CPU Available: 24%
Write to file: 390773 bytes/sec | CPU Available: 33%
Read from file: 497544 bytes/sec | CPU Available: 16%

Testing with a 512 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 56440 bytes/sec | CPU Available: 8%
Write to file: 38204 bytes/sec | CPU Available: 14%
Read from file: 60344 bytes/sec | CPU Available: 3%

Testing with a 4096 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 70866 bytes/sec | CPU Available: 12%
Write to file: 44682 bytes/sec | CPU Available: 18%
Read from file: 78004 bytes/sec | CPU Available: 8%

Testing with a 32768 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 73571 bytes/sec | CPU Available: 13%
Write to file: 45545 bytes/sec | CPU Available: 19%
Read from file: 80739 bytes/sec | CPU Available: 9%

Testing with a 262144 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 74777 bytes/sec | CPU Available: 12%
Write to file: 45721 bytes/sec | CPU Available: 19%
Read from file: 81495 bytes/sec | CPU Available: 9%

Average CPU Available: 19% | CPU Availability index: 26

[Shadowfire]

I guess the summary of the lessons learned here is: You can optimize anything and gain speed, when the compiler is garbage. ;)

[AGN]

Damn, I'm impressed.
Ok, now I'm famous. When comes "rich" part? ;)

Boring tasks for You:
- post core timer log for -O2
- compile with -O3, benchmark and timer log it
- find better/free compiler
I guess the summary of the lessons learned here is: You can optimize anything and gain speed, when the compiler is garbage.
This could work to our advantage.
Compile with -O0 and optimize code until You get 500KB/s. After that add -O2 and repeat whole process.

[Shadowfire]

I'm going to lay off the optimization for a bit, and deal with autoboot/RDB, and then CD-ROM.

After that, I'll do some further C optimizations to bring everything together in one function. Then I'll rewrite the IDECMD_READ/IDECMD_WRITE sections in MIPS32 assembler, and it won't matter what optimization level the compiler is set at. But we can safely say that we will get at least 500k/second out of it, since that has already been hit.

I think that I'm not going to get too much more out of the 68000/7mhz anyways, since the cpu availability is down to 17%. If I can peg it at 0%, then we will need to wait for actual 68020 boards to be made to find out how fast it can go. Hopefully Ian can design it so that the 68020 runs full-speed cycles on the SRAM (it'd definitely be easier to lump it in with the rest of the $00XXXXXX address space, I do admit), but I don't think anyone would be disappointed in the performance as it is - it's already faster than an A1200, running on a 68000.

Has anyone had experience setting up a CDROM under os 1.3 or 2.0/2.1? More specifically I'm looking for CDROM drivers compliant with these earlier OS's.

[Shadowfire]

OK. Major problem with autoboot.

I got around to reading the autodocs, the RKRM:devices/scsi.devices, and looked at the disassembly of the 1.3 kickstart.

I (incorrectly) assumed that the system would scan my memory for ROMTAGS as I knew that they could be placed in RAM. That's only partially true; what the system actually does, is find & clear memory, scan the OS ROM area ($F00000 - $FFFFFF) for ROMTAGS, builds a list of them (in RAM), then puts a checksum on them. On a warm boot, it will verify the checksums and not rebuild them if they are OK (since that involves a relatively lengthy memory scan). Thus, RAM-based ROMTAGS are possible only on a warm boot.

There are basically two options: a minor hardware redesign (i.e. spin a new board) that has full Autoconfig functionality in the CPLD (which would likely conflict with any expansion device hanging off the A500 the expansion slot); or move the SRAM into ROM space.

Not that my current method is without perils; autonfig I/O boards show up at $e80000, and are assigned by the system to $e90000, $ea0000, etc. so you can only have 6 autoconfig devices in your system (the 7th will mirror up on where my SRAM is located); what's worse, the OS won't be aware of the issue.

The way forward seems clear: change the CPLD to have the SRAM appear at $EF0000 AND $F40000. This will, unfortunately, almost certainly break compatibility with the CDTV* (I will check this out as soon as I can find my keyboard adapter). I cannot just leave it at $F00000 as that memory range would be considered "cacheable" (and I don't want the data cache on when dealing with the I/O!)

OTOH, if it works this way, it could easily also include the code to set up the Fast RAM on the board.

EDIT: YES! It will *not* break on the CDTV, the extended rom is not mirrored there.

[Shadowfire]

... but it will break on a B2000. I would like some feedback from people that have the A500, A500+, and A600. Could you please download the "MON" program from aminet http://aminet.net/dev/moni/mon165.lha, extract the "mon" command onto the machine, and type:

"mon" (start the monitor)
"m f40000" (dump data at the proposed address)

and post the results here please.

Specifically, I'm hoping that these machines don't drive something on the bus at $F40000. Otherwise I need to consider an alternate plan of attack.

[Shadowfire]

More notes...

The standard kickstart 1.2/1.3 ROM scans $FC0000-$FFFFFF (kickstart ROM) and $F00000-$F7FFFF (expansion roms) for ROMTAGS.
Unfortunately, the CDTV expansion ROM alters this. It takes over early on in the boot process, and it scans $FC0000-$FFFFFF (kickstart ROM), $F00000-$F3FFFF (CDTV extended ROM), and $E00000-$E7FFFF (memory slot address space).
This means, the CDTV doesnt pick up the ROMTAG (and will not boot from hard disk) unless the CDTV extended ROMS are disabled via JP15, or the ROM image is patched. I also noticed that the CDTV extended ROMS have quite a bit of unused space. I will speculate and say that this revised scanning (and the presence of the extended ROMS) is the reason that a lot of 68000-plugin devices like the AdIDE won't work wiith the CDTV, at least without disabling the extended ROMS.

Also, it's not 100% sure yet that B2000's are off, I was bitten again by the bug in Xilinx ISE where you can change the schematic, but the changes never get propagated to the VHDL code, and I found out the error after moving my hardware back over to the CDTV (and not finding a mirror image of my RAM at $F40000, hooking up my logic analyzer and not seeing the CPLD responding to those addresses).

IDE controller status:
Hardware - 100% (minor revision to CPLD code)
PIC32 firmware - 95% (only need to debug IDE_PACKET command and perform SCSIDIRECT <-> PACKET translation)
Device driver (mountlist-style) 95% (only need to check that I didn't miss something when CDROM support is considered)
Autoboot Device driver 40% (currently, just links the idedisk.device into the system device list and initializes it. Working on RDB support.)
Edit: RDB support is a total pain in the ass (especially the part about autobooting and filesystems).

[Zetr0]

@Shadowfire

truely an Amazing adventure!

its so close now I can taste it from here!!!

well done indeed!

[Paul_s]

Shadowfire for you;


10 PRINT "I am Cool"
20 GOTO 10


for Ian;


10 PRINT "Dear Boss, Let me play with Amiga stuff at work!!"
20 PRINT "Otherwise I will quit"
30 END

[Stedy]

10 PRINT "Dear boss, can I please play with Amiga hardware
using the equipment @ work?"
20 PRINT "Boss: No that would be a breach of the ethics policy, the code of
conduct policy and is not aligned with our value streams"
30 PRINT "Ian: WTF"
40 PRINT "Boss: go fix some hardware"


On a serious note, I'm currently working on a Video project that has applications on the Amiga. As the day job currently involves working with video, I don't need to re-learn the basics.

For the A600 accelerator design, I will decide soon if I should add in the PATA/IDE design by Shadowfire. As the A600 already has PATA it is not as clear cut a decision as the A500/CDTV option for later.

Ian

[Shadowfire]

Why would you care about adding my IDE controller for a board that only attaches to the A600? It's probably going to add $30 to the cost for the board. While it is a nice design, I hardly think it's worth it unless the existing IDE controller has severe issues.

Status update: source code modified to compile mountlist or rom-based driver by a define, the rom-based driver is scanning RDB sectors atm, (computer is guru'ing afterwards, have to track that down.)

[NovaCoder]

Shadowfire,

When do you think you'll have something for sale, any ideas yet?

Have you tried approaching someone (eg AmigaKit) to see if they want to stock (or even help finance) the end-product?

[Shadowfire]

Short answer is, you can't buy a board from me. You will need to get one from whoever is making the '020 boards, if/whenever that happens.

I'm not in the business of manufacturing or selling boards. I was doing this as a somewhat-work-related-hobby, but when I got laid off I suddenly had a lot more time to devote to it (as evidenced by the progress in the last two months).

Status update: OFS partitions are automounting at boot time. No autoboot/ffs yet. FFS automount is next on the todo list.

[Shadowfire]

Project is on hold, I just place an order for the Developer CD from software hut. I need the Amiga Mail Volume 1 article on the filesystem.resource to continue work here.

Edit: I think I might have enough information in the RKRM:Libraries book.

[Shadowfire]

Compact flash cards & CF adapters arrived today. I'm in the process of formating a 256MB FFS partition at the moment, though (just got FFS partitions to automount) and I need to test & make sure everything's ok with the firmware... before I start throwing CFD's into the mix.

Edit:
Fun Facts:
Space reserved in SRAM for device driver and autoboot code: 6656 bytes ($F42000 - $F439FF)
Space used by latest build of device driver (which automounts foreign partitions): 6232 bytes*

* Includes probably 800ish bytes of debug code.

Edit #2: "Not a Dos disk in device 0". Guess I'll need to do more debugging on the FFS loading code.
Edit #3: It formatted over (and trashed) the RDB. Nice.

[Zetr0]

I would love to publish as abook at some point me thinks. :D

[Shadowfire]

More info: I made some errors in coding (biggest one: walking BPTR's without left shifting them). It seems to be OK now, a quick format of an FFS partition pulled up an "OK" status, I'm doing a full format now to check it out, but all the DOS structures finally seem to be in order (now that I'm parsing the pointers correctly), including the DosEnvironment cylinder/head/sectors parameters, so this time *crosses fingers* it shouldn't clobber the RDB...

Edit: *sigh* clobbered again. Running the format again, this time with the PIC outputting block# requests, that I'm capturing to a text file. This will tell me if the issue is on the Amiga side or the PIC side (atm I think it might be a problem with the PIC code).

[Shadowfire]

Houston, we have a Amiga driver problem. Certainly an easy fix.

This line:
add #8,d0
should read
add.l #8,d0
(assembler default to word size operations)


Write request, length = $1000, block # = $000000000000FEB0
Write request, length = $1000, block # = $000000000000FEB8
Write request, length = $1000, block # = $000000000000FEC0
Write request, length = $1000, block # = $000000000000FEC8
Write request, length = $1000, block # = $000000000000FED0
Write request, length = $1000, block # = $000000000000FED8
Write request, length = $1000, block # = $000000000000FEE0
Write request, length = $1000, block # = $000000000000FEE8
Write request, length = $1000, block # = $000000000000FEF0
Write request, length = $1000, block # = $000000000000FEF8
Write request, length = $1000, block # = $000000000000FF00
Write request, length = $1000, block # = $000000000000FF08
Write request, length = $1000, block # = $000000000000FF10
Write request, length = $1000, block # = $000000000000FF18
Write request, length = $1000, block # = $000000000000FF20
Write request, length = $1000, block # = $000000000000FF28
Write request, length = $1000, block # = $000000000000FF30
Write request, length = $1000, block # = $000000000000FF38
Write request, length = $1000, block # = $000000000000FF40
Write request, length = $1000, block # = $000000000000FF48
Write request, length = $1000, block # = $000000000000FF50
Write request, length = $1000, block # = $000000000000FF58
Write request, length = $1000, block # = $000000000000FF60
Write request, length = $1000, block # = $000000000000FF68
Write request, length = $1000, block # = $000000000000FF70
Write request, length = $1000, block # = $000000000000FF78
Write request, length = $1000, block # = $000000000000FF80
Write request, length = $1000, block # = $000000000000FF88
Write request, length = $1000, block # = $000000000000FF90
Write request, length = $1000, block # = $000000000000FF98
Write request, length = $1000, block # = $000000000000FFA0
Write request, length = $1000, block # = $000000000000FFA8
Write request, length = $1000, block # = $000000000000FFB0
Write request, length = $1000, block # = $000000000000FFB8
Write request, length = $1000, block # = $000000000000FFC0
Write request, length = $1000, block # = $000000000000FFC8
Write request, length = $1000, block # = $000000000000FFD0
Write request, length = $1000, block # = $000000000000FFD8
Write request, length = $1000, block # = $000000000000FFE0
Write request, length = $1000, block # = $000000000000FFE8
Write request, length = $1000, block # = $000000000000FFF0
Write request, length = $1000, block # = $000000000000FFF8
Write request, length = $1000, block # = $0000000100000000
Write request, length = $1000, block # = $0000000100000008
Write request, length = $1000, block # = $0000000100000010
Write request, length = $1000, block # = $0000000100000018
Write request, length = $1000, block # = $0000000100000020
Write request, length = $1000, block # = $0000000100000028
Write request, length = $1000, block # = $0000000100000030
Write request, length = $1000, block # = $0000000100000038
Read request, length = $1000, block # = $000000000000FEB0
Read request, length = $1000, block # = $000000000000FEB8
Read request, length = $1000, block # = $000000000000FEC0
Read request, length = $1000, block # = $000000000000FEC8
Read request, length = $1000, block # = $000000000000FED0
Read request, length = $1000, block # = $000000000000FED8
Read request, length = $1000, block # = $000000000000FEE0
Read request, length = $1000, block # = $000000000000FEE8
Read request, length = $1000, block # = $000000000000FEF0
Read request, length = $1000, block # = $000000000000FEF8
Read request, length = $1000, block # = $000000000000FF00
Read request, length = $1000, block # = $000000000000FF08
Read request, length = $1000, block # = $000000000000FF10
Read request, length = $1000, block # = $000000000000FF18
Read request, length = $1000, block # = $000000000000FF20
Read request, length = $1000, block # = $000000000000FF28
Read request, length = $1000, block # = $000000000000FF30
Read request, length = $1000, block # = $000000000000FF38
Read request, length = $1000, block # = $000000000000FF40
Read request, length = $1000, block # = $000000000000FF48
Read request, length = $1000, block # = $000000000000FF50
Read request, length = $1000, block # = $000000000000FF58
Read request, length = $1000, block # = $000000000000FF60
Read request, length = $1000, block # = $000000000000FF68
Read request, length = $1000, block # = $000000000000FF70
Read request, length = $1000, block # = $000000000000FF78
Read request, length = $1000, block # = $000000000000FF80
Read request, length = $1000, block # = $000000000000FF88
Read request, length = $1000, block # = $000000000000FF90
Read request, length = $1000, block # = $000000000000FF98
Read request, length = $1000, block # = $000000000000FFA0
Read request, length = $1000, block # = $000000000000FFA8
Read request, length = $1000, block # = $000000000000FFB0
Read request, length = $1000, block # = $000000000000FFB8
Read request, length = $1000, block # = $000000000000FFC0
Read request, length = $1000, block # = $000000000000FFC8
Read request, length = $1000, block # = $000000000000FFD0
Read request, length = $1000, block # = $000000000000FFD8
Read request, length = $1000, block # = $000000000000FFE0
Read request, length = $1000, block # = $000000000000FFE8
Read request, length = $1000, block # = $000000000000FFF0
Read request, length = $1000, block # = $000000000000FFF8
Read request, length = $1000, block # = $0000000100000000
Read request, length = $1000, block # = $0000000100000008
Read request, length = $1000, block # = $0000000100000010
Read request, length = $1000, block # = $0000000100000018
Read request, length = $1000, block # = $0000000100000020
Read request, length = $1000, block # = $0000000100000028
Read request, length = $1000, block # = $0000000100000030
Read request, length = $1000, block # = $0000000100000038
Write request, length = $1000, block # = $0000000000010040
Write request, length = $1000, block # = $0000000000010048
Write request, length = $1000, block # = $0000000000010050
Write request, length = $1000, block # = $0000000000010058
Write request, length = $1000, block # = $0000000000010060
Write request, length = $1000, block # = $0000000000010068
Write request, length = $1000, block # = $0000000000010070
Write request, length = $1000, block # = $0000000000010078
Write request, length = $1000, block # = $0000000000010080
Write request, length = $1000, block # = $0000000000010088
Write request, length = $1000, block # = $0000000000010090
Write request, length = $1000, block # = $0000000000010098
Write request, length = $1000, block # = $00000000000100A0
Write request, length = $1000, block # = $00000000000100A8
...


Autoboot driver status: 80%. RDB support done, may need minor tweaking/fixes, but mounts OFS and FFS partitions. Only need to tackle autoboot (probably on Monday), this will involve spoofing an expansion board, and ohmygod am I getting low on driver space in SRAM. I might need to go back and optimize some sections for code size if autoboot turns out needing more space than is left, and see if I can cut out some functionality of the LoadSeg code.

Edit: Uncommenting all my debug code caused the driver to hang. Fortunately, I realized I had forgotten to Forbid() and Permit() while walking the resource list and inserting it. The time spent doing serial I/O apparently caused other tasks going on at the same time to get a time slice... and when I removed the serial I/O comments, it resulted in a crash because of what I was doing.

Almost all debug code commented out, down to 5288 bytes, system is stable, automounts OFS and FFS partitions under 1.3. Time to commit changes and call it a night.

[Shadowfire]

It's easy to see why CF adapters cause so much problems that there are several threads about it in other topics. Bad news. It's not the CF adapters that cause the issues.

It's the ATA electronics / firmware in the controller on the CF cards themselves.

Apparently they were never tested in master/slave configurations. The first card I tested, a Lexar 256MB 4X Compact Flash, seemed ok, but when I ran through the drive identification, I was getting a bunch of gobbledygook from the IDENTIFY_DEVICE on the slave [which should have failed out with no data to transfer].

The ATA specifications states that a master can respond for a nonexistent slave in limited circumstances (I guess this is to speed up drive detection). It must not respond to any commands addressed to the slave* (* it will only respond to global reset commands), which should be the definitive method of determining if a slave is present (no response to commands).

The Lexar, however, will happily assert the IORDY line after the IDENTIFY_DEVICE command is issued to the other, nonexistent device, and the IDENTIFY_DEVICE buffer will fill with garbage (basically, whatever value the IDE bus is currently sitting on) instead of timing out for IORDY (which happens correctly when only the Western Digital IDE drive sits in the master position).

I don't think that this would be an issue in cameras and cardreaders which never expect the card to be anything other than the master, and the only thing on the bus. However, on an IDE controller, it's a huge issue.

The Lexar may potentially cause issues when used with another device on the bus.

[Shadowfire]

This is a "Canon 32MB High Speed Compact Flash" card.

The first thing you'll notice is that it is a rebadged SanDisk SDCFB-32. It worked fine as either the master, or as a slave with the hard disk present as master. No changes were needed to get this to work.

Dump of the IDENTIFY_DEVICE packet follows.

1
Device 1 selected.
HI0: Host Idle State
>i
Identify IDE Device
Drive Model number [27]: SanDisk SDCFB-32
Firmware Revision [23]: HAD 2.13
Serial Number [10]: 101821A1804H0638
Number of cylinders [1]: 0x01EA
Number of heads [3]: 0x0004
Number of sectors/track [6]: 0x0020
Number of sectors [57]: 0x0000F500
User addressable sectors [60]: 0x0000F500
Selected sector addressing mode is LBA.
0000:8A 84 EA 01 00 00 04 00 00 00 40 02 20 00 00 00 ----------@- ---
0010:00 F5 00 00 20 20 20 20 30 31 38 31 31 32 31 41 ---- 0181121A
0020:30 38 48 34 36 30 38 33 02 00 02 00 04 00 41 48 08H46083------AH
0030:20 44 2E 32 33 31 61 53 44 6E 73 69 20 6B 44 53 D.231aSDnsi kDS
0040:46 43 2D 42 32 33 20 20 20 20 20 20 20 20 20 20 FC-B23
0050:20 20 20 20 20 20 20 20 20 20 20 20 20 20 01 00 --
0060:00 00 00 03 00 00 00 02 00 00 03 00 EA 01 04 00 ----------------
0070:20 00 00 F5 00 00 00 01 00 F5 00 00 00 00 04 04 ---------------
0080:03 00 78 00 78 00 78 00 78 00 00 00 00 00 00 00 --x-x-x-x-------
0090:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00A0:00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00B0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00C0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00D0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00E0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00F0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0100:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0110:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0120:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0130:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0140:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0150:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0160:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0170:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0180:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0190:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01A0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01B0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01C0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01D0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01E0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01F0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------

[Shadowfire]

A lot of problems with corruption, missing partitions etc. I just traced back to the FastFileSystem that ships with 1.3. Updating to the 3.1 FFS seems to have solved a lot of those problems, probably dealing with how the FS copes with the somewhat arbitrary data on the disk when it first gets mounted.

[Shadowfire]

This is a Lexar 256MB compact flash card. As a master, it incorrectly sits IORDY on the bus during an identify of the other device on the bus.

After I added the workaround code to read() after an identify(), it worked as the master. It also, surprisingly, worked as the slave with an IDE hard disk attached as master.


>1
Device 1 selected.
HI0: Host Idle State
>i
Identify IDE Device
Drive Model number [27]: LEXAR ATA FLASH
Firmware Revision [23]: V1.00
Serial Number [10]: 11523613329699098079
Number of cylinders [1]: 0x03D8
Number of heads [3]: 0x0010
Number of sectors/track [6]: 0x0020
Number of sectors [57]: 0x0007B000
User addressable sectors [60]: 0x0007B000
Selected sector addressing mode is LBA.
0000:8A 84 D8 03 00 00 10 00 00 40 00 02 20 00 07 00 ---------@-- ---
0010:00 B0 00 00 31 31 32 35 36 33 33 31 32 33 36 39 ----112563312369
0020:39 39 39 30 30 38 39 37 02 00 02 00 04 00 31 56 99900897------1V
0030:30 2E 20 30 20 20 45 4C 41 58 20 52 54 41 20 41 0. 0 ELAX RTA A
0040:4C 46 53 41 20 48 20 20 20 20 20 20 20 20 20 20 LFSA H
0050:20 20 20 20 20 20 20 20 20 20 20 20 20 20 04 00 --
0060:00 00 00 02 00 00 00 02 00 00 03 00 D8 03 10 00 ----------------
0070:20 00 00 B0 07 00 00 01 00 B0 07 00 00 00 00 00 ---------------
0080:03 00 00 00 00 00 78 00 78 00 00 00 00 00 00 00 ------x-x-------
0090:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00A0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00B0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00C0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00D0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00E0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00F0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0100:00 00 D0 75 75 00 00 A8 B8 75 78 00 74 01 F6 55 ---uu----ux-t--U
0110:F4 08 00 B8 08 FA F5 F4 E6 F0 F0 B5 F4 10 F0 F5 ----------------
0120:B8 08 F5 00 01 78 55 B4 74 E6 01 00 00 65 55 74 -----xU-t----eUt
0130:65 01 C0 90 74 4D F0 55 F0 75 30 20 D9 0D C3 CD e---tM-U-u0 ----
0140:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0150:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0160:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0170:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0180:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0190:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01A0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01B0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01C0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01D0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01E0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01F0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
HI0: Host Idle State
>

[Shadowfire]

This is the analysis for a Generic memory card, labelled as in this post's title, ordered off of e-bay from a seller in Hong Kong.
The back of the unit says "9930406-006.A00 P743580X02".

This device was logically well behaved. It worked fine as the master, and as the slave with a hard disk attached as the master.

Electrically, though, it pulls up to 3.3V on the DASP* line instead of the 5V that it is being fed, and the LED on the compact flash adapter (which is biased at the 5V being supplied at the floppy power connector) never completely went off. It shouldn't be an issue because of the series resistor on the LED, but it could potentially cause a blowout of the card if the 5V is allowed to backfeed into its internal 3.3V supply. The voltage however, was stable @ 3.3v so this card gets a pass.


1
Device 1 selected.
HI0: Host Idle State
>i
Identify IDE Device
Drive Model number [27]: TPX-CFT-2GB
Firmware Revision [23]: Ver2.31
Serial Number [10]: 88540797150000002251
Number of cylinders [1]: 0x0F45
Number of heads [3]: 0x0010
Number of sectors/track [6]: 0x003F
Number of sectors [57]: 0x003C1FB0
User addressable sectors [60]: 0x003C1FB0
Selected sector addressing mode is LBA.
0000:4A 04 45 0F 00 00 10 00 00 7E 00 02 3F 00 3C 00 J-E------~--?-<-
0010:B0 1F 00 00 38 38 34 35 37 30 37 39 35 31 30 30 ----884570795100
0020:30 30 30 30 32 32 31 35 02 00 02 00 04 00 65 56 00002215------eV
0030:32 72 33 2E 20 31 50 54 2D 58 46 43 2D 54 47 32 2r3. 1PT-XFC-TG2
0040:20 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20 B
0050:20 20 20 20 20 20 20 20 20 20 20 20 20 20 01 00 --
0060:00 00 00 03 00 00 00 02 00 00 07 00 45 0F 10 00 ------------E---
0070:3F 00 B0 1F 3C 00 00 01 B0 1F 3C 00 00 00 07 04 ?---<-----<-----
0080:03 00 78 00 78 00 78 00 78 00 00 00 00 00 00 00 --x-x-x-x-------
0090:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00A0:00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ----------------
00B0:3F 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 ?----------@----
00C0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00D0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00E0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
00F0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0100:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0110:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0120:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0130:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0140:00 00 00 00 00 00 92 00 00 00 00 00 00 00 00 00 ----------------
0150:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0160:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0170:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0180:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
0190:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01A0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01B0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01C0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01D0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01E0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
01F0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------------
HI0: Host Idle State
>

[Shadowfire]

Status Report: Autoboot, automount device driver: 100%.
It just booted off of a CF card. Just need to yank all the debug code and retest.
And, there's about 1K left to stuff more initialization code in.
Semi-final firmware uploaded to the Zone.

[Zetr0]

:bowdown

just too damn impressive shadowfire!!!!

[Shadowfire]

.. And, I just go in the email, that I'm going to get my Developer CD tomorrow. A day late & a dollar short :P

[Zetr0]

@Shadow Fire

what is this "developer cd" you mention

I have an absolute ton(e) of resources and such like for the amiga, I have not heard of it.

please prey-tell what mystical arcane information does it contain?

[Shadowfire]

The OS3.5 developer CD. It has old Amiga Mail articles in it (along with a bunch of other stuff). I found enough information to do it, scattered around in 7 or 8 different places in the various 2.0 RKM's, though.

[Jope]

Indeed, this is why we have the CF Card Compatibility list thread here.

I've had lots of bad luck with those old Canon 8MB and 32MB cards from years ago. They seem to work ok in PCMCIA mode, but not in IDE mode. :-)

[Shadowfire]

Kickstart 3.1 ROMS and OS3.9 CD are on their way to me now. I guess the target for CDROM emulation will be CacheCDFS, since that is what ships with the OS.

[Shadowfire]

The OS3.9 distribution comes on CD-ROM. You would think that it wouldn't be that hard to get it onto the hard disk of a CDTV, right? .... Well, it just happens that in order to use OS3.9, you need to have Kickstart 3.1. And the CDTV extended ROMS are incompatible with anything other than 1.3. Which means, you need to disable the extended ROMS (and therefore, the builtin CD-ROM) to boot the machine.

So... I made a mistake. The first thing I did when I got my package was yank out 1.3, install 3.1, and check to make sure I was still autobooting. Bingo, everything is still working. Except, I'm getting scrambled characters every once in a while.

To make a long story short, I played musical Fat Agnus chips yesterday among several machines (KO'ing my Amiga 3000 in the process). I ended up putting the 8370 OCS agnus in the CDTV, and the 8372A ECS agnus in the A2000. Big mistake. All my problems disappeared after I discovered my error and swapped the Agnus chips back.

After spending the better part of the day sending OS 3.9 over a serial link, I now have an OS3.9 installation on my CDTV's hard disk. (Of course, in retrospect, swapping the 1.3 ROM back in, copying files from the internal CDROM and swapping 3.1 back in would have taken about 8 fewer hours. Hindsight is always 20/20).

Well, it would be an OS3.9 installation, except I had to comment out almost everything in the startup-sequence. Having done that, the CDTV now boots with a generous 500K of free RAM.

Which (knock on wood) should be enough for me to get CD-ROM support working.

[Toni Wilen]

The OS3.9 distribution comes on CD-ROM. You would think that it wouldn't be that hard to get it onto the hard disk of a CDTV, right? .... Well, it just happens that in order to use OS3.9, you need to have Kickstart 3.1. And the CDTV extended ROMS are incompatible with anything other than 1.3. Which means, you need to disable the extended ROMS (and therefore, the builtin CD-ROM) to boot the machine.


Perhaps I missed something important but why not just update CDTV ROMs to 2.7? (or 2.30 but it is meant for A570)

[Photon]

Sounds awesome! Grabbed the Zoned stuff. You seem determined, so I think there will be a lot of Amiga owners that will be happy :) If the price is right it could be an off-the-shelf entry add-on for ClassicWB, WHDload and the like...

Any idea about time until there's a design ready for production and/or a contract with someone making it? And also if there will be a version with surface mount 68000 piggyback or a DIL version as well?

[Shadowfire]

Perhaps I missed something important but why not just update CDTV ROMs to 2.7? (or 2.30 but it is meant for A570)

(lack of) resources?

[Shadowfire]

Getting pretty close on CDROM support. I can issue a list and see a bunch of the files on the OS3.9 CD, but it looks like the filesystem eventually guru's out (it appears to keep reading/caching parts of the ISO, and crashes soon after LIST starts spitting out data).

More testing is in order, obviously, but I'll say its 70% of the way done.

Edit: it might actually be workbench crashing the machine

[Photon]

A lot of problems with corruption, missing partitions etc. I just traced back to the FastFileSystem that ships with 1.3. Updating to the 3.1 FFS seems to have solved a lot of those problems, probably dealing with how the FS copes with the somewhat arbitrary data on the disk when it first gets mounted.

ps. That sounded very "tested and official" and could start rumors. Can you confirm which machines you have trouble on and what procedure led up to it?

[Shadowfire]

The IDE controller has been tested (and works) in an A500, a B2000, and a CDTV.
The bootup guru problems I was having were indeed caused by the 1.3FFS. Updating to the 3.1FFS allowed the partitions to validate properly (but afterward the first successful boot, you will want to revert to the 2.1/2.0 FFS if you are still running Kickstart 1.3, as the 3.1FFS shows an extra icon on 1.3 Workbench as "DOS1").

CDROM support is still being worked on. I'm having a tough time tracking down the culprit responsible for the guru's, and I will probably need to acquire a full 68030 (non-EC version) accelerator for the B2000 (so I can run Enforcer) to track down the problems.

[Shadowfire]

OK... the last 2 days have had me pulling out my hair, but I finally have some results. My biggest problem was not allowing enough stack on the CDROMFILESYSTEM driver. Once I hooked up TNT, that was found & I had to sort a bunch of other things out.

Limitations:
Mode 1 discs (2048 bytes/sector) only. This is unlikely to ever go away.
CDROMFILESYSTEM support only, no CacheCDFS support yet. (More work needed here)
No CDROM commands supported (Play audio, etc).
DISKCHANGE not supported. Code is in there, but machine may reboot, so it's not ready for prime time yet.

Updates:
You can actually mount and access a CDROM.
Numerous bug fixes to PIC32 and device driver firmware, including a better ATA reset routine that fixed some nagging issues when having 2 devices on the cable.

At this point I can mount and access the CDROM, and the icons show up on Workbench. It should allow you to install OS3.9 off of CD, and access data on other CD's.

[NovaCoder]

At this point I can mount and access the CDROM, and the icons show up on Workbench. It should allow you to install OS3.9 off of CD, and access data on other CD's.

Well that's better than I ever managed with my external PCMCIA CDROM drive, well done! :D

[Shadowfire]

Automatic diskchange support added. The PIC will monitor CDROM drives for diskchanges and inform the Amiga of them. Support added for this in the driver. I need to do a bit more exhaustive testing on this, but it seems to be working fine.

Edit: Tested, latest firmware uploaded to the zone.

[Shadowfire]

I spent a decent amount of time yesterday & today optimizing the hard disk access routines on the PIC32. First, I translated most of the abstraction functions into direct hardware accesses. Then I cut most of the debug code out and moved most of the time-critical code into 0 wait state RAM. Satisfied that there was really not much more I could do on my end, at least mucking with the C source code, I pulled down some Diskperf numbers before enabling optimizations in the C32 compiler. (Compiled with -O0)


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 40.63 Normal Video DMA
Device: dh0: Buffers: 30
Comments: DiskSpeed 4.2

CPU Speed Rating: 136

Testing directory manipulation speed.
File Create: 28 files/sec | CPU Available: 11%
File Open: 45 files/sec | CPU Available: 13%
Directory Scan: 141 files/sec | CPU Available: 0%
File Delete: 72 files/sec | CPU Available: 0%

Seek/Read: 121 seeks/sec | CPU Available: 3%

[fast mem tests snipped... almost the same as chip mem results]

Testing with a 512 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 71552 bytes/sec | CPU Available: 1%
Write to file: 83520 bytes/sec | CPU Available: 0%
Read from file: 84544 bytes/sec | CPU Available: 1%

Testing with a 4096 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 250368 bytes/sec | CPU Available: 19%
Write to file: 294400 bytes/sec | CPU Available: 22%
Read from file: 313856 bytes/sec | CPU Available: 17%

Testing with a 32768 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 472184 bytes/sec | CPU Available: 7%
Write to file: 571297 bytes/sec | CPU Available: 9%
Read from file: 510087 bytes/sec | CPU Available: 16%

Testing with a 262144 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 594359 bytes/sec | CPU Available: 1%
Write to file: 714642 bytes/sec | CPU Available: 1%
Read from file: 570567 bytes/sec | CPU Available: 16%

Testing with a 512 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 71552 bytes/sec | CPU Available: 1%
Write to file: 83392 bytes/sec | CPU Available: 0%
Read from file: 84160 bytes/sec | CPU Available: 1%

Testing with a 4096 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 253952 bytes/sec | CPU Available: 19%
Write to file: 292864 bytes/sec | CPU Available: 22%
Read from file: 312832 bytes/sec | CPU Available: 17%

Testing with a 32768 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 475136 bytes/sec | CPU Available: 7%
Write to file: 571297 bytes/sec | CPU Available: 9%
Read from file: 510087 bytes/sec | CPU Available: 16%

Testing with a 262144 byte, MEMF_CHIP, WORD-aligned buffer.
Create file: 591536 bytes/sec | CPU Available: 1%
Write to file: 716418 bytes/sec | CPU Available: 1%
Read from file: 569878 bytes/sec | CPU Available: 17%

Testing with a 512 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 56960 bytes/sec | CPU Available: 1%
Write to file: 35520 bytes/sec | CPU Available: 19%
Read from file: 62016 bytes/sec | CPU Available: 1%

Testing with a 4096 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 79360 bytes/sec | CPU Available: 3%
Write to file: 32363 bytes/sec | CPU Available: 38%
Read from file: 42144 bytes/sec | CPU Available: 47%

Testing with a 32768 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 80244 bytes/sec | CPU Available: 5%
Write to file: 32230 bytes/sec | CPU Available: 40%
Read from file: 39164 bytes/sec | CPU Available: 53%

Testing with a 262144 byte, MEMF_CHIP, BYTE-aligned buffer.
Create file: 81352 bytes/sec | CPU Available: 6%
Write to file: 32699 bytes/sec | CPU Available: 39%
Read from file: 38931 bytes/sec | CPU Available: 53%

Average CPU Available: 14% | CPU Availability index: 19


I went ahead and turned on C compiler optimizations, and promptly received Amiga read/write errors. I initially thought I had found an issue with the PIC32 IO port hardware, but the truth is far more insidious.... http://www.microchip.com/forums/tm.aspx?m=440800 (it's an interesting read if you're thinking about tuning code on a semi-modern processor and want to see a train wreck in progress).

To make a long story short, there will be no optimized C version, as the C compiler groups all memory reads/writes in a row, and I have no way of inserting wait states. That means this is the semifinal performance (really, I swear this time) until the great Assembler rewrite, since I need to be able to control memory timing (the PIC will drive memory too fast & miss the data with my current program).

[gizmomelb]

Shadowfire - awesome work!

would this work (and autoboot) in a stock standard Workbench 1.3 A500?


EDIT: ahh I missed the post on the 11th of August above:

"The IDE controller has been tested (and works) in an A500, a B2000, and a CDTV.
The bootup guru problems I was having were indeed caused by the 1.3FFS. Updating to the 3.1FFS allowed the partitions to validate properly (but afterward the first successful boot, you will want to revert to the 2.1/2.0 FFS if you are still running Kickstart 1.3, as the 3.1FFS shows an extra icon on 1.3 Workbench as "DOS1")."

so it appears it does, wow!

[alanh]

Are the schematics/specs for this available ? I can't see to locate anything in this thread.

Thanks.

[AGN]

Testing with a 262144 byte, MEMF_CHIP, LONG-aligned buffer.
Create file: 594359 bytes/sec | CPU Available: 1%
Write to file: 714642 bytes/sec | CPU Available: 1%
Read from file: 570567 bytes/sec | CPU Available: 16%

That means this is the semifinal performance (really, I swear this time)....
Writing faster than reading by 140KB/s?
Read and write path are optimized same way?

[Photon]

Seems you're reading with the CPU, why use chipmem as buffer?

[Shadowfire]

Alanh - I will post current schematics/firmware in the Zone. Be advised that the schematics are slightly different than the prototype I am using, so "dpram-iopins.h" needs some minor modification (it should be pretty obvious by the comments and the schematic, specifically PIC_INT and PIC_A11 lines need to be swapped in the firmware. The optimized code sections will also need to be changed to reflect the new port/pin#.). The new schematic also corrects an error in IDE termination.

Gizmo- Yes, it is compatible with KS 1.3. It requires KS1.3+. I have tested it with KS1.3, KS2.0 & KS3.1.

AGN-execution paths are different for read & write.

Also, there is currently some CDROM wackiness I need to look into (An AOPEN cdrom drive, which works properly, returns different sector data than a LITE-ON CDROM. As a result, a lot of burned discs show up as "no disk in drive" when using the LITE-ON. I need to do a bit more research into this before I can fix it.

Photon: Performance difference between chip & fast on a 68000 is < 1%. Chip mem transfers wont be slower until you go >16 colors in a lo-res screen or >4 colors in a hires screen, and the chips start stealing cycles from the CPU - then fast memory will be faster. The PIC32 acts as a coprocessor in performing the IDE handshaking and transfers, and places data into some dual-port SRAM. The SRAM is located outside of custom chip memory space, and is therefore subject to FAST ram access behavior from the Amiga's perspective

OTOH on a 68010+, the device driver will invoke the processor's loop mode and definitely should be faster. I'm waiting on a bank transfer to paypal atm to pay for a 68030 accelerator (needed for OS3.9 testing), so I will post some more numbers then.

UPDATE: Files are posted to The Zone. See this help topic for access: http://eab.abime.net/faq.php?faq=vb_faq#faq_thezone_faq_item

8/18: Added fix for LITE-ON DVD drive firmware issues. These drives have problems when dealing with multiple sector read requests, I/O must be split up to request individual sectors.

[Shadowfire]

*****JTAG programming is NOT supported with this version, you will have to modify the schematic before spinning the board if you need to program with JTAG instead of ICSP. It will probably be less of a headache to get a cheap ICD2 to program the board, than rework the schematic ensuring that everything will work with the PIC32 JTAG lines, since the JTAG lines are all used for other functions.

I've done some testing with the latest revision of the software, and I'm going to give an official thumbs-up to the implementation, as I've had no issues with it. For those of you that want to build one, this is your green light. Contact me at gwdoiron@hotmail.com if you have any issues getting it up and running.

You will need:
1. PCB and parts (obviously), and some advanced soldering skills. The PIC32 is a 100-pin TQFP with .4mm pitch, the SRAM is a 100-pin TQFP with .5mm pitch. The level shifter has similarly small pitches, as well as the resistor networks (which you can ditch and use SM 0805's as they are cheaper, but take up more board space).
On my implementation, I placed the XC9536 underneath the 68000 socket, which meant I needed to solder the XC9536 before soldering in the socket, since I would not have much room to manipulate the XC9536 if I did thing the other way around. In otherwords, think about what order you need to solder things in. I recommend first installing all capacitors then checking for shorts on the +3.3V and +5V sides with a meter, installing U6 & J5 and doing the bench power supply test (see below, you should have no real current draw at this point), then adding SM IC's one at a time checking again after each IC has been soldered and inspected (and reworked if necessary).
Be advised that as a general rule of thumb, most chips do not have protection against short circuits or incorrect placement. So check those surface mount chips 2 or 3 times with at least 8x magnification before applying power to the board!
I recommend using a benchtop power supply connected to J5 set at 5V, 200mA. If you crowbar your power supply, immediately remove power and fix the short. When operating properly (without a 68000 installed) the unit should draw ~130mA. Do not install in an Amiga until you feel that the board is OK.
Last but certainly not least, remember ESD protection.

2. A programmer that can program a Microchip PIC32 device, and the included .HEX file for programming. AFAIK, the Promate3, ICD2, ICD3 and REAL ICE all program the PIC32. Other 3rd party programmers which claim PIC32 compatibility should work if they program via the ICSP lines. JTAG programming is NOT supported by the design, nor have I tested JTAG programming.

3. At the moment, you need to be able to send an ASCII 'x' code to UART1 on the PIC @ 19200 baud to tell it to flash the CPLD. If anyone is actually going to make the board (and make it without the debug UART interface), send me an email and I'll write up a modified firmware to have the PIC flash the CPLD and run SRAM tests & flash out the results on the LED's. (This is obviously going to be needed for the board we are doing, I just haven't gotten around to it yet, and knowing someone will need it soon will get me to doing this boring-yet-necessary task done sooner). If the CPLD isn't flashed, the Amiga will have no way to access the SRAM, and it won't be of a lot of use to you. If you can program the Xilinx part before putting it on, the .xsvf and .jed files are included in the Xilinx package. MAKE SURE to get the latest release that was put on the Zone.

4. Drivers: The device driver is embedded in the PIC32 firmware, which is presented to the Amiga in the SRAM @ $F42000/mirrored @ $EF2000. The idedisk.device is the actual device driver for disk access. It also presents the idedisk-rdb.resource, which scans the attached hard disks for partitions, mounts them, and makes them bootable if so marked. The idedisk-rdb.resource is highly likely to crash the machine on 1.2. I need to add an OS-check to the ROM startup routines and fail them out on 1.2 so that you can use the disk-based idedisk.device to mount your hard disk partitions from a boot floppy (TBD).

**** WHAT THE IDE CONTROLLER IS ****
The IDE controller is model # GWDOIR0001, an IDE coprocessor for the Amiga series of personal computers, based around the Microchip PIC32 microcontroller, Cypress SRAM, and a Xilinx CPLD.
It is a full-featured (read: Commercial Quality) IDE controller, with support for Hard Disks, CD-ROM drives, and Compact Flash cards. It supports automatic CD-ROM changedisk notification, meaning that insertion/removal of a CD is passed onto the operating system.
It is quite fast for a stock 68000 based machine and can attain reads of 500k/s and writes of 700k/s on hard disks or compact flash cards.
Standard ATA protocols with regards to master/slave settings apply (1 master, 1 slave).
The device driver is very system-friendly and will not hog the cpu*. (* During reset, the driver will busy-wait while the IDE controller resets the devices and waits for them to come online)
**** WHAT THE IDE CONTROLLER ISN'T ****
In its current incarnation, it is not a ram expander, an accelerator, or any other type of peripheral controller.
It has not been extensively tested by any means. Only a limited sample of hard disks, CDROM drives, and CF cards have been tested. Even with my limited sampling, workarounds to the standard ATA protocol were necessary for one of the CDROM drives and one of the flash cards I tested. If you have a device that doesn't work, and don't have the equipment/expertise yourself to determine why, you will need to send it to me so that I can hook it up to my prototype and find out why, and add a workaround to the firmware, if possible. Note that some devices could have implementations broken so horribly, that 'fixing' them would break other things.
It does not support ATA command tag queueing, this means that CDROM accesses will hog the bus and lock out your hard disk for however long it takes the CDROM to complete the command.
It does not pass on diskchange notifications if you remove a flash card. Due to the way the AmigaOS works, and a general lack of protections inside the OS for this sort of thing (a collection of hard disk partitions != a floppy disk, the possibility of alternate file systems which were written for fixed discs suddenly having their media removed, etc), changing out a hard disk partition is a Bad Thing. I thought about this long and hard before making this decision. (It could be done but would work only in very specific configurations.== SUPPORT NIGHTMARE HELLHELLHELL)

[Shadowfire]

8/20: SRAM access and block copy functions rewritten in MIPS32 assembler. Overall performance improvements of 7%-10%.

[Zetr0]

@Shadowfire

your like a machine man!

some awesome stuff, something tells me you are really enjoying it!

[gizmomelb]

Shadowfire - firstly many thanks for such hard work and dedication to addressing such an age old issue (auto booting IDE for A500) and secondly thanks for SHARING your time and effort with the Amiga community.

so what's next? I don't suppose you've got any interest in floppy drive emulation and protection and want to check out the Cyclone 20 project - http://eab.abime.net/showthread.php?t=40959

;)

[Shadowfire]

The SRAM functions have been rewritten in MIPS32 assembler. Select portions of the IDE functions (Register reads, register writes, and block PIO transfers) have been rewritten in MIPS32 assembler. The C code is still being compiled without any optimizations - it doesn't matter on the current system, free 68000 CPU for copying data is approaching 0%.

I don't think theres an awful lot of performance left to squeeze out of this system.

Edit: Found some stability issues when I hooked the CFA's back up. Went back and checked the IDE bus, I seem to have ~50ns rise times on the I/O lines with the termination on the prototype board. I did some cycle counting, added some NOP's and reordered some instructions, making sure no PIO4 timings were violated, and accounting for the horrendous signal rise times. CFA's are working again. Max. read speed went from 692k/s to 682k/sec.

I also found out that CFA's *always* peg the BSY* bit for >>20us after a read command is issued, while a hard disk (if it hits its cache) has the ability to reply much faster. Despite what some people here are putting forward about the speed of compact flash drives, the more I work with them, the less I like them, and I will definitely be using hard disks in my own Amiga systems. I will tolerate the power and heat for the performance. All the CFA's I tested aren't very suitable for a partition that you will be writing to with any frequency; because AmigaDOS (at least the older versions) does not typically do this, you can probably get away with it as a system drive, as long as you don't do any work on it (I would not set up a compiler/development system on a flash drive partition, for instance; definitely go with a hard disk instead. Also, you'd be crazy to try and write large A/V files to a flash drive.).

I should note that the above is somewhat subjective in nature, perhaps I'll post some Diskspeed numbers to drive the point home.

[Shadowfire]

Shadowfire - firstly many thanks for such hard work and dedication to addressing such an age old issue (auto booting IDE for A500) and secondly thanks for SHARING your time and effort with the Amiga community.

so what's next? I don't suppose you've got any interest in floppy drive emulation and protection and want to check out the Cyclone 20 project - http://eab.abime.net/showthread.php?t=40959

;)

The cyclone project doesn't really interest me (I did a bit of reading on it, mind you). I've found that most of my original old disks are, in fact, already bad.

[Shadowfire]

All tests were performed on an A2000, 512chip/512k slow-fast/2MB fast memory, stock clocked 68000 NTSC system. All tests were on partitions of 200-256mb, except for the Canon, which was 32MB. All partitions were empty, except for the hard disk's partition, which had already had a modified 3.1 Workbench image on it. All tests were performed with the 3.1 ROM FFS.

The CFA cards didn't perfom as poorly as I initially thought they would, but they obviously can't respond to data requests fast enough to sate even the bog standard 68000 in this system, as the 3 year old notebook hard disk can. The problem will be compounded if you move to a faster processor.

In what can only be described as a bizarre twist on what you'd expect, the oldest and least capacious card tested (32MB Canon) with its SanDisk firmware turned out to be the quickest of all flash drives tested, and if I needed to use a flash drive on this system, this card would be my choice.


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 40.63 Normal Video DMA
Device: dh0: Buffers: 30
Comments: DiskSpeed 4.2 - WD600VE-08HD Scorpio 2.5" 5200rpm IDE Hard Disk

CPU Speed Rating: 136

Testing directory manipulation speed.
File Create: 31 files/sec | CPU Available: 3%
File Open: 50 files/sec | CPU Available: 0%
Directory Scan: 150 files/sec | CPU Available: 0%
File Delete: 71 files/sec | CPU Available: 0%

Seek/Read: 131 seeks/sec | CPU Available: 0%

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 75904 bytes/sec | CPU Available: 1%
Write to file: 89920 bytes/sec | CPU Available: 0%
Read from file: 90240 bytes/sec | CPU Available: 0%

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 296960 bytes/sec | CPU Available: 8%
Write to file: 351232 bytes/sec | CPU Available: 9%
Read from file: 370688 bytes/sec | CPU Available: 5%

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 522329 bytes/sec | CPU Available: 2%
Write to file: 630784 bytes/sec | CPU Available: 3%
Read from file: 603943 bytes/sec | CPU Available: 5%

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 616427 bytes/sec | CPU Available: 0%
Write to file: 744359 bytes/sec | CPU Available: 0%
Read from file: 682159 bytes/sec | CPU Available: 5%

Average CPU Available: 2% | CPU Availability index: 3


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 40.63 Normal Video DMA
Device: tpx: Buffers: 30
Comments: DiskSpeed 4.2 - Generic 2GB CFA Card

CPU Speed Rating: 136

Testing directory manipulation speed.
File Create: 29 files/sec | CPU Available: 8%
File Open: 48 files/sec | CPU Available: 0%
Directory Scan: 142 files/sec | CPU Available: 0%
File Delete: 71 files/sec | CPU Available: 0%

Seek/Read: 125 seeks/sec | CPU Available: 0%

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 48384 bytes/sec | CPU Available: 29%
Write to file: 52160 bytes/sec | CPU Available: 33%
Read from file: 85504 bytes/sec | CPU Available: 0%

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 209920 bytes/sec | CPU Available: 33%
Write to file: 239654 bytes/sec | CPU Available: 35%
Read from file: 360960 bytes/sec | CPU Available: 7%

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 355596 bytes/sec | CPU Available: 31%
Write to file: 395679 bytes/sec | CPU Available: 35%
Read from file: 587620 bytes/sec | CPU Available: 7%

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 504123 bytes/sec | CPU Available: 17%
Write to file: 614905 bytes/sec | CPU Available: 16%
Read from file: 657708 bytes/sec | CPU Available: 7%

Average CPU Available: 15% | CPU Availability index: 20


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 40.63 Normal Video DMA
Device: lxr: Buffers: 30
Comments: DiskSpeed 4.2-Lexar 256MB CFA Card

CPU Speed Rating: 136

Testing directory manipulation speed.
File Create: 23 files/sec | CPU Available: 38%
File Open: 48 files/sec | CPU Available: 1%
Directory Scan: 143 files/sec | CPU Available: 0%
File Delete: 65 files/sec | CPU Available: 9%

Seek/Read: 123 seeks/sec | CPU Available: 1%

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 60104 bytes/sec | CPU Available: 15%
Write to file: 71296 bytes/sec | CPU Available: 13%
Read from file: 86272 bytes/sec | CPU Available: 0%

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 194686 bytes/sec | CPU Available: 37%
Write to file: 261632 bytes/sec | CPU Available: 30%
Read from file: 359424 bytes/sec | CPU Available: 7%

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 296524 bytes/sec | CPU Available: 41%
Write to file: 431479 bytes/sec | CPU Available: 31%
Read from file: 583539 bytes/sec | CPU Available: 8%

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 452139 bytes/sec | CPU Available: 25%
Write to file: 655360 bytes/sec | CPU Available: 11%
Read from file: 653725 bytes/sec | CPU Available: 7%

Average CPU Available: 16% | CPU Availability index: 22

MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68000 AmigaOS Version: 40.63 Normal Video DMA
Device: dh0: Buffers: 30
Comments: DiskSpeed 4.2-Canon 32MB CFA Card

CPU Speed Rating: 136

Testing directory manipulation speed.
File Create: 33 files/sec | CPU Available: 9%
File Open: 54 files/sec | CPU Available: 0%
Directory Scan: 148 files/sec | CPU Available: 0%
File Delete: 75 files/sec | CPU Available: 0%

Seek/Read: 129 seeks/sec | CPU Available: 0%

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 68672 bytes/sec | CPU Available: 5%
Write to file: 82368 bytes/sec | CPU Available: 2%
Read from file: 89920 bytes/sec | CPU Available: 0%

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 243712 bytes/sec | CPU Available: 24%
Write to file: 304128 bytes/sec | CPU Available: 20%
Read from file: 350208 bytes/sec | CPU Available: 9%

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 420154 bytes/sec | CPU Available: 20%
Write to file: 563136 bytes/sec | CPU Available: 12%
Read from file: 587620 bytes/sec | CPU Available: 7%

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 571950 bytes/sec | CPU Available: 6%
Write to file: 710242 bytes/sec | CPU Available: 4%
Read from file: 664857 bytes/sec | CPU Available: 7%

Average CPU Available: 7% | CPU Availability index: 10

[Toni Wilen]

The CFA cards didn't perfom as poorly as I initially thought they would, but they obviously can't respond to data requests fast enough to sate even the bog standard 68000 in this system, as the 3 year old notebook hard disk can. The problem will be compounded if you move to a faster processor.

In what can only be described as a bizarre twist on what you'd expect, the oldest and least capacious card tested (32MB Canon) with its SanDisk firmware turned out to be the quickest of all flash drives tested, and if I needed to use a flash drive on this system, this card would be my choice.


Quite odd results when you can get ~5-7MB/s speeds with Blizzard SCSI + ACard SCSI-IDE connected to CF card (I have 8G SanDisk Extreme III) and ~2MB/s (or more depending on CPU) when connected to A1200 IDE.

EDIT: modern CF can last years, even if you keep writing continuously.. Flash dying due to too many write cycles (yes, it does but it takes years and more) is some 80/90s "fact" only.

EDIT2: just for fun I tested my A500 Supradrive 500XP (Acard and 2G CF) and got ~500kb/s speeds (with create speed much slower than write or read). I guess thats the best it can do, it is after all non-DMA and uses byte size read/writes (stupid Supra, why not word sized.. Z2 version used words..)

[Shadowfire]

Disclaimers: My assessments are based on my observations and timings. The system I am using to test is a standard 68000 based system. My IDE controller was designed with this kind of system in mind, and may not (in fact, probably won't, although that has yet to be determined) scale well with faster processors. 500k/sec isn't a bad transfer rate at all, considering the speed of the processor and OS & I/O overhead.

68000 best case transfer rate scenario: infinite loop as such

.. move.l (a0)+,(a1)+
dbra d0,..

1 transfer to fetch move instruction, 2 transfers to read words, 2 transfer to write words
1 transfer to fetch loop instruction

@ 7.1mhz, 4 cycles per mem transfer, 6 mem transfers per iteration, this is a max of approximately 295,833 iterations/sec, each of which transfers 4 bytes, or 1,183,333 bytes a second... if the only thing it is doing is the memory transfer. Of course, the 68000 has to service interrupts, parse I/O requests & reply to messages, transfer parameters to and from hardware, etc.

This timing suggests that the Supra drive is copying data via the cpu, but actual SCSI I/O operations are handled by some sort of SCSI processor. You wouldn't want to know how slow this would be if the 68000 was doing the SCSI handshaking :)

Fun side note: Bus master DMA, hogging the bus, 7.1mhz / 4 cycles per memory transfer * 2 bytes/transfer = 3.5MB/sec maximum.

[FrenchShark]

Disclaimers: My assessments are based on my observations and timings. The system I am using to test is a standard 68000 based system. My IDE controller was designed with this kind of system in mind, and may not (in fact, probably won't, although that has yet to be determined) scale well with faster processors. 500k/sec isn't a bad transfer rate at all, considering the speed of the processor and OS & I/O overhead.

68000 best case transfer rate scenario: infinite loop as such

.. move.l (a0)+,(a1)+
dbra d0,..

1 transfer to fetch move instruction, 2 transfers to read words, 2 transfer to write words
1 transfer to fetch loop instruction

@ 7.1mhz, 4 cycles per mem transfer, 6 mem transfers per iteration, this is a max of approximately 295,833 iterations/sec, each of which transfers 4 bytes, or 1,183,333 bytes a second... if the only thing it is doing is the memory transfer. Of course, the 68000 has to service interrupts, parse I/O requests & reply to messages, transfer parameters to and from hardware, etc.

This timing suggests that the Supra drive is copying data via the cpu, but actual SCSI I/O operations are handled by some sort of SCSI processor. You wouldn't want to know how slow this would be if the 68000 was doing the SCSI handshaking :)

Fun side note: Bus master DMA, hogging the bus, 7.1mhz / 4 cycles per memory transfer * 2 bytes/transfer = 3.5MB/sec maximum.

Hello Shadowfire,

the best case transfer rate scenario on a 68000 is by using MOVEM instructions. I have done that about 10 years ago when I rewrote the AT-Apollo.device for my AT-2000 IDE controller. I was able to have more than 1MB/s with a standard 68000 and some fast ram.

Best regards,

Frederic

[Shadowfire]

Point taken, you can go up to 8 long words without too much messing around (if you have that many free registers available) over two instructions: (you could go more than 8 but then setup become trickier)

.. movem.l (a0)+,d0-d6/a3
movem.l d0-d6/a3,(a1)+
dbra d7,..

becomes 3 instruction fetches, 32 data operations, to copy 32 bytes of data per iteration
7.1mhz / 4 cycles/transfer / 35 transfers/iteration * 32 bytes/iteration = 1.682 MB/s

this unfortunately appears to become slower than the prior code on anything greater than a 68000, as it doesn't invoke the more advanced processor's loop mode (which completely removes instruction fetches from the equation)

[Toni Wilen]

this unfortunately appears to become slower than the prior code on anything greater than a 68000, as it doesn't invoke the more advanced processor's loop mode (which completely removes instruction fetches from the equation)

Do not bother with loop mode or have CPU specific loops :)

Practically nobody has an 68010 (only CPU with loop mode) and all newer CPUs have proper instruction cache (68020+)

[yaqube]

the best case transfer rate scenario on a 68000 is by using MOVEM instructions. I have done that about 10 years ago when I rewrote the AT-Apollo.device for my AT-2000 IDE controller. I was able to have more than 1MB/s with a standard 68000 and some fast ram.

Using MOVEM instruction on 68000 is relatively tricky.

"Note that the MOVEM instrudion has a side effect. An extra bus cycle occurs for memory operands, and an operand at one address higher than the last register in the list is accessed. This extra access is an 'overshoot' and has no effect as far as the programmer is concerned. However, it could cause a problem if the overshoot extended beyond the bounds of physical memory. Once again, remember that MOVEM.W sign-extends words when they are moved to data registers."

It can only be used when the hardware is designed in very appropriate way. To be able to transfer 8 long words using MOVEM to/from IDE HDD data port that data port must be repeated exactly 16 times in continuous 16-bit wide memory range and the next address locations must be insensitive to non-intended reading and writing.

This can be achieved by proper address decoding but must be done very early on design specification stage.

[yaqube]

.. movem.l (a0)+,d0-d6/a3
movem.l d0-d6/a3,(a1)+
dbra d7,..



This addressing mode is not supported on the 68000 CPU. You can use Address Register Indirect addressing mode with the same result.

Please keep in mind other MOVEM instruction limitations/side effects.

[Shadowfire]

After using the IDE controller for 3 or four days boxed up in my A2000, I have encountered several checksum errors. Retry'ing did not clear any of them up, so I have to assume data corruption on write.

I already have an idea of how to attack this & determine the cause, but I'm waiting on the 2630 accelerator card before I rip the box open again (I'll need to upload some debug firmware to get to the bottom of the issue). It seems likely that I will have to revisit my PIO or SRAM timing, but I can't say for sure until I have performed an analysis.

On a more positive note, I took one of the CFA cards I had created on the Amiga with my IDE controller, hooked it up to one of my Core2Duo systems with an IDE-CF adapter, and WinUAE immediately recognised it (via the Add Hard Disks option) as an RDB device, and I was instantly up in WinUAE with the CFA card, no problems whatsoever.

Edit: Just for haha's, I ran a diskspeed session within WinUAE (this is on a Core2DUO E8400, 3.0Ghz system with 8GB RAM, 68030 JIT option) with the 32MB Canon CFA drive.


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68030 AmigaOS Version: 40.62 Normal Video DMA
Device: dh0: Buffers: 30
Comments: DiskSpeed 4.2

CPU Speed Rating: 170997

Testing directory manipulation speed.
File Create: 140 files/sec | CPU Available: 108%
File Open: 621 files/sec | CPU Available: 98%
Directory Scan: 5564 files/sec | CPU Available: 53%
File Delete: 4988 files/sec | CPU Available: 94%

Seek/Read: 424 seeks/sec | CPU Available: 103%

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 544384 bytes/sec | CPU Available: 95%
Write to file: 161216 bytes/sec | CPU Available: 98%
Read from file: 2932480 bytes/sec | CPU Available: 52%

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 565760 bytes/sec | CPU Available: 101%
Write to file: 163840 bytes/sec | CPU Available: 100%
Read from file: 1086507 bytes/sec | CPU Available: 98%

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 473951 bytes/sec | CPU Available: 103%
Write to file: 160627 bytes/sec | CPU Available: 102%
Read from file: 246771 bytes/sec | CPU Available: 109%

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 639375 bytes/sec | CPU Available: 103%
Write to file: 162620 bytes/sec | CPU Available: 101%
Read from file: 196608 bytes/sec | CPU Available: 108%


This is compared to the fourth window of results from the prior sets of benchmarks from the A2000. It's really just a fun exercise, since there is obviously some memory buffering going on (apparent by the Create File results) by WinUAE or Windows, but it seems that with the overhead of going thru multiple abstraction layers (both within WinUAE and Windows) write speeds are in fact limited to 162k/sec. This CFA card was installed all by itself on a separate IDE channel in the machine. A better benchmark would be a native PC tool, maybe I can find one and post some numbers later.

Update: IOmeter tests for the above CFA card (same system), FAT file system:
1.80mb/sec transfer rate, I/O response times from 7ms - 41ms (1 worker thread), 140 I/O's per second

[gizmomelb]

The cyclone project doesn't really interest me (I did a bit of reading on it, mind you). I've found that most of my original old disks are, in fact, already bad.

no probs, but a pity as you obviously know your electronics and programming!

I was hoping the 'virtual floppy' aspect might interest you, to replace all those failed floppy drives in all model amigas (And other computers). But looks like the creator of the PIC18F based SD virtual floppy has also been taken with the AT91SAM7S256 chip and is converting / upgrading his design to utilise it's extra grunt over the PIC18F MCU.

http://eab.abime.net/showpost.php?p=584800&postcount=762

anyways, back on topic - looking forward to someone making your design and selling them, I'll definately be wanting to buy one for my A500.

[Shadowfire]

At the moment, I'm investigating the rather daunting task of getting this down to a 2-layer board (there's over 400 connections to the board on this, so I'm looking at almost EVERYTHING, swapping around I/O lines on the PIC32 & CPLD, as well as new layouts etc). There are no guarantees it can be done with the sheer number of interconnects, and it may have to remain a 4-layer board, but for cost reasons it would be good to have it as a 2-layer.

[Zetr0]

@Shadowfire

Sandwich boards and jump wire.... LOVE 'EM!!!!

[Stedy]

@Shadowfire

I'd leave the board as a 4 layer design. For bulk PCBs the cost difference is small.
As an example, for the board I am slowly working on, in bulk, will cost £7.50 for 4 layer and £6.80 for 2 layer. Prices are based on a quantity of 50 boards.

For prototypes, 3 PCBs will cost £138, one PCB is £69 so I might as well buy some spares ;) I have Most of the parts to make 5 PCBs now, which will be plenty for testing. Just need to finish the design.

This bank holiday weekend is the longest break I have had since June so I may get some serious work done on the design.

Ian

[Shadowfire]

Just got the 68030 accelerator in the mail today. After a false start (wrong jumper settings on A2630, it was set up for a german A2000), the machine came to life and autobooted off the hard disk without any modifications. Of course, the first thing I did was a diskspeed run on the '030 to see what it was looking like:


MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68030 AmigaOS Version: 40.63 Normal Video DMA
Device: dh0: Buffers: 30
Comments: DiskSpeed 4.2

CPU Speed Rating: 1334

Testing directory manipulation speed.
File Create: 56 files/sec | CPU Available: 8%
File Open: 99 files/sec | CPU Available: 0%
Directory Scan: 245 files/sec | CPU Available: 0%
File Delete: 155 files/sec | CPU Available: 3%

Seek/Read: 188 seeks/sec | CPU Available: 0%

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 111360 bytes/sec | CPU Available: 1%
Write to file: 127680 bytes/sec | CPU Available: 1%
Read from file: 136256 bytes/sec | CPU Available: 0%

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 485376 bytes/sec | CPU Available: 19%
Write to file: 587776 bytes/sec | CPU Available: 18%
Read from file: 625152 bytes/sec | CPU Available: 9%

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 1029617 bytes/sec | CPU Available: 13%
Write to file: 1302528 bytes/sec | CPU Available: 11%
Read from file: 1168534 bytes/sec | CPU Available: 12%

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 1347619 bytes/sec | CPU Available: 7%
Write to file: 1715263 bytes/sec | CPU Available: 6%
Read from file: 1376256 bytes/sec | CPU Available: 13%


So it appears that there may be more room for optimization. First thing's first, though, I need to track down that write error, so tomorrow will be spent modifying the firmware to verify the write and sector transfer operations to track down the issue. Once I get that nailed down, large hard disk/new style device support will probably be the last item on my to-do list, barring any unseen problems, and I will close the project and release the last version of the source and binaries.

[NovaCoder]

Cool :)

So is this baby any closer to production (eg an ETA), it would be a shame if all this good work didn't eventuate into something material,

[Shadowfire]

To find the cause of the problem, I changed the IDECMD_WRITE area of the firmware to check the data read from SRAM four times (SRAM data is read into the regular buffer, followed by four passes of reading SRAM into a verify buffer, after each pass the verify buffer is compared to the regular buffer). I then added a section to verify the blocks written to hard disk four times (similar to above, it writes the data from regular buffer, then makes four passes, reading the data from the hard disk into the verify buffer and then comparing it to the regular buffer). I then logged any anomalies to serial output and captured it on a terminal program, as usual.

This is the result of a clean install of 3.1 on an empty hard disk:


VERIFY ERROR! Pass # 00, Retrieving data from SRAM, SRAM word offset 0x0080, o
riginal data 0xD0FF, verify data 0xD2FF.
VERIFY ERROR! Pass # 01, Retrieving data from SRAM, SRAM word offset 0x0080, or
iginal data 0xD0FF, verify data 0xD2FF.
VERIFY ERROR! Pass # 02, Retrieving data from SRAM, SRAM word offset 0x0080, or
iginal data 0xD0FF, verify data 0xD2FF.
VERIFY ERROR! Pass # 03, Retrieving data from SRAM, SRAM word offset 0x0080, or
iginal data 0xD0FF, verify data 0xD2FF.
VERIFY ERROR! Pass # 00, Retrieving data from SRAM, SRAM word offset 0x0472, or
iginal data 0xF0FF, verify data 0xF2FF.
VERIFY ERROR! Pass # 01, Retrieving data from SRAM, SRAM word offset 0x0472, or
iginal data 0xF0FF, verify data 0xF2FF.
VERIFY ERROR! Pass # 02, Retrieving data from SRAM, SRAM word offset 0x0472, or
iginal data 0xF0FF, verify data 0xF2FF.
VERIFY ERROR! Pass # 03, Retrieving data from SRAM, SRAM word offset 0x0472, or
iginal data 0xF0FF, verify data 0xF2FF.
VERIFY ERROR! Pass # 02, Retrieving data from SRAM, SRAM word offset 0x020F, or
iginal data 0xF0FF, verify data 0xF2FF.
VERIFY ERROR! Pass # 02, Retrieving data from SRAM, SRAM word offset 0x0073, or
iginal data 0xF2EE, verify data 0xF0EE.


The problem is obviously reading out data from SRAM, not IDE transactions. I suspect that I will need to add the other bypass capacitor to the level shifter after all. If that fixes the issue, everything is good, since the bypass caps were fixed in the last revision of the schematic, but it is going to be a P.I.T.A to attach it to the prototype board...

Edit: Board surgery performed and the missing bypass capacitor added. I did an entire 3.1 install without any errors. Going to use it for a few days and do some installs, etc, but it seems like that was the problem, and it will be a non-issue for boards made from the schematic diagrams that were posted here as they include the bypass caps for U7.

Edit: All stability issues seem to be fixed. Moving onto NSD/64-bit trackdisk support. Amiga side device driver has been updated - testing then working on PIC32 firmware. If all things go as planned, you should (memory permitting) be able to boot into a >4GB SFS partition without any data corruption problems, the only issues should be with non-64-bit aware programs.

Edit: OS3.9 HDToolBox is now working and sees all 60gigs of the hard disk (fixed some SCSIDIRECT issues with the PIC32 firmware, also tweaked the IDENITFY_DEVICE code to report true hard disk size instead of the hard disk's 8GB safe value).

[Shadowfire]

I took a few days off to do other things, and when I got back to the project, I quickly found the stupid mistake that was stopping SFS from working: a forgotten branch (when adding the new command numbers to the code that determines the read/write direction based off of the IO_COMMAND).

I will take some screen pics later (hopefully today) after I validate that nothing else is broken...

[tonyyeb]

Best thread on EAB at the moment!

[Shadowfire]

Ok... took some final pics. First pic is the prototype installed in an A2000. I had to modify the A2000's motherboard (basically, two electrolytic caps needed to be yanked, then re-installed lying flat to the motherboard instead of standing vertically). The prototype then fits and everything can be installed and closed up (no access to the rs232 debug header when its closed up, but whatever).
http://img15.imageshack.us/img15/6253/installedina2000.th.jpg (http://img15.imageshack.us/i/installedina2000.jpg/)
Here is a WB snapshot (couldn't use my camera, nothing at all was legible, and I don't have any way to grab the composite or RGB signal, so I took a netbook and used its webcam for this shot). This is a 60GB hard disk, formatted as a single-partition on drive SDH0:, booted into OS3.9 on a A2000/A2630 with 1MB chip, 4MB 32-bit fast, 2MB 16-bit fast memory (avail command at top of CLI). The CD0: cd-rom currently has the Amiga OS3.9 disc in it.
http://img15.imageshack.us/img15/4548/screenshotxv.th.jpg (http://img15.imageshack.us/i/screenshotxv.jpg/)
Everything seems to be in order now. Final firmware files will be going up into the zone soon, which includes the NSD/Trackdisk64 support needed to autoboot off of >4GB partitions and the most recent bugfixes. No external patches (such as IDEFIX) are needed, use SFSFormat to format the partitions. Do not use non-64bit aware disk tools, yadda yadda yadda.

Edit: More notes. SFS is *not* compatible with the 68000 and generates an odd-address access error. Don't expect to plug this in a plain vanilla 68000 system and get no-hassle >4GB support, the filesystem itself is the limiting issue here.

[Stedy]

@Shadowfire

Well done mate. Let me know when the final files are available so that I can download and review them.

Ian

[Shadowfire]

They should already be in the Zone.

[Photon]

Too bad you made a controller that works with SFS, but the SFS software is written for 68020 and up only :(

Maybe there's a proper all-68xxx version of the software? Cos now that we have a controller for the nice old beasties it would be a bummer if SFS is limited to new Amigas only. Not that FFS isn't nice enough... :)

Would it be precocious to ask for a controller to try/hack into my A1000? Unless I've missed something and internal controllers already exist for it :P

[rkauer]

<SNIP>
Would it be precocious to ask for a controller to try/hack into my A1000? Unless I've missed something and internal controllers already exist for it :P

Pssst! (http://www.students.tut.fi/~leinone3/ide/ide68k.html)

[Photon]

Yeah, I saw that. Where's the Buy it now button? :) I don't mind assembling a kit. I meant it in the spirit of 'off the shelf' or at least reasonably 'buyable'.

[Shadowfire]

SFS doesn't use TD64 commands if the partition lies completely within the first 4GB of the hard disk, so you can use any RDB-compliant hard disk controller (SCSI or otherwise) to see if SFS works with your system. Heck, you don't even need RDB compliance if you're willing to mess with mountlists. I don't know what options are available on the A1000, but my controller *should* work if it can physically fit.

However, I can tell you that if you are running a 68000, the SFS posted on Aminet will not work for you. Additionally, SFS shows builds for OS3.X and OS4.0, which leads me to believe you need probably need Kickstart 3.0 in ROM as well.

There is another FS called PFS2, which supposedly also supports large partitions and lists 68000 support, however it is commercial software and I have not tested with it. If it uses TD64 commands, it should work with my controller. If it uses SCSI_DIRECT, it will likely not work, as SCSIDIRECT (read6 and write6 are implemented, not read10 or write10) commands are limited to 4K data transfer lengths, and would need a partial rewrite of the driver to support larger transfers. Furthermore, the rewrite would be extremely tricky (I would basically need to parse the HD_SCSIDIRECT command, and I don't have enough memory left in my Amiga memory map to add that much code - as it stands, the command is parsed only by the PIC32. A workaround would be needed, and while I can think of two or three ways to do it, none of them are easy, and the method I would likely use would require more rejiggering of code on both (Amgia/PIC32) platforms. My driver was originally designed around the Amiga's native IOREQUEST and CMD_READ standard, not SCSI_DIRECT. (As a result, TDCMD64_XXXX support was much, much easier to add than HD_SCSICMD, which basically requires emulating SCSI command protocol.)

Edit: You could also set MaxTransfer to 0x00001000 in the mountlist to get around that, but you would certainly get a significant decrease in your performance (versus a filesystem using standard trackdisk/trackdisk64 commands where my driver internally breaks it up into 4K requests with minimal overhead.)

[rkauer]

For the PFS: tested, used and is good for your 68000. :D

Bad news: you need to find a (sucker) guy willing to part of his registered PFS2 or PFS3. It is a commercial product and can't be used without buy it (from nowhere, I'm affraid... :sad)....

[Photon]

Hehe, just read the thread tags :)

Big question: will the A600 accelerator have a SIMM socket for, and support, 32-bit RAM? Please tell me it isn't EC020-only... :crying

Also, what socket does it have for the 24-bit ram? SIMM would be great for that too, I think. Unless the "only 4MB please I'm using the PCMCIA"-switch is incompatible with it.

[Shadowfire]

I put the files up on my blog on windows live. I tried myspace, but it isn't a real web hosting service and has no way to upload binary files. Windows Live Spaces and Windows Live Sky Drive fit the bill perfectly.

http://cid-8e37976cf1ef4c2a.spaces.live.com/blog/cns!8E37976CF1EF4C2A!146.entry

[tonyyeb]

We've seen great work by Shadowfire on an IDE controller but not much talk about the accelerator... what's the latest please guys?

[Shadowfire]

Photon,

The 68EC020 part differs from the 68020 in that it doesn't support an MMU or FPU, and has a 24-bit external address bus. The 68EC020 is a "true" 32-bit part, the external data bus is 32-bits wide. The big difference here is that the 68EC020 "only" has a 24-bit external address bus (instead of the full 32-bits on the 68020), which limits your usable address space to 16MB (and, in the Amiga's architecture, this essentially means 2MB CHIP ram, and 8 MB autoconfig RAM).

To reiterate, a 68EC020 with 32-bit RAM is no slower or faster than a regular 68020 with 32-bit RAM of the same speed. I seriously doubt that Stedy would go through the effort of rolling out a 68ec020 accelerator card and then neuter it with 16-bit RAM access :) Your data throughput speed depends only on the size of the data bus, and the clock speed. The address bus affects how much memory you can attach, not the speed at which you can access it.

[Stedy]

Hello,

@Photon,

The card will have a SIMM socket and support 32 bit wide SIMMs.

The processor will be a PQFP 68EC020 16 MHz, clocked at 14 MHz to provide lowest latency accesses to the Amiga system bus.

The 68EC020 was chosen as I can purchase them for a less than $5 each, the full 68020 costs $62 in the same speed grade.

The RAM limit will be 8 MByte of RAM, the explanation given by Shadowfire covers the reasons.

@Thread

Progress on the design has slowed to a near halt as there are not enough hours in the day. I have been working late nights and weekends in the day job since March this year so time is precious and in short supply.

The plan is to have a few prototypes around christmas 2009, all going well and test them thoroughly. From there I decide if I spend £4000 producing a small production run of cards. The aim is to have a unit that retails around the £75-£100 mark.

If anyone wants to get involved with the design of this card and could assist with technical effort, please contact me.

Ian

[Photon]

It's gonna be a sweet Xmas :great

Heh, sorry about that. :) I know about bus width etc and the different # of address lines for the CPUs. Someone mentioned "24-bit" RAM, and I'm afraid I absorbed that jargon like a sponge. :S Will not confuse you with that crap anymore. Silly me.

But it would be sweet if one could have an silly amount of RAM in an A600 :xmas For webstuff and possibly image editing, if nothing else. Maybe some Unix-alike would also be possible?

I could have kept it simple and just asked if it was an EC020 :P

So, I will lose half my fastram if I use the PCMCIA. I guess there's no non-MMU way of put it elsewhere in address space.


Some ideas, probably to late in the devstage, but...
- Two SIMM sockets, one for memory accessible via mobo/68EC020, one for 020-only memory mapped elsewhere (somewhere) (over the rainbow) (by which I mean the 16M boundary)(c)(Homer Simpson)?
- 68020 socket (or any socket, really)+EC020 adapter? Would allow upgrades and 32-bit addressing, if supported.

[Shadowfire]

Photon,

You ain't going to be mapping anything > 16MB on the 68ec020. There is no hardware support for it on the chip, and no clever ways around it. You would have to resort to bank switching hacks with custom external logic, which no Amiga software is designed to use. Nothing would run with it.

[Shadowfire]

Ian,

I would like to help, but I no longer have access to decent CAE/CAD software, and additionally I do not have an A600 (which I would need to do the board layout, for obvious reasons).

[Photon]

Photon,

You ain't going to be mapping anything > 16MB on the 68ec020. There is no hardware support for it on the chip, and no clever ways around it. You would have to resort to bank switching hacks with custom external logic, which no Amiga software is designed to use. Nothing would run with it.
Hence the socket suggestion.

[kipper2k]

Ian,

I would like to help, but I no longer have access to decent CAE/CAD software, and additionally I do not have an A600 (which I would need to do the board layout, for obvious reasons).


Hi Shadowfire,

i have about 15 A600 boards, if you want one to continue work then i can send you a working A600 board (PAL version though)

Let me know

[MagerValp]

The card will have a SIMM socket and support 32 bit wide SIMMs.
...
The RAM limit will be 8 MByte of RAM, the explanation given by Shadowfire covers the reasons.

Just out of curiosity - what's the cost of soldering 8 MB of DRAM straight to the card, compared to a SIMM socket?

[rkauer]

@MagerValp: will increase the cost of the board a little due the size of the board to accommodate the RAM chips.

There is a way to add a bit more memory to the EC board: mapping 1.5Mb to the slow RAM address. It is easy to do using a 8Mb SIMM and two separate address decoders inside the PGA of the accelerator. 5.5Mb total FAST is very good for WHDLoad and lots of applications.:)

[Zetr0]

I would love to see if the FG ec020's can run at 28mhz.... that would indeed be a boon!

the problem will be XOR'ing back to the 7mhz BUS properly....

[Shadowfire]

Kipper,

I would also need the RF shielding (and the case, too, if it would impact things) as the whole point of doing all that work is to make sure that you can close up the case after installing the PCB. Otherwise, we could just do any arbitrary board and stack four or five 64-pin DIP sockets under the board to bring it up above everything else. But I don't think that anyone wants a solution like that.

[Photon]

Just out of curiosity - what's the cost of soldering 8 MB of DRAM straight to the card, compared to a SIMM socket?
ARGH! DRAMs cost real estate on the board and they're harder to get than SIMMs. 8MB SIMMs are just about free, and they're everywhere. SIMM socket please!! It's tiny :)

Plus all the nice accels for higher Amiga models have SIMM sockets :)

[Shadowfire]

FYI for those that may not know exactly what is involved here....

Layout of a PCB like this involves:
- measurement of dimensions on the motherboard
- measuring heights of various componenets, specifically ones which are at/above the heigh of the 68000 socket we are plugging into
- available vertical space, typically limited by the RF shielding or case

You would typically use a CAD program to create a model of the motherboard PCB along with any high components, then overlay your proposed PCB and choose what you would think is the "best" fit, in this case, least number of holes you have to have drilled in the final board. This must also be balanced against available routing area, since the final PCB will likely have >1500 connections to it. When you've chosen your best fit, you note the size & location of holes that need to be drilled in the board from the CAD program, and enter them into the layout. The header strips that connect to the 68000 socket on the motherboard (or, in the A600 case, there is a special socket connector) are then placed and fixed into position.

At this point you have a PCB you know you can install in the machine without obstructions, but you still have to worry about clearance above the board (component height versus space between the board & RF shield) and possibly below the board (any components placed on the bottom of the board also have to clear anything on the motherboard below them, or it won't sit proper in the socket).

Now you get to do the layout proper, grouping components up and placing them on the board, trying to find the layout that will give you the easiest routing. Then you save the board and let the autorouter have a go at it to see if it is possible to route the board. It's possible on a board this complicated to need to tune your layout dozens of times before you find something you're happy with (or that the autorouter can do most of the work on). For instance, on my prototype board, I ended up switching the SRAM headers from .100" headers to .050" surface mount headers (through hole .050" headers at my chosen board house would not allow me to route any traces between the pins with my minimum 6 mil clearances, with the drill sizes available from them and my own requirement to have at least 10mil pad around each via... smaller pads are easily destroyed if you need to solder to them, which I ended up needing to do to add the forgotten bypass capacitors on the level shifter). This was after 3 or 4 attempts to get the .100" headers on the board, but it was never routable unless I made all 4 layers routing layers... and I wanted at lease a continuous ground plane, if not a solid power plane too. I would guess that I went through 9 or 10 layout iterations before the final prototype layout was done, with a solid ground plane and a mostly solid power plane.

Once you finish laying out the board, you need to double check all the component heights for clearance. Fortunately, all the parts we are using have datasheets that document all these dimensions. The biggest bugaboo in the entire process is that no mechanical drawings exist for the populated motherboards of these machines, which is why we need to make all the manual measurements. Assuming the components are OK, you complete the routing, then make any changes to the copper fill.

You then print out the top layer, and bottom layer at a 1:1 ratio and place your parts on the printout to make sure you haven't made any mistakes entering the component's footprint, or assigned the wrong footprint, a common mistake for new AND old PCB designers :)

Finally, you generate your Gerbers and load them up in a separate program like Viewmate, making sure that your silkscreening is OK, that your drill drawing overlays correctly with your electrical layers, and that all your layers line up correctly - if not, you go back into your PCB program and adjust the output options. You also look for anything that seems wrong, this is especially important when you are manually making changes to the copper pours or manually routing the board. A good (read: Expensive) PCB program has design rule checks which automatically flag problems like this.

Needless to say, it is not a small investment of time.

[Photon]

Hey m8 :)

I've offered help to Stedy. Have I got something wrong here?? I've been up since 5:30am :)

4-layer board seems a good solution. The space under the grille beside (to the left of) the floppy drive seem a good place to put an accelerator board without having to think about height of capacitors etc :) Just screw the board (or plate under board, if required) to the little ledge at the back of the case. [Edit: who the hell uses the top part of the RF shield anyway?? hehe]

Requires a cable, though, from a 68000 socket to the board. But I think it's a good thing to decouple the board from the 68000 socket. If you "hang" the board "on the socket", it will budge the moment you put the A600 on a table... just like the A608 that has the PLCC socket in the corner.

BTW, what's that 68030 board you mentioned?

[kipper2k]

@shadowfire..


I'm pretty sure i got a shield kicking around. i got a not so pretty case and keyboard i can put in, what rom do you want, i guess 3.1 is probably the best one. Do you got a floppy drive?, If thats good for you let me know your addy and i can throw it in the mail for you, probably take about 12 days to get to Ct from up here if the dogs pulling the train don't get too tired :)

[Shadowfire]

Kipper - hold off on doing any of that for a response from Stedy.

Edit: About "hanging" the board: no need, you just put a hole in the PCB to mount a plastic spacer on two corners where the weight bears down. That's something you consider during the "make it fit inside the machine" part of the layout. Thats the kind of design problem that you should find out about after you make the first prototype, and I would *not* introduce a cable just to get around that, since the cable will introduce its own electrical issues (crosstalk [which you can't do a lot about except build a more expensive cable] and impedance mismatches [which may or may not be bad enough to have to change signal terminations on the board]).

[Stedy]

Hi,

@Photon/Shadowfire

I'll be in touch shortly with areas you can help me with. I want to get the basic schematics in place first with a concept PCB scheme.

@Thread

The plan has always been to use a SIMM socket for economic reasons. You can buy 1 GB of DDR2 for less than 32 MB of DRAM when you buy ICs. Adding the socket is a no brainer.

The plan has always been to use a 4 layer board with at least one continuous power plane, 2 if possible. Shadowfire covered the steps involved in a comprehensive manner.

I had my A600 stripped down last weekend when replacing the electrolytics, it gave me the opportunity to see what room is inside. A 3U (100x160mm) blank PCB was used and this is a realistic maximum size. One concept is to include the hard drive mounting in the PCB area, it allows me to use some more space and to have a mechanical fixing scheme. The RF shield will need to go.

The PCB will only connect onto the MC68000 in the A600.

For the A500 and A1200, I have drawings of available PCB area and skylines, this needs to be done for the A600.

The design uses surface mount components as they are lower profile than PTH parts, especially useful when mounting a board in limited skylines.

There are no plans for a dual 68EC020/68020 footprint board. This will complicate the tracking immensely. If we go to an 8 layer board, it could be done, at 4X the price for the PCB! Connecting from the 68000 on the A600 to the 68EC020 will take some clever routing.

On the A500, it is simpler as it has the 64 pin DIL package on 2.54 (0.1") spacing, easy to route tracks between pins. The A600 has a CPU with 1.27 mm (0.050") pitch on the CPU so there is less room to route tracks.

It is easy to get carried away with a design like this but I have set some requirements:

1) Support a MC68EC020 CPU running at 14 MHz to provide lowest latency access to the Amiga bus.
2) Use a SIMM socket, supporting upto 8MB of RAM, with logic to utilise larger 16-32 MByte parts but still provide 8 MByte RAM.
3) Provide a DRAM controller.
4) Provide the required bus interface logic in a CPLD, most likely a coolruner-II or XC95xx device.
5) Retail price of less than £100 for a unit assembled by a professional supplier as I will not be soldering these PCBs!

Optional, if space and costs allow

i) provide mechanical support for the hard drive.
ii) provide a clock port
iii) FPU?

The first 5 requirements must be satisfied before the optional ones are taken into consideration.

In the workshop I have an A600, 2xA500, A1200 and a CD32/SX32 pro to test any designs on. No point adding a 68EC020 board to either the A1200 or CD32 though as they have a 68040 and 68030 already fitted.

Time for bed.

Ian

[rkauer]

As Shadowfire already states (and myself too, earlier in the thread) an easy way to secure the board exists: just using the HD cradle holes in the A600's board to screw the board in place.:spin

Of course, you need to put the HD over the accelerator. Or even better, install a CF adaptor over the PCMCIA port. ;)

[Photon]

Kipper - hold off on doing any of that for a response from Stedy.

Edit: About "hanging" the board: no need, you just put a hole in the PCB to mount a plastic spacer on two corners where the weight bears down. That's something you consider during the "make it fit inside the machine" part of the layout. Thats the kind of design problem that you should find out about after you make the first prototype, and I would *not* introduce a cable just to get around that, since the cable will introduce its own electrical issues (crosstalk [which you can't do a lot about except build a more expensive cable] and impedance mismatches [which may or may not be bad enough to have to change signal terminations on the board]).
And when you take the accelerated A600 out of a bag and put it on a table, the spacers won't stop the socket from plopping off the socket. You plug the Amiga in and turn it on, and frizzle.

My A500-040 never has stability problems. I made a socket-to-socket flatcable from some old IDE cable, hand-soldered 4 years ago and ugly as hell. :)

Crosstalk can be reduced by having every other wire grounded or the like, but I didn't need to.

When I made the A600 portable I had to spend a good part of the time thinking about the space inside, but especially, since it was portable, how to secure the devices.

Anyway, I'm not gonna fight about it, it's not my design. But on A600 there's basically nowhere else to go but "back and to the right", if you want to attach something to the PLCC socket. And the socket will be in the corner of the accel PCB and a jar will make a little wiggle and it'll pop off. Cos there are no screw holes to secure it to the mobo and you can't even put in something to press on the socket when the case is closed.

Never mind, I'll just make a socket to socket cable and put it where it can be secured.




Stedy: good that you decided to lose the RF shield - after all, it's not super-hard for users to cut a hole in it, if they want it on.

HD cradle holes? (I have a normal A600 purchased with no top RF shield, I don't see any.)

SIMM socket for the memory, that'll be perfect.

[rkauer]

As stated very earlier in this thread, the best idea I see around is using the IDE cradle holes in the motherboard to screw a pair of screws with plastic spacers.

I stole this idea from Jens's ACA630. I hope he don't want to sue me for this...:nervous

[xc8]

..
I stole this idea from Jens's ACA630. I hope he don't want to sue me for this...:nervous

heh.. I doubt!! As he must travel to Brazil/hire a lawyer there etc etc.. a lot of expenses..

[Photon]

Still see no cradle holes in my A600 (not A600HD) with RF shield top off. Am I blind???? :)

[xc8]

Look at the light-green spots...

http://img8.imageshack.us/img8/8610/23571014200202890146160.jpg

[Photon]

Well, bwää :) I was looking for screw holes :P never had a harddisk in my A600, so quite unfamiliar to me... thanx for the pic.

[Shadowfire]

Just an FYI, the idedisk.device driver is fully 64-bit aware and compliant, and available to the OS on first powerup. No patching of scsi.device, no rebooting. Even boot from a >4GB partition in OS3.1, if you set it up with SFS (the RDB uses 32-bit block pointers, which should be good for an RDB/SFS image anywhere in the first 2 TB of the drive).

[petersieg]

Hi.

What is the status of this project? Is the development in a status, where one
can build such device by themself? Are schematics, pcb design file(s), parts list etc. and other required files (firmware?) available (I don't seem to have access to the zone..?)?

Thanks, Peter

[kipper2k]

@Xc8

Where did you get the CF adapter with the builtin connector? do you have a url ?

Thanx

Look at the light-green spots...

http://img8.imageshack.us/img8/8610/23571014200202890146160.jpg

[Merlin]

I think it's this one mate:-

http://cgi.ebay.co.uk/Compact-Flash-CF-To-2-5-IDE-Female-Bend-Angle-Adapter_W0QQitemZ200390031523QQcmdZViewItemQQptZUK_Computing_CablesConnectors_RL?hash=item2ea82d38a3

:)

[xc8]

got it from that ebay shop:
http://tinyurl.com/yhjvgr9 ,
as I see they sell the same :
http://tinyurl.com/yzdpt6s

Chris

Merlin's link is ok too (the same) , as the 'brand' of that CF/IDE is 'SINTECH'

[Shadowfire]

petersied,

The accelerator board itself is still a work in progress. The standalone IDE controller (and associated firmware) is finished, and you can download the schematic & firmware off of my web site at http://gwdoiron.spaces.live.com/. Sorry that there is no board layout there, I only did a layout for 1 board which had debug headers & other utility stuff (and didn't fit anything without modifications), so you'll have to roll your own 4-layer PCB.

[kipper2k]

I think it's this one mate:-

http://cgi.ebay.co.uk/Compact-Flash-CF-To-2-5-IDE-Female-Bend-Angle-Adapter_W0QQitemZ200390031523QQcmdZViewItemQQptZUK_Computing_CablesConnectors_RL?hash=item2ea82d38a3

:)

Thanks Merlin,

couldnt find that little git anywhere :)

[rkauer]

@Xc8

Where did you get the CF adapter with the builtin connector? do you have a url ?

Thanx

Here is a better one from our friend mrmkl (IDE68k author): http://www.amiga.org/forums/showthread.php?t=49480

It don't clash with anything we are intending to do here.:)

:blased Hmm... Better chuck some pictures (hardware pr0n) for our friend Zetty:http://www.students.tut.fi/%7eleinone3/ide2cf/a6i2cf.jpg
http://www.students.tut.fi/%7eleinone3/ide2cf/a6i2cfpcb.jpg

[Zetr0]

@rkauer

Nice!!

how much does he sell these for?

[Photon]

Thanks for the pr0n but the sight of that CF card made my salt peter peter out... ;)

[Photon]

Just an FYI, the idedisk.device driver is fully 64-bit aware and compliant, and available to the OS on first powerup. No patching of scsi.device, no rebooting. Even boot from a >4GB partition in OS3.1, if you set it up with SFS (the RDB uses 32-bit block pointers, which should be good for an RDB/SFS image anywhere in the first 2 TB of the drive).
I guess idedisk.device is nothing I could use to speed up my measly 825 KB/s on my A600 portable, is it?? (I use FFS and not SFS, as it has a 68000 cpu)

Will the in-development IDE interface beat those speed in an A600 when it's finished? (With Gayle/driver optimization magic)

[rkauer]

@rkauer
Nice!!
How much does he sell these for?
Hello my friend. Mika sell those babies for 30 Euro, IIRC. Look into the Amiga.troll link on my above post.;)

@Photon: hardly you'll get any benefit from another Gayle... IDE is CPU dependent and use it up to the last resource. Only upgrading the CPU you'll have some speed up.

[Shadowfire]

No, you aren't going to break 700k/sec on a stock 68000 on the new IDE controller. It's not a DMA-driven design, it's a buffered PIO design (basically, instead of a DMA copy, the CPU performs 4KB memory copy loops). It could probably break 1MB/s with a rewrite of the inner copy loop to use MOVEM (right now, its just a 1024-iteration [MOVE.L (AX)+,(AX+) & DBRA DX,LOOP]) but I've moved on to other things. That kind of optimization isn't going to happen unless I find a bug which requires a rewrite of that part of the code, which is highly unlikely.

The IDE68K is basically a Gayle IDE hardware re-implementation, so it needs kickstart revisions which have the Gayle driver in ROM, uses the Gayle kickstart device driver, and has all the features (and drawbacks) of the A600's integrated IDE controller.

The new IDE controller is *not* a Gayle workalike, it's a brand new controller, with brand new firmware, which is why you get stuff like NSD, 64-bit access and no messing with MaxTransfer or Mask settings, compatibility with all autoboot kickstart revs from 1.3 to 3.1, and workarounds for compact flash compatibility, without installing a patch. The driver is stored in flash memory on the microcontroller.

On the other hand, it's a brand new controller, with brand new firmware, which hasn't had any field testing. Bugs are likely to occur in unusual situations - my system is working 100% but I'm not foolish enough to say it is "unbreakable".

[Photon]

Hello my friend. Mika sell those babies for 30 Euro, IIRC. Look into the Amiga.troll link on my above post.;)

@Photon: hardly you'll get any benefit from another Gayle... IDE is CPU dependent and use it up to the last resource. Only upgrading the CPU you'll have some speed up.
Well, IDEfix Express clips onto Gayle... or what did you mean?

[Photon]

No, you aren't going to break 700k/sec on a stock 68000 on the new IDE controller. It's not a DMA-driven design, it's a buffered PIO design (basically, instead of a DMA copy, the CPU performs 4KB memory copy loops). It could probably break 1MB/s with a rewrite of the inner copy loop to use MOVEM (right now, its just a 1024-iteration [MOVE.L (AX)+,(AX+) & DBRA DX,LOOP]) but I've moved on to other things. That kind of optimization isn't going to happen unless I find a bug which requires a rewrite of that part of the code, which is highly unlikely.

If you will let me, I can do the work. I've done some app replacements where I haven't cared about surrounding code, just made a strict functional replacement of the parts I wanted to change, without changing anything (flags, registers, stack) that could have side effects on retained code.

The IDE68K is basically a Gayle IDE hardware re-implementation, so it needs kickstart revisions which have the Gayle driver in ROM, uses the Gayle kickstart device driver, and has all the features (and drawbacks) of the A600's integrated IDE controller.

The new IDE controller is *not* a Gayle workalike, it's a brand new controller, with brand new firmware, which is why you get stuff like NSD, 64-bit access and no messing with MaxTransfer or Mask settings, compatibility with all autoboot kickstart revs from 1.3 to 3.1, and workarounds for compact flash compatibility, without installing a patch. The driver is stored in flash memory on the microcontroller.

On the other hand, it's a brand new controller, with brand new firmware, which hasn't had any field testing. Bugs are likely to occur in unusual situations - my system is working 100% but I'm not foolish enough to say it is "unbreakable".
Sell me one and I can do some field testing. After all, it will be going in my A600 portable, which must not fail under any circumstances, or I am computerless with possible loss of code sources on trips...

Have you check my speed comparison (http://eab.abime.net/showthread.php?t=47708) thread? I'm at 825 KB/s on the A600 (mobo IDE) and still want more ;)

[Zetr0]

@photon

you know, you really are beyond flogging a dead donkey with the IDE on the 68k!

dont get me wrong I totally salute you work :bowdown but there is just not that much more you can do with a 68k.

Even if you managed to get 1MB a sec from the native IDE, your still cripped as all your CPU cycles are gone in to achieving it.

If you REALLY want speed, then look at developing a DMA controller that can either be clipped or soldered on. look at somthing that uses the ROM / Gayle combination like the FastATA, but obviously with a DMA ability however the HUGE drawback of couse this would mean the need for Fast Ram (24bit for the 68k or 32bit for other cpu)

I would personally love the time to develop an A2000 CPU socket for the A600, (i know its possible for the A500/A500+) and that all the signals are on the board (with exception to a couple I think of the top of my head, however it would be awesome =D

[NovaCoder]

Here is a better one from our friend mrmkl (IDE68k author): http://www.amiga.org/forums/showthread.php?t=49480

It don't clash with anything we are intending to do here.:)

:blased Hmm... Better chuck some pictures (hardware pr0n) for our friend Zetty:http://www.students.tut.fi/%7eleinone3/ide2cf/a6i2cf.jpg
http://www.students.tut.fi/%7eleinone3/ide2cf/a6i2cfpcb.jpg

Sorry for the thread hijack...but wow, an IndivisionAGA friendly CF adapter :D