Terrible Fire Accelerators

[8 Bit Dreams]

Originally Posted by plasmab

I actually transferred the build from my laptop to the desktop via dropbox. The version that is up there works for me. I didnt try the rev 2 to be fair.

EDIT: I have all the stuff i need for testing an A2000 in the post. (Pico ATX PSU, Keyboard Adaptor and A2000 motherboard)

tried RC2 just right now - works nice on A500, still no luck on A2000, picture remains corrupted

[alenppc]

Just flashed RC2 on two rev2 cards, unfortunately the slow ram issue persists, same as before.

[EzdineG]

Originally Posted by alenppc

Just flashed RC2 on two rev2 cards, unfortunately the slow ram issue persists, same as before.

Confirmed :/

[EDIT]
Also noticed about 300K more available RAM in Workbench with RC2.
SYSTEST reports the slow RAM region as 00c00000 - 00dbffff with this firmware, 00c00000 - 00d7ffff with working firmware.
Created a bug report on GH.

[plasmab]

Originally Posted by EzdineG

Confirmed :/

[EDIT]
Also noticed about 300K more available RAM in Workbench with RC2.
SYSTEST reports the slow RAM region as 00c00000 - 00dbffff with this firmware, 00c00000 - 00d7ffff with working firmware.
Created a bug report on GH.

Ah poo. I had thought the cached area was being detected as RAM. Trouble is I don’t have a reproductive setup. The plain A500 trapdoor ram appear here?

[alenppc]

The plain trapdoor ram works fine since it's limited to 512K. This happens using PeteAU's open source 2 MB trapdoor expansion (512K chip + 1.5 MB slow-fast).

I would be happy to build and send you one of those for testing but finding the compatible ram chips is a pain in the butt. I can't get the rev b to work with any chips and while the rev C works fine, I am waiting eternally to get compatible chips from Ali Express (2 months now, still no sign of them).

[solidcore]

Regarding the A500 is there any mainboard rev's I should stay clear of for the tf530 rev 3... ?

[EzdineG]

Originally Posted by solidcore

Regarding the A500 is there any mainboard rev's I should stay clear of for the tf530 rev 3... ?

We’ve tested Rev 5,6,8 with no issue. Nobody here has a 3, but should be fine.

[solidcore]

Originally Posted by EzdineG

We’ve tested Rev 5,6,8 with no issue. Nobody here has a 3, but should be fine.

Thanks that really helps a bunch Appreciated.

[plasmab]

Originally Posted by alenppc

The plain trapdoor ram works fine since it's limited to 512K. This happens using PeteAU's open source 2 MB trapdoor expansion (512K chip + 1.5 MB slow-fast).



I would be happy to build and send you one of those for testing but finding the compatible ram chips is a pain in the butt. I can't get the rev b to work with any chips and while the rev C works fine, I am waiting eternally to get compatible chips from Ali Express (2 months now, still no sign of them).

I have a trapdoor expansion. It doesn’t attach to Garry though?

[alenppc]

Yes, you also need a gary adapter for the thing to function but it's a very simple board which is included as part of the gerber files already.

[Mathesar]

Originally Posted by plasmab

A start on the SPI port docs.

https://github.com/terriblefire/tf53...PI-Port-(alpha)

I had a look at the wiki and everything seems very clear to me.

A few questions / observations though:

• A read from the data register automatically starts a new transfer. I assume you do this for reading blocks of data without the overhead of having to start a transfer. But, will this work with other devices if you have to do a write just after a read? What is send out the MOSI line when a transfer is started by a read?
• During an MMC/SD init procedure the SPI clock first has to be very low (100..400khz or so) and then later on it can be bumped up to 25MHz. What is the clock speed on the TF530 and would it be possible to add some bits to control the clock speed?
• is an interrupt useful? At 25MHz clock speed, a transfer takes only 320ns so an interrupt wil come very quickly. At lower speeds though the interrupt makes perfectly sense.

Native support for an SD card would be the perfect thing to have on an Amiga I have been tinkering with Mika Leikonen's a500ide project to fix some small bugs and add some speedups. The full source code is available and is easily adapted to an SD card. The only problem it is doesn't support RDB (rigid disk block). It might be a good starting point though....

[plasmab]

Originally Posted by Mathesar

I had a look at the wiki and everything seems very clear to me.

A few questions / observations though:

• A read from the data register automatically starts a new transfer. I assume you do this for reading blocks of data without the overhead of having to start a transfer. But, will this work with other devices if you have to do a write just after a read? What is send out the MOSI line when a transfer is started by a read?
  

• MOSI is high during a read. A read loads the shift register with 1's.
  
  

  During an MMC/SD init procedure the SPI clock first has to be very low (100..400khz or so) and then later on it can be bumped up to 25MHz. What is the clock speed on the TF530 and would it be possible to add some bits to control the clock speed?

  Maybe. I will try and squeeze in more stuff for this later. The space available is very tight. I want to suck this and see first. Most cards dont care in my experience.
  
  

  is an interrupt useful? At 25MHz clock speed, a transfer takes only 320ns so an interrupt wil come very quickly. At lower speeds though the interrupt makes perfectly sense.

The interrupt is nothing to do with the byte exchange. Its a separate pin that NICs can use to generate INT2. It was asked for explicitly by someone for NICs. To be clear a transfer completion does not generate an interrupt.

I guess a sound card may want to generate an INT2 when the buffer is getting low too etc etc. Its a General purpose interrupt.

Native support for an SD card would be the perfect thing to have on an Amiga I have been tinkering with Mika Leikonen's a500ide project to fix some small bugs and add some speedups. The full source code is available and is easily adapted to an SD card. The only problem it is doesn't support RDB (rigid disk block). It might be a good starting point though....

The SPI exchange code is derived from Mike Stirlings zxmmc code. And i've used it in Atari ST, BBC and Speccy FPGA implementations. So its known good.

[Mathesar]

Originally Posted by plasmab

MOSI is high during a read. A read loads the shift register with 1's.

Maybe. I will try and squeeze in more stuff for this later. The space available is very tight. I want to suck this and see first. Most cards dont care in my experience.

The interrupt is nothing to do with the byte exchange. Its a separate pin that NICs can use to generate INT2. It was asked for explicitly by someone for NICs. To be clear a transfer completion does not generate an interrupt.

I guess a sound card may want to generate an INT2 when the buffer is getting low too etc etc. Its a General purpose interrupt.

I understand. It's a nice and straightforward SPI interface!

The SPI exchange code is derived from Mike Stirlings zxmmc code. And i've used it in Atari ST, BBC and Speccy FPGA implementations. So its known good.

I was more thinking about the Amiga driver / filesystem interface part.
The zxmmc code which deals with the SD card needs to be interfaced to the Amiga OS somehow and Mika Leikonen's code might be a good starting point. The only limitation is that it doesn't support RDB. Maybe a coder here on the forum would be willing to take on the task? I know how Mika's driver works but adding the rdb code is something I have never done before.

Potentially we could have a new mmc.device which could replace ide.device in a custom rom....

[Toni Wilen]

Originally Posted by plasmab

I guess a sound card may want to generate an INT2 when the buffer is getting low too etc etc. Its a General purpose interrupt.

It probably needs to be INT6 for stable realtime sound (like Toccata which only has 1k buffer but still can easily keep up without glitches)

I was more thinking about the Amiga driver / filesystem interface part.
The zxmmc code which deals with the SD card needs to be interfaced to the Amiga OS somehow and Mika Leikonen's code might be a good starting point. The only limitation is that it doesn't support RDB. Maybe a coder here on the forum would be willing to take on the task? I know how Mika's driver works but adding the rdb code is something I have never done before.

Where? I won't promise anything but I can check if it can be easily extended and looks good enough

Potentially we could have a new mmc.device which could replace ide.device in a custom rom....

ide.device?

[Mathesar]

Originally Posted by Toni Wilen

Where? I won't promise anything but I can check if it can be easily extended and looks good enough
ide.device?

Oops, I meant scsi.device of course .

The a500ide project can be found here:
http://www.mkl211015.altervista.org/ide/a500ide.html

I have an updated version at home which I can post tonight. The above version hangs when you let hdtoolbox search for an unconnected second ide drive. I have fixed that.

[plasmab]

I created a driver. I already said this.

I merged roger burrows code into the mntsd.device from the VA2000. Its buggy but checked into the spi_alpha branch on GitHub

[Mathesar]

Originally Posted by plasmab

I created a driver. I already said this.

I merged roger burrows code into the mntsd.device from the VA2000. Its buggy but checked into the spi_alpha branch on GitHub

I missed that! Going to have a look tonight.

[plasmab]

Originally Posted by Mathesar

I missed that! Going to have a look tonight.

It doesn’t work very well yet but the code is there along with the alpha firmware for anyone to contribute too. It’s based off the SD.c code in the bios of EmuTOS.

[plasmab]

Originally Posted by plasmab

It doesn’t work very well yet but the code is there along with the alpha firmware for anyone to contribute too. It’s based off the SD.c code in the bios of EmuTOS.

It’s only using CS0 at the moment

[plasmab]

@Mathesar re the slow clock... i could use a bit in the control register to force the CLK line low when set and unsettling will let it come from the low bit of the shift register... the effect would be the ability of the CPU to sent 74 slow clock pulses and avoid having to do that in the CPLD..