New to SBC projects

[BigDumbDinosaur]

GARTHWILSON wrote:

I would still like to find the '521 and '138 in ABT, if anyone knows a source.

I don't believe there's an ABT version of either part.

[BigEd]

GARTHWILSON wrote:

If you do that with (E)EPROM though, you'll have to make a programming adapter to mix them around such that the (E)EPROM will get read properly when put in the target system.

I think things are easier these days. Daryl confirms that a suitable modern EEPROM can be programmed in-system. For example, this $5 Atmel 8K EEPROM has a single 5v supply and an internal write buffer. Check Daryl's schematics: it's the same pinout as an SRAM, you just use \WE to write it (a jumper is convenient)

So, you still need to get some kind of code running, but you can update it on the fly. Daryl kindly offered to program-by-post, or you could single-step a small bootstrap.

[8BIT]

BigEd wrote:

Daryl confirms that a suitable modern EEPROM can be programmed in-system. For example, this $5 Atmel 8K EEPROM has a single 5v supply and an internal write buffer. Check Daryl's schematics: it's the same pinout as an SRAM, you just use \WE to write it (a jumper is convenient)

The one thing I discovered was that you need to have the routine that does the writing located in RAM, as any attempt to read the EEPROM during a write cycle returns the wrong data (by design). If you try to execute a program in EEPROM during a write (even to another location in EEPROM), your program will become corrupt and the result is usually not desireable!

The datasheet explains this under the "detecting the end of the write cycle using data polling" section. As I recall, data bit 7 is inverted during a read access while a write cycle is in progress. This affects every address location. You write a data byte, then read it back and compare the result. If they match, the write cycle is complete, otherwise keep reading it until it does match. There are also page mode writes, but the end of cycle detection still applies.

Daryl

[ChuckT]

I think the mimimig (mini Amiga) uses an FPGA to generate video through a discrete resistor DAC.

I found it was a little involved to generate video so I looked to third party solutions and wondered what everyone thought about using these products with a 65C02 or 65c816 SBC.

http://www.sparkfun.com/commerce/produc ... ts_id=8541
http://www.sparkfun.com/commerce/produc ... ts_id=8540

Here is a video on Youtube:
http://www.youtube.com/watch?v=zNLXGV1f5PQ

The specs are here (click on features):
http://www.4dsystems.com.au/prod.php?id=15

http://www.4dsystems.com.au/
http://tinyvga.com/
http://www.microvga.com

I was reading about the Beagle Board and heard that people were using Adruino to interface with it. It is essentially a computer but on the other hand, it could be a video card for the 65C816. With its memory card slot, it could hold libraries of advanced routines and I read that the VGA-Picaso MD1 can store up to 2 Gigabytes worth of icons and graphics.

720p Video on OMAP3 Beagle Board running Android by Ingenient

http://www.youtube.com/watch?v=BdnDpH3543Q

I possibly want to go forward with ordering a 65C02 or several 65C816 this summer.

[kc5tja]

I'm not sure why an FPGA would be difficult for video generation. You have to get your timing signals right, and that's usually the toughest part of it all, but otherwise, it should be quite simple to get something working.

I was able to get about four cores of the Intellasys S24-thumbdrive unit to generate stable (monochrome, since it only had two DACs I could use) 640x480 VGA resolution right to an analog VGA monitor. It took about 24 man hours to get working.

I can't imagine why it'd take getting an FPGA working with a basic video interface any longer than this.

ALSO, note that the Amiga's video hardware is not for the feint of heart anyway. Unless you have experience coding for the Atari 800 series of computers, its video architecture will not be obvious to you. You have a rather large number of DMA channels to set up for the video bitplane pointers, a number of DMA channels for the blitter, a number of DMA channels for the sprites, and then you need interrupts enabled so you can reset the bitplane pointers on each VSYNC. (Not updating these pointers is one of the tricks that Amiga software used to pull off 60fps animation back when the CPU only ran at 7MHz.)

However, the Amiga's video hardware is doggone SIMPLE compared to the configuration needed to get a VGA chipset initialized correctly.

Still, nothing would prevent the implementation of something simpler to use, like perhaps a subset of the TI VDU chip, the Commodore 64's VIC-II chip, or even the C128's VDC chip.

[Nightmaretony]

http://elm-chan.org/works/crtc/report.html

CPLD video display controller.

The FPGA needs the data bootstrapped into it, hence the Arduino or AVR tyhpe. This one, not so much....

[kc5tja]

You can just use a serial EEPROM to bootstrap the FPGA too. Also, I believe there are EEPROM-based FPGAs on the market too, though they're not nearly as popular as the RAM-based units. (And, I presume, a lot more expensive too.)

Still, you can pack a lot more functionality in an FPGA than you can a CPLD, which allows you to have a VIC-class video interface. With a CPLD, you're either going to end up with an Apple-II type display interface (some would say it's too simple to be useful) or an Amiga/Atari-type display (which relies on periodic software intervention to keep the unit working properly).

[Nightmaretony]

The Chan is asynchronous in design but is a simple bit map. Sprites possibly CAN be done with a CPLD, through clever logic design. I like it due to its simplicity all around.

The FPGA requires the bootstrap every wakeup, plain and simple. I didnt know that there were eeprom serial load types, how popular are they and are they easy to get and all?

the Xilinx 9500 series equations would work across their platforms bigtime and if you depend o a serial eeprom load, how portable if that part goes obsolete and you have to redesign with a cpu loader type of fpga?

[kc5tja]

Nightmaretony wrote:

The FPGA requires the bootstrap every wakeup, plain and simple.

For the RAM-based ones, yes. Not for the EEPROM-backed units.

NOTE: EEPROM-backed FPGAs are not the same thing as RAM-backed FPGAs bootstrapped from an external EEPROM unit. Do not get these two confused!!!

Quote:

I didnt know that there were eeprom serial load types, how popular are they and are they easy to get and all?

Every single FPGA ever manufactured, starting with Xilinx's very first, can be programmed from an external memory without microprocessor intervention. In fact, FPGAs are one of the market-driving factors for the success and inexpense of serial EEPROMs today.

Quote:

Xilinx 9500 series equations would work across their platforms bigtime and if you depend o a serial eeprom load, how portable if that part goes obsolete and you have to redesign with a cpu loader type of fpga?

You'd probably have to supply a new EEPROM, but this is completely normal. Equations may be portable, but this is a property of the language used to code the chip, not the chip itself. The programmer format will differ quite wildly from model to model, even within the same family. Equations are compiled by a synthesis tool, which must be instructed on which specific part you're programming.

[Nightmaretony]

ah, so defintiely pmore portable than I assumed there. Kick me in the port a mind out here....

[OwenS]

Nightmaretony wrote:

the Xilinx 9500 series equations would work across their platforms bigtime and if you depend o a serial eeprom load, how portable if that part goes obsolete and you have to redesign with a cpu loader type of fpga?

As per kc5jta, pretty much every FPGA can boot from standard SPI eeproms provided they're big enough. It's not the fastest boot - for that you need to hook up either a parallel EEPROM (Very fastest) or something like an Xilinx Platform Flash (Second fastest, but serial, so easier to route, and also JTAG prorgammable like the FPGA)

And, besides, if you have to redesign with a different FPGA, it's probably a reroute anyway.

[BigEd]

Quick question, if you're in the know: how long does it take before the fpga is functional? A few tens of milliseconds, or a few seconds?

(Presumably it's linear, so a million-gate FPGA would take 5x longer than a 200k gate one)

[OwenS]

BigEd wrote:

Quick question, if you're in the know: how long does it take before the fpga is functional? A few tens of milliseconds, or a few seconds?

(Presumably it's linear, so a million-gate FPGA would take 5x longer than a 200k gate one)

A few miliseconds normally. Only time I've seen seconds is with a slow MCU driven bootstrapper for one.

Generally, the way to work around the startup time is to have the FPGA control the reset lines of the rest of the system

[BigEd]

great - thanks!

[GARTHWILSON]

Quote:

As per kc5jta, pretty much every FPGA can boot from standard SPI eeproms provided they're big enough. It's not the fastest boot

I don't know if the FPGA would run the SPI memory (probably flash) at its speed limit, but I've seen ones that would do 50Mbps. That's about 50 times as fast as I²C EEPROMs.