tremendous progress - I'm impressed.


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

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:


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

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L

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

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


Exactly


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

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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:



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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Impressive. 29.5 MHz is really fast!

Dietrich

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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:



*********************************
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

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

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L

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

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L

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

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

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

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L