engineers@work

New designs…

2020-04-28T00:00:00+01:00

This month sees two new hardware boards and significant upgrades on the zOS/ZPUTA software.

Rom Filing System

The Rom Filing System has been upgraded with the release of v2.0 schematics and PCB’s. The new design resolves the shortcomings of v1.1 and incorporates a coded latch to guard against writing to the control registers when not intended. It also include 2 additional (optional) Memory devices, a 512KB FlashRAM to expand the RFS storage and a 512KB Static RAM to expand the memory for CP/M allowing for a greater number of SD drives and TPA size. Also included is a Software SPI and a Hardware SPI interface for driving an SD card. v2.0 schematic , v2.0 pcb

tranZPUter SW

After spending some time with the tranZPUter and noticing it’s design pitfalls (choosing an FPGA with insufficient GPIO pins) and the possibilities seen writing CP/M and the RFS updates, I sat down and redesigned the tranZPUter hardware around the Z80 so that it can be overclocked and access upto 512KB of local static RAM. This allows for a full 64K-512K version of CP/M and also the capability to run MZ-700/800 and MZ80B software.

In order to progress the design more quickly I decided not to use an FPGA (primarily as I couldnt find a dev board with the required 60+ GPIO pins small enough for this project and I didnt want to attempt to solder a BGA (Ball Grid Array) given how expensive the Altera Cyclone V/10 devices are in the needed specification. I settled on an interim solution, to use a dev board by PJRC.com called the Teensy 3.5. This is a Freescale K64F processor, 512K Flash RAM, 256K RAM operating at 120MHz but most importantly it had the required number of GPIO pins which are 5V tolerant thus simplifying the hardware. schematic and PCB for the new design.

zSoft

In order to support the Freescale K64F on the Teensy3.5 board in the tranZPUter SW, the ZPU and tranZPUter software repositories were merged into zSoft and ported to the ARM Cotex-M4 architecture. zOS and ZPUTA can now be built according to requirements for the ZPU or Cortex-M4 processors.

In addition, new Applications were added to zOS/ZPUTA in the form of a visual editor and 2 versions of BASIC, Mini-Basic written by Malcolm McLean and Tiny Basic written by RodionGork and Miskatino.

The original Mini-Basic was designed to run within Windows or Linux and take a file containing a BASIC program and run it. Within an embedded environment this is not so convenient as you want to be able to enter lines or commands and get feedback immediately. This is generally the case in an environment such as this where you are programming or controlling hardware under development. Mini-Basic was thus enhanced to have a full screen editor and a command processor to make it into a fully interactive BASIC.

Projects advancing…

2020-03-24T00:00:00+00:00

Like most of Europe, many are forced to stay at home for the next few weeks, so rather than go mad, time to forward all the on-going projects.

Rom Filing System

I have made quite a headway on the Rom Filing System, adding an SD Card and CP/M v2.23, the Sharp MZ80A is now all the machine I wanted it to be 20+ years ago. Still more edges to round on the design and software, but it is getting nearer to completion.

tranZPUter

Some strange behaviour during testing led me to fry U9 as I was probing the signals with my oscilloscope. The pins are so tiny and working after midnight is probably not a good idea, so a tricky job replacing it. Also there were some hardware bugs in the addressing and latching of the 2 16bit latches CY74FCT16543T which needed board modifications. The schematics have been updated with the changes.

Now currently working on the Finite State Machines in VHDL to perform accurate Z80 Read/Write cycles in order that a soft-cpu or ZPU Evo can control the MZ80A Host hardware.

ZPU Evo

After quite sometime perfecting the SDRAM, both vanilla and cached versions, and running numerous tests where the memory passed with flying colours at 100MHz, I decided to try it out on the Trenz Electronic CYC1000 in the tranZPUter which went well until I ran a ZPUTA application! Some of the smaller apps ran fine but others just went haywire. After many hours of debugging and pondering, I came to the logical conclusion, which I proved, that the L2 to L1 cache mechanism had a timing flaw when dealing with the SDRAM and it’s timing uncertainty. When a ZPU Jump intruction was encountered which jumped out of scope of L2, the L1 and L2 caches were flushed and L2 began to fetch new data from SDRAM. The CPU was held in a wait state and once data was in L2 it began to trickle into L1 and the CPU allowed to continue. Between the L2 filling and the L1 obtaining its first word from L2, a timing bug occurs and L1 receives data from L2 which belonged to the pre-flushed cache set. If I slow the CPU down by adding wait states, it works fine but at full speed this bug just rears its ugly head. After many a late night debugging and pondering, I decided to take a break and work on some of the other projects, coming back to this issue later with fresh eyes! To quote an old saying, ‘So close, yet so far!!’

Github.io website initial release

2019-11-12T00:00:00+00:00

Initial web site built for github pages using Michael Rose’s excellent Minimal Mistakes Jekyll theme.