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:



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:



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/master/font8x8_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

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

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 ...



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



And finally running it ...



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.

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.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

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:



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

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.

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.

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!

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?

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/wdc/wdc_w65c265s_sep_13_2010.pdf

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!

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.

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:



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.



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:



Works like a charm.

Happy breadboarding!

A good result!