Can all registered uses please login, even just for a few minutes..
It helps build a picture where our "good traffic" is coming from..
Thanks :)
It helps build a picture where our "good traffic" is coming from..
Thanks :)
TF CD32 Riser Revision 2 Design Complete
Moderators: terriblefire, Terriblefire Moderator
- arkadiusz.makarenko
- Moderator Team

- Posts: 1371
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
Re: TF CD32 Riser Revision 2 Design Complete
@terriblefire
I think I did find the reason for instability of arm which we had at the same begging of Rev2.
We are missing Vcap1 between pin 30 and ground. It is cap for internal regulator. Documentation requests (64 pin package) cap of value 4.7uF and ESR between 0.1 Ω and 0.2 Ω.
Source (in case I was taking rubbish):
https://www.st.com/resource/en/datashee ... f722ic.pdf - page 109
I did run cap and jump wire for tests, and it is much more stable. This was not a thing on f105's.
I think I did find the reason for instability of arm which we had at the same begging of Rev2.
We are missing Vcap1 between pin 30 and ground. It is cap for internal regulator. Documentation requests (64 pin package) cap of value 4.7uF and ESR between 0.1 Ω and 0.2 Ω.
Source (in case I was taking rubbish):
https://www.st.com/resource/en/datashee ... f722ic.pdf - page 109
I did run cap and jump wire for tests, and it is much more stable. This was not a thing on f105's.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
-
terriblefire
- Admin sponsor

- Posts: 5687
- Joined: Mon Aug 28, 2017 10:56 pm
- Location: Glasgow, UK
Re: TF CD32 Riser Revision 2 Design Complete
excellent find! I'll make this added to my own board this weekend.
———
"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."
Re: TF CD32 Riser Revision 2 Design Complete
There's my solution: https://github.com/daleking/Amiga_to_VGA_Buffered for DB23->VGA using solder cups, but it's a little awkward hanging off the back of the CD32. I believe Edu has an opensource one too....
If there is space on the riser, and since this is to be the 1 riser to rule them all, is it too much to ask for dual footprint for DB23 and HD15 VGA if there is room? I don't think it needs to be buffered as the sync buffer is really only there for big box amiga's that detect genlocks.
If there is space on the riser, and since this is to be the 1 riser to rule them all, is it too much to ask for dual footprint for DB23 and HD15 VGA if there is room? I don't think it needs to be buffered as the sync buffer is really only there for big box amiga's that detect genlocks.
- arkadiusz.makarenko
- Moderator Team

- Posts: 1371
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
Re: TF CD32 Riser Revision 2 Design Complete
@terriblefire
I have just pushed fixes for stupid bug which made keyboard with multiple interfaces (keyboard&mouse combo) stopped working.
This version requires that additional cap on the board to work. I might leave it like this if chip is stable.
And I have extended startup time for HSE crystal, I have noticed on Atari keyboard work that if power supply is too noisy at boot, this may cause issues with usb init. Giving a little bit more time on init solved my issue. This is more a precaution.
Ps.
I know that you are busy, but if you find some time could you send me picture how to sort video?
Ps2.
I have noticed that holding some buttons too long down causes reset. Will try to fix it over the weekend
I have just pushed fixes for stupid bug which made keyboard with multiple interfaces (keyboard&mouse combo) stopped working.
This version requires that additional cap on the board to work. I might leave it like this if chip is stable.
And I have extended startup time for HSE crystal, I have noticed on Atari keyboard work that if power supply is too noisy at boot, this may cause issues with usb init. Giving a little bit more time on init solved my issue. This is more a precaution.
Ps.
I know that you are busy, but if you find some time could you send me picture how to sort video?
Ps2.
I have noticed that holding some buttons too long down causes reset. Will try to fix it over the weekend
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
-
terriblefire
- Admin sponsor

- Posts: 5687
- Joined: Mon Aug 28, 2017 10:56 pm
- Location: Glasgow, UK
Re: TF CD32 Riser Revision 2 Design Complete
Sorry things have been crazy... still this is the board I want the most...arkadiusz.makarenko wrote: Thu Jun 04, 2020 7:57 pm Ps.
I know that you are busy, but if you find some time could you send me picture how to sort video?
Video fix is to remove all the resistors (6 of them next to the video socket) then either short the purple...
Or put < 22R on them.. but you get the idea.
———
"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: 1371
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
Re: TF CD32 Riser Revision 2 Design Complete
Works great. Thank you.
Unfortunately don't have knowledge to pick up xillinx firmware.
Unfortunately don't have knowledge to pick up xillinx firmware.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
-
terriblefire
- Admin sponsor

- Posts: 5687
- Joined: Mon Aug 28, 2017 10:56 pm
- Location: Glasgow, UK
Re: TF CD32 Riser Revision 2 Design Complete
2 secs i'll send you enough to boot.arkadiusz.makarenko wrote: Thu Jun 04, 2020 10:41 pm Works great. Thank you.
Unfortunately don't have knowledge to pick up xillinx firmware.
———
"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."
-
terriblefire
- Admin sponsor

- Posts: 5687
- Joined: Mon Aug 28, 2017 10:56 pm
- Location: Glasgow, UK
Re: TF CD32 Riser Revision 2 Design Complete
Jed is inside..
This code does nothing except make the riser passive at this point. But that should let you test keyboard.
This code does nothing except make the riser passive at this point. But that should let you test keyboard.
———
"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."
-
terriblefire
- Admin sponsor

- Posts: 5687
- Joined: Mon Aug 28, 2017 10:56 pm
- Location: Glasgow, UK
Re: TF CD32 Riser Revision 2 Design Complete
So here's how I thought this would work with the CPLD.
1. ARM CPU Identifies a device that needs to be overridden (i.e mouse/ joystick is plugged in.. we dont want to override the mouse unless one is plugged in right?).
-> ARM asserts one of the INTSIG PINS to let the CPLD to decode this address (or group of addresses - ARM has lower address pins to sniff if it needs).
2. If an address is overriden then when that address is accessed CPLD asserts PUNT to stop the chipset responding, sets a bit to tell the ARM it which address is decoded and wiggles the ARM interrupt pin (PIN 61 on the ARM) to let the arm know to do stuff.
3. When the arm is ready to respond with (for read cycle) data it puts data on PB0-7 and wiggles another INTSIG pin (pin 62 on the arm i think) to tell the CPLD to give the system the ack it needs. I do it this way because then the arm doesnt have to deal with clock periods and timings.
and thats it. You can override any address in the lower 16M space this way. Basically the CPLD is an address decoder.
1. ARM CPU Identifies a device that needs to be overridden (i.e mouse/ joystick is plugged in.. we dont want to override the mouse unless one is plugged in right?).
-> ARM asserts one of the INTSIG PINS to let the CPLD to decode this address (or group of addresses - ARM has lower address pins to sniff if it needs).
2. If an address is overriden then when that address is accessed CPLD asserts PUNT to stop the chipset responding, sets a bit to tell the ARM it which address is decoded and wiggles the ARM interrupt pin (PIN 61 on the ARM) to let the arm know to do stuff.
3. When the arm is ready to respond with (for read cycle) data it puts data on PB0-7 and wiggles another INTSIG pin (pin 62 on the arm i think) to tell the CPLD to give the system the ack it needs. I do it this way because then the arm doesnt have to deal with clock periods and timings.
and thats it. You can override any address in the lower 16M space this way. Basically the CPLD is an address decoder.
———
"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: 1371
- Joined: Wed Jun 19, 2019 7:36 am
- Location: Edinburgh
Re: TF CD32 Riser Revision 2 Design Complete
@terriblefire
So from ARM perspective would it work like this?
USB stack reads which device is connected and when data report is received from device arm sends address to CPLD (how would it do it? usart data lines).
Then cpld send irq reqest to arm, and arm sets data via data lines, then sets INTSIG and waits very little and release INTSIG and go back to normal?
So from ARM perspective would it work like this?
USB stack reads which device is connected and when data report is received from device arm sends address to CPLD (how would it do it? usart data lines).
Then cpld send irq reqest to arm, and arm sets data via data lines, then sets INTSIG and waits very little and release INTSIG and go back to normal?
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem