yaz180: initial support

[feilipu]

I note that you've committed some initial bits of yaz180 support. Thank you. I'm looking forward to trying. And, I note that this is already more than I would be capable of achieving.

Just thinking, it might be easier to do it without CP/M, if FUZIX doesn't need CP/M disks to operate.

I've got a bios written in part in C, and with access to all the FATFS functions.

For CP/M I use the reserved space in the CP/M Page 0 from 0x0040 to store the LBA of 4 CP/M drives (FATFS files). Something similar might work for FUZIX?

I don't know, but it might be easier to write a function for yabios specifically to load FUZIX, without initially jumping through CP/M hoops. That way I can write the kernel to flash permanently, in one of Bank 13, 14, or 15, and starting the kernel simply means using the bios command to load it into the relevant RAM Bank, filling out what ever disk information is required to initialise, and then jumping into its launch address.

What do you think?

--

Just for interest, I am building MP/M so that its Bank 0 is actually YAZ180 Bank 8 physically. It will only be loaded into Bank 8, which implies that CP/M cannot be in Bank 8 when the MP/M loader is started. That also means that the 7 user banks will be numbered Bank 1 through Bank 7. I thought this would make accessing Banks simply a matter of masking off the Bank number to 8 bits, and keep things simple.

[EtchedPixels]

It's probably easier in the end to do that, but on the other hand as a starting point CP/M leaves the serial hardware up and running and everything in a known good state, plus you can use DDT to debug the early boot phase before anything appears on the serial.

Fuzix uses standard PC MBR and partition types 7E (fuzix fs) and 7F (swap) so if you have a valid MBR fuzix should be quite happy.

On the MPM loader the thing was designed when CP/M was 2.2 and never banked and the world was simple. Thus you could link it at 100 and run it from CP/M or DDT without complications. If I remember rightly though you can put CP/M and the MP/M loader in the same bank. The moment the loader has loaded from CP/M it will never touch CP/M again. (Beware if you have interrupts running..)

[feilipu]

For further info, from yabios, you can use any of these available calls, for example into serial, far calls and far memory copy. Those calls above 0xF000 remain in common RAM. I don't have a debugger, but there are memory dump and disk dump commands from the command line.

--

On the off-topic MP/M thing.

I actually ended up writing a loader using Hitech-C CP/M, because the z88dk CP/M target doesn't have file access finished in its new library yet. Which meant learning yet another new thing...

The loader does what it is supposed to do. But, I got delayed and sidetracked before I could finish the XIOS. I'll be back to it soon...

[feilipu]

Noted that you’ve added some changes for the PPIDE interface.

I don’t know whether these initial bits are in a state where they will work.

Could you @ me in a comment when you’re looking for a live test, please? Thanks.

[EtchedPixels]

@feilipu The code committed should boot, produce all the expected boot up text and then try and read the partition table on the PPIDE and prompt you with a boot prompt. In the unlikely event it does all that it might even work completely as there's not a lot of platform specific Z180 code.

[feilipu]

Ok. Great, thanks.

I'm assuming I just unzip the 32MB Z80 file system from here in the root of an attached IDE drive, and then there is a CP/M COM to build according to this, and this.

Not sure I understand fully how to get the correct build outcome right now, but I'll read up over the next few days.

On the SDCC patch, do you know whether this will work with the 3.8.5 version we're using in z88dk now? Would it be worth submitting this to Philipp to try to get it added to mainline as a new option?

[EtchedPixels]

Except for the banked kernels they ought to build with sdcc 3.8.5 just beware that recent sdcc's have a very very nasty bug where it will put const data in the wrong segment and not just in the case I fixed. That one is not afaik yet fixed but is in the sdcc bugs.

If you look in my repositories you'll find a more current SDCC than 3.5 which has the banking patches and the initial Z280 stuff in it. I was playing with 8080 support as well but ACK now does the job far better than I was able to get out of SDCC. Some day I may have another go at that, especially 8085.

I've not really pushed the banking fix upstream - it relies on horrible linker hackery so really it needs a clean set of linker fixes. It's only needed for banked kernels anyway (Spectrum and friends, TRS80 model 1)

[EtchedPixels]

For building you should be able to just follow the instructions with the kernel. The only icky bit is that I've not found a nice way to avoid having to create a /opt and putting some of the front end tools there as it builds them.

The kernel build should give you a CP/M bootable (or generally loadable) image. The rest builds tools, libraries and the applications.

[feilipu]

I found your SDCC Bug Report. I'll keep an eye on it too, and hope that it gets resolved for 3.9.0, which I understand, via Philipp, will be their next "stable" version. The intention is to make 3.9.0 the default for z88dk for a while.

[feilipu]

I'm finding SDCC is SIGSEGV-ing all the time (at least 20x so far for this one compile run). Just reading your note that my 8GB RAM may not be enough. So further progress may take a while, or at least until I can get some more RAM installed.

[EtchedPixels]

Should just need some swap. I do laptop builds that way without problem. Without swap then sdcc has some serious performance and memory scaling problems although I think a couple of the worst ones got fixed.

[feilipu]

Yes, I just have a "token" 2GB swap configured, as a hangover from the '00's.

I've never seen the RAM usage on htop go above 50% (this is obviously historical reporting). But this makes me think there's a config issue in my system that prevents a single process taking more than 50% (say) of available RAM.

Anyway, more RAM purchased and on its way. TBC next weekend.

[feilipu]

Now, with 32GB of RAM SDCC doesn't baulk constantly, and

• [x] the fuzix build proceeds to completion.
• [x] I have loaded the fuxix.com file to the CP/M drive on hardware, which was created in this directory, and run it.
• [x] received the panic inode message.
  • [ ] And, how or where to find a the root file system that will need to be loaded?

Are there some instructions that I'm missing?

[EtchedPixels]

The fuzix.com file is the entire OS packed, when you run it then it will take over. It will probe the hardware and report any partition tables and ask for a boot device, to which you can reply something like "hda1" assuming it gets that far.

[feilipu]

We'll I might have to start from smaller steps, as running the fuzix.com file just hung the machine.

Are there some obvious points to insert debug? Or, can it be run with zsid and stepped through?

Even if it got to asking me where the root file system was located, it still wouldn't work because I've no file system ready for it.

Are the contents of the root file system aggregated somewhere? Or, am I picking binaries out of the directory structure?

[EtchedPixels]

zsid will work briefly for the very early setup.

Beyond that your first stop is to stuff a call to outchar somewhere early and debug/check outchar is correct for your system (and on the right serial port etc). Once outchar works then the rest gets rather easier to debug.

Standalone has tools for making a file system image or there are some raw ones on fuzix.org

[feilipu]

It has compiled and when fuzix is run it produces an effective tty output. I'm seeing panic, and some other message about bdwrite.

So I tried expanding the rootfs-z80-32.gz file system fs and writing it using dd if=fs of=/dev/sda2 to a CF card with a sacrificial partition. But, that is not right, otherwise it might have worked.

Is there somewhere describing how to expand the pre-existing file systems (that will do for now) onto a CF card?

[EtchedPixels]

If it gives you a bdwrite panic before trying to mount file systems then for some reason the buffers or data memory was not clear. crt0.s should clear all the buffers and data area and they are also set up in start.c:bufinit() for the initial buffers, and platform/main.c:platform_discard for any added ones.

You did expand the fs right but I don't think it's getting that far. Where does the actual message appear and what is just before it ?

[feilipu]

This is the message where CP/M is loaded into NOT Bank 1 (blank lines deleted).

YAZ180 - yabios - CRT
> :? :-)

> ls
----A 2018/02/04 20:40  16777216  BASCOM53.CPM
----A 2018/02/04 20:41  16777216  BBCBASIC.CPM
----A 2018/03/09 21:15  16777216  C.CPM
----A 2018/07/22 22:18  16777216  SYS.CPM
----A 2018/03/24 14:15  16777216  TEMPLATE.CPM
----A 2018/05/23 00:44  16777216  USER.CPM
----A 2018/02/04 20:42  16777216  ZORK.CPM
D---- 2019/06/23 15:34         0  TRASH-~1
----A 2018/09/21 22:27  16777216  HITECHC.CPM
----A 2018/08/19 19:09  16777216  BASCOM.CPM
   9 File(s), 150994944 bytes total
   1 Dir(s),  803864576 bytes free

> mkcpmb 15 3 sys.cpm user.cpm
Opening "sys.cpm" at LBA 371376
Opening "user.cpm" at LBA 305712
Initialised Bank: 3, for CP/M
> initb 3

A>b:
B>
B>fuzix
bdwrite:
panic: invalid dev
panic: corrupt inode
panic: corrupt inode
panic: inode freed.

...hangs

And when loaded with CP/M in Bank 1... it looks to hang immediately.

YAZ180 - yabios - CRT
> :? :-)

> ls
----A 2018/02/04 20:40  16777216  BASCOM53.CPM
----A 2018/02/04 20:41  16777216  BBCBASIC.CPM
----A 2018/03/09 21:15  16777216  C.CPM
----A 2018/07/22 22:18  16777216  SYS.CPM
----A 2018/03/24 14:15  16777216  TEMPLATE.CPM
----A 2018/05/23 00:44  16777216  USER.CPM
----A 2018/02/04 20:42  16777216  ZORK.CPM
D---- 2019/06/23 15:34         0  TRASH-~1
----A 2018/09/21 22:27  16777216  HITECHC.CPM
----A 2018/08/19 19:09  16777216  BASCOM.CPM
   9 File(s), 150994944 bytes total
   1 Dir(s),  803864576 bytes free

> mkcpmb 15 1 sys.cpm user.cpm
Opening "sys.cpm" at LBA 371376
Opening "user.cpm" at LBA 305712
Initialised Bank: 1, for CP/M
> initb 1

A>b:
B>fuzix

...hangs

I've looked at the configuration file ~/platform-yaz180/kernel.def and it looks right. At least nothing stands out.

There is flash in Banks 0 0x00000-0x0BFFF,13,14,&15, so writing and verifying those banks would cause a failure.

Sorry, for the following list of seemingly banal questions, but I can't find the docs leading to answers. Should the the fs file be written to root of hard drive eg. /dev/hda? Or, can it be written into a partition? Is fs an ext2 formatted image? gparted doesn't recognise it, so perhaps I've broken it somehow? How are the device names represented? What if there's an offset from the start of the drive? Say I write the fs to a CF / HDD starting at block 8192 for example, what configuration do I give fuzix.com when I launch?

[EtchedPixels]

If it gave you a bdwrite message before anything else than it jumped into random wrong space. bdwrite doesn't get called that early. You are nowhere near the point of it even looking for an fs (and it will prompt you first). I would start by putting some debug in Kernel/platform/crt0.s and tracing the early boot logic.

The file system is a Fuzix file system image and can go into a partition or raw to a device

/dev/hda - first hard disk /dev/hda1 - first hard disk partition 1 etc

/dev/hdb - second hard disk

[feilipu]

Doing some paper debugging, I note that PROGTOP value is in the common space starting at 0xF000. That can't be right. Can it?

#define PROGTOP     0xF800  /* Top of program, base of U_DATA copy */
#define KERNTOP     0xF000  /* Kernel has lower 60KB */

https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/platform-yaz180/config.h#L27

[EtchedPixels]

The common isn't common. What you actually have is

<60K kernel bank 0><4K mixed kernel/user per process>

and in user <64K single bank with the top 4K the end of user/kernel common copy>

which is much faster and more efficient. That is why KERNTOP is F000.

[feilipu]

I've turned on DEBUGCOMMON and had a look. What I see is that the code gets to here, and then goes awry somehow. The a register is not printed, nor is the closing > character. But, then the code goes off and panics about inodes.

What I think the code is doing is copying 1:1 from where it is running down to BBR 0x10. I can't see why that would go wrong.

The entry criteria for BBR=CBR is not met, as the CP/M guest system is running in a non-zero bank number, with CBR=0, as the system common area is located in 0x0F000 -> 0x0FFFF. But, that shouldn't matter. The CP/M stack should be in the banked area, so that's not a problem. The FUZIX.COM doesn't use any CP/M resources so the bios, and hence the common area functions, shouldn't be needed.

I guess there's some other issue at play around this?

Perhaps something is copied into the wrong common area, and then the 1:1 copy fails?

[EtchedPixels]

I'm not convinced that debug code hasn't rotted. outcharhex is I think in common , which would mean its not there when you call it that early ?

[feilipu]

Started on PR #733 with those fixes, we get to here...

B>fuzix
FUZIX version 0.3pre1
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 <will@sowerbutts.com>
Copyright (c) 2014-2019 Alan Cox <alan@etchedpixels.co.uk>
Devboot

hangs...

[feilipu]

And, now sometime I get this

FUZIX version 0.3pre1
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 <will@sowerbutts.com>
Copyright (c) 2014-2019 Alan Cox <alan@etchedpixels.co.uk>
Devboot
map_init done
makeproc done
add_argument done
create_init done
768kB total RAM, 704kB available to processes (11 processes max)
Enabling interrupts ... ok.
IDE drive 0: LBA unsupported.
IDE drive 1: ide error, status=0000
bootdev:

Which is almost there, I think.

But, this outcome is not consistent. If I sprinkle a number of kputs() into create_init() it sometimes works, but then remove the debugging and it fails, like some kind of timing issue.

[EtchedPixels]

There shouldn't be any timing issues prior to "Enabling interrupts" because there isn't anything there that is timing connected. More likely it depends on how big the kernel is and create_init is calling uput which should put stuff into user pages but is landing them into the kernel. In other words the size matters not the timing ?