English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 13 September 2014, 11:50   #41
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 11,941
Do no SD cards support mulitibit SPI?

We use quad bit SPI Prom devices here at work.
alexh is offline  
AdSense AdSense  
Old 13 September 2014, 12:03   #42
ferix
Registered User
ferix's Avatar
 
Join Date: Sep 2009
Location: Spain
Age: 40
Posts: 95
Yes, they do in nibbles (4 bits), but it's only mandatory for high speed cards.
And there's no benefit in my case, I just read and write bytes.
The serial SPI transfer is achieved at very high speeds (from the amiga point of view), so you have your byte transmitted and/or received faster than the cpu can get them from the main memory.

In case you're interested:
https://www.sdcard.org/downloads/pls...partE1_100.pdf
and
https://www.sdcard.org/downloads/pls.../part1_410.pdf

Last edited by ferix; 13 September 2014 at 12:40.
ferix is offline  
Old 13 September 2014, 13:54   #43
kamelito
Zone Friend
kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 829
Quote:
Originally Posted by JimDrew View Post
I need to transfer hundreds of megs of Amiga source code from a real A3000 (and then an A4000) to my PC so I can copy the data I want to a SD card for use with FPGA Arcade Replay. I can also use this data with WinUAE and FS-UAE. So, I don't want to go the floppy route. I also don't want to use CrossDOSFileSystem or something similar to handle the PC format. I have a super fast FAT32 handler I wrote for the PIC24 that will outrun this by a mile. The theoretical max transfer for the parallel port is 715K per second (every bus cycle). Obviously, your're not going to get that, but you could likely get a couple of hundred K per second. That ZIP interface has a lot of control stuff to setup and it's getting 114K per second. I would be happy with that. I could make it so this device also handles block-level transfers. I already have empscsi.device written, so I could just gut the 53C80 code and implement this. It handles SCSI-direct commands and such as well. So, I guess the device could be dual purpose. This biggest issue I see is that this needs external power because the parallel port only has 10mA of current available.
I also love to have such device to transfer my A3000 files. Kamelito
kamelito is offline  
Old 13 September 2014, 19:16   #44
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 496
In my case I don't have to do the switching of the DDR (data direction register) for every byte, just a couple of times per every block (512 bytes). I can move an entire block keeping the DDR set one direction. The ZIP drive interface (linked to earlier in this thread) is similar to what I am doing, but that has even more setup so I expect faster speeds than that. I expect around 100KB per second with a stock A500 and much faster on accelerated machines.
JimDrew is offline  
Old 13 September 2014, 21:25   #45
ferix
Registered User
ferix's Avatar
 
Join Date: Sep 2009
Location: Spain
Age: 40
Posts: 95
Yeah, I know.
I can't wait to see what you would get.
ferix is offline  
Old 14 September 2014, 03:38   #46
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by JimDrew View Post
That's not actually true. There are specific byte combinations that trigger certain things when dealing with MFM data and flux level data. Paula is by far more carefree than the WD177x series, but you still can't use every byte (0x00-0xFF) in the MFM data. I know a little bit about Paula and floppy drives... I created Supercard Ami, Supercard Ami II, SYBIL, and AMIA hardware devices for the Amiga to copy/image floppy disks. I make a product right now that also images/copies floppys:

http://www.cbmstuff.com/proddetail.php?prod=SCP

Besides giving you the ability to backup your software, this product creates flux-level images that can be used under WinUAE, FS-UAE, E-UAE, and FPGA Arcade Replay to give you an exact emulation of a real disk, just as real hardware (Paula) sees it.
But it still not clear - are some bytes trigger particular Paula behavior or not?
And once again - when transferring data trough fdd interface there is no such things as flux - flux is unique for magnetic domains but not for serial port.

So i assume fdd interface can be used as just plain serial interface with DMA. Issue of course will be to recover clock. So perhaps synchronization should be designed based on different principle than MFM.


Quote:
Originally Posted by JimDrew View Post
Serial would be too slow. The parallel port is the "printer port", and that is what I am using.
And why You think that serial port (UART in Pula) is slow - 1Mbps or more should be available as Paula use 1.79MHz clock - issue can be interrupt processing when reading, writing can be performed with Copper help.
pandy71 is offline  
Old 14 September 2014, 07:08   #47
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 496
Paula only handles flux data, and there are many patterns that you can not use. Paula samples data at a maximum of 2us per bitcell, which converts to either 10, 100, or 1000. However, those values require 4us/6us/8us bitcell times with the Amiga format. It's not even remotely close to serial data, it's a disk controller. So, yes there are limitations, like you can't write more than three consecutive 0 bits in a row. Writing more than three 1 bits in a row is interpreted as a 00 byte, etc.

To use the floppy port you would have to emulate a flux data stream. There are always two bytes of MFM data required to extract a single byte of usable data. If you could just send serial data, we wouldn't need FM, MFM, GCR, or any other type of encoding method - we would just write the byte to the disk.


The Amiga serial port is pretty slow. I wrote several serial device drivers (in assembly of course) and the same core driver worked fine at 230400 baud with EMPLANT's serial port on a stock A2000, but the Amiga serial port would barely do 115200 baud.

Last edited by JimDrew; 14 September 2014 at 07:24.
JimDrew is offline  
Old 14 September 2014, 13:07   #48
Yulquen74
Registered User
 
Join Date: May 2013
Location: Kleppe / Norway
Posts: 162
Jim: When this fine project matierializes into a mature and usable state, have you any plans to either

- sell complete, assembled boards ready to use
- sell non assembled boards bundled with programmed PIC (and perhaps all remaining parts) as a kit
- release schematics and hex files for complete diy building
- opensourcing the entire project
- none of the above
Yulquen74 is offline  
Old 14 September 2014, 13:35   #49
kamelito
Zone Friend
kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 829
Quote:
Originally Posted by JimDrew View Post
Paula only handles flux data, and there are many patterns that you can not use. Paula samples data at a maximum of 2us per bitcell, which converts to either 10, 100, or 1000. However, those values require 4us/6us/8us bitcell times with the Amiga format. It's not even remotely close to serial data, it's a disk controller. So, yes there are limitations, like you can't write more than three consecutive 0 bits in a row. Writing more than three 1 bits in a row is interpreted as a 00 byte, etc.

To use the floppy port you would have to emulate a flux data stream. There are always two bytes of MFM data required to extract a single byte of usable data. If you could just send serial data, we wouldn't need FM, MFM, GCR, or any other type of encoding method - we would just write the byte to the disk.


The Amiga serial port is pretty slow. I wrote several serial device drivers (in assembly of course) and the same core driver worked fine at 230400 baud with EMPLANT's serial port on a stock A2000, but the Amiga serial port would barely do 115200 baud.
So if you've an Emplant board on your Amiga it'll be faster right?

Kamelito
kamelito is offline  
Old 14 September 2014, 16:08   #50
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by JimDrew View Post
Writing more than three 1 bits in a row is interpreted as a 00 byte, etc.

Interpreted by CPU? Paula? or by flux change on magnetic disk but not on semiconductor memory ?

Quote:
Originally Posted by JimDrew View Post
To use the floppy port you would have to emulate a flux data stream. There are always two bytes of MFM data required to extract a single byte of usable data. If you could just send serial data, we wouldn't need FM, MFM, GCR, or any other type of encoding method - we would just write the byte to the disk.
Yes but only when magnetic recording is involved... all you wrote about flux is valid for magnetic storage but we saving bitstream to semiconductor memory without this limitations. So let forget about flux and all magnetic problems - if this is limitation of Paula (AFAIK Paula not interpreting any data).

Quote:
Originally Posted by JimDrew View Post
The Amiga serial port is pretty slow. I wrote several serial device drivers (in assembly of course) and the same core driver worked fine at 230400 baud with EMPLANT's serial port on a stock A2000, but the Amiga serial port would barely do 115200 baud.
Hardware is fast but primitive (no fifo like in common on PC 16550 etc) - drivers are slow as interrupt processing take time but once again as we can send block of data (for example 16 bytes) then perhaps overhead can be reduced...
I assume that based on this:
http://amigadev.elowar.com/read/ADCD.../node01A1.html
1Mbps should be possible especially when slow and outdated 1488/1489 will be replaced by modern level translators.
pandy71 is offline  
Old 14 September 2014, 16:50   #51
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 496
Quote:
Originally Posted by kamelito View Post
So if you've an Emplant board on your Amiga it'll be faster right?

Kamelito
Yes. You could network two Amigas at 230400 baud using an EMPLANT board in each Amiga. In fact, both serial ports on the EMPLANT board could run 230400 baud at full speed simultaneously.
JimDrew is offline  
Old 14 September 2014, 16:56   #52
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 496
Quote:
Originally Posted by pandy71 View Post
Interpreted by CPU? Paula? or by flux change on magnetic disk but not on semiconductor memory ?
Paula. This is a standard limitation of all disk controllers. It's a condition that must be met. Paula sends and receives bitcell time (flux) data. That data must meet certain criteria to be valid or random data is interpreted.

Quote:
Yes but only when magnetic recording is involved... all you wrote about flux is valid for magnetic storage but we saving bitstream to semiconductor memory without this limitations. So let forget about flux and all magnetic problems - if this is limitation of Paula (AFAIK Paula not interpreting any data).
It's not a "limitation" really, it's a design requirement for MFM data. Paula also works with GCR data, but that also has some features (by design) that prohibit every byte value from being available.


Quote:
Hardware is fast but primitive (no fifo like in common on PC 16550 etc) - drivers are slow as interrupt processing take time but once again as we can send block of data (for example 16 bytes) then perhaps overhead can be reduced...
I assume that based on this:
http://amigadev.elowar.com/read/ADCD.../node01A1.html
1Mbps should be possible especially when slow and outdated 1488/1489 will be replaced by modern level translators.
We don't have that luxury in a stock setup.
JimDrew is offline  
Old 14 September 2014, 18:01   #53
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by JimDrew View Post
Paula. This is a standard limitation of all disk controllers. It's a condition that must be met. Paula sends and receives bitcell time (flux) data. That data must meet certain criteria to be valid or random data is interpreted.

AFAIK Paula is not standard FDD controller - this is plain parallel to serial and seriall to parallel converter with DMA + some features to help deal with things typical for FDD - but data stream decoding is performed in a software way (or by CPU or by blitter).

Quote:
Originally Posted by JimDrew View Post
It's not a "limitation" really, it's a design requirement for MFM data. Paula also works with GCR data, but that also has some features (by design) that prohibit every byte value from being available.
What with different RLL coding than 1.3 - for example 1.7 or other - there are some device drivers to provide higher than MFM capacity on FDD.


Quote:
Originally Posted by JimDrew View Post
We don't have that luxury in a stock setup.
Unless there is no long cable (capacity) 1488/1489 should be fine.
pandy71 is offline  
Old 14 September 2014, 20:44   #54
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 496
Quote:
Originally Posted by Yulquen74 View Post
Jim: When this fine project matierializes into a mature and usable state, have you any plans to either

- sell complete, assembled boards ready to use
- sell non assembled boards bundled with programmed PIC (and perhaps all remaining parts) as a kit
- release schematics and hex files for complete diy building
- opensourcing the entire project
- none of the above
Likely assembled/tested units and kits.
JimDrew is offline  
Old 14 September 2014, 20:50   #55
vext01
Registered User
 
Join Date: Nov 2012
Location: UK
Posts: 124
Quote:
Originally Posted by JimDrew View Post
With the advent of all of the various FPGA Amiga emulators, as well as software based Amiga emulators (for PC, iPhone, iPad, etc.) it seems that the biggest battle still is how to get data from a real Amiga over to the emulator.
Not an SD card solution, but what I do is take the CF from my Amiga 600 and plug it into my laptop running fs-uae. From there you can point the emulator at the raw device node of the CF and th emulator will boot it. By also making a dummy "directory" hard disk, you can easily copy files to and from the Amiga CF.

My low tech solution for the A500 is to use a terminal emulator and send files over the serial line with XMODEM, although you still need to get the terminal emulator over to the amiga in the first place. I seem to recall using the AmigaDOS 'type' command to send files over the serial line as described here:
http://adfsender.stoeggl.com/adfsend...ethods.html#A1


type ser: to ram:filename

Hope that helps.
vext01 is offline  
Old 14 September 2014, 20:58   #56
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 496
Quote:
Originally Posted by pandy71 View Post
AFAIK Paula is not standard FDD controller - this is plain parallel to serial and seriall to parallel converter with DMA + some features to help deal with things typical for FDD - but data stream decoding is performed in a software way (or by CPU or by blitter).
Paula does not use any type of serial data stream. Just like other disk controllers, it clocks bitcell times that are provided from a floppy drive. This is nothing even close to serial data. Flux to data conversion (MFM or GCR, depending on how you set Paula) is the function of Paula's disk controller. You can see how Paula's disk controller circuitry works by looking up the patent that Commodore had for Paula. There is a PLL, missing clock detector, sync detector, etc. Its a rather complex device, and far more flexible than the WD177x controllers of the same era in that it doesn't frame sectors and can provide raw MFM data. The incoming (and outgoing) data is restricted to the legal MFM or GCR values. Hence, no more than three 0 bits in a row for MFM, you can't use FF (and other illegal values), etc. There are different rules for GCR.

I made dozens of things (disk copiers, device drivers, and utilities) that poked directly at Paula. I also just got done helping MikeJ (FPGA Arcade Replay) with the FPGA implementation of Paula for the Amiga core. I know even the undocumented quirks that Paula's disk controller has.

Last edited by JimDrew; 14 September 2014 at 21:09.
JimDrew is offline  
Old 14 September 2014, 21:12   #57
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 496
Tinkered with the board layout today. I still have all of my design files for SYBIL so I already had a parallel port layout done... just need to add the SD card and PIC - and keep the entire thing within a DB-25 plastic hood.
JimDrew is offline  
Old 14 September 2014, 23:08   #58
Retro1234
5150

Retro1234's Avatar
 
Join Date: Jun 2006
Location: Sycophantazia
Posts: 3,776
I always thought this looked good http://eab.abime.net/showthread.php?p=709005#post709005
its a shame theres no HardDrive support for floppy emulators yet.
Retro1234 is offline  
Old 15 September 2014, 00:27   #59
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 496
Hard drive emulation for floppy emulators would be really slow because of having to go through Paula. I have two serial ports on the SuperCard Pro board (which is getting the firmware update to be a floppy emulator like the HxC and Grotek devices), so I could use either of these connected to a CIA or something for hard drive emulation.
JimDrew is offline  
Old 15 September 2014, 01:03   #60
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by JimDrew View Post
Paula does not use any type of serial data stream. Just like other disk controllers, it clocks bitcell times that are provided from a floppy drive. This is nothing even close to serial data. Flux to data conversion (MFM or GCR, depending on how you set Paula) is the function of Paula's disk controller. You can see how Paula's disk controller circuitry works by looking up the patent that Commodore had for Paula. There is a PLL, missing clock detector, sync detector, etc. Its a rather complex device, and far more flexible than the WD177x controllers of the same era in that it doesn't frame sectors and can provide raw MFM data. The incoming (and outgoing) data is restricted to the legal MFM or GCR values. Hence, no more than three 0 bits in a row for MFM, you can't use FF (and other illegal values), etc. There are different rules for GCR.
Yes, i've read this patent - there not many details there and all You saying is different than HRM this why i ask...


Quote:
Originally Posted by JimDrew View Post
I made dozens of things (disk copiers, device drivers, and utilities) that poked directly at Paula. I also just got done helping MikeJ (FPGA Arcade Replay) with the FPGA implementation of Paula for the Amiga core. I know even the undocumented quirks that Paula's disk controller has.
I know, You've wrote this multiple times however seems that all those things was related to floppy and magnetic storage.
pandy71 is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
PCMCIA CF card adapter, that I can buy online? theshinyknight support.Hardware 13 07 November 2013 08:52
CF Card or Adapter Problem spanner support.Hardware 12 30 July 2012 19:38
Transcend - Card adapter ( CF I ) - PC Card spannernick support.Hardware 6 09 May 2012 21:58
PCMCIA adapter with 256mb CF Card issue smeghead support.Hardware 6 01 July 2011 11:23
A4000D cf card adapter and cdrom heALer support.Hardware 39 23 January 2011 22:05

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:13.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.32464 seconds with 11 queries