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

alanh · 16 August 2009, 12:47

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

Thanks.

AGN · 17 August 2009, 00:49

Quote:

Originally Posted by Shadowfire

Code:

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 · 17 August 2009, 06:22

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

Shadowfire · 17 August 2009, 22:29

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_...ezone_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 · 19 August 2009, 19:19

*****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 · 21 August 2009, 02:03

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

Zetr0 · 21 August 2009, 10:21

@Shadowfire

your like a machine man!

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

gizmomelb · 21 August 2009, 15:21

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 · 21 August 2009, 17:33

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 · 21 August 2009, 17:39

Quote:

Originally Posted by 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

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 · 21 August 2009, 23:54

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.

Code:

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

Code:

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

Code:

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

Code:

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 · 22 August 2009, 09:56

Quote:

Originally Posted by Shadowfire

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 · 22 August 2009, 20:44

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

Code:

.. 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 · 23 August 2009, 05:30

Quote:

Originally Posted by 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

Code:

.. 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 · 23 August 2009, 07:25

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 · 23 August 2009, 09:55

Quote:

Originally Posted by Shadowfire

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 · 23 August 2009, 12:04

Quote:

Originally Posted by FrenchShark

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 · 23 August 2009, 12:13

Quote:

Originally Posted by Shadowfire

.. 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 · 25 August 2009, 23:39

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.

Code:

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 · 26 August 2009, 14:26

Quote:

Originally Posted by Shadowfire

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=...&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.

17 August 2009, 22:29	#424
Shadowfire Registered User Join Date: Aug 2001 Location: Connecticut USA Posts: 617	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_...ezone_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. Last edited by Shadowfire; 18 August 2009 at 19:21.

19 August 2009, 19:19	#425
Shadowfire Registered User Join Date: Aug 2001 Location: Connecticut USA Posts: 617	***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) Last edited by Shadowfire; 19 August 2009 at 20:09. Reason: typos, add description

21 August 2009, 17:33	#429
Shadowfire Registered User Join Date: Aug 2001 Location: Connecticut USA Posts: 617	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. Last edited by Shadowfire; 22 August 2009 at 00:00.

22 August 2009, 20:44	#433
Shadowfire Registered User Join Date: Aug 2001 Location: Connecticut USA Posts: 617	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 Code: .. 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. Last edited by Shadowfire; 22 August 2009 at 21:15.

23 August 2009, 07:25	#435
Shadowfire Registered User Join Date: Aug 2001 Location: Connecticut USA Posts: 617	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) Last edited by Shadowfire; 23 August 2009 at 07:38.

16 August 2009, 12:47	#421
alanh Registered User Join Date: Sep 2008 Location: Flintshire, UK Posts: 12	Are the schematics/specs for this available ? I can't see to locate anything in this thread. Thanks.

17 August 2009, 06:22	#423
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,602	Seems you're reading with the CPU, why use chipmem as buffer?

21 August 2009, 02:03	#426
Shadowfire Registered User Join Date: Aug 2001 Location: Connecticut USA Posts: 617	8/20: SRAM access and block copy functions rewritten in MIPS32 assembler. Overall performance improvements of 7%-10%.

21 August 2009, 10:21	#427
Zetr0 Ya' like it Retr0? Join Date: Jul 2005 Location: United Kingdom Age: 49 Posts: 9,768	@Shadowfire your like a machine man! some awesome stuff, something tells me you are really enjoying it!

21 August 2009, 15:21	#428
gizmomelb Registered User Join Date: Sep 2005 Location: melbourne Age: 55 Posts: 541	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

25 August 2009, 23:39	#439
Shadowfire Registered User Join Date: Aug 2001 Location: Connecticut USA Posts: 617	A little update. 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. Code: 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 Last edited by Shadowfire; 26 August 2009 at 02:13.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
GVP1230+ Accel Board Jumper settings?	gtrmn01	support.Hardware	3	03 September 2013 20:21
Having trouble creating HDD for 1.3 A500	trydowave	support.WinUAE	26	14 February 2013 16:04
SFS on A600 020 KS 2.0	demolition	support.Other	27	22 December 2012 18:46
68060 board stuck in an A500 or A600 - impossible goal?	Photon	support.Hardware	17	04 October 2009 15:09
WTB: A500 Accel Must Have Switch to Go Back to 68K Mode	kjmann14	MarketPlace	0	26 March 2009 21:01