Topics

Confused about OUT command, vs RESET conditions

Erturk Kocalar
 

Hi there,

I will appreciate if you can help confirm/debug an unexpected (to me) 1802 behavior after it comes out of reset.

Background: I'm building a bunch of 8-bit microprocessor boards for Arduino Mega, where Arduino monitors address/data/control signals and emulates ROM/RAM/peripherals while the microprocessor executes code (called RetroShield for Arduino Mega). My goal is to build a board for every 8-bit microprocessor out there (so far I have 6502, 6809, Z80, 8031 and 8085 working).

I brought up the 1802 version yesterday. 1802 is executing my test code however there is one behavior that doesn't make sense to me.

// 1802 comes out of reset:
0x0000 0xC4,       // NOP
0x0001 0xC4,       // NOP
0x0002 0x7B,       // SEQ      <<=== LED turns on.
0x0003 0x69,       // INP 1
0x0004 0x61,       // OUT 1
0x0005 0x7A,       // REQ        <<=== this instruction after OUT 1 is skipped. so LED does not turn off.
0x0006 0x30, 0x00, // BR $00

Does it make sense if REQ is skipped?

- If so, I suspect this has something to do with reset values of the registers (I'm not setting up any registers). I'm suspecting PC is incremented by one as a side-effect, but could not find any documentation to confirm this.
- If not, my low level code for handling CPU control signals is not correct for IO instructions. if this is the case, I will share logic analyzer pictures and we can go over to make sure I implement INP/OUT waveforms correctly.

Thank you very much for your help,
Erturk

This is the setup but with the 1802 board:
http://www.8bitforce.com/projects/retroshield/

David Schultz
 

On 7/17/19 12:54 PM, Erturk Kocalar wrote:
Hi there,

I will appreciate if you can help confirm/debug an unexpected (to me)
1802 behavior after it comes out of reset.

Background: I'm building a bunch of 8-bit microprocessor boards for
Arduino Mega, where Arduino monitors address/data/control signals and
emulates ROM/RAM/peripherals while the microprocessor executes code
(called RetroShield for Arduino Mega). My goal is to build a board for
every 8-bit microprocessor out there (so far I have 6502, 6809, Z80,
8031 and 8085 working).

I brought up the 1802 version yesterday. 1802 is executing my test code
however there is one behavior that doesn't make sense to me.

// 1802 comes out of reset:
0x0000 0xC4,       // NOP
0x0001 0xC4,       // NOP
0x0002 0x7B,       // SEQ      <<=== LED turns on.
0x0003 0x69,       // INP 1
0x0004 0x61,       // OUT 1
*0x0005 **0x7A,       // REQ*        <<=== *this instruction after OUT 1
is skipped. so LED does not turn off.*
0x0006 0x30, 0x00, // BR $00

Does it make sense if REQ is skipped?
Yes. OUT outputs the value at M(R(X)) and increments R(X). Since X=P=0
at reset...

This is all very well documented.


--
https://web.archive.org/web/20190214181851/http://home.earthlink.net/~david.schultz/
(Web pages available only at the Wayback Machine because Earthlink
terminated that service.)

David Schultz
 

On 7/17/19 12:54 PM, Erturk Kocalar wrote:
// 1802 comes out of reset:
0x0000 0xC4,       // NOP
0x0001 0xC4,       // NOP
0x0002 0x7B,       // SEQ      <<=== LED turns on.
0x0003 0x69,       // INP 1
I should have also mentioned that INP writes to M(R(X)) so will
overwrite your code since X+P.

--
https://web.archive.org/web/20190214181851/http://home.earthlink.net/~david.schultz/
(Web pages available only at the Wayback Machine because Earthlink
terminated that service.)

Bob Kay
 

This is the expected behavior.  It is documented although not explicitly.

When the 1802 is reset, the program counter register and the index register pointers are both set to point to register 0, which in turn is cleared to zero.  Therefore the program starts executing at location zero.

The out instruction outputs the byte at r[x], then increments r[x].  Since r[x] and r[p] are both register 0, the out instruction increments the program counter.  Therefore the byte following the out instruction would be skipped.

Lee Hart
 

Erturk Kocalar wrote:
Hi there,

I will appreciate if you can help confirm/debug an unexpected (to me)
1802 behavior after it comes out of reset.

Background: I'm building a bunch of 8-bit microprocessor boards for
Arduino Mega, where Arduino monitors address/data/control signals and
emulates ROM/RAM/peripherals while the microprocessor executes code
(called RetroShield for Arduino Mega). My goal is to build a board for
every 8-bit microprocessor out there (so far I have 6502, 6809, Z80,
8031 and 8085 working).

I brought up the 1802 version yesterday. 1802 is executing my test code
however there is one behavior that doesn't make sense to me.

// 1802 comes out of reset:
0x0000 0xC4, // NOP
0x0001 0xC4, // NOP
0x0002 0x7B, // SEQ <<=== LED turns on.
0x0003 0x69, // INP 1
0x0004 0x61, // OUT 1
*0x0005 **0x7A, // REQ* <<=== *this instruction after OUT 1
is skipped. so LED does not turn off.*
0x0006 0x30, 0x00, // BR $00

Does it make sense if REQ is skipped?
Yes. After reset, P=0 and X=0. The INP and OUT instruction read or write to the RAM location pointed to by X... which will be R0, which is the *program counter*.

So the OUT 1 instruction at 0004 writes the following byte (0x7A at 0x0005) to output port 1. It then increment register R(X) (the program counter, when X=P).

Likewise, the INP instruction reads input port 1, and writes it to the following address (at 0004). The INP instruction does *not* increment register X; so if X=P, an INP instruction is a "hit self on head with hammer" instruction. It writes a byte into the next location, then tries to execute it!

Set X to something other than P, and initial that registe to point to some "safe" memory location; and you should be all set.

--
In software development, there are two kinds of error: Conceptual
errors, implementation errors, and off-by-one errors. (anonymous)
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com

Erturk Kocalar
 

Thank you all very much for the detailed comments and explanation. It makes sense now. (Lee, also thanks for the emails we exchanged about connections a few months ago).

I copy/pasted the tinybasic rom into arduino code and I am working on code to decode the serial output coming thru Q.

Bringing up 1802 taught me a lot about 1802. I am more curious now because it is different from the 8-bit micros. I like to understand more why it was built this way and I also like how CPU helps in I/O and DMA operations at hardware level.

Enjoy your day,
Erturk


On Wed, Jul 17, 2019 at 01:11 PM, Lee Hart wrote:
Erturk Kocalar wrote:
Hi there,

I will appreciate if you can help confirm/debug an unexpected (to me)
1802 behavior after it comes out of reset.

Background: I'm building a bunch of 8-bit microprocessor boards for
Arduino Mega, where Arduino monitors address/data/control signals and
emulates ROM/RAM/peripherals while the microprocessor executes code
(called RetroShield for Arduino Mega). My goal is to build a board for
every 8-bit microprocessor out there (so far I have 6502, 6809, Z80,
8031 and 8085 working).

I brought up the 1802 version yesterday. 1802 is executing my test code
however there is one behavior that doesn't make sense to me.

// 1802 comes out of reset:
0x0000 0xC4, // NOP
0x0001 0xC4, // NOP
0x0002 0x7B, // SEQ <<=== LED turns on.
0x0003 0x69, // INP 1
0x0004 0x61, // OUT 1
*0x0005 **0x7A, // REQ* <<=== *this instruction after OUT 1
is skipped. so LED does not turn off.*
0x0006 0x30, 0x00, // BR $00

Does it make sense if REQ is skipped?
Yes. After reset, P=0 and X=0. The INP and OUT instruction read or write
to the RAM location pointed to by X... which will be R0, which is the
*program counter*.

So the OUT 1 instruction at 0004 writes the following byte (0x7A at
0x0005) to output port 1. It then increment register R(X) (the program
counter, when X=P).

Likewise, the INP instruction reads input port 1, and writes it to the
following address (at 0004). The INP instruction does *not* increment
register X; so if X=P, an INP instruction is a "hit self on head with
hammer" instruction. It writes a byte into the next location, then tries
to execute it!

Set X to something other than P, and initial that registe to point to
some "safe" memory location; and you should be all set.

--
In software development, there are two kinds of error: Conceptual
errors, implementation errors, and off-by-one errors. (anonymous)
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com

Gregg Levine
 

Hello!
I agree. The CDP1802 is perhaps the most interesting of the original
family members of the 8 bit micros. And Ertuk you will be seeing a
note regarding my buying an R6502 PCB because that is the processor I
got my start on. After I do get it, and of course get it working. I am
more interested in using the board to assist me in building the nearly
ultimate R6502 project, more then running the Apple 1 monitor.

I'll probably order the CDP1802 one and get firmly involved in the
doings of the group here.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."

On Wed, Jul 17, 2019 at 4:24 PM Erturk Kocalar <erturkk@...> wrote:

Thank you all very much for the detailed comments and explanation. It makes sense now. (Lee, also thanks for the emails we exchanged about connections a few months ago).

I copy/pasted the tinybasic rom into arduino code and I am working on code to decode the serial output coming thru Q.

Bringing up 1802 taught me a lot about 1802. I am more curious now because it is different from the 8-bit micros. I like to understand more why it was built this way and I also like how CPU helps in I/O and DMA operations at hardware level.

Enjoy your day,
Erturk


On Wed, Jul 17, 2019 at 01:11 PM, Lee Hart wrote:

Erturk Kocalar wrote:

Hi there,

I will appreciate if you can help confirm/debug an unexpected (to me)
1802 behavior after it comes out of reset.

Background: I'm building a bunch of 8-bit microprocessor boards for
Arduino Mega, where Arduino monitors address/data/control signals and
emulates ROM/RAM/peripherals while the microprocessor executes code
(called RetroShield for Arduino Mega). My goal is to build a board for
every 8-bit microprocessor out there (so far I have 6502, 6809, Z80,
8031 and 8085 working).

I brought up the 1802 version yesterday. 1802 is executing my test code
however there is one behavior that doesn't make sense to me.

// 1802 comes out of reset:
0x0000 0xC4, // NOP
0x0001 0xC4, // NOP
0x0002 0x7B, // SEQ <<=== LED turns on.
0x0003 0x69, // INP 1
0x0004 0x61, // OUT 1
*0x0005 **0x7A, // REQ* <<=== *this instruction after OUT 1
is skipped. so LED does not turn off.*
0x0006 0x30, 0x00, // BR $00

Does it make sense if REQ is skipped?

Yes. After reset, P=0 and X=0. The INP and OUT instruction read or write
to the RAM location pointed to by X... which will be R0, which is the
*program counter*.

So the OUT 1 instruction at 0004 writes the following byte (0x7A at
0x0005) to output port 1. It then increment register R(X) (the program
counter, when X=P).

Likewise, the INP instruction reads input port 1, and writes it to the
following address (at 0004). The INP instruction does *not* increment
register X; so if X=P, an INP instruction is a "hit self on head with
hammer" instruction. It writes a byte into the next location, then tries
to execute it!

Set X to something other than P, and initial that registe to point to
some "safe" memory location; and you should be all set.

--
In software development, there are two kinds of error: Conceptual
errors, implementation errors, and off-by-one errors. (anonymous)
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com

Lee Hart
 

Erturk Kocalar wrote:
Bringing up 1802 taught me a lot about 1802. I am more curious now
because it is different from the 8-bit micros. I like to understand more
why it was built this way and I also like how CPU helps in I/O and DMA
operations at hardware level.
The 1802 has always fascinated me as a wonderful example of "just right" design.

The other micros of the time (and today) seem to be designed by committee. The emphasis was on "hurry, hurry, ship it now, Now, NOW". The people on the committes were smart; but had little practical experience in either hardware or software design. They may have "perfected" one area, but left other totally inept.

Here are some guiding principles I like:

1. "Things should be kept as simple as possible; but not too simple". (Albert Einstein)

2. "A design achieves perfection not when there is nothing left to add, but when there is nothing left to take away. " (Antoine de Saint Exupery )

3. "Beware of the Turing tarpit, where everything is possible but nothing of interest is easy." (Alan Perlis)

4. "Verschlimmbessern" (German, verb) - To make something worse by
trying to improve it. (English translation: "Microsoft")

Joe Weisbecker took the time to "perfect" the 1802 design. It has everything you need, and no more. Its hardware features make it easy to interface to just about anything with a minimum of chips. The instruction set seems odd in comparison with what later became "normal"; but it has a consistency and regularity that makes it easy to learn and use. It can easily do things that were difficult to do with other CPUs of the time.

--
In software development, there are two kinds of error: Conceptual
errors, implementation errors, and off-by-one errors. (anonymous)
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com

joshbensadon
 

Erturk,

Your curiosity is well founded. This CPU is an extremely rich collection of features cleverly put together to use a very small number of transistors (about 5,000 if memory serves). Why? The answer is with Joseph Weisbecker. This man was very much into digital electronics since 1950. He worked on many transistor based computers and in 1968 wanted to build a home made computer, like the kits for radios you would see from Heathkit. Of course, Heathkit did eventually put out a computer kit.... in 1978! So Joseph was a decade ahead! Did he know he was a pioneer? He knew well enough that computers were strange things to many people and avoided talking about his plans. On his own dime, he designed and bought all the parts for his home made computer, the FRED. Oh, I guess I should add, he was very much into developing games and other tools to facilitate learning. So FRED stands for Friendly Recreational Educational Device. He saw the value in games and education. Well, long story short, the FRED soon became the COSMAC 00 (check that name?), it was a discrete logic computer. Being discrete logic, he found what features it needed and the best way to do it with the smallest IC count. Something that has inspired a whole generation of engineers, probably (definitely) everybody on this forum! I should mention that Lee Hart has an incredible knack for small IC count solutions.

I did a talk about him at VCF MW last year, I think it's on You Tube. Please have a look.

PS. Congrats on your fine work with the Arduino Mega CPU collection.

Regards,
Josh Bensadon


On Thursday, July 18, 2019, 2:48:58 p.m. EDT, Lee Hart <leeahart@...> wrote:


Erturk Kocalar wrote:
> Bringing up 1802 taught me a lot about 1802. I am more curious now
> because it is different from the 8-bit micros. I like to understand more
> why it was built this way and I also like how CPU helps in I/O and DMA
> operations at hardware level.

The 1802 has always fascinated me as a wonderful example of "just right"
design.

The other micros of the time (and today) seem to be designed by
committee. The emphasis was on "hurry, hurry, ship it now, Now, NOW".
The people on the committes were smart; but had little practical
experience in either hardware or software design. They may have
"perfected" one area, but left other totally inept.

Here are some guiding principles I like:

1. "Things should be kept as simple as possible; but not too simple".
(Albert Einstein)

2. "A design achieves perfection not when there is  nothing left to add,
but when there is nothing left to take away. " (Antoine de Saint Exupery )

3. "Beware of the Turing tarpit, where everything is possible but
nothing  of interest is easy." (Alan Perlis)

4. "Verschlimmbessern" (German, verb) - To make something worse by
trying to improve it. (English translation: "Microsoft")

Joe Weisbecker took the time to "perfect" the 1802 design. It has
everything you need, and no more. Its hardware features make it easy to
interface to just about anything with a minimum of chips. The
instruction set seems odd in comparison with what later became "normal";
but it has a consistency and regularity that makes it easy to learn and
use. It can easily do things that were difficult to do with other CPUs
of the time.

--
In software development, there are two kinds of error: Conceptual
errors, implementation errors, and off-by-one errors. (anonymous)
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com



ian may
 

Josh, your comments about Joseph Weisbecker's early microcomputers are confused.
See http://www.cosmacelf.com/gallery/system-00.html and http://www.retrotechnology.com/memship/cosmac_system_00.html .
Summarizing - Joe's first microcomputer was called "System 00" (not COSMAC 00). The later "FREDs" were a development of "System 00" not the other way around.
Cheers, Ian.

joshbensadon
 

Ian,

Thanks for the corrections.  I guess I should be more careful when stating things, less I pollute history!
Thanks for picking up my "history trash".  I probably read and knew all that, but can't remember things.
I remember Lee calls it "Forgetary".. or something like that...??? Lee?

I appreciate your correction! 

Cheers,
Josh

On Monday, July 22, 2019, 5:15:48 a.m. CST, ian may via Groups.Io <fps16xn3@...> wrote:


Josh, your comments about Joseph Weisbecker's early microcomputers are confused.
See http://www.cosmacelf.com/gallery/system-00.html and http://www.retrotechnology.com/memship/cosmac_system_00.html .
Summarizing - Joe's first microcomputer was called "System 00" (not COSMAC 00). The later "FREDs" were a development of "System 00" not the other way around.
Cheers, Ian.