Commander X16

I recently posted a rant on Facebook (and then immediately deleted it) about how 6502 system designers love to fragment memory maps.



Basically Zero Page and System Stack are untouchable. Put I/O in Page 2 and BIOS scratch RAM in Page 3. Start VRAM at $0400 as it's usually a known quantity. Start of usable RAM at the top of that. If video is I/O based, map I/O into Page 2, and start usable RAM at $0400.  The BIOS/OS lives in RAM/ROM from $FFFF downward. Everything in the middle is contiguous RAM. Use big banks (16K or 32K) if you have banked memory.



Hodge Podge memory maps plague many 6502 systems and I don't know why....

On 10/17/2022 at 8:39 PM, BruceMcF said:

But there doesn't have to be a contention between having the BDOS and CCP in High RAM and applications using High RAM...

The problem isn't that there's contention, the problem is that the programs have no idea that multiple memory regions might be a thing. The whole system's designed along single slabs of contiguous memory and there's no way to tell the program that there's a piece in the middle that they can't use.

As I have to track the start end end of allocated memory and zero page anyway in order to know where to load relocatable programs, the simplest solution to this was to allow the system to track multiple such areas. The user program always loads into region 0 (on the X16, low memory) and the BDOS and CCP into region 1 (on the X16, high memory). On systems with contiguous memory, both region IDs point at the same area. The BIOS can, of course, put itself whereever it likes but on systems with two regions the idea is that goes into region 1. This gets the most effective use out of most real-world 6502 machines which I've seen. I've made the deliberate decision to ignore banking because it's just too hard to come up with a common ABI which uses it which works across multiple machines.

On 10/17/2022 at 4:18 PM, hjalfi said:

The problem isn't that there's contention, the problem is that the programs have no idea that multiple memory regions might be a thing. The whole system's designed along single slabs of contiguous memory and there's no way to tell the program that there's a piece in the middle that they can't use.

Yes, for me, that is the compelling reason for using as much of Low RAM as possible for TPA in the CX16, since it seems like $0400-$9xxx (somewhere, maybe $9Exx) is as big a CP/M TPA as can be made available ... perhaps 38.5K TPA.

Quote

As I have to track the start end end of allocated memory and zero page anyway in order to know where to load relocatable programs, the simplest solution to this was to allow the system to track multiple such areas. The user program always loads into region 0 (on the X16, low memory) and the BDOS and CCP into region 1 (on the X16, high memory). On systems with contiguous memory, both region IDs point at the same area. The BIOS can, of course, put itself whereever it likes but on systems with two regions the idea is that goes into region 1. This gets the most effective use out of most real-world 6502 machines which I've seen. I've made the deliberate decision to ignore banking because it's just too hard to come up with a common ABI which uses it which works across multiple machines.

To me, the most compelling use of HighRAM for a CPM/65 is a RAMdisk.

On 10/17/2022 at 11:39 AM, BruceMcF said:

But there doesn't have to be a contention between having the BDOS and CCP in High RAM and applications using High RAM. CP/M 2.2 programs that don't use the CCP functions are free to overwrite them, since the CCP is typically reloaded on exit, and those that don't use the BDOS functions are free to overwrite those as well and have the BDOS reloaded when they exit. It's even easier to do either of those if BDOS and CCP are in a HighRAM segment, since the warm start is just bringing those back into the memory map and calling the correct routine there.



If the CP/M function call is at a vectored location, you could even swap between a direct call when the BDOS/CCP is in HighRAM and the X16 Kernal is in ROM, and a long call when the correct window need to be set-up for a call, so that when you are NOT using the freedom to use HIghRAM, you don't have the extra overhead on CP/M function calls. That would make the LowRAM stub the direct function call, the long function call, and optionally the LowRAM support for using all or part of HighRAM as a RAMdisk.

Something to consider is that Monarch will not actually use the KERNAL. So the BDOS and BIOS will actually be in ROM and there is no overwriting of those. After loading the BIOS, BDOS, CCP, and FAT32 drivers, any ROM banks left over can be used for a ROM disk, with essential operating system files. 

When I said "operating system", I was really thinking more about a BASIC interpreter: the interpreter would sit in low RAM, and the tokenized program would live in banked memory. 

 

 

On 10/17/2022 at 8:44 PM, BruceMcF said:

To me, the most compelling use of HighRAM for a CPM/65 is a RAMdisk.

Noooo.... data, data, data.

Writing an adventure game? You can pack an entire Z-Machine style game in 512K or 2MB. 

Writing a platform game? All of the level data can go in 512K. 

With SD cards being as fast as they are, there's not much use case for a RAM disk on the Commander X16. 

The overhead in the CX16's SD card is all tied up in FAT32, not so much in the physical access itself. Turning high RAM into a RAM disk has the same kind of overhead, unless you invent a new filesystem for that... which is a major undertaking with very little reward.

I'd prefer to just see the entire set of banked memory be completely untouched by the operating system. Leave 100% of it for applications to use as they wish. One of the complaints I have on the Commander X16 OS is the use of bank 0 for KERNAL and BASIC variables. That is going to cause all kinds of complications down the road.

 

On 10/18/2022 at 9:53 PM, TomXP411 said:

I'd prefer to just see the entire set of banked memory be completely untouched by the operating system. Leave 100% of it for applications to use as they wish. One of the complaints I have on the Commander X16 OS is the use of bank 0 for KERNAL and BASIC variables. That is going to cause all kinds of complications down the road.

I could, but I'd have to specify some kind of cross-platform API for accessing it, and the result would look very much like a file system. So I might as well just put a file system on it! (The CP/M file system is actually amazingly cheap.)

It's a little more complicated on the X16 because I've chosen to put the BIOS in high memory. So if I were to do that I'd probably want to move it to low memory. The entire BIOS, containing all the platform-specific code and required storage, is under 0x300 bytes so it wouldn't cost much, but it'd be nice to avoid if possible. Unfortunately the only other option is to put some trampoline code down low which can copy in and out of high memory while the BIOS bank is swapped out, and it'd need a 128-byte buffer.

On 10/18/2022 at 3:53 PM, TomXP411 said:

Noooo.... data, data, data.



Writing an adventure game? You can pack an entire Z-Machine style game in 512K or 2MB. 



Writing a platform game? All of the level data can go in 512K. 



With SD cards being as fast as they are, there's not much use case for a RAM disk on the Commander X16.

A file is where a CPM/65 program would normally store its data. You gave two use cased for a CPM/65 RAMdisk and then said it had no use cases.

Tom makes sense when he talks about going through the steps of calling a BDOS function instead of just switching banks. But as hjalfi also rightfully points out, there's no good mechanism for dealing with discontiguous RAM, nor for banked RAM even if it were contiguous.

And Bruce's idea of using the banked RAM as a block device is one that many CP/M-80 systems with more than 64K of installed RAM have used before.

 

On 10/18/2022 at 8:11 PM, kelli217 said:

Tom makes sense when he talks about going through the steps of calling a BDOS function instead of just switching banks. But as hjalfi also rightfully points out, there's no good mechanism for dealing with discontiguous RAM, nor for banked RAM even if it were contiguous.



And Bruce's idea of using the banked RAM as a block device is one that many CP/M-80 systems with more than 64K of installed RAM have used before.

I'm just thinking that the point of a CPM/65 program would be that it runs on any CPM/65 system with a large enough TPA. If it is using the X16 banks natively, it may as well be a native X16 program ... and if programmed in a higher level language, can be compiled for any CPM/65 or CPM2.2 system with a large enough TPA.