Does the download of program data set anything in the CPU?
Does the download of program data set anything in the CPU?
This question really pertains to moving from BasicX to ZX system. I noticed (by trial and error) that on the old BX line of chips, the download of a user program (to the eeprom) also updated something in the CPU (i.e. they were "paired" after the download - you had to move both to a new board in order for the code to work). What I'd like to do is be able to transport just the eeprom to a new board - is that possible with the ZX cpus? I know they have to match (in terms of ZX40 and ZX40a code is not compatible), but if they are the same CPU, will this work?
Re: Does the download of program data set anything in the CP
Section 6.3 in my series of articles (see part 6) on the internals of BasicX show the contents of the CPU EEPROM. This is probably why you found you needed to move both the SPI EEPROM and the CPU.drapal wrote:This question really pertains to moving from BasicX to ZX system. I noticed (by trial and error) that on the old BX line of chips, the download of a user program (to the eeprom) also updated something in the CPU (i.e. they were "paired" after the download - you had to move both to a new board in order for the code to work).
I don't think this is going to be possible because the ZX40/ZX40a need a faster EEPROM (AT25256A) than the BX-35. In any case what are you trying to do - reuse parts?drapal wrote:What I'd like to do is be able to transport just the eeprom to a new board - is that possible with the ZX cpus? I know they have to match (in terms of ZX40 and ZX40a code is not compatible), but if they are the same CPU, will this work?
Mike Perks
Re: Does the download of program data set anything in the CP
On each download, a flag is set in Persistent Memory that indicates that code was just downloaded. You can query the state of this flag using the FirstTime() function. Calling it resets the flag.
Also, two 16-bit values are set in Persistent Memory that indicate the size and the CRC value of the downloaded code. These stored values are not used for anything in the VM but they are returned by the device when its identity is requested.
One other aspect to be aware of is that the EEPROM configuration data is stored in Persistent Memory. The ZX devices are configured during manufacturing for the AT25256A EEPROM. If that is what you are using then it won't be a problem. Otherwise, you'll have to configure each ZX for the EEPROM type you're using. If this is necessary, you may want to use the zload.exe utility in your manufacturing operation.
Also, two 16-bit values are set in Persistent Memory that indicate the size and the CRC value of the downloaded code. These stored values are not used for anything in the VM but they are returned by the device when its identity is requested.
It sounds as if you want to program the EEPROMs on one board and then install the programmed EEPROM on another - essentially a manufacturing environment. This should work as long as the parts match and that your code does not rely on the FirstTime() function.drapal wrote:What I'd like to do is be able to transport just the eeprom to a new board - is that possible with the ZX cpus?
One other aspect to be aware of is that the EEPROM configuration data is stored in Persistent Memory. The ZX devices are configured during manufacturing for the AT25256A EEPROM. If that is what you are using then it won't be a problem. Otherwise, you'll have to configure each ZX for the EEPROM type you're using. If this is necessary, you may want to use the zload.exe utility in your manufacturing operation.
- Don Kinzer
Thanks for the help...
Yes, actually this is a "manufacturing process" - I wanted to use the BX Development board to program the EEPROM, and transport just that to the working system. Since the code I use currently uses FirstTime(), this doesn't seem possible.
The other part of the initial question had to do with not being able to get the downloader to work on the manufactured board. I built 3 different incarnations of the download circuit before I had the epiphany that I was missing the diode isolation from your reset circuit drawing - Once I inserted that, they all 3 worked.
So, given all of the help here, I'll equip my laptop to be able to download the board in place.
BTW, I did check my EEPROM parts, and so far none of them are "A" parts. They seem to work fine.
The other part of the initial question had to do with not being able to get the downloader to work on the manufactured board. I built 3 different incarnations of the download circuit before I had the epiphany that I was missing the diode isolation from your reset circuit drawing - Once I inserted that, they all 3 worked.
So, given all of the help here, I'll equip my laptop to be able to download the board in place.
BTW, I did check my EEPROM parts, and so far none of them are "A" parts. They seem to work fine.
Re: Thanks for the help...
The parts that we ship have the FirstTime flag set so as long as you haven't run code that calls FirstTime(), it will still be set and should work with an EEPROM programmed on a different system.drapal wrote:Since the code I use currently uses FirstTime(), this doesn't seem possible.
If necessary, you can assert the FirstTime flag by downloading a simple program like the one below that doesn't call FirstTime().
Code: Select all
Sub Main()
End Sub
This is not an unusual result but it is also no guarantee that all non-A parts will perform likewise. There also is the issue of performance changes over the range of operating temperatures. While it may work flawlessly at room temperature, it may not work when the chip warms up to 50*C.drapal wrote:I did check my EEPROM parts, and so far none of them are "A" parts. They seem to work fine.
Early in the development cycle for the ZX-40 one of the Beta testers had a bout of exasperating problems where one day a program could be downloaded successfully and then later the download would fail only to work correctly the next day. After much hair pulling it was discovered that he was using a non-A EEPROM. Replacing it with an A part completely eliminated the difficulty.
The maximum SCK speed specification for the non-A part is 3MHz when running at 4.5 to 5.5V. On a ZX, the SCK speed is 7.37MHz - that's why the A part, with a maximum speed of 10MHz, is recommended.
- Don Kinzer