Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: Aasync SD card operations?

  1. #1
    Junior Member
    Join Date
    Dec 2020
    Posts
    12

    Aasync SD card operations?

    For a project we are using a Teensy 4.1 together with a custom PCB to replace the original PCB set in an old arcade game from 1981. As it is a vector based game the custom PCB contains 2 SPI DACs for x/y and a 4 bit resistor DAC for the intensity. A timer is used to ensure that these DACs are updated (FlexIO & GPIO) with a fixed 1.5MHz interval. There is although a PT8211 connected to SAI2. It uses a interrupt based updates with 125KHz. The isr emulates the two audio chips (AY3-8910) used on the original PCB. The main loop emulates two Z80 CPUs (3MHz & 1.5MHz) and the attached components synchronized to the 1.5MHz timer. This all works create and the game looks, sounds and play already like with the original PCB.

    But there is one last issue. The original PCB has a 256x4Bit battery buffered RAM to store high scores and other statistic. The idea is to store these data on the SD card that already contains the settings and the ROM files. Unfortunately I noticed that saving the 256 nibbles take multiple milliseconds and it is a blocking operation. The time itself is not the problem as it would be enough to update the data on the card only from time to time. The issue is that during the safe the emulation stops. We like to avoid this. Based on the code for the SD card it spend most time just waiting for data transfers to be finished. This let me believe that it should be possible to rewrite the SD card code that it runs asyncron.*Have someone tried this before?

    In our case it should be enough to just update the same sector every time we want to save an update. Updating the access time in the FAT is not that important. Neither*will the file every change it's size.

  2. #2
    Member
    Join Date
    Aug 2018
    Location
    Brisbane, Australia
    Posts
    79
    Does the amount of data you need to save not fit in the (emulated) EEPROM?

  3. #3
    Junior Member
    Join Date
    Dec 2020
    Posts
    12
    Yes, but as it updated quite often I am hesitate*to use it as it will wear down and cannot easily replaced. After some more thinking about it I might just move the CPU emulation from the main loop to another timer interrupt*with a lower priority. This way it will not matter if the file io blocks the main loop for a few milliseconds. The emulated CPUs will still run and the DAC updates can still interrupt them.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •