I made a Single Breadboard Computer

[AndersNielsen]

A 6502 Based Computer on a Single Breadboard
https://youtu.be/s3t2QMukBRs

Spoilers: 6507,6532,ROM,74’04

Whatcha think?

I might try with a SSD1306 i2c display in the future. Maybe someone will have written some code for that already.

[BigEd]

I like it!

[BillO]

Cool! This was the sort of idea I had when I had my little contest a couple of years ago.

[plasmo]

Yes, I like something small and simple.

I have a couple SSD1306 programs (analog clock, Conway Game of Life) for 128x64 OLED display. You can find them on CRC65 homepage.
Bill

[AndersNielsen]

Thank you, all!

plasmo wrote:

Yes, I like something small and simple.

I have a couple SSD1306 programs (analog clock, Conway Game of Life) for 128x64 OLED display. You can find them on CRC65 homepage.
Bill

That'll certainly save me some time and it won't really take up more space on the Breadboard.

[Michael]

I thought it was another nice video, Anders. I envy your organization and video production skills.

[AndersNielsen]

My Single Breadboard Computer also transmuted into another first: The first 6502 based Arduino-clone!
I call it the 65uino

https://hackaday.io/project/190260-65uino

[plasmo]

I like that a lot. You can put it in an acrylic enclosure for arduino that is readily and cheaply available off eBay. I’ve designed a series of SBC for Arduino Mega enclosure which is a bit bigger. Like this, https://www.retrobrewcomputers.org/lib/ ... otated.jpg

I called them Zuno, or Kuno, or ZRuno, etc. I was thinking about putting CRC65 in an Arduino mega case as well, but I see 65uino name is already taken. I guess I’ll have to call if CRCuino, or something.
Bill

[AndersNielsen]

plasmo wrote:

Yes, I like something small and simple.

I have a couple SSD1306 programs (analog clock, Conway Game of Life) for 128x64 OLED display. You can find them on CRC65 homepage.
Bill

@plasmo
I got it working-ish. I ended up using my own I2C routine and initialization, but your code did help me figure out a couple of things
Since I only have 128 bytes of RAM I can't do the double framebuffer thing, so I have to rely on the one in the ssd1306.
However... It's blinking. It "works" and I got it to display text and everything(font takes up 5*95 bytes of ROM).. But it blinks. Like 10 hz refresh rate blinks - or like a fast version of the rolling bars you sometimes see on recordings of CRT screens.
I've been assuming it was bad hardware but a new 128x64 .96" OLED acts exactly the same way :/

Do you or anyone else see if somethings's up with my init?

Code: Select all

.byte $ae		;turn off display
.byte $d5		;set display clock div
.byte $80		;ratio 0x80
.byte $A8		;set multiplex
.byte $3f		; 128x64
.byte $d3		;set display offset
.byte $00    ; None
.byte $40		;set startline
.byte $8d		;charge pump
.byte $14		;vccstate 14
.byte $a1 ; Segment re-map
.byte $c8 ; Com output scan direction
.byte $20		;memorymode
.byte $00 ;
.byte $da		;set com pins
.byte $12		; 02 128x32 12 ; ??
.byte $81	  ; set contrast
.byte $10		;contrast
.byte $d9		;set precharge
.byte $ee		;vcc state f1
.byte $db		;set vcom detect
.byte $40
.byte $a4		;display all on resume
.byte $a6		;A6 = normal display, A7 = invert
.byte $af		;display on
.byte $00 ; ColumnL 0
.byte $10 ; ColumnH 0
.byte $B0 ; Page 0

[AndersNielsen]

Hmm. Doesn't matter if I run the module on 3v3 or 5V.
If I crank up the display clock to max (d5 f0) the refresh flicker is hardly visible unless I move it and having precharge set to 0x11 seems to help too. It's still very visible on my phone camera. On my other camera the tearing starts to be visible around 1/13s shutter speed.

These are my current settings for future reference - I'm happy with how it looks but I'm still confused why I have to crank up the speed so much. Maybe something is slowing down the RC clock of the display.

Code: Select all

.byte $ae		;turn off display
.byte $d5		;set display clock div
.byte $f0		;ratio 0x80
.byte $A8		;set multiplex
.byte $3f		; 128x64
.byte $d3		;set display offset
.byte $00    ; None
.byte $40		;set startline
.byte $8d		;charge pump
.byte $14		;vccstate 14
.byte $a1 ; Segment re-map
.byte $c8 ; Com output scan direction
.byte $20		;memorymode
.byte $00 ;
.byte $da		;set com pins
.byte $12		; 02 128x32 12 ; ??
.byte $81	  ; set contrast
.byte $3f		;contrast, $3f = One quarter
.byte $d9		;set precharge
.byte $11		;vcc state f1
.byte $db		;set vcom detect
.byte $20   ; 0.77V (Default)
.byte $a4		;display all on resume
.byte $a6		;A6 = normal display, A7 = invert
.byte $af		;display on
.byte $00 ; ColumnL 0
.byte $10 ; ColumnH 0
.byte $B0 ; Page 0

[Michael]

Here are a couple init settings I've used with SSD1306 OLED displays (you'll notice many of the 'default' settings were used). Hope this helps.

Code: Select all

/************************************************************************
 *   init command sequence for 0.96" SSD1306 SPI 128x64 OLED display    *
 ************************************************************************/

   const unsigned char ssdcfg[] = { 
  // 0xAE,                          // displayoff . . . . . . . (default)
  // 0xD5, 0x80,                    // displayclockdiv & param  (default)
  // 0xA8, 0x3F,                    // setmultiplex & param ()  (default)
  // 0xD3, 0x00,                    // setdisplayoffset & param (default)
  // 0x40,                          // setstartline . . . . . . (default)
     0x8D, 0x14,                    // chargepump & param
     0x20, 0x00,                    // memorymode 'horizontal'
  // 0xA1,                          // segremap (A0/A1, flip horizontally)
  // 0xC8,                          // comscandec (C0/C8, flip vertically)
  // 0xDA, 0x12,                    // setcompins () . . . . .  (default)
  // 0x81, 0x7F,                    // setcontrast, 0-255 . . . (default)
     0xD9, 0xF1,                    // setprecharge
     0xDB, 0x40,                    // setvcomdetect
  // 0xA4,                          // displayallon_resume . .  (default)
  // 0xA6,                          // normaldisplay . . . . .  (default)
     0xAF                           // displayon
   };                               //

Code: Select all

/************************************************************************
 *   init command sequence for 0.91" SSD1306 I2C 128x32 OLED display    *
 ************************************************************************/

   const unsigned char ssdcfg[] =  
   { 
  // 0xAE,                          // displayoff               *
  // 0xD5, 0x80,                    // displayclockdiv & param  *
     0xA8, 0x1F,                    // setmultiplex & param ()
  // 0xD3, 0x00,                    // setdisplayoffset & param *
  // 0x40,                          // setstartline             *
     0x8D, 0x14,                    // chargepump & param
     0x20, 0x00,                    // memorymode 'horizontal'
  // 0xA1,                          // segremap (A0/A1, flip horizontally)
  // 0xC8,                          // comscandec (C0/C8, flip vertically)
     0xDA, 0x02,                    // setcompins ()
     0x81, 0x5F,                    // setcontrast
     0xD9, 0xF1,                    // setprecharge
     0xDB, 0x40,                    // setvcomdetect
  // 0xA4,                          // displayallon_resume
  // 0xA6,                          // normaldisplay
     0xAF                           // displayon
   };                               //

[Michael]

I enjoyed your I2C on a 6502 Single Board Computer video. Bit-banging the I2C protocol is a nice challenge and the relatively inexpensive 0.96" and 1.3" OLED displays are fun to code and use, though they require precious memory for one or more font tables.

May I suggest a relatively inexpensive keypad solution to complement the OLED display? They're LED lighting controller sets which include a small LED controller module and an IR remote keypad. You would remove the IR Receiver from the controller and connect it to a single I/O line on the 6532 RIOT (with pull-up) and you will need some 6502 code to parse the NEC codes from the IR keypad. A plastic coated paper keypad overlay would be a nice finishing touch.

Have fun. Stay safe. Mike

[AndersNielsen]

Michael wrote:

I enjoyed your I2C on a 6502 Single Board Computer video. The relatively inexpensive 0.96" and 1.3" OLED displays are fun to code and use, even though they require precious memory for one or more font tables.

May I suggest a relatively inexpensive keypad solution to complement the OLED display? They're LED lighting controller sets which include a small LED controller module and an IR remote keypad. You would remove the IR Receiver from the controller and connect it to a single I/O line on the 6532 RIOT (with pull-up) and you will need some 6502 code to parse the NEC codes from the IR keypad. A plastic coated paper keypad overlay would be a nice finishing touch.

Have fun. Stay safe. Mike

Thanks for watching!

That's certainly the right price range! I might make a video with enough detail to do it with just a vs1838b IR receiver and whatever IR remote you have in your junk drawer (to stay with the green theme of only buying new if you can't rescue some junk - and an old TV remote membrane is usually better quality than the cheapest membranes).

Good idea!

[Michael]

Good point. I have plenty of old IR Remotes on hand.

I purchased some shiny new ("new old stock") CMOS 6504's several years ago at a premium (they would represent half the cost of a $10 SBC) which are waiting for just the right project. The 6504 has an IRQ pin in place of the RDY pin on the 6507.

Cheerful regards, Mike

[AndersNielsen]

Michael wrote:

Good point. I have plenty of old IR Remotes on hand.

I purchased some shiny new ("new old stock") CMOS 6504's several years ago at a premium (they would easily represent half the cost of a $10 SBC) which are waiting for just the right project. The 6504 has an IRQ pin in place of the RDY pin on the 6507.

Cheerful regards, Mike

Those are beautiful! Didn't think about them being a drop in replacement for the 6507 but it certainly looks like it. The IRQ pin is generally more useful than the RDY pin - but in many cases you can get away with soft IRQ on a pin you can read with BIT. The 6507's are a bit more expensive than generic 6502's too - but not enough to really matter.