Contemporany 6502 compatible hardware (chips, actually).

[Agumander]

The block-move feature of the VLSI chip is very interesting. It's basically what I've approximated with the massive 74HC-based copy controller card on my game console project, not to mention the similarly-sized composite signal generator card that attaches to it...

How available are those Yamaha chips, though? Are they being made today? I can't seem to find a store page for them. If the VLSI chip can shrink the video part of my system, the audio synth part would be the next thing to miniaturize.

[tokafondo]

Agumander wrote:

The block-move feature of the VLSI chip is very interesting. It's basically what I've approximated with the massive 74HC-based copy controller card on my game console project, not to mention the similarly-sized composite signal generator card that attaches to it...

Some of the EPSON chips does also include a BitBLT engine and some of them an sprite engine. But sadly, the sprite engine only work with a 16 bit data bus... Too much to handle: everything should be made with twice or three times the instructions.

Agumander wrote:

How available are those Yamaha chips, though? Are they being made today? I can't seem to find a store page for them. If the VLSI chip can shrink the video part of my system, the audio synth part would be the next thing to miniaturize.

There is a development board for the YMF825 chip: https://international.switch-science.com/catalog/3399/

And this is how it sounds: https://www.youtube.com/watch?v=D1ZzOOMt9sk

[rpiguy2]

Bridgetek makes a cheap ($4.50) video chip with 18-bit RGB out and a built in frame buffer. It is SPI only thought.

Any good threads or tutorials on hooking up SPI peripherals to a 65xx system?

[Agumander]

rpiguy2 wrote:

Any good threads or tutorials on hooking up SPI peripherals to a 65xx system?

Garth's primer has some writeup on using the 6522 for SPI. Given that most display controllers seem to be oriented towards SPI, and even the VLSI chip requires it for controlling the Display Controller, I might just have to do this on my board as well.

tokafondo wrote:

There is a development board for the YMF825 chip: https://international.switch-science.com/catalog/3399/

And this is how it sounds: https://www.youtube.com/watch?v=D1ZzOOMt9sk

That is some nice sound output. If I can source the chip by itself to put on a PCB it might be a compelling choice.
Another idea that occurs to me is that audio computation can be done a lot more slowly than video, so replacing my jelly-bean logic square wave generators with a second 6502 and a DAC is an option.

[Dr Jefyll]

tokafondo wrote:

But sadly, the sprite engine only work with a 16 bit data bus.

If you feel sprites are highly valuable then remember: at a cost of 3 or 4 extra 74xx chips, you could connect the 16-bit EPSON chip to a 65xx machine (eg: '02, 'C02 or '816. One approach is to design around a 74xx646 registered transceiver (a 20th-century chip, BTW). Or, if you can get by with 8-bit reads, and only writes need to be 16-bit, then 8 of the bits could be taken from CPU address lines A7-A0 via a tristate buffer. You'd have a memory map that grants 256 bytes to every register in the video chip, and STA $6900, X (for example) would simultaneously output A and X.

Oops, did someone mention 6522? That's another way to get an extra 8 bits (or all 16 of the bits), and in this case they could both read and write.

-- Jeff

[rpiguy2]

Agumander wrote:

rpiguy2 wrote:

Any good threads or tutorials on hooking up SPI peripherals to a 65xx system?

Garth's primer has some writeup on using the 6522 for SPI. Given that most display controllers seem to be oriented towards SPI, and even the VLSI chip requires it for controlling the Display Controller, I might just have to do this on my board as well.

You'd think I'd be conditioned to look there first before asking by now, lol

[tokafondo]

Dr Jefyll wrote:

tokafondo wrote:

But sadly, the sprite engine only work with a 16 bit data bus.

If you feel sprites are highly valuable then remember: at a cost of 3 or 4 extra 74xx chips, you could connect the 16-bit EPSON chip to a 65xx machine (eg: '02, 'C02 or '816. One approach is to design around a 74xx646 registered transceiver (a 20th-century chip, BTW). Or, if you can get by with 8-bit reads, and only writes need to be 16-bit, then 8 of the bits could be taken from CPU address lines A7-A0 via a tristate buffer. You'd have a memory map that grants 256 bytes to every register in the video chip, and STA $6900, X (for example) would simultaneously output A and X.

Oops, did someone mention 6522? That's another way to get an extra 8 bits (or all 16 of the bits), and in this case they could both read and write.

-- Jeff

So, for every word of data the video chip would need, there whould be two write instructions, wouldn't it? If that is the case, would it match the timing needed by the chip?

[Dr Jefyll]

tokafondo wrote:

So, for every word of data the video chip would need, there whould be two write instructions, wouldn't it?

It depends what method you choose. But yes, with most of the methods the 65xx would do two write instructions. Only the STA $6900,X idea uses only one write.

Quote:

If that is the case, would it match the timing needed by the chip?

Well, yeah -- with unlimited effort, you can match the timing of almost anything. But of course you want a plan that's reasonable for your needs.

If you're seriously interested, then show us a datasheet for this EPSON chip with the sprites. Then we can decide how hard or easy things will be.

[tokafondo]

Dr Jefyll wrote:

tokafondo wrote:

So, for every word of data the video chip would need, there whould be two write instructions, wouldn't it?

It depends what method you choose. But yes, with most of the methods the 65xx would do two write instructions. Only the STA $6900,X idea uses only one write.

Quote:

If that is the case, would it match the timing needed by the chip?

Well, yeah -- with unlimited effort, you can match the timing of almost anything. But of course you want a plan that's reasonable for your needs.

If you're seriously interested, then show us a datasheet for this EPSON chip with the sprites. Then we can decide how hard or easy things will be.

Please, take a look.

You would be also taking a peek at the "Data formats" section, because I understood from there that for every pixel shown, a lot of writes should me made...

I chose the S1D13781 for my project, btw...

[Dr Jefyll]

tokafondo wrote:

Please, take a look.

• "The S1D13513 is a highly integrated Display Controller capable of outputting to LCD or
  TV. With the flexibility of an external SDRAM memory interface, this low cost, low
  power, device supports a wide range of CPUs [...]
  The S1D13513 features both Sprite and 2D BitBLT engines designed to reduce the load on
  the Host, while increasing the performance of graphics intensive operations. Additionally,
  the S1D13513 offers such features as multiple windows, alpha blending, gamma
  correction, and mirror/rotation function which allow user configurability of various images
  on the Main/PIP1/PIP2 displays. [...]
  • IO operates at 3.3 volts ± 0.3V
  • Core operates at 1.8 volts ± 0.15V"

Wow, quite the chip! And these are only some of the features. But AIUI you'll need to attach it to external SDRAM, so it's NOT a self-contained solution. Notice, too, the requirement for two power supplies.

I think a 65xx CPU plus a 74xx646 etc etc could be made to work with this chip (despite its 16-bit bus) but I haven't taken a close look because that's only one piece of the puzzle. In order to use this chip, somebody will need to make a pretty big commitment. If there's someone who truly is serious then I'd be willing to offer further advice.

Quote:

You would be also taking a peek at the "Data formats" section, because I understood from there that for every pixel shown, a lot of writes should me made...

I haven't time to take a peek now, but let's just say performance is more likely to be satisfactory if the host CPU is fast. '816 will be a better choice than '02 or 'C02.

Quote:

I chose the S1D13781 for my project, btw...

• "The S1D13781 is a simple LCD controller with an embedded 384K byte display buffer. The S1D13781 supports both 8/16-bit direct/indirect CPU interfaces and a SPI CPU interface."

OK, this one's a LOT more manageable. On-chip display buffer, and choice or 8-bit, 16-bit or SPI interface... But I didn't see any mention of sprites.

Would you like to tell us about your project? If it's 65xx-related, then you can post here. Otherwise, consider posting on our sister forum, anycpu.org.

-- Jeff

[tokafondo]

Dr Jefyll wrote:

Wow, quite the chip! And these are only some of the features. But AIUI you'll need to attach it to external SDRAM, so it's NOT a self-contained solution. Notice, too, the requirement for two power supplies.

And maybe you haven't seen the Yamaha graphics offerings... Want >300 sprites on screen, with 128 sprite per line support?

EPSON does also have the S1D13506 chip, that's still on production but being phased out. If needs external EDO or FP RAM, and features a two layer design with a somewhat advanced BitBLT engine. But can only be managed with a 16 bit wide data bus.

Dr Jefyll wrote:

OK, this one's a LOT more manageable. On-chip display buffer, and choice or 8-bit, 16-bit or SPI interface... But I didn't see any mention of sprites.

Nope, no sprites at all, but the integrated, directly addressable VRAM, BitBLT engine and 2 layers with interesting effects like Alpha Blending and transparency, makes it a nice chip for software rendered sprites, doesn't it?

Dr Jefyll wrote:

Would you like to tell us about your project? If it's 65xx-related, then you can post here. Otherwise, consider posting on our sister forum, anycpu.org.

-- Jeff

I posted about my project in the Newbies forum. But as I'm still waiting for parts, I've not been able to advance further, so my efforts are now on research and learn.

[rpiguy2]

tokafondo wrote:

Dr Jefyll wrote:

Wow, quite the chip! And these are only some of the features. But AIUI you'll need to attach it to external SDRAM, so it's NOT a self-contained solution. Notice, too, the requirement for two power supplies.

Nope, no sprites at all, but the integrated, directly addressable VRAM, BitBLT engine and 2 layers with interesting effects like Alpha Blending and transparency, makes it a nice chip for software rendered sprites, doesn't it?

I posted about my project in the Newbies forum. But as I'm still waiting for parts, I've not been able to advance further, so my efforts are now on research and learn.

What kind of video output are you looking to provide?

I am not sure if you noticed but the video out is designed specifically to drive an LCD panel, so there isn’t one pin for R, one pin for G, and one pin for B. If you are running in 24 bit color you use 24 pins (8:8:8) plus 1 for hsync, 1 for vsync, and would likely have to run the 24 bits through a DAC to get a video signal. I did not see a DAC anywhere in the on-chip block diagrams.

Color depth determines how many pins are used, so if you intend to support multiple color depths then whatever output hardware you bolt on to this it will need to be able to work with the different pin out configurations for each color depth.

I also looked at the Yamaha chips and only one has analog RGB out, but it requires a 16-bit interface to the CPU.

[tokafondo]

rpiguy2 wrote:

tokafondo wrote:

Dr Jefyll wrote:

Wow, quite the chip! And these are only some of the features. But AIUI you'll need to attach it to external SDRAM, so it's NOT a self-contained solution. Notice, too, the requirement for two power supplies.

Nope, no sprites at all, but the integrated, directly addressable VRAM, BitBLT engine and 2 layers with interesting effects like Alpha Blending and transparency, makes it a nice chip for software rendered sprites, doesn't it?

I posted about my project in the Newbies forum. But as I'm still waiting for parts, I've not been able to advance further, so my efforts are now on research and learn.

What kind of video output are you looking to provide?

I am not sure if you noticed but the video out is designed specifically to drive an LCD panel, so there isn’t one pin for R, one pin for G, and one pin for B. If you are running in 24 bit color you use 24 pins (8:8:8) plus 1 for hsync, 1 for vsync, and would likely have to run the 24 bits through a DAC to get a video signal. I did not see a DAC anywhere in the on-chip block diagrams.

Color depth determines how many pins are used, so if you intend to support multiple color depths then whatever output hardware you bolt on to this it will need to be able to work with the different pin out configurations for each color depth.

Well... If you didn't went to the post where I describe the project, I'll tell you. It's a portable gaming console, gameboy advance style. I first decided to create yet another sbc that will end in a drawer, so I changed the focus to something that many people would actually want to use: a portable gaming console.

And I believe that many experienced programmers would want to create games for it, because of the fetures of the EPSON chip I chose: not hardware sprites but enough hardware features to make easy to render them by software, and have fast scroll by just changing registers in the graphic chip, it taking care of the rest.

[rpiguy2]

tokafondo wrote:

rpiguy2 wrote:

tokafondo wrote:

Dr Jefyll wrote:

Wow, quite the chip! And these are only some of the features. But AIUI you'll need to attach it to external SDRAM, so it's NOT a self-contained solution. Notice, too, the requirement for two power supplies.

Nope, no sprites at all, but the integrated, directly addressable VRAM, BitBLT engine and 2 layers with interesting effects like Alpha Blending and transparency, makes it a nice chip for software rendered sprites, doesn't it?

I posted about my project in the Newbies forum. But as I'm still waiting for parts, I've not been able to advance further, so my efforts are now on research and learn.

What kind of video output are you looking to provide?

I am not sure if you noticed but the video out is designed specifically to drive an LCD panel, so there isn’t one pin for R, one pin for G, and one pin for B. If you are running in 24 bit color you use 24 pins (8:8:8) plus 1 for hsync, 1 for vsync, and would likely have to run the 24 bits through a DAC to get a video signal. I did not see a DAC anywhere in the on-chip block diagrams.

Color depth determines how many pins are used, so if you intend to support multiple color depths then whatever output hardware you bolt on to this it will need to be able to work with the different pin out configurations for each color depth.

Well... If you didn't went to the post where I describe the project, I'll tell you. It's a portable gaming console, gameboy advance style. I first decided to create yet another sbc that will end in a drawer, so I changed the focus to something that many people would actually want to use: a portable gaming console.

And I believe that many experienced programmers would want to create games for it, because of the fetures of the EPSON chip I chose: not hardware sprites but enough hardware features to make easy to render them by software, and have fast scroll by just changing registers in the graphic chip, it taking care of the rest.

A hand-held? Cool. Physical design will then be as important or more important than electrical. How the LCD mounts to the PCB, can the PCB safely be held or does it need a case, will it have a hinge, how will you wire up the controller buttons, building a battery pack, etc. Fun challenge!

[Dr Jefyll]

tokafondo wrote:

EPSON does also have the S1D13506 chip, that's still on production but being phased out. If needs external EDO or FP RAM, and features a two layer design with a somewhat advanced BitBLT engine. But can only be managed with a 16 bit wide data bus.

Well, here's an outline of what I had in mind for connecting to a device with 16 bit wide data bus, and I suspect it'll work for almost any chip, including S1D13506. It's just a question of whether you consider the extra logic to be justified by the benefit the S1D13506 (or other chip) provides.

The elements I've shown could be built as

• a pair of 74xx646 registered transceivers (two 24-pin chips), or
• two each of 574 and 541 (four 20-pin chips), or
• a PLD could hold them.

There will also need to be some glue to wiggle the various control lines. The details aren't immensely intricate.

Interface to 16-bit device .png (7.64 KiB) Viewed 1665 times

Here's the behavior I had in mind. For performance reasons, I chose to exploit the '816 or '265's ability to generate both bus cycles with a single instruction (ie, with the m bit in the P register =0).

• Read:
  cycle 1: 16 bit read of IO device. Lobyte straight to 65xx bus; Hibyte to temp reg.
  cycle 2: temp reg (the stored Hibyte) to 65xx bus.
  
  Write:
  cycle 1: 65xx bus (the Lobyte) to temp reg.
  cycle 2: Temp reg to IO device. 65xx bus (the Hibyte) to IO device. 16 bit write to IO device.

In your code you'll need to stick to simple loads and stores such as LDA BIT STA STY etc. Instructions like that always deal with the lowbyte first. But R-M-W instructions (INC DEC etc) are a no-no -- a minor limitation to keep in mind. The write portion of a R-M-W instruction will deal with the high byte first (according to WDC's '816 datasheet) and thus won't work as expected with this circuit.

-- Jeff