Page 37 of 60
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 25 Oct 2020 20:18
by arkadiusz.makarenko
Any touching override CIA kills performance of Amiga...
Fire1 - control clocking so maybe I could detect it from there and on rising edge shift data to pass it to POTGOR register. I am not sure if I can detect it and sync it well enough.
Or override CIA only at command to change Fire to output, and release it afterwards.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 26 Oct 2020 09:15
by terriblefire
arkadiusz.makarenko wrote: 25 Oct 2020 20:18
Any touching override CIA kills performance of Amiga...
Fire1 - control clocking so maybe I could detect it from there and on rising edge shift data to pass it to POTGOR register. I am not sure if I can detect it and sync it well enough.
Or override CIA only at command to change Fire to output, and release it afterwards.
CIA read/write is done by emulating the old 6800 so are slow. ~1uS But i think the issue is probably something to do with timers.
On writes you probably want to let go of PUNT after the ARM has the data and let the CIA get the data for real.
I realize people will say the CD32 has not got CIAs but it has a partial emulation of them in Akkiko.
Also if you can get the code to run in ARM RAM try that as it might make a difference.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 26 Oct 2020 09:50
by terriblefire
Your other option is to pass all fire button data to the CPLD via SPI and let it handle all this for you outside the arm. Clocking and everything. There is just enough space in the CPLD for this.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 26 Oct 2020 16:45
by terriblefire
Not sure how much space is left in the ARM but the CD32 floppy drive pins are wired to it if you feel like implementing GoTek?
You would need to emulate these as outputs.
BFD100 prb /MTR /SEL3 /SEL2 /SEL1 /SEL0 /SIDE DIR /STEP
And you are already emulating these as inputs.
BFE001 pra /FIR1 /FIR0 /RDY /TK0 /WPRO /CHNG /LED OVL
I was thinking this could be a more long term thing.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 26 Oct 2020 17:37
by arkadiusz.makarenko
terriblefire wrote: 26 Oct 2020 16:45
Not sure how much space is left in the ARM but the CD32 floppy drive pins are wired to it if you feel like implementing GoTek?
You would need to emulate these as outputs.
BFD100 prb /MTR /SEL3 /SEL2 /SEL1 /SEL0 /SIDE DIR /STEP
And you are already emulating these as inputs.
BFE001 pra /FIR1 /FIR0 /RDY /TK0 /WPRO /CHNG /LED OVL
I was thinking this could be a more long term thing.
ARM has 480k flash and like 200k ram still free. F722 is massive.
So really only cpld might run of space.
I was thinking (long term) about gotek as adfs and drive emulation or direct data from usb -> amiga somehow (even if it was very slowly).
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 26 Oct 2020 17:50
by terriblefire
arkadiusz.makarenko wrote: 26 Oct 2020 17:37
ARM has 480k flash and like 200k ram still free. F722 is massive.
So really only cpld might run of space.
I was thinking (long term) about gotek as adfs and drive emulation or direct data from usb -> amiga somehow (even if it was very slowly).
You should be able to do this with one extra decode in the CPLD (BFD100).
You would need to read adfs off a USB stick i guess and other than that it should be identical code to flashfloppy. The only tricky bit is going to be how to select a disk.
There are two spare pins wired up to a the DAC header which could be used i guess.
https://github.com/keirf/FlashFloppy
You could probably cut down the code size since you wont need all those floppy formats for the Amiga.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 26 Oct 2020 18:08
by arkadiusz.makarenko
terriblefire wrote: 26 Oct 2020 17:50
arkadiusz.makarenko wrote: 26 Oct 2020 17:37
ARM has 480k flash and like 200k ram still free. F722 is massive.
So really only cpld might run of space.
I was thinking (long term) about gotek as adfs and drive emulation or direct data from usb -> amiga somehow (even if it was very slowly).
You should be able to do this with one extra decode in the CPLD (BFD100).
You would need to read adfs off a USB stick i guess and other than that it should be identical code to flashfloppy. The only tricky bit is going to be how to select a disk.
There are two spare pins wired up to a the DAC header which could be used i guess.
https://github.com/keirf/FlashFloppy
You could probably cut down the code size since you wont need all those floppy formats for the Amiga.
Kier went full in with this firmware by writing own libraries to control stm32, nothing that coudn't be ported to HAL I don't think, but jaw dropping as he had to put A LOT of effort.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 26 Oct 2020 19:06
by terriblefire
arkadiusz.makarenko wrote: 26 Oct 2020 18:08
Kier went full in with this firmware by writing own libraries to control stm32, nothing that coudn't be ported to HAL I don't think, but jaw dropping as he had to put A LOT of effort.
Yeah i'm not a fan of the STM32 standard firmware.
If we get floppy working i guess we could look at using an spi text video overlay chip.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 26 Oct 2020 21:37
by arkadiusz.makarenko
I have jumped the gun with Floppy drive support.
Need to complete what I have started first.
So Enable/disable override on plug unplug of USB device. I cannot easily do it gradually. So it will be close to all or nothing approach as button 2 and 3 is in the same place for both ports.
But to start this I need to tidy up and rationalise usb hid middleware and assign right port to right USB slot etc.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 26 Oct 2020 22:23
by terriblefire
Can i check.. are you decoding / overriding BFE001? I'm not certain you need to as you can output on FIRE0/FIRE1 instead?