Welcome to cpm65 Discussions!

[davidgiven]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[mscha5678]

Hello, I'm a retired professor of Business IS and started playing around with retro computers.
Right now, I'm using a Neo6502 with Morpheus v1.0.0 on Windows 11. I would like to boot directly into the Morpheus shell without NeoBasic auto-launching. Could someone provide a prebuilt firmware (.uf2) that achieves this?
I looking for this to enable loading Davis Given's CPM65 to the NEO.

[erlendnagel]

I am wondering about the driver concept in CP/M 65. Right now there are three driver types (tty, serial and screen) and I don't understand yet how the drivers are added to CP/M 65 and how they then become available to CP/M (BDOS)?

The devices.asm , kbdtest.asm and vt52drv examples help, but does it mean that driver can be loaded on demand? E.g. if I were to assemble and run vt52drv , would it add that screen driver, or would I need to assemble it and include it in the bios or bootprom? And can there be multiple drivers of the same type? The examples just look for one with a matching driver type, but if I wanted to create a terminal program that can support multiple serial ports, how would that work?

I am planning to eventually run CP/M 65 on an MECB 6502 device (https://digicoolthings.com/minimalist-europe-card-bus-mecb-mos-6502-or-wdc-w65c02-cpu-card/ ) which will have at least a mc6850 and an mc6840, so one obvious addition I would want to make is to add a driver type "timer" (with a get and set function for each timer, similar to what Dietmar L has in his CP/M 65)

[davidgiven]

Hello---

Drivers can be dynamically loaded or baked into the BIOS. If you run devices.com, you'll see the currently active drivers. Typically a port will have a TTY and SCREEN driver in the BIOS, and possibly some loaded at runtime; currently the only runtime drivers are ones which will either emulate a VT52, ADM3a etc terminal on top of the BIOS SCREEN driver, or provide a BIOS SCREEN driver on top of a VT52, ADM3a etc (for running CP/M-65 over a serial terminal).

I am actually currently planning on driver-fying the disk system, so block devices can be loaded at run time. This is primarily for the Commodore ports, which want to be able to use RAM expansions as a ramdrive, but they're uncommon enough not to warrant baking into the BIOS.

A timer/clock device is also planned but hasn't happened yet. I was trying to figure out how the timer could notify the application that something had happened without needing a callback (as if the application exits without deregistering the callback, bad things will happen)...

[erlendnagel]

Ah, I forgot to introduce myself. I love playing with old computer technology. I own several old computers as well as an Agon and a neo6502pc and have built several rc2014 modules and now as I mentioned I am building MECB modules.

As for timers I had a look at how Dietrich L. handles it in his CPM65, and it appears he does not use notifications, but rather lets a user start a timer and then poll it.

driver-fying the disk system could also be interesting for those that use devices with a FAT filesystem, so the driver could do the de-blocking transparently.