Enhancement: more ez80 targets?

[pawosm-arm]

As distro-installed sdcc gained ability to target ez80 architecture, maybe it's worth to port FUZIX for those targets too?

I have physical access to the two of such devices:

• eZ80 Development Platform (99C0858-001G) with ez80F91 E-NET module and ZENETSC0100ZACG (ZDI hardware debugger with the ethernet link, so there is no problem with drivers and everything works with Wine on Linux!). I can build nuttx with Zilog's proprietary compiler and boot it on this board. The board lacks any kind of video output, so it was equipped with 4D's uVGA serial to VGA output device (this device deserves Fuzix driver of its own, many other boards could find a good use for it!).

• TI-84 Plus CE-T calculator - a lot was written about this device, real beast with lovely display

Sadly, I don't have too much of the spare time to work on it myself, but I can help with running things on the hardware and with occasional bugfixing.

[EtchedPixels]

There's some initial work in the ezretro port but nothing anyone has then run with to turn into anything more serious.

[pawosm-arm]

wow, I didn't notice this platform (with '80' in the name I would more likely did), and I didn't know about that platform either.

[pawosm-arm]

Interesting reading for a future reference: https://www.cocoacrumbs.com/blog/2023-01-01-reading-zilogs-lod-file-format If I attempt to port FUZIX to ez80f910200zco evaluation board (a.k.a 99C0858-001G, I've managed to verify that the one I have still works), I'd have to figure out how to generate those .lod files from SDCC-generated binaries. I don't know any better way of uploading a boot image over the EthernetSmartCable than using ZDS-II IDE in Wine, and ZDS-II requires .lod binaries.

[pawosm-arm]

SDCC isn't able to compile the FUZIX library, I'd consider using Zilog's ez80cc, but its command line flags syntax is from another world completely, so I'm not sure if it's worth a challenge.

[EtchedPixels]

The Zilog compiler is non-free last time I checked so not of interest. Last time I checked the SDCC used for all the Fuzix stuff built it all fine - what errors are you seeing ?

[pawosm-arm]

ez80cc is enclosed with ZDS-II, and you can download it for free. But still, it is proprietary compiler so in that sense it's non-free.

The bug I'm seeing is:

fcc -mez80_z80 -O2 -c inet_aton.c
inet_aton.c:134: error 9: FATAL Compiler Internal Error in file 'gen.c' line number '8374' : Unimplemented 
Contact Author with source code
inet_aton.c:134: error 9: FATAL Compiler Internal Error in file 'gen.c' line number '8395' : Unimplemented 
Contact Author with source code

It happens at -O2 (FUZIX default), but also -O0. Even if I silence it somehow, similar issue happens later on with:

fcc -mez80_z80 -O2 -c vfscanf.c
vfscanf.c:461: error 9: FATAL Compiler Internal Error in file 'gen.c' line number '8145' : Unimplemented 
Contact Author with source code
vfscanf.c:461: error 9: FATAL Compiler Internal Error in file 'gen.c' line number '8166' : Unimplemented 
Contact Author with source code

...seems like an endless struggle. I've tried sdcc-4.2.0 from Gentoo Linux, and the one I've built myself from this repo: https://github.com/swegener/sdcc.git

[pawosm-arm]

Seems I didn't check the obvious first. Apparently your fork of earlier version of sdcc is already able to target ez80 and this indeed is able to compile FUZIX codebase.

[pawosm-arm]

There is some problem down the line though (with sdcc280):

../../Library/tools/fcc -mez80_z80  -O2 -c decomp16.c
decomp16.c:261: warning 196: pointer target lost const qualifier
decomp16.asm:1758: Error: <a> machine specific addressing or addressing mode error
removing decomp16.rel

[EtchedPixels]

Yep.. just ran a test on it. It's a trivial bug in a peephole by the look of it - so I pushed a change. It may need a canAssign check rather than that one but it should fix it

[EtchedPixels]

https://hackaday.io/project/9483-ez80-open-source-programmer looks useful

[pawosm-arm]

Wow, it actually uses ZDI :) Yet with the EthernetSmartCable that I have (it does not require any OS drivers, hence I could run ZDS-II IDE on Wine in order to upload the code to the board and monitor its execution), I could take purely software approach, though I'd have to investigate the TCP protocol it uses. I suppose if I google for long enough I may even find a ready to use OpenOCD driver.

[pawosm-arm]

There is some observation that I've made on current FUZIX kernel code. Seems the assumption was made that all of the 8-bit architectures have 16-bit address space, which requires resorting to the bank switching. The flat memory layout is currently reserved to 32-bit architectures only. I assume that typical ez80 port would rather use ADL addressing mode, which works in full 24-bit addressing. In effect, flat memory layout could be used, simplifying the porting effort.

[EtchedPixels]

The flat code shouldn't in theory care about pointer sizes. Whether its entirely clean for 8/24 I don't know. However I can't imagine wanting to run most stuff on the ez80 in 24bit long mode as it makes everything much bigger, slower and incompatible with the Z80/Z180 world, aside from the task switching nasties.

[pawosm-arm]

With 24bit addressing, I wonder how slow is slower, I guess FUZIX has worked fine on machines that were even slower by nature. Also I didn't expect to copy binaries from other Z80/Z180 machines. Everything was supposed to be compiled natively.

Meanwhile, I've managed to boot CP/M Plus on my evaluation board:

64K CP/M V3.1 - eZ80F91 Rev 2 CBIOS v1.0.0.3107 of 2008-01-10 [MDS, DEBUG]
Copyright (C) 1982, Digital Research
Copyright (C) 2000-2007, Howard M. Harte

A> dir
No File
A>

I had it built from this repo: https://github.com/hharte/ez80_cpm.git

One sad change was needed though:

--- a/CPM3.0/src/sdmmcdrv.asm
+++ b/CPM3.0/src/sdmmcdrv.asm
@@ -252,7 +252,7 @@ IF SD_DEBUG
     call    _pmsg                       ; print init message
 ENDIF
 IFNDEF _ZSSC                                                   ; Smart Serial Cable dsoes not support SD Cards
-    call    b_MMCInit                   ; Initialise MMC FLASH Memory Card.
+;    call    b_MMCInit                   ; Initialise MMC FLASH Memory Card.

 ENDIF
     jp      b_rwfinish

Now I've connected this cheap, never tested before micro-SD card adapter to the SPI lines of the on-board 'Application Module' connector, but TBH, nothing I connected to this connector ever worked for me! I wonder how Chris Brock has managed to build his monster 'Application Module' card for MP/M, I've been trying to build my own monster 'Application Module' a decade ago and failed.

All of this means, porting FUZIX will encounter yet another obstacle. I can't imagine running FUZIX without a mass storage!

Either this micro-SD card adapter from e-bay was too cheap, or this 'Application Module' connector is haunted by some major issue that I still don't know about. The CP/M port that I've tried can work with ramdisk alone, and with some huge effort I could probably add the ability to mount remote disk images using built-in network connector (I've tested it with ez80 port of nuttx 6.7 recently, and it worked), once I've managed to do that with CP/M running on zx+3 equipped with Spectranet, I could probably use that experience to do it again.

[TurBoss]

Hello, just got in my hands an agon-light2, it uses a ez80 could be possible to adapt ez-retro platform to work on this one?

https://github.com/TheByteAttic/AgonLight

Thanks

[pawosm-arm]

If we're listing various ez80 things here, I guess CPCng is also worth mentioning: http://cpcng.hytherion.com

[EtchedPixels]

Probably - they seem to have it running CP/M. Send patches

[pawosm-arm]

I'd rather send patches for FUZIX :)

[pawosm-arm]

I've looked into the history and realized that this is somewhat recurring issue. No point in having another one, so closing it.