Writing some games for the DEMO board. Converting my old TRS-80 stuff....

RobotWorkshop

Hello,

I have a Propeller DEMO board built up and working well on a protoboard and have been really impressed with some of the DEMO's for it. Now, I want to learn a bit more on the software side and think that converting some of my old games might help me get familiar with it. Back in the early 80's I had written a bunch of arcade games for the TRS-80 Model I, III, and 4 systems. They were all written in z-80 assembly for speed since BASIC was too slow for what I wanted to do. If anyone here has been using one of the TRS-80 emulators there is a chance you've seen some of my old programs. Some of the ones that were popular were: Chopper Defense, Kaboom, and Clock-80. There were others that were almost complete like Time Pilot and RoboTron but by the time those were almost ready the TRS-80 tanked as people switched to color systems. I've dug up my old source code and have it on the PC. For nostalgia i'd like to convert them to a newer platform and learn a bit along the way.... Since most of the games would easily run on a 16K system I expect I could squeeze them on the propeller DEMO board.

I'm thinking about buying Andre’ LaMothe's book on the Hydra to help get familiar with propeller program which may aid in the conversion process.

I've seen a few posts from people that had used the TRS-80 systems and was curious if anyone has already done some conversions or even looked to see if perhaps some of the instructions and registers could will map out well so that most of the conversion work would focus on the input device (mouse or Keyboard) and the graphics.

Any suggestions on where to start?

Robert

AndreL

The Z80 and Propeller are completely alien architectures, the Z80 is a very CISC processor with rich instructions, strings, stack, etc. the propeller is a very stripped down RISC processor, so the best way to approach it is to write a Z80 emulator in ASM and stream the instructions from main memory, the instruction set in the propeller is very powerful, so most instructions you will be able to process nearly directly, but others with take 3-10 to get things done and moved in and out due to the lack of direct addressing the propeller has for asm, you have to use self modifying code to access tables for example, you can't just use a base and offset and so forth. But, the cool thing is that everything is 32-bit so it wil make lots of calcs easier since you don't have to use multibyte computation, it will all fit in the cog. And of course, there is no support for interrupts, this is a biggie, so you have to run a cog at full speed and have it poll the interrupt lines (or virtual lines) then transfer to your ISRs which then have to re-run the emulator, blah blah. Lastly, you will probably need to use a large model or at least run half the emulator on one COG, half on another to fit the emulator in ASM, so that's an issue as well. Of course, you don't need to implement the whol Z80 instruction sets, I doubt if anyone uses more than 10-20% of all the instrucitons.

So lots of fun things to figure out [noparse]:)[/noparse] I suggest starting with the Z80 emulaiton then from there implement the graphics mode and keyboard I/O of the trs-80, those two things would be a good place to start. So step one would be to create a Z80 memory map, at least the begining of one then put some opcodes in there and start working on getting the emulator to reset propeller, model the IP, status, flags, etc. and then just work on each instruction implmentation as you would any emulator. I find writing them in C first always helps the conversion process, rather doing it directly in Asm, that way you can get your game plan thought out.

Andre'

RobotWorkshop

Thanks for the suggestions. I guess I can either approach it from the emulation standpoint or I can just use my existing algorithms and re-write them in Spin and Assembly.

As far as the memory map of the TRS-80 goes I pretty much have the most important aspects of that burned in my brain forever! Most of my programs dealt with the hardware directly as the Screen memory 3C00-3FFF and keyboard mapped was pretty much the same. They just changed the # of interrupts per second on the Model I and 3 and also switched from memory mapped I/O on the Model I to I/O based on the Model III & 4 systems. Ahh.. Those were the days!

FYI. I just ordered your book and hopefully it will help things along.

Best Regards,

Robert

Dennis Ferron

RobotWorkshop said...

As far as the memory map of the TRS-80 goes I pretty much have the most important aspects of that burned in my brain forever! Most of my programs dealt with the hardware directly as the Screen memory 3C00-3FFF and keyboard mapped was pretty much the same.

Lol, I know what you mean. In high school I read a book that revealed that "B800" is the segment address of CGA video memory on DOS machines. That one number "changed my life": instead of being chained to the clunky graphics interfaces that came with my Basic and C compilers, it meant I could now write my own graphics drivers and "real" games.

JoannaK

Hmm.. Call -151 .. Definitely

potatohead

I know this is a bit off topic. Feel free to move this, but I just gotta post this history here.

http://www.llamasoft.co.uk/lshistory1.php

This is the history of Jeff Minter, author of a lot of early games. This is his discovery process and is an excellent and compelling read, appropriate to the propeller, IMHO. Many of us will experience these same things, in the context of the prop.

(I know I am!)

The realization of what screen memory is, and the implications of that is one of the most fun and profound moments in anyones computing experience. For the prop, it's like this, only we are now getting to experience multi-processing in that same readly accessable way. Like screen memory, the implications will take a while!

Enjoy, and don't run into happy fun memory land too quickly!

BTW: Somebody should send Jeff one of these things. I'll bet the code returned would be well worth the gift --if we could get his attention. A single mention of this device from this guy will bring lots of people to the platform.

(I'm gonna send him a link to some prop stuff, just for the heck of it.)

RobotWorkshop

Back in the 80's it sure was a learning experience originally writting a lot of the games originally. I wasn't happy with the way that some of the early TRS-80 games had graphics that flickered on the screen and I wanted smooth animation. I think a lot of it stemed from the way others cleared the screen and painted it on the fly. I just kept a virtual screen buffer in RAM that I could clear and then build up my screen image. It was also cool since I took a layered approach and could check to see it any pixels were lit in place of new ones I was laying down on top of them. Once done the nice block move instructions like LDIR would send the while image to screen memory quickly. Since the real screen memory was never cleared it didn't flicker. Didn't matter if a pixel or the whole screen changed. It all looked good.

It will be interesting to read the Hydra book when it comes in and see how others are writing for the Propeller.

Robert