6502.org

Posted: **Mon Jun 11, 2018 3:06 am**

After destinating this gray and rainy sunday afternoon for digging into the protocols with a logic analyzer tool, the reason the display didn't work became obvious. It was a silly bug in a hex to binary conversion routine. With this fixed, the display started to work like a charm.

As mentioned in one of the previous posts, the QBX talks to the ATTiny85 via the UART0 by sending I2C ASCII/HEX command sequences. This implementation is kept very generic, and the code running on the QBX 'has to know' the bytes to write and to read.

To give an example, let's write a capital 'A' to the top left corner of the screen. This can be done by letting the QBX send two I2C write commands via UART0 to the ATTiny85 I2C Bus Master:

Code: Select all

I2C3C0400000010B0
I2C3C090040007C7E13137E7C00

The ASCII/HEX format had been chosen for ease of debugging and testing. I wrote a monitor extension routine, which lets me input sequences like these, in order to communicate with the I2C devices on the bus.

Breakdown of the first command sequence:

Code: Select all

I2C3C0400000010B0

I2C   command prefix
3C    I2C device address
04    number of bytes to write
00    number of bytes to read (from the device after write is complete)
00    data byte 1
00    data byte 2
10    data byte 3
B0    data byte 4

The SSD1306 does not have a built-in character ROM, so one has to transmit 8 bytes of bitmap data in order to display a character on screen. The second sequence does basically that where the first sets the current write (cursor) position. Further details in the data sheet.

For non time critical stuff this approach works quite satisfactory, since one can plug additional I2C modules on the bus and talk to them right through the monitor.

For the display, I converted the character map data from a monochrome bitmap font I found on gitHub (https://github.com/dhepper/font8x8/blob ... x8_basic.h) and swapping the bits into the column oriented format required for the SSD1306. After writing still some crude display routines and a monitor extension for char based text input and then printing it on the display.

All that stuff is growing really fast, summing up already 6k (code and data) in memory.

Here is what the result looks like:

Happy breadboarding

Posted: **Mon Jun 11, 2018 4:15 am**

Well done... you very nearly rickrolled your audience...

Posted: **Sun Jun 17, 2018 12:00 am**

Hi again!

@BigEd thanks for stopping by

In one of the previous posts I mentioned that I was looking into developing some kind of interactive assembly tool running as user command under the monitor ...

Well, here is what it looks like ...

Code: Select all

>u  
USER>a

Interactive ASSEMBLY Tool
--------------------------------
Enter Address  BB:AAAA 00:4000
00:4000> REP #$20
00:4002> LDA #$1234
00:4005> SEP #$20
00:4007> BRK
00:4008> BRK
00:4009> XBA
00:400A> BRK
00:400B> BRK
00:400C> 
READY
>

And here is what the disassembled code looks like ...

Code: Select all

>u  
USER>d

Interactive DISASSEMBLY Tool
--------------------------------

Enter Lowest Address   BB:AAAA 00:4000
Enter Highest Address  BB:AAAA 00:400c

00:4000   C2 20         REP #$20
00:4002   A9 34 12      LDA #$1234
00:4005   E2 20         SEP #$20
00:4007   00 00         BRK #$00
00:4009   EB            XBA 
00:400A   00 00         BRK #$00

READY
>

And finally running it ...

Code: Select all

>g  
Enter Address  BB:AAAA 00:4000

PCntr     Acc    Xreg   Yreg   Stack
00:4009   12 34  24 72  00 00  01 FF  

  DirRg  F  DBk
  00 00  20 00  

Status Reg
N  V  M  X  D  I  Z  C
0  0  1  0  0  0  0  0  

>g  
Enter Address  BB:AAAA 

PCntr     Acc    Xreg   Yreg   Stack
00:400C   34 12  24 72  00 00  01 FF  

  DirRg  F  DBk
  00 00  20 00  

Status Reg
N  V  M  X  D  I  Z  C
0  0  1  0  0  0  0  0  

>

BTW The disassembly code has been borrowed and adapted from Andrew Jacob's great w65c265sxb-hacker tool (https://github.com/andrew-jacobs/w65c265sxb-hacker).

The (still very crude) assembly tool shares some of this project's data as well.

Regards.

Posted: **Sun Jun 17, 2018 10:57 am**

I was planning on adding an assembler (to the SXB Hacker) at some point. I used the same code base for my monitor rom in my sb-6502 board but I’ve been adding a trace/single step feature first.

This weekend I’m down a completely different shaft in the 65xx code mine experimenting with a silly idea but I’ll get back to the monitor soon. I want to wrap the sb-6502 project up and sell a few boards with 6502, 65c02 or 65802 devices.

Posted: **Sun Jun 17, 2018 9:44 pm**

Hi Andrew!

Great to hear you are planning to implement the assembly feature in the monitor. It would be a great way for beginners to try out the different opcodes to figure how to use them. This is what I am using this functionality for.

While playing around with the assembly and disassembly I stumbled over a couple of minor glitches in the original source. I thought you would be interested in knowing about ... so hope you don't mind posting right here:

Code: Select all

$B3 $00         decodes as      LDY ($00,S),Y    should be     LDA ($00,S),Y    (misplaced OP code in lookup table)
$54 $00 $00     decodes as      MVN              should be     MVN $00,$00      (using TxImplied instead of particular TxMove)
$44 $00 $00     decodes as      MVP              should be     MVP $00,$00      (using TxImplied instead of particular TxMove)

Keep up the good work!

BTW The sb-6502 seems very interesting too ... at some point I'll have e deeper look into it. Still have to improve my knowledge about certain aspects in order to fully understand the readme

BitWise wrote:

I was planning on adding an assembler (to the SXB Hacker) at some point. I used the same code base for my monitor rom in my sb-6502 board but I’ve been adding a trace/single step feature first.

This weekend I’m down a completely different shaft in the 65xx code mine experimenting with a silly idea but I’ll get back to the monitor soon. I want to wrap the sb-6502 project up and sell a few boards with 6502, 65c02 or 65802 devices.

Posted: **Fri Jun 22, 2018 4:16 pm**

Hi!

this weekend I am planning to add one of my W65C21S Peripheral Interface Adapter to my breadboard assembly.

I am not sure about the required logic for the three chips RAM, ROM (currently NVRAM) and the PIA to play nicely together.

I came up with the following idea, which would require 3 auxiliary logic chips I have in stock.

What do you think ... could that work?

Regards.

Posted: **Fri Jun 22, 2018 8:01 pm**

/RESET wrote:

Hi!

this weekend I am planning to add one of my W65C21S Peripheral Interface Adapter to my breadboard assembly.

I am not sure about the required logic for the three chips RAM, ROM (currently NVRAM) and the PIA to play nicely together.

I came up with the following idea, which would require 3 auxiliary logic chips I have in stock.

The attachment ChipSelect21.png is no longer available

What do you think ... could that work?

Regards.

A more detailed I/O memory map would be nice. The information you've given doesn't really tell enough to determine if your logic is completely correct.

In any case, the logic as designed will be quite slow, especially with using the CD4081. Take a look at the 74HC21, which is faster, and see if you can simplify your circuit to reduce the number of gates between the address bus and the individual chip selects. Further reductions may be possible by not trying to cram all of the I/O hardware into one page.

Also, the 54LS04 inverter is not recommended in an all-CMOS circuit. I suggest you use 74AC04 or 74HC04. Mixing TTL and CMOS logic may cause hard-to-diagnose problems due to the families' differing notions of what voltage levels constitute a valid logic condition.

74hc21_and_4input.pdf: 74HC21 4-Input Dual AND; (856.84 KiB) Downloaded 171 times

Posted: **Fri Jun 22, 2018 8:45 pm**

Hi!

Thank you very much for your help!

I had no idea about such huge timing differences. I assume we are talking about the propagation time. As of the data sheet, the CD4081 is about 10x slower than the 74HC21 you suggested.

The image below shows the memory map from the WDC data sheet. As of my understanding, the PIA should be mapped to either $DF00-$DF1F or $DFC0-$DFFF.

Regards.

BigDumbDinosaur wrote:

/RESET wrote:

Hi!

this weekend I am planning to add one of my W65C21S Peripheral Interface Adapter to my breadboard assembly.

I am not sure about the required logic for the three chips RAM, ROM (currently NVRAM) and the PIA to play nicely together.

I came up with the following idea, which would require 3 auxiliary logic chips I have in stock.

The attachment ChipSelect21.png is no longer available

What do you think ... could that work?

Regards.

A more detailed I/O memory map would be nice. The information you've given doesn't really tell enough to determine if your logic is completely correct.

In any case, the logic as designed will be quite slow, especially with using the CD4081. Take a look at the, which is faster, and see if you can simplify your circuit to reduce the number of gates between the address bus and the individual chip selects. Further reductions may be possible by not trying to cram all of the I/O hardware into one page.

Also, the 54LS04 inverter is not recommended in an all-CMOS circuit. I suggest you use 74AC04 or 74HC04. Mixing TTL and CMOS logic may cause hard-to-diagnose problems due to the families' differing notions of what voltage levels constitute a valid logic condition.

The attachment 74hc21_and_4input.pdf is no longer available

Posted: **Fri Jun 22, 2018 9:09 pm**

If you dare to solder a tiny wire to the outer pin of resistor network R6 left to P17 of J4 you have P70=CS0B which you could use as chip select for your PIA.

This requires some skill in soldering!

Posted: **Fri Jun 22, 2018 9:32 pm**

Mmmh ... but who takes care that the CS4B External ROM and the CS0B PIA won't interfere, since both overlap in terms of address range?

GaBuZoMeu wrote:

If you dare to solder a tiny wire to the outer pin of resistor network R6 left to P17 of J4 you have P70=CS0B which you could use as chip select for your PIA.

P70access.png

This requires some skill in soldering!

Posted: **Fri Jun 22, 2018 9:52 pm**

This is done internally to the W65C265 as layed out on page 22 of the data sheet. In this case you need to enable external busses (BCR0=1) and PCS0=1. The latter enables CS0B @ P70. (see 2.9.2 @ pg.37).

Datasheet: http://6502.org/documents/datasheets/wd ... 3_2010.pdf

Posted: **Tue Jun 26, 2018 10:33 pm**

Hi!

time for another project update from the last weekend.

Initially everything went well. I managed to build the logic circuit like presented in the previous post. This time using the components I had at hand, which later could be replaced by the suggested faster components.

To test the circuit, I put a ATMega328 on a breadboard using the 8 pins of port D to simulate the A8 to A15 address lines of the 65C816 of the QBX. The ATMega runs at 16MHz. A short sketch iterates a 16bit integer simulating sequential addressing and the Hi-Byte of the counter is used as output on PORTD.

The image below, shows the produced signal levels and timing for one cycle over the whole 16-bit address range.

So far so good. Looks like the circuit is doing what it is supposed to do. Enabling the RAM for adresses $0000-$7FFF then enabling ROM from $8000-$DEFF and then enabling I/O from $DF00-$DFFF and enabling ROM again from $E000-$FFFF.

Looking close at the edge timings, there is some overlapping of around 83ns. But let's ignore that for now. To compensate I could go for faster logic chips and/or slow down chip access timing via the '816 speed control register (SSCR).

If I had stopped here the weekend would have been a success, but I resolved to test some more variations for the simulation, basically fast alternations between pairs of address spaces: $81 (ROM) and $00 (RAM), $DF (I/O) and $81 (ROM), $DF (I/O) and $00 (RAM).

It happens that the last alternating address combination between $DF (I/O) and $00 (RAM) shows a strange behavior I could not explain. Even the $81 (ROM) is not involved, the corresponding signal briefly goes high immediately before the I/O chip select line does.

The image below shows the different simulations along with the source code for better understanding.

Any idea what could cause this behaviour?

[image]

Happy breadboarding!

Posted: **Tue Jun 26, 2018 10:58 pm**

/RESET wrote:

If I had stopped here the weekend would have been a success, but I resolved to test some more variations for the simulation, basically fast alternations between pairs of address spaces: $81 (ROM) and $00 (RAM), $DF (I/O) and $81 (ROM), $DF (I/O) and $00 (RAM).

This is a classic "glitch" signal, caused by some parts of the address transitioning or being decoded more quickly than others. You will note that $81 has the most-significant and least-significant bits set, and so does $DF (as well as most of the others).

In particular, A15 is decoded much faster (only 1 gate delay) than the combination of A15-A8 which selects the I/O (4 gate delays), and there's a further 2 gate delays before the latter deselects the ROM when A15 initially selected it.

This is an excellent argument in favour of qualifying all output and write enabled with the clock, giving time for the decode logic to settle before driving or interpreting the data bus.

Posted: **Mon Jul 09, 2018 12:37 am**

Hi folks!

today I am very happy to be able to announce that the PIA 65C21 now works on the breadboard. Both ports, configured as output, are lighting up some LEDs implementing a simple counter.

As suggested in this thread, I tried to simplify the address decode logic to a minimum of stages. Also I am still using the original (slow) components, as the faster ones are a bit difficult to obtain.

In order to simplify the address logic I realized, that I am not limited to the specific range of $DFxx and I also didn't take the risk to ruin the board soldering a wire in order to access the CS0B pin directly. Thus I could allocate the PIA to virtually any unused address and choose $C000 giving me the following address mapping:

Code: Select all

+---------------+---------------+ 
|  Addr. Range  |  Usage/Chip   |
+---------------+---------------+ 
| $E000 - $FFFF | Intern. ROM   |
+---------------+---------------+ 
| $C000 - $C003 | External PIA  |
+---------------+---------------+ 
| $8000 - $9FFF | Ext. NVRAM    |
+---------------+---------------+ 
| $0000 - $7FFF | Ext. SRAM     |
+---------------+---------------+

The CS0 and CS1 lines are tied the the A15 and A14 lines. The CS2B line is qualified with PHI2 through an inverter. The RS0 and RS1 are tied to the A00 and A01 lines respectively,

Unfortunately, when wiring up the chip, initially I switched the RS0 and RS1 lines which caused the LEDs light up inversely

. Writing $FE into $C000 lighted the first and writing $01 into $C000 all but the first.

After fixing this silly mistake, everything works fine as intended.

The simple test code below show the PORT initialization and counts the value of the corresponding PORTA and PORTB data registers, which flashes the LEDs accordingly.

Code: Select all

;----------------------------------------------------------------------------
;   PIA_TEST
;----------------------------------------------------------------------------

PIA_TEST:
!zone           {
                jsl     SEND_CR

                lda     #$00
                sta     $c001           ; select DDRA
                sta     $c003           ; select DDRB

                lda     #$ff            ; set all pins as output
                sta     $c000           ; write into DDRA
                sta     $c002           ; write into DDRB

                lda     #$04
                sta     $c001           ; select PORTA
                sta     $c003           ; select PORTB

                lda     #$00            ; set all outputs LOW
                sta     $c000           ; write into PORTA
                sta     $c002           ; write into PORTB
.LOOP:
                jsl     GET_CHR         ; wait for input
                cmp     #$20            ; is char a space?
                bne     .QUIT           ; no then we're done
                    
                inc     $c000           ; increment PORTA
                inc     $c002           ; increment PORTB
                lda     $c000           ; obtain the counter value
                jsl     SEND_HEX_OUT    ; and print it on serial console
                jsl     SEND_CR         ; start a new line
                bra     .LOOP           ; and stay in loop
.QUIT:
                rtl
}

An additional improvement in my code-build-test process saved me a lot of time. After assembling the code and generating the required S28 file afterwards, I upload the file to the board via the serial terminal. But once uploaded, I had always to type a J 00:0400 to call the initialization routine. Although the srec_cat tool I am using provides an option to set the start address (-execution-start-address=0x400) which I think should be detected by the monitor and called after uploading is complete, this does not happen. Seems that this behavior is not implemented.

A simple solution to achieve the initialization beeing called right after upload is simply adding the corresponding command to the end of the S28 file.

This is what it looks like in my build script:

Code: Select all

#!/bin/sh

acme -r user.lst user.asm

srec_cat user.bin -binary -offset=0x400 \
         -o user.s28 -address-length=3 \
         -execution-start-address=0x400

echo "j000400" >> user.s28

Works like a charm.

Happy breadboarding!

Posted: **Mon Jul 09, 2018 5:15 am**

A good result!

6502.org

Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB

Re: Wiring SRAM to W65C265SQXB