A new riser?

[sampedenawa]

The main thing we'd want to do is to make this work for PC/USB joypads.. that should be possible without much hardware change at your side right?

Correct.
My only concern is about emulating CD32 joypads.
In order to be able to do that, I should strip out from the current hw at least one of the 3.3->5v level translation mosfets (so I can read the clk signal sent out by the console to the pad).
Easy and no risky at all mod (first hid2ami prototypes didn't have any mosfet at all), but a slightly less "clean" hw design.
Oh, incidentally I will then have to code CD32 pad emu in the fw ;)

[terriblefire]

Correct.
My only concern is about emulating CD32 joypads.
In order to be able to do that, I should strip out from the current hw at least one of the 3.3->5v level translation mosfets (so I can read the clk signal sent out by the console to the pad).
Easy and no risky at all mod (first hid2ami prototypes didn't have any mosfet at all), but a slightly less "clean" hw design.
Oh, incidentally I will then have to code CD32 pad emu in the fw ;)

Yeah. the fw is something i wanted to avoid doing.

Also the CD32 needs a hack to put the joystick on the riser.... maybe hack up one of your current boards to run joypads in the joystick port. Then when i clear the decks i'll get a a riser started and see if we cant put two of these plus a keyboard controller into the riser. I presume its easy to detect multiple HID devices in a single arm chip?

[sampedenawa]

I presume its easy to detect multiple HID devices in a single arm chip?

Unfortunately the USB hardware stack of stm32f105 can bear one single HID device at a time, while in USB host mode (usb host mode not supported by the hardware).
So for two pads we should put two chips on board (luckily they are extremely cheap).
Further one could be added to manage the keyboard (I already have keyboard support in my current firmware)

It's no efficient at all, but it does not add too much circuit complexity, because only few pins of each chip shall be connected.

[terriblefire]

Unfortunately the USB hardware stack of stm32f105 can bear one single HID device at a time, while in USB host mode (usb host mode not supported by the hardware).
So for two pads we should put two chips on board (luckily they are extremely cheap).
Further one could be added to manage the keyboard (I already have keyboard support in my current firmware)

It's no efficient at all, but it does not add too much circuit complexity, because only few pins of each chip shall be connected.

Space is a serious constraint on the riser.. there isnt much room at all.. are there any ARM variants that can cope with 2 USB devices?

I'm also a little concerned about doing the mouse with 2 arm chips. Essentially the chip needs to not do the DAC and put the data on the data bus when requested instead. This needs more pins. The mouse analog lines are not present on the riser.

[sampedenawa]

Why talking about DACs ? Mouse lines aren't analog ... not sure what you are referring to ???
Original Amiga mice output "quadrature waveforms" on 2 differential line pairs (4 wires in total).
What Hid2AMi does (in the mouse part) is to translate the timed dataflow packets coming from HID mice into [digital] "quadrature waveforms"

Returning in topic: there's a stm32F412 and a guy on github who seems to have coded an USB-HUB firmware stub.
I could think about two scenarios:
either
a. try to port his work to stm32F105 (the fw stack could be the same)
or
b. port the current hid2ami fw to stm32F4xx

Unfortunately the USB hardware stack of stm32f105 can bear one single HID device at a time, while in USB host mode (usb host mode not supported by the hardware).
So for two pads we should put two chips on board (luckily they are extremely cheap).
Further one could be added to manage the keyboard (I already have keyboard support in my current firmware)

It's no efficient at all, but it does not add too much circuit complexity, because only few pins of each chip shall be connected.

Space is a serious constraint on the riser.. there isnt much room at all.. are there any ARM variants that can cope with 2 USB devices?

I'm also a little concerned about doing the mouse with 2 arm chips. Essentially the chip needs to not do the DAC and put the data on the data bus when requested instead. This needs more pins. The mouse analog lines are not present on the riser.

[terriblefire]

Why talking about DACs ? Mouse lines aren't analog ... not sure what you are referring to ???
Original Amiga mice output "quadrature waveforms" on 2 differential line pairs (4 wires in total).
What Hid2AMi does (in the mouse part) is to translate the timed dataflow packets coming from HID mice into [digital] "quadrature waveforms"

Quad waveforms... i havent dug into them before but assumed they were analog. Mostly because Haynie got pissed when people ran those lines next to the databus on the original A2000 (i think). caused the mouse to jitter.

Either way you havent got those signals on the riser. You need to put a 16 bit wide data port on the riser that responds when the system accesses the mouse custom chip register... and supply the X/Y values directly.

There are also analog joystick signals but i guess nothing actually uses those. But they could have been used with joypads? maybe for a future thing... i always fancied hooking my G27 wheel up to F1GP on the amiga.

Returning in topic: there's a stm32F412 and a guy on github who seems to have coded an USB-HUB firmware stub.
I could think about two scenarios:
either
a. try to port his work to stm32F105 (the fw stack could be the same)
or
b. port the current hid2ami fw to stm32F4xx

Either may work. Probably should grab one of those and slap it on a riser to build a test rig to do the dev work.

[terriblefire]

OK i'm gonna pick this up as a Xmas project.

I have the Kipper2k files, I'l going to keep the video connector on there and do something like..

1. Make the board 4 layers to give me the use of every bit of surface on the board. Maybe make the final board 6 layer if things get tight... we can pack more things in more layers to make up for the lack of space to put components.

2. Put a XC9535XL chip on there (maybe squeeeze between the two edge connectors) to do address decodes.

3. Integrate an ARM USB-HID Keyboard solution into the board. Really we want a DUAL USB HID solution here.

For this job i need SMALL chips so if you have suggestions tell me now. Dont reply to this thread in 3 years time telling me i'm dumb for not considering a chip that doesnt exist in December 2019.

[go0se]

I think the Kipper2k PCB footprint could be enlarged a fair bit before things start to get ugly.

At 140mm X 60mm it would probably still be sensible.

[terriblefire]

Very basic start on this ...

basic_idea.JPG

The idea is to put a single USB device that can be a keyboard, mouse or joypad... then later scale it up to 2 x usb devices maybe later.

1. The ARM CPU Does the HID/USB interface.
2. The CPLD will hijack accesses to any port on the CPU bus and allow the ARM to pass data on that port to the bus.. its an address bus decoder.

[arkadiusz.makarenko]

Is there firmware for this stm32f10x chip?
Maybe it should be stm32f7x0 (fake chip issue and more power?) And port the code?