Search the Community

Hello! During the preservation phase, I stumbled upon this beautiful version of the famous arcade game, Nibbler. It has been published on an Italian Magazine in 1985 and it is written purely for the Mini Memory cartridge and consists of two parts, the first loaded using option 2 EasyBug and the second loaded by TI-BASIC but through the instruction CALL LINK ("LOAD"). It would be really nice to save everything in a digital format more usable than the .WAVs files. I tried to load them with the MAME/MESS emulator and they work fine. In my opinion it's a beautiful version and deserves to be played by everyone in an easy way. I never thought that with the Mini Memory cartridge you could get such a complete game loaded from a cassette tape. I am really surprised. is there in the community someone that would have the ability to convert it to a better format, maybe .BIN or at least, a disk format? Could be nice! There are the link to the game page and the .ZIP file containing the material that I was be able to put together. Page: https://www.ti99iuc.it/web/index.php?pageid=database_cerca&archivioid=883 Download: (Ita)-(Game)-(Snake Snake)-(1985)-(MM)-(by M.M.G. Software)-(from TI99NewSoft).zip

As discussed a little yesterday in the Pandemic club 4A zoom call (thanks for the interesting discussion!) I started to look a bit how the GPL interpreter could be optimised. My original idea was to add some instructions to my FPGA processor core to speed up the interpretation with special purpose instructions, but as I started to look at the code it's quite clear that a lot can be achieved with normal code optimisation. @RXB mentioned that there has been a discussion with @Tursi about this topic. I somehow recall seeing that thread myself, but couldn't easily find it (which is probably my fault). As an obvious optimisation, instead of the multiple levels of tables, the GPL instruction decoding could be improved at the cost of using some more memory simply by having a 256 entry lookup table (occupying 512 bytes). For that part I could create a new instruction which could combine a few TMS9900 instructions, in pseudo code: // Address 0x78 MOVB *R13,R9 JGPL @TABLE,R9 // Here JGPL would be a new instuction, something like below. // The instruction would only perform 2 memory fetches: Read R9, and fetch the jump vector from TABLE. BANK 1 // Switch bottom 8K to a new bank, which has the jump table MOV R9,TEMP // Temp internal register SRL TEMP,7 // TEMP >> 7, shift to a word index MOV @TABLE(TEMP),TEMP // Fetch from table BANK 0 // Switch bottom 8K to normal bank B *TEMP In the arrangement above since the opcode would be passed to the new instruction JGPL, that instruction could also be developed further to understand some GPL instructions directly, executing them directly by the CPU instead of TMS9900. Many GPL instructions are quite involved, so it would best to be able to incrementally improve things, for example starting with branch instructions which seem to be rather simple. I also realised that I am jumping the gun - I should try to look at some GPL code before going to optimization phase to understand how things work. To that end I started using xga99.py to assemble the GPL code for Minimemory cartridge, as a test. Also since I think this a very cool cartridge which could be integrated and expanded in interesting ways in both my icy99 and StrangeCart projects. So I got the GPL source code for Minimemory from Thierry's excellent TI-99/4A tech pages. I guess that code is for his GPL assembler. But I wanted to use the xdt99 package. So I started to assemble the source with xga99.py, like so: xga99.py --aorg 6000 mmg.gpl -L mmg.lst I quite quickly ran into a few problems, due to differences in syntax, for example: The AORG directive in xdt99 does not accept addresses higher than 8K. This causes a number of problems, because there is a hole in the code, i.e. it AORGs to >70AC skipping a bunch of bytes. I guess I have to manually fill that range with some bytes. The multiplication instruction in the source is MPY, but xga99 uses MUL. Not a biggie. Many lines in the code contain comments (which is great) after the code. I have never understood why the comments don't start with a special character like semicolon or something, that would make parsing easier for the assembler and it could probably also prevent some mistakes. Anyway, xga99 could not assemble a number of lines because the comments were separated by just a space. I just removed those comments after the code (by moving them to a separate comment line). The HTEX instruction (in a FMT block) escapes hex bytes differently, simple change: from HTEX '[>0A]' to HTEX >0A Some other opcodes also are different: CAR -> CARRY, PARS -> PARSE, DCGTE -> DCGT The source code uses the BIAS command also outside a FMT - FEND block, it appears to specify a constant to be added to strings specified with the STRI directive. The source I used has first BIAS >60 to set the TI Basic character code offset. I did not find a way to replicate this functionality in xda99. The advice goes: "use the source, Luke". And so I did, and created a new directive STRI60 for xda99, as follows. It's hack for sure, but I didn't want to enter the text as BYTE statements. * Original source (disassembled and commented by Thierry) BIAS >60 G6E1A STRI "ILLEGAL TAG" G6E26 STRI "CHECKSUM ERROR" ---------------------------------- * Modified source for xda99: *EPEP BIAS >60 G6E1A STRI60 "ILLEGAL TAG" G6E26 STRI60 "CHECKSUM ERROR ---------------------------------- * xda99.py has been modified to support the new STRI60 as follows: # EP 2020-12-13 added new STRI60 operation to add the screen offset to each byte. # Used for Mini Memory porting @staticmethod def STRI60(asm, label, ops): asm.process_label(label) text = ''.join(asm.parser.text(op) for op in ops) asm.emit(len(text), *[ord(c)+0x60 for c in text]) And this is roughly where I am at the moment. I am comparing the generated GPL binary image to the original, and now the first >770 bytes match (except for the pointer to >70AC due the AORG stuff, need to come up with a solution for that - probably I'll just fill in the empty range with some bytes) to get to 70AC.