6502.org

Yes, I noticed that some time ago... and posted it recently here:

viewtopic.php?f=2&t=7337#p95951

If you're interested in porting V3, I can probably save you some time

I've been working on a RAM based Version using my 3.04 as a base. I decided to call it version 3.10. The only things you'll need to change are some SIM bits for the CRC65, or use your own. There's a main file and the the 3 modules as separate files: CCM, PEM, SIM. Note that it's not in a sysgen file. This version also uses CMOS instructions and addressing modes, so be sure those are enabled for your assembler.

I've been running it for a bit...configured for 8 drives at 8MB each. As I'm also working on a partition record and the ability to have multiple bootable partitions, there is a 16-byte load header at the start of the code. You can drop that if you don't need it. Other than that, there's a couple include files for routines and pointers for my BIOS/Monitor that DOS/65 uses, but those can easily be replaced for the CRC65.

Total space for the Boot Image is 10KB, which includes the 4KB for the drive allocation maps. You just jump to SIM to make it go. Have fun!

DOS65 and DOS/65 are two different operating systems!

DOS65 is an OS developed by the Dutch 6502 Users Club, based upon Elektor boards (CPU 6502, RAM boards, 6845 video display baord). and their own floppy disk controller.
Not CP/M compatible, but quite a complete OS with programming languages and editors. Hardware and DOS65 are not well separated.
I have owned several DOS65 systems, dumped the floppies, they are now in the hands of other Dutch collectors.
Read all about it, sources (some only in scanned format), binaries and documents.

DOS/65 is Richard's OS. I have tried to collect (and keep updating!) as much as I could find online and get from Richard, published with his permission., just to archive it before it gets lost.
Richard does not really care anymore about the copyright, he is not capable of doing more work on DOS/65, any further development work on it is OK.

All on http://retro.hansotten.nl

Hans,
Thank you for collecting various DOS/65 developments into one place. Please feel free to include what little work I have done in your web page. Another source of DOS/65 works is Dan Werner's (author of SEDIT) github page under nhyodyne, https://github.com/lynchaj/nhyodyne/tre ... PROC/DOS65 He has ported EhBASIC to DOS/65 and an intriguing idea of having Z80 and 6502 coexist on the same hardware platform sharing the same CF disk and a mechanism of switching between Z80 and 6502.

I believe opening up DOS/65 as freeware will encourage more development with it.
Bill

Amen to that.

Further ways to encourage development:

* Provide some sample programs.

* Make binaries available; do not make everybody rebuild everything from source especially if unique tool sets are required.

* Provide a bootable "disk" so that potential users can try it without a big commitment via emulation.

* Did I say sample programs?

Thanks for the V3 software. As I read through Richard Leary's V3 documentation I realized all the changes are in CCM and PEM; there are no changes needed for SIM. So I extracted CCM and PEM from Leary's SYSGN302.ASM and appended my SIM for DOS/65 V2 and it all just worked!

Cool!
Bill

Well, I'm among the first to agree that having Rich open up his license for DOS/65 is a real positive for the 6502 community in general. I've been working with the V3 code he sent me over a year ago and have made some good strides with it. I've also got plans on enhancing it further over time. But to comment on BillG's post, I'd also say that I'm playing "devil's advocate" as well.... so here goes:

Sample Applications: - This shouldn't be too difficult. There's already a fair amount of stuff out there. One can also take the approach of porting various CP/M applications over. It's a timing thing and someone putting in the effort.

Making Binaries: - This is where things can get a bit ugly. In short, everyone has their own view and implementation of a memory map and what those allocated sections are used for. This topic alone can span pages over a long period. More needed here!

Bootable Disk: - Once again, this gets problematic fast. Define a bootable disk... even try and forget about the physical media device (CF Card, IDE, SCSI, SD-Card, Floppy anyone?) for a minute. Some sort of de-facto BIOS interface needs to exist that isolates the hardware completely... yet, also defines the mapping of media to usable drives to the system.

Sample Programs: - Echo test.... Echo test... Echo test...

Not to toss water on it all, but in contrast, the first IBM PC did create a hardware architecture and software interface (BIOS) to make it accessible. Like it or hate it... it became a de-facto standard and off the world went down the rat-hole, or whatever you prefer to call it. This also indirectly made giants of Intel and Microsoft, nuff said.

From my view, I can only decide on how I design and build my own systems. With regard to CCM and PEM, these two modules are the core of DOS/65 and basically can be the same across any implementation. The only catch is where they are loaded in memory, as that requires the binary be configured for it. As for the SIM and it's tie-in to the hardware, there's options.... you can write a dedicated SIM and have it control the hardware directly (making it an integrated SIM+BIOS) or a standalone module that interfaces to a system's existing BIOS.

Booting the system... how does one create a somewhat universal bootable disk architecture when no two hobby-built 6502 systems are similar enough for attaching media? Whatever starts the system, there needs to be some common structure to accessing media (pre-OS) and figuring out what to load from where, turn control over to it, etc. If the goal is to provide a bootable disk or bootable media, some agreed to standard needs to exist, mostly for the format of the bootable media. I would most certainly say that all media should be accessed as a logical block device (LBA addressing) and completely eliminate any references to cylinder/head/sector access.

Granted, this is a much more complex subject to get ones arms around, but to make DOS/65 a standard 6502 OS is going to require some effort and more importantly, a lot of agreement from those who are interested in pursuing it.

On top of all of this, there's David Givens' recent CP/M-65 port. This also becomes a contender in the same space... and David has worked on addressing relocatable binaries, making that part easier. Still, there's the requirement for a BIOS that BDOS accesses and the concept of having bootable media being a similar problem. The same applies to having the available media formatted into a usable drive and the details around that, i.e., number of blocks, allocation size, directory entries, etc.

So to come full circle, I'm all for something that's reusable for the 6502. However, I don't consider this to be something you run on old retro NMOS sysems from the 80's. All of those systems have their software environments. All of my code is CMOS based only, which is a choice I made back in the 80's. I'm still working on a bootable setup... hoping to have something cobbled together for multiple bootable partitions within the next few days... depending on free time. In any case, all of my work on this is being shared, both here and also eventually gets loaded to my Github account.

Widespread adoption of DOS/65 was severely hampered by its license prohibition against "commercial use" while it was the only game in town for an operating system not tied to a particular platform.

"Thou shalt not distribute" definitely kept some people from bundling it with an emulator to run it.

No doubt Richard had hopes of making some money with it, but it was not clear whether the restriction was only on distribution. Suppose a company wanted to develop software, for sale, intended to run on DOS/65. Is that considered to be a prohibited "commercial use?"

Another problem was the lack of an obvious way to buy a legal copy.

Time will tell whether relicensing is too little, too late.

David did a wonderful thing coming up with a relocatable binary. The question is whether his story is one of "been there, done that" or will he continue to invest time to promote its use and adoption. Some of his prior videos covered the development of a native assembler for CPM-80; maybe he is busy at work doing the same for CPM-65?

He can obviously generate a virtual disk to boot with emulators for the BBC Micro and Commodore 64. But to get one requires downloading the source code and installing the needed tools to build it. Furthermore, someone wanting to write a BIOS for another platform with some other assembler currently cannot because the binaries for the BDOS and CCP are not aailable.

The benefit of a hobby endeavour (as opposed to a would-be business) is that you can just forge ahead, doing what you enjoy, without worrying too much about how many people are benefiting or how many people agree with your approach.

If you're flexible and amenable you can find yourself working with others, and have more fun, but if you feel you need to stick to some original thoughts, there's no penalty, just go ahead.

In a parallel universe nearby, there's a host of people writing software for the UXN virtual machine, and a spreadsheet has appeared... in fact I think the spreadsheet turned out to be easier than a Basic interpreter. Why are they doing it? Because it's fun.

Yea, this can be a tough topic... and depending on who you're talking to, what's important to one may not be important to another. As noted, much of the folks out here are doing this as a hobby and having fun doing so. But there's also a serious level of information, education, advice and sharing that makes it more interesting and generally enjoyable.

My interest in having a bootable disk system is possibly different from others. I've opted to stick with IDE going forward. Multiple reasons: I have lots of them... they are cheap and easily obtainable, published information for the interface is well documented and readily available. Performance is more than adequate for most, if not all, uses on an 8-bit platform. I've also got a solid working BIOS written and debugged as well.

The other side of the hobby bit is being able to do more with it. There are actually a few disk based filesystems now available, DOS/65, CP/M65 and even Fuzix is out there. Defining a bootable setup for my C02 Pocket SBCs makes it much easier for me to install and run multiple systems, without having to crater the disk and start over. I prefer having a multiboot environment, I can have multiple versions of DOS/65 installed on different partitions... and the basic design will provide flexibility on where the block of data assigned for drive use can be configured. Another idea of the multiboot system setup will be the ability to clone one partition to another, creating a backup or a new system to be upgraded for additional testing. I purposely defined the Partition record (patterned from the Ontrack Manager) to support 16 bootable partitions.

Having a 6GB drive on the system, I don't see me running out of space easily (famous last words), especially with a single OS environment. It would appear that 32MB is rumored to be about as large as you might be able to reasonably manage in an 8-bit/64KB memory footprint. My current DOS/65 environment is configured for 8 drives at 8MB each... a whopping 64MB of drive space, out of 6GB.

At least this is my $0.02 on moving forward with building a bootable drive system.