floobydust,
I was puzzled why the rev3.0 SIM works up to a point with rev3.2 CCM and PEM. As I dug more into your "get_lba" I realized I've defined the disk parameter block of rev3.0 DOS/65 such that it is actually compatible with your record-based PEM! It is purely accidental that I defined a track to contain 1024 sectors (sector=128 bytes) so my 16-bit "sector" variable is same as your record (pemrec,pemrec+1) variable. The net result is my rev3.0 SIM only need one instruction change replacing "track" variable with "sector+1" variable and it all works!

Well, I'm walking back the above statement that only drive A works with the one-instruction-modified rev3.0 SIM. Since the rev3.2 disk parameter block no longer have the reserve track entry, for disk B,C,D,etc I do need to look at drive # and offset the LBA for different drives accordingly.

It occurs to me while writing that I probably can come up with a SIM that's compatible with both rev3.0 DOS/65 as well as rev3.2 DOS/65.
Bill

OK, it looks like I have a working rev3.2 ported to CRC65. I'm able to run a TeraTerm macro script file that starts off with a blank CF disk, load DOS/65 rev3.2 into system track, load xmodem which then uploaded all sources of rev3.0 utilities then I use ASM to assemble all sources into executables and BASIC compiler to compile *.bas programs into executables. When it is all done DOS/65 rev3.2 will auto-boot at power up and these are files in drive A:



Everything works EXCEPT FLST.BAS does not work. When I run the compiled FLST.INT I got this:


It is a complicated BASIC program that delves into innards of DOS/65. I suspect rev3.2 is different enough to blow it up. Super directory, SD.COM, does work so I believe rev3.2 is compatible with rev3.0 at BIOS calls level.

My TEA is at $400. The SIM is crude right now and need polishing and better documentation, I'll publish it in CRC65 homepage in a few days.

Great job, Kevin!

Bill

Bill, First... thanks for taking the time to get version 3.20 working on your CRC65, and thanks for the kudos on the code itself. I also did not have the Basic program FLST working... it's an odd one. I did slightly change the Basic SYST program which works fine... go figure.

A few things to note regarding the 3.20 version code:

- The calls "to" PEM are still the same (as the standard 3.0 version code), no functional difference in what they do.
- The calls "from" PEM (to SIM) are different for some of them.
- The new SIM code was specifically written to interface to the new PEM code.

The key differences are in the following SIM routines:

- Set Home: - this is a dummy call in the new SIM code. There's no reason to home the drive of any IDE block device for any reason.
- Set Reserved Tracks: - this is a dummy call in the new SIM code. The original PEM code (routine sttrsc) would add reserved tracks before setting the track number for a read or write.
- Set Record Number: - this was set sectors in the original SIM code. This is a modified routine to set a 16-bit record number for reading or writing by SIM.

Based on the above, there will never be a call from the 3.20 version PEM to the Set Home or Set Reserved Tracks calls. Also note that the Disk Control Block (DCB) has been slightly modified as:

sample for drive A: on my system:

; .DW 4079 ;max block number (this is the same as before)
; .DW 4 ;records per physical block (LBA) - THIS IS DIFFERENT. There are 4- 128-byte records to a single 512-byte block on the IDE device!
; .DW 256 ;number of reserved records (OS Boot area) - THIS IS DIFFERENT. This accurately determines how many Records are reserved. Note that this value MUST be a multiple of the above value (which is 4).
; .DB 1 ;block size = 2048 (this is the same as before)
; .DW 1023 ;max directory (this is the same as before)
; .DW almpa ;address of allocation map (this is the same as before)

The last two entries were for checksum on diskettes to sense if a diskette had been swapped out by the user. These have been removed, saving 3 bytes per drive DCB.

The new PEM only copies the new DCB count of 11 bytes over and operates based on those new values. As the new PEM checks for Reserved Records, it will add that to the requested Record number before calling SIM. This requires that SIM use the requested drive number and add the offset to the requested Record number from PEM.

Not sure if your new SIM version is doing all of the same things my 3.20 version is, but I would recommend using it (new 3.20 SIM) and just replacing the BIOS and Monitor calls with yours. That should work without any issues as the BIOS calls used are quite simple. Looking forward to seeing a final version... as I also have one of your CRC65 boards!

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

Kevin,
My "new" SIM for rev3.2 is actually a minor tweak of rev3.0 SIM. Only change is in the way new 'record' is translated to LBA for read/write drive A/B/C/D. So unlike your SIM, mine still does not do delay write back (same as my rev3.0 SIM) so it is less efficient. CRC65 rev3.2 CCM/PEM/SIM is attached.

Beside flst.int not working, alloc.com also not working, it complains about drive H: which I don't have.



Also attached is TeraTerm macro script for installing DOS/65 r3.2 in CRC65 starting with a blank CF disk (assuming you use TeraTerm terminal emulator). It takes about 10 minutes to upload and assemble everything. These files need to be installed in c:teraterm/dos65tea400 directory. The macro file is newDOS65CF_v32fast.ttl. It is kinda fun to watch it runs, but the faster/better way is to copy the CF image using tool like Win32DiskImager.
Bill

Hi Bill,

Not sure on Alloc.com not working, I use it quite a bit without issue. Have you tried the SYST.BAS program? I made some minor changes to the text messages so it shows reserved records, etc.



Note that PEM doesn't actually use the second parameter in the DCB (records per physical block), but it does check for reserved records and adds those in if present. I've only taken a quick scan thru your SIM code... but there might be something in your DCB or how you add in the drive number to offset the record number, which is actually the LBA number once you do the 16-bit rotate. You're offsetting it by 16384 blocks, or 8MB of space on the CF card. Note that your DCB shows system tracks for all of the drives. PEM now considers that parameter as reserved records and adds that to the record number before calling SIM. This might be causing a problem.... hard to say.

Here's a few screen shots from my system:

ALLOC against the B: drive:




SD against the B: drive:



Note that I run OSX and use a native terminal app called Serial:

https://www.decisivetactics.com/products/serial/

It supports just about everything including Xmodem with drag 'n drop as well. If you have a disk image file, I can move that to a CF card using Balena Etcher, which is how I got your initial V3 code running.

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

I did compile the original SYST.BAS without modification and it displays:


If I type "alloc a", it does display the allocation map correctly like this:


However, rev3.0 of DOS/65 would display allocation map of current drive if I just type "alloc", but that doesn't work with rev3.2. This is where I had the problem with alloc command.

Attached is the image of DOS65 rev3.2 on a 64MB CF disk.
Bill

Edit: Just noticed at the end of the "alloc a" display is the message "UNKNOWN DRIVE". Hmmm...

Hi Bill,

I loaded the image and booted it, and find the same problem you're having.

I've spent some time scanning thru your code.... some things that might cause some issues. First, the invalid drive message is being created by PEM. This is due to a drive range check, which really wasn't done initially. There's a parameter "maxdrv" which I have set to default of 8 drives, as that's how many I use. As you're only using 4 drives, that might cause some issues, as you still have it set to 8 drives and you only have 4 drives configure in SIM. Second, in your SIM version, the select disk routine (seldsk) does a compare for 4, if greater, then you don't actually the save the drive number to the diskno variable, so it might be random, or incorrect. The new PEM also validates the drive number range before calling SIM, so SIM does not need to validate the drive range.

My SIM routine is below:



Your SIM routine is below:



With your routine above, you don't need to do the cmp #4 and branch to invdsk. Using a zero value in the dcbtbl resolves this, and also saves the drive number in the variable.

Also, one of the things I do during a warm boot is to clear out the Page Zero space for applications, i.e., any of the Page Zero locations that aren't used by DOS/65 or the machine's BIOS/Monitor routines.

I'll be out of town for most of this week, but if I can get some free time, I'll look to create a BIOS module based on your hardware I/O routines in your SIM module. Breaking these out separate with equivalent calls to my ROM based BIOS and then using my supplied SIM module should provide the same SIM functions and have the performance benefit of delayed block writes as well.

Perhaps if you make some of the changes noted above, that might help resolve the problem.

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

Hi Bill and floobydust I have downloaded and tried this version of Bill's on the CRC65. Without having any real answers I have a few observations.
1) when programs end with a warm boot the system always reverts to drive A even if you have been working on another drive. I presume this is somehow related to what floobydust mentioned about the default drive parameter in his new PEM.
2) Basic (Microsoft version) can save programs but if you try and load them the system hangs. Not sure what has changed from version 3.
3) I haven't tried to recompile DBASIC (ehbasic) for the new TEA so I can't comment on save and load on that.

I have appreciated your efforts in pursuing development on DOS/65 (and the 6502 in general) as it makes this retro hobby more fun and useful(?). Sadly I think the 40 years that have passed mean it is unlikely we would see a Wordstar or Supercalc equivalent for DOS/65 but at least working with files using an editor like sedit is possible for those who want to work on and do some development in a completely retro environment.
Watching further developments with interest!

There was an issue in the standard PEM code around drive selection. If you attempted to select a drive that did not exist, it would loop on an invalid drive error. I changed PEM to default to the A: drive if that happened. However, just as long as you don't attempt selecting an invalid drive, a warm boot should not reset the drive letter. PEM doesn't actually change the drive letter as part of a warm boot, it calls SIM, which should preserve the drive letter and user number and pass that over to CCM for finishing the warm start. I also added code to do drive range detection with CCM and PEM. The problem here was you could enter any character (alpha or not) as part of DIR (x): and you could get a listing, as the code was simply masking off the lower 3 bits and throwing it over to PEM (which also the same thing). An erase command to a bogus drive could easily erase files on one of your drives.

Load/Save from Basic. I've used the DOS/65 Basic compiler and runtime, but only at a simple level. However, the PEM calls for open/close files, read/write to files are still the same and should function without issue. I created a submit file that creates all of the 2.1 utilities, which exercises PEM quite heavily, as it's a sequence using multiple programs (SD, ASM, MAKECOM, SUBMIT, etc.) and it also exercises CCM quite a bit too.

I'm not sure I have the source code for either of the Basic versions you're using... as the only one I've tested with is the compiler and run time components that were part of DOS/65 2.1. I've not found any problems assembling and running any of these programs on (DOS/65) version 3.20.

The system I've used to develop and test the new DOS/65 version on is quite different from Plasmo's CRC65. I have a BIOS ROM which contains a core set of function calls for all the hardware (which is all interrupt-driven data transfers) that SIM uses via a JSR/JMP to a jump table. Bill has his hardware routines integrated into his SIM code. Still, I think using my SIM module and creating a set of BIOS routines for accessing the serial port and compact flash card might resolve these issues. I'm just swamped on personal stuff this week and next before I can look at doing anything along those lines.

Not sure if this helps....

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

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

I agree with this.


You appear to be confused about what was and was not part of CP/M.

Digital Research supplied the BDOS, which was the part of the OS itself and always remained in memory, and the utility programs, among which was included the CCP (command processor) which ran like any other program in the TPA (transient program area, from the base of memory up to the start of the BDOS).

While DR did supply a BIOS for the Intel MDS-800 system, vendors of other machines were expected to write and provide their own BIOS, and there was a clearly delimited interface between the BDOS and utility programs and the BIOS. The distinction between BDOS and BIOS was made very clear in the manual, which stated, "only the BIOS is dependent upon the particular hardware."

The BIOS was usually written to a system-specific boot disk along with the BDOS, which itself would be relocated (using GETSYS and PUTSYS, as described in the manual above) to place the BIOS+BDOS at the top of memory for however much memory the particular system had. But it was perfectly possible (and I am pretty sure, done by some systems) to have some ROM at the top of the address space containing the BIOS, though there's really not a lot of point except in particularly cost-sensitive early systems with less than 64K of RAM where ROM was significantly cheaper than adding the same amount of RAM.

The issues you're talking about are something completely different and related to the way CP/M and the Z80 processor works. On reset the Z80 starts executing instructions at $0000, which means that there must be ROM at the bottom of the address space. However, CP/M requires RAM at the bottom of the address space (the TPA starts at $100, and CP/M housekeeping information is below that) which is why you could have only the boot loader in ROM there; it had to be paged out after loading CP/M. So if you wanted your BIOS in ROM as well, it couldn't go in that ROM, but needed to go in a different ROM mapped to upper address space.

(Well, actually, I suppose you could perform some tricks to have the same ROM mapped into both areas of the address space, and unmap it from just the lower part of the address space, but you're still losing memory by keeping the initial loader mapped in if you do that. Again, except in _very_ cost-constrained systems, you're better off just replacing the proposed upper ROM with RAM and loading the BIOS from the boot disk.)

_________________
Curt J. Sampson - github.com/0cjs

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

Well, in that case the separate "BIOS" you're proposing for DOS/65 will be just as integral to DOS/65, since DOS/65 will not be able to run without it.

Regardless, CP/M did have the exact split between machine-independent code and machine-dependent code that you are proposing for DOS/65: that was a key feature of its design, and a major part of the reason for its popularity.

_________________
Curt J. Sampson - github.com/0cjs

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

I don't actually see the difference here. If the SIM is a firm interface, how would the PEM know if the SIM is calling a "BIOS" or the SIM itself is doing all the work? The PEM should neither know nor care.


Right, but that was a) running only on _much_ more expensive hardware, and b) hidden deep inside Bell Labs, for the most part.


Indeed. Though it looks to me as if MS did quite well out of their BASIC, too. The "every computer must have BASIC in ROM" thing in the late '70s and early '80s got them quite a bit of business (and in at least some cases, royalties). Even here in Japan, pretty much everybody either started out with or switched to MS-BASIC.

_________________
Curt J. Sampson - github.com/0cjs