Scrolling an SSD1306 OLED in 6502 assembly

[GARTHWILSON]

BillG wrote:

I am waiting for them to block me entirely so that I can try some tricks to defeat it...

Let us know if you figure out a trick that works.  I got the 3...2...1...warning, and then they turned off the service, and in spite of how many YT videos I used to watch every day, I haven't watched a single one now in over 10 days.

[BillG]

I never registered for an account before YT was acquired, so I wasn't going to for the Borg.

Try watching without logging in.

I primarily use Opera to watch YT. It comes with its own ad blocker which may be working better than the common add-ons.

Edge is my secondary browser - it also has built-in ad block though it appears leakier than Opera's. I have never used it to watch YT.

So you might try different browsers. Chrome is almost guaranteed to be the worst since it is part of the Borg Collective.

Finally, go nuclear. There are various techniques to get around age restrictions...


Edit: Edge, not Bing...

Further edit:

Just for gits and shiggles, I tried using the Borg search engine to look for techniques and was surprised how many discussions that turned up. The left hand apparently doesn't know what the right is doing. Either that or it is a diabolical scheme to get users to do pen testing for them...

[barnacle]

I've had a couple of warnings; now I'm using FreeTube (apparently available for Windows as well as Linux). It's more intended, I think, if you have a number of people you follow rather than just splashing in and out.

That said, I have had no warnings recently on Youtube (I use both uBlock Origin and Noscript), and on the TV which also offers YT there has been a noticeable absence of adverts where they have appeared in the past.

Neil

[GARTHWILSON]

BillG, I have not had a YT account since Google acquired it and insisted I have, and use, a Google account, which I will not do.  I still cannot view any YT videos since I'm not willing to disable adblock.  [Edit:  I have been watching YT without a Google account for years.  The watching ended 11 days ago.]

barnacle, I see FreeTube in the Ubuntu software center now, so I'll try that.

[drogon]

GARTHWILSON wrote:

BillG, I have not had a YT account since Google acquired it and insisted I have, and use, a Google account, which I will not do.  I still cannot view any YT videos since I'm not willing to disable adblock.

barnacle, I see FreeTube in the Ubuntu software center now, so I'll try that.

Wandering way off-topic, but it's relatively easy to watch youtube without a google account. You use Firefox, install UBlock Origin and open a private window and off you go.

However it's a constant cat & mouse game. Eventually google/youtube will seamlessly inject adverts mid-stream and they'll be much harder to block They have the technology and the cpu power to do this.

I'll continue to use google/YouTube for some time - not because I want to earn money through it, but because it's easy. I have the resources and ken to host my own videos, but it's easier with youtube - and also searchable - and that's the key for a lot of people. Make a video for a nice small/niche community and host it yourself and great, but if you ever want to engage a wider audience, no-one out there will find you... google can make sure of that, although other search engines are out there.. I switched to duckduckgo some time back and occasionally revert to google but mostly ddg has the results I need.

Also - don't kid yourself that google isn't tracking you. Google provides many many services that appear transparent to us - am obvious one is fonts. Many web pages you view will fetch a font from google and in doing so, Google will fingerprint your browser, IP address and so on. That are many other instances like this - a library of handy scripts, graphics and so on. It's almost impossible to turn google off and maintain a usable internet experience now. And just because you can't google someone, doesn't mean google doesn't know it. They're just not telling.

-Gordon

[barrym95838]

[Off-Topic transgression; removed, with apologies]

[BigEd]

You might or might not be in the minority, but I can't help wondering what this has to do with scrolling an OLED. It might seem - it might be - that I'm particularly grumpy, but it doesn't seem good to me to lose all thread discipline, which seems to have happened over the past few months. It could result in this place being much less useful as a repository of discussions, ideas, conclusions.

[AndersNielsen]

Michael wrote:

AndersNielsen wrote:

Unfiltered feedback appreciated!

I wonder if it would it be worth the effort to include in-circuit programming capability via a USB serial connection for iterative code development and testing on a project like this? I couldn't resist fleshing out a couple ideas (below)...

Please keep up the good work.

Anyone actually try programming an SST39SF010 with a 6502?

The whole "magic byte dance" on the address bus looks like it's going to give me a headache.. By demanding $5555 and $2AAA are in ROM address space.

[gfoot]

AndersNielsen wrote:

Anyone actually try programming an SST39SF010 with a 6502?

The whole "magic byte dance" on the address bus looks like it's going to give me a headache.. By demanding $5555 and $2AAA are in ROM address space.

I haven't programmed this device, but it sounds like it has similar requirements to a locked AT28C256 EEPROM. Here's example code to deal with that for the Pi Pico in case it helps: https://github.com/gfoot/picoprom/blob/ ... prom.c#L67

In your 6502 case, you don't need those addresses to actually be in the ROM's address space from the CPU's perspective - what you need is to work out what addresses to use from the CPU to cause those bit patterns to appear on the ROM's address lines. So if your ROM region is filling the upper half of the memory map, then you'd write to $D555 and $AAAA instead, i.e. the same addresses but with the top bit set - the top bit triggers the address decoding to select the ROM, and the rest of the bits are passed through to the ROM, giving the desired addresses.

The only challenge of this byte dance, at least for full-page writes on the AT28C256, is that you need to be careful with the timing and also mustn't read from the chip during the operation (so your code needs to be located elsewhere). If you pause too long between writes, or try to execute reads, it truncates the page write operation and returns garbage to the CPU for a while, as the operation is taking place in the background. So you need to execute the dance and supply all the data with the right timing in one operation, then be prepared to sit and wait for a while running code from elsewhere (e.g. RAM) as the chip performs the full page write.

[drogon]

AndersNielsen wrote:

Anyone actually try programming an SST39SF010 with a 6502?

The whole "magic byte dance" on the address bus looks like it's going to give me a headache.. By demanding $5555 and $2AAA are in ROM address space.

Yes, I'm doing it right now, as we speak.

I'm programming the SST39SF010 EEPROM in the WDC65C134-SXB board directly from 6502 code. (From TinyBasic, but that not relevant) It's working very well (now, anyway, it wasn't easy to get going for many reasons not directly connected to the SST39SF010).

You need to copy code into RAM and run it from RAM to program the EEPROM. You can't program it from code running inside the EEPROM - because code access gets in the way of the "magic byte dance" routine.

So that's what I do - I have a version of my TinyBasic that I download into RAM to run from there - it's a handy tool to write a programmable device flasher in than anything else and call some specific built-ins to do sector erase and programming from RAM images..

Here is the relevant snippets of code:

Code: Select all

;********************************************************************************
;* doEra:
;*      Erase a single 4K sector of the EEPROM
;*      Variables:
;*              A has the EEPROM address
;*              D has the EEPROM bank (0-3)
;********************************************************************************

.macro  flaCmd  addr,data
        lda     #data
        sta     $8000+addr
.endmacro

.proc   doEra
        jsr     extractVars
        jsr     flashSetup


        flaCmd  $5555,$AA               ; Unlock
        flaCmd  $2AAA,$55
        flaCmd  $5555,$80
        flaCmd  $5555,$AA

        flaCmd  $2AAA,$55               ; Sector erase

        lda     #$30                    ; Erase command
        ldy     #$00
        sta     (regA),y
wait:
        lda     (regA),y
        cmp     #$FF
        bne     wait
                                        ; Fall into...
.endproc

and

Code: Select all

;********************************************************************************
;* doFla:
;*      Flash data into the device
;*      Variables:
;*              A has the FROM address (RAM)
;*              B has the TO address   (Flash)
;*              C has the length.
;*              D has the ROM page (0-3)
;*      On exit the variables, A, B and C are updated.
;********************************************************************************

.proc   doFla

        jsr     extractVars
        jsr     flashSetup

        ldy     #0
loop:
        flaCmd  $5555,$AA               ; Unlock
        flaCmd  $2AAA,$55
        flaCmd  $5555,$A0               ; Byte write

        lda     (regA),y
        sta     (regB),y
wait:
        cmp     (regB),y
        bne     wait

; Inc To:

        inc     regAL
        bne     :+
        inc     regAH

; Inc From:

:       inc     regBL
        bne     :+
        inc     regBH

; Dec. count

:       lda     regCL
        bne     :+
        dec     regCH
:       dec     regCL

; If not zero, then go back for more...

        lda     regCL
        ora     regCH
        bne     loop

You can ignore the JSRs at the start - that's to do with getting data from the Basic environment into the ASM world and also setting up the SXB hardware for the right thing (it treats the 128KB EEPROM as 4 banks of 32KB and there is further shenanigans to do with the built-in ROM).

Remember to disable all interrupts before you start the operations too.

This is what I'm doing for "bulk" re-flashes of my new OS and TB for the '134 - once my TB in is ROM, then to do the flashing for program saves, it copies a little stub into a small reserved area of RAM and calls that to do the actual load/save of Basic programs.

Hope this helps..

-Gordon

[Michael]

AndersNielsen wrote:

Michael wrote:

AndersNielsen wrote:

Unfiltered feedback appreciated!

I wonder if it would it be worth the effort to include in-circuit programming capability via a USB serial connection for iterative code development and testing on a project like this? I couldn't resist fleshing out a couple ideas (below)...

Please keep up the good work.

Anyone actually try programming an SST39SF010 with a 6502?

The whole "magic byte dance" on the address bus looks like it's going to give me a headache.. By demanding $5555 and $2AAA are in ROM address space.

When I was fleshing out the idea of using a $2 Nano uC for in-circuit programming on a variation of your 65uino design I realized I would have to force writes to ROM in the decoded $1XXX block or its shadows and manipulate the ROM A12, A13, and A14 address lines to spoof the $2AAA and $5555 addresses required for ROM command and control sequences. If it helps, here are some notes for a uC wrByte() function (below). It's fast enough to program bytes between incoming characters at 115,200 baud. I would need a similar function to erase the 4K sector. A simple set of functions could present as Erase (about 50-msecs), Program (from hex file, about 2 seconds), Display (memory), and Run commands to the host PC running terminal software or a custom program.

Good luck. Have fun. Mike

Code: Select all

    /* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       ~  wrByte() in Flash ROM on Neil's 65uino (erase 4k sector first)  ~
       ~                                                                  ~
       ~  force ROM writes to the decoded $1XXX block and setup the A12,  ~
       ~  A13, and A14 address lines to spoof a $2AAA or $5555 address.   ~
       ~                                                                  ~ 
       ~  the uPush() clock function disables ROM (RUN pin = 0) and the   ~
       ~  uPull() clock function enables ROM (RUN pin = 1).               ~
       ~                                                                  ~
       ~  set the 6507 'PC' to $1000 to avoid running the 'PC' into the   ~
       ~  I/O area during programming operations.                         ~
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
    /*     uReset();                  //  reset 6507 (sync' uC to cpu)    ~
           uPush(0x4C);               //  jmp $1000  reset PC             ~
           uPush(lo(0x1000));         //   "         abs address lo       ~
           uPush(hi(0x1000));         //   "         abs address hi       ~
    // ~~~ wrMEM(0x5555,0xAA) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           set(x12);                  //  rom A12 = 1                     ~
           clr(x13);                  //  rom A13 = 0                     ~
           set(x14);                  //  rom A14 = 1                     ~
           uPush(0xA9);               //  lda #$AA                        ~
           uPush(0xAA);               //   "                              ~
           uPush(0x8D);               //  sta $1555 (spoof rom $5555)     ~
           uPush(lo(0x1555));         //   "         address lo           ~
           uPush(hi(0x1555));         //   "         address hi           ~
           uPull();                   //   "         6507 write cycle     ~
    // ~~~ wrMEM(0x2AAA,0x55) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           clr(x12);                  //  rom A12 = 0                     ~
           set(x13);                  //  rom A13 = 1                     ~
           clr(x14);                  //  rom A14 = 0                     ~
           uPush(0xA9);               //  lda #$55                        ~
           uPush(0x55);               //   "                              ~
           uPush(0x8D);               //  sta $1AAA (spoof rom $2AAA)     ~
           uPush(lo(0x1AAA));         //   "         address lo           ~
           uPush(hi(0x1AAA));         //   "         address hi           ~
           uPull();                   //   "         6507 write cycle     ~
    // ~~~ wrMEM(0x5555,0xA0) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           set(x12);                  //  rom A12 = 1                     ~
           clr(x13);                  //  rom A13 = 0                     ~
           set(x14);                  //  rom A14 = 1                     ~
           uPush(0xA9);               //  lda #$A0                        ~
           uPush(0xA0);               //   "                              ~
           uPush(0x8D);               //  sta $1555 (spoof rom $5555)     ~
           uPush(lo(0x1555));         //   "         address lo           ~
           uPush(hi(0x1555));         //   "         address hi           ~
           uPull();                   //   "         6507 write cycle     ~
    // ~~~ wrMEM(addr,data) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           clr(x12);                  //  rom A12 = 0                     ~
           clr(x13);                  //  rom A13 = 0                     ~
           clr(x14);                  //  rom A14 = 0                     ~
           uPush(0xA9);               //  lda #data                       ~
           uPush(data);               //   "                              ~
           uPush(0x8D);               //  sta addr  ($1000..$1FFF)        ~
           uPush(lo(addr));           //   "         address lo           ~
           uPush(hi(addr));           //   "         address hi           ~
           uPull();                   //   "         6507 write cycle     ~
           _delay_us(20);             //  required write delay            ~
    // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */

[AndersNielsen]

Michael wrote:

AndersNielsen wrote:

Michael wrote:

AndersNielsen wrote:

Unfiltered feedback appreciated!

I wonder if it would it be worth the effort to include in-circuit programming capability via a USB serial connection for iterative code development and testing on a project like this? I couldn't resist fleshing out a couple ideas (below)...

Please keep up the good work.

Anyone actually try programming an SST39SF010 with a 6502?

The whole "magic byte dance" on the address bus looks like it's going to give me a headache.. By demanding $5555 and $2AAA are in ROM address space.

When I was fleshing out the idea of using a $2 Nano uC for in-circuit programming on a variation of your 65uino design I realized I would have to force writes to ROM in the decoded $1XXX block or its shadows and manipulate the ROM A12, A13, and A14 address lines to spoof the $2AAA and $5555 addresses required for ROM command and control sequences. If it helps, here are some notes for a uC wrByte() function (below). It's fast enough to program bytes between incoming characters at 115,200 baud. I would need a similar function to erase the 4K sector. A simple set of functions could present as Erase (about 50-msecs), Program (from hex file, about 2 seconds), Display (memory), and Run commands to the host PC running terminal software or a custom program.

Good luck. Have fun. Mike

Oh now I get it! Thanks for the detailed feedback!

I'm thinking the X12-14 aren't needed since A14 == A12 and A13 is the inverted A12 and that's the inversion we already have as ~OE on the 65uino.
On this revision I have ROM-A12 grounded(easy trace to cut) but instead I could just connect it to A12 and offset ROM data.

From there I guess the issue is ~OE is active @ $5555 - so instead of just inverting A12 for ~OE it could be A12 NAND ~RW.. But then we'd be missing the inverted A12 for A13.

So unless gating ROM ~RW with PHI2 is strictly necessary a single extra NAND gate would do the trick - but obviously not being able to program the whole ROM... Even though it would make it self-programmable.

I think when we write AA and A0 to address 2AAA we'll also be writing to Output Register B on the 6532.. And that's not ideal, but maybe not a dealbreaker.

@drogon - Yay! Almost makes it look like timing isn't that big of a deal? Do you just happen to have $5555 and $2AAA in ROM address space or other hardware decoding?

[drogon]

AndersNielsen wrote:

@drogon - Yay! Almost makes it look like timing isn't that big of a deal? Do you just happen to have $5555 and $2AAA in ROM address space or other hardware decoding?

The EEPROM is mapped to $8000-$8FFF in the 134-SXB board. There are 2 bits in an output port to control the top 2 address bits, so I can access all 128KB of it in 32KB "banks" ... I write the magic spells to $8000+$5555, etc.

As for timing - not checked - I started writing it from a TinyBasic program (interpreter running in RAM) but I added in assembler code as commands in the interpreter to make life easy... This is actually a "bootstrap" process to enable me to put my own code inside the EEPROM on that board, so start board, download "special" version of GIBL into RAM, download ROM version of GIBL and replacement monitor into RAM, use a Basic program to flash the RAM images into ROM, light the blue touch paper and stand well back...

-Gordon

[AndersNielsen]

drogon wrote:

AndersNielsen wrote:

@drogon - Yay! Almost makes it look like timing isn't that big of a deal? Do you just happen to have $5555 and $2AAA in ROM address space or other hardware decoding?

The EEPROM is mapped to $8000-$8FFF in the 134-SXB board. There are 2 bits in an output port to control the top 2 address bits, so I can access all 128KB of it in 32KB "banks" ... I write the magic spells to $8000+$5555, etc.

As for timing - not checked - I started writing it from a TinyBasic program (interpreter running in RAM) but I added in assembler code as commands in the interpreter to make life easy... This is actually a "bootstrap" process to enable me to put my own code inside the EEPROM on that board, so start board, download "special" version of GIBL into RAM, download ROM version of GIBL and replacement monitor into RAM, use a Basic program to flash the RAM images into ROM, light the blue touch paper and stand well back...

-Gordon

Gotcha!
As long as it works, thats good enough timing for now.

Also just realized I don't need the inverter to do the magic dance either - connecting A11 to A13 should do the same thing, except that requires duplicating ROM sections.

[Michael]

Thought you might enjoy this. I was wondering if it's possible to fit an ICSP (In-Circuit-Serial-Programming) program into the 128 bytes of RIOT RAM on modified 65uino hardware. The attached file contains clumsy, untested, and probably buggy code, and while the ICSP process has a few limitations and caveats, I'm kinda' geeked to see what you can fit in 128 bytes.

Regards, Mike