Z180 troubles

[Nick Brok]

Hello,

It is not really about an rc2014, but I' ve some problems getting a z180 cpu up and running.

z180test,pdf is thw schematic and the program is cylonrom.asm.

Can some of the z180 guys help me out what I dis wrong?

Greetings,

Nick

[Phillip Stevens]

On Tuesday, 15 January 2019 21:07:49 UTC+11, Nick Brok wrote:

Can some of the z180 guys help me out what I dis wrong?

Nick, I can't really help much, but I would say that there's usually a bit of a preamble in setting up a Z180. I've got an example of what that could look like here.

But, if you go with all of the defaults, then it should work out of the box (pretty much).

Doesn't the Scrumple 7 have some kind of test code available, or at least a user manual?

Cheers, Phillip

[Marten Feldtmann]

What do you expect and what do you get ?

Marten

[Nick Brok]

The test program must output a walking light that goes up and down, like at a Cylon of battle star galactica. I do see a lot of activity on the bus of the z180 on my Scope. But no IOREQ. So I think I didn't put the z180 in Z80 mode. That's why I uploaded the assembly code of the test-program. The scrumpel is my own design. So possibly made errors are possible. I used the information read in the Zilog docs but i have no clue. The design is very straight forward..... so I expect to see on portA 8 bits moving up and down.

Op dinsdag 15 januari 2019 12:52:32 UTC+1 schreef Marten Feldtmann:

[Nick Brok]

After some thinking I found a design failure in my own design. After solving that my test program runs!

When the ROM comes enabled,  it disabled RAMS0 and so also the ROM! So I used the second CE from the 128KB RAM in stead of switching of the whole decoder.

I uploaded the new schematics.

Greetings,

Nick

Op dinsdag 15 januari 2019 11:07:49 UTC+1 schreef Nick Brok:

[Karl Albert Brokstad]

Hi Nick

Why did you choose to use 4 128k RAM chips, and not go with a 512k chip (AS6C4008)? 

It would reduce the number of chips and complexity of the design.

Karl

-- 
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/d4540419-a6d6-467f-9bec-f32bbec1466d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<scrumpel7r1_2.pdf>

-----
Karl Albert Brokstad
Kirkeveien 9B, 5072 Bergen
98843314, 55289014
ka...@brokstad.no

[Nick Brok]

Hi Karl,

The answer is quite simple: Those 128k by 8 I've plenty in stock. The 512K ones are expensive.

Greetings,

Nick

Op woensdag 16 januari 2019 10:05:48 UTC+1 schreef karlab:

Hi Nick

Why did you choose to use 4 128k RAM chips, and not go with a 512k chip (AS6C4008)? 

It would reduce the number of chips and complexity of the design.

Karl

On 16 Jan 2019, at 09:51, Nick Brok <nick...@gmail.com> wrote:

After some thinking I found a design failure in my own design. After solving that my test program runs!

When the ROM comes enabled,  it disabled RAMS0 and so also the ROM! So I used the second CE from the 128KB RAM in stead of switching of the whole decoder.

I uploaded the new schematics. 

Greetings,

Nick

Op dinsdag 15 januari 2019 11:07:49 UTC+1 schreef Nick Brok:

Hello,

It is not really about an rc2014, but I' ve some problems getting a z180 cpu up and running.

z180test,pdf is thw schematic and the program is cylonrom.asm.

Can some of the z180 guys help me out what I dis wrong?

Greetings,

Nick

-- 
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/d4540419-a6d6-467f-9bec-f32bbec1466d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<scrumpel7r1_2.pdf>

[Karl Albert Brokstad]

Hi Nick

The AS6C4008 cost about 4-5 euro at mouser.com, but I assume free is cheaper as you already have plenty of the 128k chip.

The AS6C1008 is about 3 euro at mouser.com.

BTW: my Z180 module now work with the ROMWBW, it used to halt after boot screen, but after adding a CF-module I can go into CP/M and access the drive.

Karl

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/800dcc62-b79d-45b2-a31d-2e01ccea86bd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Nick Brok]

For Karl:

Hi Karl, thanks for your advice about the RAM chips. With this brand (Alliance) I have trouble. The z180 has problems reading correct data from those devices. It must be some impedance problems or so, also on my own z80 system those RAM cause problems. How did you solve it, or better said what type of cpu are you using? I use the "normal" z80180.

These are cmos low power types. The "normal" power rams does work.

Do you have a place where I can find schematics of your projects?

Greetings,

Nick de PE1GOO

[Karl Albert Brokstad]

Hi Nick

I am not an expert on RAM chips, but I am mainly using AS6C1008 and AS6C4008 from Alliance Memory, these can be bought from a range of vendors e.g. Mouser and Ebay. These are low power CMOS chips, and are used by many in the rc2014 community.
The few z180 processors I have, are of type Z8S18033VSG, I might have one 20mhz version as well.
You find more information about my projects on my homepage www.z80.no, the schematics and pcb layouts are openly available at EasyEDA.com

Just a tip, see:
RC2014 Infobase by Marten Feldtmann, contain a lot of useful information
https://feldtmann.ddns.net/rc2014/doc/

good luck
Karl

> --
> You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
> To post to this group, send email to rc201...@googlegroups.com.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/0b466dad-0c0b-4b3b-9aa7-aa356d93fb4b%40googlegroups.com.

[Nick Brok]

Hello,

My Scrumpel 7 works fine now. Look at the screenshot I made from the monitor program.

Greetings,

Nick

[Karl Albert Brokstad]

Congratulations Nick

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/ab4076a0-c4ed-4479-864c-92cd59751ae9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<Schermafbeelding 2019-01-23 om 10.00.51.png>

[Karl Albert Brokstad]

Hi again Nick

Will you share design and photos of your creation?

We are all very curious.

Karl

On 23 Jan 2019, at 10:04, Nick Brok <nick...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/ab4076a0-c4ed-4479-864c-92cd59751ae9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<Schermafbeelding 2019-01-23 om 10.00.51.png>

[Nick Brok]

Here the schematic and a photo of the pcb.

Greetings,

Nick

[Nick Brok]

Hello again,

Most of the the troubles with the z180 are solved. It runs CP/M now (My IDE adapter card was defective ;-) )

As you can see in my schematics I use a clock of 8 MHz but the z180 seems to be slower then a Z80A on 4 MHz!

I did only setup the Z80 I/O compatibility in the OMCR register.  040h.

Is there something I've missed?

Greetings,

Nick

[Steve Cousins]

Nick,

Have a look at the CPU Control Register (CCR).

I think you need to set the clock to XTAL/1 instead of XTAL/2.

Steve

[Phillip Stevens]

On Friday, 25 January 2019 23:28:27 UTC+11, Nick Brok wrote:

As you can see in my schematics I use a clock of 8 MHz but the z180 seems to be slower then a Z80A on 4 MHz!

I did only setup the Z80 I/O compatibility in the OMCR register.  040h.

Is there something I've missed?

An example preamble for configuring the z180 is here, and a relevant generic z180 header file is here.

The generic z180 target is well supported by z88dk.

Look at the PHI pin. It shows whether you've got the CCR and CMR configured correctly.

If you've done it right, off a 4 MHz crystal it should show 8 MHz.

Good luck,

Phillip

 

 

[Nick Brok]

Hi, I have the Z180, not the Z8S180! The Z180 doesn't have this register.

Op vrijdag 25 januari 2019 13:47:09 UTC+1 schreef Steve Cousins:

[Steve Cousins]

Could it be that the Z180 is inserting 3 wait states into each memory access. That would slow things down somewhat.

[Marten Feldtmann]

* Turn off Refresh (if not needed) in register 36h

* Reduce the WaitCycle times in register 32H. Memory wait cycles should be set to 3 after reset and 4 for I/O

[Nick Brok]

Op vrijdag 25 januari 2019 15:21:55 UTC+1 schreef Marten Feldtmann:

* Turn off Refresh (if not needed) in register 36h

* Reduce the WaitCycle times in register 32H. Memory wait cycles should be set to 3 after reset and 4 for I/O

Thanks! now is my z180 a little faster then my z80 at 4MHz!

Greetings

Nick

[Marten Feldtmann]

I wanted to say: "the default value for memory wait cycles are set to 3 after reset and 4 for I/O"

[Nick Brok]

Hello,

I found another mistake in my design: I forgot to connect DCD0 (pin 47 on PLCC socket Z180) to ground. When it is floating you can get strange problems receiving characters!

Monitor did work fine, but CP/M hanged up in a loop after some seconds! This was not to easy to find! Putting this pen to ground solved the problem...... I think CP/M is causing more noise on the bus than my monitor-program did.

Greetings,

Nick

[Nick Brok]

Hi folks,

I looked into the source-code of romwbw but it looks a bit complicated for me. (reading code made by others is always difficult) So I want to know some assembly-code examples for bankswitching in the Z180.

I have also another question: Did some of you guys run Fuzix successfully on a Z180 processor? I want some info how to start.... The info I find on the net is a little bit to much.... CP/M runs very good on my Z180.

My goal is to run a Unix like OS on my Z180, because I have plenty of CP/M machines now....

Any help will be very appreciated.

Greetings,

Nick

[Phillip Stevens]

On Sunday, 3 February 2019 16:19:40 UTC+11, Nick Brok wrote:

I looked into the source-code of romwbw but it looks a bit complicated for me. (reading code made by others is always difficult) So I want to know some assembly-code examples for bankswitching in the Z180.

Bank switching depends on understanding the memory map of the the device you're thinking about. FUZIX, MP/M, and YABIOS all have different memory maps, so the bank switching code will be different.

I use 64kB banks. You can read the banking code for this memory map associated with the function descriptions.

Phillip

[Alan Cox]

> I looked into the source-code of romwbw but it looks a bit complicated for me. (reading code made by others is always difficult) So I want to know some assembly-code examples for bankswitching in the Z180.

ROMWBW isn't a good place to look for that because it tries to fake up
32K/32K banking with whatever the hardware
does and present a 'portable' interface.

The Z180 is not really 'bankswitched', instead you have a 64K address
space divided into three chunks (and chunks of zero size just vanish).
The upper two blocks can live at any 4K boundary.

You normally boot into flash ROM in the bottom of the address space
and map in RAM above it. When you run from RAM you load the OS/boot
code somewhere into RAM and then have it map out the ROM space
completely.

Page 58 of the manual has some useful diagrams.

For CP/M 3 or MP/M you run with all the memory from 0-56K or so
"banked", and the upper 8K a fixed mapping. When you want to switch
banks you set the base to some baseaddress + 56K * banknumber. The
baseaddress being the start of RAM + the size of the common and any
other chunks you want to carve out (eg a CCP copy).

In the Fuzix case each process gets 64K (we could tidy that but since
everyone seems to have 512K+ RAM nobody has bothered!).

> I have also another question: Did some of you guys run Fuzix successfully on a Z180 processor? I want some info how to start.... The info I find on the net is a little bit to much.... CP/M runs very good on my Z180.

Fuzix currently runs on the N8VEM mark IV and the P112. It shouldn't
be too hard to port to any other platform as Will Sowerbutts who wrote
the Z180 support made the core Z180 code very generic and fairly
complete (serial, SD card etc). so you should only need to write the
code for board specific stuff and a suitable bootloader.

For the N8VEM mark IV for example the only non standard code outside
of the bootloader is the DS1302 RTC, the PropIO card option and the
IDE CF card. Of those the DS1302 is almost entirely a standard
library, the IDE is just some defines to set the addresses and the
PropIO is actually platform specific bits.

The Z180 seriial code needs updating to do better flow control and
baud rate setting at some point but that shouldn't be hard when
someone needs it.

Alan

[Phillip Stevens]

> I have also another question: Did some of you guys run Fuzix successfully on a Z180 processor? I want some info how to start.... The info I find on the net is a little bit to much.... CP/M runs very good on my Z180.

Fuzix currently runs on the N8VEM mark IV and the P112. It shouldn't
be too hard to port to any other platform as Will Sowerbutts who wrote
the Z180 support made the core Z180 code very generic and fairly
complete (serial, SD card etc). so you should only need to write the
code for board specific stuff and a suitable bootloader.

Alan

Supporting FUZIX on the YAZ180 is high on my "complex but important" To-Do list.

It was the first multi-tasking target I had in mind to support, but currently I don't know enough to do this work effectively.

So, I started on working on MP/M instead and that has led down some deep diversionary rabbit holes, like using Hi-Tech C to compile a MP/M Loader (because it can access CP/M file systems) and using SLR180 to assemble the XBIOS (because it generates PRL files for DRI LINK tool). Man, some of those rabbit holes go endlessly deep.

One day soon, I'll get back to adding FUZIX.

Cheers, Phillip

[Alan Cox]

> One day soon, I'll get back to adding FUZIX.

If you have CP/M running and its a generic PPIDE interface using the
usual lines then I can probably knock you up a binary to boot from
CP/M in half an hour. Now whether it works first time ...8)

Alan

[Phillip Stevens]

Would love to try it!

I've got CP/M running from ROM stored in any one of the top 3 64kB pages of the Flash. Page 0 of the flash is the boot page.

CP/M is loaded by copying it from the flash, down into RAM into any of the pages 1 through 12, and then running it from RAM.

Following a warm boot, the CCP is reloaded from flash.

There is no "boot disk". There are 4 CP/M drives permitted, and they're all the identical (no boot tracks).

The IDE interface is a little bit different to the default, as I've swapped some of the pins to make it more general.

Years ago the mistake was made to invert some of the pins needed for the 82C55 inputs in Mode 1 and Mode 2.

I've put the IDE Address lines (that don't need to be inverted) onto the 82C55 input lines, so that the 82C55 is not blocked into Mode 0.

The YAZ180 pin order is here, compared to the default RC2014 or normal PPIDE pin order here.

Cheers, Phillip

[Nick Brok]

Update:

I got a sample from Zilog: the Z8S180. The clock speed programming of this CPU works fine. I got a speed of 16 MHz with a 8 MHz cristall!

Nice processor. So my Scrumpel 7 becomes a turbo Scrumpel now!

I experimented with bank switching and that works fine also. You can set the block size to a minimum of 4K I experienced.

Greetings,

 

Nick

[Nick Brok]

Hello,

A question about memory access time:

On high speed 16MHz  (X-tal 8 MHz, clock *2 mode and dived by 1) the z180 works with a 150ns EEPROM, but calculating the access-time as mentioned by Zilog, I need at least 60ns devices. The internal waitstate generator is set to 0 for memory and 1 for I/O. Does anyone have a clue? 

Greetings,

Nick

[Tom Szolyga]

The difference is best case timing vs worst case timing.  If you use a part with access time calculated by the Zilog formula, the design will work with EVERY Z180 and EPROM that meet spec over the voltage and temperature range in the datasheet.  However, most parts can operate at higher frequencies or shorter access times at 5V and 25 C.  I suspect this is the case with your design.

Back in the day, I worked on "Gaming PCs".  First, we would put a better CPU cooler or liquid cooling into the system.  Next, we would increase the CPU core voltage.  Finally, we would "overclock" the system (run the system clock at a higher frequency than spec'd), increasing the clock speed until the system failed.  We would back off the clock a bit and run the system at that speed.  Essentially this process optimizes the voltage, temperature and clock frequency to exploit the margins designed into the processor/chipset/graphics card to gain performance.  

You could do the same thing with your Z180.  

Tom

[Nick Brok]

I found the correct timing initialization for the ZS180:

Setting for high speed (8 MHz input clock) CPU at 16 MHz:

        ld      a,080h          ;Clock divide off, xtal * 2
        out0    (ccr),a
        out0    (cmr),a
        ld      a,040h          ;1 Wait state for memory
        out0    (dcntl),a       ;1 Wait state for I/O

With these settings 55ns memory works fine and 170 ns 82c55 port also.

Without the wait-state xmodem gives many errors.

Greetings,

Nick

[Nick Brok]

Hi Folks,

The post before this one represent not the complete info, so I re-post it with new discovered info.

After some experiments with the Z8S180 I found the following correct timing initialization.

This is only necessary when refresh cycles are switched off as xmodem gives many errors then.

When refresh kept switched on a waitstate is not necessary.

Setting for high speed (8 MHz input clock) CPU at 16 MHz:

       

        xor     a
        out0    (rcr),a         ;Switch off refresh cycles
        ld      a,080h          ;Clock divide off, xtal * 2

        out0    (ccr),a
        out0    (cmr),a
        ld      a,040h          ;1 Wait state for memory
        out0    (dcntl),a       ;1 Wait state for I/O

With these settings 55ns memory works fine and 170 ns 82c55 port also.

Greetings,

Nick

[Nick Brok]

I have written a small utility to show some setting of the Z180/Z8S180.

It works when using the internal uart0 of the z180 under CP/M. I use the direct access to the uart, not via CP/M. Under CP/M I mentioned it cpustat instead  of z180stat.

Greetings,

Nick

[Marten Feldtmann]

So, the input clock is 8 MHz, but - due to the possibilities of the S version of the Z180 - internally divided by 2. Does the external timing changes due to this internal division ? I thought no ?! So the "problem" is only related to the missing of the RFSH cycle ?

I would like to know, WHAT really changes due to the internal speedup ?

[Phillip Stevens]

On Saturday, 9 February 2019 19:18:12 UTC+11, Nick Brok wrote:

Hi Folks,

After some experiments with the Z8S180 I found the following correct timing initialization.

This is only necessary when refresh cycles are switched off as xmodem gives many errors then.

There's an application note from Zilog, that might reveal some more information. If you haven't already found it.

It is written for a 20MHz system, so this will be conservative for your 16MHz system.

 

When refresh kept switched on a waitstate is not necessary.

The Refresh is not really not really the tool to control your /RD and /WR timing. It is like driving around with the hand brake on, because the accelerator is stuck.

It has a very detrimental effect on a static RAM system. To quote the data sheet...

After RESET, based on the initialized value of RCR, refresh cycles occur with an interval of ten clock cycles and are three clock cycles in duration.

That means that you are slowing down your machine to run at 10/13th (or 76%) of its potential ALL the time. Not just when you're doing an I/O /RD or /WR.

So turning Refresh off is definitely the right thing to do.

 

Setting for high speed (8 MHz input clock) CPU at 16 MHz:

       

        xor     a
        out0    (rcr),a         ;Switch off refresh cycles
        ld      a,080h          ;Clock divide off, xtal * 2
        out0    (ccr),a
        out0    (cmr),a
        ld      a,040h          ;1 Wait state for memory
        out0    (dcntl),a       ;1 Wait state for I/O

With these settings 55ns memory works fine and 170 ns 82c55 port also.

The application note provides calculations for 60ns RAM at 20MHz, and it shows 0 Wait for memory.

I'm sure this will work for you too. I was running at 18MHz with 0 Wait. It is only at 36MHz that 1 wait becomes necessary.

The calculation that is important for XMODEM via the 82C55 is the I/O /RD /WR delay. I calculated that the 82C55 requires 2 I/O Wait states, as /RD is 200ns minimum. You might be lucky and have some good devices, but for belt&braces I've used 2 I/O Wait states at 18MHz, previously.

Cheers, Phillip

[Nick Brok]

Hi Marten,

I have measured the clocks and changing of the settings in both clock registers influences the external timing.

The calculations made by Zilog are with the default refresh cycle.

So my "problem" solves by setting the refresh to one or inserting 1 waitstate.

Op zaterdag 9 februari 2019 10:26:58 UTC+1 schreef Marten Feldtmann:

[Nick Brok]

Hi Phillip,

Thanks for your answer!

I switched to 0 memory wait-states and 2 I/O wait-states. The problem is solved now too! DCNTL is set to 010h.

Strange, slowing down memory access did also do the job, but your solution looks better to me too.

Greetings,

Nick

[Nick Brok]

Op zaterdag 9 februari 2019 10:54:32 UTC+1 schreef Nick Brok:

[Marten Feldtmann]

I tried to measure the stuff and what the clock management does:

Each picture shows 4 signals (from top to bottom): Trigger Signal, PHI, M1, WR

The picture show a sequence of ... MLT HL, INC (IX+2) ..., the MLT command begins just afrer the first WR signal, the seconds WR signal ends with the INC(...) command.

* the first picture shows the system driven by ext 16MHZ, CCR=80h, CMR=00

* the second picture shows the system driven by ext 16MHZ, CCR=80h, CMR=80 (PHI = 32 MHz)

* the third picture shows the system driven by ext 16MHZ, CCR=00h, CMR=00 (PHI = 8 MHz)

So, CMR=80h also doubles the external PHI signal ...

[Phillip Stevens]

On Monday, 11 February 2019 02:10:51 UTC+11, Marten Feldtmann wrote:

I tried to measure the stuff and what the clock management does:

So, CMR=80h also doubles the external PHI signal ...

I originally thought that the Z180 was somehow magically doing a double clock rate internally, but it turns out that the Z180 clock management is nothing more than a multiplier on the oscillator.

The CCR and CMR registers are just setting up multiply or divide on the oscillator input or clock input, to generate a PHI  or CPU clock signal.

So really, nothing magical at all.

The key is always the PHI signal, and that is what drives the CPU clocking, and from that the M1 and all other signals are derived.

Cheers, Philip

[Nick Brok]

These are the final settings for running the ZS180 with 8 MHz x-tal and on 16 MHz clock. Memory 55ns, 82C55 200ns. Thanks to Phillip.

I use both internal serial ports with an external provided baudrate-clock at 9600 Baud.

        xor     a
        out0    (rcr),a         ;Switch off refresh cycles
        ld      a,080h          ;Clock divide off, xtal * 2

        out0    (ccr),a
        out0    (cmr),a
        ld      a,010h          ;0 Wait state for memory
        out0    (dcntl),a       ;2 Wait states for I/O

Greetings,

Nick

[Nick Brok]

Another update about my Zx180 Scrumpel 7 computer.

I had a weird problem that while dumping data in the monitor the computer via the console, spontaneous executed a reset. I have the problem solved: it was a crap and cheap power-supply made in China. I use a power-supply from Apple IPAD now. Perhaps that causes also some problems on the RC2014. (I'll reconnect the rc2014 with a better power-supply soon.)

Greetings,

Nick

[Nick Brok]

Here a short film of Scrumpel 7 counting binairy.

[Nick Brok]

Hello,

I have now a good working design of my zx180 board. It has the following specifications:

2 Serial ports (Internal) with external fixed baudrate  at 9600 Baud.

1 Parallel port 82c55 8 Mhz that can be used for 8 bit IDE interface.

512 KB RAM.

32 KB ROM with two selectable banks of 16 KB that can be switched off. RAM writes are possible while the ROM is active.

3 Software SPI ports.

The CPU is fed with 8MHz clock so the max programmable speed is 16MHz. I use the Zs180.

Now I am looking for someone who can help me to run the z80 UNIX version on this computer. In the mean time I understand the bankswitching logic of the z180 MMU.

Via the SPI-bus I have a working RTC based on the DS3234.

Here a picture of this Scrumpel 7 version 1.3.

Greetings, Nick de pe1goo

[Alan Cox]

On Wed, 29 May 2019 at 06:27, Nick Brok <nick...@gmail.com> wrote:

Hello,

I have now a good working design of my zx180 board. It has the following specifications:

2 Serial ports (Internal) with external fixed baudrate  at 9600 Baud.

1 Parallel port 82c55 8 Mhz that can be used for 8 bit IDE interface.

512 KB RAM.

32 KB ROM with two selectable banks of 16 KB that can be switched off. RAM writes are possible while the ROM is active.

3 Software SPI ports.

The CPU is fed with 8MHz clock so the max programmable speed is 16MHz. I use the Zs180.

Now I am looking for someone who can help me to run the z80 UNIX version on this computer.

Do you have CP/M 2.2 running on it yet ? I would start there before trying to bring up something more complex. Not only because it's an easier way to get the bugs shaken out of drivers and hardware but it's also a nicer environment to debug the bootstrap of UZI180 or FUZIX, and it's usually the bootstrap that causes all the problems.

Alan

[Nick Brok]

Hi Alan,

CP/M 2.2 is running and my assembly I/O routines works fine. Also the routines for using the IDE interface are working in CP/M.

I have a SPI to Ethernet adapter what I want to try to use under fuzix.

Greetings,

Nick

Op woensdag 29 mei 2019 15:46:40 UTC+2 schreef Alan Cox:

[Alan Cox]

On Wed, 29 May 2019 at 16:01, Nick Brok <nick...@gmail.com> wrote:
>
> Hi Alan,
>
> CP/M 2.2 is running and my assembly I/O routines works fine. Also the routines for using the IDE interface are working in CP/M.
> I have a SPI to Ethernet adapter what I want to try to use under fuzix.

The way I usually start is to take an existing Z180 platform like the
SC111 and tweak it accordingly. You don't have to write that much code
if you are following the usual conventions for the SPI<->SD card
interface via CSIO and PPIDE pin choices.

Alan

[Nick Brok]

Hi again Alan,

It sounds stupid but where can I find the fuzix version for the SC111. And with what SDK can I compile the code. I have a linux machine to develop my Z180 programs.

Op woensdag 29 mei 2019 22:17:55 UTC+2 schreef Alan Cox:

[Alan Cox]

On Thu, 30 May 2019 at 16:38, Nick Brok <nick...@gmail.com> wrote:
>
> Hi again Alan,
>
> It sounds stupid but where can I find the fuzix version for the SC111. And with what SDK can I compile the code. I have a linux machine to develop my Z180 programs.

Sorry I had to take a wild guess at how familiar you were with it.

Fuzix lives at https://github.com/EtchedPixels/FUZIX

For Z80/Z180/eZ80 is built with SDCC (a recentish SDCC is needed - I
need to fix the docs to recommend 3.8.5/3.9.0)

The platform level code lives in Kernel/platform-$(name)/ with chunks
of stuff (not as much as there should be) shared in Kernel/dev/.

There are some ready to go file systems on www.fuzix.org which saves
having to build the lot (make kernel and make kclean just do the kerne
bits) The docs suck so feel free to email me questions

Alan

[Nick Brok]

Thanks for the help that Alan gave me, I've successfully running fuzix on my scrumpel7.

 

Greetings,

 

Nick