MFX with a difference grows up

[Martin A]

Seeing as CPM3 on other platforms often had incompatible disk formats to CPM2 on the same machine, is there a reason for keeping the old restrictions in the original BIOS?

CPM2 has been left exactly as it was, there's no changes to the bootrom or the BIOS, that's to ensure compatibility. With HexTrain we have the "best" 8 bit game ever. I wasn't going to do anything to break that, or require a "special" version. Similarly NewWord is tied pretty tightly to the BIOS/Bootrom. Plus of course SDX basic and all the games that makes available, is not only tied to the CPM2 BIOS/BDOS, its tied specifcally to the 59k version.

CPM3 more or less required a new partition format. CPM2 expects each track to be 26 sectors of 128 bytes, that works out at 3.25k per track. CPM3 works with the native sector size, for CF and SD that's 512 bytes, meaning there's no way to define a track that is 3.25k long. I possibly could have made the track 6.5K long and made things work. However a 4k track size and a 4K block size makes the disc geometry calculations incredibly simple. The CPM 2 calculation is something like 42 bytes to the CPM3 version's 18 bytes. It's a lot simpler and quicker to multuply by 8 than 26!

As for the current hybrid structure, CPM 2 can only see 4 partitions at once, so restricting it to 4 partitions total is no real hardship. SDX Basic can't ever see the last 4 partitions so there is no loss there either. Putting the CPM3 partitions where the last 4 CPM2 partitions were meant that the HexTrain data that sits immediately after the CPM area isn't affected in any way.

Reducing the size of the CPM3 partitions from 8meg to 4meg, that was just to make file management a bit easier. With no real sub directory support 256 files per drive (or 192 with time stamps) is easier to manage than double that. There's no overall loss of capacity, because CPM3 can cope with 16 drives at once, all 8 partitions are always visible for 32meg of storage. Moving to 16 x 2 meg partitions would require more memory for the drive tables in the BIOS, and therfore consume more TPA space that I was willing to give up, so 8 was a compromise.

With FTP available to both versions, that means there's no requirement for direct file transfer between CPM2 and CPM3 partitions. So keping them totally separate isn't a problem.

[Martin A]

Excuse the messy bench, I just had to own up to Dave about the extra feature I slipped into the FPGA version 4.05 code. Andy's floating Point accelerator from ReMemorizor/ReMemotech.

Performance is exactly the same as ReMemorizor, so 9m 11s to complete the benchmark Mandelbrot. Unlike CPM3 there won't be a version of this for old boards, there's not enough space in those FPGAs for the accelerator.

Img_5379-small.jpg (80.79 KiB) Viewed 15415 times

That's literally not enough space, even if all the other code was deleted, the FPA takes around 5000 logic elelments. Which is more than the 4608 total logic elements avaialble on the cyclone 2 we were using.

[gunrock]

Looks cool Martin - and why not? If we worried whether any of these extensions and mods made sense, we'd be loading from tape and floppy still.

[Martin A]

I keep promising myself that "one day" that bench will be tidied. In the mean time ...

The latest version of BBC Basic Z80

Img_5384-small.jpg (75.58 KiB) Viewed 7949 times

Richard Russell has released an updated version of BBC Basic for the Z80 https://www.bbcbasic.co.uk/bbcbasic/z80basic.html Basic 5 is based on the Archimedes version of basic, instead of the one from the BBC Master.

I've made use of the built in system specific patch area, to allow it to run on the MFX with CPM3 with as many features as possible. The patched code needs more testing, a release candidate has gone off to Dave to play with and if there's no show stoppers will no doubt appear on his site at some point

The unpatched CPM download from the linked above works on any CPM system, including MTX CPM 2.2. It's just missing the customisations.

[1024MAK]

I keep promising myself that "one day" that bench will be tidied.

One clipped resistor leg at a time... Or is that just me!

Mark

[gunrock]

I keep promising myself that "one day" that bench will be tidied. In the mean time ...
Img_5384-small.jpg
Richard Russell has released an updated version of BBC Basic for the Z80 https://www.bbcbasic.co.uk/bbcbasic/z80basic.html Basic 5 is based on the Archimedes version of basic, instead of the one from the BBC Master.

I've made use of the built in system specific patch area, to allow it to run on the MFX with CPM3 with as many features as possible. The patched code needs more testing, a release candidate has gone off to Dave to play with and if there's no show stoppers will no doubt appear on his site at some point

The unpatched CPM download from the linked above works on any CPM system, including MTX CPM 2.2. It's just missing the customisations.

This benchmark is really interesting - I guess there is some credence in the theory that a 6502 matches or slightly outperforms a Z80 that runs at double the frequency of the 6502. I think a lot of that is chalked up to the 4-bit ALU in the Z80. However, the trig/log test above is way outperforming the 2mhz 6502 BBC B, where the Z80 should be weakest. So, Martin.... did you add support the extra maths accelerator functions of the new FPGA code?

[Martin A]

It's more than just the width of the ALU, the 6502 just does more per clock cycle than the Z80.

At the lowest level, the 6502 reads/writes to memory in one cycle. The Z80 depending on whether it's the instruction fetch or something else takes 2 or 3 cycles to access memory.

As the insruction level, 6502 instrictions take between 2 and 7 cycles, the Z80's between 4 and 23.

For the math stuff the extra register storage in the Z80 comes in handy, meaning less recourse to memory than the 6502. The earlier version of BBCbasic Z80 does all the maths using registers, there's a note in the source:

Code: Select all

;ARITHMETIC AND LOGICAL OPERATORS:
;All take two arguments, in HLH"L"C & DED"E"B.
;Output in HLH"L"C

I expect V5 is the same. Acorn's 6502 code has to use locations in zero page

All I did for the Floating Point Accelerator was add Andy's code to the FPGA build. That's it. It's there if you have the code to use it, theoretically MTX basic could be re-written and maybe run a bit faster, but that is
a) beyond my skills
b) a potential compatibility problem for anything that (ab)uses rom code.

[1024MAK]

This benchmark is really interesting - I guess there is some credence in the theory that a 6502 matches or slightly outperforms a Z80 that runs at double the frequency of the 6502. I think a lot of that is chalked up to the 4-bit ALU in the Z80. However, the trig/log test above is way outperforming the 2mhz 6502 BBC B, where the Z80 should be weakest. So, Martin.... did you add support the extra maths accelerator functions of the new FPGA code?

To add to what Martin says.

The 65XX microprocessors are substantially different to the Z80 processors in many, many ways. But they were both designed to use the same/similar memory chips that were available at the time they were designed. Hence the more important figure is the memory bus speed, not the clock speed.

Both were designed for embedded applications. Not general purpose "central processors". They should be called microprocessors - (MPU or µPU) rather than CPUs, as typically they are the only processor chip (rather than multiple chips forming the CPU) and are on the same board as all the the main system memory).

The 65XX use both edges of the clock. One clock cycle is one memory access cycle (but the 65XX can't use every clock cycle for memory access). Look also at the 6800 which needs two clock signals (a two-phase clock)...

Indeed, the 65XX was designed to be a cheap cut down replacement for the 6800. The discontinued 6501 was pin compatible with the 6800.

The 65XX has less instructions but more addressing modes. It has only three working registers (A, X, Y, all of which are 8 bit wide). The stack pointer is also an eight bit register, so the stack is limited to page 1 (0x0100 to 0x01FF). But one of the addressing modes is to zero page (0x0000 to 0x00FF) and as a result only needs a single byte from memory for the address. This reduces the number of bus cycles by one making the instruction shorter and faster compared to the MPU having to fetch a two byte address.

The Z80 was designed to be a cheaper and more comprehensive MPU over the 8080, indeed it was designed to be software-compatible with the Intel chip. This is the reason for what now appears to be many of the strange instructions and the hardware arrangements. This was important as it allows most 8080 code to run without alterations being needed. Including the CP/M operating system.

It uses a single clock which is effectively internally divided down to control the bus / memory cycles. Hence T-states (or clock cycles) and memory cycles (M - cycles) are different. One memory cycle being made up of a number of T-states (the number depending on the actual instruction). And instructions taking up one or more M-cycles.

The Z80 has a greatly expanded instruction set compared to both the 8080 and the 65XX processors. Coupled with it's extensive set of registers (including it's 16 bit register and memory instructions) this means it's code can be more compact.

All the extra registers means some well written code rarely needs to access RAM for working variables. Indeed, in some very simple embedded applications, this means the amount of RAM can be minimal or none is needed at all.

The main reason for the Z80 using a four bit ALU was said to be to ensure there was no possibility of Zilog getting sued by intel. But I suspect there were other reasons why this design choice was made. Either way, in practice, it's not really any kind of limitation. The Z80 outperformed the intel 8085 in the market (the 8085 being Intel's replacement for the 8080).

Anyway go read the Wikipedia pages on both the 6502 and the Z80 for more details.

Overall, a Z80 running at 2MHz is approximately equivalent to a 6502 running at 1MHz and a Z80A running at 4MHz is approximately equivalent to a 6502A running at 2MHz. In software, each processor is slightly better in some areas than the other, but overall, these differences even out in general purpose computing.

In practical, actual home computers, it was the other hardware and the system and language software that had a substantial effect on the speed. For example, a BASIC running under CP/M on the ZX Spectrum +3 is far quicker than the built-in BASIC.

Of all the BASICs available in the 1980s, BBC BASIC is by far the quickest. But then on a BBC Micro (6502), BASIC alone is 16K bytes in size and uses the separate OS ROM for ALL input/output operations (yes, including all screen/display operations).

Mark