Showing posts with label 6502. Show all posts
Showing posts with label 6502. Show all posts

Wednesday, November 24, 2021

Retrocomputing Basic Implementations

Here is a summary of a number of Basic implementations that I have come across and worked with as part of my retrocomputing hobby. Many of these were ported by me or others to different platforms from the ones they were originally written for (for example, single board computers based on the 6502, 6809, Z80, and 68000 microprocessors). These are all found on my github  account.

Name Developer Platform Code size Comments
Enhanced Basic (68000) Lee Davison 68000 14K Full-featured Basic for 68K platform
Tiny Basic for the 68000 Gordon Brandly 68000 4K Derived from and similar to Palo Alto Tiny Basic.
Enhanced Basic (6502) Lee Davison 6502 11K Full-featured Basic for 6502 platform.
Microsoft Basic for 6502 Microsoft Apple 2, Commodore, KIM-1, OSI, and others 8K Basic used on several early 6502-based microcomputers.
Tiny Basic for 6502 Tom Pitman 6502 3K Originally published in Dr. Dobbs Journal.
Apple 1 Basic Steve Wozniak 6502 (Apple 1) 4K Basic for the Apple 1, later expanded into Apple 2 Integer Basic.
BBC Basic 2 for Acorn Atom/BBC Computer Roger Wilson (Acorn Computer) 6502-based Acorn Atom and BBC Computers 16K Basic for the Acorn Atom and BBC Computers.
Tiny Basic for 6800 Tom Pitman 6800 2K My version runs on the Heathkit ETA-3400.
Tiny Basic for 6809 Tom Pitman 6809 2K 6809 port of 6800 version.
TSC Micro BASIC PLUS Technical Systems Consultants 6809 4K Similar to Tiny Basic.
Sinclair ZX81 Basic John Grant and Steve Vickers, Nine Tiles Networks and Sinclair Research Sinclair ZX80/ZX81, Timex 1000 8K Basic for the Sinclair ZX81 computer.

Sunday, March 15, 2015

KIM-1 MIcrocomputer

I recently acquired an original KIM-1 microcomputer. This is quite an interesting and historically important machine, being one of the first affordable microcomputers.

This particular machine also has an interesting history. I've covered it in a YouTube video, and intend to create some more videos in the series.

For the last couple of weeks I have been entering a and running the programs from The First Book of KIM-1. I've put buildable source code as well as binary download files on my github account.




Sunday, February 1, 2015

Superboard /// Theory of Operation

Here are some notes on design and theory of operation of the Superboard ///. This was gleaned from looking at the circuit and I may have got some details wrong. Refer to the schematic diagram that is included on the CD.

All parts on the board are through-hole, making it easy to assemble. All ICs are socketed, and the board is silk-screened with component designations and values. Vince Briel says that the blue solder mask used is a tribute to the blue color scheme that Ohio Scientific used in their line of computers. About half of the board is taken up by the 53 keyboard keys.


Power comes in as +5V via the USB port through the USB to serial FTDI board. Vince Briel recommends a 1000 mA or more USB power supply but the USB 2 standard calls for 500 mA from a host (computer) and the board typically takes about 115 mA, in my measurements. Note that the power switch comes after the USB to serial board, so the serial board is always on and takes some power. The power LED is after the power switch.

The original Superboard took a lot more power and was specified as needing a 5 volt 3 amp power supply. Power consumption depended a lot on the amount of RAM, e.g. whether 4K or 8K was installed. I remember on mine that a lot of the chips on the board ran quite hot, especially the 2114 RAM chips. On the Superboard ///, the only chip that gets warm at all is the 6850, which is the only non-CMOS chip on the board.

An LM3940 voltage regulator IC converts the 5V from the USB port to 3.3V. All circuitry runs on 3.3V except for the 6850 ACIA.

The USB to serial board is a low cost off the shelf FTDI board. These can be ordered from various suppliers from China and the SKU on the package matched one from http://www.banggood.com. There are some units on the market which have fake FTDI chips; this seems to be a legitimate one. It also just happens to have a blue solder mask that nicely matches the main board. It looks like Vince replaced the original right angle header on the board with a straight one, as it appears to have been hand soldered.



The DTR line of the USB to serial board goes via a cap to a transistor switch to the RESET line of the Propeller switch. This allows the Propeller to be reset from the serial port as part of the protocol for in-circuit programming. Arduino boards use a similar scheme. On Linux systems you may find that when you open the serial port it toggles DTR and resets the system, which is annoying. You can disable this using this command:

  stty -F /dev/ttyUSB0 -hup -clocal raw

The Parallax Propeller chip is an interesting device that contains eight 32-bit processors which can run independently and communicate via shared memory. It has hardware on-board to assist with generating video signals in software. a serial port, and can load a program from an external serial ROM on powerup.

The Propeller CPU does some of the emulation, most notably generation of composite video in one of two video modes, and emulation of the ROM and video RAM for the 6502. It runs at 5 MHz. On reset it loads its firmware from the serial EEPROM, a 24LC256 32Kx8 serial EEPROM. This is a standard feature of the Propeller. With the Propeller development tools (which are free) you can reprogram either the Propeller or the EEPROM via the serial port from a host computer. All of the source files for the firmware are included on the Superboard /// CD.

Vince Briel, with help from Jac Goudsmit, wrote the firmware for the Propeller chip which is included on the CD. They had to use some creativity to implement the emulation in real-time and within the available pin contraints on the Propeller CPU chip. I have not looked closely at the code. It is written in the BASIC-like SPIN programming language as well as some assembly language.

The video by default is monochrome with 25 lines by 25 characters. If you hold down the BREAK key on powerup, it uses a 32x32 video mode that some models of OSI computers also supported. However, BASIC always only uses 24x24 characters for display. The Superboard /// supports the same character set font as the Superboard II, offering 255 characters including a number that could be used for games and graphics.

The BREAK key on the key board goes to an input of the Propeller so simulate reset operation. The software requires holding it down for 3 seconds to avoid accidentally hitting it. Contrary to what the manual says, on reset you do not lose any program in memory. A BASIC warm start ("W" from the boot menu) will preserve any BASIC program in memory. The random screen on powerup is simulated in software to act like the original Superboard (interestingly, the one I owned had a powerup reset circuit and did not do this, it also had a 3 second delay on the BREAK key). At the upper left of the "random screen" is the firmware version number (currently 0.06).

The serial port transmit and receive lines go to the Propeller chip. Another Propeller i/o pin directly generates the composite video output (in software). Other Propeller i/o pins control some of the address lines and the data lines for the 6502, as well as some control signals such as R/W, RESET, and CLOCK. The 1 MHz clock for the 6502 is completely generated by the Propeller in software.

The 6502 is a Western Design Center 65C02. It is clocked at 1 MHz for compatibility with the Superboard II but can run at higher speeds (mine is a 14 MHz part). It runs at 3.3V. Between the Propeller chip, glue logic, RAM, etc. it runs in a standard fashion even though some hardware like the ROM is emulated by the Propeller. Incidentally, the 65C02 has some additional instructions over the original 6502 that can be quite useful. It is backwards compatible, with the new instructions using what were invalid/unused opcode on the original 6502. It is also much lower power than the original 6502.

The RAM uses a real RAM chip rather than being emulated. It is an AS6C1008, which is a 128K x 8 chip but only 32K is used as this was the maximum that the Superboard II supported.

The 6850 ACIA provides the serial interface. This is the same chip that was used on the original Superboard II, ensuring software compatibility. It is made by Motorola and was the standard UART at the time for the 6800 series of CPUs. It is interesting that Ohio Scientific did not use the more powerful 6551 ACIA that was made by Motorola for the 6502 series (it may not have been available at the time, or possibly it was more expensive). The 6850 is the only chip that runs on +5V, and is no longer manufactured, so new old stock chips have to be obtained. Mine has a date code of 8507 (the seventh week of 1985). It runs at 9600 baud, unlike the 300 baud of the original Superboard. On the Superboard II is was usually used for the cassette tape interface. Since the baud clock is being generated by the Propeller chip, you could change it in the Propeller firmware, although there is no hardware handshaking and the 6502 when running BASIC cannot keep up to 9600 bps and needs delays added to avoid data loss.

The keyboard circuit is similar to the original Superboard II. The key switches are arranged in rows and columns. A register can select one of 8 rows of keys and drive it low. The register is then read back to detect which, if any, keys in each column of that row are pressed. The software scans each row in turn to detect key presses. This is a simple design but has some side effects, most notably that there is no latching or typeahead of keys pressed, you can only tell if a key is pressed at the time it is scanned. It does mean that you can detect if multiple keys are pressed simultaneously, and independently detect the left and right shift keys. The BREAK key is not part of the keyboard scanning circuit.



 SHIFT LOCK is a latching key and is typically on to enable uppercase characters only as BASIC did not recognize lowercase characters in keywords or commands. The keyboard circuit uses a few discrete TTL chips for the read and write registers and for address decoding. The keyboard row and column signals are also brought out to a 16-pin DIP connector (not included) on the board so that you could connect an external keyboard, if desired. The original Superboard II did not have this connector.

The keys are high quality units made by Cherry, and the key caps are custom and made by WASD Keyboards. The latching SHIFT LOCK key is no longer manufactured, so when the supply runs out Vince will have to ship small slide switches instead (there is a place on the board to install one).

More address decoding is done by a 7HC138 decoder, and some of the signals go back to the Propeller CPU to help it identify when certain blocks of addresses are selected so that ROM and video memory can be emulated. This reduces the number of signals that need to go to the Propeller CPU.

A 40-pin expansion connector brings most of the important signals out so that in theory peripherals devices could be added. It is similar to the expansion connector on the original Superboard II, but uses a different connector since it is not electrically compatible with the Superboard II, using 3.3V rather than 5V levels. It would be an interesting project to interface the Superboard /// with one of the original Ohio Scientific floppy disk controllers so that it could run the disk operating system.

The original Superboard II has a cassette tape interface that ran at 300 baud and followed the Kansas City Standard for storing data on audio tapes. This circuitry is not included on the Superboard ///, as the higher speed serial port is a more convenient way to transfer files. There is a 10-pin connector that brings out the relevant signals so you could implement a tape interface if you desired.

That's pretty much it. There's not a lot of circuitry on the board, especially compared to the original Superboard II, which has to do things like generating the video using discrete logic, and used more than 70 ICs. You could even simplify the design by replacing the 6 TTL chips with a PAL, for example, but that would take away some of the retro design.



By the way, the name Superboard ///, is clearly derived from wanting to be the logical successor of the Superboard II, and calling it /// is a nod to the (infamous) Apple /// computer which was the successor to the Apple II.

Saturday, January 31, 2015

Superboard /// Port of JMON

JMON is a machine language monitor program I wrote for the Briel Replica 1, a replica of the Apple 1. It was only natural to want to port it to run on my new Superboard ///. Given that both computers use a 6502 microprocessor, and JMON has minimal hardware dependencies, it was not hard to do. In one evening I had it all working on the Superboard ///.

After determining the addresses of suitable keyboard input and screen output routines, I very quickly got it up and running. Most of the work to fully port it was to adapt the output to the smaller screen width (24 characters) of the Superboard. I also had to disable some features that did not apply. It is now fully working and is quite useful, particularly as the built-in OSI machine language monitor is very primitive.

Years ago, when I had an original Superboard II, I wrote some machine language programs by hand assembling them and entering the hex codes into the monitor. I very quickly wrote a disassembler in BASIC in order to help verify and debug my programs.

JMON is cross-compiled on a desktop computer, and both the Apple Replica 1 and Superboard /// versions build from the same source code using ifdefs for conditional code.

Below are some representative screens showing some of the commands.

Initial Screen
Help command
Disassemble command
Memory Dump command
Info command
Changing registers and single stepping
Memory test

The Superboard ///

My latest retrocomputing project is building the Superboard /// computer kit by Briel Computers.

It is a replica of the Ohio Scientific Superboard II. The original SuperBoard II was one of the first affordable computers that featured a full keyboard, video output, BASIC in ROM.


At a price of $279 in 1979, it was an amazing bargain at the time when compared to systems like the Apple II that retailed for about $1300. For that you got an assembled board but needed to add a 5 volt power supply, monitor or TV set and RF modulator, and cassette tape for storage.

I owned one that I purchased in 1979 and it was my first computer. With it, I learned BASIC and 6502 machine language programming.

The SuperBoard /// is Vince Briel's replica of the original SuperBoard. It features a 6502 processor, but simplifies the design by replacing a lot of logic chips with a Propeller CPU. It is software compatible with the original system.

It is sold assembled or as a kit. I opted for the kit.



To date I've made three YoutYube videos on the kit, covering unboxing, assembly, and basic operation. They can be found on my YouTube channel.

I also have some files on my github account including a handy Quick reference, the OSI firmware including BASIC, and a port of my JMON monitor program. The Visual Monitor program that I entered a few months ago also works.

Below are some useful web links.

My Stuff:



Ohio Scientific:

http://en.wikipedia.org/wiki/Ohio_Scientific
http://classiccmp.org/dunfield/osi/index.htm
http://home.cmaaccess.com/~jerrytravis/
http://oldcomputers.net/osi-600.html
http://osi.marks-lab.com/
http://osiweb.org/osiweb/software.html
http://superboard.com.sapo.pt/
http://uk101.sourceforge.net/
http://www.6502.org/
http://www.6502.org/users/sjgray/computer/osi-c4p/
http://www.binarydinosaurs.co.uk/Museum/ohio/index.php
http://www.classic-computers.org.nz/collection/challenger1.htm
http://www.compukit.org/Compukit.org
http://www.cse.dmu.ac.uk/~mward/martin/software/index.html#UK101
http://www.gifford.co.uk/~coredump/uk101.htm
http://www.historyofpersonalcomputing.com/osi-superboard-i-and-ii/
http://www.lysator.liu.se/adventure/machines/OSI.html
http://www.neoncluster.com/projects-osi/osi-cassettes.html
http://www.old-computers.com/museum/computer.asp?c=572&st=1
http://www.old-computers.com/museum/computer.asp?c=860&st=1
http://www.oldcomputermuseum.com/superboard_2.html
http://www.osiweb.org/
http://www.pagetable.com/?p=43
http://www.pagetable.com/?p=46
http://www.pc-history.org/ohio.htm
http://www.technology.niagarac.on.ca/people/mcsele/OhioScientific.html
http://dabeaz.blogspot.co.uk/2010/08/using-python-to-encode-cassette.html
http://searle.hostei.com/grant/uk101/uk101.html
http://www.slideshare.net/dabeaz/using-python3-to-build-a-cloud-computing-service-for-my-superboard-ii
https://www.youtube.com/watch?v=pB2t6xG2RzE

Superboard ///:

http://forum.6502.org/viewtopic.php?f=8&t=2487
http://www.brielcomputers.com/phpBB3/viewtopic.php?f=39&t=1627
http://www.brielcomputers.com/wordpress/?cat=39
http://www.brielcomputers.com/wordpress/?cat=41
http://www.retrothing.com/2014/06/superboard-iii-briel-recreates-another-1970s-microcomputer.html

Thursday, October 23, 2014

The Visible Monitor

While waiting for my Briel Superboard III kit, I was reminded of a book that I blogged about last year. The Visible Monitor program in that book was written to run on a number of computers of the era, including the Ohio Scientific C-1P or Superboard II.


In preparation for trying it on the Superboard III, I entered the machine code from the book. Back in the day, this consisted of typing in many numbers as BASIC DATA statements. A loader program read the data at run-time and stored it in memory. A simple checksum scheme caught most errors. After a number of sessions I had all the code entered. I was able to save some time by scanning the book pages and using OCR software to convert it to text, however the process was still quite error prone and required a lot of manual corrections.

After fixing any obvious errors, I was able to load the software on an Ohio Scientific computer emulator. The loader program found a number of additional errors that I had made. After correcting those, I made a file suitable for directly loading from the OSI monitor program. Loading it into the emulator, I was pleasantly surprised to see that it ran fine. I'm quite confident that it will also run on the real hardware.

I also entered some of the source code for the monitor with suitable changes to build with the CC65 assembler. I've only entered a small portion of the code so far, and may not complete this as it is a very time consuming task. All of the code can be found here at github.

By coincidence, a lot of vintage books I recently bought on eBay included the book "Top Down Assembly Language Programming for your VIC-20 and Commodore 64". It turns out that this is essentially the same book, but with the Visible Monitor ported to the VIC-20 and Commodore 64 computers.


To be honest, the Visible Monitor seems a little clunky and hard to use and I think my JMON program is better. I plan to port it to the Superboard III.

Thursday, August 21, 2014

Ohio Scientific Superboard II

The first computer I owned was an Ohio Scientific Superboard II. Bought in 1980, it was the only reasonably complete computer on the market for under $300.

I learned a lot on that machine, including BASIC and 6502 machine and assembly language programming.

Alas, it was damaged in a flood a number of years ago and had to be thrown out. I recently found this original paperwork which came with the machine:





I am, however, eagerly waiting the Superboard III.  a replica of the Superboard II that is being offered by Briel Computers. It should be fun to see the Superboard powered up again, running BASIC and the really primitive machine language monitor. I might even have some software I wrote on old cassette tapes that can still be recovered.

I'll report back here as the project progresses.

Monday, June 2, 2014

New Retro Computer Kit

Dubbed a Software Defined Computer, the Propeddle  is a new forthcoming computer kit that has a 65C02 processor as well as a Propeller CPU, and is planned to be able to emulate various 6502-based computers by changing the software. The prototype is already able to emulate an Apple 1.

The name Propeddle comes from the Propeller CPU used on the board, and Chuck Peddle, one of the designers of the 6502 microprocessor.

It has similarities to the Briel Replica 1, but aims to be able to be able to emulate different computers.

It looks like a interesting project, and one that I will keep my eye on. Being able to emulate a number of different old computers would be cool. It should be able to emulate, say, a KIM-1, Commodore PET, or Ohio Scientific Challenger by changing the firware. I wonder if it will have the processing power to emulate a more complex machine like the Apple II?

Tuesday, May 13, 2014

Apple II Monitor Running on Briel Replica 1

As a followup to my previous blog post, here is a transcript of running some Apple II Monitor commands on the Briel Replica 1. You can find documentation on the Monitor commands in a number of places, including here. The commands typed by the user are in bold.


Monitor prompt:

*

Dump memory:

*1000.100F
1000- A2 10 EA CA D0 FA 60 BE
1008- 00 00 4A 83 00 00 75 D7

Change memory:

*1000:01 02 03

*1000.100F
1000- 01 02 03 CA D0 FA 60 BE
1008- 00 00 4A 83 00 00 75 D7

Move Memory:

*1000<2000 .2fffm="" b="">

Verify Memory:

*1000<2000 .3000v="" b="">
3000-FF (00)

Disassemble:

*FF00L
FF00-   D8          CLD   
FF01-   58          CLI   
FF02-   A0 7F       LDY   #$7F
FF04-   8C 12 D0    STY   $D012
FF07-   A9 A7       LDA   #$A7
FF09-   8D 11 D0    STA   $D011
FF0C-   8D 13 D0    STA   $D013
FF0F-   C9 DF       CMP   #$DF
FF11-   F0 13       BEQ   $FF26
FF13-   C9 9B       CMP   #$9B
FF15-   F0 03       BEQ   $FF1A
FF17-   C8          INY   
FF18-   10 0F       BPL   $FF29
FF1A-   A9 DC       LDA   #$DC
FF1C-   20 EF FF    JSR   $FFEF
FF1F-   A9 8D       LDA   #$8D
FF21-   20 EF FF    JSR   $FFEF
FF24-   A0 01       LDY   #$01
FF26-   88          DEY   
FF27-   30 F6       BMI   $FF1F

Mini-Assembler:

*7666G

!1000:LDX #$10
1000-   A2 10       LDX   #$10
! NOP
1002-   EA          NOP   
! DEX
1003-   CA          DEX   
! BNE 1000
1004-   D0 FA       BNE   $1000
! RTS
1006-   60          RTS   

Call Monitor to Disassemble:

!$1000L
1000-   A2 10       LDX   #$10
1002-   EA          NOP   
1003-   CA          DEX   
1004-   D0 FA       BNE   $1000
1006-   60          RTS   
1007-   BE 00 00    LDX   $0000,Y
100A-   4A          LSR   
100B-   83          ???   
100C-   00          BRK   
100D-   00          BRK   
100E-   75 D7       ADC   $D7,X
1010-   00          BRK   
1011-   00          BRK   
1012-   F8          SED   
1013-   87          ???   
1014-   00          BRK   
1015-   00          BRK   
1016-   B5 F6       LDA   $F6,X
1018-   42          ???   
1019-   00          BRK   

Go back to Monitor:

!$7F65G

Single step:

*1000S
1000-   A2 10       LDX   #$10
 A=10 X=10 Y=7D P=70 S=CA
*S
1002-   EA          NOP   
 A=10 X=10 Y=7D P=70 S=CA
*S
1003-   CA          DEX   
 A=10 X=0F Y=7D P=70 S=CA
*S
1004-   D0 FA       BNE   $1000
 A=10 X=0F Y=7D P=70 S=CA
*S
1000-   A2 10       LDX   #$10
 A=10 X=10 Y=7D P=70 S=CA
*

Display 6502 Registers:

*^E
 A=10 X=10 Y=7D P=70 S=CA

Hex arithmetic:

*12+34
=46
*FE-12
=EC

Go to BASIC:

*^B
>LIST

Sunday, May 11, 2014

Apple II Monitor Ported to Apple 1

As announced here,  a cassette tape was found that contains a port of the Apple II Monitor to the Apple 1. It was done by Winston Gayler. Additional work was done by Wendell Sander, who posted documentation, cassette tape sound files and Woz Mon binaries here .

I've tested the code on a Briel Replica 1 and it works quite well. The only issue I found on the Replica 1 is that the commands that require Control keys do not work as the Replica 1 does not emulate Control keys when using a PS/2 keyboard. They will work if entered from the serial port.

This weekend I went a little further adapted the original monitor source from the "Red Book" to build under the CA65 assembler, then applied the changes for the Apple 1. The result is code that can be assembled from source and easily relocated.

References:

  1. www.apple1notes.com/old_apple/Monitor_II_on_1.html
  2. www.applefritter.com/content/apple-ii-monitor-ported-apple-1
  3. github.com/jefftranter/6502/tree/master/asm/Apple%5D%5BMonitor


Thursday, March 13, 2014

Building Apple II DOS From Source Code

I am currently reading the book Sophistication & Simplicity: The Life and Times of the Apple II Computer by Steven Weyhrich. It is a fascinating history of the Apple II series of computers, from the beginnings with the Apple I up to the present time.

Many of the books and historical articles about Apple do not give enough credit to the Apple II for getting the company started and generating the revenue and size of company that was need to develop later products like the Lisa, Macintosh, and iPhone.

Reading about Apple DOS reminded me that, recently, the original Apple II DOS source code was publicly released. It has quite an interesting  history, which is covered both in the Steven Weyrich book as well as the Computer History Museum site where the materials can be downloaded.

There is both PDF format scans of the original assembler listing as well as a Microsoft Word file with the source code. I thought it would be fun to try to get the code to build using the CC65 assembler.

An evening's work was enough to get both the low-level disk routines source file as well as the full DOS source cross-compiled on a Linux system using CC65. Since I do not own an Apple II I am not able to test it. but the files assemble and appear to be correct.

I did not check every instruction in detail against the PDF source listing but the length of the code is correct and I checked a good number of the addresses. The Microsoft Word version was very helpful and was used as a starting point, but it did contain a number of errors which were resolved by looking at the scan of the assembly listing. Interestingly enough, the original source code assembler listing reports one assembly error in the code, which I believe I fixed correctly.

If you are interested in the ported code, it can be found here.

After doing the port, I found out that Scott LaBombard had also got the code built and even running on an Apple II. I plan to compare my binaries to his and see if there are any errors in my version that I missed.

I don't plan to do more with this, at least not unless I get my hands on an Apple II (I had an Apple //e and an Apple ][+ in the past but they were damaged a number of years ago in a basement flood).

References:

Monday, January 14, 2013

More About the Abandoned Farmhouse Adventure


I mentioned here earlier that I ported my Abandoned Farmhouse Adventure  game to the Raspberry Pi and got it into the Pi Store as a free download. Here are some more details about the game and how it was developed for people that may be interested.

The program was written in the C programming language, consisting of just over 800 lines of source code. I originally wrote it in March 2012 as a game for the Replica 1 Computer, a replica of the first computer, the Apple 1, offered by Apple Computer in 1976.

The Briel Replica 1 Computer
On the Replica 1 it was compiled using the CC65 compiler which supports the 8-bit 6502 microprocessor used by the Replica 1 (and Apple 1). It took me a few evenings and weekend mornings to design and write the game. The game had to fit within the hardware constraints of the Replica 1: a one MHz 8-bit processor with only a few kilobytes of memory and only text output.

I did most testing of the game on a Linux desktop system using the GNU gcc compiler, as it was faster and easier to build and debug than on the Replica 1.

The game was announced on the Briel Computers forum and made available to any Replica 1 or Apple 1 computer users who wanted to try it.

I've been following the Raspberry Pi since it's early development. With the announcement of the Raspberry Pi store, I thought it would be fun to get an application in the new store. The adventure game was already running on Linux so getting it on the Linux-based Raspberry Pi should be straightforward. Porting it to the Raspberry Pi involved adding lower case text (the Apple 1 could only display upper case text). I also removed some code that was specific to the CC65 compiler. Most of the work was figuring out how to publish an application in the Raspberry Pi app store, and waiting for it to pass through the application approval process.

Screen Shot Of The Game
For people trying the game, I won't give a solution or any spoilers, but here are a few hints. I suggest drawing out a map on a piece of paper and making notes as you play the game. Pay attention to any messages, like needing food or water, as these will soon become important in the game. Not all items in the game are necessarily needed to solve it; some may be red herrings. The game will take some time to solve. Keep at it. If you get frustrated, set it aside for a while and you may think of some new insight into how to solve it.

I would really like to hear from you if you solved the game, or even if you played it but did not complete it yet. As I write this the game has had 361 downloads but no one has actually reported completing the game. I don't think I made it too hard, but it is difficult as the developer to stand back and assess how challenging the game is.

I have been planning to make a version of the games with a Qt-based graphical user interface on it, which would be less like a retro text adventure game but more playable by people accustomed to modern GUIs.

Early Prototype of GUI Version of the Game
The game is open source and published under an Apache license. The source code can be found here. You are free to share, port, or modify the game subject to the terms of the Apache license. If you are really stuck solving the game and are at all fluent in C code, you could look at the source code to get some hints. Much of the code is data-driven and could be used to implement an entirely different adventure just by changing the map, strings, and some of the logic that handles special actions.

Finally, the farm described here is based on a real farmhouse where my father lived many years ago, right down to the layout of most of the rooms. And I also have a grandson who was almost three years old at the time I wrote this. It is interesting to think that in a few years he may come across this game in which he appears and maybe play it.

Saturday, October 6, 2012

The Apple 1 Cassette Interface


The Apple Cassette Interface (ACI) was the only accessory sold for the Apple 1 computer. It allowed saving and loading programs from cassette tape using an inexpensive tape recorder.

Vince Briel  recently made a batch of replica ACI boards both as kits or pre-assembled. The board is similar to the original except using a more easily obtainable EEPROM chip rather than the ROM chips on the original design. I got one of the first batch of kits and assembled it.

ACI parts and manual ready to be assembled
I have a couple of tape recorders from that era. I have a GE model that I bought around 1980 and used with my Ohio Scientific Superboard computer for tape storage. I also recently picked up a Panasonic model from the 1970s or 1980s at a thrift store.  I don't the Panasonic RQ-2102 model that Apple originally recommended (amazingly it is still be manufactured and available).

GE Cassette Recorder circa 1980
Panasonic Recorder picked up a thrift shop
Panasonic RQ-2102 Recommended by Apple
The original Apple Cassette Interface manual is available on-line. The software is on-board the ACI and consists of only 256 bytes of code written by Woz. It is primitive and has no error detection. The later Apple II had a similar cassette interface circuit built into the motherboard (in models up to the Apple 2c). The Apple II used a similar storage scheme but added a checksum verification to detect errors.

Assembled ACI Replica
I haven't got mine to work reliably yet. I am working with some other kit builders to track down why. It is known to be tricky to get working. As well as a tape recorder I've been using my computer's sound card and an oscilloscope to debug it. I'll report more here on my progress toward getting it to work reliably. 

ACI Installed in the Replica 1

Sunday, August 12, 2012

Replica 1 Quick Reference, Apple 1 on the Raspberry Pi, and the return of IMSAI


Earlier I made a one page reference of useful addresses for the Replica 1. I've extended that into a more comprehensive four page quick reference. You can download it from hereThat directory also has some documents I wrote like a summary of the 65C02 and 65816 processors and some errata for Apple 1 manuals.




I recently got a Raspberry Pi board. This is a very small (credit card sized), low cost ($35) embedded desktop computer that can run Linux. For fun I compiled the POM1 Apple 1 Emulator on it. It ran quite well although it was a little slow on the Raspberry Pi's 600MHz ARM CPU. I've ordered a hardware expansion board for the Raspberry Pi called the Gertboard and plan to use if for some hardware experiments.




I've started playing with the Propeller CPU on the Replica 1. It is quite an amazing chip - 8 CPUs with shared memory, a built-in high level language interpreter as well as machine language, and hardware I/O ports. It can even generate video (which it does for the Replica 1). I'll have more to say here as I explore it further.




I'm looking forward to getting the Apple Cassette Interface when Briel computers starts shipping them. It sounds like big things are in store for Briel Computers. Vince Briel is planning to purchase the assets
of IMSAI computer. They were one of the first home computer manufacturers (along with Altair) and a portion of the company was still in business. He is hoping to restart a project they had to introduce a new replica of the original IMSAI 8080 computer.

Wednesday, August 8, 2012

Converting Between Floating Point and Human Readable Format


In my last post I mentioned 6502 code that can convert between ASCII and floating point formats that was written by Marvin L De Jong and published in the February and April 1981 issues of COMPUTE! magazine.

I've now entered it and ported it to the CC65 assembler to run on the Replica 1.

As often seems to be the case, there were a number of errors in the printed code, such as symbols that were never defined. The "#" sign was also not used to specify immediate addressing (this was apparently a coding convention that the author followed in all of his published code).

Fortunately it seemed that the generated machine code in the listing was correct, so in most cases I was able to use that as a reference to determine what the code should be.

I also had to combine the code in the first article with changes in the second one as there was no complete listing of the final software.

The code used some i/o routines for the AIM-65 machine so those needed to be be replaced with equivalents for the Replica 1.

After a couple of evenings of porting and testing I had the string to floating point and floating point to string functions working (De Jong refers to it as "BCD format" but it is really an ASCII string format). So, for example, I could now convert a string like "+6.02214E23" or "-1.2E-19" to floating point and back to ASCII. I then updated my little test/demo program to support calling the new routines.

The floating point format used by the De Jong code is a little different from the format used by the Woz code, but I was able to convert them easily enough.

The final result is the demo program which exercises all the functions. Here is an example run:

FLOATING POINT DEMONSTRATION PROGRAM

F - FIXED TO FLOATING POINT
P - FLOATING TO FIXED POINT
L - NATURAL LOG
N - COMMON LOG
E - EXPONENTIAL
A - FLOATING POINT ADD
S - FLOATING POINT SUBTRACT
M - FLOATING POINT MULTIPLY
D - FLOATING POINT DIVIDE
B - STRING TO FLOATING POINT
T - FLOATING POINT TO STRING
? - THIS HELP SCREEN
X - EXIT

SELECT A FUNCTION: B
STRING TO FLOATING POINT
ENTER FP STRING: 1234
FLOATING POINT IS: 8A 4D2000

SELECT A FUNCTION: T
FLOATING POINT TO STRING
ENTER EXPONENT AND MANTISSA: 8A 4D2000
FLOATING POINT IS: 1234

SELECT A FUNCTION: B
STRING TO FLOATING POINT
ENTER FP STRING: 6.02214E23
FLOATING POINT IS: CE 7F8616

SELECT A FUNCTION: T
FLOATING POINT TO STRING
ENTER EXPONENT AND MANTISSA: CE 7F8616
FLOATING POINT IS: 60221399.E16

With the facilities here you could implement a math program like a scientific calculator. I may do that at some point.

I learned a little about floating point code with this project. It also reminded me that back at the time this code was written there was no standard for representing floating point numbers. That was addressed by the IEEE Standard for Floating-Point Arithmetic (IEEE 754) and most modern CPU chips that have floating point hardware now support this standard, and language compilers typically support it in their run-time libraries. CPUs that lack floating point hardware typically emulate it in software, using code much like the 6502 code here, but more complex and typically written in C.

As usual, all of the code can be found here and you are welcome to use it.

Sunday, August 5, 2012

6502 Floating Point Routines


In the August 1976 issue of Dr. Dobb's Journal Steve Wozniak and Roy Rankin published a listing of floating point math routines for the 6502. The code is portable and provides routines for floating point add, subtract, multiply and divide as well as natural and common log and exponential functions and conversion between fixed and floating point. A version of this code was later included in the firmware for the Apple II.

The article in PDF and text format is available from 6502.org  so I thought it would be fun to get it running on the Replica 1. I took the code and made a few small changes to get it to assemble under the CC65 assembler. I also included some later fixes that were published in Dr. Dobb's.

I then wrote an interactive program that allows the different functions to be executed. I did some minimal testing and all the routines seemed to be working quite well.

Here is a sample run of the program (input by the user is in bold):

FLOATING POINT DEMONSTRATION PROGRAM


F - FIXED TO FLOATING POINT
P - FLOATING TO FIXED POINT
L - NATURAL LOG
N - COMMON LOG
E - EXPONENTIAL
A - FLOATING POINT ADD
S - FLOATING POINT SUBTRACT
M - FLOATING POINT MULTIPLY
D - FLOATING POINT DIVIDE
? - THIS HELP SCREEN
X - EXIT


SELECT A FUNCTION: F
FIXED TO FLOATING POINT
ENTER 16-BIT HEX NUMBER: 0123
FLOATING POINT IS: 88 48C000


SELECT A FUNCTION: P
FLOATING TO FIXED POINT
ENTER EXPONENT AND MANTISSA: 88 48C000
FIXED POINT IS: 0123


SELECT A FUNCTION: F
FIXED TO FLOATING POINT
ENTER 16-BIT HEX NUMBER: 0456
FLOATING POINT IS: 8A 456000


SELECT A FUNCTION: M
FLOATING POINT MULTIPLY
ENTER EXPONENT AND MANTISSA: 88 48C000
ENTER EXPONENT AND MANTISSA: 8A 456000
RESULT IS: 92 4EDC20


SELECT A FUNCTION: P
FLOATING TO FIXED POINT
ENTER EXPONENT AND MANTISSA: 92 4EDC20
ERROR OCCURRED AT ADDRESS $1FE6


SELECT A FUNCTION: A
FLOATING POINT ADD
ENTER EXPONENT AND MANTISSA: 88 48C000
ENTER EXPONENT AND MANTISSA: 8A 456000
RESULT IS: 8A 579000


SELECT A FUNCTION: P
FLOATING TO FIXED POINT
ENTER EXPONENT AND MANTISSA: 8A 579000
FIXED POINT IS: 0579


SELECT A FUNCTION: X

This code could be used to write assembly language programs that need to do floating point math. One piece is missing though -- conversion between the floating point representation and one that can be input by a user or printed. This is usually done using Binary Coded Decimal (BCD).

A little research found a couple of articles by Marvin L De Jong in the February and April 1981 issues of COMPUTE! magazine that described BCD to floating point and floating point to BCD conversion routines. While the floating point format he used was slightly different from what was used in Woz's code, I'm hoping that I can adapt it. So that is my next little project.

All of the code can be found here on github.

Tuesday, July 31, 2012

A YUMmy New Game


I wanted to write another game for the Replica 1, and after considering a few alternatives, I decided to write a computer version of YUM, a game that is popular with our family.


YUM is a dice game, similar to games known as Yahtzee, Yacht and Generala. Each player rolls five dice up to three times and then applies the dice toward a category to claim points. The game has 12 rounds during which each player attempts to claim the most points in each category.

The winner is the person scoring the most points at the end of the game. This version supports up to three players of which any can be human or computer players.

It would be a little frustrating to write in BASIC and tedious in assembler so I wrote it in C using the CC65 6502 compiler/assembler. This had the advantage that I could develop and test it on a desktop Linux system.



There is nothing particularly novel about the code. The computer players play a relatively good game based on some simple rules. The game could support more than three players by changing a compile-time constant -- the only limitation is that the screen size only conveniently fits a table of scores for three players.



Because it was intended to run on the Replica 1 it was kept small and efficient to run within the 32K memory limit and only use uppercase characters and fit on a 40x24 character screen.





The source is released under an Apache license. Both the source code and a binary that will run on a Replica 1system  can be found at here.

If you want to run it on a real Apple 1 or similar, you will need to have just over 16K of RAM. With a little effort I could probably get the code size down a little to fit in 16K (the Replica 1 has 32K).





For my next Replica 1 project I am eagerly awaiting the Apple Cassette Interface kits that Vince Briel is offering. I expect to be one of the first beta testers for this, and I have a cassette tape player ready to go.


Saturday, July 14, 2012

JMON Trace Function


I've implemented one of the features missing from JMON, and one that I had been relying on Krusader's mini monitor for: an instruction trace function. This function allows you to single step through a program, see a disassembly of the current instruction, and see the values of the hardware registers. This feature is almost indispensable for debugging code. Krusader does this but I wanted to write my own.

I can think of at least three ways to single step code. One is a hardware solution. The Apple 1 manual actually shows a circuit that does this, and presumably Woz used this circuit to debug the Apple 1. This approach is very useful for bringing up new hardware that may not yet be working, but it is complex and expensive.

A second approach is the use the breakpoint instruction (BRK). By inserting a BRK instruction in code, when executed it can jump to the break vector which can run code which shows the current values of the registers. You can then replace the BRK with the original instruction and place a BRK at the next instruction, and continue execution. A disadvantage of this approach is that it only works for code in RAM and not ROM, since the program memory must be written to with the BRK instruction.

A third approach, and the one I used, is to look at the next instruction to be executed, copy it to a buffer, and execute it in place. The instruction can be followed by code that jumps back into the trace code in the monitor program. This approach has the advantage of working even for code that is in ROM.

To make this work there are a couple of wrinkles. Some instructions change the flow of control (e.g. JMP and JSR) and would jump out of the trace code. To trace these I simulate instead of execute them, doing the equivalent of what the instruction would do. For example. a JMP instruction just needs to update the value of the program counter. These special instructions are JMP, JSR, RTS, RTI, and BRK. Similar are the branch instructions. Initially I thought I would simulate these, looking at the CPU registers to determine whether the branch was taken or not. This would get a little complex as there are about 8 branch instructions to simulate, each checking a different condition. Instead I use a simpler approach that can use the same code for all branches. I execute the branch instruction in the buffer, but I adjust the branch destination so it jumps to a known location in the trace code. Whether the branch is taken or not, it stays under control of the trace code.

My trace function produces similar output to Krusader's mini monitor. You can set the register values use the Register command, including the Program Counter. The "." command traces/executes one instruction.

The breakpoint feature of JMON works in conjunction with this. If a breakpoint is hit, it updates the register values and you can single step as desired. You can also use the Go command to execute from the current program counter address.

It took a little work to get all of this correct for all instructions. It leveraged the previous work on the disassembler and mini assembler. For example, I needed to know the length of each instruction and this information was already available in tables used by the disassembler.

A sample session is shown below. Commands entered by the user are in bold. The actual trace commands "." are not echoed.

JMON MONITOR 0.99 BY JEFF TRANTER
? R
A-00 X-00 Y-00 S-0140 P-00 ........
0000   00          BRK
A-00 X-00 Y-00 S-0140 P-00 ........
PC-6000
? R
A-00 X-00 Y-B0 S-0140 P-00 ........
6000   EA          NOP
A-Esc
? A-00 X-00 Y-B0 S-0140 P-30 ..-B....
6001   A9 01       LDA   #$01
? A-01 X-00 Y-B0 S-0140 P-30 ..-B....
6003   A0 01       LDY   #$01
? A-01 X-00 Y-01 S-0140 P-30 ..-B....
6005   A2 01       LDX   #$01
? A-01 X-01 Y-01 S-0140 P-30 ..-B....
6007   08          PHP
? A-01 X-01 Y-01 S-013F P-30 ..-B....
6008   68          PLA
? A-30 X-01 Y-01 S-0140 P-30 ..-B....
6009   38          SEC
? A-30 X-01 Y-01 S-0140 P-31 ..-B...C
600A   18          CLC
? A-30 X-01 Y-01 S-0140 P-30 ..-B....
600B   69 01       ADC   #$01
? A-31 X-01 Y-01 S-0140 P-30 ..-B....
600D   F8          SED
? A-31 X-01 Y-01 S-0140 P-38 ..-BD...
600E   69 10       ADC   #$10
? A-41 X-01 Y-01 S-0140 P-38 ..-BD...
6010   D8          CLD
? A-41 X-01 Y-01 S-0140 P-30 ..-B....
6011   4C 17 60    JMP   $6017
? A-41 X-01 Y-01 S-0140 P-30 ..-B....
6017   20 15 60    JSR   $6015
? A-41 X-01 Y-01 S-013E P-30 ..-B....
6015   EA          NOP
? A-41 X-01 Y-01 S-013E P-30 ..-B....
6016   60          RTS
? A-41 X-01 Y-01 S-0140 P-30 ..-B....
601A   A9 28       LDA   #$28


As part of my testing I modified the code to stay in trace mode and ran the Woz monitor and Apple BASIC under the trace code. They executed correctly, although a little slower than normal.

The code supports 65C02 instructions without any extra coding except the BBR and BBS commands which would need some additional branch instruction support. Some 65816 instructions should work but the new instructions which change flow of control would fail and it doesn't understand the variable length of instructions depending on the CPU mode (but it would be quite straightforward to add).

This new trace function should prove useful for debugging future code I write. As always, the code can be found here.