Jump to content

palmheads

Members
  • Posts

    216
  • Joined

  • Last visited

Posts posted by palmheads

  1.  

    Nope, the entire program will have to fit in 760 bytes :) That's my goal. While it sounds like a minuscule amount of memory, assembly language can be pretty efficient and compact and so you can do a surprising amount with that. As I had stated earlier, it does force you to get into a different mindset than when you are programming under the EA environment, and that's the attraction for me. We shall see if I can overcome that challenge in the end!

     

    Thats gonna be impressive!

     

    Some quite good games were developed for the 1k ZX81 like the still talked about 1k chess -

  2. MM and LBLA workflow not as bad as anticipated surprisingly. I'm not yet sure if the project I have in mind will fit in 760 bytes, but so far it's looking promising. The trick for me is to try and break up the program into as many small independently testable routines as possible which would be easy to debug and edit without too much retyping. Once they are certified to work, then I can later roll them directly into the main program. I have a decent library of assembly routines I have accumulated through my previous work to achieve various things, but the challenge has been to creatively modify them so they fit better within the memory constraints I am working with, and in a way I found that to be quite fun. Weird...

     

    So what do you think the next step(s) would be? Once you've filled that 760 bytes, do you save that chunk of code as a reloadable data source, then start again on a new chunk of code? So you might end up with (say) 4 chunks of 760 bytes that you load up that you then piece together with CALL LINK in TI-BASIC?. Or do you take all the opcodes & end up combining them all in a bunch of DATA/CALL LOAD (ie POKE) TI-BASIC commands until you filled as much of the 4k MM as possible?

     

    Always wondered how you could fill the 4k with LBLA.

  3.  

    Interesting. I'll take a look at them. Thanks!

     

    No problem! Always thought these 2 TI-BASIC utils, and LBLA, would have been a reasonably effective development package (given obvious limitations)

     

    99ner mags that describe usage are:

    http://www.mainbyte.com/ti99/micro/go99.asp?search_string=&type99=Assembly+Language&Send=Search

     

    Mini Memory Relocator - ftp://whtech.com/magazines/99er/99er8305.pdf

    Mini Memory Disassembler Utility - ftp://whtech.com/magazines/99er/99er8303.pdf

  4. So this MM thing really requires a much tighter level of thinking... Yesterday I spent a couple of hours trying to figure out why my test program was not working, only to finally find out that the LBLA symbol table only has room for 10 entries (40 bytes) starting at >7CD8 and it was overwriting the start of my program at the default >7D00 as I had 12 labels it it... Nothing a judiciously placed AORG can't solve, but I never had to worry about such issues with the EA despite writing some sizable programs like SkyChart for example. Effectively I was spoiled rotten!

    Now I have to really be careful in minimizing the use of labels because at 4 bytes per label they are expensive in memory!!!

    The good news is that I'm starting to get the hang of using the MM and LBLA :) That said, even though I am putting everything on paper, I am still cheating a bit by copying and pasting into Classic99 for testing purposes. Last night I typed in my routines on the real thing and saved them to tape, but it only worked if I saved the entire 4K of the MM (>7000 to >7FFF) which is just fine because when I reload, then the LBLA will be back in memory. Oh and by the way the battery in my MM is dead, so I have no backup and I need to open it up and replace it....

    Onward and upward :)

     

    Dunno if it might help, but have got copies of 2 TI-BASIC utils that a Marty Knoll did for the MM cart. One is a TI-BASIC disassembler, the other one is a MM mem relocator (shifting code around to get over the lack of memory)

     

    99ER2-5.DSK - MMDISASM_M

    99ER2-7.DSK - MEMRELOC_M

    99ER2-7.DSK

    99ER2-5.DSK

  5. Sounds like a great idea!

     

    Having MM/4k limit is perfect. There really was only a handful of games written for that platform that didn't require 32k as well (Entrapment, Defend the Cities II). Given the quality of games for other platforms with similar memory (eg: unexpanded Vic 20) always has felt like an unexplored environment.

     

    And like you say, given its limits, more achievable.

     

    I could even rip out some of my code from my stalled "Thrust" project to get something working.

     

    cheers

    Daryn

    • Like 1
  6. I reckon stick around. We are all different. For me, I love the combo of console & the mini-memory module. Most of my posts are about that combo. Just something that interests me. Wouldn't expect many people to be overally excited at that combination (ha!), but am sure some people searching for info on the TI might find info related to that interesting.

     

    Reckon just do stuff 'cos it interests you. Noone will think down on you for doing that.

     

    One of the quirky things about the TI is that you could actually do that. Console only, console + mini mem, console + ext basic, console with 32k, peb etc etc and now with nanoPebs/finalGroms etc

    • Like 3
  7. Think its really cool showing what you can do with TI-BASIC.

     

    Was looking at one of the old 99ner mags, and its got an article about using TI-BASIC with mini memory module.

     

    ftp://whtech.com/magazines/99er/99er8309.pdf

     

    Its actually a light racer game using PEEKV, POKEV to get faster responses from the VDP.

     

    Totally breaks the console only concept, but if you wanted to keep the TI-BASIC theme could be quite neat using the TI-BASIC extensions that the mini memory module gave.

     

    The article is called Byte Lightning. The actual game is on this attached disk

    OLD DSK1.MMLIGHTRCR
    RUN
    

    MMProgs.dsk

  8. This is interesting - Looks like someone in Australia (Ross Mudie) back in 1989 had an additional hardware/software solution that used the Joytalk RS-232 (output only) printer interface

     

    ftp://ftp.whtech.com/user%20groups/Sydney%20Australia/TIsHUG-1989-06.pdf(pg 7/8)

     

     

    Ross also brought along a serial to parallel conversion for his very interesting Joy Talk printer interface. This piece of hardware, together with software written by Ross, can be used as an economical printer interface (requires Extended BASIC and 32K).

  9. Ok think I have the answer. It definitely is the mini memory version.

     

    I actually used the mini memory TI-BASIC disassembler and put in a memory location near the end of the 7000-7FFF span of the mini-memory RAM.

     

    So chose looking at TEXT statements between 7EEE-7FFF. See attached

     

    post-40572-0-08652700-1504602057_thumb.png

     

    Thats actually really cool!

     

    cheers

    Daryn

     

     

  10.  

    Taken from gamebase ... ;)

     

    attachicon.gifdefend.dsk

     

    Cartridge: Editor/Assembler, Load and run, File name: DSK1.DEFCITIES, Program name: DC

     

    defcities.gif

     

    Hmmm this is actually really interesting...

     

    I know for a fact that there are 2 versions of this game

    • Defend the Cities - Extended Basic version
    • Defend the Cities II - Mini Memory/Assembly version

    For the attached disk above, in js99'er I was able to turn off the 32K expansion, load up the Mini memory module and "Load and Run" using DSK1.DEFCITIES and DC.

     

    I could also see opcodes in the 7d00 range that the Mini Memory (I believe) uses.

     

    Does this mean that this version attached to the DSK could in fact the Defend the Cities II?

     

    cheers

    Daryn

  11. Yeah even back in the day alot of Pseudo hires games were developed for the ZX81. Some of the more famous ones were Forty Niner, Rocketman etc.

     

    From what I understand, effectively the ZX81 display is software based - a display file is written. Some clever clogs figured out you can effectively rewrite that display file yourself (with limitations).

     

    Some formatting issues, but this page is really comprehensive explaining the techniques

     

    http://www.user.dccnet.com/wrigter/index_files/ZX%20Video%20Tutorial.htm

     

    Also this

    http://www.pictureviewerpro.com/hosting/zx81/download/zx81/highres.txt

×
×
  • Create New...