OS/A65 v1.3.6g --- 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. But I finally built a x1541 cable and managed to put the files back on a VC1541 to test it on the real thing. I used to have serial bus support on my selfbuilt CS/A computer, but this is long time gone (never needed it ;-). I have pulled the serial routines from very old archives and ported them to the C64 so that it now works. I have an original C64 parallel IEEE488 expansion board, so that I use this for better performance. I also implemented the hardware emulation for the CBM IEEE488 interface for the C64 in the VICE Commodore emulator (from version 0.11 on). So if you have this interface, use it for better file transfer performance on the real C64 or for file access in VICE. Change the line in c64rom/c64rom.a65 from '#undef PARALLEL' to '#define PARALLEL'. 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 assemble time (zeropage) memory allocation scheme. Because the stack is to small, there can only be five (5) tasks running concurrently at the same time. 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. 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. For vice, you have to use the PARALLEL option in c64rom.a65. In vice the serial bus routines are trapped and the routines are now on different addresses obviously. Only parallel bus hardware emulation is in vice, so we have to use this. Also start vice with the notraps option. 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.obj file!). '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. You also have to undefine the PARALLEL option in c64rom.a65, if you don't have the original CBM parallel IEEE488 or don't want to use it. 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 C= key switches between the different windows (Don't try to use the Ctrl-Alt-Fx keys in XFree when the mouse cursor is in the vice window. OS/A will detect a Ctrl-Switchkey and therefore send an EOF to the program....) 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 program invocations. 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 (as my selfbuilt one does). Memory Map. ----------- The area below $80 is used by the ROM. The same holds true between $300 and $1c00. 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). $1c00-$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)