Hello, Guest the thread was called1.5k times and contains 10 replays

last post from Sgw32NULLchar at the

UltiSID - new STM32 SID chip replacement

  • Hi everyone!


    First of all, I am sorry, I can't write in Deutsch since I am from Russia, my native language is Russian :)


    image.png


    image.png

    image.png


    Link to GitHub repository https://github.com/Sgw32/UltiSID/tree/hal_usid


    Schematic: https://github.com/Sgw32/UltiS...ltiSID.pdf


    It is time to release one of my new project UltiSID.

    Open source SID chip replacement 8580/6581 emulator that can be executed on Bluepill boards and STM32F103


    License - GNU General Public License v3 (derived from Bakisha STM32 SID player)


    Introduction


    Project is heavily inspired by SwinSID and ArmSID project. And is maintained as an open-source alternative to them. Now it is even working on a STM32F103C8T6 on an overclocked freq 128 MHz with 8 MHz crystal. With some errors in behavior - some readings/writings from CPU are missing. I'm looking for contributers(I can even pay for the work) who will add some assembler optimization magic into my code. Also I plan releasing Altium Designer PCB hardware files publicly available right after I'll sell 10 copies of UltiSIDs to public.Working in a time-stretched and computation-intensive environment of C64 requires hardcore optimization of code. We have only 500ns for interrupt processing. Project is still in a very early stage of development


    So why UltiSID? Why Ulti? I think that open-source contributions make our planet better, and since, the open-source alternative to SwinSID and ArmSID is still better than closed solutions. In 2021 there are still no any good SID emulators publicly available. 2021, Carl!


    Chip support - it supports STM32F103C8T6 and STM32F405RCT6 both(but not at the same time Very Happy )


    Credits and special thanks

    Future plans


    STM32F103 has a very long delay between CS fall down and interrupt routine begin - about 200ns. With a 500 ns window at all. I plan migrating to STM32F405RCT6(still, very cheap on Aliexpress) my PCB also supports it. Also, I should optimize RW&CS routines to enhance performance.


    Limitations


    We have a 256b buffer for SID data, and it is processed in main cycle. Seems enough, but sometimes I hear that it is not.

    Pitch is not calibrated

    Data readings are not correct at event-intensive tunes(where there are a lot of write-to-SID activities)

    No 6581/8580 switch

    No paddles(sorry, no reads)


    Support us

    PayPal Me:

    https://paypal.me/sgw32

    Or buy something here (3d print models):

    https://www.cgtrader.com/sgw32


    Video(and audio) PoC:

    https://www.youtube.com/watch?v=_ROxem-S0Jo

  • Now it is even working on a STM32F103C8T6 on an overclocked freq 128 MHz

    Wow, that's quite a large overclocking factor. Do you know if your code works on the various STM32F103 clones that seem to have become prevalent on Bluepill boards?

  • In this project I've used such a clone, just resoldered MCU from it using hot air :) It works.
    So it will, but it now works in extreme frequency conditions. I'll even test it on 160 MHz(10 MHz * 16 PLL) in a few days. And I plan testing with 128 MHz&NOR logic for CS&RW (approved read operation) - it will help to optimize the code, save interrupt time for MCU.

    This code is the most difficult part to optimize:

    The first two lines are executed ~20-30ns before the end of 1 data transfer cycle.

  • The first two lines are executed ~20-30ns before the end of 1 data transfer cycle.

    Have you tried running the interrupt handler from RAM instead of flash? It needs a few tweaks in the linker script and some additional code to copy it during startup, but RAM usually has no wait states in these chips and flash only fakes zero waitstates by using a cache. In the STM32F103 that cache is tiny, so chances are high that it must be reloaded on every interrupt, increasing the latency.


    I'm not 100% certain if it will work on this chip though, the block diagrams in the reference manual claim that the instruction bus is only connected to the flash, but not the main bus matrix. IIRC there are newer STM32 ARM chips that are better for this trick because they have some RAM dedicated for code/data that is tightly coupled to the core, guaranteeing low latency by avoiding any stalls in the bus matrix.

  • IMHO "UltiSID" is a rather bad decision, since the emulated SIDs in the Ultimate64-Board are called "UltiSID"s, too.


    I'd go for another fancy name, in this early phase a change doesn't matter.


    STeaMSID?

    IncrediSID?

    HeavySID?

    STorMSID?

    DreamSID?

    OpenSID?

    BlueSID?

    PowerSID?

    ...


    Just my 2 cents.


    [EDIT]


    Oh, sorry, forgot ... really a stunning project - and Open Source! Like it!


    [/EDIT]

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.


    Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.


    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.

    Edited once, last by kinzi ().

  • The first two lines are executed ~20-30ns before the end of 1 data transfer cycle.

    Have you tried running the interrupt handler from RAM instead of flash? It needs a few tweaks in the linker script and some additional code to copy it during startup, but RAM usually has no wait states in these chips and flash only fakes zero waitstates by using a cache. In the STM32F103 that cache is tiny, so chances are high that it must be reloaded on every interrupt, increasing the latency.


    I'm not 100% certain if it will work on this chip though, the block diagrams in the reference manual claim that the instruction bus is only connected to the flash, but not the main bus matrix. IIRC there are newer STM32 ARM chips that are better for this trick because they have some RAM dedicated for code/data that is tightly coupled to the core, guaranteeing low latency by avoiding any stalls in the bus matrix.

    I've heard about it. Definitely worth a try, I'll check for examples in the web.

    I refered Kung Fu Flash for Address/Data routines, however now I see it also uses remap of RAM. Cool thing! However a bit complex at a first glance though :)

  • Thanks for the feedback! Yes, checked out - the name needs to be changed. My first idea is to change to UltiSID32, however I'll try to find some other variants.

  • STMSID would be nice imho. Short name and includes the chip its based on and what it replaces :)

    Thanks!


    Another Teensy-based open source SID in development:

    FREE STEREO SID: Neuentwicklung zum mitmachen

    It is smaller than first revisions, worth a try. Isnt Teensy expensive though? Even 25 EUR is higher than ArmSID price, because Armsid price is its components price+margin :) Still cheaper than real sids though. BTW I'm just tired of SwinSIDs, made ~400-500 pcs of them and sold every unit, still not enough quality of sound.

    Teensy is great because it uses native reSID core.