Recent content by JohnElliott

I've been playing with the V6355D (a CGA-compatible chipset) for a while now, and created a GEM driver for it that uses the hardware pointer support. It also supports the palette registers, but these only apply when output is to a composite monitor, so I haven't been able to test that area of...

The CP/M 3 assumption is that memory above a certain address is common to all banks, and bank switching changes memory below that address. On any given system, the address in question is held at offset 5Dh in the SCB.

cpmfuse appears to allow CP/M drives to be mounted on Linux. It then might be possible to use winfuse to make cpmfuse work under Windows (I haven't tried, so no idea if it would work). If you wanted to access CP/M filesystems inside container files like DSK images you'd need at the least to...

What CP/M Plus doesn't guarantee you is the number of banks (0 is for the BIOS, 1 is for the TPA, anything beyond that is system dependent). It also doesn't guarantee anything about what lives where in banks other than the TPA. On the Spectrum +3, for instance, there are three banks but banks 0...

LocoScript copies just about anything it finds off the boot floppy and into the ramdisk. And when it's done, if there was a file on the floppy called ET.AL, it prompts the user to remove the boot floppy and insert another, and keeps going.

In the case of the PCW, its main use was for word processing and (to a lesser extent) desktop publishing. So the use of adding extra memory was to increase ramdisk size for more data files: fonts, spell checking dictionaries, document templates, clipart and so forth. There was enough of a demand...

Here's a scenario where you wouldn't just dd a disk image to a drive: You've got a disk image of a 320k ( 40 cylinders, 2 heads, 8 sectors/track) FAT12 floppy and you want to write it to a 3.5" disk, using a USB drive that supports 720k media. You'd need to write 512 dummy bytes after every 8...

If you want to try bringing up something more recent than CP/M-68K, there's also source for GEMDOS out there.

You should just be able to use the stock BNKBDOS / RESBDOS SPR files distributed by DRI.

It sounds as if you're having to rebuild the BDOS so the resbdos$pg ends up as the address the BDOS will actually be loaded at, rather than with the magic values that get altered by GENCPM. In which case the difference in resbdos$pg will be the difference between the load addresses of the banked...

There were Z80 replacement BDOSes such as DOS+ which managed to squeeze extra functionality like date stamps into the same space occupied by CP/M 2, so going to Z80 does give some advantages.

You won't save much space by removing a few ANI 7Fh instructions, if they are present; and removing the paper tape punch/reader support from the BDOS only nets you another handful of bytes. As for usefulness, those hobbyists currently using CP/M presumably find it useful enough at the moment...

I think one possible future would have had the cursor control operations from GSX integrated into the BDOS, so you'd use function 73h to get the screen size, move the cursor around, change attributes etc. That would of course have needed BIOS support, but DRI were in charge of the BIOS spec and...

When you're saying things like there's "no valid reason" to keep CP/M the way it is, it's easy to read that as a request -- even a demand -- that people should rewrite CP/M to be the way you want it to be.

I'm open to correction on this point, but to the best of my knowledge and belief everyone here who works with CP/M is an unpaid volunteer, scratching a personal itch. If you think CP/M implementations would benefit from a standard 8-bit CP437 character set, a standard VT100 terminal emulation...