_________________
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?

We've had several debug investigations here on the forum in the past year or two where it turned out that glue logic, or clock skew, was eventually found to be the root cause.

It feels like it's been a while since I did anything much with Iittiara. In any case, I feel like I should leave something here.
I'm not going to bother replacing the 65SPI on v3.1, because I think it'll be better to save that money for the next thing.

My to-do list currently looks like this:
- Write/obtain software SPI routines for [Ittiara] v3.1
- Set up IRQ-driven transmission and reception on DUART channel A
- Design PCB for Ittiara v4.0 (65816-based)
- SPI-10 ADC and DAC modules

I have decided that the final design will be based on the 65816 instead of the '265 to make the software interface cleaner. If I use the '265, it eases the hardware design a bit, but using that part defeats most of the purpose of using a microcontroller in the first place, that being chip count reduction. It has no user-programmable EEPROM or Flash, and a rather odd selection of peripherals, most of which I hadn't planned to use. It would also make the programming interface more cluttered than I'd like, so I'm just going to suck it up and use the '816. i was already going to include a CPLD with the 65SPI and glue on it (I was thinking the ATF1508), so there's little enough point in using the '265 anyway.
I can jam the high address gating in there, and probably wait-stating if it becomes necessary.

I also want to use F-RAM as the program store instead of EEPROM. EEPROM is slow, and won't get me to the speeds I want to reach. F-RAM should be fast enough on the write cycle that I can write to it without needing to wait for it afterwards. I'm kind of worried that I won't be able to program it initially, though, as it's an SMD-only part, as far as I have looked. I can probably co-opt the CPLD as a programmer, until I can do it using the MPU, but I'm not sure how well that's likely to go.

I plan to use surface-mounted parts and sockets so that I can put them on both sides of the board, particularly the MPU and CPLD, which need a lot of connections. That way I can just punch them through the board with vias. It won't work quite the same for the 6522s(I want two on the next version), but it will allow for less board area used.

Well, I have a set of software SPI routines now, copied and lightly modified from this thread. I have it set up as a single-slave only affair, seeing as this is really only intended to be a stopgap measure until I get around to actually doing the next hardware version.

I've also gone through the latest Tali Forth 2 code, and converted it to work with my existing toolchain and support routines. I've got that working now, and with a few alterations to some of the native words, it seems to be working nicely with my current hardware.

I really think I'm going to want more screen space, though. Especially if I want to use the block system, which I think I do.
I don't really want to dig into the protocol of a TFT LCD controller; I've looked at one, and it looked particularly painful to implement. I'll probably go for a Gameduino 2 or similar, especially if I can get it to talk to my UART.

The programming could also be accomplished using my Ultra-Minimal 3-Wire Interface ™. The main necessity, hardware-wise, would be adding some resistors, and a hook into the enables or glue logic in order to allow the data bus to be tri-stated on demand.

Besides letting you write to an SMD non-volatile memory, the interface would also let you write to plain ol' RAM. That might be a welcome alternative to NV-memory, in the context of code testing/debugging, I mean. Something else that can be tested/debugged is I/O, since this too can be written.

I'm just throwing the idea out there. Right now the Level 1 loader is fully specified and tested. But the Level-2 loader is more a concept than a reality, so you'd have to contribute that yourself. (Or do without it. RCE out of page 1 might be sufficient.)

BTW, congrats on the developments with Tali Forth and the SPI routines. Seems like solid progress!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I've analyzed the timing for what I'd hoped would be the next iteration of Ittiara, at 8MHz. It turns out that a 70ns response time is nowhere near meeting the '816s setup time requirement, and comes in 11ns after the next fall of Phase 2, 26ns too late.
I can shave 9ns off that if I use the fastest speed grade of the ATF1508. This is still not enough to make that work.
It seems that I need one of:
1) a faster part,
2) a slower system clock(7.14...MHz max),
3) wait-states,
4) or copy-to-RAM.

The problems with these are:
1) A Mouser search doesn't turn up any parts that are faster, except for OTP EPROMs(I'm aware that Mouser's parametric search is effectively useless),
2) 8MHz operation is a design goal,
3) I don't really want to use wait-states(it feels like cheating on the speed goal),
4) and I think that copy-to-RAM could get messy.
But having objected to all of those, the last two seem weak and weaker, respectively.

Having thought about this a bit, I've come up with the following idea:
The FRAM(with wait-states) is normally mapped into the top half of bank $FF, and is writable.
On reset, it(along with its wait-states) gets mapped into the top half of bank zero, and becomes non-writable.
The first thing that happens in the reset routine is the FRAM gets read byte by byte, and written to the same memory locations. These writes go to the RAM sitting underneath the FRAM, instead of the FRAM itself.
At the end of this copy, the '816 hits a memory location that maps to the CPLD in some way, and this kicks the FRAM back up to bank $FF. I'd probably use one or all of the registers from the 65SPI, since I plan to put that into the CPLD anyway.

Do you guys think this is a good idea? And have I missed something?

I think copy-to-RAM is a good solution. You have the RAM anyway, and it just removes all the difficulty of the slower ROM, once you're past boot time and into show time.

Interesting point of view. I never thought much about the MCU aspect - for me the '265 (and the '134 in a similar manner) are just easy to get up MPUs with a little RAM and a (more or less) working monitor that eases HW setup and inspection. But once I loaded (flashed) my own boot/monitor/OS/whatever software, the internal ROM isn't used anymore.
Yes, the "equipment" of the '265 (and even more that of the '134) is truly outdated. (To be frank, the CPU itself is somewhat outdated too but we all love it.) But you get a working (!) UART and some timers and edge sensitive I/O pins for "free". And most important: separated interrupts (with distinction between BRK and IRQ!). To me this alone is worth the money.
Beside their limited endurance when using them as regular RAM the cycle time requirement is roughly twice the access time. 5V types are perhaps a little bit too slow for 8 MHz. The (newer) 3.3V tolerant may work. There is also MRAM - but only 3.3V and less tolerant to magnetic fields and perhaps too power thirsty.

There are battery backed SRAM devices if you want to get away from the magnetics. Some in 45ns speeds (surface mount), and 70ns speeds for through hole.

See here for examples:

https://uk.farnell.com/w/c/semiconducto ... ts?st=sram

They're suggesting up to 10 years data retention and some have replaceable batteries too.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Use the slow clock to copy to RAM, then switch to the Fast clock. The MCU has direct support for this. Depending on the ROM size, it'll only take a second or so to boot.

Yes, having two clocks and (in case of the '265) the choice running a section of memory with CLK, FCLK, or FCLK/4 is another "free" benefit when using the MCU.

But remember DerTrueForce has already decided to went with the '816. There is no such feature available, but using battery backuped RAM as Gordon (drogon) suggested is another very easy and fast solution.

_________________
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?

From a previous discussion: "FRAM is touted as having effectively unlimited capacity, usually spec'd as at least 10^14 or 10^15 accesses, with one manufacturer saying they'd never observed a wearout failure."

I have no idea whether FRAM wearout is just a tale or not. The problem as said is that reading requires a write-back (similar to old core type memory it appears). So reading affects endurance as well as writing.

Cypress talks about an endurance of 10^14..10^15 cycles. Rohm is more anxious and only talks about 10^12 cycles.

Assuming a 65Cxx @ 10 MHz running an endless waiting-for-user loop as part of a monitor - i.o.w. completely running in FRAM - it would take only 10^14/10^7/3600/24 = 115.74 days to reach that limit. There are most likely safety margins, so it might last much longer.

I think the point is, such a storage is perfect for certain applications (like metering equipment), but it is not a replacement for (working) RAM in cases where the processor is constantly working.

In the given application I would choose either a battery-backed RAM (plus write protection) or fast flash-type ROM or MRAM.


my 2 cents,
Arne

You are correct Arne, FRAM does feature destructive readout, but you seem to have missed that my intention for it is not as ram, but as a slow pseudo-ROM. It will be copied to RAM on startup, and then mapped into the very top of memory, so that it can be updated later.

I expect the wear pattern to be fairly even, except where the copy loop lives. I can probably speed up the copy and lower wear a bit if I have the RAM-copier copy itself to some other section of RAM, before copying the FRAM.