Can write EPROM at specific addresses instead of entirely?

[Aloha6502]

Folks, you might know I am struggling with the W65C02SXB from WDC.

Yesterday I yet again tried all manner of connections with it, using WDC's tools, even trying to go back to the earlier TIDE program (as opposed to newer WDC Tools) and trying Windows XP (because the WDC tools are so old, I was wondering if they work better with older Windows versions).

For XP, the FTDI drivers won't install, and I had to go to the FTDI website to see if they had any XP drivers. They did, without support, but even installing those didn't work, because the WDC TIDE software didn't.

ANYWAYS now I am just going to forget trying to connect to the SXB board via a computer. The only connection I can do now is with the Java monitor but it's very limited.

So I will just directly program and flash the EPROM.

The ROM is a SST39SF010A (128K x CMOS Multi-Purpose Flash.

https://www.microchip.com/en-us/product/SST39SF010A

Since the SXB board uses it in 4 banks (which I am at this time still struggling to access viewtopic.php?f=12&t=7175) I want to overwrite the bank that is activated at RESET.

However I am not sure how I do that.

If I write and assemble a program, can I tell my EPROM programmer to only overwrite a specific portion of the Flash ROM? Instead of the entire thing?

I have read and saved the Flash ROM's original data, so I suppose I can restore it entirely if all else fails.

I am using the TL866 II Plus programmer, and I can use either its official "XgproV" Windows software, or the Linux/Mac open source program called minipro. I checked the MAN pages for minipro and there didn't seem to be anything about partial writes. So I don't know if this concept is even possible or we have to write EPROMs entirely.

Also, are there any specific directives or macros or commands I need to write in the Assembly listing?

Thanks!

[GARTHWILSON]

Each line in the hex file you give the programmer will have the address that that line starts at. The length of the line is variable too, so a line could write as little as a single byte. (I have a page on how Intel Hex files work, at http://wilsonminesco.com/16bitMathTables/IntelHex.html, but I don't cover other popular types there like Motorola S-Record.) The programmer will probably want to do the whole EPROM; but you could fill the image with $FF's ($FF being the unprogrammed state), and the software should tell you the device is not erased, and ask you if you want to go ahead and patch anyway. I've done this many times with my old Needham's programmer.

[Aloha6502]

GARTHWILSON wrote:

Each line in the hex file you give the programmer will have the address that that line starts at. The length of the line is variable too, so a line could write as little as a single byte. (I have a page on how Intel Hex files work, at http://wilsonminesco.com/16bitMathTables/IntelHex.html, but I don't cover other popular types there like Motorola S-Record.) The programmer will probably want to do the whole EPROM; but you could fill the image with $FF's ($FF being the unprogrammed state), and the software should tell you the device is not erased, and ask you if you want to go ahead and patch anyway. I've done this many times with my old Needham's programmer.

Thanks Garth.

Do all such file formats indicate address per line?

Or is there a raw format of just one huge contiguous hex dump? I am wondering if the one I read from the ROM is such a file.

By the way, is it possible for me to tell the assembler to start at addresses BEYOND the 16-bit maximum of the 65xx family? Or do some assemblers do this and others don't? Or do they all not do it?

e.g., .ORG $18000

which is what the ROM seems to want to have, as the mapped $8000 in my case of the SXB board.

And if not, then how can I do it, to achieve the same result on the final object binary to load into the ROM?

[GARTHWILSON]

There are many formats, and you can convert between them at http://srecord.sourceforge.net/ . I'm sure there's a raw format with no overhead, only strict binary data, but it might more easily let an error get by, or make it more difficult to do certain things like sets, splits, offsets, whatever. Intel Hex and Motorola S-Record have the address for each line, but also checksums so errors are unlikely to go undetected.

Quote:

By the way, is it possible for me to tell the assembler to start at addresses BEYOND the 16-bit maximum of the 65xx family? Or do some assemblers do this and others don't? Or do they all not do it?

There are so many assemblers out there and probably nobody will be familiar with very many of them; but I suspect most 6502 assemblers would take only the low 16 bits of address. What would it do with higher ones? There might be assemblers that will help with banking. I use the Cross-32 assembler that also gives you the information to adapt it to a processor of your own design; so you might be able to adapt it to support your own banking method. I suppose you could use a 65816 assembler for the '02 and just not use the 816's additional instructions and addressing modes. What do you have in mind?

[Aloha6502]

GARTHWILSON wrote:

There are so many assemblers out there and probably nobody will be familiar with very many of them; but I suspect most 6502 assemblers would take only the low 16 bits of address. What would it do with higher ones? There might be assemblers that will help with banking. I use the Cross-32 assembler that also gives you the information to adapt it to a processor of your own design; so you might be able to adapt it to support your own banking method. I suppose you could use a 65816 assembler for the '02 and just not use the 816's additional instructions and addressing modes. What do you have in mind?

It's just for creating a binary file for writing to the Flash ROM here on the SXB, which is banked.

viewtopic.php?f=12&t=7168

(I am Googling around to find out how to pad binary files with $FF and there are numerous methods, none of which seem appropriate in this case. Many use the Linux dd command to pad extra $00 to a file so it reaches a certain size).