Home » RBC Forums » General Discussion » Z1RCC, a RC2014-compatible, RomWBW-capable 2"x4" Z180 SBC
| Z1RCC, a RC2014-compatible, RomWBW-capable 2"x4" Z180 SBC [message #10454] |
Tue, 17 October 2023 06:21  |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Edit (12/4/23):
Homepage for prototype Z1RCC, https://www.retrobrewcomputers.org/doku.php?id=builderpages: plasmo:z1rcc:prototype:home
Homepage for rev0 PCB Z1RCC, https://www.retrobrewcomputers.org/doku.php?id=builderpages: plasmo:z1rcc:rev0:home
Homepage for rev0 PCB overclock Z1RCC, https://www.retrobrewcomputers.org/doku.php?id=builderpages: plasmo:z1rcc:overclock:home
------------------------------------------------------------ -----------------
I still have a couple 64-pin Z80180 left over from RIZ180 project so I thought I'll do another Z180 design. RIZ180 is a simple design using recycled DIP64 Z80180 and without using programmable logic. DIP64 version of Z180 can only support 512K memory space so it is challenging to have 512K RAM and 512K ROM that RomWBW needed. However, recently Wayne Warthen has created a version of RomWBW that needs no ROM, only 512K RAM. This version of RomWBW produces a 512K image and requires the external hardware/software to load the image into RAM then jumps to 0x0 to start RomWBW. Notably, the top 32K of the 512K image is the common area that RomWBW actively use while running, but it does not need to be initialized for RomWBW. So the RomWBW image is effectively 480K with the top 32K of 512K RAM available for temporary utility software like RomWBW loader that'll be overwritten once RomWBW has started.
With that operating characteristic in mind, a small bootstrap ROM can reside in programmable logic such as EPM7064S or ATF1504 so that Z180 boots from this bootstrap ROM, copies a loader from CF disk to top 32K of RAM, runs the loader to bring in the 480K RomWBW image from CF disk, then start RomWBW from 0x0. This sounds rather complicated, but RomWBW actually has all the tools to create a CF disk image that contains the 480K RomWBW image, the loader, and the 8 slices of CP/M files. All I need for the party is the small bootstrap ROM resides in the CPLD and the new hardware to do all that, thus Z1RCC.
Z1RCC begins with a blank RIZ180 pc board which has most of the circuitry already wired. It will retain Z80180, oscillator, and CF disk; it will upgrade the 128K RAM to 512K; and it will replace the flash and 2 TTL logic with a EPM7064S which will be glued upside down on the 512K RAM.
It is named Z1RCC because it is a 4-chip SBC based on Z180, RAM, CF disk, and CPLD. Here are features of Z1RCC:
* 9.22MHz Z80180 DIP64
* 512K RAM
* 44-pin IDE interface
* EPM7064SLC44 CPLD
* RTC with DS1302
* I2C bus
* 18.432 MHz oscillator
* 2"x4" pc board
* RomWBW capable
* Compatible with RC2014 bus
Here is Z1RCC schematic. I'll show a picture of the modified hardware once I have it modified.
Bill
[Updated on: Mon, 04 December 2023 06:34] Report message to a moderator |
|
|
|
| Re: Z1RCC, a RC2014-compatible, RomWBW-capable 2"x4" Z180 SBC [message #10455 is a reply to message #10454] |
Tue, 17 October 2023 10:07  |
norwestrzh
Messages: 196
Registered: November 2015
|
Senior Member |
|
|
Interesting, Bill --
I have a number of the 64-pin shrink DIP Z180's (and sockets), and I've always been curious about building a SBC with one of them. I'm a KiCAD user, and the biggest problem I've encountered is the footprint for the shrink DIP device. So far I haven't been able to find one that can be used in KiCAD, and I'm not adept enough with KiCAD to try to make my own. How did you handle this? Also, the closeness of the shrink DIP pins precludes trace pass through, I think. It seems to me that the footprint would in effect create a two "fences" across the PCB and make routing difficult. I'd be curious to see your layout.
I was goofing around with KiCAD and the Z180, and did a simple PCB (don't laugh -- I was just fooling around). See attached. Of course, the Z180 socket used on this one is not a *real* shrink DIP.
A long time ago, I built a Z180 on a breadboard using the PLCC version of the chip. I got it working OK, but got discouraged when I found out about the IN x,(C) and OUT (C),x problem. The classic Z80 monitor that I had used for many years would not run properly on it without major re-work. I gave up on the idea, but have had renewed interest lately.
Roger
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Z1RCC, a RC2014-compatible, RomWBW-capable 2"x4" Z180 SBC [message #10472 is a reply to message #10469] |
Sat, 28 October 2023 18:22 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
In previous post I mentioned that RomWBW can generate CF disk image such that master boot record, monitor, RomWBW itself, and many CP/M slices are assembled into an image that can be copied to new CF disk using image copying tool such as Win32DiskImager. Just as importantly, Wayne Warthen has provided an easy-to-understand framework so board designers like myself can generate our own custom components for a new RomWBW-capable board so disk image for this new board can be generated with collection of existing slices and new programs.
For Z1RCC, here is what I've added to RomWBW to generate a CF image for Z1RCC. The works are all done in RomWBW\Source subdirectory. The actual files are zipped in attached file, Z1RCC_image_maker_for_RomWBW.zip.
* First, the image of RomWBW for Z1RCC needs to be created using BuildROM script and specify "RCZ180" and "Z1RCC" parameters. This will create a RomWBW customized for Z1RCC in RomWBW\Binary\RCZ180_z1rcc.rom.
* Generate a powershell file, BuildZ1RCC.cmd that calls Build.cmd in RomWBW\Source\Z1RCC
* RomWBW\Source\Z1RCC is a newly created sub-directory for Z1RCC. There are several new files in this sub-directory
--Z1RCC Disk Layout.txt that describes the programs in CF's first megabyte (prefix) area. This is where Z1RCC loader located in master boot record, the partition tables, Z1RCC monitor program, RomWBW for Z1RCC are defined.
--Z1RCC_CFLDR.BIN is the binary of Z1RCC loader located in the master boot record
--Z1RCC_ptbl.bin is RomWBW partition tables located in last 72 bytes of the master boot record
--Z1RCC_mon is the binary of Z1RCC monitor
--Build.cmd is the new powershell script that collects all relevant files and put together a CF image in RomWBW\Binary\hd1k_z1rcc_combo.img
* Win32DiskImager can copy hd1k_z1rcc_combo.img to a new CF to create a bootable CF disk for Z1RCC.
This way of generating CF disk image is the prefer way of distributing Z1RCC software once the system software has stabilized. Currently Z1RCC monitor and RomWBW are still evolving rapidly, so I'm still using built-in commands in the monitor to update itself as well as RomWBW.
Z1RCC is a member of the Rom-less RomWBW Zx80 computers. The other members are ZRC512 (Z80) and ZZRCC (Z280) and more Zx80 computers are on the drawing board. They are all Rom-less and depend on CF disk to boot into monitor and RomWBW, so this is the process to generate CF image for this class of computers.
Bill
|
|
|
|
|
|
|
|
|
|
| Re: Z1RCC, a RC2014-compatible, RomWBW-capable 2"x4" Z180 SBC [message #10500 is a reply to message #10496] |
Sun, 12 November 2023 19:50 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Z1RCC-ovrclk has a I2C interface in CPLD that consists of 2 flip flops driven by I/O address 0x9E with data[0] for clock and data[7] for I/O. The I2C interface can also serves as a neopixel interface because 36.8MHz Z180 is fast enough to toggle the flip flop in software to drive WS2812 LED. The timing spec for WS2812 is fairly loose; it is nominally 800KHz 33%-67% pulse-width modulation. The 1.25uS period is divided into 3 phases. The first phase, nominally 400nS, is always high; the 2nd phase is also 400nS in duration and contains the actual information such that high denotes '1' or low denotes '0'; the third phase is 450nS and always low. The timing is fairly loose with tolerance of +/-150nS.
This is software bit-bang approach: Assuming reg D is 0x1, reg E is 0x0, and reg A contains the 8-bit color data then phase 1 is OUT (C),D which is 12 clocks or 325nS with 36.8MHz clock, followed by outputting data in phase 2, OUT (I2C),A and RRA, which are 407nS, and then phase 3, OUT (C),E The core pulse width modulation routine for each bit is:
OUT (C),D ;phase 1, always high, 325nS
OUT (I2C),A ;phase 2, high or low, 407nS
RR A
OUT (C),E ;phase 3, 325nS
; pad with 2 NOP to reach 1275nS
The core routine is duplicated 24 times to generate 24 bits of LED color data or 192 bytes of instruction per LED. The program becomes rather long if we want to drive a 16x16 panel of 256 LEDs. In practice, timing for phase 1 and 2 are fairly important, but the dead time between end of phase 3 and beginning of next phase 1 is pretty relaxed, enough to tolerate extra time for decrement&jump looping. The attached program is able to drive the 5 WS2812 LED in the picture. The prototype board is plugged in the I2C socket with I2C-clock driving the WS2812 LEDs. The colors, from bottom to top, are green, red, blue, yellow, and white.
Bill
|
|
|
|
| Re: Z1RCC, a RC2014-compatible, RomWBW-capable 2"x4" Z180 SBC [message #10503 is a reply to message #10500] |
Mon, 13 November 2023 11:01 |
wsm
Messages: 232
Registered: February 2017
Location: AB, Canada
|
Senior Member |
|
|
Bill: I think your timings may be heldover from Z80 T states rather than the Z180's which are typically lower. Perhaps the following might be a different approach for the Z180, assuming 36.864MHz & T~=27.1 ns. I'm not sure if the delays between colours and LEDS will cause a problem as I haven't gotten around to actually working with these LEDs.
If the Z1RCC CPLD schematic is correct and I can read that and your code correctly, it would appear that you connected the WS2812 DI to I2C SCL (i.e. D0). If DI was connected to SDA (D7) instead and the RRA was changed to RLA then there wouldn't be a need to reverse the ledTbl bit orders. My simple mind likes to keep things like tables as straightforward and obvious as possible. DE would also need to be changed to 8008h in my example. To change the number of LEDs, just add the 3 values for each LED into ledTbl.
I2C EQU 9Eh ; I2C data port, bit 0
;
writeLED: MACRO
LOCAL BYTE
LD A,(HL) ; Data to be sent
INC HL
LD B,E ; Byte / bit counter
BYTE: OUT0 (I2C),D ; 13T high = 352.6 ns
OUT (I2C),A ; 10T high|low
RRA ; + 3T = 13T = 352.6 ns
OUT0 (I2C),E ; 13T low
DJNZ BYTE ; + 9T = 22T = 596.8 ns
MACEND ======
; 1302.1 ns
ORG 100h
LD C,ledCnt ; Number of LEDs
LD DE,0108h ; Hi/low values plus byte count
LD HL,ledTbl
DI
oneLED:
writeLED ; Green
writeLED ; Red
writeLED ; Blue
;
DEC C
JR NZ,oneLED ; Do all LEDs
;
EI
RET
;
ledTbl:
;LED values in reverse order so d0 is msb while d7 is lsb
DB 20h,0,0 ; Green
DB 0,10h,0 ; Red
DB 0,0,8h ; Blue
DB 20h,20h,0 ; Yellow
DB 40h,40h,40h ; White
ledCnt EQU ($-ledTbl)/3
END |
|
|
|
| Re: Z1RCC, a RC2014-compatible, RomWBW-capable 2"x4" Z180 SBC [message #10504 is a reply to message #10503] |
Mon, 13 November 2023 16:11 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Thank you! I completely missed the part about Z180 timing is different than Z80. My oscilloscope is tied up for another project and I didn't want to tear down the setup to check the timing. I have a version similar to yours with more instructions setting regB, inc HL, fetching next value. I was surprised it worked but I've concluded that low level of the output can be much longer than the spec and still drive WS2812 successfully. The high level needs to be more accurate, however.
Shifting out of D7 is more logical, but I was worrying about the active-low, resistor-pull-up characteristic of I2C SDA signal.
Bill
|
|
|
|
Current Time: Tue Jul 15 13:13:48 PDT 2025
Total time taken to generate the page: 0.00958 seconds
|
RetroBrew Computers Forum
Members
Search
Help
Login
Home
, but its autorouter is pretty good and I do know how to create library components for it. The spacing between shrink DIP64 is such that a 6 mil trace can go through it and still have 7 mil clearance.
