6502.org

The experience with the members of this forum really amaze me. I was a child of the 70's and didn't get my first computer until 81-82 (TI-99 4/a). Shortly after that, I got a C64C and spent most of the 80's programming 6502 (6510) assembly on it. When I was 12, I *invented* a way for the C64 to display hundreds of colors by rapidly flicking two colors at 60FPS.

Of course, I wasn't the first to invent that but in my 12 year old mind...in a small country town....I was king of the computers.

Now, I spent several hours yesterday working with Vaadin and Spring. Certainly a letdown compared to those days of the C64.

Thanks for the details!

I don't know the mechanism, but CP/M certainly had a way to report how much free memory there was, since it's minimum requirement was 20K of RAM, programs must have had a way of ascertaining, portably, how big the TPA was.

CP/M 3.0 later had a mechanism to add resident modules below the BDOS, so those would consume memory. Also, ZCPR3 had different buffers you could optionally allocate. ZCPR3 was CP/M compatible. All these suggest that there was a portable mechanism to find how large the free space was.

MS-DOS COM files are a direct descendant of CP/M COM files, essentially static binary files designed to be loaded and started at $0100. You could almost mechanically port CP/M code to MS-DOS using the Tiny memory model (CS=DS=SS), since the 8088 and 8080 were so similar (I don't think they shared op codes, but they might have).

Ah:
> The address field at BOOT+0006H (normally 006H) contains the value of FBASE and can be used to determine the size of available memory

(From http://www.cpm.z80.de/manuals/archive/cpm22htm/ch5.htm)

Yea, ok.

Folks mentioned FLEX, so I took a gander at it. It's interesting to contrast CP/M and FLEX.

Specifically, all calls to BDOS in CP/M go through a single entry point, whereas in FLEX, the calls go to specific addresses.

Now, in CP/M there's simply a JMP at the single entry point, to go wherever the dispatch code is (which, coincidentally appears to be the same as FBASE, and I think the entry point in to CP/M is BASE+0005H, which would make it JMP FBASE, anyway).

But in FLEX, it's clear that all of the entry point address are also simply place to put a JMP in to the actual code.

However the architecture mandate is different. FLEX assumes code at specific locations in higher memory ($CXXX), whereas CP/M requires only some byte in very low memory. JMP 0000H is how a program "exits", and warmstarts CP/M. The CP/M technique also seems a bit more extensible (up to 255 functions using the basic function number, could always have an extended function).

Down side is that CP/M is a bit more expensive: set the register, JSR to a JMP to some dispatch code that inevitably calls the desired routine vs a simple JSR to a JMP. But, easy to argue that these calls are high level enough, and so slow anyway (couple of more instructions are going to save you when you hit that floppy…) that they're not missed.

Now, contrast this to how the Atari did it.

With the Atari, they had a single entry point to the Central IO system. They allowed 8 channels, also at a specified point in memory. They also had a table of device drivers.

So you would select a channel, specify a device name (like K: for keyboard, or D:FILE.TXT for a disk file), "open" the device, then call the common entry point with X set to the channel number. The table of device drivers was extensible, you could add your own, or override a system supplied one.

Whereas CP/M and FLEX had a different routine for writing to disk vs writing to the console, with the Atari you just wrote to the D device instead of the S(screen) device. To format a diskette on the Atari, you made an extended command to the Disk driver. The calls were the same. Much like in Unix, you basically have open, read, write, close, and ioctl that works for "anything". In CP/M you would pass a pointer to a FCB, whereas with the Atari, you passed the channel number to a list of fixed "FCBs" (they don't call them that). Likely they chose to do this because passing pointer is more of a pain than simply passing a register on the 6502.

The Atari had no real need to strive for portability, but it's easy to see if you make the Atari CIO call similar to the way CP/M does it (through a RAM vector), it could be quite portable.

Glenn Holmer gives a very helpful talk, with slides, on the C64 version of GeckOS, at the Vintage Computer Festival MidWest (VCFMW) 2019, at https://www.youtube.com/watch?v=jtlAOdJmeDI . See also Cenbe's commentary on it, at https://www.lyonlabs.org/commodore/onre ... lysis.html .

The Commodore KERNAL (first released in 1977 with the PET 2001, but continued and expanded through all their 8-bit systems), generally in a separate ROM from BASIC and certainly logically separate, had a device-independent I/O system where each device had an assigned number from 0-15 (0=keyboard, 1=cassette, 3=display, 8=first floppy drive, etc.). Ther was a standard set of vectors to open channels on a device for read/write, sending commands, etc., read and write those channels, and so on. Things were vectored through jump tables so that one could add further "virtual" devices 32-255.

PTF's? Program Temporary Fixes? There was nothing temporary about them! The place I worked at was a VAR, I got to install them on multiple S/36's, D2K if I remember correctly. For a while we had 1255 MICR readers. that cable was huge. The PTF's would fail if the 1255 was not physically disconnected from the S/36 and left disconnected for some period of time.

Fun Times!

Walter

Well, IIRC, the 1255 MICR used BUS/TAG cables, which were pretty thick and could be very long lengths, 15 feet and longer connecting it to the control unit. If you want to see really fat cables, the 1403 printer had a pair of "shoe connectors" that huge pin connectors slid into and those cables ran to the control unit. Those cables were pushing 2" in diameter.