TF CD32 Riser Revision 2 Design Complete

68030 + SDRAM + IDE

Moderators: terriblefire, Terriblefire Moderator

terriblefire
Moderator Team
Moderator Team
Posts: 3478
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire » Wed Oct 28, 2020 10:43 pm

Very-Little-Helps-Humor-Monkey-Greeting-Card.jpg
Very-Little-Helps-Humor-Monkey-Greeting-Card.jpg (43.57 KiB) Viewed 994 times
———
I get cranky when asked to repeat myself.

terriblefire
Moderator Team
Moderator Team
Posts: 3478
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire » Wed Oct 28, 2020 10:47 pm

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;
}
———
I get cranky when asked to repeat myself.

User avatar
arkadiusz.makarenko
Trusted Guru
Trusted Guru
Posts: 720
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko » Wed Oct 28, 2020 11:42 pm

terriblefire wrote:
Wed Oct 28, 2020 10:47 pm
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;
}
Took me a while to notice it. :)
So all pieces of a puzzle are in place, so next is Amiga CD32 support for all CD32 buttons.

ATK has CD32 gamepad testing kit, so I can and test solution.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem

terriblefire
Moderator Team
Moderator Team
Posts: 3478
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire » Thu Oct 29, 2020 8:50 am

Small further optimization ..

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;
}
This just avoids rotating and or'ing at the same time. And avoids rotations in two directions.
———
I get cranky when asked to repeat myself.

terriblefire
Moderator Team
Moderator Team
Posts: 3478
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire » Thu Oct 29, 2020 1:31 pm

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.
———
I get cranky when asked to repeat myself.

User avatar
arkadiusz.makarenko
Trusted Guru
Trusted Guru
Posts: 720
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko » Thu Oct 29, 2020 4:15 pm

terriblefire wrote:
Thu Oct 29, 2020 1:31 pm
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.
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.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem

terriblefire
Moderator Team
Moderator Team
Posts: 3478
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire » Thu Oct 29, 2020 6:03 pm

arkadiusz.makarenko wrote:
Thu Oct 29, 2020 4:15 pm
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.
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.
———
I get cranky when asked to repeat myself.

User avatar
arkadiusz.makarenko
Trusted Guru
Trusted Guru
Posts: 720
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko » Thu Oct 29, 2020 8:58 pm

I have rewritten Fire0 and fire1 buttons to use directly register CIAAPRA.

Now I can't see any delay in boot at all.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem

terriblefire
Moderator Team
Moderator Team
Posts: 3478
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire » Thu Oct 29, 2020 9:14 pm

arkadiusz.makarenko wrote:
Thu Oct 29, 2020 8:58 pm
I have rewritten Fire0 and fire1 buttons to use directly register CIAAPRA.

Now I can't see any delay in boot at all.
Sweet. If you are under 1uS it will behave normally or faster than the chipset.
———
I get cranky when asked to repeat myself.

User avatar
arkadiusz.makarenko
Trusted Guru
Trusted Guru
Posts: 720
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko » Thu Oct 29, 2020 10:33 pm

terriblefire wrote:
Thu Oct 29, 2020 9:14 pm
arkadiusz.makarenko wrote:
Thu Oct 29, 2020 8:58 pm
I have rewritten Fire0 and fire1 buttons to use directly register CIAAPRA.

Now I can't see any delay in boot at all.
Sweet. If you are under 1uS it will behave normally or faster than the chipset.
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.
But when I assigned fixed value everything always was OK. Now I have additional variable tempCIAAPRA on which I do bitwise operation and then I copy value back to CIAAPRA and for now it seems to be ok. Weird...

EDIT: No it is not, I have bug somewhere ....

Edit2. Give up for today. I must have bug somwhere in interrupt routine. I have seen something similar in AtariST project... can't remember what it was.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem

Post Reply

Return to “TF330”