My project with a w65c265s MCU.

[tokafondo]

Hi all. First post, so some sort of introduction first.

I'm Claudio Sánchez, known in many places as Tokafondo. I've been always a fan of the Commodore computers. I had a C64 as a teenager and I'm in the process of having another one working. Due to the restrictions imposed during this covid-19 crisis, I've not been able to fix it.

During that time, I have been following several projects of DIY computers, and I have learnt a lot of Ben Eater videos so, with no knowledge at all, I will try to make my own. I have no fear of electronics and of failing so there it goes.

I will try to get a w65c265s MCU to work, expanded with memory and a VGA display. I'm aiming at 8 mhz here, the top of what the MCU can run.

Why the '265? because it has several peripherials and interfaces included that usually are available as separated modules, but the most important thing for me is that the full 24 bit address is available with no decoding or demultiplexing needed.

As a VGA output, I will try to build a higher resultion version of Ben Eater's "Worst video card ever", aiming at a 800x600 @60hz signal with 400x300 resolution with 64 colors, maybe with 4 levels of luminance, in 8 bits: LLRRGGBB for every pixel.

Well, after reading some datasheets, and how the '265 works, my memory map would be like this:

Code: Select all

000000-00DFFF	(S)RAM   	57344 KB - standard RAM @55ns for registers, data and programs.
00E000-02DFFF	(EEP)ROM   131072 KB - kernel, rom characters and software that the user would want to be there at boot.
02E000-04DFFF	(S)RAM     131072 KB - FAST RAM @15ns that would be shared with the video output and other peripherials.
04E000-07FFFF	(S)RAM  	204800 KB - standard RAM @55ns for registers, data and programs.

As a 400x300x8 bits picture needs about some more than 117K to be displayed, the rest of the FAST memory up to 128K could be used for audio or other uses, shared by the MCU, the VGA circuit and any other chip that could read or write to it while the others are doing its things.

If I clock the computer with 40Mhz, and divide it by 2, I would get the 20Mhz needed to generate the 800x600 @60hz signal. And at the same time, divide it in parallel by 5, to get the 8 Mhz needed by the MCU. This would mean (as I understand) that the MCU would access the memory every 2.5 times the VIDEO circuit has done it. And I could use the 40 Mhz also to clock things like network interfaces, flash storage, audio chips...

Once all of this said: AM I IN THE RIGHT DIRECTION???

Thanks for comments.

EDIT: some typos

EDIT: It runs!!! Actually, I made the W65C265S run... (link)

[tokafondo]

(reserved)

[GARTHWILSON]

tokafondo wrote:

I will try to get a w65c265s MCU to work, expanded with memory and a VGA display. I'm aiming at 8 mhz here, the top of what the MCU can run.

I was talking with Bill Mensch (the designer) a few years ago over lunch, and he asked me why people were shying away from the '265 so much. I said the lower clock rate is a big factor, since it's rated for only 8MHz, slightly over half of what the '02 and '816 are. His reply was that it might go quite a lot faster, but they never tried it any faster. Why, I don't know. The '816 is rated for only 8MHz at 3.3V though, and forum member "Windfall" here got it going at 24MHz at 3.3V, which makes me wonder what it could do at 5V. So be ready to go ahead and try the '265 and see what it can do, and let us know!

[tokafondo]

Thanks for your answer.

Datasheet do show '265 absolutes max and min running 8mhz with 5V.

I almost bought the Mensch microcomputer but cancelled the order because the top 8 ports for direct addressing are not connected, and the p7 ports are connected to leds, so that for me was a drawback.

I asked Mr. Mensch about the clock and he and Mr. Gray told me that the internal ROM monitor would run fine up to 6.144Mhz, but not faster, but that with an external ROM there would be no problem at all.

[BigEd]

Welcome, Claudio! It will be interesting to follow your progress.

I'm sure your scheme can be made to work. I think a timing diagram - at least showing half-cycles, and perhaps a bit more detail - would be very useful, especially as you have this half-integer relationship between clocks.

[BitWise]

You can't normally have your ROM at $E000-$FFFF at startup as the internal ROM takes prescedence.

The datasheet suggests that by raising BE 100nS after RESB (tBR in table 3-4) you can start the processor in ICE mode with the external ROM enabled but I don't know that anyone has ever tried that.

If you can't start in ICE mode then the Mensch monitor checks for the string "WDC" at $8000 and $0800. If found it jumps to $8004 or $0804 which can then execute code that disables the internal ROM and reconfigures the system as needed, for example:

Code: Select all

                                             .code
                                             .org    $8000

00:8000  58585800          :                 .byte   "XXX",0                 ; WDC Signature (XXX until working)

00:8004  78                :                 sei                             ; Restore initial power on state
00:8005  D8                :                 cld
                                             emulate                         ; .. and return to 8-bit mode
00:8006  38                +                 sec
00:8007  FB                +                 xce

00:8008  A980              :                 lda     #$80                    ; Disable internal WDC ROM
00:800A  0C40DF            :                 tsb     BCR
00:800D  6CFCFF            :                 jmp     ($fffc)                 ; And simulate a reset

I bought some PLCC '265s intending build an 8MHz board but its still on my list of things to get around to.

I much prefer my WDC W65C265SXB board to the W65C816SXB. Its much more accessible even if it is a bit slower.

[BitWise]

If you want to use the generated chip selects then it might be better to have:

Code: Select all

00:0000-3f:ffff Page Zero and ROM (CS4B & CS5B)
40:0000-bf:ffff Normal RAM (CS6B)
c0:0000-ff:ffff Fast RAM (CS7B)

[BitWise]

Oh and the Coprocessor expansion area 00:DFC0-00:DFFF (CS1B) might make a good place to map video registers.

[tokafondo]

BitWise wrote:

You can't normally have your ROM at $E000-$FFFF at startup as the internal ROM takes prescedence.

The datasheet suggests that by raising BE 100nS after RESB (tBR in table 3-4) you can start the processor in ICE mode with the external ROM enabled but I don't know that anyone has ever tried that.

I read the '265 Monitor ROM guide. From page 17, it details the reset procedure and I think that the first thing it does is disabling all the internal ROM, RAMS and even ports, to look for an external address to boot from.

My thoughts on this memory map are:

• 000000-00DFFF (S)RAM 57344 KB
  RAM @55ns to be used just by the MCU, including zero page and On-Chip registers. No need of ROM here. The part I'm thinking here is the AS6C62256-55PCN, with 2 modules of 32K that would give 64K, wasting 8K... or not? read later.
• 00E000-02DFFF (EEP)ROM 131072 KB
  ROM to boot the MCU from, with enough room for a good kernel and more utilities that the user could install by using the very same machine, because the part I'm think about is the AS29CF010-55CCIN, that has the same read speed as the SRAM module, and can be programmed inside the machine, as it has 4 sectors of 32K each, that can be erased and reprogrammed independently of each other. A kind of FLASH storage area where the code could be read and executed from. Also, it could have the ROM character set.
• 02E000-04DFFF (S)RAM 131072 KB
  FAST RAM @15ns that would be shared with the video output and other peripherials. The part I chose is the 71256SA15TPG from IDT/Renesas. As said, it would have littel more of 10K or free RAM that could be used as I/O area with other chips in the computer.
• 04E000-07FFFF (S)RAM 204800 KB
  The continuation of the standard RAM for the computer, with no I/O to take care off, free to run code and data of programs.

Video. As said, I'm planning to have the video done by following Ben Eater's worst video card ever: a simple counter that will ask the FAST SRAM for the contents stored there and feed a resistor ladder with the values returned, when the CPU is not using it. So this means that everything graphics should be done by software: software sprites, software text, software bitmaps... If the Atari 2600 could race the beam, I think the '265 can do a nice work here... Or not?

There is a caveat here: This memory setup doesn't allow 65c02 emulation run with graphics, because it just could use the first 64K of addresses, being 56K of RAM and 8K of (EEP)ROM.

Also, it seems that I'm wasting memory surface in the chips, because to have the first 64K, I would waste 8K because I only need 56K, and to have the last 200KB of RAM, I would use 8 chips of 32KB that would give me 256KB but I would waste 56KB. But... What about this?: instead of using a lot of 32KB chips, I would use two (2) AS6C1008-55PCN chips, that would give me 256KB of memory of 55ns RAM, and with a decoder, to be able to map the first 56KB in the [0000-DFFF] area, and the rest in the [04E000-07FFFF] area.

Still viable?

EDIT: corrections
EDIT2: fix EEPROM P/N

[BigEd]

Don't think of unused RAM or unused address space as waste: think of it as an investment in simplicity.

[drogon]

tokafondo wrote:

Video. As said, I'm planning to have the video done by following Ben Eater's worst video card ever: a simple counter that will ask the FAST SRAM for the contents stored there and feed a resistor ladder with the values returned, when the CPU is not using it. So this means that everything graphics should be done by software: software sprites, software text, software bitmaps... If the Atari 2600 could race the beam, I think the '265 can do a nice work here... Or not?

I looked at this - briefly.

My thoughts were that if you used dual-port SRAM then it could work on a 6502, etc. system without the timing issues of synchronising the CPU side to the Video side.

You can do everything in software, I do that on another platform, however that platform is much much faster than a 6502, but then again the resolution of that video system is low, so who knows. It's worth a try..

-Gordon

[tokafondo]

VIDEO:

This is how I will try to generate video.

After viewing Ben Eater's The world’s worst video card? video, I started to really think about building my own SBC. Yes, there are projects everywhere that use FPGAs or ATMega or PIC chips. But that relies on software emulating hardware, a think that I want not to do.

I decided to go 400x300 pixels screen area, drawn on 800x600 display resolution. 400x300 are 120000 pixels, and with 1 byte of color information for every pixel, it would need 120000 bytes for the screen bitmap.

To generate the signal I will use high speed counters. The part I'm thinking about is the CD74AC163E, that accepts clock speeds up to 103Mhz with 5V. But I don't need that much. I would go with 40 mhz. But If I only need 20mhz to draw 400x300 resolution, why not to choose 20mhz clock then? Well, I'm thinking of make the counter to send the MCU a FCLK tick every 5th clock tick. Timing would be:

Code: Select all

"C" is every cycle of the main oscillator running at 40mhz.
"V" is every pulse sent by the counter array to the FAST SRAM.
"M" is every pulse sent by the counter array to the MCU.

         1         2         3         4         5
12345678901234567890123456789012345678901234567890...
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC...
V V V V V V V V V V V V V V V V V V V V V V V V V ...
         M         M         M         M         M

My logic here is that every 2 cycles of the CLK, the counter gets one that sends to the SRAM to get a value from it (20mhz effective). And every odd 5th cycle, the MCU gets its FCLK input (8mhz effective). Alternating this way, the FAST video SRAM should be free to be accessed both by the video circuit and the MCU.

Following this timing, it seems that every line of 400 pixels would need about 20μs to be drawn, and then there is a delay of 6,4μs where the SRAM is not accessed, because the sync signals are generated with no data at all. 20μs = 20000ns. So 20000ns / 400 pixels = 50ns. It takes 50ns to draw a single pixel. A FAST SRAM of 15ns is more than enough to serve for that purpose. For every MCU cycle, the video circuit draws 5 pixels. This relation is higher even than the one the C64 had: for every CPU cycle, the VIC-II would draw 8 pixels.

But that leaves the timing with 4 free slots of memory access that could be used by other chips that could do DMA access alternated with the video circuit. Maybe the CPU could write to the memory and a sound chip read from there, instead of I/O'ing the chip directly. Or an external or even second CPU or co-processor to write results of calculations done at higher clock speeds, like 3D acceleration or complex graphics generation, freeing the CPU of doing that.

I wrote earlier than a 400x300x8 bitmap would need a 120000 bytes of memory, and the FAST SRAM chips would provide 8000 bytes more, that are most than enough to use it as the interface that would share those other chips.

What do you think? Is this feasible? Please, do comment if the numbers and ideas are right, wrong, doable... Because maybe all my theory is just wrong because of me misunderstanding all of this.

[tokafondo]

drogon wrote:

tokafondo wrote:

Video. As said, I'm planning to have the video done by following Ben Eater's worst video card ever: a simple counter that will ask the FAST SRAM for the contents stored there and feed a resistor ladder with the values returned, when the CPU is not using it. So this means that everything graphics should be done by software: software sprites, software text, software bitmaps... If the Atari 2600 could race the beam, I think the '265 can do a nice work here... Or not?

I looked at this - briefly.

My thoughts were that if you used dual-port SRAM then it could work on a 6502, etc. system without the timing issues of synchronising the CPU side to the Video side.

You can do everything in software, I do that on another platform, however that platform is much much faster than a 6502, but then again the resolution of that video system is low, so who knows. It's worth a try..

-Gordon

Thanks. I'm planning to use the w65c265s @8mhz. I'm still wondering ig that's enough to race the beam, though.

[drogon]

tokafondo wrote:

drogon wrote:

tokafondo wrote:

Video. As said, I'm planning to have the video done by following Ben Eater's worst video card ever: a simple counter that will ask the FAST SRAM for the contents stored there and feed a resistor ladder with the values returned, when the CPU is not using it. So this means that everything graphics should be done by software: software sprites, software text, software bitmaps... If the Atari 2600 could race the beam, I think the '265 can do a nice work here... Or not?

I looked at this - briefly.

My thoughts were that if you used dual-port SRAM then it could work on a 6502, etc. system without the timing issues of synchronising the CPU side to the Video side.

You can do everything in software, I do that on another platform, however that platform is much much faster than a 6502, but then again the resolution of that video system is low, so who knows. It's worth a try..

-Gordon

Thanks. I'm planning to use the w65c265s @8mhz. I'm still wondering ig that's enough to race the beam, though.

If you have the RAM that you can poke pixels into then you're not racing the beam. The VCS2600 had 128 bytes of RAM in total and technically no video RAM.

Here is something to think about... If your screen memory needs 120,000 bytes, then the fastest you can clear it in software would be to use the block move instruction (ie. MVN). This moves one byte every 7 cycles. 120,000 * 7 = 840000 cycles, at 8Mhz is about 1/10th of a second. So that's a baseline for clearing the screen or software scrolling. A slight thorn in the side is that 120KB of RAM will span 2 x 64KB banks in the '816/'265 address space, so drawing a line from one corner to the other will cross a bank - as will moving a sprite. I think at that point things would get complex enough for me to simply give-up and move to a plan B for video. (which I have done)

The memory limitation is, I think, the biggest hurdle to overcome when you want nicer graphics than we had back in the day when allocating 20KB to video RAM was considered excessive. that's now why a lot of it is done in hardware to do the actual pixel poking, line/sprite drawing, etc. although with a fast enough CPU, you can still pixel-poke frames at a good speed, but my application for that is my desktop PC or cheap ($5) ARM based SBC with HDMI output.

-Gordon

[tokafondo]

drogon wrote:

Here is something to think about... If your screen memory needs 120,000 bytes, then the fastest you can clear it in software would be to use the block move instruction (ie. MVN). This moves one byte every 7 cycles. 120,000 * 7 = 840000 cycles, at 8Mhz is about 1/10th of a second. So that's a baseline for clearing the screen or software scrolling. A slight thorn in the side is that 120KB of RAM will span 2 x 64KB banks in the '816/'265 address space, so drawing a line from one corner to the other will cross a bank - as will moving a sprite. I think at that point things would get complex enough for me to simply give-up and move to a plan B for video. (which I have done)

.

But that cross banking issue should not be a proble with a 16 bit addressing space, should it? The MCU just write bytes to an memory address and that is... "linear address space" should stand for that: no banking at all.

It's that, or I just don't have any clue of how the '816 memory model works?