CPM-65 - yet another approach

[Dietrich]

tremendous progress - I'm impressed.

plasmo wrote:

I'm still confused about DIRMSK. In the original BIOS there are 32 sectors designated for directory, so that's 256 directory entries and value of DIRMSK is %10000000. I want to have 512 directory entries so that's 64 sectors for directory. What should the DIRMSK value be?

If you stick with 32 sectors per block, then DIRMSK would be %11000000, since you need 2 blocks.

plasmo wrote:

The question now is how to get CPM65 files into the CF disk. In CP/M-80 I would load the XMODEM binary in TPA, start CP/M and use CCP's 'Save' command to create XMODEM.COM and then use XMODEM to bring in rest of the files. 'Save' command is not in CPM65's CCP, but I can still load XMODEM binary in TPA, patch the CCP so when CPM65 starts up, it jumps to TPA to execute XMODEM binary. There is a 'cflag' for CPM65's CCP that may be used for this purpose?

My XMODEM.COM does the saving after the transfer. Syntax is XMODEM filename.ext. The transfer in the current version is PC --> 6502 only.
Actually saving a file is so easy, that all my programs nedding this feature have a save code built in. In the case of XMODEM that is:

Code: Select all

          JSR XMODEM
          BCS STERR
.
.
          JSR SETDMA

START3    LDX #WRITE
	       JSR BDOS
	       BCS STERR
	       JSR INCDMA
          BCC START3
          LDX #CLOSE
          JSR BDOS
          BCS STERR
          LDA #SUCCESS
          LDY #SUCCESS/256
          JSR STR_OUT

You got me on the CFLAG. It was intended to invoke commands from a command file to automate things. In the end, I never used this and its probably not well designed. What CCP really does well, like the CP/M original, is, if you call a program with filenames as arguments, it will put the first filename in FCB1 and the second filename in FCB2 ready to use for the program.

Your screen output for D.COM looks really good. However ALLOC.ASM seems way too long.
BTW what is TIME.ASM?

Keep going - you are nearly there

Dietrich

[plasmo]

Dietrich,
I added the CF write routine and created multiple CF drives so now I'm able to copy files from one drive to another. In your example BIOS, I see all drives share the same DIRBF, DMA and BAT buffers. CP/M-80's drive has separate directory and allocation buffers, that's not necessary for CPM-65? If so, that's a great improvement because buffers eat up lots of BIOS memory space.

My block size is 4K (16 sectors) so for 512 entry directory I'll need DIRMSK of %11110000, right?

Using DOS/65's xmodem to transfer CPM65 files worked up to a point. I ported ASM.ASM to CA65 assembler so it can be assembled to ASM.COM on my PC then copy ASM.COM to CPM65 disk along with all distribution files in assembly sources. After a few tries I'm able to assemble all .ASM sources to .COM using CPM65's native ASM. One of the problems was the original .ASM sources as downloaded from GitHub is unix-coded text files(line-feed termination instead of carriage-return+line-feed), so I need to convert them (I used unix2dos) before transferring them to CPM65 disk. Another problem is I can't find BASIC.ASM on the directory. BASIC.ASM is transferred with DOS/65's XMODEM, but D.COM can't find it when I display the directory of the entire disk, but if I type "d basic.*", it will show the file. I think it has something to do with incompatibility between DOS/65 file format and CPM65. BASIC.ASM requires 2 extents to store and through experimentation I've found files bigger than 32K (which requires 2 or more extents) are not visible. Using your DUTIL I'm able to see BASIC on the directory, so it is on the disk. I'll work on getting BASIC transferred correctly to CPM65 because I'm dying to try your StarTrek BASIC program! BTW, CPM65 is running on 29.5MHz CRC65 so the native assembler is running lightening fast, every program took less than a second to assemble.

I believe I have the CPM65 core functions in place now. What I need to do is auto-boot CPM65 so CRC65 will power up and boot directly into CPM65.

BTW, TIME.ASM is TIMEDATE.ASM. I want to work on CPM65's I2C functions soon.
Bill

[Dietrich]

plasmo wrote:

In your example BIOS, I see all drives share the same DIRBF, DMA and BAT buffers. CP/M-80's drive has separate directory and allocation buffers, that's not necessary for CPM-65? If so, that's a great improvement because buffers eat up lots of BIOS memory space.

Yes indeed, but this design comes with a caveat: you can have only one file open for R/W at a given time and if you try to write in a opened file and need a new block for the first time, the BAT has to be rebuilt. Surprisingly this design is pretty nimble even on 1 MHz and the inability to access more than one open file has never been an issue for me, so I stuck with it.
Also I have to confess, that my READ/Write routines don't allow random R/W. I planned to change that some day, but it never came to that ...

BTM, I uploaded a BDOS command overview on my repo to make your life a bit easier

plasmo wrote:

My block size is 4K (16 sectors) so for 512 entry directory I'll need DIRMSK of %11110000, right?

Exactly

plasmo wrote:

I'm dying to try your StarTrek BASIC program!

Ok, I see - thats really a cool program from the old days - source is David .H. Ahl, Basic Computer Games. My version is in German though.
Be aware, that my basic is afaik not able to load txt files with the built in LOAD command. So you will have to feed the source via TeraTerm and appropriate waiting time after each CR. I have never done that though. My listing was hand typed 20 years ago, but still works of course.

have fun

Dietrich

[plasmo]

I have not figured out how to xmodem the large BASIC.ASM file to CPM65, but I ported the BASIC.ASM to CA65 assembler and assembled it on my PC. It is working well enough to run first part of the StarTrek. I took German in high school 50 years ago, I think I may need to look up a few words!
Bill

[BigDumbDinosaur]

plasmo wrote:

It is working well enough to run first part of the StarTrek. I took German in high school 50 years ago, I think I may need to look up a few words!

You can almost figure it out, even if you don’t know German, as long as you are familiar with the Star Trek story. (Who under the age of 90 isn’t familiar with it? ) For example, Sternentag is “star date.”

[plasmo]

BigDumbDinosaur wrote:

You can almost figure it out, even if you don’t know German, as long as you are familiar with the Star Trek story. (Who under the age of 90 isn’t familiar with it? ) For example, Sternentag is “star date.”

StarTrek was my very first computer game; I was green with envy watching graduate students with extra computer time playing it in the computer room. It motivated me to be extra careful with homework assignments so I'll also have extra time left after homeworks were done to play StarTrek.


Dietrich,
I ran the Mandelbrot benchmark on your BASIC:

Code: Select all

10 MAXITER=20
20 LET C$=" .,'~!^:;[/<&?oxOX#  "
30 FOR Y=-39 TO 39
40 FOR X=-39 TO 39
50 CREAL=X/20
70 CIMAG=Y/20
80 ZREAL = CREAL
90 ZIMAG = CIMAG
95 COUNT = 1
100 ZM = ZREAL*ZREAL
105 ZN = ZIMAG*ZIMAG
107 ZL = ZM+ZN
110 IF ZL>4 THEN GOTO 170
120 Z2=ZM-ZN+CREAL
130 ZIMAG=ZREAL*ZIMAG*2+CIMAG
140 ZREAL=Z2
150 COUNT=COUNT+1
160 IF COUNT<MAXITER THEN GOTO 100
170 PRINT MID$(C$,1+COUNT,1);
180 NEXT X
185 PRINT ""
190 NEXT Y
200 END

On 29.5MHz CRC65 it ran 44 seconds. Here are comparison to other BASIC:
DOS/65 (29.5MHz) MicroSoft BASIC 51 seconds
DOS/65 EhBASIC 45 seconds
DOS/65 BASIC compiler 24 seconds
29.5MHz Z80 CP/M Microsoft BASIC 115 seconds.

Bill

[drogon]

plasmo wrote:

Dietrich,
I ran the Mandelbrot benchmark on your BASIC:

Code: Select all

10 MAXITER=20
20 LET C$=" .,'~!^:;[/<&?oxOX#  "
30 FOR Y=-39 TO 39
40 FOR X=-39 TO 39
50 CREAL=X/20
70 CIMAG=Y/20
80 ZREAL = CREAL
90 ZIMAG = CIMAG
95 COUNT = 1
100 ZM = ZREAL*ZREAL
105 ZN = ZIMAG*ZIMAG
107 ZL = ZM+ZN
110 IF ZL>4 THEN GOTO 170
120 Z2=ZM-ZN+CREAL
130 ZIMAG=ZREAL*ZIMAG*2+CIMAG
140 ZREAL=Z2
150 COUNT=COUNT+1
160 IF COUNT<MAXITER THEN GOTO 100
170 PRINT MID$(C$,1+COUNT,1);
180 NEXT X
185 PRINT ""
190 NEXT Y
200 END

On 29.5MHz CRC65 it ran 44 seconds. Here are comparison to other BASIC:
DOS/65 (29.5MHz) MicroSoft BASIC 51 seconds
DOS/65 EhBASIC 45 seconds
DOS/65 BASIC compiler 24 seconds
29.5MHz Z80 CP/M Microsoft BASIC 115 seconds.

Bill

Some time back I took a variant of that code and adapted it to a format that had a bug corrected and one that would run on all the BASICs I had access too as a crude way to benchmark them - what it's really testing though is floating point performance and not much else.

The code is here:

https://unicorn.drogon.net/mandel.bas

with expected output:

https://unicorn.drogon.net/mandel.txt

The time on that output (48 seconds) is BBC Basic 4 on my Ruby system which is a 16Mhz 65C02. Scaling the times to your 29.5Mhz system, I'd expect it to run in about 28 seconds - which probably demonstrates that even with a compiled BASIC, the overhead is still the floating point calculations..

-Gordon

[Dietrich]

Quote:

Dietrich,
I ran the Mandelbrot benchmark on your BASIC:

Impressive. 29.5 MHz is really fast!

Dietrich

[BigDumbDinosaur]

Dietrich wrote:

Quote:

Dietrich,
I ran the Mandelbrot benchmark on your BASIC:

Impressive. 29.5 MHz is really fast!

Dietrich

He’s got one of those liquid-cooled 65C02s.

[plasmo]

drogon wrote:

Some time back I took a variant of that code and adapted it to a format that had a bug corrected and one that would run on all the BASICs I had access too as a crude way to benchmark them - what it's really testing though is floating point performance and not much else.

The code is here:

https://unicorn.drogon.net/mandel.bas

-Gordon

I've learned from previous benchmarks that BBC BASIC is very fast. Taking your code and runing it on 29.5MHz CRC65 in CPM-65 BASIC and DOS/65 BASIC I have these results:

Code: Select all

DOS/65 BASIC compiler                     24 seconds
DOS/65 Microsoft BASIC                   56 seconds
CPM-65 BASIC                                49 seconds.
Ruby BBC BASIC scaled to 29.5MHz,         26 seconds.

*********************************
Running to 29.5MHz requires a small minimal 6502 SBC. I know CRC65 won't run 29.5MHz plugging into a back plane driving another board. 25.175MHz seems much more stable which is the 60Hz VGA clock. I have CRC65 plugged into backplane driving vido board, quad serial board and blinking light display board while running at 25.175MHz.
Bill

[Dietrich]

Quote:

I've learned from previous benchmarks that BBC BASIC is very fast. Taking your code and runing it on 29.5MHz CRC65 in CPM-65 BASIC and DOS/65 BASIC I have these results:

Code:
DOS/65 BASIC compiler 24 seconds
DOS/65 Microsoft BASIC 56 seconds
CPM-65 BASIC 49 seconds.
Ruby BBC BASIC scaled to 29.5MHz, 26 seconds.

That is no surprise. My BASIC was disassembled and rewritten from a BASIC, I extracted from a CBM 8032 in 1982. So it is essentially a Microsoft BASIC.

Dietrich

[Dietrich]

I just published a first port of CPM-65 on the Apple II, see https://github.com/Dietrich-L/CPM-65-for-Apple-II

A 80 col card is required.

Feedback is welcome

Dietrich

[fachat]

Very cool!

What are you using as timer source or Interrupt source? My understanding is the Apple II does not have timer interrupts up until the IIe

[Dietrich]

fachat wrote:

Very cool!

What are you using as timer source or Interrupt source? My understanding is the Apple II does not have timer interrupts up until the IIe

Well, CPM-65 does not need any timers or interrupts, except for the debugger, which uses the BRK interrupt.
My own system, a heavily modified Elektor Junior Computer, uses timer interrupts for various purposes, e.g. disk access timeouts, and also offers BIOS functions for timers to be used by any apps. The Apple II version doesn‘t have those though. Its actually a shortcoming of the original design.

Dietrich