Page 2 of 10

Re: Bootstrap and boot blocks

Posted: 22 Jun 2019 22:22
by EtchedPixels
One via the VDP, one via the 80 column card with shift-F1 shift-F2 on the keyboard switching where the input goes. If you have a comms card you add more users on the serial ports, although I suspect four users doing much more than editing documents would be fairly sucky on a 4MHz CPU :D


Re: Bootstrap and boot blocks

Posted: 22 Jun 2019 22:30
by Dave
Ah, so not really multi-user if there’s only 1 keyboard, but very neat all the same.

Not that it’s very practical - as you say, 4MHz isn’t exactly fast, but a “practical” multi user system might be one user at the console with the second user via the comms port.

Does it do file locking etc. so that only one user can access/write a particular file?

Is it just a “proof of concept”, or is there any software that can actually run ?

Re: Bootstrap and boot blocks

Posted: 22 Jun 2019 22:38
by Martin A
EtchedPixels wrote: 22 Jun 2019 20:07 Is the stuff that CP/M does calling via 0xFFF9 documented somewhere. I can see the call ends up loading 0x34 sectors to CE80 but not how you set which sector to start or what happens if you call it multiple times.
The FDX technical manual section 1.6 has the basic details of the high memory allocation. That includes both the routine entry points and the data.

The CFX series keep to the same interface to maintain compatibility with the original 80's BDOS.

The source file for that part of the boot rom is CPMvectors in the archive.

Re: Bootstrap and boot blocks

Posted: 22 Jun 2019 22:50
by Bill B
Dave wrote: 22 Jun 2019 20:01 Bill Brendling has just released a Python script that compiles Z80 opcodes written in Microsoft MASM, Bill's own ZASM and Martin's assembler formats.
I am in the process of writing some documentation, but for now the help screen is:

Code: Select all

usage: [-h] [-v] [-b [BINARY]] [-f FILL] [-x [HEX]] [-n] [-l [LIST]]
                 [-a] [-o [OUTPUT]] [-r {MA,M80,ZASM}] [-m] [-k [KEEP]] [-e]
                 [-c {Z80,Z180}] -s {MA,M80,ZASM} [-p] [-d]

Assemble Z80 code written in different styles

positional arguments:
  source                The Z80 source file

optional arguments:
  -h, --help            show this help message and exit
  -v, --version         show program's version number and exit
  -b [BINARY], --binary [BINARY]
                        Machine code in binary format
  -f FILL, --fill FILL  Fill byte for undefined addresses
  -x [HEX], --hex [HEX]
                        Machine code in Intel hex format
  -n, --number-build    Append build number to assembled file names
  -l [LIST], --list [LIST]
                        List file
  -a, --address         Show load address as well as relocation
  -o [OUTPUT], --output [OUTPUT]
                        Reformatted source file
  -r {MA,M80,ZASM}, --reformat {MA,M80,ZASM}
                        Style for reformatted source (default M80)
  -m, --modeline        Emacs modeline in reformatted source
  -k [KEEP], --keep [KEEP]
                        Keep pass 1 list file
  -e, --echo            Echo source to screen
  -c {Z80,Z180}, --cpu {Z80,Z180}
                        The processor type
  -s {MA,M80,ZASM}, --style {MA,M80,ZASM}
                        The style of the Z80 source
  -p, --permissive      Ignore some syntax errors
  -d, --debug           Show assembler debug info

Re: Bootstrap and boot blocks

Posted: 22 Jun 2019 23:12
by Bill B
EtchedPixels wrote: 22 Jun 2019 19:09 The rest works - at least on MEMU. As ever that doesn't always mean it runs on the hardware because emulators are never perfect - and also it doesn't emulate the CFII.
There is a version of MEMU that emulates the CFX-II, including the CF ... memupi.htm.

The source code there will build six versions of MEMU on a Raspberry Pi. The first four versions will also build on x86 Linux. These versions are:

This is the classic command line version of MEMU, but with additional features (see below). It requires XWindows, and is configured using the command line.

This version also requires XWindows. Configuration is specified by a configuration file "-config-file memu.cfg" and a configuration dialog. Try <SysRq>, <Windows> or <Windows Menu> keys to open the dialog (not all environments pass all keys).

Command line version that does not require XWindows. Instead each window is shown full screen (using frame buffer). Use <Ctrl> plus function keys to switch between windows.

Configuration dialog version that does not require XWindows.

Configuration dialog version that does not require XWindows. Uses GPU to display. Can use RPi GPIO to attach: MTX keyboard, Atari style joysticks, printer, PIO (Note only 3.3v not 5v). Specify hardware as "-hw-config hardware.cfg". Example file for MTX keyboard included.

The bare metal versions for the different RPi processors. This version uses two configuration files "memu0.cfg" (static) and "memu.cfg" (changed by the configuration dialog). It supports use of GPIO to attach hardware (specify "-hw-config hardware.cfg" in "memu0.cfg"). At present this version does not use the GPU, nor does it provide DART emulation. More work to do. However it is currently the best one to use for MTX-Pi.

All of these versions include:

CFX-II Emulation:
Enable this with "-cfx2 rom_file". The rom_file should be 16KB as Martin produces, it is automatically split into rom 4 and rom 5. CF partitions are specified as separate files, which means that the same files can be used as either SID drives or CF partitions. Specify the partitions as -cf-image c:p image_file", where "c" is card number (0 or 1) and "p" is partition number on the card (0-7).

There is a technique to getting into CFX CP/M mode. First press and hold both the <Alt> keys. Then press and hold the "C" key. Release the <Alt> keys. Continue to hold the "C" key long enough for the CFX ROM to recognise CP/M mode required. This order is necessary because XWindows will not report the second <Alt> key if the "C" is already down.

Enhanced keyboard re-mapping:
Enable this with "-kbd-remap". This now works as per the Propeller hardware interface. By default Andy's original mapping. Hit <Scroll Lock> to make use of the three "missing" keys to match the shift state of most characters. <F12> to turn on <Num Lock> so that keypad keys produce the digits as labelled. The "-kbd-remap" switch also applies the ROM patches to support the three extra keys.

Load and save audio (*.wav) files:
Enable this with "-cassette-in file" or "-cassette-out file". The files may be either *.wav or *.mtx. *.mtx files are converted to/from audio during load/save. Clearly this is much slower than the usual way of loading *.mtx files. To keep the file size down the attached Zip file only contains a couple of examples in the "tapes" folder.

Slightly improved usage message:
If there is an issue with the command line, it tells you which switch is causing the problem.

Re: Bootstrap and boot blocks

Posted: 22 Jun 2019 23:43
by EtchedPixels
@Dave It implements a fairly full classic Unix compatible kernel and file system - the command line shell is the real bourne shell, most of the general utilities are there, I has assemblers and linkers but the C compiler and a native basic are ongoing projects. It can also run CP/M apps although right now on the mtx because of the memory layout you are limited to a TPA of about 44k (will be 47.25 when I fix a few things). It's also quite good at playing adventure games because it's got interpreters for older Infocom, Scott Adams, Brian Howarth, Quill and older Level 9 games. Still need to do a PAW engine. And yes it has file locking (or because it's Unix two people can modify the same file at the same time too if they want)

So yes it has real apps. Is it useful .. probably no but that's not the point :lol:

@Martin: thanks I will go and read up on this as I doubt I can get a CF version 1 loader in 128 bytes.

@BillB: Thanks for the pointer I will take a look


Re: Bootstrap and boot blocks

Posted: 22 Jun 2019 23:55
by Dave
Hi Alan,

We have done lots with MTX that is not really useful, but cool all the same. :)

This looks like another one - well done!

I will check out the details.

Can I suggest that, when you’re ready, you make a CF image available so that Unix novices like myself can get it running quickly without having to build from scratch?

Re: Bootstrap and boot blocks

Posted: 23 Jun 2019 10:23
by stephen_usher
I was wondering how long it would be until you tried to get this running on the Memotech, Alan. I miss your updates since Google+ went away.

It's nice to see a bit of 'anarchy' on the board. ;-)

I would imagine that the system, even on a 4MHz processor, would work better if you had more memory to play with? Maybe even use memory paging as a memory protection system, though the 16K granulatity might be a bit of a problem.

Re: Bootstrap and boot blocks

Posted: 23 Jun 2019 17:08
by EtchedPixels
So I've done a bit more work on it to add SD card (not tested but should?? be trivial), 80 column card probing and surviving on 40 columns only.

I've added the basic bits for CF1 (not tested). Right now CF1 needs a different kernel build. I'd expect it to work as it's all library code that's the same for other platforms using the 82C55 approach.

I assume nobody has ZIP drives wired to their parallel port or bitbanged SD cards on printer or the internal PIO ?

@stephen: Memory isn't actually the real limit. If you have 400K or so available and running rather than waiting for an event then you've got 7 things to do at once which on a 4MHz Z80 isn't generally very pleasant. If you have lots idle then you have swap. Not only that but a CF card is actually faster than the RAM in the MTX so the impact of swapping is not much more than a memory copy, and even on a real MTX once I have a couple of oddments fixed you could swap on a silicon disc.

@Dave: will generate some images and post them up when I have a bit of time. I've run out of CF cards that work with the CFII so need to order a few and see which do in order to test the images.

(just to keep the mr usher happy)

Re: Bootstrap and boot blocks

Posted: 23 Jun 2019 17:58
by Dave
Hi Alan,

that's great - thanks a lot.

So, you're hoping to get it working with CFX-I and CFX-II? - That's good, there are more CFX-Is in the world (not that there are many of either)

Are you having issues with some CF cards and CFX-II?