CRC65 only has 64 bytes of ROM located inside CPLD, just enough to either serially load program via a simple serial port in the CPLD or bootstrap from CF disk, so there are no ROM-based BIOS to be called by SIM. Yes, I do have a monitor loadable into memory from CF and I suppose the various monitor routines can be called by SIM. However, only very few monitor routines are reused by DOS/65, so it is simpler and easier and smaller code to just integrate the few routines into SIM.

For debugging purpose I do load the monitor into RAM just below DOS/65 but that monitor is not needed to boot DOS/65. At reset CRC65 loads CCM/PEM/SIM (CP/M equivalent of CCP/BDOS/BIOS) into RAM and jumps into SIM's cold boot routine to start DOS/65. So I don't need the overhead of a monitor just to reuse a few of its routines for SIM.
Bill

Hi Bill,

I've been looking more closely at your code, the SIM module specifically. There's a few things here that might be the cause, coupled with whatever your coldstart process for the CRC65.

One of the things that was part of the SYSGEN was to zero out the page zero space before creating the new image. Note that the "switch" routine in PEM swaps some key bytes between the page zero locations and it's own internal variables. There's a good chance that this is causing the problem with an invalid drive from the alloc program. If the page zero space is not cleared, there could be an invalid value there which gets swapped in.

Note that on my systems coldstart process, I clear ALL of page zero before initializing any of the hardware. I also clear the unallocated page zero space from a warm boot in SIM. This ensures you don't have some garbage out there which can cause some odd issues.

Based on the above, I would suggest (as a test) that you clear out page zero on a SIM cold start and then clear out the rest of page zero that's NOT used by your hardware and DOS/65 for a warm start. This might clear up some issues.

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

The alloc problem is because of page zero usage, but not because ZP not initialized in SIM cold boot. The ALLOC208.ASM has a variable "pzstrt" that was originally set to $2 so its zero page variables starts from $2 and I believe it is conflicting with DOS/65 ZP usage. To test that theory, I did not change my DOS/65 but changed ALLOC208.ASM so pzstrt is set to $10. Now ALLOC is working correctly. The lesson-learned is ZP usage of DOS/65 utility programs must not conflict with ZP usage of DOS/65.

Thanks for taking the time to look over my SIM code. It is a good idea to clear ZP variables used by DOS/65. I'll update my SIM accordingly.

Bill

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

okwatts,
The reason for warm boot reverting to drive A is because I write 0x0 to iostat in my warm boot routine. That was a leftover from troubleshooting a problem and I forgot to remove it. Search for the word ";diagnostic" and you'll find 5 consecutive instructions in wboot routine. These instructions can (should be) be removed.

I, too, find BASIC unable to load file--it hangs just as you've said. This is different than rev 3.0 DOS/65. It appears able to save file with the command, SAVE "FILENAME.BAS". I'll check into possible zero page conflict.

Attached is DBASIC (EhBASIC) with TEA changed to 0x400. Instruction for installing it in DOS/65:
1. At DOS/65 prompt, type "go $b400" to run CRC65 monitor.
2. In CRC65 monitor environment, send DBASIC.HEX to CRC65
3. At CRC Monitor prompt, type "gdc00" to boot DOS/65
4. At DOS/65 prompt, type "save 44 dbasic.com" to install DBASIC.

In DBASIC you can load FILENAME.BAS with "LOAD A:FILENAME" and you can save FILENAME.BAS with "SAVE A:FILENAME". FILENAME.BAS is a binary file, not human readable.
Bill

Yes, a page zero overlap will certainly mess things up. I didn't specifically look at the alloc program source. For my systems, I allocate page zero space from the top ($FF) to the bottom ($00). My current system allocates the top 48 bytes for BIOS use, followed by the next 48 bytes for Monitor use. Right below that is DOS/65. As a result, page zero space from $00 - $97 is free for applications. Note the Basic Compiler, Run time and Assembler use a fair amount of page zero space.

I have noticed that most of the 2.1 utilities source code started their page zero use at $02. The logical conclusion for that was due to the MOS6510 CPU having a built-in port at the bottom of zero page.

Anyway, glad you found that and hopefully version 3.20 is working better.

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