6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 2:32 am

All times are UTC




Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Don't write to ROM
PostPosted: Sat Jan 21, 2023 9:22 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
Speaking of address decoding...

I think that like many here, as a part of my retrocomputing experience I enjoy reading what you might call "period literature." For example, Microprocessor Interfacing Techniques by Rodnay Zaks, and Programming & Interfacing the 6502, with Experiments by Marvin L. De Jong.

These older sources sometimes suggest that best practice of the time was to gate ROM selects with R/W\ to prevent accidentally writing to ROM; the disadvantage of this approach being that the selection of the (already slow) ROM will be delayed until Ø2.

I have seen a few designs on the forums that prevent selecting ROM during a write operation, but not too many. Since the board I'm building right now uses oldschool parts with kind of an oldschool design (using the processor's Ø2-out to control timing, for example) I was considering adding an OR gate to prevent accidental writes to ROM.

I'm curious what others think about this. I thought I remembered reading in the Primer that Garth does not do this, because accidental writes to ROM are rare, will probably be found during debugging, and because ROM chips are robust enough to survive the occasional mistake. However, after a quick check of the "address decoding" page, I don't see those comments, so maybe I am misremembering!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sat Jan 21, 2023 9:44 pm 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1120
Location: Albuquerque NM USA
I like to hear concerns about writing to ROM or flash. Many of my designs had assumed no ill effects from ROM writes and use that to “shadow write” data to corresponding RAM reside in the same memory space.

As you may already know, ROM is slow and useful only during bootstrapping so sooner you can copy ROM to RAM and get it off the memory map, the more you have the limited 64K space available for more RAM or I/O. Reading ROM and writing it back is a one of techniques for copying ROM to RAM. I love to hear why that’s a bad idea.
Bill


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sat Jan 21, 2023 9:58 pm 
Offline

Joined: Sun May 07, 2017 3:59 pm
Posts: 21
Rom chips usually have distinct CS and OE lines - so you could still "select" the chip on a write cycle, as long as you don't enable the output.


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sat Jan 21, 2023 11:32 pm 
Offline
User avatar

Joined: Fri Aug 03, 2018 8:52 am
Posts: 746
Location: Germany
is this actually a concern? like if you don't want the ability to write to the ROM couldn't you just pull the WE line of the ROM/FLASH chip permanently high?
even when you connect it, modern Flash chips require a very specific sequence of accesses to unlock them, so it's immensely unlikely to happen by accident. especially on 65c02 systems as they cannot even fit the whole address range required to write to the flash in the first place (atleast without some kind of MMU)

so this only seems like an issue if you're using an actual EEPROM and designed your system around being able to program it in-system. in which case you could use a physical jumper for the WE pin. Or if you use PLDs or CPLDs for your logic, implement a software controlled switch to enable/disable writing to the ROM.


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sat Jan 21, 2023 11:44 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
I certainly have a unique look at "writing to ROM". Here are three thoughts:

1) I used to 'write to ROM' to output to my video RAM. It was very convenient to do so as my video memory was write-only from the 6502 side anyways.

2) On my most recent boards, I now 'write to ROM' to latch output bits used for things like ROM banking, audio output, and SPI pins. It has worked very well.

3) Like Proxy and hmn have said, you can do things so that you are never *really* writing to ROM. I pull the /WE pin high on my SST39SF010 Flash ROM's. Likewise, the /OE and/or /CE lines are opposite of the /RW, meaning it will only be selected on reads not writes anyways.

Thus, I have never ever had a problem with 'writing to ROM'. I have thought of putting a jumper on the /WE line, so that I could actually *try* to write to ROM at some point, but the way I access it through the memory map would not allow for it anyways.

There's my take on it. Thank you!

Chad


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sun Jan 22, 2023 1:01 am 
Offline

Joined: Sun May 07, 2017 3:59 pm
Posts: 21
Proxy wrote:
is this actually a concern? like if you don't want the ability to write to the ROM couldn't you just pull the WE line of the ROM/FLASH chip permanently high?

I assume that the issue is not "overwriting" the ROM, but rather the CPU and ROM both trying to drive the data bus during the write cycle.


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sun Jan 22, 2023 4:19 am 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
Thanks for the replies so far!

hmn wrote:
Proxy wrote:
is this actually a concern? like if you don't want the ability to write to the ROM couldn't you just pull the WE line of the ROM/FLASH chip permanently high?

I assume that the issue is not "overwriting" the ROM, but rather the CPU and ROM both trying to drive the data bus during the write cycle.


Yes, this. For example:

Gene Zumchak in a vintage computer magazine wrote:
For ROM selects, it is desirable to gate in the R/W signal, so that the ROM select can never go true for a write operation. In the AIM, for example, ROM selects are generated from a 2 to 4 decoder. Ironically, this decoder has a gate input that was grounded instead of using the inverted R/W signal. If a write operation is attempted to ROM area, both the ROM and 6502 will attempt to drive the bus. Fortunately, most chips are designed to take momentary shorting and it is most unlikely that any harm will come to the 6502 or ROM. Still, it is careless design not to consider that writes may be attempted to read-only space.


I guess "is this actually a concern?" is my question as well. Historically, at least, it was enough of a concern that some people wrote about it and designed safeguards. I've seen a few designs on the forums that do as well, but people seem mostly interested in getting the ROM ready as early as possible, since slow ROM tends to be the limiting factor for system speed.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sun Jan 22, 2023 6:22 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
I think most of these old design features were implemented as a safety for many of the older ROM chips, like the 2332 and 2364 mask ROMs. Commodore used these in the Vic-20, C-64, 1541, etc. These parts have address lines, data lines and a chip select line. There's no read or write signal. As many early machines also had incomplete address decoding. This allowed for smaller and cheaper designs, but also led to having shadow accesses of devices. If your hardware managed to generate a chip select on a phantom address during a write instruction (assuming one of the 2332/2364 ROMs), you would have the ROM trying to assert it's data on the data bus at the same time the CPU is trying to assert it's data on the data bus.

For other ROM type devices which have an OE line and a WR line, a simple hardware jumper will suffice. The same would apply for older EPROM devices which use higher voltages for programming, which wouldn't be present in the basic hardware design. For more modern ROM devices, like EEPROMs, some can be easily programmed insitu without having to unlock them (the AT28C256 can be programmed without an unlock code). Other devices, like the AT28BV256 does require an unlock code. Newer and larger Flash devices also require an unlock code sequence, but as previously noted, most of these devices are 128KB and larger, so there's no easy way to send an unlock code with a sub 64KB addressable space.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sun Jan 22, 2023 9:15 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
I'm sure the original idea is to avoid contention: the electrical problem where the ROM drives a zero and the 6502 drives a 1, or vice versa.

Those schemes where writes into what's normally ROM space are different: the writes are directed to some hardware, and the ROM does not drive the bus. These are not ROM writes, to my way of thinking.

And then Flash ROM is another case, because it can be written, and the idea of being able to update it while in circuit is quite a feature. Again, there won't be contention, because it sees the RnW line and acts accordingly.

There is something to watch out for though: if you have a write-locked Flash ROM and you happen to send a write to it, it will go through some internal sequence of states which will cause reads not to work for some short time. Accidental writes will break reads, and this will appear as an obscure bug in your design. So, the write-locking prevents writes, but there still might be benefit in implementing a write-protect.


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sun Jan 22, 2023 11:48 am 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
BigEd wrote:
There is something to watch out for though: if you have a write-locked Flash ROM and you happen to send a write to it, it will go through some internal sequence of states which will cause reads not to work for some short time. Accidental writes will break reads, and this will appear as an obscure bug in your design. So, the write-locking prevents writes, but there still might be benefit in implementing a write-protect.


WOW, that is good info Ed, thank you. I hadn't even thought of that!

Chad


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sun Jan 22, 2023 11:49 am 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 589
Location: Michigan, USA
floobydust wrote:
Newer and larger Flash devices also require an unlock code sequence, but as previously noted, most of these devices are 128KB and larger, so there's no easy way to send an unlock code with a sub 64KB addressable space.

The Microchip/SST 39SF series 'flash' ROMs ignore the upper address bits in command sequences so ROM in a contiguous ~32K block in address space should work. Example Arduino code excerpt below from my current SBC project could use command sequence addresses $2AAA or $AAAA and $5555 or $D555 since ROM, when enabled by the Arduino, resides in those spaces.

Code:
  /******************************************************************************
   *  program 64K RAM image onto 64K 'A' or 'B' half of the 128K Flash ROM      *
   *                                                                            */
   void flash()                       // ****************************************
   { addr = 0x0000; x15(0);           // start address $0000, ROM A15 = 0       *
     uReset();                        // reset 6502 (synchronize uC to cpu)     *
     do                               //                                        *
     { if((addr & 0x0FFF) == 0)       // if 4K sector boundary                  *
       { wrROM(0x5555,0xAA);          // erase sector sequence                  *
         wrROM(0x2AAA,0x55);          //  "                                     *
         wrROM(0x5555,0x80);          //  "                                     *
         wrROM(0x5555,0xAA);          //  "                                     *
         wrROM(0x2AAA,0x55);          //  "                                     *
         wrROM(addr,0x30);            //  "                                     *
         _delay_ms(25);               // required delay                         *
         putSer('.');                 // indicate progress                      *
       }                              //                                        *
       wrROM(0x5555,0xAA);            // write byte 'unlock' sequence           *
       wrROM(0x2AAA,0x55);            //  "                                     *
       wrROM(0x5555,0xA0);            //  "                                     *
       wrROM(addr,rdMEM(ram));        // write byte                             *
       _delay_us(20);                 // required write delay                   *
       if(++addr == 0x6000)           // if I/O area ($6000..$7FFF)             *
       { addr = 0x8000; x15(1);       //   skip, ROM A15 = 1 ($8000..$FFFF)     *
       }                              //                                        *
     } while(addr);                   // until roll-over to 0 (full 64K image)  *
   }                                  // ****************************************


Attachments:
SBC6502 Fully Populated.png
SBC6502 Fully Populated.png [ 1.76 MiB | Viewed 1043 times ]
Beater 08.png
Beater 08.png [ 564.39 KiB | Viewed 1043 times ]


Last edited by Michael on Sun Jan 22, 2023 12:34 pm, edited 2 times in total.
Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sun Jan 22, 2023 11:53 am 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 589
Location: Michigan, USA
BigEd wrote:
There is something to watch out for though: if you have a write-locked Flash ROM and you happen to send a write to it, it will go through some internal sequence of states which will cause reads not to work for some short time. Accidental writes will break reads, and this will appear as an obscure bug in your design. So, the write-locking prevents writes, but there still might be benefit in implementing a write-protect.

Which Flash ROMs do that, please, BigEd?


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sun Jan 22, 2023 12:01 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Not 100% sure, but I find a reference to this post...
https://stardot.org.uk/forums/viewtopic ... 67#p146267

Edit: I think it might be the Atmel AT28C256 family... is that maybe not described as Flash but as EEPROM??


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sun Jan 22, 2023 2:31 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Way back when (~10 years ago) I wrote some code into my Monitor that will write into the AT28C256 EEPROM. The code is quite simple... using a toggle bit, which also requires that the code writing to the EEPROM is NOT within the EEPROM. This is basically what Ed is referring to. The earlier version of my Monitor could accidentally write to the EEPROM address space... and yes, the internal operations resulted in the monitor code kinda crashing, resulting in a BRK trap being executed. Later versions (of my Monitor) check for the address range and will not attempt to simply write into the EEPROM space.

The AT28BV256 is basically the same, however... if you don't send the unlock sequence first, the write routine (using toggle bit) will appear to work correctly without any errors, but the contents of the EEPROM will not be updated.

As Mike has been using the SST39 series, it appears to have the same unlock sequence as the AT28BV256. I do have some of the SST39 series flash ROMs but haven't put one in circuit yet. Based on the address range for the unlock sequence, you can get the ROM addressable window down to 24KB. According to the datasheet for the SST39 series, you can do a byte-by-byte write sequence, but you first need to perform a sector erase, which is based on a 4KB block. Again, I've not put one of these into circuit yet, but perhaps Mike can confirm this is the case.

In the end, I think armed with some knowledge on the devices you're using, you can get around all of these issues with a combination of hardware design and software to support the hardware as needed. Also, here's the routine I use to program the AT28BV256 EEPROM insitu. The code is kept in EEPROM and copied to page zero for execution:

Code:
;Byte write code for EEPROM.
; Note: AT28BV256 requires an unlock sequence for all write operations.
;  This is different from earlier Atmel EEPROMs (i.e., AT28C256). The
;  sequence must be sent first to unlock the device, then data can be
;  sent for programming. Note that byte writes can be 1 to 64 bytes.
;  The EEPROM is defined in constants for the Offset of the EEPROM in
;  the hardware memory map.
;
BYTE_WRS        SEI                     ;Disable interrupts
;
                LDA     #$AA            ;Get code $AA
                STA     EEPROM+$5555    ;Send to EEPROM
                LDA     #$55            ;Get code $55
                STA     EEPROM+$2AAA    ;Send to EEPROM
                LDA     #$A0            ;Get code $A0
                STA     EEPROM+$5555    ;Send to EEPROM
;
                LDA     (SRCL)          ;Get source byte
                STA     (TGTL)          ;Write to target byte
                LDA     (TGTL)          ;Read target byte (EEPROM)
                AND     #%01000000      ;Mask off bit 6 - toggle bit
BYTE_WLP        STA     TEMP3           ;Store in Temp location
                LDA     (TGTL)          ;Read target byte again (EEPROM)
                AND     #%01000000      ;Mask off bit 6 - toggle bit
                CMP     TEMP3           ;Compare to last read (toggles if write mode)
                BNE     BYTE_WLP        ;Branch back if not done
                CLI                     ;Re-enable interrupts
BYTE_WRE        RTS                     ;Return to caller
;


Note that the same code excluding the unlock sequence works with the AT28C256.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
 Post subject: Re: Don't write to ROM
PostPosted: Sun Jan 22, 2023 4:17 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
BigEd wrote:
Not 100% sure, but I find a reference to this post...
https://stardot.org.uk/forums/viewtopic ... 67#p146267

Edit: I think it might be the Atmel AT28C256 family... is that maybe not described as Flash but as EEPROM??


Yikes. I'm using that exact EEPROM just now. I'll have to take a closer look at that thread!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 43 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: