6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Apr 27, 2024 8:33 pm

All times are UTC




Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Wed Nov 08, 2023 7:31 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 08, 2023 7:49 am 
Offline

Joined: Thu Mar 12, 2020 10:04 pm
Posts: 690
Location: North Tejas
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...


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 08, 2023 8:22 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 660
Location: Potsdam, DE
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 08, 2023 8:41 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 08, 2023 9:00 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1399
Location: Scotland
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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 08, 2023 4:37 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1927
Location: Sacramento, CA, USA
[Off-Topic transgression; removed, with apologies]

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Last edited by barrym95838 on Wed Nov 08, 2023 9:14 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 08, 2023 5:40 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 09, 2023 12:19 pm 
Offline
User avatar

Joined: Sun Dec 26, 2021 8:27 pm
Posts: 182
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.


Attachments:
Screenshot 2023-11-09 at 13.15.21.png
Screenshot 2023-11-09 at 13.15.21.png [ 215.31 KiB | Viewed 2763 times ]

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1 :)
Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 09, 2023 12:37 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 09, 2023 12:40 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1399
Location: Scotland
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:
;********************************************************************************
;* 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:
;********************************************************************************
;* 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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 10, 2023 9:51 am 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 586
Location: Michigan, USA
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:
    /* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       ~  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            ~
    // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */


Attachments:
6504 RIOT Lab 2.png
6504 RIOT Lab 2.png [ 159.17 KiB | Viewed 2720 times ]
Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 10, 2023 8:16 pm 
Offline
User avatar

Joined: Sun Dec 26, 2021 8:27 pm
Posts: 182
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?

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1 :)


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 10, 2023 8:30 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1399
Location: Scotland
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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 10, 2023 11:02 pm 
Offline
User avatar

Joined: Sun Dec 26, 2021 8:27 pm
Posts: 182
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.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1 :)


Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 12, 2023 7:29 pm 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 586
Location: Michigan, USA
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


Attachments:
6504 RIOT Lab 2a.png
6504 RIOT Lab 2a.png [ 152.32 KiB | Viewed 2619 times ]
flash.s.txt [7.56 KiB]
Downloaded 44 times


Last edited by Michael on Wed Nov 15, 2023 1:22 am, edited 1 time in total.
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 24 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: