Recently, it occured to me that there are other machines out there that use the Z80 microprocessor and the Z80 assembly language. While it is outside my personal scope to do so, I was wondering if anyone here could examine a few examples of other Z80-based source code and identify the closest to our own TIASM Z80.

The goal of all this is to determine if it is at all possible to either port TIASM programs to other Z80 computers, or if at all possible, to understand the differences between TIASM and another machine, and create a lightweight shell allowing TIASM programs to run on a foreign machine, such as a TRS-80 or ZX Spectrum. It is my understanding that a lightweight shell would be well within the realm of possibility, needing to emulate or approximate things like TIOS ROM calls, graphical instructions, and memory access.

However, should all this be possible, we'll be providing a massive new library to microcomputer enthusiasts and possibly facilitating the use of Doors CS7 on old machines, and with some clever serial hijacking, the possibility of running calcnet-enabled programs.

ZX Spectrum source:
http://99-bottles-of-beer.net/language-assembler-(z80)-813.html

I couldn't find any examples of TRS-80 code, but it shoudn't be too hard to dig up. I didn't look for very long.

The biggest problem would be emulation (or cross-assembling) of hardware aspects of each device. For example, the TI-83+ display is connected and manipulated by poking bytes in and out of a set of ports, whereas many devices (including the Spectrum?) use a memory-mapped display. The keyboard port is similarly different, as is the necessary mapping between RAM/ROM addresses on the TI-83+ and the native machine that would have to be made. Sadly, in the end you'd probably essentially end up with an emulator, which might be verrrry slow.

Still, it's possible. We might be able to do it if we were able to re-compile TIASM source code in a TRS-80 or Spectrum compiler. Of course this would cut out a great, great many of TIASM programs that were written years ago and the source for never released, but it's still something. A shell would still likely be required but at least we would be able to make them use the graphical outputs of the system we port it to, but at this point we're porting programs rather than running them directly, which is still fine by me.

If programs only used iFastCopy for screen-writing and only used calls for input, automatic porting is potentially possible. However, I'd imagine that that describes relatively few modern ASM programs, which would then require manual porting. Not that I think manual porting wouldn't actually be really cool!

I think it would, too. Should this see any headway at all, I would seriously consider buying an actual machine. I've always been partial to that sort of thing.

Then again, a combination of automated porting and a shell might be very possible. Just as Doors CS has its own graphical libraries, we could treat the TIOS graphical calls as library functions and approximate their effects (such as instead of pushing bits to a port on a call, it's pushed to a memory-mapped location) and use that sort of technique combined with some light source modification to come up with a lightweight shell that provides the basic functionality to run some TIOS programs.

I don't think you'd get great results with automated porting - the TI is quite far removed from a "typical" Z80 machine (lots of RAM and ROM, a very small bitmapped display and a keypad instead of a keyboard or joystick). I did have some luck porting Gemini to the Sega Game Gear, however, though I couldn't get objects (for enemies and the like) to work.

That is very, very impressive. Automated porting would be little more than automated find-and-replace for a few specific commands and such. It would still require the actual source code to work and to be recompiled under an actual TRS-80 or ZX Spectrum compiler. The rest (such as ROM/RAM access, and controlling the screen outputs, ect) would be handled by the shell, not unlike the libraries Doors CS7 provides. Things like the keypad would have to be remapped to the user's likings within the shell's settings.

Part of the issue is that a lot of TI Z80 programs are tailored specifically for the TI OS. They oftentimes make assumptions as to where certain routines are, where safe RAM is, and how the screen and keyboard work on a low level. If a program didn't use any memory outside of its own memory space, and doesn't touch the out and in functions, and only use B_CALL, then there's a chance that automated conversion would work. That is a lot of ifs, though, and I'm sure that any game out there uses direct keypad reading, which would be a pain to translate. Some programs also assume the speed of the CPU, and timing issues could occur.

I highly doubt that there could be an "easy" TI Z80 converter. You'd get unparalleled conversion quality to just learn about the target and do it by hand.

Again, you're not listening to everything I'm saying.

A quick and dirty automated conversion is not the be-all end-all of my suggestions and will never work completely on its own.

This is to be combined with a shell, like Doors, that includes libraries of identically-named functions and calls to what exists in the TIOS but tailored to the system it is made for. For example, you have a draw() function that turns a single pixel on. In TIOS, this pushes a value to a port to draw it to the screen. The ZX Spectrum does not work this way, having a memory-mapped display. The idea for cases like this theoretical draw() function is that you take the source code for the program you have that references draw(), and you compile it in a ZX Spectrum Z80 compiler. This program will then be run from within our theoretical shell, which has a library that includes an identically named draw() function of its own, that has the same end result, but instead of pushing a value to a port like TIOS, this pushes a value to a point in the memory.

So you're saying that someone should create a standard compatibility layer interface such that any program written for it can be run on any Z80 machine with the runtime?

But what about awesome people that don't use any TIOS calls and directly access the hardware and have algorithms that exclusively depend on the hardware, not the software? You will have to rewrite the entire program since the environment that the binary runs in is completely foreign.

The problem is that very, very few programs rely entirely on calls and bcalls instead of manually manipulating memory and ports, because it's extremely slow. Therefore, very, very few programs would work in this system with no modification.

I think that he's basically saying that a standard library should be programmed and ported to a ton of Z80 targets, so that we can have cross compatibility for programs written for the libraries in the same way which C is cross compatible. Just reassemble and link for the other target, and it should run. Maybe use some #ifdef tricks for choosing logical things like key mappings. The idea is cute, but kind of pointless in my opinion. Z80 based machines are too specific to their respective communities, and there isn't much overlap like there is in the world of personal computers.

Most of the reason why people write ASM for TI calculators anyway is to squeeze as much speed out of it as they can; a standard library would only serve to inhibit any speed gains made, but your headache from the assembly wouldn't be any smaller.