Author Topic: Z80 Homebrew Computer - fault finding  (Read 96260 times)

0 Members and 1 Guest are viewing this topic.

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #275 on: July 21, 2017, 09:34:51 pm »
NO, NO NO

You connect those to the microcontroller's SPI or I2c interface to get more bits you can control.

You are thinking microcontroller, not microprocessor.

74HCT374
One 74HCT374 connect to an IO port of Z80 gives you 8 bits output.
You connect the D0-D7 to data bus, Q0-Q7 is output, OE low and generate a clock(CP) by a 74hct138 or 74hct139.
You have some unused outputs on your 138,
With a second 138 connect as follows
E1 to unused output of your 138
E2 to Z80 WR
E3 high
you now have 8 outputs that you can connect to clock(CP) of 74HCT374
One 74HCT138 and with 8  74HCT374 you have 64 output bits

For input
You connect Q0-Q7 to data bus,  D0-D7 is input.
Change E2 to Z80 RD
EO is connected to 138 in place of CP
Clock Cp when input data changes.

Replace input 74HCT374 with 74HCT244 for input with out clock.

 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #276 on: July 21, 2017, 10:28:52 pm »
Now
Reading my last you should see some problems if your thinking microcomputer.

The Z80 does not know when output data has been read.
Think of an old parallel printer & the printer does not know when there is new data.
The signal to clock( CP) of 74HCT374 is a new data signal and with a FF you can store this so printer can see there is new data. Printer After reading new data can clear FF. With FF output also connected to input 244 Z80 has a status bit for when printer has read the data. In addition you have 7 more bits on 244 that can be used. One could be paper out, One could be ERROR, one could be printer off or not connected.

so far you have to keep reading input ports for a change, need interrupts to get better.

Interrupts
Z80 has a fancy interrupt mode, vector interrupts. The SIO is using this.
 Using vector mode is not hard.
The interrupt vector is put on data bus during an interrupt acknowledge cycle.
Nothing fancy M1 & IORQ = interrupt acknowledge & a 244 can put vector on bus.

You could use a 244 for each vector or You can get 8 using a priority  encoder chip like 74LS148.

The 74LS148 has 8 inputs for interrupts (1-8)
A0-A2 get connected to input 1.2.3 of 244 
GS is interrupt out to Z80
244 output is connected to z80 data bus
244 output is enabled on interrupt acknowledge with some simple logic that connects to IEI & IEO interrupt chain (SIO)
244 input 0 is low
244 input 4-7 is upper part of vector.
Need more interrupt vectors? Just add more  74LS148's

This does not take in to account what you could do with a fast memory chip.

Now in place of this you could use a PIO, but at a cost of less interrupt vectors & more programming needed.

.

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 Homebrew Computer - fault finding
« Reply #277 on: July 22, 2017, 10:24:22 am »
Yeah, I think I'll stick to the solution you're suggesting, C, for the SPI interface - still, that's a long way off yet and I'm getting ahead of myself thinking about it just yet.  ;)

Quick question to do with crystal oscillators - at least, the all-in-one packages that I seem to have found, like this one:



Could that be used as a straight replacement for the oscillator circuit on the breadboard? (i.e. replace the xtal, both caps, resistors and first logic gate in the clock section of the schematic)?

In the meantime I'm going to try and connect up the CF card to the SBC this weekend.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #278 on: July 22, 2017, 03:11:21 pm »
First you should note that clock input to Z80 is not TTL level.

Some oscillators do not produce a great square wave. The cure is to use 2x osc to clock a FF.

Z80 needs nice square clock at max speed. But at lower speeds can be not square, the Z80 clock high time can be different from Z80 clock low time. You can change between cycles of clock. You have a 8m part, 8M needs to be square, but slower un-square is ok, note clock high & clock low are min times.

Now your thinking of SPI, do you want a faster clock for that serial data out?

Note that with proper hardware handshake the SIO baud clock can be higher and the character data rate still not overload the Z80. EASY to use different OCS for this.

If you are going to connect an AVR or some other micro controller it's sometimes nice to have same clock source for all, and divide to get what you need for each.

Think ahead 2x, 4x, 8s, 16x osc  are easy to work with and some times can be very nice to have. In places in place of a delay line, you can use a shift register if you have the clock source. When you go faster like this you need logic that can work/function at that speed. It is harder to work with 3x,5x,7x ect but not impossible.

breadboard can limit max clock, but you could have High speed on pcb that plugs into breadboard.

You have a 8M max limit for Z80, but can divide to this.
You have a need to match standard baud rates to 1% or less. but again can divide to to need OR use different osc.

If I was building, I would do X__ for the clock, probably from 2x,4x, might to 8x.

So can type osc is fine, CMOS type is good here. Question is what speed for what cost $. Cost is why you often see just see the crystal with osc circuit.

 If you are going to order some, might want to think on some other parts that would be nice to have to add to order.

Your needs might change based on memory speed also.

You have one working OSC now,  both Z80's could use same osc just use different driver to each z80, II would use it and think on this as future step.
« Last Edit: July 22, 2017, 03:26:06 pm by C »
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #279 on: July 24, 2017, 06:19:42 am »
This post is about learning

You have been asking a lot of questions which is good way to learn.
Way back Z80's were used for a lot of different things.
More questions with ideas of what you want to learn or do can help alot and could save you time also..

You just had some fun or pain with an SIO, How much of what the SIO can do did you look into.

SIO
The SIO is a Universal Synchronous/Asynchronous Receiver/Transmitter.
with Z80 vector interrupt generator added.
Universal Synchronous/Asynchronous Receiver/Transmitter
https://en.wikipedia.org/wiki/Universal_Synchronous/Asynchronous_Receiver/Transmitter
 You Might want to do a quick read of this first.
 https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter
If you look at the first chips like WD1402A or AY-5-1013, you would see part of what is inside the SIO
AY-5-1013
http://www.rogtronics.net/files/datasheets/uarts/AY-5-1013.pdf
There is no software initialization needed with this chip, Some pins were set high or low by a dip switch an pull up resistor. The baud rate clocks often by another chip. Fancy was using software to set pins in place of dip switch which then needed software.
One reasion for SIO was to reduce the logic needed to connect this chip to Z80.
You would use 374's and 244's and some more chips to interface this chip.

The SIO is a Universal Synchronous/Asynchronous Receiver/Transmitter.
IBM and many others used the Universal Synchronous part. This removes the start stop bits and lets you transmit/receive data packets with known packet start. This makes software easer at the cost of transmitting complete packet at speed or aborting packet.
When you understand the basics used here, you can see parts of this used many places.
So while you may not care about HDLC, SDLC or Synchronous it is not a bad idea to look up and try to understand the terms you come across while building your Z80
So as you were looking at the SIO data sheet did you look up some or all of this?

Software flow control
https://en.wikipedia.org/wiki/Software_flow_control
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #280 on: July 24, 2017, 07:00:59 am »
How are you getting along with CF card interface.?
would be good idea to make a spreedsheet or text file of all the connections.
You have the CF card,  CF card adapter, the breakout board & Z80 to deal with.

For quick SD Card interface,

in your position I would want a working CP/M system if at all possible first.
Z80, You need software & hardware. For Z80 you would need to find the software or translate from some existing software that works with a microcontroller interface
You would need to add hardware to Z80, test it and get software working. .
Right now you are playing shuffle and have to move Code to Z80.
You should look and understand each option grant has to get code to Z80.
No CF card changes this some. If your rom is larger then grants you have more options.

Option #1A
A 4$, 4ICs, Z80 homemade computer on breadboard
https://www.eevblog.com/forum/projects/a-4$-4ics-z80-homemade-computer-on-breadboard/
You might think of this as a Z80 development system
He is using a MEGA32A, with some Adriano programming. The mega32a is 40-pins  Cost and breadboard plays a large part of choice.
Something with even more pins could be better.
Note this is using I2S memory for drives. SPI pins are used and have not looked how hard it would be to change so SD Card possible.

Option #1B
A Arduino Mega 2560 would be nice due to more pins, but real at $45.95 but I would not pay that price.  This is used in a some/lot of 3D printers. It is ok for 3d printer but not great. Arduino Mega 2560 Clones are much cheaper and have some parts used above on a PCB. Would need some Arduino side software changes to use this.
The extra pins should allow I2C, SPI or SDcard use as drives.
 
1A & 1B dos not prevent you from adding more hardware on Z80 side.
If memory serves Grant's basic exists for this.
You could  have Arduino Mega boot Z80 and with software changes add Z80 hardware
Or with some software changes you could have Z80 boot from rom and then start using Arduino Mega for its IO.


Option 2:
You could treat a micro-controller as a disk drive controller.
You could then use existing software on micro-controller. .You could have Z80 using raw data space of SD card or a file per drive on SD Card.
At the simple level the Z80 is going to ask to read or write block # on drive x

I would think a quick simple version of SCSI interface on Z80 connected to a microcontroller that has a SPI interface would be a good starting point.
You would then have hardware that adapts to differences in speed of CPU's and hardware based control of data flow speed between the two systems.
This would let you use a lot of the existing software for SPI Interface and SD Card on microcontroller.
This one interface on Z80 would let you add hardware & software  on micro controller side with just software changes on Z80. Full SCSI interface on your two Z80 & micro controller and you have a network.

An operating system like CP/M just wants a drive to look like a collection of blocks. CP/M programs work with blocks of 128 bytes. When this does not match drive block, a part of CP/M will adapt to put many 128 byte blocks into a drive block. Small block size = smaller disk and less memory CP/M needs as a drive buffer to do this. The great thing about CP/M 3 and turbodos is that it can swap in banks of memory to hold these and other buffers.

When you have a working CP/M system
You can do all parts of software development on Z80. While this can be slower, it could still be faster then moving code to Z80. I think some of the Assemblers are even better on z80.

A lot of possible options where a micro-controller can help on Z80 side.
« Last Edit: July 24, 2017, 07:23:09 am by C »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 Homebrew Computer - fault finding
« Reply #281 on: July 24, 2017, 12:46:36 pm »
How are you getting along with CF card interface.?
would be good idea to make a spreedsheet or text file of all the connections.

Hmm.. well, I was able to wire up the GPIO adapter on the breadboard, but that's as far as I've gotten.  If I plug the CF adapter into the GPIO's IDE slot, the SBC won't boot or show the 'Press <space> to continue...' prompt.  If I remove the CF adapter, it will boot - so there must be a problem somewhere with the wiring.  As soon as I've got some time I'm going to go through the connections (I'm pretty sure they're all correct) and also check for shorts or unexpected connections between pins - I'm not sure that the CF adapter is providing clear connections between the IDE connector and the CF card's pins - one of the wires (~WE - Write Enable on the CF card) is connected to Vcc through a 1K3 resistor in the adapter, for example.  There's probably something else in the CF-IDE adapter not wired as it should be for the SBC.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #282 on: July 24, 2017, 12:57:29 pm »

(WE) A pull-up resistor should be same as strapped high

First thought is power problem
The CF card needs power, normal IDE cable no power
Have you connected power to the power jack on CF Adapter?
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 Homebrew Computer - fault finding
« Reply #283 on: July 24, 2017, 01:29:07 pm »
No, I haven't connected anything to the power connector on the CF card adapter (the power LED illuminates when power is on to the SBC) - but a quick check with the multimeter and I'm picking up +5V at the Vcc pin for the CF card.  As I had to take the CF card out of the adapter to check the voltage on Vcc, I thought I'd turn the SBC on with the adapter plugged in to see if it would boot... No.  So it seems the CF adapter is causing the issue, but I'm a little confused as to how or why it would prevent the SBC transmitting anything to the console.

EDIT:  Here's a pic of the setup so far...

« Last Edit: July 24, 2017, 01:32:21 pm by nockieboy »
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #284 on: July 24, 2017, 01:38:41 pm »

Need to test power with card plugged in
I would just connect grounds and +5 from power jack to breadboard.

Their is a chance that you are using more power then USB supplies.

Might try disconnecting CF chip select and putt this high and see if things change.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 Homebrew Computer - fault finding
« Reply #285 on: July 24, 2017, 01:52:33 pm »

Need to test power with card plugged in
I would just connect grounds and +5 from power jack to breadboard.

Their is a chance that you are using more power then USB supplies.

Might try disconnecting CF chip select and putt this high and see if things change.

Power draw for the SBC is 20mA according to my USB power monitor, well within the specs for the USB port if that is correct...



Yes, the next thing I'll try is to disconnect the CF adapter - probably one connection at a time to see if I can pinpoint which one is causing the problem.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 Homebrew Computer - fault finding
« Reply #286 on: July 24, 2017, 02:00:59 pm »
Hah! Didn't expect to find the problem with the first wire I disconnected, but I did..  ;D

It seems there's a problem with the reset wire/pin.  If I disconnect it, the SBC works fine with the CF card in/out.  The minute I connect it, it freezes the SBC.

With a minute or two investigation with my multimeter, it seems the RESET pin for the CF adapter is connected straight to GND.  This was pulling the RESET pin to the ENABLE ROM gate low, causing the SBC to freeze.  Seems I need to find another pin that functions as RESET for the CF adapter...
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #287 on: July 24, 2017, 02:14:03 pm »
As I said the CF adapter is adapting CF Card so that it looks like IDE drive.

Quick test would be CF CS High at CF card.
All outputs should then be tri-state from CF card.
Chip select would be Drive select on IDE Cable. and adapter could be built to do/not do Cable select drive selection a second difference.

If this does not work, I would start a spread sheet and list all the connections on all the parts used for this..
Better chance to see a conflict.
Some pins will be different on IDE vs CF card slot.
Could be many differences.

Normal 40 pin IDE cable does not do power.
In laptops they sometimes use a 44 pin connector to connect drive power & IDE signals to a drive.

Check power with all connected. Power up could be a big load.
Could also need some cap's on power bus.

For reset, adapter could be built for software reset of CF card.

I would still do a spreed sheet to verify

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 Homebrew Computer - fault finding
« Reply #288 on: July 24, 2017, 06:51:45 pm »
Okay, well, here's how I did this so far:

1) I connected the CF card adapter into the IDE breakout/GPIO board, which is plugged into the SBC breadboard.

2) With no CF card inserted so I could get to the pins, I set about testing continuity using my multimeter between the CF pins and the pins in the SBC breadboard from the IDE breakout board.  That way I would know exactly which pins on the breadboard to connect up to the Z80's ADDRESS and DATA bus, along with the control lines as detailed in Grant Searle's schematic.

3) Connected up the buses and control signals accordingly.

4) Discovered that the RESET pin in the CF adapter card is also connected directly to GND.  If I connect the IDE GPIO breakout RESET pin to the appropriate place on the SBC (Enable ROM logic input from RESET button), that line is pulled LOW and the SBC is held in a permanent RESET state.

So I have a CompactFlash to IDE adapter that has a permanent connection from CF RESET to GND for some reason.  I will take a closer look at the adapter tomorrow, but I can't work out why it would be made this way.  If I can break a trace on the CF/IDE adapter to stop this short, then maybe I can get it working.
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Homebrew Computer - fault finding
« Reply #289 on: July 24, 2017, 07:36:27 pm »
2) With no CF card inserted so I could get to the pins, I set about testing continuity using my multimeter between the CF pins and the pins in the SBC breadboard from the IDE breakout board.  That way I would know exactly which pins on the breadboard to connect up to the Z80's ADDRESS and DATA bus, along with the control lines as detailed in Grant Searle's schematic.
If you are following Grant's design then he connects the lower three bits of the address bus and the data bus directly to the CF card - IMO this is a mistake because it's too easy to disturb the Z80 buses that way and get unreliable operation. I would aim for a buffer between the two.

As for the reset thing have you identified pin 1 and the pin ordering correctly - if you are 180o out then the corresponding pin on the CF card is pin 10 or A9 which should, indeed, be grounded.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 Homebrew Computer - fault finding
« Reply #290 on: July 25, 2017, 09:33:05 am »
As for the reset thing have you identified pin 1 and the pin ordering correctly - if you are 180o out then the corresponding pin on the CF card is pin 10 or A9 which should, indeed, be grounded.

I've checked and double-checked the orientation of the CF card pins against Grant's schematic here:



Using the guides at the edges of the connector (one is thin on the left, the one on the right is thicker) there seems to be only one interpretation of the pin positions, so I'm pretty sure I'm not getting them mixed up - this is the RESET pin I've identified in the CF card connector.... (I've marked it on the image below, but unfortunately it's a bit small/faint - click on the image for a much larger version.)



I've also checked continuity between the CF RESET pin and pin 1 (IDE RESET) of the IDE connector on the CF adapter - they are indeed connected.  Unfortunately, there is a definite short between IDE RESET pin 1 and GND.  There's no obvious damage to the adapter PCB or traces - I just can't work out WHY it would be connected to GND like that.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #291 on: July 25, 2017, 12:11:19 pm »

Think you have an adapter from CF to ATAi IDE drive
Parallel ATA
https://en.wikipedia.org/wiki/Parallel_ATA

You have a 50-pin CompactFlash
You have a 40-pin Parallel ATA
You have Power jack
you have 3 leds.

This is more then just change pin #
Trace out what is on adapter , reverse engineer it.


 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Homebrew Computer - fault finding
« Reply #292 on: July 25, 2017, 12:42:54 pm »

Think you have an adapter from CF to ATAi IDE drive
Parallel ATA
https://en.wikipedia.org/wiki/Parallel_ATA

You have a 50-pin CompactFlash
You have a 40-pin Parallel ATA
You have Power jack
you have 3 leds.

This is more then just change pin #
Trace out what is on adapter , reverse engineer it.

Reset on the CF card (pin 41) should go (I think) to pin 1 on the IDE interface.


Note that the IDE interface numbers pins in a different order to the CF interface
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 Homebrew Computer - fault finding
« Reply #293 on: July 26, 2017, 09:21:58 am »
Well, it's not pretty, but I got it working last night.  ;D



As you can see in the image above, I swapped out the CF-IDE adapter that I had initially been using (and associated IDE-GPIO adapter that plugged into the breadboard) and have used an alternative CF adapter I had lying around - unfortunately the IDE pins on this one are too close-pitched (and male) so they won't fit the IDE-GPIO adapter.  Instead I've had to use the short length of IDE cable that came with the CF adapter and plug the breadboard connections directly into the ribbon cable connector.  Like I said, not pretty (or particularly stable) but it works.  :phew:

It now has CP/M 2.2 installed and runs BBC BASIC in CP/M (as well as my modded NASCOM BASIC in ROM).  Work finished late last night, so I've yet to get hold of more CP/M software to test, but it's almost complete for this stage of development.  I just need to look at the code in my own monitor ROM - I had to swap out the ROM last night for Grant's original ROM monitor as mine was having trouble with the Intel HEX pasting into the console.

So what's next? I have a nice little space on the breadboard for an AY-3-8912 that you may have noticed in previous post images - the next step is get this in and working and sort out some sound and IO for the SBC.

Then after that - an SPI interface perhaps?
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #294 on: July 26, 2017, 01:45:07 pm »
Well, it's not pretty, but I got it working last night.  ;D
It now has CP/M 2.2 installed and runs BBC BASIC in CP/M (as well as my modded NASCOM BASIC in ROM).  Work finished late last night, so I've yet to get hold of more CP/M software to test, but it's almost complete for this stage of development.  I just need to look at the code in my own monitor ROM - I had to swap out the ROM last night for Grant's original ROM monitor as mine was having trouble with the Intel HEX pasting into the console.

So what's next? I have a nice little space on the breadboard for an AY-3-8912 that you may have noticed in previous post images - the next step is get this in and working and sort out some sound and IO for the SBC.

Then after that - an SPI interface perhaps?

 :-+Great to here you are running.

Lots of places to get CP/M software. In general any CP/M software works on any CP/M machine.
BUT You can have differences in many areas that can make it fail.
Displays:
  There were many different ways to work with a display. Go to X.Y on screen was often different for example.
Printers:
  Same problem as above when doing  fancy prints.
Hardware:
 You have some software that is special for Grant's, Things like this could have problems.

AY-3-8912
  I would suggest that when you can you use a separate breadboard for things like this.

Think of building to a bus based breadboard system..
Think of future some, If you have memory on separate breadboard with easy connection to a bus, It becomes easer to change in future.
IF all of SIO special was on a breadboard, again easy to change. Connections can be easer to connect or disconnect.

As a hint of what you might want on your bus, look at bus used for Radio Shack/Tandy Model II. There is a technical service manual on web. This was a great Z80 system. Note also what boards plugged into this bus. A bus lets you expand to bus limits and more. You might not want or need all the signals now, but if you leave space you can more easily add signals later to the bus. Note the IEO/IEI chain of signals that let you add more vector interrupts to system.
You can see how expandable this system is when you look at Model 16B or Model 6000. Here a 68000 processor board is plugged into a Model II. The Z80 boots the 68000 and after boot does the IO reducing load on 68000.

Programming takes space & run time. In future you might like the AY-3-8912 connected to your second Z80 so that you have more memory for CP/M and less load on CP/M's CPU. Bus makes this an easer change.

If you put one breadboard the other direction(vertical in picture), it could be your Z80 bus.

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 Homebrew Computer - fault finding
« Reply #295 on: July 26, 2017, 02:07:12 pm »
There's no denying a separate bus board would make future development a lot easier.  I was just looking at the board and wondering where I'd get the address and data bus signals from for the PSG - looks like I can get data from around the SIO and address from around the ROM ZIF socket, but it'd be so much easier with a dedicated bus board as you've suggested, C.

I wanted this iteration of the SBC to be compact and solid - version 1 was wide and spread across four breadboards and, as a result, it was flimsy and didn't take too well to being moved around the house (it has actually stopped working currently, I think because of a disturbed connection somewhere.)

I'm wondering about the virtues of prototyping board.  My prior electronics and soldering experience was entirely based on veroboard (stripboard?) many years ago and I've never used prototyping board, but I've seen many dense and neatly-created SBCs online using protoboard, so I might consider giving that a chance as the next step away from breadboard... any thoughts?
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #296 on: July 26, 2017, 02:30:46 pm »

The big thing is having a bus that you can plug into.
Cost is a problem. With many changes you can have to replace things to keep going.
Using a breadboard is ok first step.
You can find a design on youtube that uses headers on stripboard  to create system.  Bus is on a stripboard. Should take a look.

Think build it on breadboard and test it. Then move it to stripboard. Keep it logical & have modules. After you have made one module it is easer to make the second.

Big problem is the need of a lot of signals on a good Z80 bus.  Look at that Model II and get an idea of what might be needed.

The Z80 is only 40 pins, but needs a lot more pins on the bus.
To do it right you need to add IEI & IEO for interrupts. Can need same idea for Busgrant.

Now is a good time to do some clean up to make things easer in future.

You have thought of Z80 clock.
You now have Grant's CP/M working, so with software changes you can improve on it.
My first change would be to replace Rom disable circuit with a 273.
You need to get to CP/M3 or TurboDos. This gives CP/M programs more ram to work with. You need memory to do this.


 
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #297 on: July 26, 2017, 03:02:39 pm »

The 274 could give a simple memory management with the extra bits with known state at power on.

You may not know, to shift from CP/M2 to CP/M 3 or Turbodos you just run a CP/M2 program.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 Homebrew Computer - fault finding
« Reply #298 on: July 26, 2017, 03:16:14 pm »

The 274 could give a simple memory management with the extra bits with known state at power on.

You may not know, to shift from CP/M2 to CP/M 3 or Turbodos you just run a CP/M2 program.

Sorry C, a 273 or 274? I'm assuming you mean the 273 (8-bit register)?

So I could use the 273 to control the ROM and the remaining 7 outputs to page in 16 or even 32K sections of RAM, say from 3000-AFFF (as an uneducated guess)?  Bare in mind I know next to nothing about the CP/M memory space (and especially memory paging in general), so please forgive me if I come out with some real nuggets. ;)

How does CP/M 3 page the memory? Via IO space?
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 Homebrew Computer - fault finding
« Reply #299 on: July 26, 2017, 04:13:37 pm »
Sorry 273

You have a clear input for power up.
You have a low to high input to latch new data.
Note that this puts the latching of data at the end of a Z80 write where data is valid.

To me when using single chips like this where Z80 OUT sets the data to use a 138 or 139  with WR as one of its signals.
For Z80 input Use one with Z80 RD
One of the inputs would come from your existing 138

273 gives 8 bits logic 0 on power up.
Grant is using 1 bit.

You have option of
1. read from rom, write to nothing.
2. read from rom, write to ram
3. read from rom, write to eerom


Sorry C, a 273 or 274? I'm assuming you mean the 273 (8-bit register)?

So I could use the 273 to control the ROM and the remaining 7 outputs to page in 16 or even 32K sections of RAM, say from 3000-AFFF (as an uneducated guess)?  Bare in mind I know next to nothing about the CP/M memory space (and especially memory paging in general), so please forgive me if I come out with some real nuggets. ;)

How does CP/M 3 page the memory? Via IO space?
Paging can be almost any way with CP/M3 & turbodos
Both want some high memory common.
Keep in mind that first 128 bytes is important also.

For 32k banks you use one Z80 address line while adding more.
For 16k banks you use two Z80 address lines while adding more.

Some use a data selector IC to select output address.
Some use a tri-state latch to output address.
One you select the bits while other you select the chip.
These are simple.
Fancy is using very high speed memory.

One of my Z80's uses a 8 bit magnitude comparator chip and has a movable bank location.
 
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf