Yeah. I looking for a second 134 to play with that. But AFAIK the SIB is limited to eight participants.

As a backup in case the multi-processor thing doesn't pan out, I have a backup chip that might be more authentic in its capabilities. The only problem is that the bus speed is limited to 20 Mhz at a minimum. What would be the best way to get around this? Would it be possible to overclock the W65C265S 2Mhz and then use a clock doubler, or is it even possible to use this chip at all? I may go back to the EVE chip, but the problem with that one is that it uses two separate QSPI lanes for controlling the chip and moving data. With the Epson chip I'd have DMA and in general would be easier for me to figure out how to connect it up. My only interest in the Microcontroller was just to reduce the amount of chips and connections needed to make a machine.

Datasheet: https://vdc.epson.com/display-controllers/hardware-specification-rev-1-92/viewdocument

I think that bus interface is only 20MHz minimum if it's a clocked interface. See p38 for a whole slew of different configurations.

If you go to the EVE, I don't think you'll need two QSPI interfaces going between your computer and the GPU.
If I understand how the EVE series works, the second QSPI interface is for a flash chip, on which you can store things like fonts, images and sounds. You might be able to use a plain SPI interface for control if you want, instead of QSPI; it seems to support that.
I would imagine that both can be constructed from standard logic ICs. A QSPI master might be simpler than a standard SPI one.

Sure, for assorted values of "authentic".

20-50Mhz, 16 alpha blended, with arbitrary rotation, reversible, full 24bit color sprites up to 1280x1280.

Sure is nice to have some horsepower.

It's a 256 pin chip, and has a 16b data bus. The Atari Technical Reference manual (which used to be a 3 hole punched, 2+ inch ream of paper) isn't as big as the spec sheet for this thing.

I mean, it's really a gorgeous chip, but, kind of a square peg/round hole to cram in it in to 8 bit system.

With a casual google, Mouser sells them, but only in blocks of 24, with a minimum qty of 480. Dunno if you've found a better source for it.

As an aside, this is designed for LCDs, I wonder what it would take to be able to let it drive a "normal" video interface.

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

There is provision for more I/O and pins. CS0B has 32 bytes; that's room for 2 6522s or 8 6521s or mix and match. CS1B has 64 bytes. That's room for 4 6522s or mix and match 6521s and 6522s. There's a couple of areas in CS2B that are "reserved" but with decoding could be mapped to I/O registers of chip of choice. Here's an idea: map additional 65c265s to CS0B or CS1B using PIB; 4 @ CS0B and/or 8 @ CS1B.

There's provision for more priority encoded IRQs (again, reserved) : $FF00-$FF7F.

Cheers,
Andy

Yea, adding external memory is "expensive" in how much of the chips feature set is lost because of it.

Enabling external memory instantly consumes 4(!!) of the I/O ports. If you could make it only consume 3 so you can only address 64K of RAM, that would be a bonus.

Having the internal ROM be programmable (especially from a "dead" chip, so you can't brick it) would be a boon, I think.

Put 32K of RAM on it as well, and then you're cooking with gas for a lot of folks.

The point in the beginning wasn't for it to really be an 8Bit machine. That sort of just sprung up when my partner suggested the multiprocessor thing, but I think he's given up on that. Mostly due to thinking what the point is rather than having the ability to do it. Trust me, he could have if he wanted to.

In my head it was meant more to be a 16Bit machine that could 8Bit stuff if I "wanted to." I wanted to play in either arena without working on multiple machines. Also they make two version of the chip for some reason. One is for general use and one is for automotive. Supposedly the automotive one is the stronger chip in terms of tacking a hit. The other one is the S1D13513, and it can be found on mouse individually for about $20 a pop. Not cheap, but it actually has built-in sprite functions and specifically mentions game capabilities in the datasheet, unlike the EVE chip.

Actually it would bring things much closer to my original idea, which was something more like a 65816 Amiga type machine because it has built in blitting functions. Sure it's powerful for something "16 Bit", but it's not anywhere near as powerful as some of the early 32 Bit stuff that supported polygons.

Mouser Link

I think the reason the Epson part's 16-bit data bus was brought up is because both the '816 and the '265 have an 8-bit data bus. This is not insurmountable, but it is awkward.

I had thought I read it would run in an 8Bit data mode with a lower BPP (or something like that), but it looks like I was mistaken. My only real issue with the BT816 is that I'd like the ability to have some graphics/sound/text data stored in a NOR permanently on the main board, but I'd like to pull data from an external SD card occasionally as I toy with it. I don't see how that would be possible with it.

As for the ability to use these chips outside of a TFT screen, I basically have two options. I can either use the expensive $13 or so DAC I found or increase the amount of circuitry at a lower cost by using the the display conversion circuit I'll link below.

TFT to VGA DAC


TFT Converter Circuit

I think you'd have to read the data from the SD card into main memory, possibly in chunks, and then feed that into the GPU's memory. It would seem reasonable to be able to upload data to the GPU over the host interface, although I've had no experience with it, so I can't say if it's possible for certain.

You could run the SD card from the SPI interface I assume you'd build into your device, assuming you can comprehend the protocol. That is how the Arduino library does it, but I've not been able to comprehend the protocol well enough to attempt to replicate it. I'd suggest using an Arduino-programmed microcontroller(so you can take advantage of the SD library) or a CH376, unless you really want to build a FAT and SD implementation.
If you do use a CH376, you can also read a USB stick. The official documentation for that device is quite bad, though. I'm working on de-chinglish-ing the datasheet, but I might never finish it, knowing how a few other things I've talked about have gone...

From the response email Bridgetek sent me:



For a first version I'll just use DIP Switches to sort between a NOR flash and an SD card just in case they just meant that it can only send commands.

The good news is I won't need a DAC since I'm using the Bridgetek chip with an AY-3-8910 if I decide to use samples. The Bridgetek can play a single ADPCM/Wave sound at a time and the PSG can be manipulated into playing samples as well.

I finally found the time to figuring out more exactly what hardware I want to put into the design.
I put together a block diagram to give a loose idea of what I'm looking to do.
Tell me what y'all think. Keep in mind that the diagram is still a work in progress.

I'm trying to figure out how to use one of the UARTs to send Midi data to the synthesizer chip I'm using. Does anyone know where I can find resources on how to do it on the microcontroller?