Topics

RC2014 compatible 1802 card


P Todd Decker
 

I would love to see an 1802 processor board that is pin compatible with the RC2014 z-80 microbus (https://rc2014.co.uk/ ) where all the large growing set of peripheral cards could be used with the 1802.  Someone already did a 6502 board so I know it could be done.  Perhaps another project for my growing project list.

---
P. Todd Decker
913-284-8814


ian may
 

Adapting an 1800 series MPU to the bus of any other contemporary 8 bit MPU will cost you the INP and OUT instructions. Other processors that have input and output instructions put the port address on the address bus and read or write the data to/from the accumulator. The 1800 series MPUs are unique in that they also have the 3 N line I/O address bus. 1800 series MPUs use both the memory address bus and the I/O address bus at the same time for I/O instructions so those instructions can't be used unless there are separate memory address and I/O address buses available.

So an 1802 on the RC2014 bus will have to use memory mapped I/O like the 6502 you mention. Addressing a fixed memory location on a 6502 is a lot easier and faster than having to load the required address into one of the 1802's 16 bit registers before you can access it. A reasonable compromise might be dedicating a register to I/O addressing and loading the required I/O address into the low byte of the register when needed.

Unless there are spare pins available on the bus system you are using, you probably won't be able to use the EFx lines, DMA lines or Q. Do you really want to accept all of these limitations? The expression "horses for courses" comes to mind.
Cheers, Ian.


joshbensadon
 

Another way to interface 1802 I/O to Z80 I/O would be to use one of the N lines (decoded or not) to generate the IOR and IOW signals.
Indeed, the address has to be correct, so let's say N lines decoded for 7 generate IOR, IOW, the instructions to access Z80 port FF would require R(X) to be xxFF.
There was an S100 card with the 1802... I wonder if that's how they did it?

LDI 00
PLO R2
DEC R2   (R2 = xxFF)
PHI R2   (R2 = 00FF)
SEX R2

LDI AA
STA R2
OUT 7     

Regards,
Josh 
Toronto


From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of ian may via groups.io <fps16xn3@...>
Sent: Saturday, September 12, 2020 7:28 AM
To: cosmacelf@groups.io <cosmacelf@groups.io>
Subject: Re: [cosmacelf] RC2014 compatible 1802 card
 
Adapting an 1800 series MPU to the bus of any other contemporary 8 bit MPU will cost you the INP and OUT instructions. Other processors that have input and output instructions put the port address on the address bus and read or write the data to/from the accumulator. The 1800 series MPUs are unique in that they also have the 3 N line I/O address bus. 1800 series MPUs use both the memory address bus and the I/O address bus at the same time for I/O instructions so those instructions can't be used unless there are separate memory address and I/O address buses available.

So an 1802 on the RC2014 bus will have to use memory mapped I/O like the 6502 you mention. Addressing a fixed memory location on a 6502 is a lot easier and faster than having to load the required address into one of the 1802's 16 bit registers before you can access it. A reasonable compromise might be dedicating a register to I/O addressing and loading the required I/O address into the low byte of the register when needed.

Unless there are spare pins available on the bus system you are using, you probably won't be able to use the EFx lines, DMA lines or Q. Do you really want to accept all of these limitations? The expression "horses for courses" comes to mind.
Cheers, Ian.


cmdrcosmac
 

See Kilobaud Microcomputing, June 1979
-Chuck
.


ian may
 

The Kilobaud 1802 S100 bus design uses memory mapped I/O  @ 8200-82FF. The following paragraph is from page 71 and refers to figure 8 in the article.

"The 1802 input/output operations pose a minor problem when using a split data bus. The reason for this can be seen in Fig. 8. During the input instruction the 1802 expects data to flow directly from the I/O device (which outputs onto the Data In bus) to memory (which inputs from the Data Out bus). Therefore, it will be necessary to add logic as shown to connect the two buses during an input operation (the MEMR line is low during an input)."

Figure 8 shows the N lines going to a 3 input OR gate which is used to provide one part of a signal that is generated to connect the S100 data in bus to the 1802's bi-directional data bus. So they are definitely writing about the INP instructions (and therefore probably OUT as well) since those are the only instructions that set the N lines non-zero during execution.

The fundamental problem associated with using the INP or OUT 1802 instructions on the S100 bus has not been considered. Taking the Z80 as an example, it has a pin that indicates that the address bus is carrying EITHER a memory address OR an input/output address. When an 1802 executes an INP or OUT instruction the address bus carries a memory address AND the N lines carry an input/output address, there are two address buses in action at once. So the data flow described above (regarding figure 8) for the INP instruction is actually impossible on the S100 bus.

For your example Josh, if I understand you correctly, there is an I/O device that is accessed INSTEAD of memory at location 00FF, i.e. it is memory-mapped. I'm not sure what you are using for a write signal to this device. If you are using the /MWR from the 1802 then the STA R2 (which I assume is a typo of STR) will write D to the device and I think that is job done. The OUT 7 will also put 00FF on the address bus and set /MRD active. If your hardware uses /MRD to generate the write signal to the peripheral it will write the contents of the data bus into the addressed register. The question is - what's driving the data bus in that situation? It isn't memory because that particular memory address has been designated for input/output operations.

Using a Z80 (or similar) on a bus system with separate memory address and I/O address buses would be possible, you would simply route the required Z80 address lines to the I/O address bus for I/O operations. For an 1802, the memory address bus would be connected to the 1802's address lines and the 1802's N lines (perhaps with some extra bits from a two level I/O scheme) connected to the I/O address bus. Was there ever a (non 1800 series) microprocessor bus with separate memory address and I/O address buses?
Cheers, Ian.


joshbensadon
 

Hi Ian,

It's not as simple as it looks and may even be thought messy, but it would work.

Opps, I did mean STR (forgot the mnemonic, it's been a couple of years).

So, in some way, the 1802 is really using a kind of memory mapped I/O since the I/O is really a form of DMA.  
Of course the memory is real and writes to memory aren't writes to I/O, but any I/O depends on values stored in memory (and not a CPU register).

The example uses I/O address 0xFF since this is the LED/Switch address used on the IMSAI computer.

The I/O circuit would need to steer the DATA-IN to the DATA-OUT bus.
On OUT instructions, that's already happening, since MRD would enable DATA-IN (assuming DATA-OUT is always enabled)
On IN instructions, some logic must be used from the OR'd N lines to enable DATA-IN unless MRD occurs?  Sorry, I need to look at data sheets to sort out the exact details, but suffice to say it shouldn't take much more than a couple of gates.

During I/O the address bus will be simultaneously addressing memory (which is the way of the 1802) and I/O (because this is the way of the S100 bus).
The only pitfall is, the low byte of the memory address will be the I/O address.  This does not seem like a big problem to code around.

Of course Kilobaud design of memory mapped I/O works very well too.  Perhaps it works even better than the 1802 INP & OUT instructions?

In the example, the X register must be set to a memory location (as per 1802 I/O), then the value stored at that location, and the OUT instruction.
For memory mapped I/O, you can use set ANY register and then just store your value... done.

Hmm, after looking at things that way, I believe the Kilobaud design is better.  It's probably easier to implement in hardware and software.  Only costs you a page of memory! (which isn't 100% true since in a way the 1802 I/O also costs memory).

Cheers,
Josh






From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of ian may via groups.io <fps16xn3@...>
Sent: Sunday, September 13, 2020 10:02 AM
To: cosmacelf@groups.io <cosmacelf@groups.io>
Subject: Re: [cosmacelf] RC2014 compatible 1802 card
 
The Kilobaud 1802 S100 bus design uses memory mapped I/O  @ 8200-82FF. The following paragraph is from page 71 and refers to figure 8 in the article.

"The 1802 input/output operations pose a minor problem when using a split data bus. The reason for this can be seen in Fig. 8. During the input instruction the 1802 expects data to flow directly from the I/O device (which outputs onto the Data In bus) to memory (which inputs from the Data Out bus). Therefore, it will be necessary to add logic as shown to connect the two buses during an input operation (the MEMR line is low during an input)."

Figure 8 shows the N lines going to a 3 input OR gate which is used to provide one part of a signal that is generated to connect the S100 data in bus to the 1802's bi-directional data bus. So they are definitely writing about the INP instructions (and therefore probably OUT as well) since those are the only instructions that set the N lines non-zero during execution.

The fundamental problem associated with using the INP or OUT 1802 instructions on the S100 bus has not been considered. Taking the Z80 as an example, it has a pin that indicates that the address bus is carrying EITHER a memory address OR an input/output address. When an 1802 executes an INP or OUT instruction the address bus carries a memory address AND the N lines carry an input/output address, there are two address buses in action at once. So the data flow described above (regarding figure 8) for the INP instruction is actually impossible on the S100 bus.

For your example Josh, if I understand you correctly, there is an I/O device that is accessed INSTEAD of memory at location 00FF, i.e. it is memory-mapped. I'm not sure what you are using for a write signal to this device. If you are using the /MWR from the 1802 then the STA R2 (which I assume is a typo of STR) will write D to the device and I think that is job done. The OUT 7 will also put 00FF on the address bus and set /MRD active. If your hardware uses /MRD to generate the write signal to the peripheral it will write the contents of the data bus into the addressed register. The question is - what's driving the data bus in that situation? It isn't memory because that particular memory address has been designated for input/output operations.

Using a Z80 (or similar) on a bus system with separate memory address and I/O address buses would be possible, you would simply route the required Z80 address lines to the I/O address bus for I/O operations. For an 1802, the memory address bus would be connected to the 1802's address lines and the 1802's N lines (perhaps with some extra bits from a two level I/O scheme) connected to the I/O address bus. Was there ever a (non 1800 series) microprocessor bus with separate memory address and I/O address buses?
Cheers, Ian.


Lee Hart
 

joshbensadon wrote:
It's not as simple as it looks and may even be thought messy, but it
would work.
The S-100 bus has defined extra address bits, so it can address beyond 64K. But they are ignored if you only have 64K of memory.

I wonder if it would be possible to put the 1802's N0-N2 on A16-A18? You would need hardware that watches these lines. If they are 000, then it is a normal memory cycle. But if they are 001 to 111, then it is an 1802 I/O cycle. Let the bus read or write memory as usual, but the data on the bus either gets latched into your output port (OUT), or your input port puts its data byte on the bus (INP).

If it was necessary to read/write to an existing I/O port that was built for an 8080 or Z80 I/O addressing, you could build an 1802 CPU board that had an on-board port that INP or OUT instructions used. Then hardware could WAIT the 1802, and do a second I/O cycle to read or write that byte to the 8080/Z80 port address. A small PAL or even a PIC or Atmel micro implement the logic.

Lee

--
A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away.
-- Antoine de Saint Exupery
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com


ian may
 

Firstly - I need to correct an error I made in my previous post. I wrote "Taking the Z80 as an example, it has a pin that indicates that the address bus is carrying EITHER a memory address OR an input/output address." It is the 8085 that uses a single pin to indicate memory or I/O address, the Z80 has separate memory and I/O request lines.

Josh, are you and I thinking about different system designs? The system I'm thinking of has 3 boards connected to a system bus.  One board is the processor, one board is memory and the third board is the I/O device. Are you thinking of a system that has 2 boards, one is the processor with memory, and the other is the I/O device? I understand how the combined processor and memory board could allow use of the INP and OUT instructions, since the system bus would only need to handle the single transaction of reading the I/O device. The problem with the 3 board system (when trying to use the INP and OUT instructions) is that the system bus has to perform two transactions at once, reading the I/O device and writing to memory at the same time. After consulting my copy of "interfacing to S-100/IEEE 696 microcomputers", for a 3 board S100 system doing an INP instruction, pDBIN would need to be asserted because an I/O read is being performed. The memory card would also receive pDBIN indicating read but the memory needs to be configured for writing so I don't think the 3 board S100 configuration could be made to work.

Since the RC2014 bus is the subject of this thread what happens with that? The RC2014 system design philosophy seems to be "one function per PCB". The signals on the bus are the signals to/from the Z80 which is on one PCB. Memory is another PCB and I/O is on another. I/O devices are enabled by /IORQ and memory devices are activated by /MREQ. The /RD and /WR lines are common to memory and I/O PCBs. So for an INP instruction asserting /IORQ and /RD would allow reading an I/O device, and asserting /MREQ and /WR would be required to write to memory. While asserting /MREQ and /IORQ at the same time is not something a Z80 would do, the problem is telling the I/O device to read and the memory to write at the same time. For that reason I would argue that an 1802 on the RC2014 bus can't use the INP and OUT instructions.
Cheers, Ian.


joshbensadon
 

Ian,

I see your point and it makes sense that Kilobaud got it right by doing memory mapped I/O.  Indeed, on a 3 board S100 system, and on the RC2014 Z80 system the idea of directing the /RD to the IO board while sending a /WR to the Memory board is not possible on a common bus.  You are right, the use of pDBIN & pWR in the 8080 and /MREQ & /IOREQ in the Z80 make the 1802 INP/OUT system (a system of DMA) impossible.  The 1802 INP/OUT could only work if the memory is on the same cpu card, this way, you can fake the data transfer to let the bus think it's going from the I/O board to the CPU. 

PS. Sorry, I'm not familiar with the RC2014.  I had a look at it briefly while I was writing firmware for Lee's Z80MC system but I don't recall anything special.

Cheers,
Josh




From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of ian may via groups.io <fps16xn3@...>
Sent: Monday, September 14, 2020 8:56 AM
To: cosmacelf@groups.io <cosmacelf@groups.io>
Subject: Re: [cosmacelf] RC2014 compatible 1802 card
 
Firstly - I need to correct an error I made in my previous post. I wrote "Taking the Z80 as an example, it has a pin that indicates that the address bus is carrying EITHER a memory address OR an input/output address." It is the 8085 that uses a single pin to indicate memory or I/O address, the Z80 has separate memory and I/O request lines.

Josh, are you and I thinking about different system designs? The system I'm thinking of has 3 boards connected to a system bus.  One board is the processor, one board is memory and the third board is the I/O device. Are you thinking of a system that has 2 boards, one is the processor with memory, and the other is the I/O device? I understand how the combined processor and memory board could allow use of the INP and OUT instructions, since the system bus would only need to handle the single transaction of reading the I/O device. The problem with the 3 board system (when trying to use the INP and OUT instructions) is that the system bus has to perform two transactions at once, reading the I/O device and writing to memory at the same time. After consulting my copy of "interfacing to S-100/IEEE 696 microcomputers", for a 3 board S100 system doing an INP instruction, pDBIN would need to be asserted because an I/O read is being performed. The memory card would also receive pDBIN indicating read but the memory needs to be configured for writing so I don't think the 3 board S100 configuration could be made to work.

Since the RC2014 bus is the subject of this thread what happens with that? The RC2014 system design philosophy seems to be "one function per PCB". The signals on the bus are the signals to/from the Z80 which is on one PCB. Memory is another PCB and I/O is on another. I/O devices are enabled by /IORQ and memory devices are activated by /MREQ. The /RD and /WR lines are common to memory and I/O PCBs. So for an INP instruction asserting /IORQ and /RD would allow reading an I/O device, and asserting /MREQ and /WR would be required to write to memory. While asserting /MREQ and /IORQ at the same time is not something a Z80 would do, the problem is telling the I/O device to read and the memory to write at the same time. For that reason I would argue that an 1802 on the RC2014 bus can't use the INP and OUT instructions.
Cheers, Ian.


Lee Hart
 

joshbensadon wrote:
I see your point and it makes sense that Kilobaud got it right by doing
memory mapped I/O. Indeed, on a 3 board S100 system, and on the RC2014
Z80 system the idea of directing the /RD to the IO board while sending a
/WR to the Memory board is not possible on a common bus.
I'm not familiar with the RC2014 system, either. But it sounds like it uses the Z80's address, data, and control signals as its bus?

If so, and you want to stay with the idea of separate boards for CPU, memory, and I/O; then an 1802 CPU board will have to be restricted to memory-mapped I/O. Or, the 1802 CPU board will need special logic to convert the 1802's one-cycle OUT and INP instructions into two bus cycles:

- OUT would need to
1. read the data from the address,
2. write the data to the Output port.

- INP would need to
1. read the data from the Input port,
2. write the data to the address.

This is actually not too hard, given the 1802's speed. Most memory and I/O devices are fast enough so that both cycles could be performed in one 1802 8-clock bus cycle time. Consider an OUT instruction:

- At the end of TPA, the full address is available, /MRD can set bus /RD low to read system memory.
- About 1 clock cycle later, the memory will have the data ready for the output device.
- Latch the data; and then set /RD back high to disable memory.
- Switch the address bus to the desired output port. 3 bits could be the 1802 N-lines. The other port bits could come from a "port" latch that the 1802 previously set; or just pullup/pulldown resistors to give them a default state.
- set /IORQ and /WR low to perform the needed write cycle (to write the latched address data into the desired output port).

A similar procedure could be used for INP.


Tain't easy; but ain't impossible, neither!

Lee
--
A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away.
-- Antoine de Saint Exupery
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com


 

On Fri, Sep 11, 2020 at 09:40 PM, P Todd Decker wrote:
I would love to see an 1802 processor board that is pin compatible with the RC2014 z-80 microbus (https://rc2014.co.uk/ ) where all the large growing set of peripheral cards could be used with the 1802.  Someone already did a 6502 board so I know it could be done.  Perhaps another project for my growing project list.
Hi Todd and gang:

Is it correct that the A0..A15 address lines on the RC2014 bus carry a memory address (0..65535) during a memory request and an I/O address (0..255) during an I/O request?  Also, do any RC2014 I/O cards use I/O addresses other than 0..255?  In other words, do we need to worry about the A8..A15 address lines when performing an I/O request?

As mentioned...  if the '1802 CPU card includes all its own memory, would it be possible to implement a relatively simple 2-level I/O sub-system on the bus using two '1802 ports?  One port to set a latch for the I/O address (0..255) which is pushed onto the A0..A7 address lines during an I/O request (and decoded separately on each I/O card), and another port to perform the actual I/O request?  I wonder if something like the attached untested circuit might work?  It's based on examples I've studied from Mike (Riley), Bob, Dave, Todd, and others.


Regards, Mike





P Todd Decker
 

If the card carried its own memory, then this clever solution might be just what is called for.  It would enable the use of RC2014 I/O cards.  Thank you for taking the time to craft the excellent diagram.  I’m excited enough about the prospects that I’ll probably take on creating an 1802 card for the RC2014 just as soon as I get my RC2014 fully working (getting very close now).

---
P. Todd Decker
913-284-8814

On Sep 15, 2020, at 11:44 PM, Mike McLaren, K8LH <k8lh@...> wrote:

On Fri, Sep 11, 2020 at 09:40 PM, P Todd Decker wrote:
I would love to see an 1802 processor board that is pin compatible with the RC2014 z-80 microbus (https://rc2014.co.uk/ ) where all the large growing set of peripheral cards could be used with the 1802.  Someone already did a 6502 board so I know it could be done.  Perhaps another project for my growing project list.
Hi Todd and gang:

Is it correct that the A0..A15 address lines on the RC2014 bus carry a memory address (0..65535) during a memory request and an I/O address (0..255) during an I/O request?  Also, do any RC2014 I/O cards use I/O addresses other than 0..255?  In other words, do we need to worry about the A8..A15 address lines when performing an I/O request?

As mentioned...  if the '1802 CPU card includes all its own memory, would it be possible to implement a relatively simple 2-level I/O sub-system on the bus using two '1802 ports?  One port to set a latch for the I/O address (0..255) which is pushed onto the A0..A7 address lines during an I/O request (and decoded separately on each I/O card), and another port to perform the actual I/O request?  I wonder if something like the attached untested circuit might work?  It's based on examples I've studied from Mike (Riley), Bob, Dave, Todd, and others.


Regards, Mike




<RC2014 Bus.png>


ian may
 

In this thread so far, Lee has posted a couple of I/O scheme ideas and Mike wrote about Mike Riley's (et al) 2 level design. Would starting a new thread titled something like "I/O addressing schemes" be worthwhile for the benefit of others (i.e. those not interested in RC2014 or readers searching the group for I/O information in the future)?
Cheers, Ian.


Gregg Levine
 

Hello!
Well yes and no. Yes because there might be people interested in other
ideas. For example on the forum that supports the Parallax hardware, a
chap came up with a dandy use for the Propeller, that of the use as an
intelligent terminal controller. He did that with several different
processor designs.

The no part is related to that issue.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."

On Thu, Sep 17, 2020 at 8:54 AM ian may via groups.io
<fps16xn3=yahoo.com@groups.io> wrote:

In this thread so far, Lee has posted a couple of I/O scheme ideas and Mike wrote about Mike Riley's (et al) 2 level design. Would starting a new thread titled something like "I/O addressing schemes" be worthwhile for the benefit of others (i.e. those not interested in RC2014 or readers searching the group for I/O information in the future)?
Cheers, Ian.

And this space is being used as a Bantha parking space.


Stuart Remphrey
 

On Tue, Sep 15, 2020 at 09:44 PM, Mike McLaren, K8LH wrote:
Is it correct that the A0..A15 address lines on the RC2014 bus carry a memory address (0..65535) during a memory request and an I/O address (0..255) during an I/O request?
Someone on this list will probably know this better, but IIRC from the chip layout: the Z80 gates the immediate I/O address value onto the low 8 bits of the address bus, and the contents of the B(?) register onto the high 8 bits (a consequence of the register-addressed variant that uses C for the low-order bits).
Most systems just use an 8-bit I/O address space and ignore the upper bits, but it is possible to run a 16-bit space.

Also, do any RC2014 I/O cards use I/O addresses other than 0..255?  In other words, do we need to worry about the A8..A15 address lines when performing an I/O request?
I presume the upper 8 bits would ignored.


Lee Hart
 

Hi all,

Let me back up a bit. What are the reasons for making an 1802 CPU board compatible with the RC2014 bus? Are there peripherals for the RC2014 that people feel they "must have" for the 1802? I'm not familiar with the RC2014, but in a quick look I didn't see any boards that were especially cheap or powerful. And you'd have to re-write all the software for the 1802 anyway.

Maybe we should re-think the idea a bit. We could simply add more pins to the bus header, to accommodate the 1802's extra I/O pins. 1802-compatible boards would use these extra pins; existing RC2014 boards would just ignore them.

Or, perhaps forget strict compatibility, and just re-purpose some pins on the RC2014 bus for our own uses.

It's mighty simple to make a bus-oriented 1802 computer with a 40-pin bus between boards that is nothing but the 1802's own pins! We could make something that looks like the RS2014 form factor, but is in fact an Elf.

Lee Hart


--
Excellence does not require perfection. -- Henry James
--
Lee A. Hart http://www.sunrise-ev.com


P Todd Decker
 

Lee,

Your question is very valid.  I only suggested it because I’m enjoying the RC2014 format.  It feels like a very accessible “mini” S-100 kind of set-up.  And, there is a big following around it.  So, my thinking is that if we had an 1802 CPU board that could plug into it, we might be able to highlight the 1802 platform to a new group.  I also recall back in the late 70’s Ohio Scientific had a board that always fascinated me.  It was a 6800, 6502, and 8080 (might have been Z80) board that provided all three—somewhat of a novelty at the time I imagine.

From the personal side, why I liked the idea, is it would help cut down on the growing proliferation of retro computing platforms I have on my shelf if I could have one bus that supports all my interests.  For example, the RC2014 has a great terminal card based around the raspberry pi. I’m also making an rom burner card for it and would love to have the same for 1802 and don’t need two.  It also has cards that support SD, USB, and CF cards for storage.  And, it has some good old graphic chip cards (of which we could add a PIXIE card). And, more recently some cards are coming out for the various retro sound chips (SID, etc.).

---
P. Todd Decker
913-284-8814

On Sep 17, 2020, at 12:59 PM, Lee Hart <leeahart@...> wrote:

Hi all,

Let me back up a bit. What are the reasons for making an 1802 CPU board compatible with the RC2014 bus? Are there peripherals for the RC2014 that people feel they "must have" for the 1802? I'm not familiar with the RC2014, but in a quick look I didn't see any boards that were especially cheap or powerful. And you'd have to re-write all the software for the 1802 anyway.

Maybe we should re-think the idea a bit. We could simply add more pins to the bus header, to accommodate the 1802's extra I/O pins. 1802-compatible boards would use these extra pins; existing RC2014 boards would just ignore them.

Or, perhaps forget strict compatibility, and just re-purpose some pins on the RC2014 bus for our own uses.

It's mighty simple to make a bus-oriented 1802 computer with a 40-pin bus between boards that is nothing but the 1802's own pins! We could make something that looks like the RS2014 form factor, but is in fact an Elf.

Lee Hart


--
Excellence does not require perfection. -- Henry James
--
Lee A. Hart http://www.sunrise-ev.com







Tony
 

I had that exact idea. I was thinking I could use an RC2014 backplane, and maybe place a few signals like the serial TX and RX in the same places so that a couple of the RC2014 peripheral boards might work, but otherwise come up with an 1802-specific pinout. It would be simple to come up with processor, clock, and memory boards. Then there could be 1861, terminal, or hex IO boards.

The problem is that there are just too many interesting projects to do, and I got distracted by implementing an ELF-style computer on an Intel MAX10 FPGA. I made an interface for a 24-key customizable USB keypad to function as a Quest Super Elf-style hex keypad for it. Right now I'm working on a design to connect one of those 128x64 OLEDs and have it appear as an 1861. I'm mapping 64x64 and 64x32 mode on to the 128x64 display by doubling the 64 pixels in the horizontal direction and skipping every other horizontal line. I'm thinking instead of supporting the 1861 64x128 mode, I'll use the same DMA bus cycles but treat it as 128x64 and map it directly to the display. I'd like to get a monitor and BASIC up and running on it.

I've got a Membership Card and a couple of prototype boards. I thought it might be cool to put a bunch of level translators on one of the prototype boards so I could make 3.3V expansion cards. I was looking at a parallel to i2c bridge chip that I thought might be neat for interfacing a real-time clock or some other interesting i2c sensors with the 1802.

I've also got my original Netronics Elf II with a Quest Super Expansion Board that I'd like to get up and working again. I recently got my Netronics video terminal board and George Risk keyboard up and running with an amazing 64 characters x 16 lines (upper and lower case!) at a whopping 300 baud.

Too many projects; never enough time.


Gaston Williams
 

Hi Tony,
I have an I2C 128x64 OLED running pixie video at 64x64 and 64x32 resolution simulating an 1861.  You can find pictures, a schematic and other details about it on github in the fourstix/MCard1802TeensyPixieVideo project.  It's worked with all the 1861 code I've tested it with.

The Teensy 3.2 is just running a state machine counting instruction cycles so one could replace the Teensy with something else like a an FPGA if you prefer.   There are a lot of comments in the code that detail that signals for the states.  Also the bit routines for expanding and mapping the video data for the OLED XBMP display format is already worked out and documented.  I found those to be a little bit tricky. 

If you have any trouble understanding or re-using the code. I'd be happy to help answer any questions.  I'm toying with the idea of making a version for an SPI OLED display instead of an I2C OLED display.  The larger OLED graphic displays tend to use SPI rather than I2C.

Have a great day,
Gaston (fourstix)


Lee Hart
 

Gaston Williams wrote:
I have an I2C 128x64 OLED running pixie video at 64x64 and 64x32
resolution simulating an 1861... The Teensy 3.2 is just running a state machine counting instruction
cycles so one could replace the Teensy with something else like a an
FPGA if you prefer.
Gaston, how does the Teensy "capture" the DMA data from the 1802? Does it count, or control the 1802's clock cycles so it somehow "knows" which bus cycles are intended as 1861 data?

If the Teensy is fast enough to spot a DMA cycle and capture its data, then I have an idea that could considerably improve video performance.

With the 1861, any data on the screen got put there by the 1802 writing it into video RAM. The DMA cycles themselves aren't necessary. They are just how that block of RAM gets displayed by the 1861.

So, instead of the Teensy looking for a DMA cycle, suppose it instead looks for a write cycle to any address in video RAM. Perhaps a comparator generates an interupt to the Teensy when it detects a write to the video page address.

The Teensy interrupt handler then captures the address and data to save it in its own RAM buffer. It can then return from its interrupt routine to its main program.

The Teensy's main program can then format and send the bytes in its buffer to the LCD (via I2C or SPI). Both of them are clocked, so it shouldn't matter if this routine gets interrupted.

In effect, this means the 1802 is running at twice the speed (no DMA cycles). It still has its 60 Hz vertical interrupt, so timekeeping still works. But this interrupt routine is tiny in comparison to the 1861's interrupt routine.

Video is being generated *in parallel* by the Teensy. So video updates should be much faster; basically as soon as the 1802 changes a byte in its video RAM, it gets reflected in the LCD almost instantly in the LCD. :-)

Lee Hart

--
A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away.
-- Antoine de Saint Exupery
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com