Pluggy Reloaded

[norgate]

Hey all,

Progress has been made on the PCB front. My current design can be seen in the images below.

Following monsonites suggestion I have broken out the remaining 4 GPIO Pins, which happen to also be analog inputs.

I'm considering adding mounting holes, since I'm going to 3D print an enclosure, but that would increase the width of the board quite a bit.

Before I order the boards, I would appreciate any feedback you might have on the layout.

P.S.: I have disabled ground fill for the screenshot, that's why there some ratsnest lines left.

[marcelk]

It looks fantastic. This is a really useful and cool development.

With the original Pluggy we struggled with the PS/2 jack footprint: none of the parts we sourced fit very well in the KiCad layout, no matter where we bought them. You could still make it fit if you bent the legs outward a bit, but it was frustrating. We ended up adjusting the footprint based on our own measurements.

It looks like you got yours from a different library, so you may not have this issue. Otherwise this is something to keep in mind.

[norgate]

[Edit: I'm terribly sorry, I accidentally edited your reply instead of replying to it. The text below is mine... -marcelk]

KiCad's default trace width is quite thin. For our PCBs we changed the default trace width to 0.250 mm for signal and clock lines, and 0.400 mm for power lines. Kit makers learnt that thin traces and sometimes inexperienced solderers aren't a great combination (apply a bit too much heat and the trace is gone). But this shouldn't stop you from ordering boards now.

[marcelk]

New thoughts popped up: This setup is great for loading files, and Loader's speed of 28k8 payload bits per second is more than sufficient for that.

I pondered about writing data. The current scheme with vPulse modulation attempts to keep the video signal alive. This leaves us with 60 bits per second, which isn't stellar performance. And even at that rate, some monitors don't like this scheme, which is why we didn't bother to pump it up further to 120 bits per second.

But if we just stop the /hSync signal while sending data, we could go much faster. ROM v4 has a feature to bypass the video signal generation entirely and run vCPU all by itself: MODE 1975. This can be activated with SYS_SetMode, and after that the SYS_Out function can send data over the /vSync line. Lacking a /hSync signal, it must be self-clocked with a Manchester code. My hunch is that LCD monitors ignore the /vSync signal in the absence of horizontal pulses, and so they won't go berserk when this happens. If confirmed, your solution will be the quickest way to achieve bidirectional file system support.

[at67]

Very cool stuff in this thread, hurry up and finish all of it, HW, SW, PCB, file system, etc

[norgate]

@marcelk
Sounds great! What are you envisioning to be written out from the Gigatron? You want to be able to write files to the SD card, or Serial to the PC like it is currently?

Regarding the trace width. Data lines are currently .25 mm and power lines are .5mm. Should be fine, but I can widen the data lines a bit a since there's more than enough room.

Also, as I mentioned yesterday, SRAM usage is currently a bottleneck on the Pro Micro, since the SD library requires a 512 byte buffer. Any ideas on reducing that? The strings currently take up the most space.

@at67 Thats the plan!

[marcelk]

I checked again and mixed up KiCad's defaults with our own. We have 0.400 mm for data and 0.750 mm for power. Then 0.250 mm only for assist lines that disappear when replaced with the ground fill.

What to save...? Ultimately I'ld like to have some sort of CP/M-like experience on the machine: editing and compiling on the system itself. Maybe serving a webpage at some time? Work on the SPI interface is ongoing of course, but only slowly making its way past the software bottleneck.

SDcard loading would already supergreat, because of becoming fully untethered.. One step at a time..

Indeed, putting strings in PROGMEM makes sense. But in the end there's only so much functionality you can squeeze out of a microcontroller. We have a 256 byte buffer in BabelFish for GT1 file segments, and that's already being read out of boundaries in some cases (for "dontcare" data, but still).

[norgate]

After finding and fixing some errors in the PCB layout and widening the traces, I have now ordered 5 PCBs, which should arrive by the end of the week.

I have attached the Gerber files to this post for anyone interested.

[norgate]

Hey everyone,

the boards arrived today, and I got one fully assembled and working.
It all went together without any issues. I have tested the game controller, ps/2 keyboard, USB and SD card and everything works like a charm.

pluggy1.jpg (893.05 KiB) Viewed 11165 times

pluggy2.jpg (368.63 KiB) Viewed 11165 times

In case anyone is interested in having one, I have parts for another four, which I'd be willing to sell.
Alternatively you can order the boards and parts yourself.
The required parts can be found here:

https://www.reichelt.de/my/1632151
https://www.sparkfun.com/products/12640

These are not the exact parts I used, but should be fully compatible.

The Gerber Files for the board are attached to my last post. I have also attached the KiCad files in case you want to make any modifications.

Next I'll probably build a 3D printed housing.

Edit: You don't have to buy the original Pro Micro from Sparkfun. You can get a clone for about 3,50€ a piece which works just fine.

[marcelk]

That looks wonderful. Congratulations!

P.S.: I sent you an e-mail for getting a board