Looking at the 256KB AT24CM02 EEPROM, it appears to support sequential reads up to the maximum 256KB limit, then rolls back over to location $0. Page writes are limited to 256 bytes each.
Seeing that each 64kB requires a different device address I would have expected that the rollover would be contained to 64kB, so I am surprised that it is a bit more practical in this regard.
If you can't wait, I have zipped up the contents of my current P1 target directory and attached it. I have left out the "CUSTOM" files so as not to overwrite yours, but please make a backup copy of all your files just in case ... and be aware that you USE THIS AT YOUR OWN RISK!!!
An indicator could be how fast you saw the various MenuTest screens updating when you were running XEPROM. If the GPS Command Screen was updating pretty quickly then there's a chance the EEPROM approach might work. If it was moving at a snail's pace, then Flash wins.
So what was your feel for the Menu display speed? Fast, slow, molasses?
That there could give me a clue as to whether or not the EEPROM API approach should even be pursued...
The 512KB SRAMs I use consist of two, 256KB SRAMs on the same die. I believe they will support sequential access up to the 256KB limit, in which case you must terminate the process and restart since you can't cross the die boundary.
Looking at the 256KB AT24CM02 EEPROM, it appears to support sequential reads up to the maximum 256KB limit, then rolls back over to location $0. Page writes are limited to 256 bytes each.
The EEPROM page size is separate to the cache page size. The default EEPROM page size Catalina uses is 32 bytes, and it must be a divisor of 512, so it can never cross the EEPROM size boundary. I think this means that 2 sequential EEPROMs will work ok, whether they are in the same chip or in different chips.
If you can't wait, I have zipped up the contents of my current P1 target directory and attached it. I have left out the "CUSTOM" files so as not to overwrite yours, but please make a backup copy of all your files just in case ... and be aware that you USE THIS AT YOUR OWN RISK!!!
Understood.
Do I need to do anything with build_utilities in order to try this? Like saying it has Flash memory and setting the cache size?
An indicator could be how fast you saw the various MenuTest screens updating when you were running XEPROM. If the GPS Command Screen was updating pretty quickly then there's a chance the EEPROM approach might work. If it was moving at a snail's pace, then Flash wins.
So what was your feel for the Menu display speed? Fast, slow, molasses?
That there could give me a clue as to whether or not the EEPROM API approach should even be pursued...
I wasn't really paying attention to the speed. I think it was usable at 4K or 8K cache sizes, but I wouldn't have called it fast. But some of that is just down to the serial I/O speed, not the execution speed.
Do I need to do anything with build_utilities in order to try this? Like saying it has Flash memory and setting the cache size?
No, I don't think so. Just compile with -C XEPROM -C SMALL -C CACHED_4K and then use the EEPROM loader in payload. For example, here are the commands I used:
Cluso99 already has tiny P8XBlade2 modules and could supply them with 256kB I'm sure but I have a ton of various modules I have designed such as the P8 which also has Flash. What are your requirements in terms of size, power, I/O etc?
Essentially, something like the FLiP module, but with 256KB EEPROM, would be the minimum.
If it also had on-board SRAM and/or Flash, that would be even better. That would give me the option of running XMM code directly from EEPROM, or from SRAM and/or Flash if desired.
At this point I don't need a micro-SD Card, but I wouldn't mind if one was included.
What types of P1 modules have you designed? Tell me more, please.
My P8XBlade2 is linked in my signature.
If you want a different eeprom fitted i can do that provided it is the same footprint and you can send me the eeprom. I use TSSOP8 4.4x3@0.65 CAT24C512YI-GT3. I use a stencil and oven to assemble and it’s not hand soldering friendly! It has a handful of 0402 parts too.
I'm finding XEPROM fascinating. Since my EEPROM supports Fast Mode Plus (1MHz) I've been able to speed it up somewhat by adjusting the delay in the API, as well as tweaking some of the Menu display stuff in my code. I'm using the 8K cache. The Menu display speed is slow but usable. If I found an EEPROM that supported high speed mode (3.4MHz) the performance would likely be even better. I've found some FRAM ones that support that speed, but at $20 each that's pretty steep. I may ultimately still have to use external Flash to get where I need to go, but I'm going to continue experimenting with XEPROM to see what can be done. I'm captivated by it.
Anyway, that's not what this post is about. I'm working on something else that uses your standard Serial plugins (PC, PropTerminal, TTY, or TTY-VT100).
I'm facing the age-old problem of needing to scan the keyboard for input, but not wait for a carriage return.
Essentially I need something like the kbhit() or getkey() function, but there doesn't appear to be one available. Is it there but I'm missing it?
The EEPROM page size is separate to the cache page size. The default EEPROM page size Catalina uses is 32 bytes, and it must be a divisor of 512, so it can never cross the EEPROM size boundary. I think this means that 2 sequential EEPROMs will work ok, whether they are in the same chip or in different chips.
Of course, I have never actually tried it.
I now have two 256KB EEPROMs on the same I2C bus on my USB Project Board.
One is physically mapped from $0000_0000 to $0003_FFFF while the other is mapped from $0004_0000 to $0007_FFFF.
Whatever reading/writing scheme Tachyon uses apparently worked fine.
I loaded Tachyon into HubRam, then issued this command:
Don't know what the story is with these Zeros, but Tachyon apparently had no problem transitioning from one EEPROM to the other across the 256KB boundary, so I think your suspicions might be correct:
The default EEPROM page size Catalina uses is 32 bytes, and it must be a divisor of 512, so it can never cross the EEPROM size boundary. I think this means that 2 sequential EEPROMs will work ok, whether they are in the same chip or in different chips.
Where in this case, we have two separate chips that are sequentially mapped on the same bus.
So I guess the next question deals with the caching page sizes, and would they attempt to cross the 256KB boundary, in which case they would fail.
Obviously, if there were such a critter as a 512KB EEPROM that consists of a single die allowing sequential access across the entire memory range, then neither your EEPROM page sizes nor the actual XEPROM memory caching scheme would encounter any problem.
Haven't seen such a critter on the market, though...
I've got another crazy question, something that is totally hypothetical, but I would appreciate your thoughts on it nevertheless.
If I understand it correctly, CMM is a type of hybrid between pure LMM code and a series of tokens, resulting in code which is much more compact than LMM code but also slower to execute.
In contrast, the XMM kernel is similar to the LMM kernel but with the added overhead of fetching LMM code from external memory instead of HubRam?
Would it be possible to have a hybrid XMM kernel that fetches tokenized code from external memory, similar to how CMM does it from HubRam?
I realize there would likely be another speed penalty, as the tokens were fetched from external memory, decoded, then executed, but perhaps this could be partially offset by having smaller code that would require fewer memory fetches?
Just wondering about this and curious as to your thoughts on such a thing.
Just wondering about this and curious as to your thoughts on such a thing.
Your understanding is correct. However, your suggestion is not practical - at least not on the P1. There is simply not enough space in a single cog to do it all. The CMM kernel only barely fits in a cog as it is - I even had to move some of the very basic floating point support routines out to another cog make it fit (which I hated to do!).
However, I have been giving some thought to how XMM might work on the P2, where 2 cogs can closely co-operate and even share RAM. I think having a combined 2-cog "kernel and cache" might mean XMM would work very well on the P2, but perhaps a 2 cog kernel could also combine CMM and XMM functionality.
I like your way of thinking. I also think that this would be a major thing to figure out. How to build a two COG object working in tandem fashion. The basics seem to be there, gosh I wish I had more time for the P2.
For some reason I'm still having problems getting the 8K cache option working in Catalina when using my external SRAMs.
Please check your email for the test files used, including the CUSTOM_XMM memory driver.
Program storage is achieved using the EEPROM option, but for ongoing testing and debugging, I'm just dumping the code directly to XMM RAM after compilation via the Code::Blocks Menus.
I'm using a variant of the "RamPage2" external memory arrangement for this test, but without any Flash memory. The two SRAMs are running in Quad Mode. Each SRAM is connected to a 4-bit bus, yielding 8-bits total. So after the addressing information is strobed in for a read/write operation, 8 data bits are transferred upon each clock pulse.
Transferring large blocks of data causes the amortization of the initial read/write command overhead thus resulting in decent transfer speed. Short of using HyperRam, I'm guessing this is the most efficient external memory arrangement to quickly transfer 8-bit blocks of data using the fewest number of pins (10 total: 8 data, plus CS and CLK).
Anyway, Catalina works fine (as does RamTest) using the 1K, 2K, and 4K cache options.
RamTest also works fine with 8K cache.
I just can't get Catalina to work with the 8K cache, regardless of what I try.
This 8K cache problem persists if I compile the program for SMALL or LARGE memory models. No difference, the program just won't run. I get a blank screen.
Originally I thought the issue might be too much HubRam consumed. Here's what compiling using SMALL shows:
In each case I'm seeing the DATA portion being 3512 bytes. Does this exceed the amount of HubRam that can be used?
If it's not a HubRam memory overrun, any idea what's going on here?
Whatever is happening, it only manifests when using the 8K cache option...
This "Rampage2" XMM memory arrangement works perfectly in cache mode provided that the caching cog always transfers an even number of bytes. If it doesn't, the whole scheme breaks down, and that right there would cause the program not to run.
However, I'm assuming that an even number of bytes is always transferred to/from the cache irrespective of the cache size used (1K, 2K, 4K, or 8K).
I'm just perplexed that I can't get the program to run using 8K cache.
For some reason I'm still having problems getting the 8K cache option working in Catalina when using my external SRAMs.
Please check your email for the test files used, including the CUSTOM_XMM memory driver.
Or, we can cut through the clutter and take a look at the CUSTOM_XMM driver right now, since I assume that's where the problem resides. I've included it here for anyone who wants to take a look.
I don't see why it works perfectly for cache sizes of 1K, 2K, and 4K, but mysteriously doesn't work for 8K, at least not with Catalina, but yet it does work fine with RamTest.
Why it doesn't work with one, but does with the other, is what has really thrown me...
I've also sent you an email on this. But here is the gist:
It is probably not your driver, or the program size.
I found and fixed a problem with Catalina's caching. It was a bug I introduced way back in Catalina 3.12 - I never spotted it because it only affects certain programs with certain cache sizes - your program with an 8K cache just happened to be one such combination!
I have attached a new version of Cached_XMM.inc, which you should put in Catalina's "target" directory. Then recompile your program (and the utilities) to use an 8K cache.
I've also sent you an email on this. But here is the gist:
It is probably not your driver, or the program size.
I found and fixed a problem with Catalina's caching. It was a bug I introduced way back in Catalina 3.12 - I never spotted it because it only affects certain programs with certain cache sizes - your program with an 8K cache just happened to be one such combination!
I have attached a new version of Cached_XMM.inc, which you should put in Catalina's "target" directory. Then recompile your program (and the utilities) to use an 8K cache.
Let me know if it works.
Ross.
Yes sir, it works like a charm!
As an added bonus, there also appears to be a noticeable increase in execution speed due to the additional caching.
I have a question about how Tachyon writes to and reads from EEPROM.
But first, let me describe what I'm doing here.
For my Project I want to use a FLiP module instead of a USB Project Board. However, the FLiP doesn't have sufficient memory, so I designed a small mezzanine/carrier board that the FLiP plugs in to, which in turn plugs into a 40-pin socket on my main board.
Here's what it looks like:
Side by side with the FLiP:
FLiP plugged in to the carrier board:
The mezzanine board contains 3 EEPROMs (the top 3 chips) and 2 SPI SRAMs (the lower 2 chips). This arrangement brings FLiP addressable EEPROM memory up to 512KB, while the SPI SRAMs (256KB total) serve as XMM memory in which my program will run.
I only had some oversized Arduino Headers on hand, so I had to use them instead of some preferred low profile ones. It's also not the cleanest job since I used a soldering iron to install all components.
When (if?) @RossH returns to the forums in a few months (assuming his Retreat survived the fires and customers have returned), he might be interested to know that the 256KB SRAMs work perfectly using the Catalina RamTest program and 8K of cache.
Unfortunately, the Catalina EEPROM Loader gave me an error when I attempted to save an XMM program in EEPROM:
It's almost like the Loader is trying to write across the EEPROM physical boundary which obviously won't work.
So, I loaded up Tachyon and took advantage of its excellent diagnostic capability. I had it fill the entire 512KB EEPROM memory with different characters (with the last tested value of $5A shown here), and it worked perfectly.
The EEPROM page size is separate to the cache page size. The default EEPROM page size Catalina uses is 32 bytes, and it must be a divisor of 512, so it can never cross the EEPROM size boundary. I think this means that 2 sequential EEPROMs will work ok, whether they are in the same chip or in different chips.
Of course, I have never actually tried it.
If I'm reading this post correctly he's using 32-byte writes/reads but for some reason the Catalina EEPROM Loader isn't working correctly and outputs the previously mentioned error. If I can find the default settings for this loader maybe I can try different values and see if I can find something that works.
So my question to you is what size write/read blocks does Tachyon use, because whatever it's using works, and whatever the Catalina EEPROM loader uses, doesn't.
Tachyon will fill and copy to EEPROM in a page size to suit the device which is typically 128 bytes for 64KB chips. Each time it performs a write it calculates the device address so it will cross device boundaries seamlessly. So each page write is:
<START> <DEVICE ADDR> <WRITE> <16-bit MEMORY ADDRESS> <128 BYTES> <STOP>
Because the device may be busy programming a page of data, the device address is polled for an ack to indicate when it is ready along with a timeout to prevent hanging.
I use the LY68L6400, an 8MB SPI RAM as an option on the P2. It's cheap!
Thanks for the heads up on the LY68L6400 SPI SRAMs. I couldn't find a US distributor for them yet, but I did find them on Aliexpress. A batch of 10 goes for about $17.50.
How are they working out for you? Any troubles with them? I've had no problems with the ISSI 512KB SPI SRAMS so far...
I want to dig a little deeper on how Tachyon does EEPROM writes/reads as well as the techniques you employ to get past the EEPROM physical barriers in a ganged EEPROM arrangement.
Since I'm using a potpourri of EEPROMs (64KB on board the FLiP, and 64KB, 128KB, and 256KB on my expansion board), Tachyon has no a priori knowledge of how many EEPROMs it's working with, nor the memory size of each one. Yet your algorithm effectively determines this and adjusts accordingly to seamlessly write/read across EEPROM physical boundaries.
I've written code to write to a GPS receiver on an I2C bus, but not EEPROMs. There's no such thing as Page reads/writes in this case, as I just send a string of characters to the GPS receiver and look for ACK/NACK responses to verify reception of the string.
If you're using EEPROMs <= 64KB in size, the entire A15->A0 physical address is contained within the Memory Address bytes, with the Device Address byte containing device select fields A2, A1, A0 (allowing a total of 8 of these sized devices on the I2C bus).
However, if you're using a 128KB EEPROM, then device select field A0 is replaced with physical address A16 (thus restricting you to a total of 4 of these devices on the bus).
Finally, if you're using a 256KB EEPROM, then device select fields A1 and A0 are replaced with physical addresses A17 and A16, respectively, which limits you to a maximum of 2 such devices on the bus.
OK, with that out of the way, and since you're using a 128-byte Page Write scheme for the EEPROMs, I'm going to make the following assumptions and you can tell me if I'm on the right track or not:
1. Tachyon will send this packet to the EEPROM as you described:
<START> <DEVICE ADDR> <WRITE> <16-bit MEMORY ADDRESS> <128 BYTES> <STOP>
2. If the bytes you attempt to write fit within its physical boundary, the EEPROM will respond with ACKs for each byte you write.
3. Tachyon will then send this command to verify the write was successful:
<START> <DEVICE ADDR> <READ> <16-bit MEMORY ADDRESS> <128 BYTES> <STOP>
4. Assuming all is well, Tachyon will advance the memory address to the start of the next block of data and continue the write process until the task is complete.
5. However, if Tachyon attempts to write past its physical boundary, the EEPROM will respond with a NACK for the last byte it attempted to write.
6. If byte N failed, then Tachyon will downward adjust the number of bytes to send to 128 - (128 - N) bytes and retry.
7. If successful, Tachyon will send the Read command to verify N bytes were written.
8. If the Read was successful, then Tachyon will advance the memory address to the start of the next block of data and attempt to write 128 bytes again.
9. But, if Step 6 fails, then Tachyon will attempt again X number of times until a timeout value is reached, in which case it will quit and provide an error message.
So, if this process is correct, then Tachyon will dynamically adjust the number of bytes it will attempt to write until it achieves success or a timeout error occurs.
This technique thus allows Tachyon to seamlessly bridge across physical boundaries of multiple EEPROMs regardless of how many physical devices are on the bus (up to 8 total), and/or their memory size.
Does this make sense, and is this similar to how you achieve the successful bridging?
Practically all modern I2C EEPROMs accept 16-bits for their address and even for 128kB and larger devices. Whereas you would expect A16 to be the b1 or the lsb of the 7-bit address, it is in fact b3 for Atmel/Microchip x1025 devices, which is rather non-standard. Tachyon doesn't perform any voodoo, it just translates A16,A17,A18 into the device address which most normal larger devices handle, well normally. I favor the M24M0x EEPROMs.
Page writes can never cross boundaries because they always start on an aligned page address. You cannot start a page on the last byte for instance. But page writes take the same amount of time as a byte write, probably because that's what they are doing internally. I found that the guaranteed "maximum" endurance cycle of 1M writes typical is in fact a very minimum figure that you can count on. I endurance tested an EEPROM once and gave up when it was still working normally after several million cycles.
If you are trying to mix 32kB (256kb) devices with larger devices then that's your problem and the solution is simple, just don't.
The SPI RAM I buy from LCSC who I can highly recommend. To me they are a bit like an Asian Mouser, albeit they are not guaranteed to have every part, but the parts they do have are at very good prices. For instance if you buy 10 of those chips they are 61 cents each. Much cheaper than Aliex.
P.S. Tachyon doesn't need "expanded memory" as it is very compact and fast and runs directly out of 32k RAM, even for very large applications which I have written. It does however use the upper 32k of a normal 64kB EEPROM to hold ROMS which are the named binary images that can be loaded at runtime into cogs such as VGA, F32, SIDcog, UARTS, etc. That way unlike the image taking up RAM space as in Spin, you can have all that functionality but not use up any RAM.
EDIT: I've just attached a capture of the console startup and a quick look around including mounting an SD and opening and examining a file.
If you are trying to mix 32kB (256kb) devices with larger devices then that's your problem and the solution is simple, just don't.
Fortunately I'm not using 32KB EEPROMs. What I did do is expand total EEPROM memory space to 512KB by using an expansion board that has 64KB, 128KB, and 256KB EEPROMs installed. But doing this allows, in fact requires, the use of the existing 64KB EEPROM on the FLiP as well.
Which means that all four EEPROMs used are mapped like this:
As we know, for EEPROMs 64KB and smaller, the Device Byte A2,A1,A0 fields are external physical inputs to essentially select up to 8 of these on the I2C bus.
For the 128KB EEPROM, Device Bit A0 has been replaced with memory location A16, while the physical pin formerly known as A0 became NC.
And for the 256KB EEPROM, Device Bit A1 has also been replaced with memory location A17, with physical pins formerly known as A1 and A0 replaced with NC.
So, looking at the above table, the EEPROMs are properly segmented and mapped into their expected ranges.
Indeed, Tachyon confirmed this by successfully writing to and reading from all EEPROM memory locations from $00000 to $7FFFF.
However, the Catalina EEPROM loader failed while trying to access memory locations from 64KB to 128KB. @RossH had mentioned the Catalina loader is quite old and was only designed to work with EEPROMs up to 128KB. It also clearly has problems working with multiple EEPROMS on the I2C bus.
Hopefully in due time, when (if?) he returns to this forum he can take a closer look.
Of course, if I disable the FLiP internal 64KB EEPROM, and use only the 256KB EEPROM on the expansion board the Catalina loader will work. That's essentially what I did with my USB Project Board and it works fine.
The caveat is that the 256KB EEPROM will have to be placed on the expansion board where the 64KB one currently is. This is certainly doable, and will allow me to proceed with my Project, but the intent was to not mutilate the FLiP but instead allow full 512KB EEPROM access by simply plugging it into the expansion board.
Until the Catalina loader is fixed (or another software workaround is found), it's time to mutilate a FLiP, remove the 64KB and 128KB EEPROMs on the expansion board, and install the 256KB EEPROM instead...
The SPI RAM I buy from LCSC who I can highly recommend. To me they are a bit like an Asian Mouser, albeit they are not guaranteed to have every part, but the parts they do have are at very good prices. For instance if you buy 10 of those chips they are 61 cents each. Much cheaper than Aliex.
Wow, I priced out 10 of these chips and I can have them delivered to the USA for $11.19, including shipping. Amazing!
Comments
Seeing that each 64kB requires a different device address I would have expected that the rollover would be contained to 64kB, so I am surprised that it is a bit more practical in this regard.
If you can't wait, I have zipped up the contents of my current P1 target directory and attached it. I have left out the "CUSTOM" files so as not to overwrite yours, but please make a backup copy of all your files just in case ... and be aware that you USE THIS AT YOUR OWN RISK!!!
So what was your feel for the Menu display speed? Fast, slow, molasses?
That there could give me a clue as to whether or not the EEPROM API approach should even be pursued...
The EEPROM page size is separate to the cache page size. The default EEPROM page size Catalina uses is 32 bytes, and it must be a divisor of 512, so it can never cross the EEPROM size boundary. I think this means that 2 sequential EEPROMs will work ok, whether they are in the same chip or in different chips.
Of course, I have never actually tried it.
Understood.
Do I need to do anything with build_utilities in order to try this? Like saying it has Flash memory and setting the cache size?
I wasn't really paying attention to the speed. I think it was usable at 4K or 8K cache sizes, but I wouldn't have called it fast. But some of that is just down to the serial I/O speed, not the execution speed.
No, I don't think so. Just compile with -C XEPROM -C SMALL -C CACHED_4K and then use the EEPROM loader in payload. For example, here are the commands I used:
It works!
For some reason it didn't like the CUSTOM platform so I changed it to QUICKSTART.
No problems with compiling or uplinking.
But, it is pretty slow, even with 8K cache.
I will continue to experiment with it and see what, if anything, I can do to speed it up...
Essentially, something like the FLiP module, but with 256KB EEPROM, would be the minimum.
If it also had on-board SRAM and/or Flash, that would be even better. That would give me the option of running XMM code directly from EEPROM, or from SRAM and/or Flash if desired.
At this point I don't need a micro-SD Card, but I wouldn't mind if one was included.
What types of P1 modules have you designed? Tell me more, please.
If you want a different eeprom fitted i can do that provided it is the same footprint and you can send me the eeprom. I use TSSOP8 4.4x3@0.65 CAT24C512YI-GT3. I use a stencil and oven to assemble and it’s not hand soldering friendly! It has a handful of 0402 parts too.
I'm finding XEPROM fascinating. Since my EEPROM supports Fast Mode Plus (1MHz) I've been able to speed it up somewhat by adjusting the delay in the API, as well as tweaking some of the Menu display stuff in my code. I'm using the 8K cache. The Menu display speed is slow but usable. If I found an EEPROM that supported high speed mode (3.4MHz) the performance would likely be even better. I've found some FRAM ones that support that speed, but at $20 each that's pretty steep. I may ultimately still have to use external Flash to get where I need to go, but I'm going to continue experimenting with XEPROM to see what can be done. I'm captivated by it.
Anyway, that's not what this post is about. I'm working on something else that uses your standard Serial plugins (PC, PropTerminal, TTY, or TTY-VT100).
I'm facing the age-old problem of needing to scan the keyboard for input, but not wait for a carriage return.
Essentially I need something like the kbhit() or getkey() function, but there doesn't appear to be one available. Is it there but I'm missing it?
I think k_ready() is what you are looking for. See "catalina_hmi.h" for all the HMI (Human/Machine Interface) functions.
One is physically mapped from $0000_0000 to $0003_FFFF while the other is mapped from $0004_0000 to $0007_FFFF.
Whatever reading/writing scheme Tachyon uses apparently worked fine.
I loaded Tachyon into HubRam, then issued this command:
$0000 $7FFFF $FF EFILL --> ok
Then This:
$0000 $7FFFF EE DUMP
And got this: All the way up to here, where I got some Zeros at the end: Don't know what the story is with these Zeros, but Tachyon apparently had no problem transitioning from one EEPROM to the other across the 256KB boundary, so I think your suspicions might be correct: Where in this case, we have two separate chips that are sequentially mapped on the same bus.
So I guess the next question deals with the caching page sizes, and would they attempt to cross the 256KB boundary, in which case they would fail.
Obviously, if there were such a critter as a 512KB EEPROM that consists of a single die allowing sequential access across the entire memory range, then neither your EEPROM page sizes nor the actual XEPROM memory caching scheme would encounter any problem.
Haven't seen such a critter on the market, though...
I've got another crazy question, something that is totally hypothetical, but I would appreciate your thoughts on it nevertheless.
If I understand it correctly, CMM is a type of hybrid between pure LMM code and a series of tokens, resulting in code which is much more compact than LMM code but also slower to execute.
In contrast, the XMM kernel is similar to the LMM kernel but with the added overhead of fetching LMM code from external memory instead of HubRam?
Would it be possible to have a hybrid XMM kernel that fetches tokenized code from external memory, similar to how CMM does it from HubRam?
I realize there would likely be another speed penalty, as the tokens were fetched from external memory, decoded, then executed, but perhaps this could be partially offset by having smaller code that would require fewer memory fetches?
Just wondering about this and curious as to your thoughts on such a thing.
Your understanding is correct. However, your suggestion is not practical - at least not on the P1. There is simply not enough space in a single cog to do it all. The CMM kernel only barely fits in a cog as it is - I even had to move some of the very basic floating point support routines out to another cog make it fit (which I hated to do!).
However, I have been giving some thought to how XMM might work on the P2, where 2 cogs can closely co-operate and even share RAM. I think having a combined 2-cog "kernel and cache" might mean XMM would work very well on the P2, but perhaps a 2 cog kernel could also combine CMM and XMM functionality.
So many possibilities, so little time ...
I like your way of thinking. I also think that this would be a major thing to figure out. How to build a two COG object working in tandem fashion. The basics seem to be there, gosh I wish I had more time for the P2.
Me too! I think "2 cog" objects are going to be a big deal on the P2.
For some reason I'm still having problems getting the 8K cache option working in Catalina when using my external SRAMs.
Please check your email for the test files used, including the CUSTOM_XMM memory driver.
Program storage is achieved using the EEPROM option, but for ongoing testing and debugging, I'm just dumping the code directly to XMM RAM after compilation via the Code::Blocks Menus.
I'm using a variant of the "RamPage2" external memory arrangement for this test, but without any Flash memory. The two SRAMs are running in Quad Mode. Each SRAM is connected to a 4-bit bus, yielding 8-bits total. So after the addressing information is strobed in for a read/write operation, 8 data bits are transferred upon each clock pulse.
Transferring large blocks of data causes the amortization of the initial read/write command overhead thus resulting in decent transfer speed. Short of using HyperRam, I'm guessing this is the most efficient external memory arrangement to quickly transfer 8-bit blocks of data using the fewest number of pins (10 total: 8 data, plus CS and CLK).
Anyway, Catalina works fine (as does RamTest) using the 1K, 2K, and 4K cache options.
RamTest also works fine with 8K cache.
I just can't get Catalina to work with the 8K cache, regardless of what I try.
This 8K cache problem persists if I compile the program for SMALL or LARGE memory models. No difference, the program just won't run. I get a blank screen.
Originally I thought the issue might be too much HubRam consumed. Here's what compiling using SMALL shows: And here's what compiling using LARGE shows:
In each case I'm seeing the DATA portion being 3512 bytes. Does this exceed the amount of HubRam that can be used?
If it's not a HubRam memory overrun, any idea what's going on here?
Whatever is happening, it only manifests when using the 8K cache option...
This "Rampage2" XMM memory arrangement works perfectly in cache mode provided that the caching cog always transfers an even number of bytes. If it doesn't, the whole scheme breaks down, and that right there would cause the program not to run.
However, I'm assuming that an even number of bytes is always transferred to/from the cache irrespective of the cache size used (1K, 2K, 4K, or 8K).
I'm just perplexed that I can't get the program to run using 8K cache.
Thoughts?
I don't see why it works perfectly for cache sizes of 1K, 2K, and 4K, but mysteriously doesn't work for 8K, at least not with Catalina, but yet it does work fine with RamTest.
Why it doesn't work with one, but does with the other, is what has really thrown me...
I've also sent you an email on this. But here is the gist:
It is probably not your driver, or the program size.
I found and fixed a problem with Catalina's caching. It was a bug I introduced way back in Catalina 3.12 - I never spotted it because it only affects certain programs with certain cache sizes - your program with an 8K cache just happened to be one such combination!
I have attached a new version of Cached_XMM.inc, which you should put in Catalina's "target" directory. Then recompile your program (and the utilities) to use an 8K cache.
Let me know if it works.
Ross.
Yes sir, it works like a charm!
As an added bonus, there also appears to be a noticeable increase in execution speed due to the additional caching.
Thanks again for your help.
I have a question about how Tachyon writes to and reads from EEPROM.
But first, let me describe what I'm doing here.
For my Project I want to use a FLiP module instead of a USB Project Board. However, the FLiP doesn't have sufficient memory, so I designed a small mezzanine/carrier board that the FLiP plugs in to, which in turn plugs into a 40-pin socket on my main board.
Here's what it looks like:
Side by side with the FLiP:
FLiP plugged in to the carrier board:
The mezzanine board contains 3 EEPROMs (the top 3 chips) and 2 SPI SRAMs (the lower 2 chips). This arrangement brings FLiP addressable EEPROM memory up to 512KB, while the SPI SRAMs (256KB total) serve as XMM memory in which my program will run.
I only had some oversized Arduino Headers on hand, so I had to use them instead of some preferred low profile ones. It's also not the cleanest job since I used a soldering iron to install all components.
Here's how the EEPROM mapping is arranged:
Memory Map: 0 -> 64KB FLiP Internal EEPROM 64Kb -> 128KB Memory Board EEPROM #1 (AT24C512C) 128KB -> 256KB Memory Board EEPROM #2 (AT24CM01) 256KB -> 512KB Memory Board EEPROM #3 (AT24CM02)When (if?) @RossH returns to the forums in a few months (assuming his Retreat survived the fires and customers have returned), he might be interested to know that the 256KB SRAMs work perfectly using the Catalina RamTest program and 8K of cache.
Unfortunately, the Catalina EEPROM Loader gave me an error when I attempted to save an XMM program in EEPROM:
It's almost like the Loader is trying to write across the EEPROM physical boundary which obviously won't work.
So, I loaded up Tachyon and took advantage of its excellent diagnostic capability. I had it fill the entire 512KB EEPROM memory with different characters (with the last tested value of $5A shown here), and it worked perfectly.
Here are some snippets to summarize what I saw:
As you can see, Tachyon was able to seamlessly write and read across EEPROM physical boundaries.
@RossH mentioned this earlier in this thread:
If I'm reading this post correctly he's using 32-byte writes/reads but for some reason the Catalina EEPROM Loader isn't working correctly and outputs the previously mentioned error. If I can find the default settings for this loader maybe I can try different values and see if I can find something that works.
So my question to you is what size write/read blocks does Tachyon use, because whatever it's using works, and whatever the Catalina EEPROM loader uses, doesn't.
Thanks.
<START> <DEVICE ADDR> <WRITE> <16-bit MEMORY ADDRESS> <128 BYTES> <STOP>
Because the device may be busy programming a page of data, the device address is polled for an ack to indicate when it is ready along with a timeout to prevent hanging.
I use the LY68L6400, an 8MB SPI RAM as an option on the P2. It's cheap!
Thanks for the heads up on the LY68L6400 SPI SRAMs. I couldn't find a US distributor for them yet, but I did find them on Aliexpress. A batch of 10 goes for about $17.50.
How are they working out for you? Any troubles with them? I've had no problems with the ISSI 512KB SPI SRAMS so far...
I want to dig a little deeper on how Tachyon does EEPROM writes/reads as well as the techniques you employ to get past the EEPROM physical barriers in a ganged EEPROM arrangement.
Since I'm using a potpourri of EEPROMs (64KB on board the FLiP, and 64KB, 128KB, and 256KB on my expansion board), Tachyon has no a priori knowledge of how many EEPROMs it's working with, nor the memory size of each one. Yet your algorithm effectively determines this and adjusts accordingly to seamlessly write/read across EEPROM physical boundaries.
I've written code to write to a GPS receiver on an I2C bus, but not EEPROMs. There's no such thing as Page reads/writes in this case, as I just send a string of characters to the GPS receiver and look for ACK/NACK responses to verify reception of the string.
If you're using EEPROMs <= 64KB in size, the entire A15->A0 physical address is contained within the Memory Address bytes, with the Device Address byte containing device select fields A2, A1, A0 (allowing a total of 8 of these sized devices on the I2C bus).
However, if you're using a 128KB EEPROM, then device select field A0 is replaced with physical address A16 (thus restricting you to a total of 4 of these devices on the bus).
Finally, if you're using a 256KB EEPROM, then device select fields A1 and A0 are replaced with physical addresses A17 and A16, respectively, which limits you to a maximum of 2 such devices on the bus.
OK, with that out of the way, and since you're using a 128-byte Page Write scheme for the EEPROMs, I'm going to make the following assumptions and you can tell me if I'm on the right track or not:
1. Tachyon will send this packet to the EEPROM as you described:
<START> <DEVICE ADDR> <WRITE> <16-bit MEMORY ADDRESS> <128 BYTES> <STOP>
2. If the bytes you attempt to write fit within its physical boundary, the EEPROM will respond with ACKs for each byte you write.
3. Tachyon will then send this command to verify the write was successful:
<START> <DEVICE ADDR> <READ> <16-bit MEMORY ADDRESS> <128 BYTES> <STOP>
4. Assuming all is well, Tachyon will advance the memory address to the start of the next block of data and continue the write process until the task is complete.
5. However, if Tachyon attempts to write past its physical boundary, the EEPROM will respond with a NACK for the last byte it attempted to write.
6. If byte N failed, then Tachyon will downward adjust the number of bytes to send to 128 - (128 - N) bytes and retry.
7. If successful, Tachyon will send the Read command to verify N bytes were written.
8. If the Read was successful, then Tachyon will advance the memory address to the start of the next block of data and attempt to write 128 bytes again.
9. But, if Step 6 fails, then Tachyon will attempt again X number of times until a timeout value is reached, in which case it will quit and provide an error message.
So, if this process is correct, then Tachyon will dynamically adjust the number of bytes it will attempt to write until it achieves success or a timeout error occurs.
This technique thus allows Tachyon to seamlessly bridge across physical boundaries of multiple EEPROMs regardless of how many physical devices are on the bus (up to 8 total), and/or their memory size.
Does this make sense, and is this similar to how you achieve the successful bridging?
Page writes can never cross boundaries because they always start on an aligned page address. You cannot start a page on the last byte for instance. But page writes take the same amount of time as a byte write, probably because that's what they are doing internally. I found that the guaranteed "maximum" endurance cycle of 1M writes typical is in fact a very minimum figure that you can count on. I endurance tested an EEPROM once and gave up when it was still working normally after several million cycles.
If you are trying to mix 32kB (256kb) devices with larger devices then that's your problem and the solution is simple, just don't.
The SPI RAM I buy from LCSC who I can highly recommend. To me they are a bit like an Asian Mouser, albeit they are not guaranteed to have every part, but the parts they do have are at very good prices. For instance if you buy 10 of those chips they are 61 cents each. Much cheaper than Aliex.
P.S. Tachyon doesn't need "expanded memory" as it is very compact and fast and runs directly out of 32k RAM, even for very large applications which I have written. It does however use the upper 32k of a normal 64kB EEPROM to hold ROMS which are the named binary images that can be loaded at runtime into cogs such as VGA, F32, SIDcog, UARTS, etc. That way unlike the image taking up RAM space as in Spin, you can have all that functionality but not use up any RAM.
EDIT: I've just attached a capture of the console startup and a quick look around including mounting an SD and opening and examining a file.
Propeller .:.:--TACHYON--:.:. Forth V5r7 NEON 570190926.2300 *** MODULES *** Propeller .:.:--TACHYON--:.:. Forth V5r7 NEON 570190926.2300 3C84: EASYFILE SDHC card + FAT32 Virtual Memory File System V1.2 171024-0000 2FFC: TOOLS DEV TOOLS 1AC0: EXTEND Primary extensions to TACHYON V5 kernel - 191226-1200 FREQ = 96.00MHZ *** INITS *** MOUNT 42CA *** ROMS *** C01C: HSUART 560 C260: UART 464 C444: VGA32x15 848 C7A8: TV 1276 CCB8: SIDCOG 1648 D33C: F32 1900 *** I2C *** $A0 EE/RTC I/O = 31 :UHUU 27 :~~~~ 23 :~~~~ 19 :~~~~ 15 :U~~U 11 :~~~~ 7 :~~~~ 3 :~~~~ INTERCOM: &05.78.32.55 @4,788 CODE:$4D76 = 19318 bytes NAME:$5A44 = 6588 bytes DATA:$7859 = 841 bytes FREE: = 3278 bytes Data Stack (0) Mon, 01 Jan 2001 00:00:00 UTC CARD: SL08G SD03.80 #8C0D.A960 2016/2 !C0FF.80AF 1,515us FAT: #6338.6430 WIDGET FAT32 7,944,011,776 bytes (32kB clusters) *** I2C *** $A0 EE/RTC I/O = 31 :UHUU 27 :~~~~ 23 :~~~~ 19 :~~~~ 15 :U~~U 11 :~~~~ 7 :~~~~ 3 :~~~~ INTERCOM: &05.78.32.55 @4,788 CODE:$4D76 = 19318 bytes NAME:$5A44 = 6588 bytes DATA:$7859 = 841 bytes FREE: = 3278 bytes Data Stack (0) Mon, 01 Jan 2001 00:00:00 UTC CARD: SL08G SD03.80 #8C0D.A960 2016/2 !C0FF.80AF 1,516us FAT: #6338.6430 WIDGET FAT32 7,944,011,776 bytes (32kB clusters) -------------------------------------------------------------------------------- ... ... WORDS --> DICTIONARY WORDS @5A44 QV FL SAVETEXT FRUN .FILES .FX .FILE lss VOLNAME! DIRW ls .LIST (SLIST) DIR .FNAME cd cd$ pwd cat (cat) FPRINT$ FL OAD FCOPY FCOPY$ RENAME RENAME$ APPEND -FERASE FMAKE$ FOPEN FOPEN$ mk RW RO FOPEN# FCREATE$ MAKE FCLOSE >FILE FILE> FPUTB FPUT FGET FREM fwrite fread FSTAMP DIR? FSIZE! UpdateDir OpenDir FILE$ ?MOUNT MOUNT ROOT FMAX@ CLUST>SECT @F AT @BOOT @ROOT FS FS@ FSW@ FSC@ FS! FSC! FSADR SD XW@ XC! XC@ X! X@ XADR FSECT@ FSIZE@ FSIZE dirbuf dirfsa @FILE FI LE# FILE SDRD SECTOR SCAN! FLUSH WRSECT SDWR !SD ACMD CMD SDPINS SDERR SDBUSY SDIO32 SDIO8 I+ CARD? sdbuf _sdpins o cr csd cid #files BLKSIZ EASYFILE DEFAULTS SAVEROM .TIMERS .TASKS .INDEX HELP W WWORDS QW .VARS ?? lsini lsroms fib os fibo .LAP ~F .FREQ .INTERCOM .MODULES NEON lsi2c lsio FSQRT FSIN F/ F* F- F+ F> >F FCMD LOADCOGS LOADCOG SERVO! DEGREES RUNSERVOS PWM! PWM PWM% PWM% PWM.START RGBS RGB ALED RGBPIN IRRX IRTX .DHT DHT DISTANCE PING TOOLS BOOT DEF ER ID! INTERCOM! +POLL ?POLL TIMERJOB !RTC .TEMP 'F 'C STAMP@ .DT TZ tz$ .ASMONTH .DATE .TIME .DAY DAY DAY@ SUN SAT FRI THU WED TUE MON DATE! SDT! DT! TIME! DATE@ HMS MS>TIME TIME@ DEC>BCD BCD>DEC RTC RTC@ RTC! SETRTC date time ru ntime WATCHDOG ALARM: TIMEOUT? ALARM COUNTUP TIMEOUT timers TIMER IO! IO@ CONBAUD BACKUP ?BACKUP EE ECOPY EFILL ELO AD ESAVE ESAVEB ep I2CPINS EEPROM E! E@ EW@ EW! EC@ EC! EERD @EEWAIT @EE eeflg eedev I2C400 I2C100 I2CFAST nakI2C@ ackI2C@ I2C@ I2C! I2C!? I2C> <I2C> <I2C ?I2C i2cflg MODPINS SETPINS SPIPINS @SPISCK @SCL @CNT @CE @MISO @MOSI @SCK @SDA *SDA *SCL BLINK RINGS RING SIREN WARBLE BIP BEEPS TONE BEEP CLICK SPKR LOW@ HIGH@ FREQ@ FB EDGE NEG POS COUNT@ !COUNT DETECT MUTE HZ KHZ MHZ VOLTS FRQ DAC! BPIN APIN PLLDIV PLL DUTY DIFF CTRMODE NCO B A SERIN ISERIAL SERIAL I SEROUT SEROUT SERBAUD TRAP +VECTOR REVECTOR REDEFINE (FORGET) FORGET RECLAIM STRIP !INITS +INIT AUTORUN INIT .CFA . HEAD$ ?ANSI MARGINS WRAP BOLD REVERSE PLAIN CURSOR ERLINE ERSCN CLS XY PAPER PEN HOME ESC white cyan magenta blue y ellow green red black .BIN32 .BIN16 PRINT& .DEC2. .DEC2 .DECL .DEC4 .AS" .AS COGINIT TASKREGS RUN: RUN TASK? RND PI NS@ OUT PIN! CNT? =CNT CNT@ P! P@ VSCL VCFG PHSB PHSA FRQB FRQA CTRB CTRA DIRB DIRA OUTB OUTA INB INA CNT PAR SPR L EFT$ RIGHT$ MID$ +CHAR $! APPEND$ $= LOCATE$ NULL$ ESC? CON] CON [CON boot NULLOUT EMIT: KEY: M MB KB 1M s us ms FO RK R@ INVERT MOD 2OVER 3DUP 2SWAP D. @. => <= AVG C~~ W~~ ~~ W>L B>L B>W W>B L>W >W 3++ 3@ 3! @3 2++ 2@ 2! @2 1++ 1 @ 1! @1 C-- C++ W-- W++ -- ++ FALSE TRUE |< ] =[ SWITCHES CASES BREAK CASE SWITCH@ SWITCH STRING TABLE |<= WRAP DS res DS+ reg clong cword cbytes CARRAY CREATE DOES> SHORTCUT QUIET NUM>STR STR>NUM .W: .W .L LIMIT >| :=! BIG! BIG@ U@ U! org@ CLKMHZ CLKFREQ PUBLIC PRIVATE EXTEND NOP ?DUP DUP 2DUP 3RD 4TH OVER SWAP ROT -ROT DROP 2DROP 3DROP NIP B OUNDS AND ANDN OR XOR ROL ROR SHR >> 8>> SHL << 8<< 2/ 2* 4* SAR L>S REV MASK >b >N >B 0= NOT 1+ 1- + - OVER+ 2+ CE LL+ 2- * UM* U/ U/MOD / */ UM*/ 0<> <> WITHIN U> = > < U< 0< IC! IC@ C@ W@ @ C+! C! C@++ W+! W! +! ! D@ D! C~ W~ ~ BIT? SET? SET CLR TOG BIT! COG@ COG! CMOVE <CMOVE ERASE FILL CLOCK CLKIN CLKOUT H L P T F SHROUT SHRINP OUTSET OUTC LR OUTPUTS INPUTS HIGH LOW FLOAT PIN@ IN WAITLO WAITHI SPIWRB SPIWR16 SPIWR32 SPIWR SPIRD SPICE DO ADO FROM BY FOR NEXT LOOP I J K LEAVE FOR@ FOR! BY! LP! LP@ RESET 0EXIT EXIT ?EXIT CALL JUMP ?JUMP IF ELSE THEN ENDIF BEGIN UNTIL A GAIN WHILE REPEAT " ." PRINT" >R R> !RP !SP : pre pub pri module ; [C] ' ['] NFA' NFA, NFA$ := vars org @org byte w ord long bytes words longs , || | C, W, L, ALIAS RUNMOD LOADMOD COGSTOP pCOGINIT COGID REBOOT CLK CLKSET WAITX WAIT CNT (EMIT) (EMITX) EMIT SPACE SPACES CR KEY WKEY (KEY) KEY! doKEY CLS EMITS DOT BELL <CR> TAB TABS XTAB SPINNER TX! .HEX .BYTE .WORD .LONG .WORD$ @PAD HOLD >CHAR ASCBIN #> <# # #S <D> PRINT$ CTYPE .NFA LEN$ U. .DP PRINT . CREATE: CREATE$ GETWORD SEARCH CFA CPA +NFA NFA ALIGNORG ALIGN @NAMES names WORDS ALLOT ALLOCATED HERE [W] [B] ["] KEY$ [W, ] VER .VER TACHYON END CONSOLE ECHO DISCARD TASK REG BUFFERS COLD HEX DECIMAL BINARY LAP LAP@ RAM DUMP: DUMPX DUMP DUMPW DUMPL DUMPC DUMPA DUMPAW QD DEPTH .S DEBUG .STATS IDLE NOOP --- --> \ '' ( { } IFDEF IFNDEF OFF ON GRAB ABS ? NEGATE NEGATE MIN MAX MINS MAXS ADDABS SUBABS CMPSUB UM/DMOD UM/MOD WAITVID [WS2812] [SDRDF] [SDRD] [SDWR] [SDIO] [ LTC2754] [SSD!] [PWM32] [PWM32!] [PLOT] [CAP] [WAV] [MCP32] [RCTIME] errors uhere uthere flags prompt uauto keypoll lastkey rxpars rx id keytable @WORD uemit ukey base num uswitch undef (.") (") ... V5 *end* ok ... fibos --> fibo(1) = 1 688 cycles = 7.166us fibo(6) = 8 1,168 cycles = 12.166us fibo(11) = 89 1,648 cycles = 17.166us fibo(16) = 987 2,128 cycles = 22.166us fibo(21) = 10946 2,608 cycles = 27.166us fibo(26) = 121393 3,088 cycles = 32.166us fibo(31) = 1346269 3,568 cycles = 37.166us fibo(36) = 14930352 4,048 cycles = 42.166us fibo(41) = 165580141 4,528 cycles = 47.166us fibo(46) = 1836311903 5,008 cycles = 52.166us ok ... HELP fibo 5E2A 366A 0 fibo ADDR: DATA NAME 366A: 8000 0 366C: 8001 1 366E: 009C ROT 3670: 0156 FOR 3672: 0097 BOUNDS 3674: 0166 NEXT 3676: 008A DROP 3678: 005A EXIT ... MOUNT --> CARD: SL08G SD03.80 #8C0D.A960 2016/2 !C0FF.80AF 1,518us FAT: #6338.6430 WIDGET FAT32 7,944,011,776 bytes (32kB clusters) ok ... DIR --> CARD: SL08G SD03.80 #8C0D.A960 2016/2 !C0FF.80AF 1,519us FAT: #6338.6430 WIDGET FAT32 7,944,011,776 bytes (32kB clusters) WIDGET _BOOT_P2.BI1 .....a 0000.D600 96 m2018/05 /14 15:23 c2018/10 /05 08:04 520. a2018/10 /05 P2ROMA .TXT .....a 0000.D980 411k m2018/05 /30 23:13 c2018/10 /05 08:05 660. a2018/10 /05 HELP . ....d. 0000.DCC0 0 m2017/12 /04 12:34 c2018/10 /05 08:06 840. a2018/10 /05 FISH2 .VT .....a 0000.E040 211k m2017/11 /23 15:08 c2018/10 /05 08:06 840. a2018/10 /05 3X5 .TXT .....a 0000.E200 3968 m2017/11 /23 15:06 c2018/10 /05 08:06 840. a2018/10 /05 LOVE .WAV .....a 0000.4240 14M m2015/02 /16 08:06 c2017/03 /22 23:42 400. a2018/10 /18 POPCORN .WAV .....a 0000.B200 117k m2014/06 /17 06:15 c2017/03 /22 23:42 400. a2018/10 /18 ASCIIART.TXT .....a 0000.E240 55k m2017/11 /23 15:05 c2018/10 /05 08:06 840. a2018/10 /05 MIDENG .TXT .....a 0000.E2C0 1M m2017/11 /23 14:11 c2018/10 /05 08:06 840. a2018/10 /05 VULGAR .TXT .....a 0000.EC80 511k m2017/11 /23 13:56 c2018/10 /05 08:06 840. a2018/10 /05 ROUGES .TXT .....a 0000.F080 219k m2017/11 /23 13:51 c2018/10 /05 08:06 840. a2018/10 /05 WARPEACE.TXT .....a 0000.B540 3M m2015/08 /30 07:27 c2017/03 /22 23:42 400. a2017/03 /22 ROM_136X.OBJ .....a 0000.CE00 1M m2018/05 /15 23:02 c2018/05 /16 14:55 000. a2018/05 /16 LEXICON .TXT .....a 0000.F240 988k m2017/11 /23 13:48 c2018/10 /05 08:06 840. a2018/10 /05 WARWORLD.TXT .....a 0000.FA00 365k m2017/11 /23 13:42 c2018/10 /05 08:06 840. a2018/10 /05 WEBSTERS.TXT .....a 0000.FD00 28M m2017/11 /23 12:59 c2018/10 /05 08:06 640. a2018/10 /05 ILIAD .TXT .....a 0001.DA00 1M m2017/11 /23 12:55 c2018/10 /05 08:06 640. a2018/10 /05 PRIDE .TXT .....a 0001.E340 726k m2017/11 /23 12:54 c2018/10 /05 08:06 640. a2018/10 /05 EASYFILE.FTH .....a 0001.E900 46k m2017/10 /24 13:53 c2018/10 /05 08:06 640. a2018/10 /05 EXTEND .FTH .....a 0001.E980 60k m2017/10 /24 12:14 c2018/10 /05 08:06 640. a2018/10 /05 EASYNET .FTH .....a 0001.EA00 42k m2017/10 /24 01:57 c2018/10 /05 08:06 640. a2018/10 /05 LIFE .FTH .....a 0001.EA80 7308 m2017/10 /15 05:40 c2018/10 /05 08:06 640. a2018/10 /05 CALCDEMO.FTH .....a 0001.EAC0 1848 m2017/10 /11 06:28 c2018/10 /05 08:06 640. a2018/10 /05 KJV .TXT .....a 0001.EB00 5M m2017/08 /28 12:28 c2018/10 /05 08:06 640. a2018/10 /05 SEE .FTH .....a 0002.1500 2187 m2017/07 /06 01:30 c2018/10 /05 08:06 640. a2018/10 /05 SPLAT-V4.FTH .....a 0002.1540 18k m2017/03 /09 12:30 c2018/10 /05 08:06 160. a2018/10 /05 FILES . ....d. 0002.1580 0 m2018/10 /05 08:10 c2018/10 /05 08:10 170. a2018/10 /05 _BOOT_P2.BI0 .....a 0002.1BC0 65k m2018/10 /18 01:01 c2018/10 /18 01:02 000. a2018/10 /18 _BOOT_~1.BI1 .....a 0002.1C40 65k m2018/10 /18 01:01 c2018/10 /18 01:02 000. a2018/10 /18 _BOOT_~1.BI2 .....a 0002.1CC0 65k m2018/10 /18 01:01 c2018/10 /18 01:02 000. a2018/10 /18 BIRD .BMP .....a 0002.1D40 308k m2015/11 /17 10:00 c2018/10 /22 22:58 800. a2018/10 /22 GIRL .BMP .....a 0002.1FC0 308k m2018/10 /19 14:14 c2018/10 /22 22:58 800. a2018/10 /23 MARIO .BMP .....a 0002.2240 256k m2018/10 /19 14:41 c2018/10 /22 22:58 800. a2018/10 /23 TIGER .BMP .....a 0002.2440 308k m2018/10 /19 14:59 c2018/10 /22 22:58 800. a2018/10 /22 LMMS .BMP .....a 0002.26C0 308k m2018/10 /23 01:01 c2018/10 /23 01:03 000. a2018/10 /23 DRAGON .BMP .....a 0002.2940 308k m2018/10 /23 01:21 c2018/10 /23 01:22 660. a2018/10 /23 P2D2A .BMP .....a 0002.2BC0 331k m2018/10 /23 05:40 c2018/10 /23 05:43 000. a2018/10 /25 P2D2B .BMP .....a 0002.2E80 331k m2018/10 /23 05:44 c2018/10 /23 05:44 450. a2018/10 /23 P2BLOCK .BMP .....a 0002.3140 308k m2018/10 /24 23:40 c2018/10 /24 23:41 550. a2018/10 /24 P2D2C .BMP .....a 0002.33C0 308k m2018/10 /25 00:49 c2018/10 /25 00:50 960. a2018/10 /28 FACE .BMP .....a 0002.3640 308k m2018/10 /28 04:03 c2018/10 /28 04:04 280. a2018/10 /28 SUNSET .BMP .....a 0002.38C0 308k m2018/10 /28 04:13 c2018/10 /28 04:14 240. a2018/10 /28 EYEGOD .BMP .....a 0002.3B40 308k m2018/10 /28 04:17 c2018/10 /28 04:17 910. a2018/10 /28 MCQUEEN .BMP .....a 0002.3DC0 308k m2018/10 /28 04:19 c2018/10 /28 04:19 000. a2018/10 /28 SPIDEY .BMP .....a 0002.4040 308k m2018/10 /28 04:24 c2018/10 /28 04:24 960. a2018/10 /28 ok ... FOPEN KJV.TXT --> ...opened at 0001.EB00 for 5504282 ... 0 $80 FS DUMP --> 0000.0000: 20 20 20 20 20 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F ___________ 0000.0010: 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F ________________ 0000.0020: 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F ________________ 0000.0030: 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F ________________ 0000.0040: 5F 5F 5F 5F 5F 5F 5F 0A 0A 20 20 20 20 20 20 20 _______.. 0000.0050: 20 20 20 20 54 69 74 6C 65 3A 20 54 68 65 20 4B Title: The K 0000.0060: 69 6E 67 20 4A 61 6D 65 73 20 56 65 72 73 69 6F ing James Versio 0000.0070: 6E 20 6F 66 20 74 68 65 20 48 6F 6C 79 20 42 69 n of the Holy Bi ok ... 1234 1,000,000 * PRINT --> 1234000000 ok ...Which means that all four EEPROMs used are mapped like this: As we know, for EEPROMs 64KB and smaller, the Device Byte A2,A1,A0 fields are external physical inputs to essentially select up to 8 of these on the I2C bus.
For the 128KB EEPROM, Device Bit A0 has been replaced with memory location A16, while the physical pin formerly known as A0 became NC.
And for the 256KB EEPROM, Device Bit A1 has also been replaced with memory location A17, with physical pins formerly known as A1 and A0 replaced with NC.
So, looking at the above table, the EEPROMs are properly segmented and mapped into their expected ranges.
Indeed, Tachyon confirmed this by successfully writing to and reading from all EEPROM memory locations from $00000 to $7FFFF.
However, the Catalina EEPROM loader failed while trying to access memory locations from 64KB to 128KB. @RossH had mentioned the Catalina loader is quite old and was only designed to work with EEPROMs up to 128KB. It also clearly has problems working with multiple EEPROMS on the I2C bus.
Hopefully in due time, when (if?) he returns to this forum he can take a closer look.
Of course, if I disable the FLiP internal 64KB EEPROM, and use only the 256KB EEPROM on the expansion board the Catalina loader will work. That's essentially what I did with my USB Project Board and it works fine.
The caveat is that the 256KB EEPROM will have to be placed on the expansion board where the 64KB one currently is. This is certainly doable, and will allow me to proceed with my Project, but the intent was to not mutilate the FLiP but instead allow full 512KB EEPROM access by simply plugging it into the expansion board.
Until the Catalina loader is fixed (or another software workaround is found), it's time to mutilate a FLiP, remove the 64KB and 128KB EEPROMs on the expansion board, and install the 256KB EEPROM instead... Wow, I priced out 10 of these chips and I can have them delivered to the USA for $11.19, including shipping. Amazing!