65uino

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!

First PCB's ordered. Gerbers posted to Github if you're feeling especially lucky - I'd be surprised if a bodge or two won't be needed. With a holiday coming up I have a horrible feeling I won't get my hands on them before there's less than a week left until the challenge round deadline. 

I also had to throw in a last minute change, since 1 MHz crystals might not be as common as I thought. The breadboard version has a 1 MHz can oscillator but unless I mount that awkwardly in a socket on top of some other components(or the dreaded bottom of the PCB) there's simply no room for a DIP8 footprint can. 
My solution is a 2.5x2mm SMD oscillator, slightly overlapping the crystal footprint since they won't be used at the same time anyway - the more options the merrier I guess. 

I'll certainly be trying my luck with some 2-3MHz overclocking eventually - I have a feeling the bottleneck will be the 6532 before the 6507. 

With only a month from the announcement of the HaD Prize 2023 to the close of the first challenge round there certainly isn't a lot of time to come up with something brilliant - but challenge most certainly accepted!

It certainly doesn't leave a lot of time to source parts for the prototype but thankfully I do have a left over 6507, a couple of 6532's and some ROM's - hopefully I will get the PCB in time to try it out... and if I know my luck, time to make some bodges before the challenge round is over. 

I started thinking about the project on Sunday and I'm happy to say I just published the KiCAD files to Github. https://github.com/AndersBNielsen/65uino

If you see something weird I'd certainly like heads up! Planning to order PCB's tonight or tomorrow. (Note to self: Add pads for extra decoupling caps before ordering!)

When I put together projects like this I can't help but feel people look at it like some sort of steampunk alternate time line but where IC's stopped shrinking in the 70's instead of the during the industrial revolution. 

That's not exactly what I'm going for but I do appreciate the aesthetic of large DIP's on a modern PCB and it is fun to imagine a world where the electronics that powered Space Shuttle Columbia is still in wide use today.
Fun fact: At least until recently the ISS EVA Suits - a.k.a. space suits - were 6502 powered. Allegedly.

Just because IC packages have shrunk quite a bit over the past 50 years there's still quite a lot to learn from the integrated circuits that powered the home computer revolution and beyond. 

Concepts like memory addressing, stack, busses, interrupts, and machine language instructions - at least to me - really are a lot easier to get a firm grip on if you can point at a component and say "when I address I/O, this chip sets these voltages to indicate to this other chip what we want to do" instead of a single package doing all the work.

In a teaching environment, or just following along with my videos (or Ben Eater's for that matter) I hope that showing where each component is and what it specifically does will make programming, computer engineering and embedded design much less of a steep conceptual hill to climb. 

Hopefully I'll succeed doing exactly that with the #65uino. Liftoff!