OS/A65 v1.3.5e --- C64 version --- These are the instructions how to load and run OS/A65 on a C64. First, there is currently only few support for the C64. I used to have serial bus support on my selfbuilt CS/A computer, but this is long time gone (never needed it ;-) and I have pulled the serial routines from very old archives and ported them to the C64. Maybe someone can have a look at it and test it. I don't have a C64 around and the x64 emulator does no hardware emulation of the serial bus, so I cannot test it. But then I implemented the hardware emulation for the CBM IEEE488 interface for the C64 in x64. So if you have this interface, it should be working (The emulation is tested with several PET ROMs, and the original IEEE488 interface ROM.). For the C64, the devices 9 to 11 are mapped to the drives c: to f: As the C64 doesn't have an MMU, there are other restrictions. Only programs can coexist (i.e. run at the same time) that use different memory locations - or know how to share them peacefully. This is why in the ROM source, the variables "sysmem", "syszp" and "sysblk" are given from one prg to the next. They are incremented (sysblk is decremented) and are used as basis for a simple compile time (zeropage) memory allocation scheme. I don't know If I can get the BASIC to work - it wants too much stack space to run without MMU. The programs have to use the PCBUF to send and receive messages. If two or more programms access this 'shared' memory without, protection, bad things can happen. Imagine one task preparing a FORK call and then getting interrupted. Another task is then scheduled and using the buffer for something else, causing the FORK of the first task to go bad... Because of this, a system semaphore is defined that has to be allocated (PSEM) before accessing the send buffer and released (VSEM) after using it. More on this issue in doc/nommu.html. I don't have a C64 at hand, current testing takes place on x64, the X-Windows C64 emulator... There still are some glitches, but the system itself is stable. Some things might happen, because there's no MMU. I have tried to fix all this, but remnants are there... (When you have a 'virtual machine' for a program, you get some kind of lazy about where to put the variables sometimes...) How to get started ------------------ To build the program, you have to have my 6502 cross assembler 'xa-2.0.7d' (the 'd' is important for the #undef directive!). Current testing takes place on 'vice' (x64), the versatile Commodore emulator. Better get the newest version because the IEEE488 interface is not yet in vice-0.10.0. In the file c64rom/c64rom.a65, a few options can be set by setting the defines appropriately. See doc/build.html. First, build the ROM by typing 'make' or 'make c64' in the 'oa' root directory. Then change to the 'c64boot' directory and start x64. In x64, i.e. on the C64, load the (BASIC) program 'loader', which is in 'c64boot'. When run, this program loads the charom, the program ROM and a small machine language program (boot.obj, which is made from boot.a65). It then starts the boot routine that copies the ROMs to their places and jumps to the kernel RESET routine. To test it on a real C64, you have to copy the contents of the 'c64boot' directory to a C64 disk and load it from there (follow the link to the c64rom!). 'loader' is a Basic program that loads the ROMs from drive 11. This is for x64. You should change this to the device you are loading it from. The current ROM contains the video device, the device filesystem, a 'big' shell+monitor and a 'small' monitor. The video device is able to handle up to three screen output windows. The key F1 switches between the different windows. On the first window, the shell is started. On the second one, the small monitor is started. As the C64 has no MMU, these two programs have to use different memory locations and are therefore assembled into the ROM twice. A computer with MMU would only have one binary for both programs. In the shell you can use "dir" on drives a: (registered devides) and b: (rom inventory). If the iec bus works, then drive c: is disk unit 8 and drive d: is disk unit 9, till drive f: is device 11. For the shell/monitor commands see the docs. The memory map is described below, have a look at it for where to put own programs. Internals: ---------- Changes to the normal version have been made in oa1/oa1si.a65 - kernel startup and irq entry/exit to use irq timer (CIA1, timer b) oadev/oa1dt.a65 - video device oafs/fsiec.a65 - to handle serial/parallel bus hardware of the C64. All changes are wrapped around with '#ifdef C64' constructs. fsiec uses CIA2 timer b as serial bus timer. Due to the deficiencies of the C64 hardware, the C64 cannot serve as a disk drive on the bus, giving access to its devices to other computers. Memory Map. ----------- The area below $80 is used by the ROM. The same holds true between $300 and $1000. The exact values can be seen in the assembler screen output (sys* are the 'allocation counters' for different memory types; they are printed at the beginning of each source file and afterwards to compare). $1000-$8000 free memory $8000-$d000 ROM (well, the RAM contains what should be in the ROM of a CS/A computer...) $d000-$e000 I/O area and the RAM under it contains the charrom $e000-$e400 screen buffer 1 $e400-$e800 screen buffer 2 $e800-$ec00 screen buffer 3 $ec00-$f000 stdio library. As opposed to the other docs, the lib has been moved to give better screen handling. Instead of $e7** calls, use $ef** $f000-$10000 OS/A65 kernel. -------------- Any suggestions and comments welcome Andre Fachat (a.fachat@physik.tu-chemnitz.de)