Posts by SukkoPera

No problem, anyway you might want to check/resolder RN6, Q6, PU1 and pins 12/13 of U1. If this all fails, pin 59 of U3 is the last thing to check.

You might have some problem with the DiskChange signal, either HW (cold solder joint, bad cable, etc) or in FlashFloppy: check the inteface keyword in your ff.cfg.

It's perfectly normal, this has nothing to do with the OpenFlops, it's just the way the Amiga Drive chain works: all drives will be driven through the SEL0 signal, it's the enclosure that has the task of activating that with the signal coming on its SEL1 pin. It will also redirect its input SEL2/3 to SEL1/2 on its output so that the next drive in the chain can work the same. It's this that makes the chain work without any configuration at all, otherwise you would have to somehow tell DF1 that it is DF1, DF2 that it is DF2, etc.

So again: it's perfectly normal and if you look at real floppy drives inside the enclosure, they will all be jumpered to react on SEL0. Literally all drives on Amigas must be jumpered like that, it's a common misconception that external drives should be jumpered on SEL1.

Quote from Snocksman

Den einzigen Jumper den ich gesteckt habe ist Sel0...

From the picture it looks like you putit between SEL0 and 1, while it goes between SEL0 and 0.

EDIT: Oh ok, you had already found out. SEL0/1/2 are the selection signals coming from the floppy connector, 0 and 1 are the selection "outputs" going to the microcontroller. This matrix is necessary for the long-awaited function of FlashFloppy emulating two drives at once, in which case you want flexibility on which selection signal selects which "virtual drive". But this is not yet implemented in FF (and IMHO will never be, it looks like keirf doesn't like the features i like :D), hence in 99% of cases you will want just onw jumper between SEL0 and 0. Addnig one more between SEL1 and 1 is future-proof and doesn't hurt anyway.

That's a bit... extreme!

You can use one of these modules, or the maaaaany other similar ones:

https://it.aliexpress.com/item/1005005302035188.html

As already mentioned, the way Flashfloppy expects the CD (Card Detect) pin to work is the opposite of how every single card module I've seen works (and keirf won't change it), so in most cases it should be left disconnected. I have already added a circuit to compensate for this on the board.

Quote from CapFuture1975

Eigentlich in den letzten Tagen:

Ein Vectrex Lightpen

Das Projekt findet ihr auf dieser Seite:

https://www.playvectrex.com/vectech/mvlp/mvlp_f.htm

Display More

May I ask what phototransistor you used?

That is not our replica, ours is the one on PCBway.

My friend Edoardo designed that board and I gave him some advice so that I could later write a firmware for it.

Although I still haven't had the time to do so, and in any case I will never make my firmware public, it will only be for the two of us. The bottom line is that you will have to write your own firmware to get that board to work.

That is correct. The holes were designed to accommodate both a plain 2.54mm header OR the Berg Connector. As I already said, there is no reason why it would not fit.

My response to Freak:

The board is pretty configurable to the user's taste, so you decide what is essential and what not. IMHO everything is essential, as the FlashFloppy/Gotek experience is sooooo much better when you have an OLED screen and a rotary encoder. Note that the front buttons are useful even if you are using the rotary encoder, as they are necessary if you want to update the FlashFloppy firmware by just putting a file on your USB stick.

You can maybe leave out the SD card header if you don't plan to use it, but I think it's better to just solder it all at once so that if you later change your mind, you can just plug in the SD module. By the way I think it was a very clever idea to solder it from the top, so that it doesn't interfere with the OLED connector! I hadn't thought of this.

It's perfectly normal to have to split pin headers in smaller sizes. Generally they are bought as 40-pins and broken down as necessary. I don't even know if you can buy them in any other lenghts, but with male headers it's very easy to break them, no special instrument is needed (I use flush cutters or just pliers), so why add several items to the BOM when you can make do with one? The only exception is the 2-row one for the data connector, but I also buy these in 2x40 and break them down.

Also keep in mind that some people will prefer straight headers while others will use 90-degree ones. Some might even use female headers in some cases. In all of my projects, I try to leave as much liberty as possible to the final user, and this is why I always recommend self-building them, rather than buying them assembled.

For the speaker, it's again up to the user which one to choose. The one you soldered in is the same type I use and I think it's perfect for the purpose. Still, if someone prefers a real speaker or anything else, they can just connect it by soldering a pin header at SPK1.

About the power connector, well, it was your choice. You can solder the TE 171826-4 connector in that spot, and that's what I do. Also, you can see in the pictures above that other people use it too.

Finally, there are several tailored enclousers available for 3d-printing. If you plan to put it in an Amiga, for instance, there's basically one for every model, just search on Thingiverse.

Man, I really hate this heatsinking frenzy that actually does more harm than good, sigh. Remove them all.

Don't bother rechanging the ElKos, they are fine. Rather replace all the single-wipe sockets, the original ones are really really bad. Another option would be the internal voltage regulator, it might be producing a bad voltage once it heats up. And anyway, replacing that with a modern switching one (2A recommended, TRACO TSR 2-2450 is a good choice, or this one) and getting rid of its heatsink and of the big white cement resistor reduces the internal temperature A LOT and has a much more tangible effect on the chips than any crappy heatsinking attempt.

Good to know! Unfortunately I didn't progress much, I haven't had any chances for testing on my side.

But at least I've opened an issue to FF to see if the CS polarity could be inverted, as the way it works is nonsense to me.

My board has also arrived and I managed to flash it under Linux through dfu-util. I tried to do it through the serial bootloader and stm32flash to no avail, not even using this patch :(. But this isn't a problem on the board, it's most likely due to the AT32F435 not behaving as expected by stm32flash.

OLED works, can't test much else at the moment, as I don't have any SD card modules nor USB connectors, I guess I'll need to buy a couple...

Regarding the OLED pinout: yes, there are displays with different pinouts out there, I picked the one that looked most common to me, but since you will need a cable to connect it anyway, it's trivial to adapt that to any display. Just be careful! Swapping SDA/SCL is no big deal but reversing the polarity is muuuuch worse.

On a side note: an electrolytic cap on my board was soldered only on one side. Not a big deal, but you might want to check that yours are sitting solidly on the board!

So far, so good!

Quote from jonny64

Quote from Dekay

Ich finde überhaupt keinen Beeper mit Rastermaß 2.54mm...

ich denke so ist das auch gar nicht gedacht… entweder vom 2.54mm-Raster via Jumper-Wire zum Speaker, oder den Speaker direkt auf die „SMD-Pads“ daneben löten, so wie bei https://github.com/SukkoPera/OpenFlops zu sehen… ist aber nur geraten

That's exactly how it's supposed to work. There's plenty of compatible speakers on AliExpress, some will sound quieter, some louder. So pick a couple of these and a couple of those and try them.

I was really upset by the lack of an open configuration tool for the WiC*. I don't care about the portal, that can be closed, but if you want a project to be open, everything that is required to bring it at least to a BASIC level of usability MUST be open. So again no-one volunteered to help (of course) and I just decided to have a go at making one myself. If nothing else, it was a good excuse to start picking up 6502 assembly. So, after a lot of "fun" I found out that I would need to alter the firmware quite a bit in order to get the whole thing working reliably with the original iteration of the HW I had designed, the main cause being the unavailability of the "handshake lines" in the +4 userport.

Thus I stepped back and started having more "fun", this time with the HW, in order to compensate for the missing features. After countless hours of experimentation, getting lost multiple times in a big mess o'wires, I think I reached a satisfactory solution. It feels a bit more convoluted than I would like but it seems to be pretty solid, peaking at ~18 kb/s. I'm not sure about the peak speed on the C64 but we shouldn't be too far. It could have been made more straightforward with a few modifications in the firmware, but that was a no-no to me, as I know the developers already have enough to do, so I'd rather avoid turning the burden over to them.

So, the bottom line is that I now have a fully open-source implementation of the WiC+4, including the HW, the driver, the configuration tool (which I will also make work on the C64) and the testing tool. All that's left is some software that makes actual use of it but I guess that will come after I release my stuff, which will happen later on as I am now going to relax a bit and have some holidays.

I'd like my changes to the driver to be upstreamed in the "official" driver. The basic idea is to abstract all HW interactions through macros (such as "init_userport", "clear_flag2", "pa2_high", etc), and then have different system-dependent implementations of those. I guess I'll talk to the devs about that one day.

Except that not everyone is able to make their own cart as easily as using a disk image.

There would still be solutions, like using D81 images for disks and RAM expansions, but most current programmers explicitly target an unmodified machine in "standard" configuration (i.e.: with a 1551 or 1541), for reasons that I can understand.

There was briefly an idea to use AdLib sound in this version (if detected), but unfortunately disk and memory space were tight and this feature had to be dropped. It could not even be included as an Easter Egg :(.

But you can still test this Tech Demo:

Since no-one volunteered, I decided to have a go at getting the software to work myself. I MacGyver'ed some hardware together and I managed to get to a point where the WiC would ask me for configuration through a "launcher" program that, as I later found out, is not open source, so I cannot adapt it to the +4.

I respect this choice by the WiC64 dev team, but then please respect my own choice of stopping my involvement with this project here.

I realize it is possible to write new software that does a similar work to the launcher, as all the information required is public, but I am unable to do it. I have improved the readme of my customized version so that someone else can bring this further.

Good luck!

The +4 version is complete, as far as I'm concerned. Apart from the functional changes:

• I have added a jumper that selects whether the ESP should be powered by the rectified +9VAC or by the 5V rail.
• Consequently, I have added a ferrite on the 5V rail. An axial inductor should also fit, some experimentation will show what is better.
• I have switched the resistor footprints to 0805 for easier hand solderability.

The board keeps exactly the same size and component layout, so all enclosures should still be usable.

Project is shared at https://github.com/SukkoPera/WiC64-Plus4. Gerbers are attached. Note: NO WARRANTIES at all :).

For the software side, again, I reckon no firmware changes will be required. About the +4 software:

• The "PC2" signal (ack/strobe: byte read from/written to port, rising edge) is controlled through /DTR
• The "PA2" signal (Direction: HIGH = C64/+4 => ESP, LOW = ESP => C64/+4) is controlled through /RTS
• The "FLAG2" signal (ack/strobe: byte read from/written to port, falling edge) can be read through /DCD.

/DTR and /RTS can be controlled through bits 0 and 3 (respectively) of $FD02 (Note that there is an inverter inbetween, so they are not really active-low).

/DCD can be read through bit 4 of $FD01. An interrupt can also be set up to track its changes.

I recommend taking a quick look at the 6551 ACIA datasheet in order to understand how to treat the other bits properly.

Another recommendation would be to make the ACIA base address configurable, for those who might want to use the 16UP board in External mode.

If anyone wants to have a go at the +4 side software, I can have empty PCBs shipped directly to them for free. They will have to solder all components though!

--- END OF TRANSMISSION ---

I have finally added the files to the GitHub page, thanks again!