I recently started working on moving some of the standard utility programs for DOS/65 over to the my current CMOS implementation on my prototype C02 Pocket SBC, which uses a Microdrive for storage and has a Maxim RTC (which is not being used by DOS/65 as of yet).

Initially, there were a few utilities that Rich Leary had included in the ROM V3 code:
Super Directory V103
User Copy V302
Submit V300
SysGen V302

I made some changes to the above (sans SysGen) and had those running without much work. I also made minimal changes to the Xmodem file transfer utility which is quite useful for getting data back and forth.

Other utilities that are supplied with the V2 code included:
Alloc - shows disk map block allocation usage
ASM - 6502 (no CMOS support) 2-pass Assembler (creates KIM hex files and a listing file)
EDIT - line editor
COMPL - Basic Compiler (creates a .INT file for the runtime interpreter)
RUN - Run interpreter for the Basic Compiler
MKCOM - converts KIM hex files to .COM files
DEBUG - Code debugger (requires some changes based on specific hardware)
SYSGEN - also somehwat specific to a particular hardware platform
COPY - Basic file copy
COMPR - File compare

I made the required changes to the Assembler and MakeCOM utilities to assemble/link using WDC Tools, which wasn't too difficult. Once those were working and moved over, I was able to assemble all of the above utilities without issue. Note that I did need to make some basic configuration changes so they would work. The larger utilities are the Basic compiler and Runtime interpreter... both of these have large page zero requirements, the latter being a bit more. In short, 136 bytes required to run. I had to change the config for DOS/65 and relocated it's Page Zero usage and free up another 8 bytes, then make another change to the compiler/interpreter to start at location $00 for it's usage. It just fits! Between the C02BIOS, C02Monitor, DOS/65 and Runtime, there's only a single page zero location that is not being used!

I'm still doing some testing and will likely make some changes as I continue working on these. I've only got a simple Mandelbrot Basic program running. Performance seems pretty good, but I'll need to grab another C02 Pocket and put an older config that includes EnHanced Basic to compare to. The program I'm using is from BillO, IIRC... with a couple minor changes.



Lines 5 and 195 are added by me. They invoke the BIOS benchmark timer, which shows 87.87 seconds to complete the program run. The Basic Compiler has an usual CALL command, hence creating a name that references it.

The assembler seems reasonably quick... as the Microdrive performance is quite good and the CPU is running at 8MHz. The Basic Compiler assembled in 94 seconds, and is 3454 lines of code. The generated listing file, which includes the symbol table is 5963 lines long. Files sizes on DOS/65 show as 82KB for the .ASM, 26KB for the .KIM and 162KB for the .PRN (listing file). Longer term view on the assembler is to add all of the CMOS instructions and addressing modes, but who knows how long that will take.

More testing is certainly required... but the next 24 hours or so might render me in the dark with Ian heading towards the state. Granted, I'm on the east coast, but that won't matter much with such a large storm... we're already getting lots of rain!

_________________
Regards, KM
https://github.com/floobydust

Looks like a wasteful use of zeropage?

I wonder what the zeropage locations are used for. I can have a multitasking OS kernal, IEEE488 filesystem driver and monitor and shell and apps loaded at the same time without stuffing zeropage....

_________________
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/

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

Yeah, I think a lot of that in the 1970's / early 1980's ROM based software was more an effort to squeeze the most functionality into the ROM, with "STA zp ... LDA zp" saving two bytes over "STA a ... LDA a".

The Commodore 64 was one of those systems with very little "free" zero page space ... unless you took over the space being used by Basic. It had four bytes available near the top of zero page, and another byte that was unused hidden within the Basic region, and that was about it. You could squeeze out some more for transient use by Basic SYS routines if you knew they weren't going to be called while floating point operations were in process so you could use the floating point value working space, but two (zp),Y addresses and one status byte were about it for a routine called by and returning to Basic.

But the version of Microsoft Basic in the Commodore 64 spilled out of the 8K "Basic" ROM from $0A000-$BFFF into the 8K "KERNAL" ROM from $D000-$FFFF. There really wasn't a lot of spare room. And the whole idea was to "stack them high and sell them low" ... even if putting an additional 4K ROM at $C000-$CFFF had been feasible, it seems likely Jack Tramiel would have instantly vetoed the increase in build cost.

And the KERNAL was inheriting code from the PET and Vic-20 ... when you look at systems like the KIM, the first PET, the VIC-20, there often wasn't all that much RAM in the system -- the VIC-20 only 4K RAM in the whole system. The idea of "put the KERNAL / Basic system variables somewhere else" could well be stymied by the counter-question, "where?"

We've inherited a lot of code from that era and then people have tinkered with it, but much of it has never been rewritten to fit into evolving tradeoffs in zero page RAM, general RAM and ROM since that time.

I have to agree... the Page Zero usage between the Basic Compiler and associated Runtime code is pretty extreme, eithr consuming over half of Page Zero. I haven't really spent any time going thru the code, just enough to get it working within my DOS/65 ROM implementation. There are lots of 16-bit variables and indirect addressing going on there. I think some flag usage as well. Also note that the 2-pass assembler is also quite high in Page Zero usage at 124 bytes. I've not really dug into the Assembler either at this point... just enough to make a version that would assembler under WDC Tools to get it initially working with my system.

I'll also admit that I tend to be a bit high on my Page Zero usage as well:

C02 BIOS: $D0 - $FF, all 48 bytes in use to support the 28L92 DUART, Maxim DS15X1 RTC and an IDE interface with a 16-bit latch.
C02 Monitor: $A0 - $CF, of the 48 bytes allocated, one byte free ($CF), to supports the Monitor functions, which is a lot of stuff (34 commands in all).
- BIOS/Monitor: 96 byte allocated, 95 used.

For DOS/65, there's some shared Page Zero locations for the BIOS and Monitor (in the SIM module).
- Then there's Page Zero usage from $88 - $9F (24 bytes) to support CCM, PEM and SIM.

In total, that's 120 bytes allocated, with a single byte free. Most of the DOS/65 utilities are fairly light on Page Zero usage, sans the Assembler noted above.

On another point, DOS/65 makes use of the Stack Page, albeit not for stack usage. The PEM entry points, default FCB and 128-byte record buffer are all in Page $01, which limits the stack usage quite a bit.
- The total Stack Page usage is from $0100 - $01A7: a total of 168 bytes.

_________________
Regards, KM
https://github.com/floobydust

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

Note, though, that the zero page usage of the Basic Compiler and the zero page usage of the Assembler is the kinds of things that are the reason for keeping system usage to less than half of the zero page, if practicable. The only question I would have regarding the runtime is whether the Basic compiler has a SYS call and how much zero page space is free for a SYS machine language routine to use.

I'll also admit that I tend to be a bit high on my Page Zero usage as well:



That's getting up there toward half, but I reckon that's fine. If I were working on a Forth compiler for DOS/65, it remains an option to put a 32 cell Rack in zero page, have 16 bytes for pseudo-registers and the U common work area, and there's still 48 bytes for application specific usage.



That's a whole other matter ... that leaves enough space for a 32 cell Rack, but depending on coding style, it might be a bit tight for the data stack. If one of the two stacks uses S as it stack index, and the other one uses X, that tends to put the data stack in a high RAM stack page. Pushing the data stack up into higher RAM then makes the amount of zero page used by the system less of an issue.

Good discussion about zero page usage; very timely and helpful since I ran into that problem just now. DOS/65 Basic compiler was not running correctly but I was fortunate to read this thread and fixed the zp usage of the Basic compiler. I ran the mandelbrot benchmark in 48 seconds because CRC65's clock is 14.7MHz. The time it took to assemble Basic compiler (COMPL205.ASM) was 54 seconds, longer than the expected 51 seconds (floobydust 8Mhz C02 took 94 seconds) so perhaps the CF disk is not as fast as the microdrive and/or CF write routine needs optimization.
Bill

One of the possible reasons for the Microdrive being faster would be that I enable the write caching in the BIOS, but also have a call to turn it off. With the 8MHz CPU clock, read performance averages 366KB/second and write performance averages 320KB/second. I've gone thru the BIOS routines multiple times trying to optimize them and feel pretty good about those numbers. Have you managed to run any performance tests for the CF Card routines on CRC65? Be interesting to see...

_________________
Regards, KM
https://github.com/floobydust

I have not done any CF read/write benchmark on CRC65. RUN207.PRN is fairly big file, 188K, so I did a copy of RUN207.PRN from drive C to drive B. It took 10 seconds, so that's 188K reads and 188K writes in 10 seconds for 37.6K/S. I think my write routine is particularly inefficient because it is write-through for every 128 record. A delayed write would be more efficient. There are also lots of copying to/from DOS/65 buffer to CF buffers, so aligning CF buffers on page boundary may be helpful. There were even suggestion in DOS/65 documentation about moving buffer pointer instead of moving buffer data, but there was a warning about write operation that I don't quite understand.

Do you have a benchmark program?

Bill

Yes, the actual data throughput with DOS/65 is relatively slow. I did some more extreme tests using the SUBMIT command copying 100 files between drives and then another test that copied 27 JPG files ranging in size from 148KB to 414KB. The total size for the 27 files totals 6646KB. The time required to read from Drive E: and write to Drive F: was 473.87 seconds. That works out to 28.05KB/Second. This is with the CPU running at 8MHz and the write cache enabled. The Microdrive also has a rotational speed of only 3600RPM, so I'm sure that latency plays a factor copying this much data from one set of LBAs to another.

For timing, my hardware uses a NXP SC28L92 DUART. This chip has a 16-bit counter/timer that gets clocked from the DUART Baud clock, so it's consistent. The BIOS I've written sets up the timer for a 10ms jiffy clock (100 interrupts per second). I use this to provide software RTC functions and have also implemented a 10ms benchmark timer. There is a 16-bit count for seconds and another byte used for milliseconds . Needless to say, the accuracy is within 10ms but the benchmark can go up to 65,535.99 seconds. Starting/Stopping/Clearing the timer variables are available as BIOS calls, as is a Monitor call to display the timed results. I use this with calls from a DOS/65 .SUB file. This does show realistic drive performance at a filesystem level.

Comparing your CF card performance at 14.7456MHz versus my Microdrive performance at 8MHz, I calculated a tiny improvement overall. However, I think the time to manage the buffers, directories and such within DOS/65 is much more the bottleneck than either the Microdrive or a CF Card performance.

I also wrote a small utility program that allows a hardware RTC to be setup along with some testing of an IDE drive. It also has benchmark routines for read and write and uses the BIOS benchmark timer for the results. All of the code is sitting on my Github page. Hope this helps.

_________________
Regards, KM
https://github.com/floobydust