Re: TF CD32 Riser Revision 2 Design Complete
Posted: 28 Oct 2020 22:43
We welcome retro users & hardware gurus alike! Come and join the party :)
https://www.exxosforum.co.uk/forum/
Code: Select all
static inline uint8_t ReadAddress() {
uint8_t address = 0;
address = ((GPIOC->IDR >> 9) & 1U); //PC9 - INTSIG5
address = (address << 1) | ((GPIOA->IDR >> 10) & 1U); //PA10 - A4
address = (address << 1) | ((GPIOA->IDR >> 15) & 1U);//PA15 - INTSIG3
address = (address << 2) | ((GPIOC->IDR >> 6) & 3U); //PC6 - A1 & PC7 - A2
address = (address << 1) | ((GPIOC->IDR >> 4) & 1U); //PC4 - A0
return address;
}
Took me a while to notice it. :)terriblefire wrote: 28 Oct 2020 22:47 I noticed you can do this and save 1 operation
Code: Select all
static inline uint8_t ReadAddress() { uint8_t address = 0; address = ((GPIOC->IDR >> 9) & 1U); //PC9 - INTSIG5 address = (address << 1) | ((GPIOA->IDR >> 10) & 1U); //PA10 - A4 address = (address << 1) | ((GPIOA->IDR >> 15) & 1U);//PA15 - INTSIG3 address = (address << 2) | ((GPIOC->IDR >> 6) & 3U); //PC6 - A1 & PC7 - A2 address = (address << 1) | ((GPIOC->IDR >> 4) & 1U); //PC4 - A0 return address; }
Code: Select all
static inline uint8_t ReadAddress() {
uint8_t address = ((GPIOC->IDR >> (4)) & 0x20); //PC9 - INTSIG5
address |=((GPIOA->IDR >> (6)) & 0x10); //PA10 - A4
address |=((GPIOA->IDR >> (12)) & 0x08);//PA15 - INTSIG3
address |=((GPIOC->IDR >> (4)) & 0x06); //PC6 - A1 & PC7 - A2
address |=((GPIOC->IDR >> 4) & 0x01); //PC4 - A0
return address;
}
Easy prototype solutionsterriblefire wrote: 29 Oct 2020 13:31 Actually I was thinking about this. For $BFE001 if you can get the access speed under 1uS then you could read FIRE0 and FIRE1 and mux them with any button data you have in your code (i.e. do nothing if there is no devices attached) and pass this to the CPU. This would allow fire buttons to be used from the 9 pin D connectors and the usb sources at the same time.
The exception would be to not do this when reading the CD32 extended buttons which can be detected.
You will then be able to emulate the floppy input control lines too.
The most significant issue is how to select a floppy disk image.... options...
1. implement some kind of display a'la gotek.
2. some kind of OSD overlay (needs a board respin).
3. dont display anything.
Yeah i dont think we could use the STM32 for this if we needed to respond the the CPU... There are spi controllable video overlay chips that could do the job.arkadiusz.makarenko wrote: 29 Oct 2020 16:15 Easy prototype solutions
Buttons : spare usb keyboard buttons like F11-F12 with support only for top folder.
1. Fairly easy to manage, but it could be difficult to find right pins and solder something to them.
2. ARM generated OSD ? https://github.com/keirf/FF_OSD (2 pins required one for sync second for one color via resistor) - people don't like it for some reason. Don't know if this would be viable option under one stm32.
3. For initial work... sound ok. There is a lot of work needed to get to this point anyway. USB stack, flashfloppy port, cpld...
I started first attempt to implement CD32 buttons support, it will take me a while to get it right.
Sweet. If you are under 1uS it will behave normally or faster than the chipset.arkadiusz.makarenko wrote: 29 Oct 2020 20:58 I have rewritten Fire0 and fire1 buttons to use directly register CIAAPRA.
Now I can't see any delay in boot at all.
I had some issues with freezing. For some reason when I was doing bitwise operatoins directly on CIAAPRA variable some builds behaved ok, and others caused freezing.terriblefire wrote: 29 Oct 2020 21:14Sweet. If you are under 1uS it will behave normally or faster than the chipset.arkadiusz.makarenko wrote: 29 Oct 2020 20:58 I have rewritten Fire0 and fire1 buttons to use directly register CIAAPRA.
Now I can't see any delay in boot at all.