A German magazine, from Franzis Verlag. Sonderheft der ELO Funkschau Elektronik
KIM-1 articles llike Telefonbuch. See also the page on Telefonbuch restauration.
KIM-1 and more general 6502 articles.
About small SBC systems
A German magazine, from Franzis Verlag. Sonderheft der ELO Funkschau Elektronik
KIM-1 articles llike Telefonbuch. See also the page on Telefonbuch restauration.
KIM-1 and more general 6502 articles.
Found in Hobbycomputer #1 (c) 1980 Herwig Feichtinger (of EMUF fame!) improved by Nils Andreas, a phonebook
On the github page of Nils you can find source and executables.
In fact, it is a searchable text database.
The program is written, probably by hand, Herwig Feichtinger in the German magazine Hobbycomputer, Issue 1. Available on archive.org.
I took the source as typed in by Nils, added the comments from the (see below) listing in the article and made sure it was binary compatible with the listing. There are some problems with the first entry in the database.
Source, listing, article, binary, papertape of original version of Telefonbuch
; Target assembler: TASM ;***************************** ;* Telefonbuch * ;* (c) 1979 * ;* Herwig Feichtinger * ;***************************** ; typed in and checked by Nils Andreas ; comments entered from German listing into source ; checked for being binary compatible with original listing in HobbyComputer 1 1979 ; ; Note that getch in KIM-1 returns with Y = $FF, used in this program to save two bytes? ; Testcase for the KIM-1 Simulator, which now emulates this getch behaviour ; ; Hans Otten, 15 december 2021 ; CR = $0d ; carriage return esc = $1b ; escape crlf = $1e2f ; KIM-1 print cr getch = $1e5a ; KIM-1 read char for tty space = $1e9e ; KIM-1 print space tty outch = $1ea0 ; KIM-1 print car on tty incpt = $1f63 ; increment pointer ; ; zeropage ; savy = $f9 tablep = $fa ; pointer into table bufferp = $df ; buffer table = $0200 ; table starts here ; .org $0000 ; start: lda #(table & $ff) ; low byte table address sta tablep lda #(table >> 8) ; high byte table address sta tablep + 1 ; ldx #$17 ; 17 bytes clear lda #$00 buffer: sta bufferp,x ; clear buffer dex bne buffer ; read: jsr getch ; get ascii character cmp #esc ; escape? bne chkend ; no iny ; yes, y = 0 chkfre: jsr incpt ; increment table pointer lda (tablep),y ; query buffer bne chkfre ; free space in buffer? input: jsr getch ; get ascii character iny ; y=0 cmp #esc ; escape? beq start ; yes, back to begin sta (tablep),y ; no, store in table jsr incpt ; increment table pointer jmp input ; and again chkend: cmp #CR ; return? beq zzz ; yes, line ready sta bufferp +1,x ; no, store char in buffer inx ; increment buffer index cpx #$15 ; is $15? bne read ; next character ; zzz: nop nop ; newline: jsr incpt ; table after return ldy #$00 ; search for character lda (tablep),y ; in table beq printquest ; cmp #CR ; found? bne newline ; no, search again found: ldx #$00 ; yes, compare character in table compbuf: iny ; with character in buffer lda bufferp +1,x ; no, compare table and buffer beq printline ; show it lda (tablep),y cmp #CR ; return? beq zzz cmp bufferp +1,x ; next character bne found inx bne compbuf ; nop nop ; printline: jsr crlf ; new line ldy #$01 loadchar: lda (tablep),y ; load character from table beq printquest ; zero is ready cmp #CR ; return? beq zzz ; end of table entry sty savy ; save Y jsr outch ; and print character ldy savy iny ; increment Y, next bne loadchar ; load new character printquest: jsr crlf ; print return lda #'?' ; print ? jsr outch ; jsr space ; print space jmp start ; return ; .end
Here the pages where the program is described and the listing shown.
Nils, a very enthousiast PAL-1 user discovered in an old German magazine, 1979, HobbyComputer 1, a small phonebook program for the KIM-1.
It is a command line utility, extremely small and quite clever. See the post about it here.
So he entered the code in assembler and did some tests on his PAL-1 (it worked) and in the KIM-1 Simulator, which was not working.
He found the ‘database’ corrupted.
Of course I had to look at it and see what was going on. It had to be something about using zeropage pointers into the database.
And it was. In the source an instruction appeared:
INY ; Y = 0
followed by an indirect addressing, Y into the database and preceded by a call to getch, reading a character from the keyboard.
Y was not used in the program before, so in the Simulator it was uncertain what the value was.
GETCH is known to destroy the Y register, delivering the character in register A. How is unspecified.
In the KIM-1 Simulator the KIM-1 GETCH is patched to the ACIA routines of the emulated 6850 serial interface.
Those routines do not use Y, so it is left untouched.
So time to study the KIM-1 routines. In the delay a bit routine the Y register is filled with the final state of a counter, TIMH.
It looks like the decrement ends with the value $FF, when the BPL becomes false, the whole purpose of the use of Y seems to determine that end of the loop?
1ED4 AD F3 17 DELAY LDA CNTH30 1ED7 8D F4 17 STA TIMH 1EDA AD F2 17 LDA CNTL30 1EDD 38 DE2 SEC 1EDE E9 01 DE4 SBC #$01 1EE0 B0 03 BCS DE3 1EE2 CE F4 17 DEC TIMH 1EE5 AC F4 17 DE3 LDY TIMH 1EE8 10 F3 BPL DE2 1EEA 60 RTS
Anyway, the KIM-1 Simulator 0.9.4. GETCH routine now returns with Y=$FF and the phonebook program seems to work.
Work in progress, hope to get more information from Richard!
with his permission
An operating system for the 6502. Published here with permission by the author Richard Leary, 2021.
In the following text “I” is Richard Leary.
What you will find here:
License
“DOS/65 software and documentation are provided as shareware for non-profit, educational, or private use. Any other use is prohibited without approval of Richard A. Leary.”
The DOS/65 V3 ROM software and all other DOS/65 software are free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the license, or any later version.
Of all the problems which plague the 6502 enthusiast, the lack of a low-cost, compatible operating system is one of the most critical. The operating system, the media, and the floppy disk hardware of the common 6502 systems (Commodore, Apple, OSI, Atari, and AIM/SYM/KIM) are not compatible and can not readily be interfaced to systems other than the original. This incompatibility has been the major factor which has prevented the 6502 machines from achieving the status that other systems have achieved.
The challenge then is to establish a standard which minimizes cost, allows easy use by different systems, and ultimately will help make the 6502 and its derivatives the universal processor it is capable of being.
What Richard has done is attack the software side of the problem in order to make any 6502 system a truly workable disk based system. In addition a degree of compatibility is now possible not only between 6502 systems but with large parts of the world of CP/M systems. The result of my efforts is a system of software which Richard has named DOS/65.
DOS/65 itself is a software system which has the same basic structure as the foremost 8080/Z80 software standard, CP/M, and is file compatible with CP/M Version 1.4 and later versions. Since the machine language software obviously can not be compatible between the 8080/Z80 and the 6502, the term “file compatible” simply means that a DOS/65 diskette could be inserted into a CP/M system or vice-versa and the files manipulated in every way except actual execution.
The system could not tell the difference between files created on the host versus those created on a CP/M system. For example a BASIC-E source program which had been created, edited, and used on a CP/M system could be used on a DOS/65 system using the BASIC-E/65 compiler and interpreter with at most only minor changes. Data files of all forms could be exchanged between systems without restriction
The reasons for selecting CP/M as the standard are simple. CP/M has many features including:
None of these claims are overwhelming in themselves, but taken as a whole they stand as a compelling reason to use CP/M as the format and structure standard for a 6502 operating system.
CP/M is a trademark of Caldera.
DOS/65 V3 can run from a read-only memory (ROM). To prove the concept I’ve implemented the ROM version on two different platforms. The first is the WDC W65C02SXB and the second is Daryl Rictor’s SBC2. In both cases I built an auxiliary board using Andre Fachat’s VIA-based SPI interface design. Both platforms are up and running with a micro-SD card as the storage media. Each system has four 8 MB drives provided by the micro-SD card. The interfaces are implemented as four layer printed circuit boards from Express PCB. Because the connector configuration on the two platforms are slightly different each is a unique interface.
Changes associated with DOS/65 V3.0 are small in number, they significantly improve the utility of DOS/65 especially for those users having some sort of high capacity mass storage device attached to their system.
The key changes are:
All software has used 6502 op-codes and addressing modes. No 65C02-only code has been used.
Downloads:
Documents DOS/65 V3
Sources DOS/65 V3
From http://osiweb.org/osiforum/viewtopic.php
Files come form here: https://github.com/osiweb/DOS65/tree/master/DOS65_v2.1
I released (sold in those days) a version for 5.25 inch drives for OSI and an eight inch OSI version. Development of these was frozen in 1986 as there was not enough demand to continue OSI support. I did normally ship DOS/65 as a two disk start up where the first disk was used under OS65D. I did the ROM because for all practical purposes I never used OS65D. If I remember correctly the 5.25 inch version need 9 or 10 diskettes and the 5 inch version a lot less because of the increased diskette capacity.
The SIM (system interface module) code – that is what talks to the hardware – was straightforward and could easily be expanded to handle larger capacity drives. I strongly recommend that for 5.25 inch systems.
DOS/65 manages disk use by dealing with 128 byte logical records. However because of the characteristics of the OSI floppy disk controller the physical sectors are full tracks and a full track is what is read from or written to the diskette. The SIM code maps logical records from or into the full track buffer. A physical track for the standard 5.25 in drive is 2048 bytes. Every track on a DOS/65 5.25 inch diskette is 2048 bytes long.
Downloads:
Documents OSI DOS/65
Sources OSI DOS/65
C64 port of DOS/65
“What I (Richard A. Leary) have done is attack the software side of the problem in order to make any 6502 system a truly workable disk based system. In addition a degree of compatibility is now possible not only between 6502 systems but with large parts of the world of CP/M systems. The result of my efforts is a system of software which I have named DOS/65.”
Richard’s implementation is initially made for S-100 based systems, but he began to port it to the C64 also (see below).
DOS/65 has a lot of CP/M look-alike commands for the command line and also some applications like BASIC-E included.
Of course some differences between CP/M-80 and DOS/65 exist – the lowest memory areas (e.g. the “zero page”) are not usable for the TPA, so the usable system memory area starts at a higher address (e.g. $0400).
Richard has prepared two .D64 images
DOS65-1C.D64 (Bootdisk with updated SIM C64S304.ASM)
DOS65A.D64 (Blank disk)
Load the bootdisk with: LOAD “DOS65”,8,1:RUN
Downloads:
Sources DOS/65 V2 2008
Documents DOS/65 V2 2008
Kevin, a.k.a floobydust enhanced the DOS/65 V3 system to his 65C02 system.
See the topics on the retrobrew forum 6502.org and his github repository.
What makes CP/M and DOS/65 special is the separation between hardware and the operating system with a well defined interface. In CP/M terms this is the BIOS, the only part to implement for new hardware. In DOS/65 system this is the interface module (SIM). Various examples are in the sources archives.
This part of the “V3 ROM Supplement”, see the V3 section illustrates how this works in DOS/65.
The first steps in implementing the ROM version of DOS/65 on a new platform are:
Implementation is straightforward. The basic DOS/65 software structure need not change. However, the specific addresses of functions may have to change as a function of the platform monitor or other software elements. The process of implementing D0S/65 for the SBC2 drew heavily upon the experience involved in producing the version for the WDC SXB but was actually simpler because of the capabilities provided by the SBC2 monitor.
The SD interface for the W65c02SXB based on Andre Fachat’s v1.1 design using a VIA and three eternal ICs.
DOS/65 V2 as implemented on the nhyodyne modular backplane system.
More information in the 6502proc folder at this github page.
Dwight Elvey designed and programmed a diagnostic board for the KIM-1, to determine what might be wrong with the KIM-1
The board switches off the 6530 ROMs and one can run tests on teh onboard ROM, looking for for defective RAM, defective LED display, defective 6530 ports.
Dwight Elvey designed and programmed a diagnostic board for the KIM-1, to determine what might be wrong with the KIM-1
The board switches off the 6530 ROMs and one can run tests on the onboard ROM, looking for for defective RAM, defective LED display, defective 6530 ports.
Here I present the complete design of the board, with help and permission of Dwight Elvey, Santo Nucifora and Liu Ganning.
Triggered by post on twitter by Santo Nucifora (snuci) showing the results of his tests on his impressive KIM-1 collection, I connected to Dwight Elvey for permission to publish the design files.
Alas, Dwight did not have the circuit diagram, only the pcb drawings and binary of the ROM. With the aid of Santo Nucifora the instructions and sources of the debug board pack surfaced and the circuit could be reconstructed.
In November 20121 Liu. the designer of the PAL-1, asked help with his defective KIM-1, it was dead. So I gave him all the information I got from Dwight and he recreated the circuit, made a PCB and started testing his kIM-1.
Here a redrawn and slightly modified circuit diagram by Jonathan Levine:
I’ve (Dwight) been debugging my KIM-1 and while doing so, hopefully helping others. What does one do when it doesn’t work? One can check some obvious places like the clock signals, reset pulse, interrupts and sync signal. Beyond that there is little that one can do with the monitor code dead. The problem could be any of the chips, from the simplest 7404 to one of the RRIOT chips. I’ve always said that one should write code and use an EPROM to test the functions of the board. Now I’m putting actions to these words. First one needs to create a place to put an EPROM if there is no socket. That is what I did for the KIM1. I have created a small board with a minimum of parts on a prototype board.
A little about the circuit. It is designed to run with a minimal amount of the KIM computer working. The processor has to be able to execute code and access the data but and addresses. The code I’ve written also expects the KIM’s address decoder chip to be functioning. In order to work, the debug board uses both connectors for signals. The expansion connector is mostly used but three signals are needed from the application connector. You’ll need 2 44 pin connectors.
The board disables the KIM’s ROM and takes over boot. One typically the sets the reset vector to $0C00 and assembles the code there (in other words the the reset vector need to be at $0FFC as the EPROM will be seen at $0FFFC as well as $0FFC, being dual mapped. In fact the EPROM will also be mirrored at every 1K if A15=1. This can be useful if KIM’s addresses decoder doesn’t work.
There are 2 LEDs on the debug board. One LED is on if it sees a access to the 1K space at $0C00 to $0FFF. It is not a fool proof indicator but if lit generally indicates that code is executing.
It can only be reset with the reset signal ( RS on the keyboard ). The other LED is a status light. It can be turned on and off from code. A write to $1000 of the D0=1 will turn it on and a write with D0=0 will turn it off. It provides a minimal feedback until KIM’s 7 segment LEDs are found to be functional. It also is needed to verify that the 1K RAM at address 0 is functional.
The RAM is needed to be able to use the stack and any zero page address. It can also be use to just blink to make sure a long running test is still working.
(from file DBINSTR.TXT)
Diagnostic Debug for the KIM-1 and 6530 to 6532 adapter The diagnostic EPROM can hold up to 16 1K diagnostic or other programs. Most of these diagnostic programs are intended to take over reset from the onboard ROMs in order to run various diagnostic test on the KIM-1 hardware. The control of which to boot from is controlled by the DB switch. With a working monitor, it can be run by opening the DB switch. The Diagnostic Debug board is also used to initialize the EEPROM on the 6530 to 6532 adapter with either the code for -002 or -003 ROM data. When the switch on the Diagnostic Debug board has the DB position turned on, the boot vevtors come from the EPROM on the Diagnostic Debug board. Any 1K address above 8000H will be decoded from the 1k block selected by the switch S0 to S3. Note that the switch between DB and S0 is not used. These 1k blocks are always decoded from 8000H as long as the DB switch is on. This takes over the interupt and boot vectors. There is always a 1K block decoded at 0C00 to 0FFF as well. This is available, even if booted from the monitors ROM, regardless of the DB switch position. The main thing the DB switch does is allow the boot to happen from the Diagnostic Debug EPROM rather than from a possibly defective -002 monitor ROM. Each 1K test block is intended be run in sequence. This allows one to test and diagnose a single area of the KIM-1 at a time. Many test depend on the passing of the previous test. An obvious example is if there is a RAM failure the display test is likely to fail as well. A failure of a later test may not be a positive indication that the failure is what the test is testing for if a previous test has failed. One should diagnose and repair the earliest test first. Test 0 Flash Switch setting: DB on -- S0 on S1 on S2 on S3 on This is a minimal test of the processor. All it does is slowly flash the Green LED on the diagnostic board. It is initiated by the reset switch, on the keyboard of the KIM-1 ( RS ). This test only uses the processor, addresss decoder and data bus. If it fails to run. It will be a problem in one of these areas. This test does not use any of the RAM in either the 2102s or in either of the 6530 RAM areas. It only uses a few instructions and is not a complete CPU diagnostic. Remember the processor includes clocks and reset vector and possible MNI stuck. As a bonous some of the extra space has the program Astroids from the First Book of Kim. It the normal KIM-1 monitor is running, one can play if by setting the same switches as Flash except DB to off. set the address at 0E00 and GO. Use 0 and 3 to move your space ship to avoid the astroids. Test 1 RAMTEST Switch setting: DB on -- S0 off S1 on S2 on S3 on This test does a simple stuck at test of the RAM by writing and reading 055H and 0FFH to each location in the 2102 RAM array. A passing indication is that the Green LED will blink at about 1 seconds rate for 8 time then on the 9th it will stay lit. Should there be a failure the Green LED will blink out the failing bit number. A 1 second blink indicates a good bit and a short blink indicates a failed bit. After the 8th blink it will stay unlit. If all the bits fail it may be an address decoder problem. A single bit failure is likely a single RAM or the bus buffer. The blink code starts with bit D0 and blinks through to D7. This test does not test or use the 6530/2 RAM for vaiables during the test, other than the RAM it test. It only runs in the processor's internal registers. This is not easy to do for a 6502. This is the reason it doesn't also indicate the failed address as well as the bit. This would likely need the variable space that is under test. Once this test passes, later test will assume that the RAM on Page0 and Page1 are functional and use them as most 6502 programs do. There are still possible address errors that RAMs can have. This test is initiated by the RS reset button on the keyboard. As an example, a long-long-short-long-long-long-long-long blink code would indicat that bit D2 was failing. In other words the blink code is D0 first to D7 last. With the board such that the key board is on the lower right, the RAM chips blink from top to bottom for the blink codes. Each blink is one RAM chip position. Test 2 Display Switch setting: DB on -- S0 on S1 off S2 on S3 on This test the displays. It will also flash the green LED just in case the display isn't working so that you know that the test is running. It sequences 0000 00 to FFFF FF. Not much else to say here. Test 3 KeyBd Switch setting: DB on -- S0 off S1 off S2 on S3 on This is used to test the keyboard. It test all the buttons. Pressing RS will restart the test. ST will light the green light ( use RS to turn it off if you like ). The other keys will display the row and column for each button. Refer to the schematic for a reference. As an example, the E button will display 2 G. Try each switch from 0 to GO to see what unique combination is created. This test is run with the small, on/off, switch on the keyboard in the OFF position. This switch can be tested by using the single step function as described in the KIM-1 Users manual, with the normal KIM-1 monitor. Key table: ROW COL 0 0 G 1 0 F 2 0 E 3 0 d 4 0 c 5 0 b 6 0 A 7 1 G 8 1 F 9 1 E A 1 d B 1 c C 1 b D 1 A E 2 G f 2 F AD 2 E DA 2 d PC 2 A + 2 c GO 2 b Test 4 CRC2 Switch setting: DB on -- S0 on S1 on S2 off S3 on This test the ROM data for -002. It will flash the CRC generated from reading the entire ROM. It should read C219. It does this in a continuous loop. That is why the display flashes, because it is rerunning the CRC code and not updating the display. Any erratic value could be an indication of ROM failue. Test 5 CRC3 Switch setting: DB on -- S0 off S1 on S2 off S3 on This test the ROM data for -003. It is the same as CRC2 but the CRC numbers are 5EA4 instead, for the -003 chip. Test 6 64RAM2 Switch setting: DB on -- S0 on S1 off S2 off S3 on This test the 64 bits of RAM in the -002 6530 chip. It uses the March C algorythm. This is a very good test. If it passes, it says 'Good'. If it fails it says 'Bad nn' Where the nn indicates the bad address. Say it displayed Bad C9'. That would indicate that the address 1700 + C9 = 17C9 failed. Make sure to start the test from a clean reset by pushing the RS when changing the debug switches or when powering up. Test 7 64RAM3 Switch setting: DB on -- S0 off S1 off S2 off S3 on This test the 64 bits of RAM in the -003 6530 chip. It uses the March C algorythm. This is a good test. If it passes, it says 'Good'. If it fails it says 'Bad nn' Where the nn indicates the bad address. Say it displayed 'Bad 92'. That would indicate thath the address 1700 + 92 = 1792 failed. Make sure to start the test from a clean reset by pushing the RS when changing the debug switches or when powering up. Test 8 EEPROM2 DB on -- S0 on S1 on S2 on S3 off This is not really a test. This is code to program the EEPROM on the -002 adapter module. The EEPROM on the adapter is not programmed. this must be done on the KIM-1 by this program. Install the adpater observing the proper orientation with the KIM powered off. The yellow jumper is for the -002 decode. It must be intact. The red jumper enables EEPROM programming. Set the switches as above and hit the RS button then power up. This loads the programming code into RAM. Make sure to do a clean reset (RS) after setting up the switches for this code. The programming code is loaded into RAM in a millisecond or so. The only indication is that the RED LED will be lit. The image for the EEPROM is a full 1024 bytes and the diagnosic code window in memory is only 1024 bytes. It is not possible to have the programming code and the ROM image in the same debug switch settings. Once the code is in RAM, it waits for you to select the ROM image by the debug switch settings. You do this by changing the Debug switches to: DB on -- S0 off S1 on S2 on S3 off Make sure the upper left keyboard switch is in the off position. Now press the ST button. This causes a NMI interrupt that starts the programming cycle. The green light should flash quickly. This indicated that the programming is continuing OK. If the Green LED then goes off, the programming is complete. If the Green LED comes on steady, the programming has failed. It would be wise to test that the EEPROM is working. Hold the RS button down and set the DB to off. Releasing the RS should start the normal KIM-1 monitor( it usually requires the AD or some switch selected to determine user input source. If it is working, it is wise to now cut the red wire loop at the end of the adapter board ( only the red wire the other is -002/-003 select ). This blocks the accidental writes to the EEPROM. I recommend leaving a little wire as you might want to change the programming at some future time. Test 10 EEPROM3 DB on -- S0 on S1 off S2 on S3 off This is not really a test. This is code to program the EEPROM on the -003 adapter module. The EEPROM on the adapter is not programmed. this must be done on the KIM-1 by this program. Install the adpater observing the proper orientation with the KIM powered off. The yellow jumper is part of the decode for -003. The yellow jumper must be cut for -003 location. The red jumper enables programming. Set the switches as above and hit the RS button then power up. This loads the programming code into RAM. Make sure to do a clean reset (RS) after setting up the switches for this code. The programming code is loaded into RAM in a millisecond or so. The only indication is that the RED LED will be lit. The image for the EEPROM is a full 1024 bytes and the diagnosic code window in memory is only 1024 bytes. It is not possible to have the programming code and the ROM image in the same debug switch settings. Once the code is in RAM, it waits for you to select the ROM image by the debug switch settings. You do this by changing the Debug switches to: DB on -- S0 off S1 off S2 on S3 off Make sure the upper left keyboard switch is in the off position. Now press the ST button. This causes a NMI interrupt that starts the programming cycle. The green light should flash quickly. This indicated that the programming is continuing OK. If the Green LED then goes off, the programming is complete. If the Green LED comes on steady, the programming has failed. It would be wise to test that the EEPROM is working. You might run CRC3, Test 5 to verify or check the values through the KIM-1 monitor. It is wise to now cut the red wire loop at the end of the adapter board. This blocks the accidental writes to the EEPROM. I recommend leaving a little wire as you might want to change the programming at some future time. -003 EEPROM code has a large blank portion of code space near the end. You might want to want some special code that is always resident that you could put it this space. It is starting at 1A96 and ending at 1BF9. This is 356 bytes for a small perminent piece of code. Of course any change to the -003 EEPROM will also change the CRC3 results. It is wise to write it down to ensure it you still have a -003 valid test. This is all the test in Debug EPROM. The remaining switch locations are available for other use. If you want the KIM-1 to boot to this code make sure to put the reset vector at the end of the 1K block. With the DB swith to the on position and a RS reset, it will run the EPROM code. It can be run at 0C00 to 0FFF or at FC00 to FFFF. If the DB switch is off, code on the EPROM must be started from the KIM-1 monitor. It will only be seen at 0C00 to 0FFF and is not seen in the upper memory window as it would be to boot to the debug code. There are 4 completely unused 1K blocks left in the debug EPROM. Also if you look at each of the test, you'll note that most of the test only use a small portion of the 1k block. One can always add one's code in one of these blank areas. Just remember that the code will be offset into the 1K window starting at 0C00. Before adding of edition the debug EPROM, make sure to make a copy of the original EPROM. The unused bytes, of the debug 1K blocks are all 00s so the entire EPROM would need to be erased and editied in an external image of the EPROM before writng an new code. The unused 4 1K block are 0FF and can be programed without erasing the EPROM.
I know KB6 existed. The ‘6’ stands for the precision in digits of the floating point number. In the documentation KB-6 is described.
Never seen a version in the wild. I know KB6 existed. The ‘6’ stands for the precision in digits of the floating point number. In the documentation KB-6 is described. Never seen a version in the wild. So the reconstruction here is not checked with the original, addresses in the reconstruction from the linker differ from the documentation.”>So the reconstruction here is not checked with the original, addresses in the reconstruction from the linker differ from the documentation.
More information on KB9 and a new faster and smaller version
On this page you will find:
Another MOS TECH BASIC for KIM-1, lower serial number
KB-9 stands for Microsoft Basic V1.1 for the KIM-1 with 9 digits precision. Actually, when you run it, it is called MOS Tech 6502 Basic v1.1 Copyright 1977 by Microsoft Co.
The ‘9’ stands for 9 digit precision floating point numbers. A KB-6 (6 digits precision) existed, but no copy ever turned up.
Articles on KB9 in the clubmagazine KIM/6502 Kenner:
– KIM Kenner 4 Siep de Vries Evaluatie 8K Basic, test of accuracy of KB-9, Dutch
– KIM Kenner 5 Uwe Schroder, English, Some Basic problems solved
– KIM Kenner 6 S. Woldringh Patches op 8K Basic Load and Save commands
– KIM Kenner 10 p 10 Microsoft Basic, Hans Otten.
– KIM Kenner 11 p 15 S. Woldringh Patches op 8K Basic part 2
– KIM Kenner 11 p 19 W. van Gelderen Read and Write on cassette for 8K Basic
– KIM Kenner 12 p 15 Patches Microsoft Basic, Hans Otten. Trace mode Renumber
– KIM Kenner 14 p 39 Patches Microsoft Basic, Hans Otten. Calculated line numbers
– 6502 Kenner 16 p 49 Patches Microsoft Basic, W. Blonk Corrections on KIM Kenner 12
– 6502 Kenner 19 p 34 Patches Microsoft Basic, Hans Otten. Speed up Basic 10% with ROR
– 6502 Kenner 22 p 12 Patches Microsoft Basic part 1, van Nieuwenhove Koen, adapt KB-9 to Elektor Junior
– 6502 Kenner 23 p 12 Patches Microsoft Basic part 2, van Nieuwenhove Koen, adapt KB-9 to Elektor Junior
– 6502 Kenner 24 p 14 Patches Microsoft Basic part 3, van Nieuwenhove Koen, adapt KB-9 to Elektor Junior
– 6502 Kenner 25 p 6 Patches Microsoft Basic part 4, van Nieuwenhove Koen, adapt KB-9 to Elektor Junior
– 6502 Kenner 29 p 33 KB-9 Basic on Acorn SYSTEM-1
– 6502 Kenner 32 p 21 W. L. van Pelt KB-9 Basic Tokenized keywords and addresses
All the KB9 KIMKenner articles in one PDF here
Language lab section in the 6502 User Notes:
– Vol 13 Basic tips, Renumber Page 1, Page 2
– Vol 14, Tips, Paging, Automatic Line numbers, the GET statement, USR function
Page 1, Page 2, Page 3, Page 4
– Vol 15 USR Dispatch, Load/save Basic arrays Page 1, Page 2, Page 3
-Vol 16 Line Editor Page 1, Page 2, Page 3, Page 4
-Vol 17 IEEE, Save Load cassette Page 1, Page 2, Page 3, Page 4
After I bought MOS Basic for the KIM-1 in 1978 a lot of study went into understanding and adapting the interpreter. In the Dutch club magazine the KIM Kenner (see above) I and others published my work on it, like tape I/O in hypertape format, calculated goto’s, trace mode, paged output and such.
I modified it later on to suit a bit better to my system, that moved from the KIM-1 I/O to keyboard input via a ASCII keyboard, output to video terminal and a parallel matrix printer Heathkit H14. Even later a real serial interface (ACIA 6850) was used for I/O. I also replaced the startup routine, from destructive to reusable and no questions asked.
Here the Micro Ade source of the patches to V3.0 (Parallel keyboard, video output, H14 printer) and nothing asked non-destructive startup routine. I should rewrite that to the current KB-9 V2 to also include the GET and Backspace patches. V1.3 perhaps?
In the previous section the pagetable article was shown, with resources to recreate from source many 6502 Basic’s, like KB-9.
Here an example how I, quick and dirty, used this to create a KB-9 named V1.2 which is smaller and faster than the original.
This is how to prepare for it (Windows, can be done also on Linux)
Do the adaptations as described below or your own:
ca65 -D kb9 msbasic.s -o tmp/kb9v2.o -l tmp/kb9v2.lst ld65 -C kb9.cfg tmp/kb9v2.o -o tmp/kb9v2.bin -Ln tmp/kb9v2.lbl
First example: use the ROR instruction and suppress nulls sent to the terminal and Clear decimal and fix GET
I changed this:
CONFIG_NULL := 1 ;CONFIG_ROR_WORKAROUND := 1 ; patch HO 2021
COLD_START: .ifdef SYM1 jsr ACCESS .endif .ifdef KBD . . . .else .ifndef CBM2 cld ; patch for KIM-1 HO 2021 ldx #$FF stx CURLIN+1
Assemble and link with the batch file makekb9v2.bat, this will deliver in the folder tmp/
– kb9v2.bin file : load as usual at $2000
– kb9v2.lbl text file
– kb9v2lst textfile
Start KB9 V2 now at location $3F8E, label COLD_START (used to be $4065, so we gained some RAM), see the lbl file.
Here is an archive with all files mentioned above.
And here the new KB-9 V1.2 executable, faster (no ROR instruction emulation) and a bit smaller.
You can test all this with the KIM-1 Simulator (version 0.9.3 lets you load CC65 type of symbol files)
I know KB-6 existed. The ‘6’ stands for the precision in digits of the floating point number. In the documentation KB-6 is described.
Never seen a version in the wild. So the reconstruction here is not checked with the original, addresses in the reconstruction from the linker differ from the documentation.
Perhaps the ROR workaround or the insertion of CLD in the init.s caused this.
KB-6 can be ‘reconstructed’ since other versions of 6 digit Microsoft Basic are in the ‘pagetable sources’.
It takes one define added in define_kim.s, changes on the original file are now:
; CONFIG_NULL := 1 ; patch HO 2021 ;CONFIG_ROR_WORKAROUND := 1 ; patch HO 2021 CONFIG_SMALL := 1 ; patch H0 2021
Assemble and link as above, replace kb9v2 with kb6 in the batch file. See the archive for a working batch file.
COLD_START moves to $3D50, size shrinks to 8K.
Download KB-6 here.
As you can see in the following screenshots it works! Note the number of digits is less, as expected. It should be faster also.
Microsoft Basic for the KIM-1 KB-9
Microsoft Basic for the KIM-1 KB-6, less precision, smaller program size
The bug was described and fixed first by an article in the KIM User note
From the pagetable sources:
BUG: The beq/bne L2AF8 below is supposed to be always taken. For this to happen, the last load must be a 0 for beq and != 0 for bne.
The original Microsoft code had ldx/ldy/bne here, which was only correct for a non-ZP INPUTBUFFER. Commodore fixed it in CBMBASIC V1 by swapping the ldx and the ldy. It was broken on KIM, but okay on APPLE and CBM2, because these used a non-ZP INPUTBUFFER. Microsoft fixed this somewhere after KIM and before MICROTAN, by using beq instead of bne in the ZP case.
.ifdef CBM1 ldy #>(INPUTBUFFER-1) ldx #<(INPUTBUFFER-1) .else ldx #<(INPUTBUFFER-1) ldy #>(INPUTBUFFER-1) .. beq 08
You can easily fix this in KB9 by changing the branch in $2AEE from $D0 (bne) to $F0 (beq).
I have fixed this in the source of KB9V2 (KB6 does not have the GET statement) .
Correcting typing errors can be done with the _ key ($5F). On a video terminal, like we use nowadays it can be done with backspace.
The way characters are handled by the input routine do not allow to just replace the compare with _ (C9 5F) with 08 for backspace.
A trick by Jim W4JBM can be used to reuse the BELL handling (07) to a backspace.
Replace in inline.s
INLINAIM: .endif .ifndef CONFIG_NO_LINE_EDITING cmp #$07 beq L2443
with
INLINAIM: .ifndef CONFIG_NO_LINE_EDITING cmp #$08 beq L2420 In the original KB9.BIN you can do that with poke 9260,8 poke 9262,241