Home » RBC Forums » General Discussion » TinyZZ, a Z280 SBC (Exploring Z280)
| TinyZZ, a Z280 SBC [message #4158] |
Fri, 26 January 2018 10:13  |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Created a new topic to continue discussion from here: https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;th=93&goto=4155&#msg_4155
I don't want to hijack the CPU280 thread, so this topic is about a different implementation of Z280, TinyZZ. It is not retro, is build from scratch. Since I have had no previous experiences with Z80 or its derivative chance are excellent the design won't end up where I wanted. The main design objective is CHEAP. It is a disposable computer to experiment with. I don't want to tear down experiments just to salvage and re-use the computer. To keep the cost down and setting up experiment easier, it will not have boot ROM or flash. It will boot out of CF. The UART bootstrap feature is used to boot up the first time and configure the CF. CPLD is large enough to have spare pins and logics to support experiments.
This is the pathfinder board. It has multiple ways of booting up and different RAM choices so I can learn and hopefully get smart along the way.
|
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4169 is a reply to message #4158] |
Sat, 27 January 2018 08:08  |
mikemac
Messages: 250
Registered: March 2017
|
Senior Member |
|
|
plasmo wrote
but I'm more interested in the multiprocessing feature of Z280. Question about memory size: 16meg DRAM is only $1 more expensive than 2 meg DRAM, but can anyone really use 16 meg DRAM?
I think you answered your own question as to why to use the 16MB DRAM: multiprocessing. It's a great way to suck up memory!
Mike
|
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4171 is a reply to message #4169] |
Sat, 27 January 2018 09:15 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
I want to try multiprocessing on multiprocessors, so each processor slice may have 2 megabyte of local memory, sharing 2 meg of global memory, and can reach into other processor's 2 meg local memory. With that scheme 16meg of memory can be partitioned into a 2-meg global memory and 7 local processor memories. This may be a better use of the 16 meg space. Another reason why each processor slice needs to be cheap.
[Updated on: Sat, 27 January 2018 09:16] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4203 is a reply to message #4200] |
Mon, 29 January 2018 20:54 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
You guys probably knew all about it, but I just find this cool new Z280 instruction that is a perfectly fit for CF read/write:
LD HL,1000h ; write CF data out to memory starting at 1000h
LD C,CFdata ; reg C points to CF data reg
LD B,0h ; count 256 16-bit data
getCFdat:
INIW ; input 16-bit word from port (C) to (HL), increment HL, decrement B
JP,NZ,getCFdat
One instruction (INIW) moves words from CF data register into memory pointed by HL, auto-incrementing. Loop it 256 times running in the cache and moving a sector worth of data. Bang, it is done. Cool!
[Updated on: Mon, 29 January 2018 20:57] Report message to a moderator |
|
|
|
|
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4209 is a reply to message #4208] |
Tue, 30 January 2018 06:57 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
I believe the CF interface is working. I can read/write/verify CF without problems. The UART bootstrapping is rock solid. So I'm at a crossroad: I can continue down the CF bootstrapping and replacing static RAM with SIMM72 DRAM, or I can port CP/M to this board. I'm leaning toward porting CP/M because it may test the board more thoroughly and also let me try Hector Peraza (hperaza) Z280 assembler ( https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;amp ;th=93&goto=3700&#msg_3700). Right now I'm hand assembling the few Z280 extended instructions I needed.
If CP/M, which CP/M? I am following the long discussion on "Installing CP/M3 (Plus)..." on vcfed. This morning's post is #475 and it is not done yet! CP/M 3 sounds very intimidating. CP/M 2.2 seems more reasonable, is it? I'm downloading various manuals and binaries from cpm.z80.de, I assume that's the place to get code & manuals. Is "CPM_2_0_System_Alteration_Guide" the first manual I should be reading?
[Updated on: Tue, 30 January 2018 06:57] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4234 is a reply to message #4231] |
Wed, 31 January 2018 23:49 |
rhkoolstar
Messages: 276
Registered: October 2015
|
Senior Member |
|
|
FTDI was annoyed by the counterfeit chips that were around in a large volume (justified). But they decided to 'kill' these counterfeits with the next windows driver update, which was way over the top in my opinion. They tuned it down a bit, and now they seem to corrupt the data stream without disabling the chips. So I went looking for an alternative, and found the CP2102 based converters. I like them, because they are cheaper and they are 3v3 units, but 5v tolerant, so I don't need to check the voltage setting anymore.
I myself don't use windows drivers, so I was/am not affected by these malevolent drivers. All my FTDI, PL and CP chips work as intended.
The CP2102 boards generally come with a USB-A connector attached, so I de-solder the header, connect a 6 wire cable to the board and cover the board with shrink tube, turning it into a USB-plug. the other and of the cable (usually flat cable) is fitted with the appropriate connector, doing away with the clunky converters on the CPU-boards.
Rienk
[Updated on: Wed, 31 January 2018 23:58] Report message to a moderator |
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4257 is a reply to message #4234] |
Fri, 02 February 2018 13:49 |
etchedpixels
Messages: 333
Registered: October 2015
|
Senior Member |
|
|
I'd also vote for CP/M 3.
As well as being better documented you get a lot of nice features including 512 byte block sizes without BIOS extras and the ability to have big disks (although even with 16 user areas it's a bit difficult to manage without subdirectories! . I'd agree start with the unbanked version then do the banked. There are a few nasties to watch (read carefully the rules about stacks and what you can and cannot bank), also make sure you define the magic set of CP/M offsets in one file and use them in another, otherwise your assembler will be smart, remove them from the relocations and the CP/M builder will fail to do the needed magic relocations.
To get the best use of memory you need to lay out the banked memory buffers by hand which is tedious but without that the tools do a pretty acceptable job.
There are patches to CP/M 3 for Y2K even.
[Updated on: Fri, 02 February 2018 13:50] Report message to a moderator |
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4272 is a reply to message #4257] |
Sun, 04 February 2018 08:09 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
fter receiving excellent recommendations to try CP/M 3, I started with CP/M 2.2 instead. Embarrassed This is because I find a file with CP/M2.2 CCP/BDOS sources in Z80 mnemonics on cpm.z80.de. The opportunity of working with source codes instead of binary image is too good to pass up. More importantly, the source codes are in Z80 so I don't have to struggle with 8080 assembly language. Well not entirely true, I still have to figure out the 8080 mnemonics because all the BIOS and utility examples are in 8080. It seems I've spent all my time translating and then figuring out mistakes in my translation! Mad
The advantage of starting with CCP/BDOS source is not have to worry about manipulating CF sector/track, pulling program out of boot track and putting them back, which is the main theme of the System Alteration Guide. Now I can incrementally add BIOS to CCP/BDOS sources and load the code to memory and execute. Wash, rinse & repeat. It is so much easier and I have a better understanding of what's happening when the code crashed.
The thing nagging at me all along was how to get CP/M 2.2 distro into CF in such way that the newly ported CCP/BDOS/BIOS can read and execute it. The solution was unexpected--unexpected for me, you guys probably knew all along: It dawned on me that CP/M 2.2 file format is compatible with CP/M68K 1..3, so I can use gkermit in the CP/M68K environment to transfer CP/M 2.2 distro into an empty drive then move the drive to the Z280 board. Since I used the same disk parameter block values for both CP/M68K and CP/M2.2, Z280 can read the CP/M 2.2 distro and execute them. Ha, that was easy!
I still have many loose ends and Z280 does have weird bugs above and beyond the OUTJMP. Nevertheless, I'm making progress.
Test CP/M TinyZ280
2/1/18
a>b:b>dirB: XSUB COM : SUBMIT COM : STAT COM : READ ME
B: PIP COM : LOAD COM : ED COM : DUMP COM
B: DUMP ASM : DSKMAINT COM : DISKDEF LIB : DEBLOCK ASM
B: DDT COM : CPM SYS : BIOS ASM : ASM COM
B: XXZ : XY : XZ
b>statA: R/W, Space: 7476k
B: R/W, Space: 7780k
b>stat *.*
Recs Bytes Ext Acc
64 8k 1 R/W B:ASM.COM
96 12k 1 R/W B:BIOS.ASM
60 8k 1 R/W B:CPM.SYS
38 8k 1 R/W B:DDT.COM
80 12k 1 R/W B:DEBLOCK.ASM
49 8k 1 R/W B:DISKDEF.LIB
18 4k 1 R/W B:DSKMAINT.COM
33 8k 1 R/W B:DUMP.ASM
4 4k 1 R/W B:DUMP.COM
52 8k 1 R/W B:ED.COM
14 4k 1 R/W B:LOAD.COM
58 8k 1 R/W B:PIP.COM
1 4k 1 R/W B:READ.ME
41 8k 1 R/W B:STAT.COM
10 4k 1 R/W B:SUBMIT.COM
6 4k 1 R/W B:XSUB.COM
1 4k 1 R/W B:XXZ
1 4k 1 R/W B:XY
80 12k 1 R/W B:XZ
Bytes Remaining On B: 7780k
b>type xyThe file CPM22-B.ZIP contains the files from the distribution
disk for CP/M 2.2 for a XEROX 1800 system.
b>dump xy
0000 54 68 65 20 66 69 6C 65 20 43 50 4D 32 32 2D 42
0010 2E 5A 49 50 20 63 6F 6E 74 61 69 6E 73 20 74 68
0020 65 20 66 69 6C 65 73 20 66 72 6F 6D 20 74 68 65
0030 20 64 69 73 74 72 69 62 75 74 69 6F 6E 0D 0A 64
0040 69 73 6B 20 66 6F 72 20 43 50 2F 4D 20 32 2E 32
0050 20 66 6F 72 20 61 20 58 45 52 4F 58 20 31 38 30
0060 30 20 73 79 73 74 65 6D 2E 0D 0A 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b>pip*xx.txt=read.me
ÿ*xx.com=ddt.com
*^C[Updated on: Mon, 05 February 2018 06:29] by Moderator Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4289 is a reply to message #4288] |
Mon, 05 February 2018 06:25 |
 |
lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
|
Senior Member |
|
|
Ok, I need to apologize to Bill. I accidentally edited his message with the CP/M 2.2 results, when I thought I was replying! (I didn't know I had moderator ability in this thread! Oh no!). Andrew B, is there any way to roll back my mistaken edit? I think I have the notification email, and I think it has all the data..... I've got to be more careful before my coffee kicks in! EDIT: found the email, and will be restoring the message. Is there an emoji for 'egg in my face'?
My reply was that I really appreciated the progress that Bill has done; he's making great progress, and I applaud his tenacity in getting this done; after all, a hobby is doing what you enjoy doing, and if a CP/M 2.2 port is what you enjoy, then by all means go for it....
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
[Updated on: Mon, 05 February 2018 06:31] Report message to a moderator |
|
|
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4292 is a reply to message #4291] |
Mon, 05 February 2018 08:21 |
|
lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
|
Senior Member |
|
|
I liken owning a Z280 to owning an MG. You know there are quirks, and lots of maintenance, but it sure is a fun rig to drive (I don't own one, but I have driven one, just a long time ago and it was a friend's). If you enjoy tinkering it can be very fun.
And hobbies are about having fun, and gaining fulfilment, at least to me. I tend to jump around a lot as well, which I'm sure can be a bit frustrating to others at times... Anyway, looking forward to checking out your board.
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4337 is a reply to message #4336] |
Thu, 15 February 2018 19:00 |
wsm
Messages: 232
Registered: February 2017
Location: AB, Canada
|
Senior Member |
|
|
I find it interesting how different people's experience gives them different perspectives and I try to learn from that. For reference, besides playing with various micros, I was a systems programmer mostly in the IBM world with S/360-67, S/370's, 4300's & 9370's running various operating systems such as MTS, MFT, MVT, VS1 and MVS both for IT purposes and for real-time process control. My current micro development activities are with 33MHz Z180's using a variety of I/O including RAM disks, flash disks, IDE, SATA, USB etc. while trying to maximize performance.
I think one of our differences in approach is the reference to "CPU driven loop to copy bytes from the CF card". All my current development efforts are based on DMA for "disk" I/O and use multiple LRU buffers. Likewise, byte I/O is also fully interrupt driven with FIFO queues. The one thing that could improve this I/O model would be interleaved memory but discrete dual-ported and quad-ported RAM is both expensive and power hungry. Instead, I just use 10ns 16-bit RAM and CPLD-based DMA controllers. I've already designed my next generation board with an FPGA so it can use embedded DMA with embedded FIFO queues to minimize overhead while maximizing the useage of bus bandwidth.
Virtual memory certainly is very useful but as pointed out, swapping can lead to thrashing if the system isn't balanced. Similarly, if an MP/M system "sucked" when copying disks then I would suspect there is an issue with the scheduler, load balancing and possibly the I/O controller itself. Queueing theory also has a corollary that if you make response time too fast then the users will come to expect it and consequently introduce even more load.
Having worked with low-level 3270 "smart?" terminal data streams, I agree that they do reduce the number of interrupts but there is still a LOT of decoding and formatting that went on in the mainframe before the data was useable by the underlying application. FWIW - My S100 system uses a VDB-8024 display card and a Jade DD floppy controller both with embedded Z80's to offload some of the I/O processing.
As to the dedicated CPU per MP/M user: Besides the polled I/O issues, I believe a lot of that was also due to the high price of RAM in that era, the available instruction set and also some of the application languages. The Z80 can be VERY inefficient for floating point and in my experience there is about a 2.5 times performance difference between interpreted and compiled Basic.
Don't get me wrong, I do understand how multiple CPU's can enhance performance and I've already done basic testing on my own design using up to 16 Z180's at 33MHz connected to a base I/O processor for a possible total of 567MHz. Each of these slave processors is connected to the base processor via a 4KB dual-ported SRAM and there are interrupts in both directions.
With all that being said and back on track, I think the TinyZZ is a GREAT project to enable people to start playing with virtual memory, multi-user, etc. etc. for minimal expense. Kudos to Bill for developing it!!!
|
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4338 is a reply to message #4337] |
Thu, 15 February 2018 20:23 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Indeed different experiences led to different approaches. My background in the 80's & 90's was embedded hard real-time navigation and guidance avionic computers. Beside the deterministic computation constraint, the others less hard constraint were smallness, low power & ruggedness. The multiprocessors (up to 15) were tightly coupled, shared memory design with no commercial operating system, just homebrew scheduler. Cost was not a constraint, but every piece of components must justify its place in weight, power & space. I've moved on to other less computational constrained but cost sensitive embedded computers later in my career, and the spartan mindset always stayed with me. It is not about what you designed in--it is what you designed out.
wsm wrote on Thu, 15 February 2018 20:00
With all that being said and back on track, I think the TinyZZ is a GREAT project to enable people to start playing with virtual memory, multi-user, etc. etc. for minimal expense. Kudos to Bill for developing it!!!
Thank you! Z280 really is an interesting processor with many modern features. I have not spent a lot of time with it, but I have not found serious problems so far. Most (all? of the weirdness were my own faults. The internal peripherals seem to work well. The external memory & I/O are running full bus speed, zero wait and appear to work without "weirdness". I understand the DMA may be buggy and I've only used DMA for UART so far. There maybe surprises waiting for me out there still.
|
|
|
|
|
|
| Re: TinyZZ, a Z280 SBC [message #4340 is a reply to message #4339] |
Fri, 16 February 2018 09:54 |
|
lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
|
Senior Member |
|
|
Plasmo, I'm loving this thread.
The Z280 at 12MHz should be at least as fast as a high-end PDP-11 (say an 11/83 or even /93) and might even be encroaching on VAX-11/780 territory. I need to try out dhrystone on the CPU280.
As to memory size, I am actually planning on fully populating 16MB on my board. Fuzix/UZI280 would be interesting here. Alan, as far as time-sharing goes, it was not unusual for a PDP-11/83 to have 10-15 users, and that's with the J-11 clocked at 4.5MHz (crystal is 18MHz, but the microcycle is a quarter of the clock). Even the VAX-11/780 only ran at 5MHz.
Z280 with 16MB is nearly as useful as 68K with 16MB, in my opinion, even though it's not a flat 24-bit address space. In ways it should be more conducive to something like Fuzix since you have a real MMU, even though per-process space is limited to 64K (but so was the PDP-11's, right?). Now, maybe not for TinyZZ, but I could see a NUMA machine with 8 Z280's having say 1MB local each and 8MB global (or some other split, maybe even 2MB each and no gloabl) and run in a similar system-image way as an SGI Altix would. It would just be, to me at least, the ultimate coolness to say 'nah, this is an 8-Z280 box running' and watch people's faces contort trying to figure that out....
Z280 has built in DMA, and it works quite well in the CPU280 CP/M 3 implementation. It would be fun to look at the advantages versus the disadvantages for something like Fuzix. I wonder how the UZI280 kernel handled I/O?
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
[Updated on: Fri, 16 February 2018 10:50] Report message to a moderator |
|
|
|
Current Time: Sat Mar 15 20:58:08 PDT 2025
Total time taken to generate the page: 0.00822 seconds
|
RetroBrew Computers Forum
Members
Search
Help
Login
Home
OK, I'll give it a try, Thanks.
