TF CD32 Riser Revision 2 Design Complete

TF CD32 Riser

Moderators: terriblefire, Terriblefire Moderator

User avatar
arkadiusz.makarenko
Moderator Team
Moderator Team
Posts: 1208
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko »

@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.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
terriblefire
Moderator Team
Moderator Team
Posts: 5387
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire »

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."
dalek
Posts: 224
Joined: Thu Nov 08, 2018 11:03 am
Location: NSW Australia

Re: TF CD32 Riser Revision 2 Design Complete

Post by dalek »

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.
User avatar
arkadiusz.makarenko
Moderator Team
Moderator Team
Posts: 1208
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko »

@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
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
terriblefire
Moderator Team
Moderator Team
Posts: 5387
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire »

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?
Sorry things have been crazy... still this is the board I want the most...

Video fix is to remove all the resistors (6 of them next to the video socket) then either short the purple...
fix.JPG
fix.JPG (145.58 KiB) Viewed 4439 times
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."
User avatar
arkadiusz.makarenko
Moderator Team
Moderator Team
Posts: 1208
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko »

Works great. Thank you.

Unfortunately don't have knowledge to pick up xillinx firmware.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
terriblefire
Moderator Team
Moderator Team
Posts: 5387
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire »

arkadiusz.makarenko wrote: Thu Jun 04, 2020 10:41 pm Works great. Thank you.

Unfortunately don't have knowledge to pick up xillinx firmware.
2 secs i'll send you enough to boot.
———
"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
Moderator Team
Moderator Team
Posts: 5387
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire »

Jed is inside..
cd32_riser.zip
(26.63 KiB) Downloaded 128 times
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."
terriblefire
Moderator Team
Moderator Team
Posts: 5387
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire »

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.
———
"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."
User avatar
arkadiusz.makarenko
Moderator Team
Moderator Team
Posts: 1208
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko »

@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?
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
Post Reply

Return to “TF CD32 Riser”