Trying to learn TI programming

[Pheonix]

RXB: The VDP Buffer I set was >1B0C, When I did my DSRLNK 014 it changed to >4690.

 

Tursi: All I'm trying to do right now is read a file's parameters. Eventually, it is planned to load a PROGRAM file in chunks instead of all at once. The final program I'm writing is planned to run in bitmap mode, so the available buffer space in VDP RAM becomes rather limited. The error in the debugger log is "Incorrect file type: 1/DF0 (real) vs 0/DF0 (requested)". Changing the disk type from 2 to 3 also changes the log to:

 

Sector read: TICC drive 1, sector 1, VDP >38E3
Sector read: TICC drive 1, sector 5, VDP >37E3
Sector read: TICC drive 1, sector 3, VDP >37E3
Sector read: TICC drive 1, sector 4, VDP >37E3

 

Now results in the same unexpected values I got from MAME.

[+InsaneMultitasker]

Scanning through your latest posting I notice two things:

 

1. Your space padding routine won't pad anything as written. The MOVB instruction order is reversed; change to "MOVB R0,*R2+". Secondly, you'll want to adjust the filename length test to account for a filename that is 10 characters, otherwise your subtraction will result in 0, and your DEC R3 will not produce the EQ result you desire.

 

SRL R1,8
A R1,R2
S R1,R3
LI R0,>2000
PADNAM MOVB *R2+,R0
DEC R3
JNE PADNAM * PAD FILE NAME WITH SPACES (>20)

 

 

When you reserve workspace pointers, you should always account for 16 contiguous registers (32 bytes). The "BSS 18" directive reserves space for R0-R8 (18 bytes). The next five DATA statements account for R9-R13. You should also account for R14 and R15. Depending on how SLOAD is called, the command to set the workspace (LWPI LBNWS) may be overwritten. If that happens, your routine will run from the caller's workspace and R9-R13 will /not/ contain the values you expect.

 

LBNWS BSS 18
DATA >0001 * R9
DATA VDPADR * R10 (BY SETTING THESE HERE, MAIN PROGRAM)
DATA DSRCMD * R11 (CAN ALTER TO CORRECT VALUES EASIER)
DATA DSRLNK * R12
DATA GPLLNK * R13

DATA 0 R14

DATA 0 R15 (end of 32 byte block)

SLOAD LWPI LBNWS
LIMI 0

 

 

Nothing else immediately stands out. One thing you can do if you can't find the problem is to clear the code to its bare bones: remove all the parameter passing & manipulation and set the memory directly as you expect it. Then try the DSRLNK to see what happens.

[Pheonix]

The first problem you pointed out is already partially taken care of. I don't know how R2 & R0 got reversed in the text I posted, but it is the correct way around in what I actually compile & run. As for your second point, you are correct, I missed that I added in a JEQ after the S command in case the file name is actually the full 10 bytes long.

 

As for the second issue, the program is only going to be called with a B (not BL or BLWP,) command, as there is no plan to ever return from it. The reason for all the pre-set register contents is to centralize everything that the calling program changes depending on where it will be placed in memory. The methodology was designed around the Option 5 loader, and I continued it on to this one (though, this one probably doesn't need it. I don't think BASIC ever puts program data into Low RAM. The result is that the calling program just changes registers 9-13 & 15 to set the program to run correctly no matter where it is placed. So, if it has to be moved to >3000 (for example,) it would place >3000 in R15 and the LWPI command would then reference the correct starting point of the relocated workspace. In the case of the loaders, most of the reserved registers will end up not being needed. As many of the addresses I've been putting there will become fixed. The location of the PAB, for example, being one of them.

[Pheonix]

OK, now I'm getting correct numbers Had to clear the first word of the AIB instead of setting it to the VDP buffer address. >835C presents a problem there, though. >835D sets itself to >02 as soon as any command is executed after I set it to >00. Moved it back to where the original example I found had it (>8300) and it now works just fine. 3 different programs all provide the correct information. Moving on to the next stage, that of actually loading the BASIC program into RAM and RUNning it. Have most of the code for that already, just have to break it down to load it piecemeal instead of all at once.

 

My only issue with >8300 is that seems to be where certain argument information is stored. When I was using it for temporary storage for the file name & DSR command data, it would choke if I read the file name in before the device # (device # couldn't be read afterwords.) Only 12 byte or larger address I could find in a quick search. Going to search some more to see if I can find a free 10 byte area. 12 Bytes isn't too bad an overhead to add to my program. Though, it might mean tiling up another register, if I want to maintain the ability to relocate easily. Or, since my main program will reside there, and won't be needed any more, I might just use >A000 as a known free spot, once the loading process starts.

 

Code that works:

 
       DEF  SLOAD
 
       AORG >2600
 
       COPY "DSK1.XB-EQUATES"
 
DSRCMD EQU  >1B00
VDPADR EQU  DSRCMD+12
 
ADINBL EQU  >8300
FNPTR  EQU  >8356
 
LBNWS  BSS  20
       DATA VDPADR * R10 (BY SETTING THESE HERE, MAIN PROGRAM)
       DATA DSRCMD * R11 (CAN ALTER TO CORRECT VALUES EASIER)
       DATA DSRLNK * R12
       DATA GPLLNK * R13
SLOAD  LWPI LBNWS
       LIMI 0
 
* FIRST SECTION ONLY FOR TEST CODE
       CLR  R0
       MOVB @NUMARG,R1
       SRL  R1,8
       CI   R1,2
       JNE  BADARG
 
       BLWP @NUMREF
       BLWP @XMLLNK
       DATA CFI
       MOV  @FAC,R9
       JEQ  BADARG
       CI   R9,3
       JH   BADARG   * READ DEVICE NUMBER WITH LIMITATIONS FROM BOOK
 
       DEC  R1
       LI   R2,DCBUF+1
       LI   R3,>0A00
       MOVB R3,*R2
       BLWP @STRREF    * READ IN FILE NAME
       SWPB R3
       MOVB *R2+,R1
       SRL  R1,8
       A    R1,R2
       S    R1,R3
       JEQ  NOPAD
       LI   R0,>2000
PADNAM MOVB R0,*R2+
       DEC  R3
       JNE  PADNAM     * PAD FILE NAME WITH SPACES (>20)
NOPAD
       LI   R0,>0114
       MOV  R0,@DCBUF    * REPLACE THE >0114 FOR DSRLNK SUBROUTINE
 
       MOV  R11,R0
       LI   R1,DCBUF
       LI   R2,>0C
       BLWP @VMBW     * COPY TO VDP RAM
* END OF FIRST SECTION
* MAIN PROGRAM WILL DO ALL THIS BEFORE BRANCHING HERE
 
       SWPB R9        * R9 NOW SET TO >0?00 (DEVICE # & TRANSFER FILE PARAMETERS
       MOV  R11,R8
       INCT R8
       LI   R7,ADINBL
       SWPB R7        * MSB IS NOW LSB OF ADITIONAL INFO BLOCK ADDRESS
       LI   R0,FAC+2
       MOV  R9,*R0+
       MOV  R8,*R0+   * POINTER TO FILE NAME IN VDP RAM
       MOVB R7,*R0    * >834C->8350 NOW SET CORRECTLY I THINGK
       SWPB R7        * SWAP IT BACK
 
       CLR  R0
       MOV  R0,*R7    * CLEAR FIRST WORD OF AIB TO READ FILE PARAMETERS
 
       MOV  R11,@FNPTR
       BLWP *R12
       DATA 10
 
       LWPI GPLWS
       CLR  @STATUS
       B    @RTNPTR
 
BADARG LI   R0,ERRBA
       JMP  SETERR
SETERR BLWP @ERR
 
       COPY "DSK1.DSR-GPL;S"
 
DCBUF  DATA >010A  * SECOND BYTE DOUBLES AS FILE NAME LENGTH
FNAME  DATA >2020,>2020,>2020,>2020,>2020
 
       END

[Tursi]

Changing the disk type from 2 to 3 also changes the log to:

 

Sector read: TICC drive 1, sector 1, VDP >38E3

Sector read: TICC drive 1, sector 5, VDP >37E3

Sector read: TICC drive 1, sector 3, VDP >37E3

Sector read: TICC drive 1, sector 4, VDP >37E3

 

Now results in the same unexpected values I got from MAME.

As expected. When the TI DSR is running, Classic99 gets no insight as to what's going on. The only time it steps in is to translate the actual sector reads, so that's all the debug you get. The main reason for that option, besides testing, was so I could actually step through the DSR and see what it did.

 

Won't worry about the rest since you got it sorted.

[Pheonix]

I now have it working now. The XB Long format, of course, doesn't need this, as it already loads in small chunks (1 record at a time - or 254 bytes at a time.) The code below hasn't yet been streamlined. Was a bit tired when I got it working. Also, it won't work with a second load for some reason. I'll need to track that down as well. I know that in its final form that won't be necessary, but I like to be thorough. I'll also be looking into doing the same treatment to the Option 5 loader. I've decided that my next step (instead of going into full menu/editor work,) will be to dig into how this technique needs to be changed to handle different floppy controllers & hard drive controllers. From the way it's been acting, and from what I've read, this method depends fairly strongly on which controller is in place. Also, it doesn't appear to work with sub-directories or for hard drives. Classic99 doesn't appear to support hard drives either, so I may have to switch to Win994a for that (though the lack of a debugger will make troubleshooting more difficult.) It looks like, when that time comes, that MAME will be my best choice for that Other than it's extremely high configuration options, I've been rather disappointed with MAME emulation.

 

Anyway, the rough code:

 
       DEF  SLOAD
 
       AORG >2600
 
       COPY "DSK1.XB-EQUATES"
 
DSRCMD EQU  >1B00
VDPADR EQU  DSRCMD+12
 
ADINBL EQU  >8300
FNPTR  EQU  >8356
DCBUF  EQU  >A000
 
ELNTBL EQU >8330
BLNTBL EQU >8332
EBASIC EQU >FFE7
RBASIC EQU >64BD
FNPTR  EQU >8356
LSTPRT EQU >8345

 
BLREGS DATA >00E0,>0020,>0006,>0007
       DATA >0900,>0B00,>0C00
LBNWS  BSS  20
       DATA >0100  * R10 (DEFAULT TO AUTORUN DRIVE)
       DATA DSRCMD * R11
       DATA DSRLNK * R12
       DATA GPLLNK * R13
SLOAD  LWPI LBNWS
       LIMI 0
 
* FIRST SECTION ONLY FOR TEST CODE
       CLR  R0
       MOVB @NUMARG,R1
       SRL  R1,8
       CI   R1,2
       JNE  BADARG
 
       BLWP @NUMREF
       BLWP @XMLLNK
       DATA CFI
       MOV  @FAC,R10
       JEQ  BADARG
       CI   R10,3
       JH   BADARG        * READ DEVICE NUMBER WITH LIMITATIONS FROM BOOK
 
       DEC  R1
       LI   R2,DCBUF+1
       LI   R3,>0A00
       MOVB R3,*R2
       BLWP @STRREF       * READ IN FILE NAME
       SWPB R3
       MOVB *R2+,R1
       SRL  R1,8
       A    R1,R2
       S    R1,R3
       JEQ  NOPAD
       LI   R0,>2000
PADNAM MOVB R0,*R2+
       DEC  R3
       JNE  PADNAM        * PAD FILE NAME WITH SPACES (>20)
NOPAD
       LI   R0,>0114
       MOV  R0,@DCBUF     * PLACE THE >0114 FOR DSRLNK SUBROUTINE
 
       MOV  R11,R0
       LI   R1,DCBUF
       LI   R2,>0C
       BLWP @VMBW         * COPY TO VDP RAM
       SWPB R10           * R10 NOW SET TO >0?00
* END OF FIRST SECTION
* MAIN PROGRAM WILL DO ALL THIS BEFORE BRANCHING HERE
 
       MOV  R11,R9
       INCT R9            * NOW POINTING AT FILE NAME
       LI   R8,ADINBL
       SWPB R8            * MSB IS NOW LSB OF ADITIONAL INFO BLOCK ADDRESS
       LI   R0,FAC+2
       MOV  R10,*R0+
       MOV  R9,*R0+       * POINTER TO FILE NAME IN VDP RAM
       MOVB R8,*R0        * >834C->8350 NOW SET CORRECTLY I THINGK
       SWPB R8            * SWAP IT BACK
       CLR  R1
       MOV  R1,*R8        * CLEAR FIRST WORD OF AIB FOR PARAMETER READ
 
       MOV  R11,@FNPTR
       BLWP *R12
       DATA >0A           * GET FILE PARAMETERS
 
       MOVB @FAC+6,R0     * CHECK I/O ERROR BYTE
       JNE  BADIO
       MOVB @ADINBL+4,R0  * READ STATUS FLAGS
       ANDI R0,>0100      * CHECK PROGRAM/DATA BIT
       JEQ  FILERR
       MOV  @ADINBL+2,R8  * TOTAL AU'S USED
       MOVB @ADINBL+6,R9  * EOF OFFSET IN LAST AU
       SRL  R9,8
       JNE  NTZRO
       LI   R9,>0100
       JMP  NTZRO
 
FILERR LI   R0,ERRFE
       JMP  SETERR
BADIO  LI   R0,ERRIO
       JMP  SETERR
BADARG LI   R0,ERRBA
SETERR BLWP @ERR
 
NTZRO  INC  R10
       MOV  R11,R1
       INCT R1
       LI   R0,ADINBL
       SWPB R0
       LI   R2,VDPADR
       CLR  R7            * CURRENT AU TO READ (STARTS AT 0)
       MOV  R10,@FAC+2
       MOV  R1,@FAC+4
       MOVB R0,@FAC+6
       SWPB R0
       MOV  R2,*R0+
       MOV  R7,*R0
 
       MOV  R11,@FNPTR
       BLWP *R12
       DATA >0A           * READ FIRST AU

       LI   R0,VDPADR
       LI   R1,6
       MOV  R1,R2
       A    R15,R1
       INCT R2
       BLWP @VMBR         * READ HEADER BYTES
       A    R2,R0
 
       MOVB @LSTPRT,R1
       ANDI R1,>7FFF      * TURN OFF LIST PROTECTION
       MOVB R1,@LSTPRT
       MOV  R4,R1
       XOR  R5,R1
       C    R1,R3
       JEQ  NOTPRT
       NEG  R1
       C    R1,R3
       JNE  FILERR
       MOVB @LSTPRT,R1
       ORI  R1,>8000      * TURN ON LIST PROTECTION
       MOVB R1,@LSTPRT
 
NOTPRT MOV  R2,R3
       LI   R2,>0100
       DEC  R8
       JNE  NTLAST
       MOV  R9,R2
NTLAST S    R3,R2         * SIZE ADJUSTED
       LI   R3,EBASIC
       S    R6,R3         * R3 IS NOW DIFFERENTIAL
       A    R3,R4
       A    R3,R5
       MOV  R4,@BLNTBL    * BEGINNING OF LN TABLE
       MOV  R5,@ELNTBL    * END OF LN TABLE & STARTING LOAD ADDRESS
       MOV  R3,R6
       MOV  R5,R1
       BLWP @VMBR         * COPPY VDP BUFFER TO CPU RAM
       A    R2,R1
       MOV  R8,R8
       JEQ  CLNUP
 
       LI   R0,VDPADR
       LI   R2,>0100
RDLOOP INC  R7            * SET FOR NEXT AU
       MOV  R10,@FAC+2    * SET FOR READ 1 AU
       MOV  R11,R3
       INCT R3
       MOV  R3,@FAC+4     * SET FILE NAME POINTER
       LI   R3,ADINBL
       SWPB R3
       MOVB R3,@FAC+6     * SET AIB
       SWPB R3
       MOV  R0,*R3+       * SET VDP BUFFER
       MOV  R7,*R3        * SET WICH AU TO READ
       MOV  R11,@FNPTR
       BLWP *R12
       DATA >0A           * READ AU (BLOCK)
       DEC  R8            * REMAINING AU'S TO READ
       JNE  FULBLK
       MOV  R9,R2         * WAS THE LAST
FULBLK LI   R0,VDPADR
       BLWP @VMBR         * COPY BLOCK TO RAM
       A    R2,R1         * ADJUST DESTINATION
       MOV  R8,R8
       JNE  RDLOOP        * IS LAST AU?
 
CLNUP  MOV  @BLNTBL,R0
       MOV  @ELNTBL,R1
ADJLP  MOVB *R0,R2
       DEC  R0
       SWPB R2
       MOVB *R0,R2
       A    R6,R2
       MOVB R2,*R0+
       SWPB R2
       MOVB R2,*R0
       DECT R0
       DECT R0
       C    R0,R1
       JH   ADJLP
 
       LI   R3,BLREGS
       INC  R3
       MOVB *R3,@>83D4
       DEC  R3
       LI   R2,8
       CLR  R0
NXTREG MOVB *R3+,R0
       SWPB R0
       BLWP @VWTR
       SWPB R0
       INC  R0
       DEC  R2
       JNE  NXTREG
 
       MOV  *R3+,@FAC
       BLWP *R13
       DATA >0018
 
       MOV  *R3+,@FAC
       BLWP *R13
       DATA >004A
 
       MOV  *R3+,@FAC
       BLWP *R13
       DATA >0016
 
       BLWP *R13
       DATA RBASIC
 
       COPY "DSK1.DSR-GPL;S"
 
       END

[+mizapf]

It looks like, when that time comes, that MAME will be my best choice for that Other than it's extremely high configuration options, I've been rather disappointed with MAME emulation.

 

Why disappointed?

[Pheonix]

 

Why disappointed?

 

 

Mainly with the interface, appearance, keyboard layout, and such. Some of these "may" be adjustable to an extent, but don't know how much so. I can't, for example, find a way to program combinations that I've come to enjoy with both Win994a & Classic99. Such as using the F keys for <function>1,2,3, etc... Using the arrow keys in place of <function>s,d,x,e. Using the " key instead of <function>P and such. Remembering to hit <SCRL LOCK> before trying to adjust things like emulated hardware & such. The screen is blurry, regardless of how I set filters. Again, some of these "may" have a fix, but I can't find any clear documentation on it. Shoot, I can't find clear documentation on most of what MAME can do. Took me several days, and actually finding an old MESS site just to find out how to set up a cartridge file that would work. Basically it boils down to what appears to me to be a heavy relationship to Unix in how MAME is set up.... I've never been a fan of Unix or its derivatives So, mostly a matter of taste & opinion. I'll use it eventually, probably, but of the ones I've found, I prefer Classic99 over the others (at this time.)

[RXB]

Yea I love the idea of MESS but the interface is a total kluge of text based commands, exactly the opposite of the PC/Mac using a mouse.

Way to many steps just to do simple things.

 

I will try MESS again when a much more easy to setup appears. Currently it is a nightmare to set up for new users.

[+mizapf]

I'd like to give some comments to your observations. I should say that I did not design the user interface and the overall handling of MAME, and my influence on that is limited. Or let's say, I'm not an expert on that; I hope someone else among the devs will take that job. And maybe everyone else thinks the same way.

Some of these "may" be adjustable to an extent, but don't know how much so.

Yes, documentation is bad - not a new phenomenon among such big open source projects.

I can't, for example, find a way to program combinations that I've come to enjoy with both Win994a & Classic99. Such as using the F keys for <function>1,2,3, etc...Using the arrow keys in place of <function>s,d,x,e. Using the " key instead of <function>P and such.

MAME has a second keyboard mode called "natural keyboard"; you can start it with the option "-natural" or set it in the OSD menu (ScrlLock - Tab). In that mode you can indeed find mappings like arrow-key-left to FCTN-S. However, this mode only works for combinations that produce a defined keycode in the PC. While you can find FCTN-S on the PC keyboard as arrow-key-left, most of the CTRL key sequences are not defined on the PC. Also, the natural keyboard maps F1 to FCTN-1, but it cannot map anything to FCTN alone.

This inconvenience, combined with the lagging performance of the natural keyboard, makes me prefer the emulated keyboard, although the keys are not located at the expected positions. However, I rarely get into trouble, because after a short time I learned to map the keys in my mind.

Remembering to hit <SCRL LOCK> before trying to adjust things like emulated hardware & such.

In its original domain, the arcade machines, the TAB key is never used, so there is no "partial" or "full" keyboard emulation mode; the TAB key always brings up the OSD. In MESS (or now in the computer system part of MAME), all keys on the keyboard may essentially be mapped in the emulation. For example, the Geneve uses the TAB key by itself. The core must cope with completely different keyboard layouts, from ZX-80 to a PC-AT. So it is required to switch between partial and full modes.

The alternative solution might be to have a different input method, like a mouse action, to configure the emulation, if the mouse itself is not yet used (again the case for the Geneve). Earlier MESS releases had a UI, but the UI was abandoned and suffered from bit rot. Another challenge is to provide an operating system-independent implementation. It is possible, as the built-in debugger proves, but obviously no one really tries. My guess is that most other devs focus on the Lua interface, which may be developed to a new UI.

Most of the time I don't actually use the OSD, because I rarely reconfigure my system. As I once said, instead of using the ugly OSD file manager, I rather stop the emulation and run it with a disk in drive. Yes, I won't spend efforts to defend the OSD.

The screen is blurry, regardless of how I set filters.

There is a setting in the "slider options" that stops all postprocessing. Indeed, I enjoy the slightly blurred vision, much more in fact than the pixel-hard lines, which I - personally - find ugly. There is even a way to make it "more blurry" by applying a slot mask emulation or other video artifacts.

Shoot, I can't find clear documentation on most of what MAME can do.

 

I can't either. Lack of documentation, see above. The question is - what should be documented? More related to the TI family, or more general? The features of the TI family can only be documented by me, or by other people using the emulation. I still foster some hopes that people help me documenting the stuff on Ninerpedia, but this seems to remain my responsibility, as it turned out.

 

Took me several days, and actually finding an old MESS site just to find out how to set up a cartridge file that would work.

 

Have you checked Ninerpedia? This is where I put down everything, also concerning setting up cartridge images.

 

Basically it boils down to what appears to me to be a heavy relationship to Unix in how MAME is set up.... I've never been a fan of Unix or its derivatives. So, mostly a matter of taste & opinion.

 

I think that most of the devs of MAME are actually Windows people, judging from the comments on using Visual Studio etc. I don't know whether this was always the case, but I think it is true of now at least.

 

Here is my personal opinion: I'm having increasing difficulties in understanding the aversion of people against the command line operation, but this may be mainly due to my preference of Linux. Most things could easily be settled if people tried to make friends with the command line and write their batch files as desired, instead of trying to navigate through the awkward OSD. I have several script files that are specialized for particular situations. Usually they take an arguments like disk images or cartridges to be mounted. So go into the MAME folder and say "./ti99ae -cart editass -flop1 disks/ti/mydisk01.dsk" which launches the emulation with a set of expansion cards and plugged-in Editor/Assembler. Next time, I actually don't type that anymore, just do a reverse search for "ti99", and press Return. How can things be simpler? - But I'm afraid this is just my personal taste.

[+arcadeshopper]

 

 

Mainly with the interface, appearance, keyboard layout, and such. Some of these "may" be adjustable to an extent, but don't know how much so. I can't, for example, find a way to program combinations that I've come to enjoy with both Win994a & Classic99. Such as using the F keys for <function>1,2,3, etc... Using the arrow keys in place of <function>s,d,x,e. Using the " key instead of <function>P and such. Remembering to hit <SCRL LOCK> before trying to adjust things like emulated hardware & such. The screen is blurry, regardless of how I set filters. Again, some of these "may" have a fix, but I can't find any clear documentation on it. Shoot, I can't find clear documentation on most of what MAME can do. Took me several days, and actually finding an old MESS site just to find out how to set up a cartridge file that would work. Basically it boils down to what appears to me to be a heavy relationship to Unix in how MAME is set up.... I've never been a fan of Unix or its derivatives So, mostly a matter of taste & opinion. I'll use it eventually, probably, but of the ones I've found, I prefer Classic99 over the others (at this time.)

So basically the problem is you don't want to figure it out.

 

Mame/mess is entirely reconfigurable. It's easy to change key definitions. And it supports the most hardware emulation for the ti and geneve.

 

I'm sure Michael already answered the basics.

 

Greg

 

Sent from my LG-H830 using Tapatalk

[Pheonix]

Sigh.... I spent a month (just on the TI-99/4A emulation,) trying to figure it out. Built several RPK files, till I found a place (by accident,) that had them already built without having to download several GB for just the few that matched the modules I physically own (or plan to buy within the next few months.) I've also configured it to look where I put my TI-99/4A stuff (cartridge ROMs, Disk images, Tape images, etc...) I've used a tape deck to make WAV files of all my cassettes (that took another week or so, as I had to struggle with many of the tapes to get a good read of them.) There were a couple that I never got a good read of Had to download replacements for those.

 

Many of the sites I went to trying to figure out how to do things were clearly referring Unix based OS systems, thus my assumption that MESS, at least, was designed around a Unix system. A frustration I face when trying to get details on setting up libraries or routines for programming for the PC as well. I have an entire directory dedicated to small libraries I had to hunt down to replace Unix only ones that are required for compiling projects designed for windows. I have a dozen or so, so far. On the same topic, very few, if any, of the sites I went to trying to figure out how to get MAME emulation of the TI running right, were not MAME help sites. They were almost exclusively MESS websites. A minor inconvenience for the most part, though some of the differences between MESS & MAME had to be interpreted on the fly (usually with guesswork.)

 

I found the "natural keyboard" option fairly early, but the loss of some of the basic keys moved me away from it fairly early as well. The <scrl lock> option for partial/full keyboard mode was only a minor inconvenience, but also a frustrating one at times as well. There is no clear indication whether it is active or not, for one thing. The <scrl lock> LED can't be used for that, as MAME doesn't go by state, but is a simple toggle by pressing the key. Just do a reset while in partial mode to switch states, or forget and have the <scrl lock> on when you start the emulation. The same effect can be seen with the <caps lock> key as well.

 

Post processing, on my version of MAME at least, isn't in the slider options, it is a simple toggle key. Found it by accident after trying to find it under slider controls. Default seems to be <CTRL><ALT>F5, and it does look better to me with it turned off. I also tend not to use filters at all. I usually prefer the blocky letters over the smoothing that filters provide universally getting rid of them. About the only time I will use filters is when non-integer resizing causes excessive distortion. Even then, I tend to chose the simpler filters over the more complex ones.

 

I never argued that it wasn't highly configurable. I argued that the mass of minor irritations add up to too much for me. I can either reconfigure the overall keyboard to allow mapping the arrow keys to the PC arrow keys instead of <ALT>e,s,d,x, and lose being able to map the <FCTN> key (losing all <FCTN> key combinations that don't have a direct correlation to a PC keyboard key.) Or I can add those keys to the e,s,d,x mapped keys (though it will still require the <ALT> key be held to use.) Every problem faced results in several hours of searching, hoping that the problem has already been addressed. When it hasn't, there is usually a day or two waiting for a response, and hoping the only answer isn't being called an idiot because it works for everyone except me (SAMS emulation, crashes MAME, but when I asked about it, that was the only answer I got.) I have to admit, when I got that response is when I dropped using it, and went looking for alternatives.

 

I also have no problem setting up a batch file, or an AutoIt file, if it requires multiple commands to set up something specific. Single command setups I usually just create a dedicated shortcut for it. Adding command line triggers to a shortcut is absurdly simple (for me at least.) I do it all the time for my DOSBox programs. Though that is usually limited to setting up specific config file & turning off the console window. This was never an issue for me. The closest it came was my failure to get the debug toggle key to no longer be greyed out. I either have debugging always on (-debug command line trigger,) or always off (close after load doing a reset to bring it back, or don't include the trigger.) That's actually a recent irritation, and I haven't done a search yet for the fix.

 

This problem I faced getting the staggered load routine working wouldn't have happened if I had still been using MAME, I will admit that. As I would have configured it to match my real HW. It does, however point out a problem with what I'm doing that I'm going to have to address (and has already been mentioned to me earlier in the thread.) That is, that my final program is probably going to end up being extremely machine specific. I'll have to dig into the various drive controllers and find out how they handle things.

 

I've also discovered the problem with re-use that I mentioned in my last post, with the working code. By using >8300 as the AIB, I seemed to have killed the ability to include arguments with the CALL LINK command. It flies off into an endless loop somewhere the first time it tries to read one. Moving it somewhere else has only changed how it fails on the second load (so far.) My next attempt will include saving the contents of the AIB before use, and restoring afterwords. I'll be doing that later, though.

 

[+mizapf]

Pheonix, I understand your woes with MAME, and I don't try to talk away the issues, I can just explain why things are this way and not another way, and I hope I can sort out all problems that arise because the user has gained a possibly inappropriate view how the system is supposed to work. This is not supposed to mean that I consider the user too dumb to use it. The lack of documentation forces people to make sense of what they see from the system's behavior. Obviously, as the one who wrote nearly everything concerning the TI emulation (there are basically no more lines left that I inherited from my predecessor in charge, Raphael Nabet), I may have a completely different view and therefore also some problems to take the view of a "mere user".

 

I don't remember the case with the crashed SAMS. If you get a response like "works for me", this is in most cases simply true, and it requires deeper investigation. But as for me, it does not mean that your issue report is not welcome; in contrast, I am grateful for every issue report that indicates a bug in the system. By this way, I dare to say that the TI emulations are pretty stable by now - provided that the latest release is used (one of the reasons why I urge people to keep pace with the updates).

 

I've been investing a lot of time into the TI emulations for the last 10 years, and this will continue for quite some time, as I see it right now. You can always ask me for assistance if there are problems - unless you want to figure it out by yourself. This may be more frustrating that necessary, and what I'd like to avoid is that people get frustrated by MAME simply because of an issue that can be fixed by a few keystrokes.

[Pheonix]

It wasn't a bug report or anything like that, and I don't remember the forum I went to looking for an answer. A close quote of the answer I got (in the forum,) was "Are you an idiot, SAMS works just fine out of the box." Or something close to that at least. I never responded to it I just walked away, thinking "forget it, too much trouble." It may have included other insulting fix suggestions (or maybe not so insulting suggestions,) but I didn't read past that line. I'll dig up how to get a crash log again, and send it to you if you want. Not exactly worried about it, as I usually use the 32K RAM setting instead, I was just trying to cycle through the options & look at the differences and such (mainly to see if I should include them in my project design.) Was still in just the basic design phase back then. I faced a similar, if not quite as rude, issue when I was setting up my Amiga 2000. It dual boots to KS 1.3 & 2.04, and I wanted a utility for the 1.3 boot. Found several for the 2.04, but none for the 1.3. When I asked in a forum about it, the response I got was "Don't use KS 1.3." I eventually got an answer to that one, but it was still a little upsetting.

 

I'm actually working on a non-programming project (changing things for a bit to let my mind rest,) right now, but I'll get back to this later (tomorrow at the latest.) I'm going to be making a backup of whatever section I set aside for the AIB, to restore after I finish with it (as part of the cleanup phase, probably.) That should fix the issues I have with running it multiple times. After that, I'll either apply the method to the Option 5 loader, or go looking for how using other controllers need to be addressed. I'm also considering moving HDD & sub-directory handling here instead of dealing with it later. Still haven't decide if, when HDD handling is included, I'm going to have a single info file per drive/disk, or if I'm going to have it per directory instead. I may do it one way for floppies, and the other for hard drives. Since a lot of what I'm going to do with the Option 5 loader is going to cut & past from the BASIC normal save loader, I'm thinking putting in HDD & sub-directory handling should be taken care of first.

[+arcadeshopper]

ftp.whtech.com always has the lastest mame roms and rpks

[Pheonix]

That's where I found them

[Pheonix]

Well, I don't know what's causing the issue with using CALL LINK multiple times. I've backed up everything I alter, restoring it after. I even, though I cannot see how it would be necessary, backed up the FAC & restored it after. Problem still persists. I've confirmed that I'm not altering anything in the program itself. But the only way to run it again is to first use another CALL INIT (followed by a LOAD, of course.) The normal (full load,) loader doesn't have this problem. Just the partial load. I can only think that maybe it's the DSRLNK sub-program >14 that is the issue. Or, I'm actually changing something through a mistake in coding. I'll go through the code again, later, and see if I can spot anything.

[Pheonix]

I managed to track down the multi-use problem. It seems the address I'm using for the Pre-Scan then Run (>64BD) changes the jump address for NUMREF (and maybe others as well.) Before using "BLWP @GPLLNK" "DATA >64BD" the vallue at >200E (the address part of NUMREF,) is >217E, after my program runs it becomes >2644. I had to "guess" the address to Pre-Scan & RUN from a disassembly provided earlier in the thread. I cannot find another source for an XB disassembly Nor can I find any reference to a jump table. I'll have to go back to the one provided here, and see if there is maybe a better place to jump to. My full load code worked because it never used NUMREF, but it has the same issue with the NUMREF address changing.

 

Updated code, removed the relocation code (not needed,) and streamlined a bit:

 
       DEF  SLOAD
 
       AORG >2600
 
       COPY "DSK1.XB-EQUATES"
       COPY "DSK1.DSR-GPL;S"
 
DSRCMD EQU  >1B00
DSRDEV EQU  >1B02
DSRFNL EQU  >1B03
DSRFN  EQU  >1B04
VDPADR EQU  >1B0E
 
AIB    EQU  >8398
DCBUF  EQU  AIB
DEVBUF EQU  AIB+2
FNLBUF EQU  AIB+3
FNBUF  EQU  AIB+4
FNPTR  EQU  >8356
 
ELNTBL EQU >8330
BLNTBL EQU >8332
EBASIC EQU >FFE7
RBASIC EQU >64BD
FNPTR  EQU >8356
LSTPRT EQU >8345

 
SLOAD  LWPI LBNWS
       LIMI 0
       LI   R15,DSRCMD    * FOR FASTER ACCESS
 
* FIRST SECTION ONLY FOR TEST CODE
       CLR  R0
       LI   R1,>0200
       CB   R1,@NUMARG
       JNE  BADARG
       SWPB R1
 
       BLWP @NUMREF
       BLWP @XMLLNK
       DATA CFI
       MOV  @FAC,R2
       JEQ  BADARG
       CI   R2,3
       JH   BADARG        * READ DEVICE NUMBER WITH LIMITATIONS FROM BOOK
       SWPB R2
       MOVB R2,@DEVBUF
 
       DEC  R1
       LI   R2,FNLBUF
       LI   R3,>0A00
       MOVB R3,*R2
       BLWP @STRREF       * READ IN FILE NAME
       SWPB R3
       MOVB *R2+,R1
       SRL  R1,8
       A    R1,R2
       S    R1,R3
       JEQ  NOPAD
       LI   R0,>2000
PADNAM MOVB R0,*R2+
       DEC  R3
       JNE  PADNAM        * PAD FILE NAME WITH SPACES (>20)
 
NOPAD  LI   R0,>0114
       MOV  R0,@DCBUF     * PLACE THE >0114 FOR DSRLNK SUBROUTINE
 
       LI   R0,DSRCMD
       LI   R1,DCBUF
       LI   R2,>0E
       BLWP @VMBW         * COPY TO VDP RAM
* END OF FIRST SECTION
* MAIN PROGRAM WILL DO ALL THIS BEFORE BRANCHING HERE
 
       LI   R0,DSRDEV
       CLR  R1
       BLWP @VSBR
       MOV  R1,R14        * NOW SET TO DEV# & 00 (FOR PARAMETERS READ)
 
       LI   R1,DSRFN
       LI   R0,AIB   
       SWPB R0            * MSB IS NOW LSB OF ADITIONAL INFO BLOCK ADDRESS
       CLR  R2            * CLEAR FOR PARAMETER READ
       MOV  R14,@FAC+2
       MOV  R1,@FAC+4
       MOVB R0,@FAC+6
       SWPB R0
       MOV  R2,*R0        * CLEAR FIRST WORD OF AIB FOR PARAMETER READ
       MOV  R15,@FNPTR
       BLWP @DSRLNK
       DATA >0A           * GET FILE PARAMETERS
 
       CLR  R0
       MOVB @FAC+6,R0     * CHECK I/O ERROR BYTE
       JEQ  IOGOOD
 
BADIO  LI   R0,ERRIO
       JMP  SETERR
FILERR LI   R0,ERRFE
       JMP  SETERR
BADARG LI   R0,ERRBA
SETERR BLWP @ERR
 
IOGOOD MOVB @AIB+4,R0     * READ STATUS FLAGS
       ANDI R0,>0100      * CHECK PROGRAM/DATA BIT
       JEQ  FILERR
       MOV  @AIB+2,R10    * TOTAL AU'S USED
       MOVB @AIB+6,R9     * EOF OFFSET IN LAST AU
       SRL  R9,8
       JNE  EOFNZ
       LI   R9,>0100
 
EOFNZ  INC  R14           * SET FOR READING SINGLE AU
       CLR  R11           * FIRST AU TO READ IS 0
RDLOOP LI   R1,DSRFN
       LI   R0,AIB   
       SWPB R0
       LI   R2,VDPADR
       MOV  R14,@FAC+2
       MOV  R1,@FAC+4
       MOVB R0,@FAC+6
       SWPB R0
       MOV  R2,*R0+
       MOV  R11,*R0       * NOW SET TO READ CURRENT AU
       MOV  R15,@FNPTR
       BLWP @DSRLNK
       DATA >0A           * READ CURRENT AU
 
       LI   R0,VDPADR
       CLR  R3
       MOV  R11,R11
       JNE  NTFRST        * FIRST AU READ?
 
       LI   R2,8
       LI   R1,LBNWS
       A    R2,R1
       BLWP @VMBR         * READ HEADER BYTES
       A    R2,R0
       MOV  R2,R3
       MOVB @LSTPRT,R8
       ANDI R8,>7FFF      * TURN OFF LIST PROTECTION
       MOV  R5,R1
       XOR  R6,R1
       C    R1,R4
       JEQ  NOTPRT
       NEG  R1
       C    R1,R4
       JNE  FILERR
       ORI  R8,>8000      * TURN ON LIST PROTECTION
 
NOTPRT MOVB R8,@LSTPRT
       LI   R8,EBASIC
       S    R7,R8         * R8 IS NOW DIFFERENTIAL
       A    R8,R5
       A    R8,R6
       MOV  R5,@BLNTBL    * BEGINNING OF LN TABLE
       MOV  R6,@ELNTBL    * END OF LN TABLE & STARTING LOAD ADDRESS
       MOV  R6,R7         * STARTING POINT OF DATA COPY
 
NTFRST LI   R2,>0100
       DEC  R10           * REMAINING AU'S TO READ
       JNE  FULBLK
       MOV  R9,R2         * WAS THE LAST
FULBLK S    R3,R2
       MOV  R7,R1
       BLWP @VMBR         * COPY BLOCK TO RAM
       A    R2,R7         * ADJUST DESTINATION
       INC  R11           * SET FOR NEXT AU
       MOV  R10,R10
       JNE  RDLOOP        * IS LAST AU?
 
       MOV  @BLNTBL,R0    * BEGINNING LN TABLE
       MOV  @ELNTBL,R1    * END LN TABLE
ADJLP  MOVB *R0,R2        * GET LSB OF CURRENT LN ADDRESS
       DEC  R0            * SET FOR MSB
       SWPB R2
       MOVB *R0,R2        * GET MSB OF CURRENT LN ADDRESS
       A    R8,R2         * ADD OFFSET
       MOVB R2,*R0+       * MOVE MSB & SWITCH TO LSB
       SWPB R2
       MOVB R2,*R0        * MOVE LSB
       DECT R0
       DECT R0            * DECREMENT DOWN TO NEXT LN ADDRESS
       C    R0,R1
       JH   ADJLP         * MOVE PAST END?
 
       LI   R1,>8080      * SET FOR SPACES
       LI   R0,768        * HIGHEST DESTINATION ADDRESS + 1
CLRSCR DEC  R0            * DECREMENT HERE SO WILL MOVE TO 0-HIGHEST
       BLWP @VSBW         * PLACE BYTE IN ADDRESS
       MOV  R0,R0
       JNE  CLRSCR        * WHEN DONE SCREEN HAS BEEN CLEARED
 
       LI   R3,BLREGS     * SET FOR BASIC VDP REGISTER VALUES
       INC  R3
       MOVB *R3,@>83D4    * SAVE R1 VALUE SO IT MATCHES
       DEC  R3
       LI   R2,8          * HOW MANY REGISTERS
       CLR  R0            * SET FOR REGISTER ZERO
NXTREG MOVB *R3+,R0       * GET REGISTER VALUE IN MSB
       SWPB R0            * REGISTER # IN MSB & VALUE IN LSB
       BLWP @VWTR         * SET REGISTER
       SWPB R0            * SWITCH BACK
       INC  R0            * SET FOR NEXT REGISTER
       DEC  R2            * COUNT DOWN
       JNE  NXTREG        * FINISHED?
 
       MOV  *R3+,@FAC     * READ VALUE FOR CHARACTER SET
       BLWP @GPLLNK
       DATA >0018         * SET SMALL CAPITAL LETTERS CHARACTER SET
 
       MOV  *R3+,@FAC
       BLWP @GPLLNK
       DATA >004A         * SET LOWER CASE CHARACTER SET
 
       MOV  *R3+,@FAC
       BLWP @GPLLNK
       DATA >0016         * SET STANDARD CHARACTER SET
 
       LWPI GPLWS
       CLR  @STATUS
       BLWP @GPLLNK
       DATA RBASIC
 
LBNWS  BSS  32
BLREGS DATA >00E0,>0020,>0006,>0007
       DATA >0900,>0B00,>0C00
 
       END

[Pheonix]

Well, tracked down the issue with being unable to use CALL LINK more than once. The problem was in GPLLNK, it backs up >200E and then places another value there (changing NUMREF to point to part of the GPLLNK code instead.) It restores the correct value before RTWP (returning to the main program,) so this usually isn't a problem. But, by using GPLLNK to execute the pre-scan and then RUN the program, that part of GPLLNK that would normally restore the correct value is never reached. Fixed the problem by incorporating what I needed from GPLLNK into the end of my routine instead of actually calling GPLLNK to do it. It now works fine, and keeps working if I use it over and over. Not that that would be an issue, but I just like it better that way.

 

Updated code:

 
       DEF  SLOAD
 
       AORG >2600
 
       COPY "DSK1.XB-EQUATES"
       COPY "DSK1.DSR-GPL;S"
 
DSRCMD EQU  >1B00
DSRDEV EQU  >1B02
DSRFNL EQU  >1B03
DSRFN  EQU  >1B04
VDPADR EQU  >1B0E
 
AIB    EQU  >8398
DCBUF  EQU  AIB
DEVBUF EQU  AIB+2
FNLBUF EQU  AIB+3
FNBUF  EQU  AIB+4
FNPTR  EQU  >8356
 
ELNTBL EQU >8330
BLNTBL EQU >8332
EBASIC EQU >FFE7
RBASIC EQU >64BD
FNPTR  EQU >8356
LSTPRT EQU >8345

 
SLOAD  LWPI LBNWS
       LIMI 0
       LI   R15,DSRCMD    * FOR FASTER ACCESS
 
* FIRST SECTION ONLY FOR TEST CODE
       CLR  R0
       LI   R1,>0200
       CB   R1,@NUMARG
       JNE  BADARG
       SWPB R1
 
       BLWP @NUMREF
       BLWP @XMLLNK
       DATA CFI
       MOV  @FAC,R2
       JEQ  BADARG
       CI   R2,3
       JH   BADARG        * READ DEVICE NUMBER WITH LIMITATIONS FROM BOOK
       SWPB R2
       MOVB R2,@DEVBUF
 
       DEC  R1
       LI   R2,FNLBUF
       LI   R3,>0A00
       MOVB R3,*R2
       BLWP @STRREF       * READ IN FILE NAME
       SWPB R3
       MOVB *R2+,R1
       SRL  R1,8
       A    R1,R2
       S    R1,R3
       JEQ  NOPAD
       LI   R0,>2000
PADNAM MOVB R0,*R2+
       DEC  R3
       JNE  PADNAM        * PAD FILE NAME WITH SPACES (>20)
 
NOPAD  LI   R0,>0114
       MOV  R0,@DCBUF     * PLACE THE >0114 FOR DSRLNK SUBROUTINE
 
       LI   R0,DSRCMD
       LI   R1,DCBUF
       LI   R2,>0E
       BLWP @VMBW         * COPY TO VDP RAM
* END OF FIRST SECTION
* MAIN PROGRAM WILL DO ALL THIS BEFORE BRANCHING HERE
 
       LI   R0,DSRDEV
       CLR  R1
       BLWP @VSBR
       MOV  R1,R14        * NOW SET TO DEV# & 00 (FOR PARAMETERS READ)
 
       LI   R1,DSRFN
       LI   R0,AIB   
       SWPB R0            * MSB IS NOW LSB OF ADITIONAL INFO BLOCK ADDRESS
       CLR  R2            * CLEAR FOR PARAMETER READ
       MOV  R14,@FAC+2
       MOV  R1,@FAC+4
       MOVB R0,@FAC+6
       SWPB R0
       MOV  R2,*R0        * CLEAR FIRST WORD OF AIB FOR PARAMETER READ
       MOV  R15,@FNPTR
       BLWP @DSRLNK
       DATA >0A           * GET FILE PARAMETERS
 
       CLR  R0
       MOVB @FAC+6,R0     * CHECK I/O ERROR BYTE
       JEQ  IOGOOD
 
BADIO  LI   R0,ERRIO
       JMP  SETERR
FILERR LI   R0,ERRFE
       JMP  SETERR
BADARG LI   R0,ERRBA
SETERR BLWP @ERR
 
IOGOOD MOVB @AIB+4,R0     * READ STATUS FLAGS
       ANDI R0,>0100      * CHECK PROGRAM/DATA BIT
       JEQ  FILERR
       MOV  @AIB+2,R10    * TOTAL AU'S USED
       MOVB @AIB+6,R9     * EOF OFFSET IN LAST AU
       SRL  R9,8
       JNE  EOFNZ
       LI   R9,>0100
 
EOFNZ  INC  R14           * SET FOR READING SINGLE AU
       CLR  R11           * FIRST AU TO READ IS 0
RDLOOP LI   R1,DSRFN
       LI   R0,AIB   
       SWPB R0
       LI   R2,VDPADR
       MOV  R14,@FAC+2
       MOV  R1,@FAC+4
       MOVB R0,@FAC+6
       SWPB R0
       MOV  R2,*R0+
       MOV  R11,*R0       * NOW SET TO READ CURRENT AU
       MOV  R15,@FNPTR
       BLWP @DSRLNK
       DATA >0A           * READ CURRENT AU
 
       LI   R0,VDPADR
       CLR  R3
       MOV  R11,R11
       JNE  NTFRST        * FIRST AU READ?
 
       LI   R2,8
       LI   R1,LBNWS
       A    R2,R1
       BLWP @VMBR         * READ HEADER BYTES
       A    R2,R0
       MOV  R2,R3
       MOVB @LSTPRT,R8
       ANDI R8,>7FFF      * TURN OFF LIST PROTECTION
       MOV  R5,R1
       XOR  R6,R1
       C    R1,R4
       JEQ  NOTPRT
       NEG  R1
       C    R1,R4
       JNE  FILERR
       ORI  R8,>8000      * TURN ON LIST PROTECTION
 
NOTPRT MOVB R8,@LSTPRT
       LI   R8,EBASIC
       S    R7,R8         * R8 IS NOW DIFFERENTIAL
       A    R8,R5
       A    R8,R6
       MOV  R5,@BLNTBL    * BEGINNING OF LN TABLE
       MOV  R6,@ELNTBL    * END OF LN TABLE & STARTING LOAD ADDRESS
       MOV  R6,R7         * STARTING POINT OF DATA COPY
 
NTFRST LI   R2,>0100
       DEC  R10           * REMAINING AU'S TO READ
       JNE  FULBLK
       MOV  R9,R2         * WAS THE LAST
FULBLK S    R3,R2
       MOV  R7,R1
       BLWP @VMBR         * COPY BLOCK TO RAM
       A    R2,R7         * ADJUST DESTINATION
       INC  R11           * SET FOR NEXT AU
       MOV  R10,R10
       JNE  RDLOOP        * IS LAST AU?
 
       MOV  @BLNTBL,R0    * BEGINNING LN TABLE
       MOV  @ELNTBL,R1    * END LN TABLE
ADJLP  MOVB *R0,R2        * GET LSB OF CURRENT LN ADDRESS
       DEC  R0            * SET FOR MSB
       SWPB R2
       MOVB *R0,R2        * GET MSB OF CURRENT LN ADDRESS
       A    R8,R2         * ADD OFFSET
       MOVB R2,*R0+       * MOVE MSB & SWITCH TO LSB
       SWPB R2
       MOVB R2,*R0        * MOVE LSB
       DECT R0
       DECT R0            * DECREMENT DOWN TO NEXT LN ADDRESS
       C    R0,R1
       JH   ADJLP         * MOVE PAST END?
 
       LI   R1,>8080      * SET FOR SPACES
       LI   R0,768        * HIGHEST DESTINATION ADDRESS + 1
CLRSCR DEC  R0            * DECREMENT HERE SO WILL MOVE TO 0-HIGHEST
       BLWP @VSBW         * PLACE BYTE IN ADDRESS
       MOV  R0,R0
       JNE  CLRSCR        * WHEN DONE SCREEN HAS BEEN CLEARED
 
       LI   R3,BLREGS     * SET FOR BASIC VDP REGISTER VALUES
       INC  R3
       MOVB *R3,@>83D4    * SAVE R1 VALUE SO IT MATCHES
       DEC  R3
       LI   R2,8          * HOW MANY REGISTERS
       CLR  R0            * SET FOR REGISTER ZERO
NXTREG MOVB *R3+,R0       * GET REGISTER VALUE IN MSB
       SWPB R0            * REGISTER # IN MSB & VALUE IN LSB
       BLWP @VWTR         * SET REGISTER
       SWPB R0            * SWITCH BACK
       INC  R0            * SET FOR NEXT REGISTER
       DEC  R2            * COUNT DOWN
       JNE  NXTREG        * FINISHED?
 
       MOV  *R3+,@FAC     * READ VALUE FOR CHARACTER SET
       BLWP @GPLLNK
       DATA >0018         * SET SMALL CAPITAL LETTERS CHARACTER SET
 
       MOV  *R3+,@FAC
       BLWP @GPLLNK
       DATA >004A         * SET LOWER CASE CHARACTER SET
 
       MOV  *R3+,@FAC
       BLWP @GPLLNK
       DATA >0016         * SET STANDARD CHARACTER SET
 
       
       LWPI GPLWS
       MOV  @>0050,R4
       LI   R6,RBASIC
       BL   *R4
       MOV  @GXMLAD,@>8302(R4)
       INCT @>8373
       B    @LDGADD
 
LBNWS  BSS  32
BLREGS DATA >00E0,>0020,>0006,>0007
       DATA >0900,>0B00,>0C00
 
       END

[Pheonix]

Well, I've got bitmap mode up and running. Ended up dropping the redefined lower case letters. Could never get them set up to my satisfaction, so I'm just using the TI's default set. Turns out, I need to drop files down to 2 if I want to leave bitmap mode on during the load process, otherwise the colors on the bottom of the screen start doing fun things Was hoping to do everything in assembly, using BASIC just to load the assembly routine. I was starting to look into the utility allowing you to load an assembly program along with the BASIC program (hadn't read much on that yet.) But, since I cannot seem to find how to change the files settings from assembly again, I guess I could just do it from basic.

 

All that being said, it's reached the point where I think I'll need to back burner it unless & until I get a storage device that can hold more than my SSSD floppy drive. Between the loaders, the editor, the menu system itself, the program information file, & loading screens, this is going to take up most of the disk. Oh well, back to using BASIC, and just set up DATA/READ statements for the program information. Did learn quite a bit, and have copious notes. I'll just have to find another project to work on for now.

[+Lee Stewart]

Well, I've got bitmap mode up and running. Ended up dropping the redefined lower case letters. Could never get them set up to my satisfaction, so I'm just using the TI's default set. Turns out, I need to drop files down to 2 if I want to leave bitmap mode on during the load process, otherwise the colors on the bottom of the screen start doing fun things Was hoping to do everything in assembly, using BASIC just to load the assembly routine. I was starting to look into the utility allowing you to load an assembly program along with the BASIC program (hadn't read much on that yet.) But, since I cannot seem to find how to change the files settings from assembly again, I guess I could just do it from basic.

 

All that being said, it's reached the point where I think I'll need to back burner it unless & until I get a storage device that can hold more than my SSSD floppy drive. Between the loaders, the editor, the menu system itself, the program information file, & loading screens, this is going to take up most of the disk. Oh well, back to using BASIC, and just set up DATA/READ statements for the program information. Did learn quite a bit, and have copious notes. I'll just have to find another project to work on for now.

 

Here is how I execute the DSR’s FILES subroutine in fbForth 2.0 kernel—minus the stack manipulation, of course:

 

PABADR EQU >1000 PAB address in VRAM (only 2 bytes will be used)...

* ...this VRAM address can be wherever convenient

FAC EQU >834A FAC

SUBPTR EQU >8356 DSR subroutine pointer

*

* FILES routine---

*

* Input: R2 has maximum number of simultaneous files

*

FILES LI R0,PABADR PAB address

LI R1,>0100 namelength (1 for DSR subroutines)

LIMI 0 disable interrupts because VSBW and DSRLNK don't

BLWP @VSBW write the byte to the PAB

INC R0 next PAB address to write

LI R1,>1600 FILES subroutine number in DSR (>16)

BLWP @VSBW write to PAB

SWPB R2 get no. of files to left byte

MOVB R2,@FAC+2 get number of files to first byte of transfer block

DEC R0 point to namelength byte in PAB

MOV R0,@SUBPTR copy to where DSR expects it

BLWP @DSRLNK do the subroutine

DATA >0A

LIMI 2 enable interrupts

RT return to caller

 

[Edit] You are welcome to my fbForth 2.0 font file, which includes true lowercase with descenders. I also have the TI Writer font file.

 

...lee

[Pheonix]

No wonder I couldn't find it again I didn't even think to look in the specs for disk systems book. An oversight on my part, it makes sense now, but I just didn't think of it

 

I have also kicked myself because of my original, extremely wasteful, loading screen design. I was just saving the data from the character tables (>1800 bytes,) and the color tables (another >1800 bytes.) Large chunks of that were reduced with basic RLE compression, but they were still coming out rather large IMHO. Instead, I should have just used character/color per position for the loading screen. Since I'm only using 128 characters (even though the definition tables use 256,) it makes using RLE a lot more efficient to interleave them. Plus, by using a screen position method instead of the table contents, I've reduced the size to 1/8th the original amount. It necessitates setting up a 1.5k buffer when editing the loading screen, but I can live with that. It also removes the possibility of using hand drawn (pixel by pixel,) graphics on the loading screen, but the space requirement of that doesn't make it worth it (until I can arrange larger capacity storage.)

 

I also allowed myself to get a little excited by the idea of hybrid modes. By extending my "font" to the full 256 characters and making 128-255 reverse images of 0-127, I thought I could cut my color table in half. Only to discover, after a day of reading and working things out, that I can't cut my color table in half without doing the same to the character table Since full bitmap mode needs the character tables to cover 256 characters, that doesn't work out. If I'm willing to limit the list to 8 lines, I could reduce the color table by a 3rd, but it isn't really worth it. What would be nice is if I could reduce the color table to >0300 bytes instead of >1800 (by just having 1 color definition per character instead of 8.) But there doesn't appear to be a way to do that.

 

I'm going to start working on it again Though I might make the BASIC only version as well. I've looked into the HDD options, and am dismayed by the lack of available hardware There were a couple of cards I found that looked promising. But the one I liked the most seems to have stability issues with floppy access. Not that I'm adverse to 2 cards (1 for floppy & 1 for HDD,) but I liked that it allowed HD floppy drives. Would love to install a 5.25" and a 3.5" drive into my PEB, though. Of the cards that were stable, I couldn't actually find any for sale, so I don't know how much to save up to get one

 

[Pheonix]

Well, I got bitmap mode up and running. Even tested loading & running different format programs with my relocatable segmented loaders. Relocation of everything except DSRLNK & GPLLNK has become extremely simplified. One thing that came in handy was setting a lot of the loading information up in advance. My main program set up the PAB (though it it only consists of >0114 & a 10 byte file name.) I could then put needed relocation information in either the file buffer space, or just pre-load some of the registers. I fought with the LWPI command at the beginning of the loaders until it dawned on my I could just do that command "before" branching to the loader.

 

Was working on actually setting up the interface, when I decided that I think I'm going to drop bitmap mode. I've already removed hand drawn loading screens, as they just come out too large. Even with my, admittedly simple, compression. Was setting up & experimenting with the menu setup, and just couldn't decide on a color scheme & format that I was happy with. And ended up pretty much eliminating the need for multiple colors. I've solved having reverse text issues just fine (by moving the character pattern tables to where I can actually use all of them.) The only other item on my wish list that required bitmap mode that remained was the pixel scroll. I'd like to keep that, but it isn't worth the cost (IMHO.)

 

So, reverse text, covered... I'm leaving the character pattern table where it is (>0000 through >07FF,) I'm just loading it where it's supposed to go. I may use one of the fonts that Mr. Stewart graciously provided, or I may stick with the TI fonts. Actually toyed around a bit with the 40 column fonts. Thought of right shifting them all 1 bit for true centered text but decided against it. They look just a little too squished for me. Since I don't plan on using sprites I also moved all of that to >0000 as well. Lost the first 4 characters (>0D at >0000 to disable all sprites, and color codes from >0001 through >001F.) That puts my first usable address for PAB & File Buffer at >0C00. Dropping FILES down to 1 (only need 1 file opened at a time,) gives me a file buffer of 11,994 bytes, which is sufficient to load the largest normal BASIC program without segmentation. Will prevent loading any that were designed to be loaded after a CALL FILES of 2 or 1 has been used. But I don't see that being an issue. If push comes to shove, I can put a check for that in, and then disable the screen to reclaim that area for file buffer space.

 

This has allowed me to greatly simplify my loaders again. Though I will now have to start designing my menu program from scratch again. Too much of what I have is geared around bitmap mode, and I hadn't begun to simplify it yet anyways. It had all grown around my test code anyways. Now I can start building things in the modular fashion I prefer

[Pheonix]

I'm learning that I actually have more color freedom that I originally thought, even without bitmap mode. Working on the "Loading Screen" editor right now, and can set overall background color (what shows on transparent,) Normal text color (all normal text gets a single color for simplicity,) normal text background color, reverse text foreground & background color (can just reverse it to get normal text of a different color,) and (so far,) special character FG/BG colors (4.5 sets of 8 char each so far.) Though, I think, other than the load type indicators, I'm going to stick with the special characters as having one selection for all of them (like the normal & reverse text.) I'm actually, quite seriously, considering giving up >20 bytes to get the full color table & free up character >00 as a definable character (right now, character 0 is lost because of sprite attributes byte >00 needs to be >d0, and characters 1-3 are being used by the color table.) Color table is moved in >40 byte increments, but only takes up >20 bytes. Sprite Attributes (as long as sprites aren't needed,) only takes up 1 byte (the first one >D0.) But is moved in >80 byte increments.Since the 1st 4 bytes of the color table are defined for the load type color codes, I just set >D0 as a color code for one of the load types

 

OK, maybe I need to get some sleep, I think that last bit was getting a little confusing. And I'm the one that actually wrote it I was also wasting >100 bytes, as I was mapping around a >400 byte screen instead of >300 bytes. One thing I'm definitely going to do (I think,) is to copy the copyright symbol from E/A (hehe, love the irony of that.) Like to put copyright & author information on the loading screen. Though, I think I'm going to put it in the brief description box from now on. One of my larger programs loads so fast that I don't have time to really see the loading screen. I think I'll just rename it to the Module Change instruction screen and only use it for those. Actually tempting me, to restructure it so that selecting an entry brings up an information screen instead of just loading the game. You can either load it, or go back, once there. Then I blank the screen for loading purposes. Can free up a huge track of VDP RAM if I just blank the screen during load. Move "everything" down to >0000 (with >0000 - >02FF set to >D0 & character >D0 set to all >00) Better yet, >0000 - >02FF set to >D0 & >0300 - >07FF set to >00. Then I can put the PAB at >0688 (character >D1,) and nothing will show up on screen as it loads. Of course, that's overkill. Looking at the figures, the largest load buffer (with FILES set to the default of 3,) the buffer only needs to start at >0992. Assuming the largest possible PAB (>109 bytes,) that still a lowest address of >0883.

 

All that being said. Buffering for the load is just not an issue any more. So, I'm going back to "not" adjusting the FILES value. I would like to be able to use it on other devices. Since I'm using the basic DSR routines (DATA >08) that shouldn't be an issue. What I'm running into a problem right now is finding documentation of detecting sub-directories on the drive (the instructions only list how to find a file list.) I'd also sort of like to find out if there is a way to get a list of the drives that are available.

[+Lee Stewart]

... and nothing will show up on screen as it loads. ...

 

Using the screen real estate for loads can be quite entertaining to watch.

 

...lee