Author Topic: CP/M question... for someone who has in-depth technical knowledge of CP/M  (Read 851 times)

0 Members and 1 Guest are viewing this topic.

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 616
  • Country: au
  • aka Vorax
    • 8bitology
  • Liked: 257
  • Likes Given: 227
Hi,


I was looking at both the CP/M 2.2 and CP/M Plus API and it looks fairly simple and small - at least for CP/M 2.2.


To implement a CP/M 2.2 wrapper to allow CP/M programs to work on AMSDOS, it looks like it should be fairly straight forward - is there something I am missing that has prevented someone from doing this already?


Is it purely to do with the TPA available if sitting within HIMEM?  What if CP/M 2.2 was running in the 2nd 64k bank with BASIC still in the first and a way to swap between them quickly?


Offline GeoffB17

  • 6128 Plus
  • ******
  • Posts: 787
  • Country: gb
  • PCW since '85, more CP/M than Loco
  • Liked: 169
  • Likes Given: 9
I'm not sure what you describe is possible.   If it is, you'd need to significantly restructure CP/M, recompile it, and work out a non-standard way to start/activate it.

And note that 2.2 does NOT support bank swapping, only 3.0 (Plus) does that.   There is the ZCPR etc system, however, which might be considered as CP/M 2.2++, that might do some?

CP/M normally uses the whole computer.   I'm not sure it could co-exist with AMSDOS, certainly not in it's standard form.   And which BASIC are you referring to when you refer to a BASIC remaining in the base memory space (with AMSDOS)?

In operation, a CP/M prog expects to be in RAM from &H100 upwards.  A standard CP/M prog could not operate anywhere else.  Your 'wrapper' would need to allow this.   The prog would then implement much of it's functionality via BDOS and BIOS calls to the CP/M services, the BDOS via a call to &H0005, and the BIOS calls (in the cases where they are called directly rather than via the BDOS) via &H0000.   Your wrapper would need to support those calls, although they could THEN be directed elsewhere, maybe even via a bank swap.

I'd need to know a LOT more about what you were thinking of doing before I could comment further.

Geoff

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 616
  • Country: au
  • aka Vorax
    • 8bitology
  • Liked: 257
  • Likes Given: 227
I'm not sure what you describe is possible.   If it is, you'd need to significantly restructure CP/M, recompile it, and work out a non-standard way to start/activate it.

And note that 2.2 does NOT support bank swapping, only 3.0 (Plus) does that.   There is the ZCPR etc system, however, which might be considered as CP/M 2.2++, that might do some?

CP/M normally uses the whole computer.   I'm not sure it could co-exist with AMSDOS, certainly not in it's standard form.   And which BASIC are you referring to when you refer to a BASIC remaining in the base memory space (with AMSDOS)?

In operation, a CP/M prog expects to be in RAM from &H100 upwards.  A standard CP/M prog could not operate anywhere else.  Your 'wrapper' would need to allow this.   The prog would then implement much of it's functionality via BDOS and BIOS calls to the CP/M services, the BDOS via a call to &H0005, and the BIOS calls (in the cases where they are called directly rather than via the BDOS) via &H0000.   Your wrapper would need to support those calls, although they could THEN be directed elsewhere, maybe even via a bank swap.

I'd need to know a LOT more about what you were thinking of doing before I could comment further.

Geoff


Best option is, CP/M fully in additional 64kb RAM banks.  Because CP/M 2.2 doesn't support bank swapping, it won't realise it is in an additional 64kb bank - it will be happy.  With regard to CP/M keyboard input or text output, it can use a buffer for input and a text screen for output (takes less than 2kb) which only really gets rendered when you manually swap to see CP/M. 


What are the minimum BIOS and BDOS calls we would need to implement for this?  We could potentially run 8 CPM's in a 512kb machine.

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.939
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 1157
  • Likes Given: 1924
Maybe I'm missing the point, though I would probably suggest running BBC BASIC, though I seem to recall you to not liking BBC BASIC, though the CPC version of it, is the closest thing to Locomotive BASIC in terms of getting it as close to making it like a BBC using CPC hardware. It's compatable with CP/M 2.2, though I strongly suggest CP/M Plus because of the Disk Switchy thing you have with CP/M 2.2, which makes it a real pain...



* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 616
  • Country: au
  • aka Vorax
    • 8bitology
  • Liked: 257
  • Likes Given: 227
I just downloaded the CP/M 2.2 source from here: http://cpuville.com/Code/CPM-on-a-new-computer.html


and fixed the 180+ maxam errors in WinAPE and it now assembles fine.  At a glance it looks like not a massive task to make it run in a 64k bank in parallel to CPC BASIC - especially if I only need to re-write the conin, conout and const... and then the disk operations, perhaps I could confine to a RAMdisc, at least from a POC point of view.  Then... an RSX to execute .com files with a special loader to put that small assembled CP/M in the right memory location, also put the .com file at 100h (in the 2nd 64kb bank) and run it...  a reboot of CP/M can of course close the CP/M?  that would let us run, eg: nulu from AMSDOS (against a RAMDisc).  Of course if it works in a 2nd 64k bank, and we have 8 of them... we can easily multi-task.


Perhaps CP/M is too boring?  I guess somewhat.