[HECnet] Re: Tops-20 NFT limited parse types for RSX systems?

Thanks, I will definitely keep that in my back pocket. For the moment, I'm going to assume that I've broken something. As I've said in the past, a fair amount Tops-20 code did not get the time to become fully productized and as a result can be silently susceptible to what one would think are innocuous changes.  It can sometimes be quite hard to find these.  For example, GLXLIB PID blocks for IPCF communications come in two sizes, the shorter one (PB.MNS) when you don't want to name the PID.  It saves about three words. However, GLXIPC doesn't check the length at all.  It always checks the name (among other things), so if you happen to have something that isn't really an ASCIIZ pointer after the short block, you will get boom.  Who knew?  My current working hack is to always specify the longer block length (PB.MXS), which then leaves these words zero and GLXIPC handles that properly.  I guess I can live with wasting three dinky words, but it does irk my sense of propriety. GLXLIB, FAL, NFT and DAP are all quite intertwined and debugging is can get extremely difficult when you also have multiple forks and mapped libraries, one primary problem being that you can't get to the correct symbol table.  Then you have to deal with a small amount of self-modifying code and a non-standard entry vector.  So, I would say at least half the code I've written is to enable the debugger to work properly and to get to the correct symbols. Very late in the game, DEC came up with an extremely nice idea called program data vectors (PDV) in part to support dynamic link libraries, which became more feasible with the vastly increased address space of the KL10B and the KC10 (unreleased).  For example,  VENTI2, PANDA TOPS-20 Monitor 7.1(21746)-5  PANDA TOPS-20 Command processor 7.1(4454)-5 PDVs:   Program name FAL, version 2.1(35)-5         Program name FALSRV, version 2.1(35)-5         Program name DAP%, version 2(207)-5         Program name GLX%, version 6(1546)-5         Program name DDT%, version 45.1(720)-5 So what you can see is that this is a subfork of the main FAL controller and that it is using the DAP library, GLXLIB and has the debugger.  The last three follow naming conventions for Digital supplied libraries and code, meaning the name is suffixed with a percent (%).  However, when you first start, none of them are in the virtual address space, so you can forget about their symbols. Unfortunately, PDV's are not widely used, so many of my local changes involve putting them in as well as write-protecting code spaces.  Naturally DDT had a bug with PDV's so I had to fix /that/ before I could debug the rest of Galaxy and FAL/NFT/DAP. No wonder I keep failing into all these rabbit holes... ------------------------------------------------------------------------ On 11/22/22 4:54 AM, Johnny Billquist wrote: