You should definitely take a deep look into the WDC65C265 specs. (It is hard to read, several runs required.) You could get a lot in a tiny space if you dare to use the flat package. 8 MHz is guaranteed, 12..14 MHz should be no problem. This beast has a lot of goodies but understanding the poor description is hard work

There are some post around here, where people try to figure out what is possible using that chip, e.g.: Link


Regards,
Arne

I'm only planning on including 32KB of EEPROM/FeRAM. I'd probably use a 32KB SRAM to fill out the rest of bank zero, and map the bulk memory into higher banks.

I tend to think of SOICs and TSOPs when I think SMD, but the SOJ trick is something I should keep in mind. I've been sort-of worrying about keeping the thickness down(this is meant to be a handheld in the end), but that might not be a problem, because I also want to put all the IO devices in sockets, and they'll stand up a fair height anyway.

As for the '265: I like that it has a non-multiplexed bus(when enabled), and that it includes timers, UARTs, and GPIO on the chip itself. I don't like that its internal ROM is not user-programmable, and I've heard unpleasant things about its memory mapping. But you're right, I should take a closer look. The documentation quality is pretty bad, but it looks as though the device could be usable. It might be worth investing in a QBX board when I have money, to see if it's actually as painful as I'd assumed. If it isn't, it could be a very powerful shortcut. I could put the whole computer into four or five chips(2-3xRAM, ROM, '265) if I moved the SPI into software. Otherwise, it'd probably be nearly double that(Same 3-4 memory chips, '816, decoder, latch, 65SPI, DUART).

FWIW you could reduce the height by cutting a hole in the board and having the lower RAM chip recessed, with its leads bent to extend straight out like a flat-pack IC. It's the same idea which DigitalDunc mentioned recently in regard to QFP IC's. And I think you could still piggyback a second RAM on top.

The hole in the board means you can't run traces through there, which means there's clearly a compromise when it comes to signal routing. Even so, the idea is maybe worth remembering.

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

The documentation is a reference manual, not a users guide. But it's decipherable. There's a couple threads here that do it. It's probably worth your time to skim the source listing of the ROM contents.

While the ROM isn't user programmable, it does contain a bunch of routines to drive the UARTs and what not. You'll need those routines (or something like them) in the end anyway. The boot sequence is straight forward. The internal ROM will call your external ROM (very early), at which point as part of startup you can disable the internal ROM and reuse it's space with your off chip ROM.

Adding 32K of RAM is trivial.

You can do these with no select logic at all. A RAM chip and a ROM chip and the MCU.

With a little tricky reset logic, the built in ROM is never fired at all (you need to keep the BE/RDY line low after the RESB goes high, then BE/RDY goes high). If BE/RDY is wired high, you'll enable the internal ROM and start there.

I've recently discovered SB-projects' A1-assembler. I'll start on adapting it for Ittiara after my exams are done. I want to be able to write programs on it at some point, and this will make it far easier if I can get it running.

I have gotten A1-asm working. I thought it didn't like its sources with spaces, but it turns out that I wasn't entering the source correctly, so it's fine. It definitely doesn't like lowercase, though, so I wrote and inserted a toUpper routine and then called that right after the character input loop exits. Now I don't have to hold down my one shift key while I type.

What is becoming more and more apparent is that while the display I'm currently using is easy to interface, it's 21-column display can easily make it a usability problem. I've also gotten EhBASIC working on Ittiara as a standalone ROM(I plan to integrate it into the main ROM), and it's not hard to write a source line that doesn't fit on one display line.

When I can afford it, I'll get myself a Gameduino 3, or something like it, so I can get more columns in. Even 40 columns would be a significant improvement on 20.
And while I'm at it, I'll probably design a better keyboard. I won't be able to pull the toUpper trick everywhere. I believe EhBASIC can support lowercase, but it does throw a syntax error if I try to use it in a keyword, so that may also need investigation.

Next, I think I'll look at setting up a filesystem for my SPI storage, then building load and save routines into EhBASIC and A1-asm.

Call me crazy, but I'm currently trying to get EhBASIC to work on my 20x4 LCD screen.

_________________
Cat; the other white meat.

Hey, if you're willing to live with it, it's not crazy at all. I'm probably just pickier than you in this area.
I feel a bit cramped with just 21x8. It could be that I'm too used to 80-column terminal windows.

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

For me, it's really for another project that I will be starting some day soon. I want to design a trainer PC that is primarily LCD driven (think KIM-1 but with 20x4).

_________________
Cat; the other white meat.

I have fixed the memory copy routines. They now function as they should. I had an intermediate version which wouldn't copy just one byte, but I thought about it before I posted and fixed it properly.
This was the original routine:


This would only copy the high half of a page, if I fed it $FF in Y. Quite why I did this, I don't know. I can only assume I got confused or sidetracked, as this clearly is not going to do what I want.
I've changed it to this:

This will now copy a whole page if I give it $FF, and just the one byte if $00. Now that I can grab chunks of data and drop them into an EEPROM, I can start on a filesystem.
I've come up with a basic sort of spec for one, but if there's already one that's not going to need much space overhead, I might use that instead. A modified version of the Minix FS looks like it might work well(I don't plan to boot from these things, so I can probably toss out the boot block). I do think it's a good idea to use existing formats when possible(and sensible), rather than building a custom thing that won't be compatible and might not be as well-designed.

Ittiara has a boot menu now. I just need to implement a filesystem for my SPI EEPROMs, and I should be able to implement a file browser and SPI loader.
Much as I didn't want to make another incompatible format, I've not found any particularly concrete data for anything but the MINIX filesystem, and that looks like it has too much overhead for a mere 64KB device. Of course, this could just be me being lazy about trying to understand it enough to implement it. I reckon it'd be far easier if I could use cc65, but either I don't understand C well enough, or cc65's page on targeting a new system is badly-written. Either way, I don't think I can reliably target Ittiara from it. On top of that, cc65 doesn't have the ability to produce an Intel Hex file. it only produces flat binaries, or o65 files, and I don't want to have to deal with either of those options.

My filesystem will be quite simple, and certainly not the best, but I think it will get the job done.

It's a pity cc65 has a bit of a barrier to entry - of course it's not the answer to everything, but it is a serviceable C compiler. I've tended to use it only as an assembler, with a target=none option. See this previous post:


You can convert binary to intel or motorola records using srec, if you're comfortable with the command line. See for example this post. My simple makefiles or build scripts often have an srec_cat conversion step.

I seem to recall that when I built EhBASIC from its ca65 sources, I needed to split it up into parts before I converted it, because it didn't leave gaps in the bin file to enforce the addresses.
I don't know the full extent of make's powers, but unless it's possible to have it scan a file for addresses and split on that... Wait a minute... I could probably grep the sources or the list file, especially if I use distinctive labels...
I'll have to try that now.

I sometimes use dd and xxd to cut and paste files, including in scripts and makefiles. But probably the thing here is to get cc65 to output the data in a more convenient organisation. If possible!