14 replies to this topic

[Official Ninja]

I want to play this game. I got it from the TI-99 Game Shelf web site:
http://tigameshelf.net/asm.htm

Here is the file: http://tigameshelf.n...mu/Labyrnth.dsk

I transfered the image to a disk and trying to play on real hardware.
(Something I do all the time using ti99-pc)

This is what the description says:

Requirements: Editor/Assembler cartridge, 32K RAM, disk drive. Joysticks optional.
Executable to run: LABC (E/A Option 5)

I tried that but it did not work.

Can anyone give my some instructions on how to get this running?

[sometimes99er]

DSK1.LABYRINTHC (E/A Option 5)

[Official Ninja]

Thanks! I got it working. I hadn't used any games that didn't auto boot to some kind of menu in a long time...
I had forgotten how to use the E/A cart.

[sometimes99er]

Back in the day it was CS1 for me. MINIMEM for a bit of fun (I guess I was more of XB then). Checking up on the name (MINIMEM), I see EXPMEM2 also. I don't think I ever tried that one (yes, I had the standalone Memory Expansion).

Now, having an assembler program with a code size of less than 8K, what are the loading and ready to run main differences between XB, EA3 and EA5 ? Does XB only take EA3 ? What is the best way to supply for people wanting to try out on the real deal ? I guess the 8K binary cartridge is almost out of the question ?

[Lee Stewart]

I'm not sure I completely understand your question and you probably know a lot of this: I am not totally sure about XB's loader; but, EA3 loads object files, compressed or not, and runs them if the END statement has a label after it that matches a label in the program. Otherwise, you have to know the name of the routine to give to EA to start the program. XB's loader cannot load compressed object files. EA5 loads memory image files of 8K or less that have been saved with EA's SAVE utility. In the EA manual (available in pinned topic, "TI-99/4A development resources"), page 410ff., there is information about the differences between the EA and XB loaders. One major difference is the memory map for loading assembly language programs. Since XB wants to load assembly object code at >2000 of CPU RAM and that is where EA puts its loader, you could probably write a loader for XB to put there to do the dirty work. Someone has surely done that (or something like that) already. Anyway, I'm at the edge of my understanding with this. I hope this, at least, gets you farther along the path you are headed.

...lee

[Ksarul]

Actually, the 8K binary cartridge is probably a very good option, as we now have cartridge boards available to put them on (and some of those will take up to 512K in 8K bank-switched mode).

[sometimes99er]

Thank you guys, and sorry for hijacking the thread. Yeah, it was probably a question about what people want to see, when they run assembler programs on the real deal. Would it be XB/EA3, EA3, EA5, DSK, TIFILES, 8K binary and/or ... I was originally aiming at EA5/TIFILES and 8K binary, but then thought XB/EA3 (of course with autoload) would be more "friendly" (hey, now related to the topic). Then I wondered about the generally 8K loading time difference between those, EA5 and XB/EA3. My own experience, mostly limited 1K effects, is that XB/EA3 is apparently very, very slow - but maybe "load and ready to run" isn't something real deal people care too much about ? Again, I'm emulation only.

[Willsy]

Yep - XB EA3 is MEGA slow. I don't know why. Maybe Rich or Tursi can shed some light on it.

Mark

[RXB]

Willsy, on Thu Sep 22, 2011 3:43 PM, said:

Yep - XB EA3 is MEGA slow. I don't know why. Maybe Rich or Tursi can shed some light on it.

Mark

Well this is the GPL code for EA3 Load and Run:

<0208> *
<0209> * Main Menu Option 3: LOAD AND RUN
<0210> *
<0211> E9E4 87,48 LANDR DCLR @FLAG
<0212> E9E6 B6,49,01 OR >01,@FLAG2
<0213> E9E9 07,20 ALL SPACE
<0214> E9EB 08 FMT
<0215> E9EC FF,08 COL 8
<0216> E9EE FE,00 ROW 0
<0217> E9F0 0F,2A,20 HTEX '* LOAD and RUN *'
E9F3 4C,4F,41
E9F6 44,20,61
E9F9 6E,64,20
E9FC 52,55,4E
E9FF 20,2A
<0218> EA01 89 COL+ 10
<0219> EA02 A1 ROW+ 2
<0220> EA03 09,46,49 HTEX 'FILE NAME?'
EA06 4C,45,20
EA09 4E,41,4D
EA0C 45,3F
<0221> EA0E FB FEND
<0222> EA0F 06,E6,BA CALL EXPMEM
<0223> EA12 B6,49,40 OR >40,@FLAG2
<0224> EA15 BE,A0,A2 GE7F2 ST SPACE,V@162
EA18 20
<0225> EA19 35,00,3B MOVE >003B,V@162,V@163
EA1C A0,A3,A0
EA1F A2
<0226> EA20 BF,20,00 DST 162,@CURADD
EA23 A2
<0227> EA24 B6,48,04 OR >04,@FLAG
<0228> EA27 BF,1C,10 DST >1000,@PABPTR
EA2A 00
<0229> EA2B 06,E5,1D CALL GETALL
<0230> EA2E 86,42 CLR @XTOKEN
<0231> EA30 8F,50 DCZ @FAC6
<0232> EA32 4A,3B BR GE816
<0233> EA34 06,ED,E2 CALL BINIT2
<0234> EA37 4A,59 BR RUN
<0235> EA39 4A,46 BR GE821
<0236> EA3B DA,49,40 GE816 CLOG >40,@FLAG2
<0237> EA3E 6A,46 BS GE821
<0238> EA40 06,ED,EA CALL BINIT3
<0239> EA43 B2,49,BF AND >BF,@FLAG2
<0240> EA46 BE,E0,01 GE821 ST >04,V@>0001(@PABPTR)
EA49 1C,04
<0241> EA4B BD,56,1C GE826 DST @PABPTR,@VPAB
<0242> EA4E A3,56,00 DADD >0009,@VPAB
EA51 09
<0243> EA52 0F,22 XML >22 ****** THIS LINE IS THE LINE THAT EXECUTES THE PROGRAM ******
<0244> EA54 6B,3F BS GE8B3
<0245> EA56 05,EA,15 B GE7F2
Now for XB the problem is the LOAD is just as small but the LINK routine is hundreds of lines of code.
I wrote EXECUTE for RXB as LINK in XB is just insane for all the things it does.
The RXB command EXECUTE just takes the CPU address and runs it.

[sometimes99er]

Thanks guys. I will then go EA5/TIFILES and 8K ROM Binary.

[Tursi]

EA#3 is slow because it has to convert each line from ASCII text to binary. Compressed EA#3 (not available to XB) is slightly faster because the conversion is easier. In addition, there's a tag before each byte that needs to be interpreted, and any DEF'd labels need to be stored, and REF'd labels looked up and resolved, and relocatable code needs to be relocated. In addition, no more than 80 bytes can be read at a time for parsing.

In the case of an EA#3 uncompressed file that doesn't need any fixups and only has absolute data, the best case, you still have a case where every byte written to memory takes a minimum of three bytes in the file (tag plus two bytes - the two bytes are a hexadecimal number which needs to be parsed). There's an additional overhead caused by reading one line at a time from the disk, and the header and trailer on each line wastes additional data space. A full uncompressed EA#3 file like this is only about 50-60% actual data (stored at two bytes per real byte!)

A program image (EA#5) is much faster because it's just a block of data. Up to 8k is read in a single pass, and there's no parsing, mapping, or relocation, it just gets copied into place.

[sometimes99er]

Thanks Tursi, excellent info. Even though only a handful of very patient people may run my programs, EA5 it has to be.

[RXB]

Tursi, on Fri Sep 23, 2011 2:20 AM, said:

EA#3 is slow because it has to convert each line from ASCII text to binary. Compressed EA#3 (not available to XB) is slightly faster because the conversion is easier. In addition, there's a tag before each byte that needs to be interpreted, and any DEF'd labels need to be stored, and REF'd labels looked up and resolved, and relocatable code needs to be relocated. In addition, no more than 80 bytes can be read at a time for parsing.

In the case of an EA#3 uncompressed file that doesn't need any fixups and only has absolute data, the best case, you still have a case where every byte written to memory takes a minimum of three bytes in the file (tag plus two bytes - the two bytes are a hexadecimal number which needs to be parsed). There's an additional overhead caused by reading one line at a time from the disk, and the header and trailer on each line wastes additional data space. A full uncompressed EA#3 file like this is only about 50-60% actual data (stored at two bytes per real byte!)

A program image (EA#5) is much faster because it's just a block of data. Up to 8k is read in a single pass, and there's no parsing, mapping, or relocation, it just gets copied into place.

I put BLOAD and BSAVE into RXB so you can take the lower 8K so once the EA program is loaded and save it as EA5 format for XB. I had a demo in RXB that loaded 28 banks of lower 8K from a Horizion RAMDisk into the SAMS memory banks and a single XB program used all of them. The loader of BLOAD is very fast. It loaded the 224K of Assembly in under a minute. I demoed this at the Salt Lake City fair. The demo had STAR, DUMP, WindyXB, XPD, and XPRAMDISK are the names I do remember but many more were used. Could not use TML as it messed up the VDP memory so impossible to load anything else but it, that question came up the most at the Demo.

[Willsy]

Tursi, on Fri Sep 23, 2011 2:20 AM, said:

EA#3 is slow because it has to convert each line from ASCII text to binary. Compressed EA#3 (not available to XB) is slightly faster because the conversion is easier. In addition, there's a tag before each byte that needs to be interpreted, and any DEF'd labels need to be stored, and REF'd labels looked up and resolved, and relocatable code needs to be relocated. In addition, no more than 80 bytes can be read at a time for parsing.

In the case of an EA#3 uncompressed file that doesn't need any fixups and only has absolute data, the best case, you still have a case where every byte written to memory takes a minimum of three bytes in the file (tag plus two bytes - the two bytes are a hexadecimal number which needs to be parsed). There's an additional overhead caused by reading one line at a time from the disk, and the header and trailer on each line wastes additional data space. A full uncompressed EA#3 file like this is only about 50-60% actual data (stored at two bytes per real byte!)

A program image (EA#5) is much faster because it's just a block of data. Up to 8k is read in a single pass, and there's no parsing, mapping, or relocation, it just gets copied into place.

Indeed, but the XB object loader is at least half the speed of the ea3 loader, maybe three to four times slower!

[RXB]

The XB loader is not Compressed Object code and that is 2 times slower. Add in XB checking more and you get 3 times slower.