6502.org

Bill,

It was a bit of a shotgun process... installed all of the listed tools, then started finding the missing pieces to rebuild and install llvm-mos, then find and install the missing bits to get cpm65 to build.

I'm putting together a small parts list now (Mouser) and will make some modifications to my 3.3V prototype setup. That will extend the memory by putting in a larger SRAM and changing the config on the '22V10 PLD. Once that's done, I'll modify the BIOS to allow a boot profile from the Microdrive. I'll probably use a standard partition record format and then a custom boot block that will load a BIOS stub that acts as a layer between my existing BIOS and what BDOS requires. Once that's done, it's just a load of BDOS and CCP... hopefully

In any case, It will be a little while before I get to that point. I'll post progress of course.

Oh, I see! Well, the good news is that my build system is set up to generate listings automatically --- look in .obj/cc65/src. The bad news is that cc65 helpfully censors all the useful bits, so the end result looks like this:
Note that you don't have to rebuild these... the only bit you need to write to do a port is the BIOS. You can use the same BDOS and CCP binaries everywhere!

Yep I agree, CC65 is a complex package with configuration file, pseudo directives, control commands, and recursive macros to manage many software modules, so it can be quite difficult for a newbie to untangle all these interconnected software modules. A full listing is an important intermediate step for me because it includes all the software modules, flatten the includes, hierarchy and macros, and resolve all symbols into one file so it is easier to search and understand the whole program. I’m further hampered by having no knowledge of Linux nor llvm-mos and I’m not good at C, so I think following your exploration of CPM65 port to your pocket SBC is probably the best path for me.
Bill

Okay, so if that's the listing file, it's not going to be very useful... sad but true. When I look an instruction like "sta ccp_fcb + fcb::ex", it's not clear to me what the operand is, as I don't know the syntax using :: for example. A full listing file would be helpful in getting these bits worked out. Also, I can't find any such directory ".obj/cc65/src" in my Ubuntu system... so perhaps I'm still missing something for the build?

Just FYI, found the .obj directory... it's hidden by default. So, found the listing files as well.

The :: syntax is used by ca65 to denote structure fields/offsets. So with fcb::ex, there will be a structure named fcb defined somewhere that has a field ex. I'd guess it is the structure for a file control block. Likely ccp_fcp is the address of an instance of a file control block. I'd interpret that instruction as storing the accumulator into the ex field of a file control block located at ccp_fcp.

That is because the assembler is generating a relocatable object file to be fed to the linker. No way for it to know what the final physical addresses will be.

Way back when I did a lot of programming with M80, I wrote a program to take the link map and update the listing with physical addresses. At least M80 was kind enough to put the offset from the base address of the module into the listing instead of "rr" which is very unhelpful.

My understanding is that CP/M for the Z8000 as well as the later versions of CP/M-68K were written in C. The problem is that the result is probably too big to be acceptable in a 64K address space. The initial version of CP/M was written in PL/M, but it was rewritten in assembly language to get the size down.

I have given this some thought as well as watching the first of the videos.

I hope you are open to constructive criticism because I am about to give you some...

* You chose to dispense with the sector number translation table for dealing with sector interleaving on disk.

The only truly "standard" CP/M disk format is the 8" single-sided, single-density floppy disk with 128 bytes per sector. Sector interleaving is done via the number translation table instead of formatting them out of order. This was because some of the early systems were not able to format a diskette; those users were told to buy preformatted "IBM" media.

Without the translation table, you lose the ability to deal with virtual disk files in the "standard" format.

Try this: can you interchange files with CP/M-80 running on a C128 or a C64 cartridge? Or if there is a port to the Apple II in the future, with the CP/M Softcard? I do not know whether they are physically or logically interleaved, but why preclude the possibility?

* The 6809 is not compatible with the 6800 at the machine code level. The designers of FLEX for the 6809 made a sad mistake of reusing the .CMD file extension for executable files, condemning users with the likelihood of running programs on the "wrong" processor.

It is probably best to choose something other than .COM for CPM65 executables.

* To encourage new software for the system, it would be helpful to have written documentation about

- the memory map of the system.
- the BDOS calls and which registers are used.
- the BIOS calling convention.
- sample code not obscured by macros or assembler-specific directives for interfacing with the system. Not everyone is going to want or be able to use them.
- a hexadecimal dump of the binary of a small executable program to illustrate how the relocation tables work.

The reason for dispensing with the sector translation table is because that logic is more of a BIOS thing than a BDOS thing --- the BDOS shouldn't have to concern itself with tracks and sectors, merely using consecutive logical block numbers (which is what it's using internally anyway). If the BIOS wants a translation table it's perfectly welcome to implement one. Apart from anything else, assuming that every track has the same number of sectors isn't valid; consider the Commodore 1541, where tracks can have anything from 17 to 21 sectors (IIRC).

Re the .COM extension: there's actually a magic number in the header which can be checked for processor version (although currently it's not).

There is some very basic documentation at https://raw.githubusercontent.com/david ... c/NOTES.md, but yeah, it needs work.

It has been too long since I have worked with a CP/M BIOS and cannot remember whether the sector number translation occurs with 128-byte logical sectors or potentially larger physical sectors. I will have to research this. Be sure to read section 6.12 of the CP/M 2 Alteration guide, especially the part about the contents of register C upon call to the WRITE subroutine and the deblocking algorithms in Appendix G. I also seem to recall a mention of a bug in the published sample code, but do not remember the details. An easier solution may have been to set the translation table to 1-to-1 and physically format interleaved sectors for other than the "standard" interchange format.

The question remains: can you handle a CP/M disk from a C128 or a C64 cartridge?
Several people are talking about 8080 simulation. It also matters to prevent mistaking a 6502 binary as a CP/M-80 one.
Particular attention is needed to cover the differences between yours and the documented CP/M-80 interface.

I could not find any mention of the second FCB and it appears you do not appear to set aside 256 bytes for a PSP. Also, the default "DMA" address in CP/M-80 is 80h overwriting the command line buffer in the PSP.

The ideal would be to write your own document to cover the programming interface, but that would be a lot of work. Still, if you want to attract new software...

I'm not really sure what you're trying to say here. Why wouldn't it be able to? The CP/M cartridge used a normal 1571 or 1581 disk drive, IIRC (I've never actually used one myself). Of course, you'd need to add support for the disk format in the BIOS as all I have support for is the 1541, but you'd need that anyway.

CPM-80 was infamous for "no two systems share a compatible disk format." Well, it was not quite that bad, but it was close. Unless the disk parameter tables were identical, including the sector number translation, reliable interchange was not possible.

You are developing this using emulation, right? Try creating a CP/M-80 virtual disk in a C128 emulator and test whether file interchange works...

I am going to have to conclude that watching video of a system being built is not a recommended way to learn about it.

I am trying to watch pt 2 but keep drifting in and out. At around 3:07:11, I woke up screaming. On the screen was the following code: It is pretty commonly accepted on this forum that the way to increment and decrement 16-bit quantities are: You have obviously fixed this later, but I do not think I can make myself watch any more video...

Actually, looking at the whole loop, I would rewrite as assuming that register X need not be preserved.