If you are going to copy from FRAM to RAM and then turn off FRAM (or deselect until next reset) you don't need to think about wearout - or do you wish to reboot your next Ittiara 10^14 times ?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yes, I do hope that my system software will be stabler than that. It'd better be stabler than WinCUPL! That thing crashes when I try to compile the logic I intend to use.
A 65SPI and my address decoder should probably fit in an ATF1508(at a guess), but even if it doesn't, that shouldn't crash the whole IDE with a runtime error. An incorrect file seems to stop with syntax errors, but a correct file(I'm not sure about this) crashes it. It might have something to do with the fact that I'm running it on windows 10. Switching tools will be a pain, because as far as I know, nobody else makes CPLDs anymore, only FPGAs.
Looks like it's VM time.

EDIT: I got WinCUPL to compile it without issue on Windows 98 SE. Getting files in is relatively easy; VirtualBox provides the tools to do that. Getting them out is... interesting. I have to open the hard disk image used by the VM and extract it from there. That said, I can get them out, so it wasn't a total waste of time. The fitter complains that there's a dodgy pin assignment, referencing something to do with 108, but that text doesn't appear in the source file, nor is there a pin assignment on that line.

I looked into FRAM and used a DIP8 SPI chip on one project. As I understand it, you get 10^13 or 10^14 writes [EDIT: at least, not on average] to a memory location, not just to the chip, before something breaks. It's kind of like sectors wearing out in flash. Reads are unlimited so you can even survive Windows level restarting

When I was doing CPLD stuff I was using a 16 bit DOS command line utility in a VM to convert WinCUPL output to a format I could send to a microcontroller to program the CPLD since I didn't have the Atmel programmer. You should be able to mount a folder on your hard drive as a disk in the VM and use a script to copy the compiled file to the drive so it appears instantly on your hard drive every time.

> you get 10^13 or 10^14 writes on average

Note that this is very much not what I read: that the characterisation has not shown any finite life. The lifetimes are 'at least' and not 'on average' and they haven't seen failures. Of course, if this is no longer the situation, I'd love to know (and to update my previous posts.)

AFAICT there's no reason to avoid FRAM on the basis of lifetime.

(Edit for typo)

Yes, I should have said at least. Corrected above.

TI makes versions of their MSP430 microcontroller with integrated FRAM. Someone on IRC was telling me that a guy on the forum used it for video memory and got it to fail after extended usage, but I don't have a link to confirm. I suppose you could do the math for your own usage. If you believe the 10^13 number, the worst case scenario might be LDX #0 / LDY #$FF then filling the rest of memory with STX 0 / STY 0 followed by a JMP at the very end. At 14mhz of round the clock operation, poor byte 0 would get 14,000,000 / 3 * 60 * 60 * 24 = 4.032 * 10^11 writes per day and could fail in 10^13 / 4.032 * 10^11 = 24.8 days. Realistically, which byte in RAM gets written to the most often? A global variable in zero page? The top of the stack on a simple system? If you run non-stop for 10 years then you might risk a failure if you write that byte every 365 * 10 / 24.8 = 147 instructions (assuming 3 cycle instructions as above). For most people, this will never be an issue, but I am still skeptical of TI telling the MSP430 community to "use it as RAM" regardless of application (again, assuming 10^13 is actually meaningful).

BigEd, I had not heard that they have never observed failures but that is interesting. Maybe 10^13 is just a CYA number. I will see if I can find anything else about the supposed failure on the MSP430.

Running video from FRAM sounds like a solid worst-case scenario!

F-RAM reading also affects endurance:
from

I think the essential takeaway is: don't use F-RAM for low 6502 RAM, VRAM or to store "hot" program code, but it's fine for just about any other purpose.

As far as WinCUPL goes, I think it's actually the GUI that's unstable, and not the underlying command-line utilities. I've stopped using the GUI; it's far too frustrating (and almost completely unfit for use, in my opinion). WinSim is OK as a display and a start button, but since it misbehaves so easily, I think it's better to write the input file in a text editor and just load that into WinSim.

I've gotten the source to compile now, after sorting out the MapDown node. I still have to insert the wait-state logic for the FRAM, which shouldn't be too hard. I'll need to do a bit of research into that, but I believe there's ample information floating about the forums that I can use. Since the FRAM's low speed isn't going to be much of a concern to the clock rate, I can crank the speed as fast as the next limiting factor(probably the CPLD) will let me.
Of course, given that this is a programmable logic device, and that I'll either have a JTAG header on the board, or make up a JTAG programming board, I can start it slowly, and then crank the speed till it trips, and adjust the number of wait-states as necessary.

I plan to use FRAM as non-volatile program storage, but it'll be copied to RAM as part of the reset sequence and then mapped out of bank zero.

In any case, now that I have a CPLD design that seems vaguely workable, I can start on laying out the hardware, as annoying as that's going to be. Schematic capture and board routing are always the most annoying part of this hobby, to me, but the results are so nice.

A JTAG port is trivial to implement, and is quite convenient.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I managed to get around to overclock testing Ittiara 3.1, and it seems that the AT28C256 EEPROM is very conservatively rated.
I set a Sieve of Eratosthenes running in Forth(I figured that would provide a good test workload), and started cranking the frequency up from 1MHz.
Back before I built it, I'd calculated that ~3.8MHz was going to be my maximum frequency. It seems that this actually tops out at 7MHz or thereabouts. It doesn't boot properly at 7.6MHz or faster, and 7.2MHz felt slightly unreliable. 7 MHz seemed to be solid enough.

I didn't have an oscilloscope hooked up to the frequency generator as I was doing this, though, so I don't know what the output did when I switched frequencies. I think that it might have been glitching when I switched it, because it would still boot at 7.3MHz, but it would crash if I started it at 7.2 and then turned it up to 7.3.

Getting to the point of running the test was a bit of a journey. I had to write a set of block words so I could read and write from the SPI EEPROMs I have (finally found a good use for those things...). That got a bit interesting, because some words seem to behave differently depending on whether they are interpreted or compiled. Then I had to work out why the count was getting written instead of the data(missing data retrieval), and then why some EEPROM pages weren't getting written to(I think the writes weren't actually completing, so I had it poll for write completion before moving on).

All of this highlighted the fact that the 32 columns I have don't cut it for software that assumes an 80-column display, as most of Tali Forth does, including the block editing words. I actually did the debugging and code entry using Tera Term, because a block is completely unreadable on Ittiara's current display(It's got about a quarter the character space required for just the block contents). I figure I can get around that problem by writing my own block-editor words for now(operate line-by line instead of on the whole block), and changing the display for something that can actually do 80 columns(like this, perhaps) later on, when I feel like I've got the money.

So I've come back to the project again, and taken a somewhat fresher look at the design.
I know I said I wasn't going to use the '265, but it's actually looking fairly attractive again.
It gives me four UARTs for less money and less board space, and makes device decoding substantially easier, because so much of it is already done on-chip. It also gives me an easier way to remap the FRAM.

I think I've also come up with a way to write to the FRAM without using the '265.
I want to do this because the monitor in the '265 makes the assumption of 9600 baud with hardware handshaking. I've chosen to standardize all my stuff on 115200 baud without hardware handshaking, and I'd rather not move.
- The SRAM port(for one of Garth's modules) has A0-14, D0-7, /RD and /WR, all connected to the FRAM.
- The FRAM select is not connected to that port.
- The '265 or the CPLD typically drive most of those pins.

My idea is to connect the programmer(whatever that ends up being) to the SRAM port, to take advantage of the bussed lines it's connected to. Dealing with the FRAM select and getting the '265 out of the equation will be part of the same solution.
I plan to put a jumper on the board(with a pull-up/down resistor), connected to an input on the CPLD that I'll call PGM. This will enable programming mode when jumped.
While in programming mode, the CPLD will:
Hold /RES active, making the '265 irrelevant(using an open-collector driver to prevent contention if the '265 pulls down its /RES pin),
Hold the I/O decodes inactive, to avoid any spurious accesses,
Tri-state the /RD and /WR outputs, to prevent contention,
Turn one of the SRAM select pins into an input, and mirror the state of that out on the FRAM select.
This should allow me to program the FRAM through the SRAM connector.

The fast clock will be 9.216 MHz, for easy baud-rate generation. I'm undecided on the slow clock. I have a couple of 32,768 Hz crystals around, so I'll probably use one of those.

I've also had an idea that might or might not be useful.
The 65SPI CUPL code that I have doesn't implement one of the registers present in the old version. I can probably appropriate that memory location for an "IRQ source register", which sets a bit for each IRQ source currently requesting, and a global IRQ bit as well. Since I plan to have two VIAs, two SPI-10 ports, and the 65SPI, such a register could simplify figuring out which device is interrupting.

I got one of these(Link) yesterday, with an Arduino Due.
I thought it'd be 5V tolerant, because they were offering a Uno, a Mega, or a Due with it. Apparently it isn't. It's got 74LV245s sitting between the Arduino and the module, and they look like they're supposed to be there for voltage conversion, but apparently not. There's also possible that the person who answered my inquiry misunderstood my question, but still.
These guys also distribute old versions of the UTFT and URTouch libraries without giving any sort of credit to the actual creator of said libraries, and they don't give out the documentation that goes with them, either.
Needless to say, I'm not using their (badly) rebadged library. I'm using the updated one.

Regardless, it is a functioning product. It's a 2.4" 320x240 panel, so it gives me 40x30 characters with an 8x8 font, but the text is tiny; each character is about 1.5mm high. I got the resistive touch option with it, but I have not yet gotten that working. It looks like it might be a concurrency challenge, too.
If I'd known how miniscule the text was going to be, I'd have ordered a physically bigger display.
As it sits, it's much too tall on its own, so I'll be mounting the display directly to the mainboard, and including a microcontroller of some form to replace the Arduino and shield I have now.
I've got it working with the Due, and the code compiles for an Uno, so it should work on the ATMega328 I plan to put on the mainboard(and run at 3.3v to cut down on level translators).
I've even run Ittiara through it, although doing that is a bit awkward, and the display protocol is not quite compatible with the old one. I also need to update parts of it to take a double byte for the X coordinate, because 320 does not fit in one byte.

In any case, I now have a mostly-functional 320x240 LCD, with 128 programmable colours, and the potential for touchscreen functionality as well.