[N8VEM: 19923] Grant Searle's mulicomputer revisited: update 1

[RHKoolaap]

Hi all,

This installment is an update.

The ROM monitor has been updated: it is no longer limited in volume number
use. The user can assign volumes upto 242, but use of non-existent volumes
must be avoided.
The dump command now defaults to 8 lines of text while typing a singe D
continues where it left off.
The change command is now interactive. Both D and C commands use the
DDT/SID interface (mostly)

The command MOUNT.COM is now OS aware. Only one binary is to be used in all
CP/M environments. Please discard all previous versions! Remounting drive
A: has been discontinued, because it was mostly useless anyway. A reboot
makes more sense.

ZSID.COM has been patched to use RST 6 instead of RST 7. This was messing
with interrupt mode 1

The CPM-2 BIOS has been updated, the vector to the mount table now resides
in FFFE-FFFF, while the backdoor load address is FFFB.

The FPGA configuration and the BIOSes have changed to use four 16 kByte
memory pages instead of sixteen 4kbyte pages. This frees up LE's in the
FPGA to facilitate 4 consoles, with some extra wriggle room.

The FPGA defaults to 3 consoles: the first is a VDU, the second and third
are RS-232. Off course a 4 serial console setup can still be programmed.

Not Yet Implemented:
- Date and time for the CP/M 3 and CP/M 2 BIOSes. I ran into trouble
implementing interrupt mode 1 in CP/M-3. Even with a simple "ei reti" as a
service routine the system crashes as soon as interrupts are enabled.
Perhaps location 38h in page 0 is overwritten by the OS. Suggestions are
welcome. For CP/M 2-ish there are no such problems. I just haven't gotten
to it yet. Dos+ supports date and time natively.

- Sensing SD card size. No ideas about that yet.

- Any requests?

Here are the files:
http://www.filedropper.com/filemanager/public.php?service=files&t=12c40d737402ce20e5871c3231327332


be well... RHK

[William R Sowerbutts]

I ran into trouble implementing interrupt mode 1 in CP/M-3. Even with a
simple "ei reti" as a service routine the system crashes as soon as
interrupts are enabled. Perhaps location 38h in page 0 is overwritten by
the OS. Suggestions are welcome.

Is your interrupt vector at 38h and the corresponding handler code always
present in the CPU address space? For example, do you bank switch some other
memory bank over either of these locations?

Does the hardware correctly handle the Z80 interrupt acknowledge cycle? I had
problems with socz80 when I started using interrupts -- /IORQ and /M1 are
both active during an interrupt acknowledge cycle and my hardware was
decoding every interrupt acknowledge as an I/O operation. A little time in
the simulator helped to debug this.

Will

_________________________________________________________________________
William R Sowerbutts ***@sowerbutts.com
"Carpe post meridiem" http://sowerbutts.com
main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
(m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}

[Alan Cox]

I hit a similar problem initially with CP/M 3 on the SocZ80 - the CP/M
documentation doesn't cover it well but you need to write the vectors
into each low bank on startup
in the CP/M loader, and you also need to generate a system that
doesn't try to use the low 256 bytes in each extra bank.

The other gotcha is that you need a valid stack at all times. If you
do a bank switch then you need to be sure your stack is valid even if
you take an IRQ mid switch.

The CP/M stacks and app stacks often only have a few bytes "spare" so
any IRQ handler using more than a few bytes of stack must also switch
stack itself.

Alan

[RHKoolaap]

Hi Alan, Will,

Both of you are making valid points. I hadn't tried to start bank 0 at
page 1 instead of page 0. I'll give it another shot, tomorrow
Thanks for the assistance, I'll let you know how it goes.

RHK

Post by Alan Cox
I hit a similar problem initially with CP/M 3 on the SocZ80 - the CP/M
documentation doesn't cover it well but you need to write the vectors
into each low bank on startup
in the CP/M loader, and you also need to generate a system that
doesn't try to use the low 256 bytes in each extra bank.
The other gotcha is that you need a valid stack at all times. If you
do a bank switch then you need to be sure your stack is valid even if
you take an IRQ mid switch.
The CP/M stacks and app stacks often only have a few bytes "spare" so
any IRQ handler using more than a few bytes of stack must also switch
stack itself.
Alan

[RHKoolaap]

Replying to myself again...

making bank 0 start at 0100h did the trick. I am using bank 0, 1 and 2.
Bank 2 already starts at 1000h because it stores the CCP
I also added the jump to set$jumps in bioskrnl.asm, but only for bank 1.
The clock is working now.
I will implement the suggestion of using a separate stack, like the one
recommended for MP/M

I'll now add time and date to the CP/M 2 BIOS. After that maybe time for
the next update :-)

Thank you all for your kind support, RHK

Post by RHKoolaap
Hi Alan, Will,
Both of you are making valid points. I hadn't tried to start bank 0 at
page 1 instead of page 0. I'll give it another shot, tomorrow
Thanks for the assistance, I'll let you know how it goes.
RHK

Post by Alan Cox
I hit a similar problem initially with CP/M 3 on the SocZ80 - the CP/M
documentation doesn't cover it well but you need to write the vectors
into each low bank on startup
in the CP/M loader, and you also need to generate a system that
doesn't try to use the low 256 bytes in each extra bank.
The other gotcha is that you need a valid stack at all times. If you
do a bank switch then you need to be sure your stack is valid even if
you take an IRQ mid switch.
The CP/M stacks and app stacks often only have a few bytes "spare" so
any IRQ handler using more than a few bytes of stack must also switch
stack itself.
Alan