I still have Rev0, it is different mpu. Only thing that it can be used for is usb keyboard, and only few will actually would work, as f105 has very buggy usb stack, and a lot of devices simply refuse to talk to it.RetroFletch wrote: ↑Sat Jan 09, 2021 1:07 pm Hello everyone, just a quick question, lets say someone verry tired and in a hurry to get a pcb order done went ahead and ordered the Rev0 PCBs by misstake... can these be used at all? just as simple passive risers? video out? or just expensive drink coasters? Looks in eagle that all signals are passed thru correctly and that the DB23 should work aswell? what would i need to populate other then connectors?
Anyways, im happy to see so much effort going into this i probably spent way to much time rading thru this thread, keep up the good work!
TF CD32 Riser Revision 2 Design Complete
Moderators: terriblefire, Terriblefire Moderator
- arkadiusz.makarenko
- Moderator Team
- Posts: 1208
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
Re: TF CD32 Riser Revision 2 Design Complete
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
- arkadiusz.makarenko
- Moderator Team
- Posts: 1208
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
Re: TF CD32 Riser Revision 2 Design Complete
I have noticed one thing with riser. After releasing sometimes override "CIA" gets a little bit crazy and values in registers are CIAPPRB are wrong, this causes that on workbench floppy drive icons (df0-4) appear. I am not sure how I can fix this.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
- arkadiusz.makarenko
- Moderator Team
- Posts: 1208
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
Re: TF CD32 Riser Revision 2 Design Complete
I will have a look at this again.terriblefire wrote: ↑Mon Nov 30, 2020 10:55 pmThe best source of information will be WinUAE sources.arkadiusz.makarenko wrote: ↑Mon Nov 30, 2020 8:29 pm @terriblefire
Is there a standard for communication on those cards at all, or are they have proprietary drivers?
Do we have anything to start looking at?
The Prelude 1200 is probably the best choice but i've only spent 10 mins thinking about it.. We dont want to do be doing DSP in the ARM.. thats too much work for it.
The prelude 1200 has a Crystal Semiconductor Sound Codec 4231A chip in it ... datasheet CS4231A_ETC.pdf
There will be code in WinUAE to show how its mapped in memory.. but thats the simplest candidate for a soundcard?
Do you think arm<=>amiga commutation speed is still good enough with 1us cycles?
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
-
- Moderator Team
- Posts: 5389
- Joined: Mon Aug 28, 2017 10:56 pm
- Location: Glasgow, UK
Re: TF CD32 Riser Revision 2 Design Complete
I dont think audio will be fast enough at that speed. But i could be wrong.
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
- arkadiusz.makarenko
- Moderator Team
- Posts: 1208
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
Re: TF CD32 Riser Revision 2 Design Complete
I will try to do prove of concept and as a backup I started looking at stm32H750 (460mhz with apparently lower interrupt latency), but smallest package is 100pin though.terriblefire wrote: ↑Wed Jan 13, 2021 8:34 am I dont think audio will be fast enough at that speed. But i could be wrong.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
- arkadiusz.makarenko
- Moderator Team
- Posts: 1208
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
Re: TF CD32 Riser Revision 2 Design Complete
I have a plan for prove of concept
I will look for INTSIG on its own EXTI line, and will decode only 1 addres2 for it, so this way I will need to read only one bit from address line (one read) to check which side of word it is. As it will be read only addresses no need to check for RW as well, no need to reprogram data lines. So audio data read might be much faster than other interrupts. I will measure it do some math and decide if I will continue work on the rest.
Then I would write program to fill buffer with MP3 data.
So I will have following addresses
- address - is buffer full/clear buffer
- write data to buffer as quickly as possible
Initial process would be to clear buffer and fill buffer in 100%, then check if there is enough space to write and fill when possible.
on ARM side
DMA form read buffer for decoding on half full, decode mp3 (need to think of strategy how this would be triggered ) and dma data to dac buffer for output.
I will look for INTSIG on its own EXTI line, and will decode only 1 addres2 for it, so this way I will need to read only one bit from address line (one read) to check which side of word it is. As it will be read only addresses no need to check for RW as well, no need to reprogram data lines. So audio data read might be much faster than other interrupts. I will measure it do some math and decide if I will continue work on the rest.
Then I would write program to fill buffer with MP3 data.
So I will have following addresses
- address - is buffer full/clear buffer
- write data to buffer as quickly as possible
Initial process would be to clear buffer and fill buffer in 100%, then check if there is enough space to write and fill when possible.
on ARM side
DMA form read buffer for decoding on half full, decode mp3 (need to think of strategy how this would be triggered ) and dma data to dac buffer for output.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem