Programming banked EEPROM slots - how do I make the offset?

[steveukman]

I am having an awesome time rekindling the electronics fun of my youth.  I really appreciate the work of the team, especially Spencer and Steve.  

I need to place some code (assume it already produces appropriate Intel Hex files) into 'spare ROM slots' for the paged RAM/ROM.  I am using the TL866 programmer.

Programming the '0' address slot is straight forward.

How do I load a Hex file into a higher 16K block of the EEPROM so that when I page this slot in to the appropriate page in memory it works?

My struggles are:

1. Programming a Hex file into a different EEPROM location and

2. Not overwriting any of the existing 'pages' that have the monitor, BASIC, etc. in place.

The TL866 manual does not provide any insights.  Before I roll up my sleeves and try to modify the addresses in the Hex file or create a 'carrier card' that makes the EEPROM emulate a smaller device, I was wondering how you folks achieve the feat of loading multiple sets of systems?  I am hoping that there is an easy fix that I have missed.

BTW ... My project is to connect an Altair Clone front panel (AltairClone C model) to the RC2014 bus.  I want to be able to control the RC2014 from the front panel from boot.  Hence a need for RAM at 0x0000, no boot ROM controlled paging (or any other configuration), but the need to page in a monitor for debugging later (or to have other ROM code such as the "Kill the bit").  The bus monitor seems to work fine (plenty of flashing lights).  I am starting to tinker with the /WAIT and OP-Code injection to perform some of the front panel management.  The monitor has been awesome.  

I can't believe how frustrating a 'simple' program working code into a spare EEPROM slot is.

All insights appreciated.

Steve RJ

[Duncan Munro]

Hi Steve,

On Wed, 10 Mar 2021 at 15:12, steveukman <steve...@gmail.com> wrote:

How do I load a Hex file into a higher 16K block of the EEPROM so that when I page this slot in to the appropriate page in memory it works?

My struggles are:

1. Programming a Hex file into a different EEPROM location and

2. Not overwriting any of the existing 'pages' that have the monitor, BASIC, etc. in place.

I haven't tried this in practice but faced with exactly the same problem I did have a quick look at it a few weeks ago. The key to it looks to be the file load command which has an option to load into a different address (addresses question 1. above)

I've managed to load an Intel Hex file into a non-zero location using the load command, although you need to read the existing PROM data into the programmer memory first before doing this (addresses 2. above). Notice the Clear Buffer option is set to disable.

So for example if you have a 24886009 PROM, the sixth and seventh banks of 8K are uncommitted. You could read the PROM, then load an Intel Hex file to slot at A000 or C000 and then burn the whole lot back to the PROM.

As I say, I did ponder this but didn't end up programming it to the OTP PROM that came with the RC2014. I took the lazy option of buying some Winbond W27C512-45Z which are a similar device but can be erased electrically, the TL866 works fine with them so I never ended up following through on the idea above.

Regards,

Duncan

[steveukman]

Thanks, Duncan.  That is really useful guidance.  I have not considered the "Read Device, Add Hex files (offset) to buffer, Write Device" workflow.  

Much Appreciated.

Steve 

[steveukman]

.... I am assuming that Hex files will work in the same way.  That should be reasonably simple to validate with a test file.

Thanks again

[Phillip Stevens]

Steve wrote:

.... I am assuming that Hex files will work in the same way.  That should be reasonably simple to validate with a test file.

Yes. Works identically.

And, you can write the resulting buffer back to a HEX file if you want too.

That's the way that I update my banked EEPROMs.

By storing the aggregate release. Then uploading it when necessary to do a revision, reading in the revised bank, then storing the aggregate again.

I find that method much faster and "thick thumb" proof than building the (up to 8) individual pieces every time.

Phillip