My project with a w65c265s MCU.

[tokafondo]

This is not working as expected, so I'm asking EPSON about this.

Connections:

Code: Select all

EPSON CHIP       W65C265s MCU
----------       ------------
RD#              MEMOEB (through NAND gate)
WR#              MEMWEB (NAND gate, too)
CS#              P76_CS6B

This gives me the RAM of the EPSON chip available from bank 40 onwards. Well, the thing is that I can't write to the RAM area but to the registers area. So: I can read and write registers but NOT RAM itself....

[tokafondo]

I'm still in the process of getting access to the graphics RAM.

Everytime I want the chip initialized I have to stream a series of values to the registers of the chip, so I tried to write a program in assembler to achieve that, to be had always in the EEPROM so I can initialize the chip.

But it's not working. After some initial values, a delay must be made until the next values can be set to complete the initialization.

I tried the most simple and crude way: LDA'ing and STA'ing values, and then tried to implement a delay using a routine I found by searching, but I can't get it to work. Anyone could lend a hand on this?

Thanks.

Code: Select all

; Target assembler: 64tass v1.53.1515 [--ascii --case-sensitive --nostart --long-address -Wall]
; 6502bench SourceGen v1.7.2-dev1
        .cpu    "65816"
*       =       $8000
        .as
        .xs
        sei
        clc
        xce
        lda     #$00
        sta     $460804
        lda     #$00
        sta     $460810
        lda     #$03
        sta     $460812
        lda     #$31
        sta     $460810
        lda     #$01
        sta     $460810
        jsr     L80E2
        nop
        nop
        lda     #$0a
        sta     $460816
        lda     #$02
        sta     $460804
        lda     #$4d
        sta     $460820
        lda     #$01
        sta     $460822
        lda     #$20
        sta     $460824
        lda     #$63
        sta     $460826
        lda     #$c0
        sta     $460828
        lda     #$47
        sta     $46082a
        lda     #$0a
        sta     $46082c
        lda     #$01
        sta     $46082e
        lda     #$01
        sta     $460830
        lda     #$00
        sta     $460832
        lda     #$01
        sta     $460840
        lda     #$00
        sta     $460842
        lda     #$00
        sta     $460844
        lda     #$01
        sta     $460850
        lda     #$84
        sta     $460853
        lda     #$03
        sta     $460854
        lda     #$01
        sta     $460856
        lda     #$c0
        sta     $460858
        lda     #$00
        sta     $46085a
        lda     #$00
        sta     $46085c
        lda     #$01
        sta     $460860
        lda     #$40
        sta     $460862
        lda     #$01
        sta     $460864
        lda     #$00
        sta     $460866
        lda     #$00
        sta     $460868
        lda     #$01
        sta     $4608d0
        lda     #$01
        sta     $4608d2
        lda     #$00
        sta     $4608d4
        lda     #$00
        sta     $4608ff
        brk

        .byte   $00

L80E2   ldy     #$ac
        ldx     #$00
_L80E6  jsr     _L80EF
        dex
        bne     _L80E6
        dey
        bne     _L80E6
_L80EF  rts

[leepivonka]

S (the stack pointer) should be initialized to point to some RAM before using the stack (jsr & rts).
I assume you've set the reset vector to $8000 & the native mode BRK vector to something to get control when this routine executes the BRK.

[tokafondo]

leepivonka wrote:

S (the stack pointer) should be initialized to point to some RAM before using the stack (jsr & rts).
I assume you've set the reset vector to $8000 & the native mode BRK vector to something to get control when this routine executes the BRK.

Thanks, @leepivonka. If my electronics knowledge is low, my coding knowledege is way lower. The W65C265S seems to have all its internal vectors pointing to the ROM monitor.

[leepivonka]

Ah! I wrongly assumed you weren't using the ROM monitor.

Do you have the chip select enabled on the '265? I assume you can write & read EPSON registers before running this program.
After the program runs, can you read back the registers? Do they have the expected values?
I haven't looked at the EPSON chip doc yet. Is this the only place you need a delay during initialization?
Does the EPSON chip have a reset pin? Is it getting a reset before you try to use it?

[tokafondo]

There are actually some forward movements with this.

As a workaround, because my focus is now in what I'm telling later, what I did was split the initialization routines in two parts: first one in $8000 and the second one, that should be done after a delay of 2500 microseconds, in $8100.

So I now call the $8000 code, and in the time I type the call to the $8100 code, those 2500 microseconds are already gone. It's a crude workaround, but that's what I'm able to do by now.

What I've been able to do is configuring the chip, and turn the panel interface (I still doesn't have the right connector for it) on and off. The logic analyzer show that behaviour:

What you are seeing is (forget the labels in every line, as shown in the screenshot):

Code: Select all

LINE#  DESCRIPTION
===== ===========
1      The FCLKOB pin: the clock tick as it's being fed into the '265s.
2      The PHI2 pin: the clock tick that the '265s feeds to the rest of the system.
3      The PCLK pin: the clock tick that the EPSON chip feeds to the LCD panel.
4      The DE pin: the "display enable" that tells the LCD where to start drawing pixels.
5      The HS pin: the horizontal sync pulse.
6      The VS pin: the vertical sync pulse.

By manually modyfing a register, I can enable and disable those signals at will, and that's what you see in the graphic: it begins with the panel "off", then I turn it "on" and then I turn it back "off".

The setup for this capture.

[tokafondo]

It seems there is something weird with the internal memory access... Sometimes it work, sometimes it doesn't work.

I'm sure it's being related to the fact of the type of building I'm doing or something. Maybe it' related to power lines noise or the capacitors I'm using or something.

Before the LCD panel output testing, I was not able to do reliable writes to the internal RAM. Every fourth byte, the write wouldn't be done. It can be seen here:

Code: Select all

46:0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
46:0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
46:0020 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00
46:0030 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00
46:0040 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00
46:0050 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00
46:0060 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00
46:0070 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00
46:0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
46:0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
46:00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
46:00B0 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00
46:00C0 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00
46:00D0 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00
46:00E0 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00
46:00F0 11 11 11 00 11 11 11 00 11 11 11 00 11 11 11 00

I actually tried to write some rows with "zeros" and some rows with "ones". But as you can see, the rows with "ones" hadn't the "zeros" gone "ones" every fourth byte.

But after tinkering with the chip for a while, I did another test and voilà! It worked!!

Code: Select all

40:0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40:0010 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
40:0020 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22
40:0030 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
40:0040 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44
40:0050 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
40:0060 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40:0070 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40:0080 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40:0090 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40:00A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40:00B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40:00C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40:00D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40:00E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40:00F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

[tokafondo]

Well... it seems I made a mistake and I have to tell about it here:

The memory map of the graphics chip shows that the main RAM starts from $00000 and ends in $5FFFF. Those translates to $40:0000 to $45:FFFF when connecting the chip to the CS6B pin of the '265s.

Then, there are the LUT tables betwen $60000 and $607FF ($46:0000-$46:07FF in my SBC).

And lastly, the registers in $60800-$608FF ($46:0800-$46:08FF).

I think that what's happening is that the LUT tables have its own format, so writing to certain areas is not allowed at all, and my mistake was to try to write to those areas as if they were just "RAM".

Every write between $40:0000 and $45:FFFF gets done as expected, so no failures here:

THE CHIP IS WORKING AS INTENDED.

Next step: get the LCD Panel to actually show "something". I have to wait for the connector adaptor and the step-up voltage regulators.

[Dr Jefyll]

tokafondo wrote:

Maybe it' related to power lines noise or the capacitors I'm using or something.

tokafondo wrote:

I think that what's happening is that the LUT tables have its own format, so writing to certain areas is not allowed at all, and my mistake was to try to write to those areas as if they were just "RAM".

Well, I wish you luck, and hope for the best. Compared with earlier in the thread your construction techniques have improved a great deal, and maybe the caps and power arrangements are now Good Enough. But I'm a little doubtful, TBH. Given how time-consuming it can be to troubleshoot a flaky problem, I myself would do some further tidying up before proceeding.

At the very least, I'd recommend replacing the audio caps with monolithic ceramic or multilayer ceramic as suggested.

Another significant improvement is to shorten the connections between the caps and the video chip... and, to that end, relocating the cap can help a lot. As shown in the photo, SMD caps are small enough that they can mount between the pins of your breakout board. This brings them closer to the chip, and also frees up space on the wiring side of the main board.


It's very nice to see this project coming along, BTW!

-- Jeff

[tokafondo]

Thank you very much for your words.

Actually, I'm doing this stage of the project a bit like experimenting what can I do and how far I will able to go.

Once I get something that I could say "this is a milestone", some sort of "v1.0" or something, I would start to think to rebuild the project with a proper custom PCB and better, SMD components where applicable.

Where I live, is not that easy to order custom designs to be built and have them at home the following week.

If I've been able to get to this, it's then that electronics have gone quite "hobbyist tolerant".

[tokafondo]

I think I have the parts needed to get my SBC to the next level. That LCD screen in the right comes from a Nintendo DS lite. What you see scratched is the touch screen. No worries by now, as I don't plan to have it working, but it could be fun, anyway.

[tokafondo]

It's a shame but I still haven't received the parts needed to manage the LCD module. I waited for more than a month for some LM2662 voltage inverters that never arrived, and then found that the shipment got cancelled at origin. So I had to order again from a different seller...

Meanwhile, I tried to attach a 1602A LCD module, to be controlled with the parallel port, but it seems I also need the inverters so that, also waiting.

So what I'm trying is to get is the '265s boot from the external EEPROM.

The usual way to do that is to burn the code you want to run in the EEPROM, and then put the "WDC" string in certain memory locations, so the ROM jumps to it and continue running from there.

But there is also another way, and it is bringing high the /BE line about 200ns after the /RESET line:

Code: Select all

When BE goes high after RESB goes high the BCR sets up the W65C265S for emulation. Port 0 and 1 are the address outputs, Port 2 is the data I/O bus and RUN is the multiplexed RUN function.

That means, as I understand, that you can make the '265s boot like a normal 65816 does, in 6502 emulation mode. I don't know if the owners of a '265SXB can mod that board to make this happen, by tinkering with the /BE line in pin 46 of X265_BUS connector.

I'm testing in a protoboard with ways to create that 200ns delay, having success there. I have to repeat that success in my board.

And then I have to copy the Mensch ROM Monitor in my EEPROM and get my board to boot with that delay.

I think that what is achieved this way is to get the '265s run only with external memory. The internal 576 bytes of RAM and the 8K of ROM wouldn't be used at all. That would allow to work with a linear 32K RAM + 32K ROM of memory from the start, instead of messing around with the chip select lines to disable all the internal memory, a thing that's what usually done when booted from the Mensch Monitor.

[drogon]

tokafondo wrote:

It's a shame but I still haven't received the parts needed to manage the LCD module. I waited for more than a month for some LM2662 voltage inverters that never arrived, and then found that the shipment got cancelled at origin. So I had to order again from a different seller...

Meanwhile, I tried to attach a 1602A LCD module, to be controlled with the parallel port, but it seems I also need the inverters so that, also waiting.

So what I'm trying is to get is the '265s boot from the external EEPROM.

The usual way to do that is to burn the code you want to run in the EEPROM, and then put the "WDC" string in certain memory locations, so the ROM jumps to it and continue running from there.

But there is also another way, and it is bringing high the /BE line about 200ns after the /RESET line:

Code: Select all

When BE goes high after RESB goes high the BCR sets up the W65C265S for emulation. Port 0 and 1 are the address outputs, Port 2 is the data I/O bus and RUN is the multiplexed RUN function.

That means, as I understand, that you can make the '265s boot like a normal 65816 does, in 6502 emulation mode. I don't know if the owners of a '265SXB can mod that board to make this happen, by tinkering with the /BE line in pin 46 of X265_BUS connector.

I'm testing in a protoboard with ways to create that 200ns delay, having success there. I have to repeat that success in my board.

And then I have to copy the Mensch ROM Monitor in my EEPROM and get my board to boot with that delay.

I think that what is achieved this way is to get the '265s run only with external memory. The internal 576 bytes of RAM and the 8K of ROM wouldn't be used at all. That would allow to work with a linear 32K RAM + 32K ROM of memory from the start, instead of messing around with the chip select lines to disable all the internal memory, a thing that's what usually done when booted from the Mensch Monitor.

I'm looking at the W65c134SXB board right now - it has a similar feature - ie. take BE low, then bring BE high some time after Reset goes high.

The board uses a simple RC network for the reset signal, so accurately timing it might be tricky, however my guess from reading the data sheet is that more likely to be a number of cycles from Reset going high rather than a fixed time and it looks like that might be 4 cycles (possibly 5) of the startup clock (which is off the 32768Hz xtal on the '134 SXB board)

So it may be possible to use a counter to gate BE high triggered by the Reset going high.

However, I have discounted this approach and will use the 'WDC' signature method - on the '134SXB it enables EEPROM from $8000 through $EFFF, checks for the 'WDC' signature, and if found JMPs to $8004. This check happens very early in the reset cycle, then my code at $8004 can disable the top 4K and swap-in the rest of the EEPROM and carry on.

Hopefully I'll have time today to adapt the code from Andrew Jacobs link viewtopic.php?f=4&t=6339#p79164 and give it a go.

My 'gotcha' is that if I get it wrong, I don't (currently) have an adapter for the EEPROM chip for my programmers, so if I screw it up, then I'll have to wait until I can get an adapter, so plan A is not NOT set the 'WDC' signature bytes and just start my code manually by typing the command at the ROM prompt.

Cheers,

-Gordon

[BitWise]

drogon wrote:

so plan A is not NOT set the 'WDC' signature bytes and just start my code manually by typing the command at the ROM prompt.

That's what I do. Only set the signature for auto start when the code is well tested.

For some of my projects I use a ROM with a simple BIOS in it that jumps to code in my SRAM expansion after its initialised. That way I can use the Mensch monitor to download S28 records for the code I'm developing then jump to $8004 to start it. Gives a quicker test cycle than having to flash a ROM every time.

[drogon]

BitWise wrote:

drogon wrote:

so plan A is not NOT set the 'WDC' signature bytes and just start my code manually by typing the command at the ROM prompt.

That's what I do. Only set the signature for auto start when the code is well tested.

For some of my projects I use a ROM with a simple BIOS in it that jumps to code in my SRAM expansion after its initialised. That way I can use the Mensch monitor to download S28 records for the code I'm developing then jump to $8004 to start it. Gives a quicker test cycle than having to flash a ROM every time.

I'll document my '134 stuff in a new thread at some point, but the sooner I can get away from srecords to a binary protocol at 9600 baud the better.. (My OS is ~10KB and I already have a binary file transfer program for my Ruby project)

Cheers,

-Gordon