65uino

We're reached the deadline for the Wildcard challenge round in the Hackaday Prize 2023, but let me tell you this - the 65uino has years of projects ahead!

I had a bit of a detour modifying ROMs bigger than 28 pins to work with the 65uino(video below) but I'm currently working hard on a video to finish the basic SSD1306 OLED library - and it's going well!

At time of writing I have it working, perfectly entering text via serial, setting cursor locations etc, but the whole "video editing thing" also takes a bit of time, so that'll be a thing for later. 

And I think I'll even have it logging into a Raspberry Pi! We'll see soon :)

For now, there's the ROM thing if you missed it. 

I've been thinking a LOT about the best way forward for the 65uino. 

Ideally you should be able to make it from whatever you have lying around - basically as long as you have a 6507/6504, a ROM and a 6532 you should be good to go. 

If you don't use the crystal oscillator inverter circuit though, only a single gate is used on the hex inverter, so I thought it was time for an optional minimisation - and put in a single gate SOT23-5 inverter so you can use that instead of a DIP14 '04/14.

The idea here is that if you're comfortable with fine soldering for the SOT23-5 3v3 regulator and SMD oscillator, soldering another inverter shouldn't change things much - and if you're not comfortable with it, you might skip the 3v3 regulator and use the crystal oscillator inverter circuit instead.. Or have a PCB house do the SMT assembly. 

Either way, I decided to make the SMT oscillator the default clock source since 1MHz crystals aren't actually that easy to come by but decided to leave in all the hackability. Philosophy: Make it easy to make one no matter if you want to do a lot of soldering or a little. 

I really like the idea of making it so you can get a board in your hands and you just have to solder pin headers and sockets to the board and you're good to go - maybe I'll put a kit like that on Tindie, who knows!

And if you noticed the title of this log - yes, don't forget the pullups. Even though i2c peripherals usually have enough pullup oomph it's bad practice not to at least have pads for i2c pullups - so I added them on the bottom side. Now they can be added later if they turn out to be needed for something - but I've set the value to NC for now though. 

Same goes for pullups on the serial lines since it might be good practice - especially since the current code assumes the RX pin to be high unless we're in the middle of a serial transaction. 

In the fringe case that someone would want to install an AT28C256 EEPROM that can technically be programmed in circuit(by code in RAM for instance) I added JP8 so it's easy to free the RW pin. However, that still requires you to at least NAND the ~OE line with the 6507 ~WE as well (and no NAND gate on board ATM). Doesn't hurt and makes it more hackable - you can also use it for banking ROM if you want to(that might be more fun!). 

Happy hacking!

In case you're wondering, then yes, the 65uino is absolutely designed to catch the essence of the Hackaday Prize 2023. 

It's not just educational, it's not just green, it's not just a great piece of gear - it's all of the above! - and that's why I'm submitting the project for all three of those challenge rounds. And of course the wildcard!

I've noticed some critics comment about the project being just a joke novelty, but I certainly intend to prove it's very far from a joke. It is called "challenge rounds" after all, so challenge accepted! 

In my new video I hope to convince some of the doubters as I show how I coded the serial bootloader for the 65uino and work around the constraints of a limited platform. 
I sincerely believe working in a resource constrained environment is a great driver for innovation. With 4k of ROM available and only 128 bytes of RAM you HAVE to come up with new and improved solutions for the task at hand - and with that comes a skillset you wouldn't get otherwise. 

In the video below I give a little glimpse at how the 65uino is intended to be used - you'd be surprised how much functionality you can squeeze into 100 bytes of code in RAM when you have a powerful library of subroutines in ROM. The serial bootloader will certainly speed up development when I can just move the subroutine I'm working on to RAM instead of constantly burning the ROM. 

Wish me luck!

New video out where I show how you can drive an SSD1306 OLED display using 6502 assembly - of course using the #65uino 

Of course I intended to get this log in before the end of the "Green hacks" challenge round, but only managed to get the actual board and code changes pushed to Github - I hope the judges noticed. 

From the beginning this project really was meant to inspire you to do the same thing as many of my other projects: Save some nice old chips from the landfills instead of buying a new dev board! 
And when you're done with it and the 6532, 6507, and ROM have found a new place somewhere, you still have a nice 3v3 + 5V voltage regulator that takes dupont or barrel jack input up to 18 volts, in an Arduino form factor - and has a nice little 1 MHz oscillator. 

Not the worlds greatest feat of engineering but I hope it can inspire others to try to use what you have on hand before you buy new - and if you're a maker: To design for the fact that eventually your thing might need to be scrapped responsibly - so make it easy to reuse the parts. 

On the code side there's a few spoilers if you're watching my video series on the 65uino - it has all the 6502  assembly code for showing text on the SSD1306 display as well as the bare minimum for interfacing with the BMP180 barometer and as you might expect from this sort of thing: It also supports loading code through the serial pins "D0" and "D1", at a whopping 4800 baud. 

Speaking of: I updated the silkscreen so you don't need a computer nearby to figure out if you plugged anything in the wrong way - there is the slight confusion that D0-D7 on a 6502 usually refers to the data bus pins, but on an Arduino refers to the "[D]igital pins". 

For good measure I also put the 6532 pin designations on the board - that should lessen the confusion. 
Please note the silkscreen changes aren't in the gerber zip - so if you're sending it off to a manufacturer this week you might want to plot the gerbers yourself instead of the zip file. 

Oh! And I slimmed the board a bit to make sure it fits in the "official" 68.6mm width of an "Arduino" - excluding the USB and cuttoff section of course. 

As usual it took a bit longer than expected but I'm happy to announce I finally released my video on I2C on a 6502.. Or 6507 in the case of the 65uino. 

I thought I could squeeze in the whole concept of i2c as well as making a somewhat complete SSD1306 OLED library in 6502 assembly into a single video, but that would've been way too long, so actually using the display with a small font will have to wait for next time. The video is already pretty compressed as it is. 

I hope you'll enjoy it. 

With the enormous amount of through hole pins near the board edge, one of the harder things I've postponed for the next revision is silkscreen text with the pinout. 

Even with a relatively well known pinout like for an Arduino Uno, you're still going to let out the magic smoke if you were "at least 60% sure that pin was GND and not 5V", so somehow I need to squeeze in the pinout on the bottom silkscreen. Probably it'll take some time and involve little lines or arrows to point the text to the pins, to make sure it doesn't look like random gibberish on the bottom side.  

For the past couple of weeks I've been frantically editing my introduction video for the 65uino, in the little free time I have. The video also doubles as an introduction to I2C on a 6502 platform, and since that also needs a graphic showing the pinout, you get a preview here.

Hopefully I'll find the time to update the PCB silkscreen when the video is out.

It's been a few days and I had a bit more fun with the #65uino 

I've published new code to Github, that now not only handles the SSD1306 display and includes a font, but also reads a BMP180 temperature and pressure sensor.

But "reads" is not the same as getting something intelligible out. The BMP180 raw sensor data needs to be run through an algorithm to compensate the data according to some calibration data in an onchip ROM, and even though it's not awfully complicated, it's more work than I'm willing to do in 6502 assembly right now.  It is, however, a very good way to check if my i2c routines work as intended, so that's what I've done - and the current code just updates the current 16 bit sensor data on the last line of the display on every loop tick. 

Screen updates

Of course I had to figure out how to set a cursor position first - the way most libraries for the displays of this sort work is they keep a framebuffer in RAM and just focus on sending that out as fast as possible - but with our 1MHz system clock and bitbanging i2c, that's no really reasonable. 

Instead the SSD has the two commands 0x21 and 0x22 to set the column and page start + end. It seems to be that's also the easiest way to reset the cursor position, so if you want the cursor on line 3, you set the start page to 3 and the end page to 2, which will also put the cursor at the start position. 

32 Pin ROMs

You might notice the two THT resistors I threw on the ROM here. What's going on is that I've been using an SST39sf010 Flash ROM instead of the w27c512 eeprom. The 39sf's are much faster to program(and if we weren't using them for this they actually have 128K of storage) but the problem is they're 32 pin instead of the 28 pins of the breakoff section or the "ideal" 24 pin EEPROM. 

Otherwise the pinout matches so all we need to do is put a jumper from the "NC" pin 30 to VCC on pin 32 of the 39sf, a pullup on the ~WE pin and a pulldown on the A16 pin. 

I was surprised to find there IC's available as second hand IC's for basically the same price(maybe even lower!) as the w27c512's - so that's good news. It's always nice when you have the option to buy new or used. 

It's good for this case when I have to program the ROM a lot, but I'd still recommend the smaller footprints so the pins don't stick out :) 

I've had about a week and a half to play with the board, and wow have I played!

Overall I'm super happy with the design, the limitations, and also that I've managed to pick up steam on the project. 

Luckily I had the camera running when I put together the first board, so that turned into a nice little short on YouTube. 

I also had some time over the recent holidays to play a bit with my i2c bitbanging routine from my #ABN6502 SBC R1 project. For some reason I had to turn up the display clock to get a reasonable refresh rate.
Of course the 128 bytes of RAM in the 6532 RIOT won't fit the 128x64 pixel framebuffer for an OLED but thankfully the SSD1306 comes with a builtin framebuffer, so all I need to display text is to have the font in ROM and ship out the individual characters. 

Since the available ROM size of 4096 might be a limiting factor in a lot of projects too, I decided to optimize for size, so I used a 5x7 font, and limited it to characters 0x20-0x7f = 5*95 bytes = 475 out of 4096 bytes used for the font. 

Speaking of i2c, bitbanging the display on a 1MHz CPU clock isn't exactly groundbreaking speeds, but it's plenty fast for text display. After a bit of assembly optimization I managed to get it up to around 32kHz i2c clock. I'm pretty sure the 6507 can handle 2 MHz, which would double how fast the display can be written, but for now I think it's decent. 

I have a bit of cleaning up to do in the code before I publish to Github but it should get there in the next 24 hours. Soon I'll also be making a video about how bitbanging i2c from a 6502 (*6507) running at 5V to a 3v3 device works, but that might take a bit to make. 

PCB's arrived after just six days and I jumped the first one of them with an iron and had the whole thing done in about an hour. I certainly could've done it in 30 minutes. And it just worked! Zero bodges - but I did use a builtin hack - I think I managed to catch most of that on camera, so maybe that'll turn into a video.

The "hack" is that for the first one I decided to go with the SMD oscillator since I don't have a 1 MHz crystal and didn't want to overclock the first assembly - and it saved me from soldering a few resistors and caps. 

The footprint is a bit big, since I used the "handsoldering" version included with KiCAD - smaller certainly would've been fine too since - but I guess not everyone has a 0,1mm iron tip. 
I decided to put it on the 3v3 rail even though a 5V oscillator would've been a better match, since 3v3 oscillators are way more common in that size. That's out of spec for the 6502 but I know from experience it is not that picky when it comes to input clock - I've had it running stable with way less than 3v peak-to-peak so I have no doubt that an ultra stable modern oscillator with 3 ns rise and fall times will do just fine. If supply of 5V oscillators in that size turn out to be less of a problem I'll probably change it to a 5V can. 

Speaking of - if a teacher wanted to teach soldering and use this as a class set - what I would do would probably be to have the board house do the SMD assembly, since it's single sided and only uses off the shelf SMD components, and have the students assemble the THT components as a kit. 

You might notice the extra 4 pin connector on the photo above that's usually not found on an Arduino board - it has GND VCC SCL and SDA which is perfect for many i2c breakout boards.. Specifically I hope to use it with one of the cheap SSD1306 128x64 OLED boards. Note to self - maybe at least having pads for i2c pullups would be a good idea for the next revision.  

Stay tuned!