Curious on the sizes of various 6502 kernels

[kveroneau]

I am in the process of writing a kernel in 6502 for a project I am working on, and am kind of curious on how large the kernels were in the computers in the 80s which were powered by these processors.

What functions did these vintage computer kernels have? What sort of Kernel routines were exposed to the user to ease development of assmebler projects?

I have been doing some reading on the ProDOS kernel and how it's MLI calls worked and how parameter passing was done. However, ProDOS was one of the much later 6502 compatible Kernels to be be written, and is pretty advanced in what it does. It has memory management and primitive memory protection.

[BigDumbDinosaur]

kveroneau wrote:

I am in the process of writing a kernel in 6502 for a project I am working on, and am kind of curious on how large the kernels were in the computers in the 80s which were powered by these processors.

Typically, what would fit into an 8K ROM. For example, the Commodore 64 "kernal" occupied about 7.5K of ROM—the bottom end of that ROM contained a small part of the BASIC interpreter. The Commodore 128's kernel was split into two sections, one being the I/O primitives kernel and the other a display kernel. Obviously, more than 8K of ROM was needed.

Quote:

What functions did these vintage computer kernels have? What sort of Kernel routines were exposed to the user to ease development of assmebler projects?

These kernels were more like the BIOS in a PC, mostly a collection of I/O primitives, as well as interrupt handlers and a reset routine.

[GARTHWILSON]

Remember that this site consists of more than just the forum. Pages like http://6502.org/trainers/ may help.

I have the AIM 65 monitor program listing book in front of me which I should probably send to Mike Naberezny to scan and post because it doesn't seem to be available on the site yet. A quick look tells me it had E000-FFFF nearly completely full. It has routines for running its built-in display, printer, keyboard, and tape modem, the monitor with its many commands, and a rudimentary text editor, assembler, and disassembler.

[BigEd]

From a previous discussion:

As many as 39 callable routines in the C64's kernal.

Also interesting is the different design philosophy compared to Acorn's BBC Micro - these 42 look pretty specific and relatively low level, whereas the Beeb's rather fewer entry points are a bit higher level and often very multifunction. (OSBYTE does a lot of get and set actions for example.)

The Beeb has a 16k OS, with a defined interface - about 15 subroutine vectors at the top of memory, with parameters passed in A, X and Y if needed, where in some cases X and Y form a pointer to a parameter block. The third page here sketches the calls offered:
http://8bs.com/mag/09/informantrom.txt
(For a thorough treatment, see the User Guide and/or the Advanced User Guide.)

[kveroneau]

Thanks for the replies, 8K is a fair chunk. I do like some of the methods of parameter passing. ProDOS uses a parameter table, of which a pointer to it directly follows the JSR MLI op. This means that the ProDOS MLI routine needs to pop the return address from the stack to determine the the pointer to the parameter table in memory, and update the return address so that RTS will return just after the parameter table pointer. This was a rather interesting way of passing a large amount of paramaeters to a Kernel functional call.

I do like some of the ways you mentioned above though, such as using all the registers available as the value passed parameters, or just using X,Y registers to determine perhaps the low and high bytes for a 16-bit address pointer to say a parameter table.

There are also mentions of perhaps using the BRK op-code for selecting a function and passing parameters to into a kernel function call. Similar to how a software interrupt(INT op) on x86 works a bit. While BRK doesn't directly support passing an argment in most assemblers, one can always place bytes after the op code, and again update the 16-bit address pointer on the stack for the RTI.

The kernel I am writing, I opt'd to use JSR with unique addresses for each kernel function call. Depending on the routine, parameter passing varies, to either using A,Y, or a specific memory address used to store the parameters for the call.

[GARTHWILSON]

kveroneau wrote:

There are also mentions of perhaps using the BRK op-code for selecting a function and passing parameters to into a kernel function call. Similar to how a software interrupt(INT op) on x86 works a bit. While BRK doesn't directly support passing an argment in most assemblers, one can always place bytes after the op code, and again update the 16-bit address pointer on the stack for the RTI.

BRK is already a two-byte instruction. Your assembler might neglect to put a second byte there as inlined data, but the return address already takes the inlined data byte into account so your routine doesn't have to update the return address before the RTI if you only have the one data byte.

The parameter-passing chapter of my 6502 stacks treatise is at http://wilsonminesco.com/stacks/parampassing.html .

[Steve]

The Atari had a 10 K os in rom. It was smart enough to load a program and provide some basic IO services. There is a port of CP/M to the 6502 http://www.z80.eu/dos65.html called DOS65.

[BigEd]

I was going to ask whether any OS used BRK as a software interrupt - and I'd like to know - but realised that I already knew that the Beeb uses BRK to signal an error. It's part of a mechanism which allows several ROMs (16k each paged in at 0x8000) to participate in a sort of message-passing API. When something happens, each ROM is given the chance to respond to it, which sort of means that all the ROMs are available to provide facilities all the time, even though the current application and the "current language ROM" are always in some sense in the foreground. Within the OS, BRK signals an error, and within the ROM service call system, call 6 signals that error to each ROM:
http://beebwiki.mdfs.net/Paged_ROM_service_calls

The ROMs have an ordering, and each call is passed to each ROM in turn, such that one of them can claim the call and null it out, and subsequent ROMs see a null message.

[whartung]

Steve wrote:

The Atari had a 10 K os in rom. It was smart enough to load a program and provide some basic IO services. There is a port of CP/M to the 6502 http://www.z80.eu/dos65.html called DOS65.

To be fair, the I/O services in the ROM were pretty robust and extensible. Plus it included the screen editor functionality.

[BigEd]

It was only very recently that I realised that the Atari 400/800 line had a significant OS. Here are two pointers to the sources:
http://atariage.com/forums/topic/201133 ... revisions/
https://github.com/sidneycadot/Atari8bit_OSB-NTSC-ROM
and the overview of the size from the second link is:

Quote:

atariosb-ntsc.rom

This is the 10 Kb ROM image of the OSB ROMS. It consists of:

- Floating Point routines $D800 .. $DFFF (2 kilobytes)
- Character Set $E000 .. $E3FF (1 kilobyte)
- Operating System $E400 .. $FFFF (7 kilobytes)

The Operating System ROM listing covers the 7 KB of Operating System code

There are 21 "vectors" - OS entry points.