I've finally completed the DOS/65 Version 3.20 code, yay (and there was much rejoicing).

This version has heavily re-written and modified CCM and PEM modules and a new SIM module. All disk accesses are done at a record level (no track/sector) and SIM performs blocking/de-blocking to the 512-byte LBA size on the IDE interfaced Microdrive.

All of the specific code for removable media (i.e., diskettes) has been eliminated along with some other enhancements and fixes. The new SIM version manages delayed block writes to improve performance and minimizes block reads as each disk block contains 4 PEM records.

I placed the code and the complete hardware/firmware for the 3.3-volt prototype system on my Github page:

https://github.com/floobydust/CO2-Pocket-SBC-2.5

All of the usual DOS/65 utilities are there as well. There's a PDF write-up for DOS/65. All source code is heavily documented and can easily be ported to other assemblers as required. As is my usual tooling.... WDC Tools for BIOS, Monitor, Microdrive Utility, DOS/65 V 3.20 and some of the core utilities (Xmodem, SD, ASM, Ucopy, Submit).

I'm still working to finish the Boot Block Loader, which will be in combination with my recent Partition Block. For now, the ROM based Monitor can easily load the DOS image from the drive to memory via Ctrl-B and JMP to the SIM cold start. PEM and SIM warm start already reload CCM and PEM from the Microdrive.

This version has been heavily tested using a ton of key-whacking, downloads, uploads, and SUB files (Batch processing) to copy files between drives, compare files between drives and build the entire DOS/65 utility programs.

I hope others can get some use from this code. CCM and PEM will run on any CMOS processor, as will SIM. All that's needed is a local BIOS to provide access to the console and disk routines.

Have Fun!

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

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

Well, as many prefer to suffer in silence, some of us prefer to celebrate in silence... there was a nice bottle of wine at least.

65C816... true enough, as the code uses the old Rockwell CMOS extensions (SMB, RMB, BBS, BBR), which WDC also support. It is possible to move many of those over to TSB/TRB instructions without much difficulty. By combining several flag bytes used in CCM and PEM, I was able to replace many of them with a single page zero location. The new SIM module also uses a single page zero location for all of it's flags. That can still be the case using TSB/TRB and the BIT instruction. You'll use some additional memory space, but there's no shortage of spare bytes in all 3 allocated modules.

I've been trying to conserve as much memory space as I can... as a future extension is to increase the number of supported drives from 8 to 16.

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

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

Good to hear about the progress so far...

Magic numbers.... well, yea, CCM and PEM have some of those kicking about... I cleaned up the source quite a bit and rewrote several sections and removed some as well. The end result is it's smaller and does run a tad bit quicker. My SIM module doesn't have any magic numbers... I'm usually pretty good at documenting code... so I hope that update goes over pretty well. But I guess it gets down to how your POC provides access to the SCSI drives. Hope to see this running soon.

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

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

Well, I can safely say there have been no changes to the code since the 3.20 final release. I agree with the magic number bits, but those were already there. The bulk of my work on CCM and PEM has been to rewrite multiple routines using CMOS instructions and addressing modes, condense page zero usage, remove the track/sector translations and diskette (removable media) based code, fix a few drive select issues along with some general source code cleanup. Both modules are smaller and many of the routines are a bit faster due to the rewrite.

On another note, I've had this code running on my 3.3-volt system for quite some time now and it's been completely stable and operates without any issues or crashes. I've also used most of the version 2.x utilities (assembler, basic compliler and runtime, alloc, makecom, etc.) without any modifications. The disk based tools work fine as well, albeit I did make a few changes to the Basic SYST program to display records vs tracks/sectors.

If anyone else has opted to get this code working on a system, I'd like to hear about the experience and/or any issues getting it running.

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

I have some free time coming up so I want to port v3.20 to CRC65. Richard Leary’s v3 is already ported to CRC65 so hopefully porting to v3.20 will be straightforward. CRC65 can also be configured to 65816 so I’m watching BDD’s progress with interest.
Bill

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

floobydust,
After refresh my memory about DOS/65 rev3.0 and how it was implemented on CRC65, I started the migration of rev3.0 to rev3.2. Since I do have a working rev3.0, I thought the easiest approach is replacing rev3.0 PEM and CCM with rev3.2 PEM/CCM and keep SIM the same. Yes, I know there are significant changes to PEM and CCM that'll impact SIM, but I need to start somewhere and taking baby steps. I'm also using CA65 assembler so I need to fix some syntax differences. DOS/65 3.2 starts from 0xC600; I padded rev3.2 CCM and PEM so PEM will start from 0xD000 and SIM starts from 0xDC00 and TEA starts from 0x400. These were the rev3.0 values for CCM, PEM, SIM, and TEA

With new (rev3.2) CCM/PEM and old (rev3.0) SIM, I'm able to boot into rev3.2 DOS/65 and get the A0> prompt. I can change drive and user, I can SAVE nn filename (it responded with NO SPACE) and I can GO $xxxx, DIR command will give me gibberish which is expected. So I'm reasonably comfortable that rev3.2 CCM/PEM are working even with old SIM. Now I need help tackling new SIM. I need to understand what drv_offset and part_offset are and how to manipulate it in the CF read and write routines. I've read your v3.20 release note but I'm hoping for a little more description. Thanks,
Bill

Hi Bill,

So, the new SIM must be used with the new PEM. One key difference is that the track/sector translations between PEM and SIM have been removed. All calls between the two are now record based. So it's no surprise that the old SIM module will not work with the PEM module.

I think the simplest approach would be to replace the calls in the new SIM module for console and disk I/O with the routines you have for accessing them with your hardware. The SIM console calls should be trivial to change over to your hardware. I think the calls to read and write a block to the compact flash should also be fairly easy to change. Beyond that, the SIM module should work fine and note that it does the blocking/deblocking and delayed block writes as well, which improves performance.

On another note, you don't need to provide any format program with DOS/65. For any new drive letter, you can enter "era d:*.*" and the directory will be cleaned up and you can then use the drive.

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

Ah, thanks for the tip about ERA *.*. It works even with my rev3.0 SIM.

I have a monitor command to read CF by LBA number so ERA *.* followed by SAVE nn filename is a powerful way to sneak up on new SIM read/write routines.
Bill

Bill,

I forgot to clarify the part_offset and drv_offset bits in the new SIM module.

The drv_offset is the starting LBA of each drive letter. In your SIM code, you use the reserved tracks field in the DCB which defines the starting LBA for that particular drive. I found this a bit odd at first, as this technique sorta breaks the concept of reserved tracks, as as you go to the next drive letter, there are more reserved tracks than the actual size of the disk. Needless to say, your technique works, but is limited to a 16-bit field for the offset to the next drive letter.

Richard Leary's SIM code that I initially looked at used an offset which was selected by the drive number (0-7) and that offset was added to the track/sector count that PEM requested. Since I changed the PEM and SIM code to work with record numbers, there's still a drive number that is selected by PEM as well, so the access via SIM is specified by a 16-bit record number (a record is still 128-bytes) and a 4-bit drive number (0-7). In the SIM code, the get_lba routine will take the requested drive number (sim_seldrv) and use this multiplied by 4, as an index into the drv_offset table, which are 32-bit offsets. The values in that table are the first LBA of that drive number, which is added to the calculated LBA from the record number.

Next, there is a 32-bit field called part_offset. As DOS/65 can only access up to 8 drives, with each drive size limited to 8MB, that's only 64MB of addressable space on the drive. The part_offset (which is a partition offset) allows the set of drives to be allocated to an offset from LBA 0. This allows a larger drive to be broken into more than one OS, or I can actually have multiple copies and/or versions of DOS/65 on one drive, provided the overall drive size is large enough. During a SIM cold start, the 32-bit part_offset value is added to the drv_offset table to each 32-bit drive offset. This is only done once... then the part_offset values are zeroed, so it can't happen again is SIM is cold-started again. This simply makes the disk access quicker, as the drv_offset values now point to the starting LBA of each drive physically on the disk. This allows for more flexibility in using the drive.

Hope this helps and makes sense. Lemme know if you get Version 3.20 running on your CRC65...

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

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

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