+arcadeshopper Posted November 2, 2020 Share Posted November 2, 2020 50 minutes ago, InsaneMultitasker said: Does the program (in your case, YAPP) work with EXEC without /r? Some programs require the BASIC GROMs or specific bytes in the TI ROM, and therefore must be run from the GPL program. Secondly, I implemented the "/r" option with the HFDC and SCSI in mind and IIRC it only does a power-up of the HFDC. This leads to some quirky behavior at times and is different from GPL where the TI ROM powers up all devices. Neither case should be an issue for TIPI since the Geneve EPROM performs a full-blown powerup of all devices on powerup. Edit: Only the later version of EXEC has the /r option so be sure you are using the right one. YMMV but yes rompage will get you access to TIPI. and DSK0-4 Mappings.. HOWEVER the program has to use DSR access. some wrote their own file access routines and they may ignore the DSR. I'll do some testing later and make a video Greg 1 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted November 2, 2020 Share Posted November 2, 2020 Greg, could you include showing other geneve products if you have time? Thx Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted November 2, 2020 Share Posted November 2, 2020 Just now, GDMike said: Greg, could you include showing other geneve products if you have time? Thx I have a few already if you look at my channel but yes I'll do more as time permits. https://www.youtube.com/c/arcadeshopper/ Greg 2 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted November 2, 2020 Share Posted November 2, 2020 there you are.. with actual fan and hard disk noises 4 Quote Link to comment Share on other sites More sharing options...
Nick99 Posted November 2, 2020 Share Posted November 2, 2020 2 hours ago, InsaneMultitasker said: Does the program (in your case, YAPP) work with EXEC without /r? Some programs require the BASIC GROMs or specific bytes in the TI ROM, and therefore must be run from the GPL program. Secondly, I implemented the "/r" option with the HFDC and SCSI in mind and IIRC it only does a power-up of the HFDC. This leads to some quirky behavior at times and is different from GPL where the TI ROM powers up all devices. Neither case should be an issue for TIPI since the Geneve EPROM performs a full-blown powerup of all devices on powerup. Edit: Only the later version of EXEC has the /r option so be sure you are using the right one. Thanks! I start YAPP with EXEC, have never known of /r, may be that I have an old version of EXEC... or it´s highly likely that it´s an old version. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 2, 2020 Share Posted November 2, 2020 48 minutes ago, Nick99 said: Thanks! I start YAPP with EXEC, have never known of /r, may be that I have an old version of EXEC... or it´s highly likely that it´s an old version. Run EXEC without any filename or parameters and it should tell you the version. 1.3 doesn't have /r. 1 hour ago, arcadeshopper said: with actual fan and hard disk noises music to our ears 3 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted November 2, 2020 Share Posted November 2, 2020 4 hours ago, InsaneMultitasker said: Does the program (in your case, YAPP) work with EXEC without /r? Some programs require the BASIC GROMs or specific bytes in the TI ROM, and therefore must be run from the GPL program. Secondly, I implemented the "/r" option with the HFDC and SCSI in mind and IIRC it only does a power-up of the HFDC. This leads to some quirky behavior at times and is different from GPL where the TI ROM powers up all devices. Neither case should be an issue for TIPI since the Geneve EPROM performs a full-blown powerup of all devices on powerup. Edit: Only the later version of EXEC has the /r option so be sure you are using the right one. YAPP works fine without /r it just won't see any TIPI. drives.. 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 11, 2020 Share Posted November 11, 2020 On 10/28/2020 at 8:00 PM, TheBF said: Cool so one could do A:>EXEC DSK2.CAMEL99 Is there a technical document on how to write programs for MDOS ? My cross-compiler has a 64K segment reserved for the target program. I could make a very FAT Forth system for Geneve. (not that many would care) I would care about Camel99! I was just finding the GenProg documentation here: http://ftp.whtech.com/Geneve/mdos/MDOS Development documents/ For instance, this MDOS reference (it is kind of dated) and the collection of API calls documents. Manuals for GENASM and so on. From memory... I can convey to you that it's a breeze to build a MDOS native program with GenProg. Especially if your code is self-contained (no assumptions about E/A or console ROM). The source should just use RORG. Assume you have 59K. Your address space is >0400 to >F000. You can put workspace in F000-F07E. F1xx-FFF9 is available. You write a makefile and invoke it with MAKE. In the makefile, you call ASM to produce object file(s). Then you call LINK to produce an executable. GENLINK has its own control file, listing the input, output, and special directives. It can do quite a lot, besides making one big executable. (for instance, overlays.) The specific things you'll have to replace with API calls are: Keyboard scan DSR access. VDP access you can leave as-is, provided you use Geneve specific equates for VDPWA etc. Console XMLLNK (and GPLLNK) will have to be replaced. MDOS has its own floating point API. Allocating and mapping memory pages to fill the space above your program If your Camel99 build system outputs object or binary on its own, you could make that work, too. 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 11, 2020 Share Posted November 11, 2020 On 10/28/2020 at 4:25 PM, BeeryMiller said: There was also McCann Software Forth for the Geneve. Several commercial applications were written by Mike for the Geneve including The Printer's Apprentice (TPA), and The Geometer's Apprentice (TGA). There may have been some fonts that went along TPA. Beery What has been done to preserve commercial applications? I realize some folks will treat things as abandonware, while others will not copy them. Another route is to track down the authors again. But I would really like to see these McCann products--I had only seen the illustrated full-page ads in MICROpendium. Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 11, 2020 Share Posted November 11, 2020 2 hours ago, FarmerPotato said: What has been done to preserve commercial applications? I realize some folks will treat things as abandonware, while others will not copy them. Another route is to track down the authors again. But I would really like to see these McCann products--I had only seen the illustrated full-page ads in MICROpendium. Mike's Forth program for MDOS is up on whtech in the Geneve area. I haven't looked for his The Geometer's Apprentice (TGA) or The Printer's Apprentice (TPA) he wrote for MDOS forth that are self execution programs to know if they are on whtech or not. I've got those disks myself, along with some font disks for TPA I saw the other day. I've tried finding Mike McCann, but have no idea what happened to him. As far as other commercial programs for MDOS, Bruce Hellstrom's Mouse Driver package is or at least should be, on Whtech. With Al Beard's Fortran package, and a few games for Abasic, I think everything commercial is out there on whtech including the GenProg package. Beery 1 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 11, 2020 Share Posted November 11, 2020 10 hours ago, FarmerPotato said: I would care about Camel99! I was just finding the GenProg documentation here: http://ftp.whtech.com/Geneve/mdos/MDOS Development documents/ For instance, this MDOS reference (it is kind of dated) and the collection of API calls documents. Manuals for GENASM and so on. From memory... I can convey to you that it's a breeze to build a MDOS native program with GenProg. Especially if your code is self-contained (no assumptions about E/A or console ROM). The source should just use RORG. Assume you have 59K. Your address space is >0400 to >F000. You can put workspace in F000-F07E. F1xx-FFF9 is available. You write a makefile and invoke it with MAKE. In the makefile, you call ASM to produce object file(s). Then you call LINK to produce an executable. GENLINK has its own control file, listing the input, output, and special directives. It can do quite a lot, besides making one big executable. (for instance, overlays.) The specific things you'll have to replace with API calls are: Keyboard scan DSR access. VDP access you can leave as-is, provided you use Geneve specific equates for VDPWA etc. Console XMLLNK (and GPLLNK) will have to be replaced. MDOS has its own floating point API. Allocating and mapping memory pages to fill the space above your program If your Camel99 build system outputs object or binary on its own, you could make that work, too. I understand most of that. (What does RORG do? Relative Origin?) I use my own cross-compiler so I can make it do whatever I need to but it does assume things load at a fixed address. LOL. Nope. No MAKE file here. Forth does all the building. Bootstraps-R-US Keyboard scan OK DSR access. Always tricky VDP access you can leave as-is, provided you use Geneve specific equates for VDPWA etc. - So re-write my equates file Console XMLLNK (and GPLLNK) will have to be replaced. MDOS has its own floating point API. - don't do this Allocating and mapping memory pages to fill the space above your program - Huh? I thought I had >0400 .. >F000 And... the likelihood of me getting it right without hardware in my location to test it would be very slim. I am just not that good. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 11, 2020 Share Posted November 11, 2020 RORG = Relocatable origin; defines the following data and instructions as relocatable, i.e. the loader determines the actual location where they are stored in memory. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted November 11, 2020 Share Posted November 11, 2020 Ears are perking up..hmmm Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 11, 2020 Share Posted November 11, 2020 1 hour ago, mizapf said: RORG = Relocatable origin; defines the following data and instructions as relocatable, i.e. the loader determines the actual location where they are stored in memory. How does that work? I have never built anything like that. The Assembler image has to flag that somehow I guess. Does the loader correct any addresses in the image or is everything relative to some reference value in the image? Although my Forth compiler's code is relocatable using PC relative branches, the location of the two stacks have to be initialized to something and there are system variables that point to various addresses in the system for parsing text and managing the linked list of labels. I would need to do some real study to make a RORG image I suspect. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 12, 2020 Share Posted November 12, 2020 1 hour ago, TheBF said: I understand most of that. (What does RORG do? Relative Origin?) 5 minutes ago, TheBF said: How does that work? I have never built anything like that. The Assembler image has to flag that somehow I guess. Does the loader correct any addresses in the image or is everything relative to some reference value in the image? Although my Forth compiler's code is relocatable using PC relative branches, the location of the two stacks have to be initialized to something and there are system variables that point to various addresses in the system for parsing text and managing the linked list of labels. I would need to do some real study to make a RORG image I suspect. RORG is the default setting in the TI assembler. The assembler produces tagged object code files, with directives for relocatable address (starting at 0), absolute address, etc. These are "EA3", DIS/FIX80 format files. The linking loader "corrects" or rebases relocatable symbolic addreses. If you are producing a binary file, in a PROGRAM type, this is also known as EA5, it is not relocatable. The 6-byte header at the start tells the EA5 loader where to put it, how long it is, and if there are more files. I'm sure you guessed that tagged object format is much bigger than PROGRAM binaries. It uses 5 hex digits to represent 2 bytes. A tag and 2 bytes. It also has checksum tags and symbol REF and DEF tags. A 'compressed' variant uses binary instead of ascii, so a tag is followed by 2 bytes 0-255. The linking loader knows the first free address in memory, and puts any relocatable segments starting there. It adds the starting address to local symbolic addresses in the object file, which are assembled as offsets from the program's start. On the 4A, loading begins at the high memory at >A000. If that fills up, it goes to low memory at >2000-ish. If your object file is relocatable, and the loader begins by putting it at >A000, the result is just as if you specified AORG >A000. Except, the first free address isn't updated. GENLINK is a lot more versatile. You tell it which address ranges can hold relocatable code. But it outputs a memory image (or set of images) that are binary dumps of that memory. It takes place virtually, so you can link into any address range, or produce more than one output that will be overlaid. The 4A linking loader only loads, it doesn't save PROGRAM images. To save images, you need to use TI's SAVE utility, or my SuperSave which does all the work for you. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 12, 2020 Share Posted November 12, 2020 (edited) Here is a sample GenProg build process: Source file SRCS Batch File DOIT ASM SRCS,OBJ,RS232,RLC LINK !LINK Control File !LINK ADD OBJ LIBREF LIB_MD STATUS SAVEALL PGM EXIT Command line: A:>DOIT ... GENASM loads SRCS, outputs OBJ ... ... GENLINK loads OBJ, outputs PGM ... A:>PGM ... PGM is loaded starting at address >0400, runs starting at >0400 Here is the file SRCS Spoiler REF PRINT subroutine from LIB_MD DEF START unnecessary LWPI >F000 B @START * first argument to the system call XOP KBOARD DATA 5 VIDEO DATA 6 MEMORY DATA 7 DSR DATA 8 UTILTY DATA 9 MATH DATA 10 .. equates and stuff .... START * Get and Map Memory the full 8 pages of RAM * fill up the 64K memory space * allocate our virtual pages 1-7 if they are not already LI R0,1 allocate memory LI R1,7 LI R2,1 SETO R3 use fast memory if available XOP @MEMORY,0 MOV R0,R0 JNE ERROR * map virtual pages 1-7 to logical pages 1-7 LI R1,7 IN0 LI R0,3 map memory MOV R1,R2 XOP @MEMORY,0 MOV R0,R0 JNE ERROR DEC R1 JNE IN0 * now do stuff BLWP @PRINT subroutine from LIB_MD TEXT 'Hello World!' BYTE 0 * maybe initialize a heap starting at SLAST * maybe initialize a stack extending down from >EFFE SLAST EQU $ END Edited November 12, 2020 by FarmerPotato oh crap I pasted my whole .plan file all 8k lines Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 12, 2020 Share Posted November 12, 2020 20 minutes ago, FarmerPotato said: The linking loader knows the first free address in memory, and puts any relocatable segments starting there. It adds the starting address to local symbolic addresses in the object file, which are assembled as offsets from the program's start. Yes this is the tricky part. I don't have a "local symbolic addresses" table. Code and data are interwoven in a normal Forth system. I could expand the compiler to create something but that is a PITA. I know the guys at MPE compile the Forth image twice a two addresses and then they can diff them to find the locations that need changing and compute the offsets from the load address. Makes my head spin a bit but I suppose I could do it. I would rather not. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 12, 2020 Share Posted November 12, 2020 Here is my command line to build the system. XFCC99 FLOAD CC9900\SRC.ITC\CAMEL99.HSF 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 12, 2020 Share Posted November 12, 2020 4 hours ago, TheBF said: I understand most of that. (What does RORG do? Relative Origin?) I use my own cross-compiler so I can make it do whatever I need to but it does assume things load at a fixed address. LOL. Nope. No MAKE file here. Forth does all the building. Bootstraps-R-US Keyboard scan OK DSR access. Always tricky VDP access you can leave as-is, provided you use Geneve specific equates for VDPWA etc. - So re-write my equates file Console XMLLNK (and GPLLNK) will have to be replaced. MDOS has its own floating point API. - don't do this Allocating and mapping memory pages to fill the space above your program - Huh? I thought I had >0400 .. >F000 And... the likelihood of me getting it right without hardware in my location to test it would be very slim. I am just not that good. In regards to #5, when you load a program in MDOS mode on the Geneve, the program load begins at >0400 and only fills upwards the 8K pages that will hold the image. After the 8K page, no memory has been paged in from the next 8K page boundary up to >E000. The address range from >E000 to >FFFF has a default page that is there. So, it is possible for a very short program, you would have a page at >0000 to >1FFF, and then by default, another page at >E000 to >FFFF. Between those address ranges, if you want more memory, you have to request it from MDOS through the use of a Memory XOP. You can request a list of all available memory (~1.5 MB if you have fully expanded 2 MB syste where MDOS is occupying some of the 2 MB memory and most users not having the last 128 MB ram that was reserved for an on-chip MDOS (PFM) so you do not have to boot from another device. The Memory XOP’s have a lot of functionality as you can request memory that can be shared between two multitasking applications for inter task communication, etc. There is a lot of potential there, just not widely used. ’ Beery 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 12, 2020 Share Posted November 12, 2020 1 hour ago, TheBF said: I would need to do some real study to make a RORG image I suspect. So never mind output tagged object format (RORG or otherwise). If you are going straight to a binary file, there are some bytes you put at the beginning for MDOS. GenLINK would do that for you (and it knows a lot of kinds of headers it can generate, including none at all) You are familiar with the 6 byte header on the 4A that tells EA5 where to load the PROGRAM file. This is something like that. I looked for documentation but I can't find any... So I opened an example in a hex editor. I see 0046 00 and the letter F 14B6 0400 this looks like a load address 1001 JMP $+4 5ac7 SZCB @02E0(R11),R7 certainly not code . let's go with DATA >5AC7 02e0 LWPI >F000 f000 0200 ... I think the byte 0 at the beginning means there are no more files after this one? BYTE 0 no more files after this BYTE 'F' 'F' is for fast pages , 'G' would be for slow pages DATA >14B6 length of this file. Max is >4000, beyond that you have to continue in next file DATA >0400 load address Help? Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 12, 2020 Share Posted November 12, 2020 10 minutes ago, BeeryMiller said: In regards to #5, when you load a program in MDOS mode on the Geneve, the program load begins at >0400 and only fills upwards the 8K pages that will hold the image. After the 8K page, no memory has been paged in from the next 8K page boundary up to >E000. The address range from >E000 to >FFFF has a default page that is there. So, it is possible for a very short program, you would have a page at >0000 to >1FFF, and then by default, another page at >E000 to >FFFF. Between those address ranges, if you want more memory, you have to request it from MDOS through the use of a Memory XOP. You can request a list of all available memory (~1.5 MB if you have fully expanded 2 MB syste where MDOS is occupying some of the 2 MB memory and most users not having the last 128 MB ram that was reserved for an on-chip MDOS (PFM) so you do not have to boot from another device. The Memory XOP’s have a lot of functionality as you can request memory that can be shared between two multitasking applications for inter task communication, etc. There is a lot of potential there, just not widely used. ’ Beery Beery, can you check my code in the file SRCS above? I put it together from bits I found on my floppy disks. According to GenPROG, it's harmless to allocate pages where you already have pages (it just fills holes). I'm not sure I ever used that .. I actually used BSS statements, a holdover from GPL programming. So to fill up the whole 64K with RAM, I think I make sure that pages are allocated up to >07, then map 1-7. Also I don't actually have the LIB_MD library, I just thought I would copy that example in. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 12, 2020 Share Posted November 12, 2020 41 minutes ago, FarmerPotato said: So never mind output tagged object format (RORG or otherwise). If you are going straight to a binary file, there are some bytes you put at the beginning for MDOS. GenLINK would do that for you (and it knows a lot of kinds of headers it can generate, including none at all) You are familiar with the 6 byte header on the 4A that tells EA5 where to load the PROGRAM file. This is something like that. I looked for documentation but I can't find any... So I opened an example in a hex editor. I see 0046 00 and the letter F 14B6 0400 this looks like a load address 1001 JMP $+4 5ac7 SZCB @02E0(R11),R7 certainly not code . let's go with DATA >5AC7 02e0 LWPI >F000 f000 0200 ... I think the byte 0 at the beginning means there are no more files after this one? BYTE 0 no more files after this BYTE 'F' 'F' is for fast pages , 'G' would be for slow pages DATA >14B6 length of this file. Max is >4000, beyond that you have to continue in next file DATA >0400 load address Help? Ok. That's something I can work with. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 12, 2020 Share Posted November 12, 2020 45 minutes ago, BeeryMiller said: In regards to #5, when you load a program in MDOS mode on the Geneve, the program load begins at >0400 and only fills upwards the 8K pages that will hold the image. After the 8K page, no memory has been paged in from the next 8K page boundary up to >E000. The address range from >E000 to >FFFF has a default page that is there. So, it is possible for a very short program, you would have a page at >0000 to >1FFF, and then by default, another page at >E000 to >FFFF. Between those address ranges, if you want more memory, you have to request it from MDOS through the use of a Memory XOP. You can request a list of all available memory (~1.5 MB if you have fully expanded 2 MB syste where MDOS is occupying some of the 2 MB memory and most users not having the last 128 MB ram that was reserved for an on-chip MDOS (PFM) so you do not have to boot from another device. The Memory XOP’s have a lot of functionality as you can request memory that can be shared between two multitasking applications for inter task communication, etc. There is a lot of potential there, just not widely used. ’ Beery So from this I could load my 8k micro kernel at >400 and then TAKE OVER THE WORLD! ? Thanks Beery 1 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 12, 2020 Share Posted November 12, 2020 1 hour ago, FarmerPotato said: Here is a sample GenProg build process: Source file SRCS Batch File DOIT ASM SRCS,OBJ,RS232,RLC LINK !LINK Control File !LINK ADD OBJ LIBREF LIB_MD STATUS SAVEALL PGM EXIT Command line: A:>DOIT ... GENASM loads SRCS, outputs OBJ ... ... GENLINK loads OBJ, outputs PGM ... A:>PGM ... PGM is loaded starting at address >0400, runs starting at >0400 Here is the file SRCS Hide contents REF PRINT subroutine from LIB_MD DEF START unnecessary LWPI >F000 B @START * first argument to the system call XOP KBOARD DATA 5 VIDEO DATA 6 MEMORY DATA 7 DSR DATA 8 UTILTY DATA 9 MATH DATA 10 .. equates and stuff .... START * Get and Map Memory the full 8 pages of RAM * fill up the 64K memory space * allocate our virtual pages 1-7 if they are not already LI R0,1 allocate memory LI R1,7 LI R2,1 SETO R3 use fast memory if available XOP @MEMORY,0 MOV R0,R0 JNE ERROR * map virtual pages 1-7 to logical pages 1-7 LI R1,7 IN0 LI R0,3 map memory MOV R1,R2 XOP @MEMORY,0 MOV R0,R0 JNE ERROR DEC R1 JNE IN0 * now do stuff BLWP @PRINT subroutine from LIB_MD TEXT 'Hello World!' BYTE 0 * maybe initialize a heap starting at SLAST * maybe initialize a stack extending down from >EFFE SLAST EQU $ END i believe that should work once you add a label for ERROR. Myself, I get the map with the following code: LI R0,4 LI R1,PGETBL LI R2,8 XOP @MEMORY,0 MOVB @PGETBL+1,@>F111 MOV @PGETBL+2,@>F112 MOV @PGETBL+4,@>F114 MOV @PGETBL+6,@>F116 I get the map for the pages I requested and manage mapping pages myself without calling an XOP. I've tried some of the memory XOP functions in the past, but you really have to be careful you call things correctly or things may not map where you think they should. Beery Beery 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 12, 2020 Share Posted November 12, 2020 16 minutes ago, TheBF said: So from this I could load my 8k micro kernel at >400 and then TAKE OVER THE WORLD! ? Thanks Beery And I am sitting here watching Season 1, Episode 3 of NEXT where an AI is learning and expanding it's reach............... 2 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.