Will it work on this board?

[Zibri]

https://ram-e-shop.com/product/atmel-avr-usb-development-system-eta32mini/

Eta32mini key features:

• Power supply unit.
• ATMEGA32 Microcontroller with reset switch and crystal oscillator.
• 4X4 matrix keypad.
• Output unit involves three output LEDs, two output relays and one output buzzer.
• Multiplexed two digits 7 segments display.
• 2X16 LCD display.
• Variable analog input using high precise multi-turn resistor.
• Virtual COM port via USB.
• Standard 6 pin header socket ICSP for external programmers.
• All microcontroller I/O pins are brought out via pin header.

[Larswad]

Hi Zibri!
I am surprised if it would work out of the box, even if it would compile with arduino toolsuite.
Usually it is timing involved for the gpios and not seldomly the serial ports may have some different properties. The Avr32 family is quite nice really, and I have developed for them, however, sorry to say I have a full time job and not so much time over to fix a port. But if you are into coding yourself, why not give it a try? The challange is actually the fun part.
I would actually recommend you instead the pi and pi1541 project. It is just great, you can find pre-made shields on eBay. It is TRUE 1541 emulation.
And it works with all turbo loaders.

Best regards
Lars

[Zibri]

HI! Thanks for the answer! I am no "newbie" in programming and I know about the pi projects. I am just brainstorming of all the possibilities. For esample: how about CH341A and FTDI232R?? Both could just connect directly to IEC and/or joystick ports. I was thinking that it could be the cheapest way to have a IEC to USB "converter" then all the work and timing could be done on the pc side allowing to emulate a 1541 or even a printer.

[Larswad]

Hi,
From a functional point of view, it is a great idea. That would mean either pc or even phones could be the host side.
But remember one thing (this important thing that is the one detail that make it all fall apart). Even if pc's and phones are powerful and fast, in fact many times faster than the arduinos for instance, they don't have any precise, reliable, down to the microsecond latency free timing. All these os's rely on schedulers who cannot in user space applications guarantee microsecond accuracy, which is needed. Why the pi1541 succeeds, is because they use the bare metal circle library which is a fantastic thing for embedded real-time hardware stuff on the pi. So that's the whole deal, that's why the arduino sits there in between to do the timing on the IEC pins correct. The other "in-between" things that are not timing critical, like buffering up new data continuously from the pc can be safely done without any problems, the c64 waits normally for the drive to read data from the disk. But the talk/untalk stuff and other operations must be done extremely tight, especially if turbo loaders are involved.
However, not to be raining on your parade. The idea of a "dongle - like" solution is great, but it would have to take care of the low level communication business with the c64, the whole IEC protocol let's say. A serial port converter only is not enough. And the other business could be taken care of by the pc side.

But maybe, this is exactly what you mean.

[Zibri]

I have to check this, but I am almost sure there is a way to have a "near to zero" latency program, even on windows, by using assembler and reserving a cpu for that. That'sused also by eprom programmers (which use ch341A or ftdi232r, by the way)