Fuzix

[jscrane]

          Fuzix

---

• Disk images for Fuzix on z80pack are here
• boot.dsk is A: and hd-fuzix.dsk is drive I:

This should be easy once the enhanced drivemap.txt parsing is done.

Originally posted by @jscrane in #16 (comment)

[jscrane]

Not so easy: seems to require at least a minimal MMU.

See ports 20-23 of simio.c

However it does get as far as a banner before panic-ing:

boot.dsk: 77 128 26
hd-fuzix.dsk: 255 128 128
-
IO: unhandled OUT(22, 240)
IO: unhandled OUT(20, 8)
IO: unhandled OUT(27, 1)
IO: unhandled OUT(21, 0)
IO: unhandled OUT(21, 0)
FUZIX version 0.4
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <[email protected]>
Copyright (c) 2014-2023 Alan Cox <[email protected]>
Devboot

panic: map overIO: unhandled OUT(29, 128)

• OUT(22, 240) set segment size to 60kB
• OUT(20, 8) initialize to 8 segments
• OUT(27, 1) initialize 10ms timer interrupts
• OUT(21, 0) select segment 0
• OUT(29, 128) call plt_monitor()

[jscrane]

This will require improving the present Memory abstraction.

Make relevant APIs in Memory virtual and override in BankedMemory. (Bank 0 is the "same" as existing Memory anyway.)

Provide APIs on BankedMemory to allocate and switch banks, as described above, while making the fixed segment (the top 4k) common to all banks.

[jscrane]

This has been implemented. However Fuzix on z80pack requires 7 segments of 60kB each. This much memory is not available on the esp32 unfortunately. In fact, only one bank allocation succeeds, all subsequent ones fail.

[jscrane]

More memory is available on the esp32s3: 512kB. (Whether all of this is available is not known.)

More information.

PSRAM is also an option. Apparently ESP32-WROVERs have it, e.g., lilygo-ttgo-t-koala-esp32-wrover

[jscrane]

Have tried it with banked memory on a wrover board. Now it boots with:

boot.dsk: 77 128 26
hd-fuzix.dsk: 255 128 128
-
8 banks
new bank 61440 bytes
new bank 61440 bytes
new bank 61440 bytes
new bank 61440 bytes
new bank 61440 bytes
new bank 61440 bytes
new bank 61440 bytes
IO: unhandled OUT(27, 1)
FUZIX version 0.4
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <[email protected]>
Copyright (c) 2014-2023 Alan Cox <[email protected]>
Devboot

panic: map overIO: unhandled OUT(29, 128)

[jscrane]

The given images boot OK on cpmsim.

Code (from Kernel/start.c/fuzix_main()) between the last output message and the first missing one is:

        set_cpu_type();
        sysinfo.cpu[0] = sys_cpu_feat;
        sysinfo.cputype = sys_cpu;
        plt_copyright();
#ifndef SWAPDEV
#ifdef PROC_SIZE
        maxproc = procmem / PROC_SIZE;
        /* Check we don't exceed the process table size limit */
        if (maxproc > PTABSIZE) {
                kprintf("WARNING: Increase PTABSIZE to %d to use available RAM\n",
                                maxproc);
                maxproc = PTABSIZE;
        }
#else
        maxproc = PTABSIZE;
#endif
#else
        maxproc = PTABSIZE;
#endif
        /* Used as a stop marker to make compares fast on process
           scheduling and the like */
        ptab_end = &ptab[maxproc];

        bufinit();
        fstabinit();
        pagemap_init();
        create_init();

The only real candidate for this error is pagemap_init(). This is defined in Kernel/platform-z80pack/main.c:

void pagemap_init(void)
{
 int i;
 for (i = 1; i < 8; i++)
  pagemap_add(i);
}

pagemap_add() implementations are defined in Kernel/bank*.c and are the only places from which panic(PANIC_MAPOVER) is called.

They all seem to look more-or-less like this (bankfixed.c):

void pagemap_add(uint8_t page)
{
        if (pfptr == MAX_MAPS)
                panic(PANIC_MAPOVER);
        pfree[pfptr++] = page;
        pfmax = pfptr;
}

MAX_MAPS is defined in Kernel/platform-z80pack/config.h:

/* Fixed banking */
#define CONFIG_BANK_FIXED
/* 8 60K banks, 1 is kernel */
#define MAX_MAPS        7
#define MAP_SIZE        0xF000U

[jscrane]

Comparing traces between z80pack and cpm80 allows fixing some z80 cpu bugs. Now it gets further:

FUZIX version 0.4
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <[email protected]>
Copyright (c) 2014-2023 Alan Cox <[email protected]>
Devboot
484kB total RAM, 420kB available to processes (15 processes max)
Enabling interrupts ... ok.
bootdev: 
Mounting root fs (root_dev=0, ro): OK
Starting /init
init version 0.9.1

panic: killed init

Not sure what the cause of the latest failure is.

[jscrane]

After another couple of z80 bugfixes, the latest failure is...

FUZIX version 0.4
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <[email protected]>
Copyright (c) 2014-2023 Alan Cox <[email protected]>
Devboot
484kB total RAM, 420kB available to processes (15 processes max)
Enabling interrupts ... ok.
bootdev: 
Mounting root fs (root_dev=0, ro): OK
Starting /init
init version 0.9.1
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x40088030  PS      : 0x00060f30  A0      : 0x800fee09  A1      : 0x3ffb1d30  
A2      : 0x972af495  A3      : 0x972af491  A4      : 0x000000ff  A5      : 0x0000ff00  
A6      : 0x00ff0000  A7      : 0xff000000  A8      : 0x6e55002e  A9      : 0x3ffb2010  
A10     : 0x00000003  A11     : 0x00060f23  A12     : 0x00060f20  A13     : 0x3ffbdbb0  
A14     : 0x3ffd2a10  A15     : 0x3ffb81f0  SAR     : 0x00000020  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x972af495  LBEG    : 0x40088051  LEND    : 0x40088061  LCOUNT  : 0xffffffff  


Backtrace: 0x4008802d:0x3ffb1d30 0x400fee06:0x3ffb1d40 0x400f79cf:0x3ffb2060 0x400d208e:0x3ffb2120 0x400d1be9:0x3ffb2190 0x400dcf41:0x3ffb21e0 0x400dd219:0x3ffb2210 0x400d5977:0x3ffb2230 0x400d22d6:0x3ffb2250 0x400e09cc:0x3ffb2270 0x4008b59e:0x3ffb2290

[jscrane]

Here is a Fuzix issue from JCW who was trying to do something very similar.

Short of building from source, it might be worthwhile to trace the "system calls", i.e., the port I/O and compare these to Fuzix running on cpmsim.

[jscrane]

Current status:

• it boots as far as the init banner with no further output
• timer interrupt is being processed, polling ttys from it
• keyboard input is echoed to the screen