TF CD32 Riser Revision 3 Design discussion
Moderators: terriblefire, Terriblefire Moderator
- arkadiusz.makarenko
- Moderator Team
- Posts: 1208
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
TF CD32 Riser Revision 3 Design discussion
@terriblefire
1. I was thinking if adding floppy header (most likely due to space on pcb - small custom requiring non standard cable) instead of porting FlashFloppy was solution most people would want?
FF will always be better and more up to date with all bells and whistles people can ever want, than my potential port?
So by providing all floppy signals this could be simpler solution?
If there is enough pins available?
2. Tidy up on Address Lines (?) and INTSIG lines - this could speed up cycles a lot, enabling potential Soundcard solution and direct data access.
3. Learn Eagle...
4. if not enough pins available check if 100pin stm32 would fit on PCB, and if package change is required - stm32H7 (460Mhz) series would be better fit.
1. I was thinking if adding floppy header (most likely due to space on pcb - small custom requiring non standard cable) instead of porting FlashFloppy was solution most people would want?
FF will always be better and more up to date with all bells and whistles people can ever want, than my potential port?
So by providing all floppy signals this could be simpler solution?
If there is enough pins available?
2. Tidy up on Address Lines (?) and INTSIG lines - this could speed up cycles a lot, enabling potential Soundcard solution and direct data access.
3. Learn Eagle...
4. if not enough pins available check if 100pin stm32 would fit on PCB, and if package change is required - stm32H7 (460Mhz) series would be better fit.
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 3 Design discussion
1. The issue with a floppy connector is space and you can really only do a IDC header not a 23 pin D.. .because as you can already see the the 23 pin D on there already eats way too much space.arkadiusz.makarenko wrote: ↑Sat Jan 16, 2021 1:05 pm @terriblefire
1. I was thinking if adding floppy header (most likely due to space on pcb - small custom requiring non standard cable) instead of porting FlashFloppy was solution most people would want?
FF will always be better and more up to date with all bells and whistles people can ever want, than my potential port?
So by providing all floppy signals this could be simpler solution?
If there is enough pins available?
2. Tidy up on Address Lines (?) and INTSIG lines - this could speed up cycles a lot, enabling potential Soundcard solution and direct data access.
3. Learn Eagle...
4. if not enough pins available check if 100pin stm32 would fit on PCB, and if package change is required - stm32H7 (460Mhz) series would be better fit.
2. Yeah i can do that bit for you. It would be good to get that optimized. I screwed up A3 last time.
4. There are a couple of unused pins already on the ARM but what do you want the extra ones for? If we ditch the spi pins between the CPLD and ARM you can reuse them for an SD card. Thats your mass storage. The DAC headers are there for dev but maybe not useable so could be reused.
———
"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 3 Design discussion
terriblefire wrote: ↑Wed Feb 03, 2021 10:34 am1. The issue with a floppy connector is space and you can really only do a IDC header not a 23 pin D.. .because as you can already see the the 23 pin D on there already eats way too much space.arkadiusz.makarenko wrote: ↑Sat Jan 16, 2021 1:05 pm @terriblefire
1. I was thinking if adding floppy header (most likely due to space on pcb - small custom requiring non standard cable) instead of porting FlashFloppy was solution most people would want?
FF will always be better and more up to date with all bells and whistles people can ever want, than my potential port?
So by providing all floppy signals this could be simpler solution?
If there is enough pins available?
2. Tidy up on Address Lines (?) and INTSIG lines - this could speed up cycles a lot, enabling potential Soundcard solution and direct data access.
3. Learn Eagle...
4. if not enough pins available check if 100pin stm32 would fit on PCB, and if package change is required - stm32H7 (460Mhz) series would be better fit.
2. Yeah i can do that bit for you. It would be good to get that optimized. I screwed up A3 last time.
4. There are a couple of unused pins already on the ARM but what do you want the extra ones for? If we ditch the spi pins between the CPLD and ARM you can reuse them for an SD card. Thats your mass storage. The DAC headers are there for dev but maybe not useable so could be reused.
I don't think there is not enough right type of pins available for all above.
For example if DAC is needed, we cannot use PA0-PA7 as PA4 and PA5 are only pins available for DAC, PB0-PB7 used by Data lines, PC port has missing PC5 on this package ...
I am planning to do some tests with DAC and transfer speeds to check if music card idea is achievable at all.
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 3 Design discussion
Yeah i think if you want audio you will need at least a 16 bit databus... or we could do some weird DMA from RAM trick.. but thats not available with the current hardware.arkadiusz.makarenko wrote: ↑Wed Feb 03, 2021 12:50 pm
I don't think there is not enough right type of pins available for all above.
For example if DAC is needed, we cannot use PA0-PA7 as PA4 and PA5 are only pins available for DAC, PB0-PB7 used by Data lines, PC port has missing PC5 on this package ...
I am planning to do some tests with DAC and transfer speeds to check if music card idea is achievable at all.
I think floppy + SD card is doable with current setup. Audio was a mad idea anyways.
———
"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 3 Design discussion
I like the idea of audio, but before squeezing it in CD32 riser, I was planning to test it against A1200 clock port and more beefy stm32H723 550mhz microcontroller first.terriblefire wrote: ↑Wed Feb 03, 2021 12:53 pmYeah i think if you want audio you will need at least a 16 bit databus... or we could do some weird DMA from RAM trick.. but thats not available with the current hardware.arkadiusz.makarenko wrote: ↑Wed Feb 03, 2021 12:50 pm
I don't think there is not enough right type of pins available for all above.
For example if DAC is needed, we cannot use PA0-PA7 as PA4 and PA5 are only pins available for DAC, PB0-PB7 used by Data lines, PC port has missing PC5 on this package ...
I am planning to do some tests with DAC and transfer speeds to check if music card idea is achievable at all.
I think floppy + SD card is doable with current setup. Audio was a mad idea anyways.
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 3 Design discussion
OK.
I have done some measuring (on Rev2)
I wrote a program to pretend to send 8 bytes x 1048576 times, and it takes less than 10sec.
It looks like this, where only work is to insert data to buffer.
Knowing that uncompressed data need 170KB/s and compressed MP3 with 320lbps is 40KB/s.. definitely data transfer Amiga->Riser will not be bottleneck.
Question is if it can be sustained when reads are from ide.
Edit.
And I did find out that I cannot do it too quickly (beginning and end of interrupt routine) I suspect it is because cpld doesn't detect rising edge if it goes up and down in the same amiga clock cycle.
I have done some measuring (on Rev2)
I wrote a program to pretend to send 8 bytes x 1048576 times, and it takes less than 10sec.
It looks like this, where only work is to insert data to buffer.
Knowing that uncompressed data need 170KB/s and compressed MP3 with 320lbps is 40KB/s.. definitely data transfer Amiga->Riser will not be bottleneck.
Question is if it can be sustained when reads are from ide.
Edit.
And I did find out that I cannot do it too quickly (beginning and end of interrupt routine) I suspect it is because cpld doesn't detect rising edge if it goes up and down in the same amiga clock cycle.
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 3 Design discussion
Uncompressed 8bit mono 44.1k WAV.
16k chunks read from hdd and buffered in 64k buffer, then played via stm32 dac. Can be done, but loads of work.
Next step: 16bit stereo 44.1k That is 4 times more data to move.
16k chunks read from hdd and buffered in 64k buffer, then played via stm32 dac. Can be done, but loads of work.
Next step: 16bit stereo 44.1k That is 4 times more data to move.
- arkadiusz.makarenko
- Moderator Team
- Posts: 1208
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
Re: TF CD32 Riser Revision 3 Design discussion
Yup. I did send 16bit 44.1k stereo. Sound was distorted (I pushed straight 16bit to 12bit DAC), but played exactly the right lenght 6sec.
So yes data can keep up, now next step, decode mp3 on stm32 side.
So yes data can keep up, now next step, decode mp3 on stm32 side.
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 3 Design discussion
I have mp3 decoder working, reading from fifo and outputing values.... it is not timed correctly and ouput is just rubbish but it decodes info, now need to understand what to do with it, as it is in stereo 16bit signed value.
Anyway I was happy to see this Time to sync everything and check if there is enough RAM on stm32 to make it sound right.
Anyway I was happy to see this Time to sync everything and check if there is enough RAM on stm32 to make it sound right.
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 3 Design discussion
sweet..arkadiusz.makarenko wrote: ↑Wed Feb 10, 2021 10:22 pm I have mp3 decoder working, reading from fifo and outputing values.... it is not timed correctly and ouput is just rubbish but it decodes info, now need to understand what to do with it, as it is in stereo 16bit signed value.
Anyway I was happy to see this
20210210_220755.jpg
Time to sync everything and check if there is enough RAM on stm32 to make it sound right.
I will find some time to do the eagle changes for you soon.. have house viewings right now
———
"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."