SBC-3. Current status

[Gapter]

No news since june... Daryl, can You publish news every month, pleeeease.

[8BIT]

SBC-3 has actually taken two directions:

1) if you are following the "Turnkey get-started-fast solution" discussion under the general topics section, that has not made it to the drawing board completely.

2) if you are waiting for the 65816 + 512k RAM + Video + ethernet + FLASH Storage SBC, then here's an update:

Unfortunately, SBC-3 has not seen any progress. Work and family have taken all of my time. I'm hoping to get more free time in a few months and will be working on it then.

I'll post an update around Thanksgiving time (end of Nov).

As a recap, SBC-3 will have 512k of RAM with 32k of boot ROM (which gets copied into RAM during /Reset). it will use the 65816 and have built-in color video (I'm still trying to iron this spec out), PC keyboard decoder (completed), either CF or SD flash storage (50% done), and 10MB ethernet (60% done).

It will have two 65C22's for GP I/O and will use at least one CPLD to glue it all together.

Clock speed will depend mostly upon the video, somewhere between 8MHz and 12MHz.

As you can imagine, this is a huge expansion over SBC-2 and will take time to perfect.

thanks for your interest and patience!

Daryl

[8BIT]

I've updated my website with details about my new SBC-3 core.

Check it out here:
http://sbc.rictor.org/sbc31/info.html

Daryl

[smilingphoenix]

It's looking good. One question, will you be adding PAL capabilities to the CPLD for us europeans? I know the AD724 can do either with just a change of the oscilator frequency and a jumper on the mode select pin.

[8BIT]

PAL should not be an issue. However, since I'm using over 90% of the CPLD's resources, I'll have to actually re-program the timing and test it before I say Yes. Good thing I still have a multi-system TV.

[8BIT]

The PAL timing changes were compiled successfully. I was able to see a steady picture (correct horizontal and vertical timing). The color was not right because I have the 14.318MHz clock feeding the AD724. As long as the analog section works as the datasheet describes, PAL is a go!

Daryl

[Lost]

I'm not proposing you change your design in the least. I'm just wondering if it would be reasonable to use a 65c02 for the video processor instead of the CPLD?

I'm asking partly from inexperience and partly because it strikes me as an interesting project to try. Also, it would save me from having to learn how to program the CPLD if I get far enough along to try something like you've done.

[8BIT]

The video system provides the pixel data at 8MHz. Even if you over-clock the 65C02 to 16MHz, you can't read RAM in two cycles.

You could use a 65C02 to control external counters and latches. You can look at my first video generation experiment here:
http://sbc.rictor.org/download/video.zip

If I were to suggest a non-CPLD approach, it would be to use standard CMOS logic. (74HC series)

Video generation is very straight forward.

Code: Select all

For NTSC, you need:
  a horizontal pixel counter - 0 to 909 (for a 14.318 MHz clock)
                               0 - 454 (for a 7.159 MHz clock)
  a vertical line counter - 0 to 262 
  a video memory counter - 0 to 64000, plus 3 bit block register
  decoder logic for active video, horizontal sync, and vertical sync
  CPU address and data bus multiplexers
  a master clock (14.318MHz)

This would require 10-20 IC's (just a wild guess here) but could be done.

Using the CPLD, I was able to put all of that into one chip, plus a few extra features.

I am considering supporting pre-programmed CPLD's, kits, or assembled units. However, that is still some time away.

Daryl

[8BIT]

Now that I have the RS-232 working, I have installed my SBC-2 monitor and have been playing with the graphics.

I wrote a program on my PC to convert a 320x200 BMP to a raw binary file. I then uploaded to my SBC-3 core and this is the result.

I call it, "SBC-3 - A Self Portrait"

6502.org wrote:

Image no longer available: http://i10.tinypic.com/71pgirs.jpg

This picture is the image on my TV captured with my digital camera.

Daryl

[BitWise]

Does the CPLD support hardware screen scrolling (e.g. can you move the base address of the video RAM and have the address wrap round) or will you have to block move the RAM?

[8BIT]

Right now, it is fixed at $0000 of the current block. I'm not sure there are enough resources to add two more 8 bit registers to hold the entire base address. During refresh, it just increments an 18 bit counter. That could be changed to 16 bits so the address would wrap.

I will add that to the wish list for future testing. I also discovered that my timing with the 16 MHz clock was causing dot crawl on the screen. I switched back to the 14.318 MHz clock (7.159 MHz PHI2), and the picture is solid. I want to play with the timing at 16 MHz more to see if I can eliminate the dot crawl.

Next will be font generation and text formatting.

Daryl

[faybs]

Having the ability to move the base of the screen also allows for double buffering, so I'm going to add my vote here for that feature. Come to think of it, a vblank interrupt would be needed too - although that could be just the AD724's vsync signal routed through a 6522. Actually, if you also route the hsync signal through the 6522 and use T2's pulse counting mode, you can implement arbitrary raster interrupts.

[8BIT]

It already has double buffering, if understand the term correctly.
Location $0240 has a register that selects which 64k block is being displayed. You can write a new screen to any block. Once you fill the new block, you can immediately write that block # to $0240 and it will automatically switch during the next vertical sync period.

Also, bit 7 of $0240 contains the vertical sync flag, which could be polled. Right now, I don't have any extra pins avail output an interrupt. By using an external sync seperator IC, you could provide Vert. Sync interrupt.

Hope that helps

Daryl

[faybs]

8BIT wrote:

It already has double buffering, if understand the term correctly.
Location $0240 has a register that selects which 64k block is being displayed. You can write a new screen to any block. Once you fill the new block, you can immediately write that block # to $0240 and it will automatically switch during the next vertical sync period.

Yes, that will do quite nicely. I like the fact that vsync waiting is handled automatically.

8BIT wrote:

Also, bit 7 of $0240 contains the vertical sync flag, which could be polled.

Polling for vsync? yuck

When does that bit get cleared?

8BIT wrote:

Right now, I don't have any extra pins avail output an interrupt. By using an external sync seperator IC, you could provide Vert. Sync interrupt.

Don't you need to provide sync pulses to the NTSC modulator IC? or are you sending it composite sync instead of separated hsync and vsync?

[kc5tja]

The Kestrel's proposed chipset will make use of a raster-compare interrupt instead of a vertical sync interrupt. It's more flexible timing-wise, because you can get multiple interrupts per frame. This can be used for updating color palettes, altering scroll registers, etc. The MGIA concept I have doesn't support color or scrolling, so it is of limited use. Still, I like to keep my options open.

That being said, MGIA only exists in a purely software emulated environment.

Depending on the room you have in the CPLD, you may want to use a raster line compare interrupt instead of a plain-vanilla vertical retrace interrupt.

Just an idea.