TF CD32 Riser Revision 2 Design Complete

[terriblefire]

Very-Little-Helps-Humor-Monkey-Greeting-Card.jpg

[terriblefire]

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;
}

[arkadiusz.makarenko]

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.

[terriblefire]

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.

[terriblefire]

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.

[arkadiusz.makarenko]

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.

[terriblefire]

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.

[arkadiusz.makarenko]

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

Now I can't see any delay in boot at all.

[terriblefire]

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.

[arkadiusz.makarenko]

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.