BillG

Apple II and C64 have routines to call for reading and writing characters. CP/M and DOS (PC, MS, ST) offer system call functions to write, read and determine whether a character is available.

Thanks. Are those memory-mapped I/O where just the read or write is sufficient to accomplish the operation or is something else needed to trigger an input or output?

What I intended to say and failed to make clear is that many other platforms offer simple system calls to read and write characters teletype-style. A beginner should not have to learn the intricacies of a CRT controller or video memory access to start writing a text game with a simple user interface. The whole story is that Paul (one of the original authors of Parsec) wanted me to target the 9900 with my Python compiler. I had determined that a clone of the Space Voyage game was complex enough to get a real feel for developing using the instruction set of a platform without making a huge investment in time. My project scheduling is akin to the ready list in a multitasking operating system; I pick one out of many which 1) appears interesting and challenging at the moment 2) shows potential for immediate progress, that is, no large unresolved blocking issues 3) provides some kind of lasting value 4) captures the interest of others Unfortunately, Space Voyage 9900 has not been chosen in a long while, hence "stalled."

I second much of what Airshack said here: Unlike many other platforms, the 99/4A woefully lacks a simple way to read and write a character. One of my many projects is Space Voyage Everywhere. I start with the Space Voyage game for the SWTPC 6800 and paraphrase it to run on other processors. Phase one is just getting it to work and a future phase two will be making it use the strengths of the host platform. So far, I have it working on the following processors: 6800 6809 6502 8080 AVR 68000 The 9900 implementation has stalled here: https://talk.dallasmakerspace.org/t/project-log-python-on-the-6502-c64-8080-6800-6809-and-avr/18852/282

I should probably warn you that the wiki writeup on Double Dabble is neither very clear or very optimal. It is oriented toward someone writing conversion code in a high-level language. There are two ways to convert a number from one base to another. The obvious and most intuitive method is to repeatedly divide the number to be converted by the destination radix to extract digits. But it is the slowest due to the many division operations required. A better way is to take each "digit" of the number from high to low, multiply the accumulated resultant number (initially 0) by the source radix then add in the new digit. Note that these operations must be done in the destination radix. For example, 9 is 1001 in binary. It can be viewed as 1 x 8 + 0 x 4 + 0 x 2 + 1 x 1 So you take the highest bit of the number to be converted and add to the resultant number (initially 0) yielding 1. Then multiply it by 2 yielding 2 and add the next highest bit of the number to be converted yielding 2. And then multiply it by 2 yielding 4 and add the next highest bit of the number to be converted yielding 4. Finally multiply it by 2 yielding 8 and add the lowest bit yielding 9. Double Dabble is an implementation of the second approach but shifts the number left instead of multiplying by 2. All of that fiddling about testing groups of bits and adding a correction factor is nothing more than what is known as "decimal adjust" on hardware supporting it. Unfortunately, the 9900 does not have decimal adjust so you will have to do it. More discussion and implementation for some common microprocessors can be found at: https://talk.dallasmakerspace.org/t/project-log-python-on-the-6502-c64-8080-6800-6809-and-avr/18852/364

This is probably years away from my being able to produce actual performance numbers, but I thought I would throw it out there. Many trips around the sun ago, I joined a makerspace where I experimented with the Arduino and began to learn Python. I thought Arduino is popular and Python is popular. Why can't we program an Arduino in Python?" I set out to implement a Python compiler. Yes, a compiler. By not requiring an interpreter implementing the entire language, we have a fighting chance to get some programs to run on the microcontroller of the Arduino. Initially, I had concerns around the 2K bytes of RAM in the Arduino. Because a Commodore 128 was on display at the makerspace available for me to use, I chose the 6502 as the initial target. Some arm twisting from a friend wanting me to target the 9900 brought me to this forum where I discovered the Sevens problem. Solving it requires: * multiplying a large number by 7 * converting the number to ASCII decimal * searching for "777777" in the string all of which are built into the Python language. Meaning that I can write the critical parts in assembly language as part of the run-time library, something I cannot do in most other languages. Python has the potential to provide the fastest high-level language solution of the Sevens problem, so I thought. The Python code would be merely be the "glue" tying these parts together. number = 1 power=0 string="" while string.find("777777") < 0: number = number * 7 power = power + 1 string = str(number) print('Seven to the power of', power, 'is', string) When I got to the point where I was able to compile and run this program, disappointment set in. It crawled. Analysis showed the vast majority of the time was spent in the int function which converted a number to a string representation. I had initially chosen to implement the obvious approach - dividing the number by 10 to extract each digit. The divisions were killing me. Some research turned up the Double Dabble algorithm to avoid dividing: https://en.wikipedia.org/wiki/Double_dabble I finally got around to reimplementing the faster conversion and got a greatly improved time, going from over 22 billion CPU cycles to a little over 90 million. An Apple II would take just over 90 seconds to find the solution. I do not know enough to even guess how fast something like this would run on the 9900. https://talk.dallasmakerspace.org/t/project-log-python-on-the-6502-c64-8080-6800-6809-and-avr/18852/363 In parallel, I experimented with the different approach of performing the calculation in BCD to avoid having to do the conversion. My best solution along those lines is using the Borland dialect of Pascal, doing the arithmetic using unpacked BCD stored in a string, marching a pchar pointer through the string for fast "indexing" and using pos to look for six consecutive bytes of binary 7 in the string. It completes almost instantaneously on my relatively slow netbook. Unless there is a 9900 Pascal compiler supporting pchar, I cannot test this.

6502 is worse, with only 256 bytes max for the hardware stack. If it was only for personal use, I would not worry about UCSD copyrights. But if I have any intent of someone else adopting it, I choose things already in the public domain like FLEX and LUCIDATA. And CP/M, though technically still copyrighted, is essentially public domain unless I am trying to make money selling copies of it.

I found some of those Heath newsletters. There was mention of a program to convert a P-code program to assembly language. As far as I know, nothing like that was ever available for FLEX. I steered away from UCSD for one huge reason - it is still under copyright. I would hate to spend a bunch of time on something then get a cease and desist to stop using it. That plus it lived in its own world and there was no way to run "foreign" programs.

That is why I chose to spend so much time developing programs for FLEX - to help finalizing the memory map.

The 6801/6803 places internal registers at $0000..$001F In general, FLEX programmers are not aware of this. It is very easy to type "org 0" or just let the assembler default to 0. The TSC assembler and BASIC intepreters do not load anything below $0020 but I am not familiar enough with them to be able to say whether they use that area for variables.

DOS/65 is a CP/M clone for the 6502. http://www.z80.eu/dos65.html

I'm sorry, I have not been monitoring this forum lately. The original prototype has been redone with what I hope is the final memory layout. The documented "interface" portions of the API have been moved from $200 and up to $800 and up to open the possibility of running it on Apple II family hardware. I am finalizing the design of the background printing feature as several of the utilities hook into it though I do not currently have a way to test it. Also in the works is an option to put much of the operating system in ROM, primarily for homebrew systems with only 32K of RAM. I am also prototyping several "advanced" features: The notion of a "current" drive like in CP/M or DOS to work with the FLEX working drive concept. This is complete except for changes to the ASN utility to toggle the feature on and off as well as some small modifications related to program file search. A hierarchical directory structure. HIER was an add-on program which did this with 6809 FLEX. A simplistic command history capability. A reloadable disk driver interface so that frequently used commands can be made "resident" in memory or to implement fast temporary storage. I have also been working on several tangents to increase the software base: A 6502 version of the LUCIDATA Pascal run-time system to allow running compiled programs and hopefully the compiler itself. This is pretty much complete except for the ability to run the compiler. An emulator to allow running 6800 FLEX programs on the 6502. This was barely started before I ran into several issues requiring more study. I am ready to resume work on this. An emulator to allow running 8080 CP/M programs on the 6502. This is about half done while I deal with some issues surrounding simulating the CP/M file system with FLEX FMS. A method to convert a Turbo Pascal program compiled for a Z80 into one which can run on an 8080. This is about 75% complete and was largely done to support the 8080 CP/M emulator. I do not foresee being able to actually run CP/M Turbo Pascal on the 6502 any time soon though that is a possibility down the road.

Memory in both the 6800 and 6809 versions of FLEX was pretty tight, so they probably leaned a bit toward smaller rather than faster code.

Surprisingly, there is apparently no entry for the TMS9900 or 99/4A... http://www.99-bottles-of-beer.net/t.html

This is a bit of a tangent, but... I have been working on a 8080 simulator to allow running CP/M programs on the 680x and 65[x]02. One of the posters on the forum at 6502.org said he is interested in what I am doing because he was "collecting languages" on his Apple II. Turbo Pascal was one of the compilers he mentioned; he did not say he had a Z80 card. That reminded me of my discovery long ago that Turbo Pascal for CP/M required a Z80 processor, both for running the compiler as well as for the programs it generated. I went back to MT+ or assembly language for things needing to run on an 8080 or 8085. But I also briefly considered trying to modify Turbo Pascal to generate 8080 programs; that effort did not go very far as programming on the then new IBM PC took up more of my time. I took a closer look at the CP/M version of Turbo Pascal after that discussion. I have since disassembled most of the run-time library and commented much of it. I still believe that creating a version of the compiler to run on an 8080 system is not feasible, but it now seems very doable to: * write an 8080 version of the run-time library * write a post-compiler to translate Z80 code generated by the compiler to 8080 assembly language * write a tool to stitch the two together If that can be done, it is not a huge stretch to * write enough of a Z80 simulator to run the Turbo Pascal compiler on processor X * write a version of the run-time library for processor X * write a version of a converter to translate Z80 code to processor X I believe this can be done with substantially less effort than writing a new Turbo compatible compiler to run natively on processor X