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

Comments

• AndreL Posts: 1,004

  2007-02-19 21:39 edited 2007-02-19 21:39

  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 Posts: 2,307

  2007-02-19 21:55 edited 2007-02-19 21:55

  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 Posts: 480

  2007-02-20 04:32 edited 2007-02-20 04:32

  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 Posts: 44

  2007-02-20 04:57 edited 2007-02-20 04:57

  Hmm.. Call -151 .. Definitely
• potatohead Posts: 10,254

  2007-02-20 07:03 edited 2007-02-20 07:03

  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 Posts: 2,307

  2007-02-20 16:35 edited 2007-02-20 16:35

  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