Interested in a home brew Z80 computer project?

[ziloo]

Addressing

Addressing

Hello Andrew,

Would you please take your time (????) and explain a bit more about
addressing on your Dandy board?

1- Signals such as CS_CFG, and CFG...
2- Logic to ensure upper Ram is always enabled

Thank you

ziloo

 

[NobodyIsHere]

Hello Andrew,

Would you please take your time (????) and explain a bit more about
addressing on your Dandy board?

1- Signals such as CS_CFG, and CFG...
2- Logic to ensure upper Ram is always enabled

Thank you

ziloo

Hi! Sure no problem.

The signals with the CS_ prefix are used for IO decoding and stands for Chip Select. There is some IO address decode logic which detects when the CPU is requesting the onboard IO devices. Specifically, any time the CPU is requesting IO (/IORQ low) and the address on the lower 8 bits of the address bus are in the $60-7F range.

When those conditions are met, the 74LS139 demultiplexer narrows it down further into specifically what IO device is being requested. It generates "Chip Select" signals for the 8255 PPI if the address is $60-$67, the 16550 UART for $68-$6F, the RTC for $70-77, and the MPCLs for $78-7F. The "Chip Select" signal is normally high but when the CPU wants to connect to a specific IO device, it pulls the devices "Chip Select" pin low to force the device out of "tristate mode" and actively on to the buses. Each of the CS_* lines go to the chip select pins on the various IO devices.

The normal state for IO devices when not being specifically accessed is to be in tristate mode. They are physically connected but all the inputs are in a very high impedance state so they act like they are not present in the circuit.

Regarding the logic to ensure the Upper RAM is always selected is something different and relates only to memory mapping. One thing I found during the design phase is the CPU has to have some region of memory which is essentially permanent so it can retain its own context.

There are two memory pages, the lower 32K and the upper 32K, and the lower 32K page is switchable. As a result, the 74LS32at U15 ensures the upper 32K page ALWAYS goes to the same region of the 512K SRAM (A15, A16, A17, A18 all high). No matter what the CPU does to the MPCLs to reconfigure memory, it is ensured that the program actually making the changes (assuming it is in the upper 32K RAM page) is always present in the address space. It may seem silly but you'd be surprised at how easy it is for a CPU to manipulate memory and suddenly it loses all context and crashes.

After reviewing the schematic, I noticed the terminology I used during the hardware phase is not the same as what I described during the software phase. I'll update the schematic to make sure it is more consistent with the terms used in the software source code. It is confusing when I use two different terms to refer to the same item.

Thanks and have a nice day!

Andrew Lynch

 

[ziloo]

Hello Andrew,

Would you please explain about "ECB data flow direction control"?
How does it switch direction?

Thank you

ziloo

 

[NobodyIsHere]

Hello Andrew,

Would you please explain about "ECB data flow direction control"?
How does it switch direction?

Thank you

ziloo

Hi,

The ECB bus control is in two parts; the address/control lines and the data lines. I'll explain the address/control lines first since those are easier.

The address/control lines are "export only" from the SBC perspective virtually all the time. In other words, the address/control lines are repeated from inside the SBC onto the ECB but not vice versa. The only exception to that is when something on the bus asserts bus control by lowering the /BUSRQ line. In that case, the CPU goes into BUSRQ mode and the ECB places the address/control lines into the SBC. Again, this is a pretty rare scenario but it is possible and the SBC supports it if and when a "bus mastering" peripheral is ever made. Possibly another CPU card could do this.

The SBC data lines are "import and export" depending on the situation. Normally, the SBC exports the data lines onto the ECB and does not import them. There is two exceptions though; first is the /BUSRQ being pulled low by a yet undesigned peripheral which is pretty rare, and more likely is the SBC CPU has made a IO request READ (/IORQ goes low and /RD is low) AND the IO address is outside of the internal SBC IO range ($60-$7F). In other words, the CPU is requesting to IO reads to IO address EXTERNAL to the SBC.

In all cases, it is fairly rare for the SBC to be pulling information (address, control, or data) in from the ECB. Normally, it just transmits the internal CPU bus onto the ECB for peripherals to observe and act on.

Now you may have noticed one peculiarity about this implementation of the ECB. The SBC supports CPU MEMORY WRITES (/MERQ low and /WR low) onto the ECB but it does NOT support CPU MEMORY READS from memory on the ECB. The address, control, and data lines are all there to perform the task but the SBC internal bus control logic is limited for the sake of simplicity. Also, the 1M ROM and 512K RAM is likely sufficient for actual real memory for a relatively simple CP/M or monitor based system. More than that would probably go to a secondary store like a disk drive.

If and when there is ever a next generation SBC, I will probably change the bus control logic to allow CPU MEMORY READS across the ECB. The modification would require changes to the RAM/ROM memory selection logic to allow RAM disabling in order to leave the lower 32K page fully deselected (ie, nothing is there at all, no internal RAM nor ROM) so the ECB peripheral memory would have a "hole" in the CPU address space to exist in. Also, the bus control logic would be changed to allow changing the data bus direction flow in to the SBC from the ECB whenever the SBC requests a memory write from the lower 32K memory page AND the lower 32K memory page has been disabled.

Probably, I could have made those modifications in the initial design but I put them off to lower the risk down on this SBC design. I had strayed off my prototype already in a few areas and I wanted to make sure the PCB version was fairly close to prototype to increase the likelihood it would work. PCB respins are expensive in terms of time and money so risk introduced by "feature creep" is highly undesirable.

In practical terms, having an IO only ECB is not a limitation for all the peripherals I would like to make. Virtually all of the Z80 style peripherals communicate via a IO ports. Even the "pipe dream" video cards (SY6545 and TMS9918) use IO ports only. What would be more difficult to implement would be ECB memory expansion (RAM/ROM) or memory mapped peripherals like a 6845 VDU. However, even those are possible by just using IO ports and latches to simulate the memory accesses. In other words, we are a LONG WAYS away from ever encountering this theoretical limitation and if and when it ever does get realized, there are relatively simple fixes to either get around it or resolve it as needed.

Hopefully this helps explain the SBC ECB bus design a little better. Please let me know if you have any questions. Thanks and have a nice day!

Andrew Lynch

 

[ziloo]

Hail great Andrew,

1- what is the role of A1 and A2 in extended Ram/Rom
addressing and why?

2- Who/What is taking care of stack manipulation when in
extended addressing mode?

ziloo

 

[MikeS]

OK, now I'm confused; aren't the SY6545 and the MC6845 more or less the same? Why would one be I/O driven and the other memory mapped? And wouldn't you pretty well need to share the display memory anyway unless you're going to run a sort-of internal terminal?

And BTW: I can deduce what it does, but what does MPCL stand for?

I've still got some 4MHz Z80s in case anybody wants any.

mike

 

[NobodyIsHere]

Hi Mike,

Yes the SY6545 and MC6845 are very similar but the SY6545 is a later and improved part. It has the IO port addressable video RAM feature the MC6845 lacks. The MC6845 requires some memory mapped interface to change the contents of the video RAM but the SY6545 has a provision to access the entire chip and all video RAM via IO port commands. It is very much nicer for Z80/8080 style CPUs to use the chip. Kaypro 10's and some other systems use SY6545 for this very reason. The MC6845 is great for Motorola/Mostek style CPUs with dual phase clocks but a PITA for everyone else.

MPCL = Memory Page Configuration Latch. Thanks and have an nice day!

Andrew Lynch

 

[NobodyIsHere]

Hail great Andrew,

1- what is the role of A1 and A2 in extended Ram/Rom
addressing and why?

2- Who/What is taking care of stack manipulation when in
extended addressing mode?

ziloo

Hi! The A1 and A2 are used in the IO decoding of the RAM or ROM MPCLs. Remember, Z80 circuits and peripheral chips are all active low logic (ie, when high = not enabled, when low = enabled) The OR gate acts like an AND gate in "active low" logic mode.

If A2 = 0 and A1 = 0 and /CS_CFG = 0 then /CS_CFG1 = 0 (ie, enable the chip select on the RAM MPCL chip.)

If A2 = 1 and A1 = 0 and /CS_CFG = 0 then /CS_CFG2 = 0 (ie, enable the chip select on the ROM MPCL chip.)

The "active low" logic has a nasty tendency to turn all of what you learned in school on its head but after you work with it a while it starts to make sense.

Regarding the CPU STACK while in extended addressing; the stack is set in the upper 32K memory page because it is permanent. This is one of the many reasons why the upper 32K *must* be fixed is that the CPU has to be able to depend on being able to correctly access its stack during memory map manipulations. If the stack is $FF00-$FFFF and that 32K RAM page is permanently fixed to the same physical RAM 32K block then the CPU is assured that when it pulls its context off the stack (ie returns from an interrupt or subroutine) it gets the right stuff and not some random garbage that just got paged in.

You'd be surprised at how hard it was for me to learn that particular lesson. Lose the stack and the CPU quickly goes insane! CPU context bugs are tough and can be hard to get your head around all the permutations and combinations it can manifest itself. Stack loss is just one of many... accidentally trashing a good stack is another as is changing the RAM context in midstream due to a memory page switch (ie, never execute code in the lower 32K memory page while switching memory page context!). Hopefully, this clarifies things a bit!

Thanks and have a nice day!

Andrew Lynch

 

[MikeS]

Re: 6545/6845
Thank you, Andrew; I didn't know that. I was pretty sure that the 6545 is a direct replacement for the 6845 but never knew that it had that extra mode; I've only seen both of them used in 68xx/65xx circuits where they used the 2-phase clock to essentially have dual-port screen memory. Can't do that with a Z80, eh? Pity... ;-)

Is this ECB bus a well-defined *standard* by the way, i.e. are ECB Z80 peripheral boards described and available elsewhere likely to easily interface to your SBC, at least at the hardware level?

m

 

[NobodyIsHere]

Re: 6545/6845
Thank you, Andrew; I didn't know that. I was pretty sure that the 6545 is a direct replacement for the 6845 but never knew that it had that extra mode; I've only seen both of them used in 68xx/65xx circuits where they used the 2-phase clock to essentially have dual-port screen memory. Can't do that with a Z80, eh? Pity... ;-)

Is this ECB bus a well-defined *standard* by the way, i.e. are ECB Z80 peripheral boards described and available elsewhere likely to easily interface to your SBC, at least at the hardware level?

m

Hi Mike,
Sure, no problem! Z80 can be interfaced with the MC6845, it just a PITA and requires special latching to synchronize the memory accesses. It also chews up precious address space and is generally troublesome. There are a few Z80/MC6845 systems out there though. The PROF80/GRIP is a good example. I'd like to make one someday...

The ECB is a well defined standard, hardware and interface. The standards are mostly in German, who apparently have a national love affair with the Z80 as it seems a good chunk of the Z80 home brew projects are German. No offense to all of my German friends... (it certainly is understandable...)

http://www.hardwarebook.info/ECBbus

http://www.prof80.de/circ_a02.html

http://de.wikipedia.org/wiki/ECB-Bus

Thanks and have a nice day!

Andrew Lynch

 

[ziloo]

Hi Andrew,

1- what is the role of A1 and A2 in extended Ram/Rom
addressing and why?

...The A1 and A2 are used in the IO decoding of the RAM or ROM MPCLs.

My bad...and thank you for clarifying it Andrew! I was under the impression that
you will be using the Data lines to enable and establish the Ram/Rom page, but
you are actually using the Address lines in addition to Data lines. So you would be
using:

Out Ad, Da

where, Ad represents A7 A6....A2 A1 A0 and Da represents D7 D6....D0 .

Why aren't you using A0?

Thank you

ziloo

 

[NobodyIsHere]

Hi,

Well, sort of. Yes, the address lines are used by the IO decoding circuit to identify the appropriate MPCL (RAM or ROM) and the data lines set the values in MPCL. However, the CPU address or data lines do not explicitly set the extended address lines on the RAM or the ROM, the CPU only tells the MPCL to do it.

It is a subtlety but an important one; the MPCLs act effectively as an extension of the CPU for higher memory accesses and they are accessed as IO port devices. Otherwise the CPU would have no way of controlling the memory in excess of 64K using its 16 address lines.

In other words, the CPU manipulates the MPCLs and the MPCLs control the RAM and ROM extended addressing. It is an indirect relationship but it works. Of course a Z80 with a 20, 24, or 32 bit address bus would make this unnecessary but then you'd have an 8088, Z8000, etc.

Thanks and have a nice day!

Andrew Lynch

PS, I am not using A0 as part of the IO decoder as each device is allocated an 8 address range for IO ports. It is unnecessary as the MPCLs each have their IO address mirrored across 4 addresses (RAM MPCL is $78-$7B, ROM MPCL is $7C-7F). The reason is the UART requires 8 addresses for control and to keep the decoder logic simple and small, I allow a 32 address range of IO ports dedicated to the "on board" IO devices (PPI, UART, RTC, and MPCLs).

 

[ziloo]

Hello again,

...the address lines are used by the IO decoding circuit to identify the appropriate
MPCL (RAM or ROM) and the data lines set the values in MPCL...

The point I am making is that by using an "Out Ad, Da" command you would be
placing the appropriate signals on the lines for the decoding section (MPCL) to
access the IO device. It is the Out instruction that is doing the job.

...I am not using A0 as part of the IO decoder as each device is allocated an 8 address range for IO ports. It is unnecessary ...

I am saying that you could have used A0 & A1 instead of A1 & A2, but you just
chose A1 & A2 instead.

Thank you

ziloo

 

[NobodyIsHere]

Hi!

Oh, I see what you are saying... yes, the OUT instruction is used for setting the extended addressing. The CPU uses data and address lines to with the OUT instruction accessing the MPCLs.

I could have used the A0 address line as part of the decoding and it would have worked. My thought was to keep the RAM MPCL IO port in on region ($78-$7B) and the ROM MPCL in another ($7C-$7F). Using A0 would have caused the IO ports to alternate on even/odd addresses but since practically speaking you really only access a single IO port how they are mirrored is not much of an issue.

If I had more PCB room, I would change the IO decoding logic to be a lot more specific and only the minimum necessary IO ports and reduce the usage of IO address space. However, in order to keep the design simple there was some trade off with efficiency. Its design artifacts like this which make using large PCBs and/or custom chips so appealing but of course that drives cost. Its all a trade off in the end...

Great questions and good observations! Thanks and please let me know if there are any other aspects I can help with!

Andrew Lynch

 

[Druid6900]

Well, Andrew, you certainly won't have to worry about writing technical documentation on Da'Andy, you can just come back to this thread and vacuum up all the posts LMAO.

 

[NobodyIsHere]

Hi!

Well, that is a pretty good idea! I do want to document the SBC and capture all the design information. I suspect we will be seeing even more questions once people start actually building them...

That is a good thing though. I guess we will see in a few days.

Thanks and have a nice day!

Andrew Lynch

 

[ziloo]

Hello Andrew,

Looking at the scematics for your Dandy board, some clarification would be very
helpful regarding the role of A15:

1- whenever A15=1 (high) --> Ram is selected
2- whenever A15=0 (low ) & Rom is NOT enabled (Rom_Enable=1) --> Ram is selected
3- whenever A15=0 (low ) & Rom is enabled (Rom_Enable =0) --> Rom is selected

4- whenever A15 = 1 --> we are in the higher 32k
5- whenever A15 = 0 & Ram is selected --> we are in the lower 32k

Higher 32k, one page only
                     A15 A14 A13 A12 A11 A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0
                      1      -      -       -      -       -     -     -     -   -    -    -     -     -    -     -	 
  1     1     1       1      -      -       -      -       -     -     -     -   -    -    -     -     -    -     -		
A'18  A'17  A'16    A'15 A14 A13 A12 A11 A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0

 Lower 32k, 8 pages                 
                      A15 A14 A13 A12 A11 A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0
                      0      -      -       -      -       -     -     -     -   -    -    -     -     -    -     -	 
  -     -     -       0      -      -       -      -       -     -     -     -   -    -    -     -     -    -     -		
A'18  A'17  A'16     A'15 A14 A13 A12 A11 A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0

where, A' is A_Ram in schematics
       - can be any binary value.

Generally speaking, stack pointer SP has no idea which page we are in, and I assume it
always refers to the higher 32k where our main program is located. Thus any line of
program placed on other pages that uses Call or RET would end up in the LA-LA land unless
we can devise a very sophisticated stack manipulation manager.

Any comment would be much appreciated...

ziloo

 

[NobodyIsHere]

Hi Ziloo,

Yes, I think you have it regarding A15 and the memory paging circuit. Thanks, yours is an excellent description and that was probably one of the more challenging aspects of getting the home brew prototype to work.

While CP/M is running, the only RAM pages that should have any programs executing in them are the very top (upper 32K; A15, A16, A17, A18 all high) and the very bottom (lower 32K; A15, A16, A17, A18 all low). That is where CP/M has its TPA and main memory. The rest of the RAM is basically just a block device (RAM drive).

The design theory is CP/M and the stack would exist in the upper 32K so that in any event, the CPU would retain proper context information. There is no guarrantee though as programmers could write programs to run *ANYWHERE*, even from within the ROM (which isn't a bad idea either, it sure would save TPA space by shrinking the CBIOS). The only program that exploits this ROM "execute in place" feature is the loader but it is theoretically extendable to any program. Similarily programs could execute in the other RAM pages as well but stack management becomes an issue.

However, *in theory* it is possible to have programs executing anywhere in the RAM but as you pointed out it is the responsibility of the program designer to keep track of CPU and memory context. That is the hazard of executing any program in bank switched memory and not unique to this SBC design.

If any advanced operating systems come out with support for this platform, they'll have to take this fundamental design approach into account. I am pretty sure there are some Z80 real time OS's around so it is possible but fairly unlikely. I suspect most people will be thrilled to run the monitor and CP/M (I know I am!) although you never know what people will do.

Well, since you are helping create some great detailed technical documentation (theory of operations) for the "Dandy" by extracting this information out of my brain maybe there are some other angles people would like to try?

I got asked a question about the "parts list" for the SBC which might be helpful. My plan was that the schematic and the PCB layout were sufficient to select parts but maybe people would be more comfortable with a formal Bill Of Materials? Detailed building instructions wouldn't hurt either but I think we need to get some PCBs out there to do that...

Thanks and excellent questions! I much appreciate your interest!

Andrew Lynch

 

[ziloo]

Heya Andrew,

Congratulations! I hear you got all the PCBs .
Keep us posted on any new development, hard/software-wise for
the Dandy baord.

ziloo

 

[NobodyIsHere]

Heya Andrew,

Congratulations! I hear you got all the PCBs .
Keep us posted on any new development, hard/software-wise for
the Dandy baord.

ziloo

Hi!

Yes, the PCBs arrived and all is well. I did a small trial run announcement on the N8VEM and the ALPACA_designers lists to get the process working before a wider release. So, since we are already talking about it here, I'll just go ahead and post on how to order PCBs:

Hi All,

At long last, the PCBs have arrived!


If you are interested in building your own SBC and would like to purchase a PCB, please send me an email with N8VEM in the subject line.

The PCBs are $20 a piece with shipping of $2 in the US. I prefer PayPal and I will send you the email address in the response email.

If you require different payment forms, live outside the US, or have other special requirements please specify in the email.

EPROMs are available on request but I would like to discourage ordering EPROMs as you'll want to burn your own whenever possible.

If you require an EPROM, however, they'll cost extra to replace my limited stock -- $3 for 27C1001 (128Kx8) and $5 for 27C080 or 27C801 (1Mx8).

I have no other parts so you'll have to get the rest yourself!

Although I have done everything I can practically do to ensure these PCBs are good there is some risk as with any project.

The PCBs are sold "as is" with no guarantees implied or otherwise and no returns.

I will help as best I can but it is ultimately your decision to build a SBC using one of these PCBs. Please keep this in mind before
ordering!​

So if you'd like to order a PCB or two, please send me an email. Thanks in advance for your patience! Have a nice day!

Andrew Lynch