+jedimatt42 Posted March 22, 2018 Share Posted March 22, 2018 Greg likes to point at that stuff doesn't work with TIPI... so the new one is TML. bu TML documentation says it performs something equivalent to CALL FILES on startup, but TIPI doesn't use VDP buffers, so it has no CALL FILES equivalent. And, if it did, that would be in the way of anything using the real CALL FILES... unless its implementation was complete. But I'm not really sure what call files does... besides change the value of a pointer in memory... I'm wondering if I can just modify the TML loader to not require this... -M@ Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 22, 2018 Author Share Posted March 22, 2018 If I just remove the CALL LINK("FILES", 1) in the TML loader, it acts like it loads, but then running anything that uses it like the TMLDEMO crashes... honk... and the screen goes nuts. -M@ Quote Link to comment Share on other sites More sharing options...
RXB Posted March 22, 2018 Share Posted March 22, 2018 Well this is the CALL FILES from RXB 2015: *************************************************** LINKT4 DATA >C010 STRI 'FILES' FILES DATA $+2 CALL COMB ( CALL CLSALL Close all open files CALL RXBFIL Set files BR RXBNEW Go do a NEW RXBFIL CALL SUBLP3 Get Files value DCZ @FAC Zero? BS ERRBV Yes, BAD VALUE error DCHE 16,@FAC 16 or more to high BS ERRBV Yes, BAD VALUE error CEQ RPARZ,@CHAT )? BR ERRSYN SYNTAX ERROR XML PGMCHR Skip ) DCLR @FAC2 Clear ST @FAC1,@FAC2 Load file value DST >0116,V@VROAZ Set files buffer space CALL DSKDSR RTN *********************************************************** COMB CEQ LPARZ,@CHAT If not '(' - error BR ERRSYN RTN *********************************************************** CLSALL DST @IOSTRT,@PABPTR Start at beginning of chain DCZ @IOSTRT Continue until done BR CLSAZ0 RTN And return *********************************************************** RXBNEW CLR V@LODFLG Clear AUTOLOAD flag CALL CLSALL B SZNEW *********************************************************** SUBLP3 CALL NUMFCH CALL CFIFCH RTN STRFCH XML PGMCHR XML PARSE BYTE RPARZ RTN NUMFCH CALL STRFCH CEQ >65,@FAC2 BS ERRSNM * STRING NUM MISMATCH RTN *********************************************************** DSKDSR DCHE 256,@VAR0 * BR DSRDSS * ADD >10,@VROAZ+1 * DSRDSS DST VROAZ,@FAC12 * CALL LINK * BYTE >0A * ST @ERCODE,@VAR2 * SRL 4,@FAC6 * CZ @FAC6 * BR ERRFE * CEQ >20,@VAR2 * BS ERRFE * RTN * *********************************************************** *---------------------------------------------------------- * Add the following line for fixing "MEMORY FULL" error * occurring during MERGE execution will leave the file open * to disk DSR bug, 5/19/81 SZNEW CLR V@MRGPAB Initialize merged temporary * for PAB pointer *---------------------------------------------------------- ST RSTK,@SUBSTK Load base of subroutine stack CALL CHRTA2 Load character table CLR @FLAG Initialize flag byte DCLR @BUFLEV Initialize crunch buffer leve CALL CLSALL Close all open files CLR @DATA Initialize READ/DATA pointer DST VRAMVS,@VSPTR Initialize base of value stac DST @VSPTR,@STVSPT Save in permanent base DST @VSPTR,V@SAVEVP CALL INITPG Initialize program & s.t. CALL INTRND Initialize random number CZ V@LODFLG BS TOPL02 If need auto-boot * RXB PATCH CODE ************* * CLR V@LODFLG Won't ever need to do again BR G63D0 ********************************************************** 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 22, 2018 Share Posted March 22, 2018 (edited) TML documentation says it performs something equivalent to CALL FILES on startup, but TIPI doesn't use VDP buffers, so it has no CALL FILES equivalent. And, if it did, that would be in the way of anything using the real CALL FILES... unless its implementation was complete. But I'm not really sure what call files does... besides change the value of a pointer in memory... My suspicion: TML could be expecting the 5 byte validation header and/or the last filename to be located in VDP, with the 8370 pointer set accordingly. This can be particularly obnoxious when trying to eliminate any VDP dsr dependencies, especially when no disk controller is in the system. I ran into a similar situation with the Horizon ROS. If TIPI doesn't manage this during its powerup sequence TML could be getting lost during its attempt to do its own call files, which most likely is also reserving VDP space for its routines and limiting its use by XB. And if TIPI is not doing anything in VDP ram to 'mimic' a disk controller, you may run into this issue with a few other programs down the road. Fortunately, it doesn't happen too often beyond the occasional boot tracking routine or, as in the case of FunnelWeb, 'smart' VDP buffer management routines. Might help to also consider how Tursi and Rasmus handle VDP in Classic99 and js99er, if it is indeed the root cause. Edited March 22, 2018 by InsaneMultitasker Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 22, 2018 Author Share Posted March 22, 2018 I'm in awe of the ingenuity and crap'storm it creates I think it is just the TML loader that is causing me grief... And I'll never care about supporting FunnelWeb... Use google docs or office 365. Somewhere there has to be the file that goes with : CALL LOAD("????.TML2/O") instead of magic embedded machine code at the end of fragile BASIC program images. It is inappropriate for 'not-a-floppy-controller' to mess with the floppy controllers buffers. So I'm not going to. If there is software that requires a floppy controller, you just won't be able to run it from an ONLY TIPI system. I'm going to have to press hard that TIPI provides zero floppy emulation. It may load files with floppy like paths.. but doesn't emulate a floppy controller. For TML, I'm sure an alternative loader can be created. -M@ Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 22, 2018 Share Posted March 22, 2018 (edited) Might help to also consider how Tursi and Rasmus handle VDP in Classic99 and js99er, if it is indeed the root cause. When FILES are called, JS99er is just setting the pointer at >8370, and status byte (?) at >8350. I have probably copied this from Classic99. memory.writeWord(0x8370, 0x4000 - nFiles * 0x2B8); memory.writeWord(0x8350, memory.readWord(0x8350) & 0x00FF); Edited March 22, 2018 by Asmusr 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 22, 2018 Share Posted March 22, 2018 With XB and 32K what numbers are returned when you type SIZE? Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 22, 2018 Share Posted March 22, 2018 If TML is indeed calling CALL FILES(1) via the DSR routine, and then modifying 0x8370 to reserve VDP for the screen/bitmap/whatever buffers, this is totally acceptable and within documented standards. So a CALL LOAD to 0x8370 might be enough to replace the CALL LINK, provided you know how much extra VDP space TML needs and can compute that value so XB knows what to do. (Senior Falcon probably has this memorized ) I do agree re: not messing with the floppy controller buffers. Beyond that, what TIPI does or does not do with respect to 0x8370 and VDP is your prerogative. Just don't expect programs that take advantage of this construct to work successfully if TIPI is not providing a simple call files routine and/or managing 0x8370, particularly when it is alone in the system and acting similar to a disk controller. I cited Funnelweb as an example of a program that is 'smarter' than TML but may still get into trouble if there is no recognizable disk or hard disk controller in place to manage 0x8370, which until now has been a fairly solid expectation and requirement for real systems. For the record, Funnelweb is not a word processor, though an editor is one of its components. 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted March 22, 2018 Share Posted March 22, 2018 With XB and 32K what numbers are returned when you type SIZE?Dot Sent from my LG-H872 using Tapatalk Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted March 22, 2018 Share Posted March 22, 2018 The number you show there is when a floppy drive controller is NOT present, otherwise it would read 11,840 bytes of stack space. Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 22, 2018 Share Posted March 22, 2018 (edited) The number you show there is when a floppy drive controller is NOT present, otherwise it would read 11,840 bytes of stack space. Yes, he's running TIPI without VDP disk buffers. This is the battle I went through with Classic99. Ultimatey, to work with some software, you need CALL FILES to do something appropriate, you need to update >8370, and you need to set up the VDP Buffer header at the address >8370 points to (if nothing else, the pCode card will crash if you don't). You don't actually need to use VDP for anything else, and my testing with Classic99 so far ONLY found the pCode card to require you to use VDP for anything (including that header), but if you don't set the VDP size to the same sizes that the TI Disk Controller does, then programs which are saved from BASIC or XB which fit in VDP RAM on the TIPI system might not be able to load on a TI using a TI Disk Controller. In BASIC, it's just purely the amount of free memory. But in XB it's a little more insidious -- XB saves as a PROGRAM image if it fits in VDP RAM (even with 32k available), so having more VDP available than a TI disk controller system creates an incompatible file. (RXB made the change in his system that RXB /always/ saves in the record based format, so wouldn't have that problem). (edit: some software, not most software) Edited March 22, 2018 by Tursi 4 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 23, 2018 Author Share Posted March 23, 2018 Ok... So, hopefully, if my powerup routine sets these values up to normal FDC waste level, then I won't create a situation where TIPI users are creating software that won't run on TIFDCs. That has value. And, looking at SECTION I: DSR ARCHITECTURE PG 127, the TIFDC CALL FILES doesn't appear to interact with the floppy controller at all. So it is strictly manipulating this stack reservation. So If I implement it and someone calls mine instead of their floppy controller's it shouldn't cause a problem with their floppy controller, unless CC or Myarc controllers do something additional. My worry is that as I am not the floppy controller, I shouldn't prevent the floppy controller's call files from being called. A traditional DSRLNK will find me first in a co-existance scenario. I would enjoy enabling something as developer oriented as TML2 to still work. -M@ Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 23, 2018 Author Share Posted March 23, 2018 With XB and 32K what numbers are returned when you type SIZE? What Greg said --- Question: what does TML2 actually expect of the system? Does it expect to be able to perform a DSRLNK to invoke CALL FILES? Or does it expect my controller is at CRUBASE 1100 and my FDB reservation code is at >4658? I ask, since it is asking what kind of controller I am using... and 'neither' isn't an option. I don't usually run TIPI at CRUBASE 1100. -M@ Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 23, 2018 Share Posted March 23, 2018 This is the code in TML that has the information you need. Hope it helps. ***HIMEMORY PART OF BIT-MAPPED BASIC- AORG >8330 DATA >E2E7,>E2E7 FIX LINE # TABLE POINTERS AORG >205A B @LOOKUP DOCTOR UP UTILITIES TO LOOK UP NAMES AORG >E2E8 HM part of TML GOES HERE LOOKUP LI R1,TABST \ LOOKU1 CI R1,HMWS JHE LOOKU4 MOV R1,R0 LI R2,>834A C *R0+,*R2+ JNE LOOKU3 C *R0+,*R2+ LOOKS UP NAME IN NEW REF/DEF TABLE & EXECUTES IF FOUND JNE LOOKU3 C *R0+,*R2+ JNE LOOKU3 MOV *R0+,R0 B *R0 LOOKU3 AI R1,8 JMP LOOKU1 LOOKU4 MOV @>2004,R1 FIX SO "REAL" LOOKUP CAN HAPPEN B @>205E / TABST TEXT 'MULTI ' DATA MULTI TEXT 'MONO ' DATA MONO TEXT 'FILES ' DATA FILES TEXT 'LOWHI ' DATA LOWHI TEXT 'HILOW ' DATA HILOW HMWS BSS 32 WORKSPACE FOR BASIC PROGRAMS ******************************************************************************** *CALL LINK("MULTI",FOREGROUND,BACKGROUND) SETS TO MULTICOLOR SCREEN ******************************************************************************** MULTI LWPI HMWS LI R0,>1800 BOTTOM OF STACK FOR MULTICHROMATIC SCREEN JMP MONO1 ******************************************************************************** *CALL LINK("MONO",FOREGROUND,BACKGROUND) SETS TO MONOCHROME ******************************************************************************** MONO LWPI HMWS LOAD BASIC WORKSPACE LI R0,>0958 Can't be lower -might wipe out stack if continue MONO1 MOV R0,@BOTSTK SETS THE POINTER TO THE BOTTOM OF THE STACK BITMA7 LI R0,MONITR MONITR IS ADDRESS OF MONITOR PROGRAM MOV R0,@>83C4 START UP MONITOR PROGRAM ON INTERRUPT* *this does the assembly equivalent of call files, then moves some pointers MOVB @NFILES+1,@>834C 834C gets the # of files in MSB LI R0,>03E8 Unused area of VDP RAM LI R1,HMWS+6 R3-R5 used LI R2,5 5 bytes to write (only need 2 here next) LI R3,>0116 opcode for Allocate Disk Buffer Space BLWP @VMBW Write PAB MOV R0,@>8356 >8356 gets address of PAB BLWP @DSRLNK DATA >000A a subprogram MOV @>8370,R0 Get pointer to top of memory INC R0 points to 5 byte header BLWP @VMBR read the header AI R0,>E210 Where we want the buffers put BLWP @VMBW write the 5 byte header DEC R0 points to top of memory MOV R0,@>8370 doctor Scratch pad pointer AI R0,>C006 Because VDP is auto incrementing don't have to set add. CLR R8 Going to write a Zero BITMA2 MOVB R8,@>8C00 CLEAR OUT THE REST OF VDP RAM OVER DISK INFORMATION INC R0 JNE BITMA2 LI R0,>C060 \ MOV R0,@>205A DOCTOR UP THE LOOK UP TABLE TO ORIGINAL FORM LI R0,>2004 MOV R0,@>205C / LI R0,>FFE7 \ MOV R0,@>8330 Reset basic program pointers MOV R0,@>8332 / LI R0,>5000 Turn Off sprite motion & quit key MOVB R0,@>83C2 JMP FILES1 ******************************************************************************** *CALL LINK("FILES") - A program to do the same thing as "CALL FILES(N)" ******************************************************************************** FILES LWPI HMWS Set workspace BLWP @GETNUM Get number of files to be opened DATA >0011 One number to retrieve, no optional #s DATA >0103 Number is to be from 1 to 3 INC R4 Needed because GETNUM decrements it MOV R4,@NFILES Store number for future use FILES1 LWPI >83E0 Return to Extended BASIC B @>006A ***** LOWHI LWPI HMWS \ LI R0,>2002 LI R1,>E4D0 MOV *R0+,*R1+ MOV *R0+,*R1+ Moves BITMAPPED BASIC from lowmenor to high memory LI R0,>24F4 LOWHI1 MOV *R0+,*R1+ CI R0,>4000 JLT LOWHI1 JMP FILES1 / HILOW LWPI HMWS \ LI R0,>2002 LI R1,>E4D0 MOV *R1+,*R0+ MOV *R1+,*R0+ Moves BITMAPPED BASIC from himemory to low memory LI R0,>24F4 HILOW1 MOV *R1+,*R0+ CI R0,>4000 JLT HILOW1 JMP FILES1 / *There are about 158 bytes left for extra stuff RORG 4 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 23, 2018 Author Share Posted March 23, 2018 Thanks! -M@ Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 23, 2018 Share Posted March 23, 2018 (edited) My worry is that as I am not the floppy controller, I shouldn't prevent the floppy controller's call files from being called. A traditional DSRLNK will find me first in a co-existance scenario. Yeah, that's one place that emulation was able to cheat a bit -- Classic99 knows if there is a TI controller installed, and if there is, it lets that code handle the CALL FILES call. If not, it updates the pointer and VDP like so: int nTop = 0x3def - (256+256+6)*n - 5 - 1; // should be 0x37d7 with 3 files debug_write("Setting top of VRAM to >%04X (%d files)", nTop, n); WriteMemoryByte(0x8370, (nTop>>&0xff, false); WriteMemoryByte(0x8371, nTop&0xff, false); // set up the header for disk buffers - P-Code Card crashes with Stack Overflow without these VDP[++nTop] = 0xaa; // valid header VDP[++nTop] = 0x3f; // top of VRAM, MSB VDP[++nTop] = 0xff; // top of VRAM, LSB (TODO: CF7 will change top of VRAM value by 6 bytes) VDP[++nTop] = 0x11; // CRU of this disk controller VDP[++nTop] = n; // number of files The hard coded starting offset covers the structures the disk controller uses, and the multiplier 'n' is the number of disk buffers, from 1-9. The "- 5 - 1" was clearly meant to be documenting something, but I didn't write it down. :/ The 5 bytes written to VDP is the structure the disk controller maintains at the beginning of the buffers - it uses that as a starting point for its operations. The pCode card blindly assumes it will be there, otherwise nothing I've run into so far checks for it. (Some software has been caught reaching into the buffers themselves, but it's uncommon enough that I don't support that myself). If you run before the disk controller and blindly change >8370, the disk controller will then change it again for you, and reserve even more memory. (If you run after it, life's easy cause you can just check, but then you can't override its names). It's a bit awful, but you COULD write a little scratchpad routine that turns TIPI off, turns on >1100, and checks for a disk controller FILES subprogram. If it finds it, do nothing, if not, set up the memory yourself. I'd recommend searching for the SBR program (byte >16, rather than the name 'FILES') since it's just one byte... Just some thoughts, good luck! Edited March 23, 2018 by Tursi 3 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 24, 2018 Author Share Posted March 24, 2018 Actually, holding my ground a little bit and compromising a little bit... I'll fix up my powerup routine if it is running on CRUBASE >1100. That should be all that is necessary for this issue and compatibility. If you run the TIPI on >1000 or any base not >1100 ( the reserved floppy base ), then there will be no buffer setup by TIPI, so it can be completely left to the actual floppy controller. I have tested that if my TIFDC is in, and it's power up routine runs, then loading TML2 stuff from TIPI works fine... there is a set of jumpers on the board to select >1000 - >1F00. I'll ship the sideport boards set for >1100. Time to erase some eproms -M@ 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 25, 2018 Author Share Posted March 25, 2018 Ok, Implementing the powerup routine fixed the 'size' setting. TML is not happy with me not having the >16 level 2 routine available to it to free up over 1k of stack space. Basically performing CALL FILES(1), as everyone said I'd need to do "Software Specification For The 99/4 Disk Peripheral" documents the buffer layout... 256 (for FDC) + 256(sector buffer) + 6 (legacy unused by TIFDC but left in out of fear) - Section 7.4 The 5 accounts for the 5 bytes at what you've (Tursi) identified as nTop + 1. and The -1, I think because the vdp stack pointer points to the first free byte. I have read this a couple years ago when I waiting to have a TI... Oddly Fred's awesome Level 2 IO documentation doesn't cover >16. Since HDX also doesn't do that. http://aa-ti994a.oratronik.de/GPL_Interface_Specification_for_the_99_4_Disk_Peripheral_V2_0_03_28_1983.pdf (I'm always thrown by Texas Instruments use of the term GPL to include all the machine code with interfaces meant to be called by GPL code) -M@ 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 25, 2018 Author Share Posted March 25, 2018 I get gruff about some of this stuff... probably because it all destroys a little bit of the romanticize view I had of the 4A. But it works! If TIPI is running at same CRUBASE as a TIFDC, the TIPI powerup routine will set the file buffers to 3... If Level 2 routine >16 is run, and TIPI is at the TIFDC CRUBASE, then it will handle it and adjust the file buffers. If Level 2 routine >16 is run, and TIPI is NOT at the TIFDC CRUBASE, then it returns 0 without incrementing the return address, so a good DSRLNK moves on the find the real floppy controller's routines. TMLDEMO now works in both situations! THANKS!!! You all have been very constructive and helpful! Now I should also implement the "CALL FILES(x)" version with the same conditions as >16 -M@ 4 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 25, 2018 Share Posted March 25, 2018 Nice approach! Not that it matters much for TIPI at the moment, even the Geneve is required to muck around and set up a fake VDP header during its powerup. (...and writes too many bytes in the process). HAA BYTE >AA,>3F,>FF,>11,>03 VDP RAM HEADER FOR FLOPPY LI R1,>37D7 THIS WILL HAVE TO BE PATCHED TO CHECK FOR /4A MODE MOV R1,@>8370 INC R1 LI R7,HAA R7 POINTS TO HEADER ORI R1,>4000 SWPB R1 MOVB R1,@>8C02 SWPB R1 MOVB R1,@>8C02 LI R1,10 PISS1 MOVB *R7+,@>8C00 DEC R1 JNE PISS1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 26, 2018 Share Posted March 26, 2018 Interesting label there... Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 26, 2018 Share Posted March 26, 2018 Nice solution... I was thinking to myself "but what if you don't want a disk controller", and then I realized the answer was "then run it at >1100". Simple and very reasonable, I think! 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.