Pheonix Posted June 11, 2017 Author Share Posted June 11, 2017 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 >38E3Sector read: TICC drive 1, sector 5, VDP >37E3Sector read: TICC drive 1, sector 3, VDP >37E3Sector read: TICC drive 1, sector 4, VDP >37E3 Now results in the same unexpected values I got from MAME. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 11, 2017 Share Posted June 11, 2017 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,>2000PADNAM 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. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 11, 2017 Author Share Posted June 11, 2017 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. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 12, 2017 Author Share Posted June 12, 2017 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 12, 2017 Share Posted June 12, 2017 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. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 13, 2017 Author Share Posted June 13, 2017 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 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 13, 2017 Share Posted June 13, 2017 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? Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 14, 2017 Author Share Posted June 14, 2017 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.) Quote Link to comment Share on other sites More sharing options...
RXB Posted June 14, 2017 Share Posted June 14, 2017 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 14, 2017 Share Posted June 14, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 14, 2017 Share Posted June 14, 2017 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 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 14, 2017 Author Share Posted June 14, 2017 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 14, 2017 Share Posted June 14, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 14, 2017 Author Share Posted June 14, 2017 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. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 14, 2017 Share Posted June 14, 2017 ftp.whtech.com always has the lastest mame roms and rpks 1 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 15, 2017 Author Share Posted June 15, 2017 That's where I found them 1 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 15, 2017 Author Share Posted June 15, 2017 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. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 21, 2017 Author Share Posted June 21, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 26, 2017 Author Share Posted June 26, 2017 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 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 3, 2017 Author Share Posted July 3, 2017 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 3, 2017 Share Posted July 3, 2017 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 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 3, 2017 Author Share Posted July 3, 2017 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 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 7, 2017 Author Share Posted July 7, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 9, 2017 Author Share Posted July 9, 2017 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 9, 2017 Share Posted July 9, 2017 ... and nothing will show up on screen as it loads. ... Using the screen real estate for loads can be quite entertaining to watch. ...lee Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.