Jump to content

9640News

+AtariAge Subscriber
  • Content Count

    2,479
  • Joined

  • Last visited

Everything posted by 9640News

  1. Thanks Wolfgang for it. Looks like I need to go back and review that script that creates the DV80 files. Just for others, this isn't a TIPI issue, rather an Excel script issue trying to create some DIS/VAR 80 files. I've got some other programming I am working on now, but I have this next week off from work and will try to get to it. Beery
  2. All of 9640News was released to the public domain some 15 to 20 years ago. It is available for download at several locations: Index of /Geneve/9640 News disks v1-3/9640 NEWS disks for Geneve (whtech.com) 9640 News | Jedimatt42
  3. Actually, I would plan on all editing to be on the Geneve and not Windows. When things are ready to go to GitHub, copy files and/or subdirectories from HFDC to TIPI. Then, launch the Windows program to send files up. If someone else does an update, then send the files back down to the TIPI where I can then move them back to the HFDC. Beery
  4. I see what you are reporting, but not being familiar with Cygwin or python, I would have never gotten there. I'm not a linux or python user, so that is a bit beyond my skillset at the moment. What I am hoping someone will do ( @shift838 or someone else with the skills if they are listening) will have is an installer that sets everything up on various systems (Windows a must), and then you give it a path you would like to move to<>from and it either being smart enough to do the conversion on the fly, or you tell it, and it is done from Github. Simplest scenario, I launch a Windows program, point it at the TIPI for the source file directory (and potentially subdirectories). Then, point it at Github, and necessary files move from one destination to the other with DIS/VAR 80 files converted to TXT files as needed and other formats (Program Files, others??) remaining untouched. I think at that point, more users will feel comfortable setting things up.
  5. I've seen comments clipped as well in the approach I was using last night where the comments exceeded past column 80. Last night, I finished going through about 10 files addressing comments that exceeded line 80 as well as some other issues that needed to be changed for GenASM compatability. Beery
  6. Matt, I have downloaded and been going through your TIPI DSR code and trying to convert the code to DIS/VAR 80 files that can be assembled with GenASM. I want to confirm something to make sure my understanding is correct with respect to the macros in your code. You have a line of source such as listed below along with the macro definition: .setvdpwa R1 ; Macro - Set VDP write address .defm setvdpwa ORI #1,VDWRITE SWPB #1 MOVB #1,@VDPWA SWPB #1 MOVB #1,@VDPWA .endm Now, if I understand things correctly, the macro .setvdpwa R1 would assemble inline as the following source: ORI R1,VDPWRITE SWPB R1 MOVB R1,@VDPWA SWPB R1 MOVB R1,@VDPWA If that is the case, then what I will end up doing is redefining it into a format for the GenASM macros. Where I am going with all this is to explore having a modified DSR that can be embedded in MDOS to permit some limited file capabilities such as getting a directory, launching a MDOS program from the TIPI, and maybe some file copying. In a sense, the code would embed as a new XOP. Using some modified utilities (XDIR, XCOPY) with specific coding for the TIPI that recognize this new XOP, then one could have some limited file i/o on the MDOS side of things as a start as well as executing a MDOS program directly from the TIPI. At that point, then it lays the foundation for connecting the master DSR to the TIPI if it is possible. I say "IF", because the coding on page boundaries is already tight with the HFDC, SCSI, and the CLI that tackling it straight on may be too big of an immediate step because too many things will break all at once. Beery
  7. Well, that's the first time I have seen the magazine, and can say I am quite impressed with what they produced.
  8. I tried another route, essentially downloading the TXT files through XMODEM which saved the files as DIS/FIX 128 since there were no TIFILES headers. I then used a program from Al Beard, TRANSFORM, for the Geneve that would read the DIS/FIX 128 and convert to a DIS/VAR 80 file. It stripped out the CR/LF issue I had, however, the labels were all screwed up and the first few lines of each file was missing. Not sure what was going on, so that is when I went back to MyWord to find a solution. We really need to find a method with some very clear step by step directions to transfer DIS/VAR 80 source up to and back down from Github without all these hurdles. I know some have mentioned some tiimagetool (???) features, but a clear set of tool(s) to automate a single file to a hundred or more source files at a time would be an asset. The simplest tool I could think of would be an interface function that goes talks with some tool that sends commands to GitHub to get the files, then saves the files with TIFILES headers to the TIPI. Then, if something needed to be uploaded, it would send the other way with some method to mark directories and/or individual files. I say this as there is code like FunnelWeb, MDM5, MDOS, MyWord, ABASIC, PSystem, HRD4000B+, and a host of TI-99/4A programs where this would be extremely beneficial. Not to discourage anyone from using GitHub, but it would be very helpful if comments did not exceed past column 80 as those comments get scrolled to the next line and an assembler will want to treat it as an instruction or honk for an error. Also, not sure whether the asterisks character is an allowable character for adding comments within the source on the xdt side of things. I have not played with xdt to know if comments after the instruction have to be commented with the semicolon or not. Commented source code looks great, but if comments without a semicolon is a problem for GitHub, then it really limits the ability to upload older source code. Like I said earlier, I pulled some code down from GitHub written to assemble, etc. with xdt that is not directly portable to the Geneve that I will spend several evenings porting it over into a format suitable for GenASM to process. It's great the code was posted so don't get me wrong, however it would not be easily portable back into the Editor/Assembler assembler nor GenASM for the Geneve.
  9. Wolfgang, if you are doing anything with MESS and Geneve Emulation, you should be able from the MDOS to type MW which will launch MyWord from the MDOS prompt. From there, you can type PE which will put you in Programming Edit mode on MyWord. That's likely already my default environment. Now, I just went through an ordeal in removing some CR/LF's from a text file I got from Github loaded from the TIPI into MyWord. If you are using MyWord, look under the HELP feature. From there, under the Control Keys command. I was able to use a Replace String Function typing a "/" (no quotes) CTRL-U and then I forget the specific character after that then CTRL-U which I think is what disabled the control Mode), then "//" . Effectively this replaces the character I was seeing on the screen which looked like a "dot" and a very small "9". I don't know if TI-Writer has those capabilities or not. In my case, I was saving files to the TIPI from the Windows PC, then using MyWord loading the file from the TIPI. I know the TIPI can load .TXT files, and the formatting was not clean for source code, but I got things across. There is still some cleanup, but I had over 1000 such characters to replace that the Replace String function made things easy. Beery
  10. Sounds like the found the culprit. Glad my suggestion helped!!!😁
  11. It's probably one of the yellow or blue wires, and if not them, then one of the red wires. 😀
  12. Ditto to Vorticon's comments. I'm following this topic to see your progress as I am interested in the finished product. Beery
  13. Will the Program Counter on real hardware allow execution of code on an odd boundary? I did not think it would allow that. I know back when Geneve support was first added to MESS, I found one or two instructions that did not 'autocorrect' for an even boundary that then threw the emulated 9995 into executing code on an odd boundary. On the real hardware, the very same code did not allow that to happen. Beery
  14. HEX01 BYTE >01 EVEN or better to include all your BYTE/TEXT labels as a group whenever possible. HEX01 BYTE >01 STR1 TEXT 'Hello World!" HEX02 BYTE >02 HEX03 BYTE >04 STR2 TEXT 'See you another day.' EVEN By grouping all possible odd length strings and bytes together, the use of EVEN results in at most only a single byte of extra space used if there was an odd length to all the statements. Beery
  15. I've seen the GenProg file move around, disappear, reappear, disappear, etc. a number of times on Whtech. It always makes me nervous when things are moving around as I wonder if at some point it will just disappear and I will be the only resource. Now, just about everything I do I am trying to release things into a large enough domain that hopefully someone will have archived the program should someone ever desire to seek the program or code again. Beery
  16. I received more than enough thanks back in the day. The big guy to thank now is @InsaneMultitasker for all his work and efforts he has put into the updates along with people like Mike Maksimik, Clint Pulley, Alan Beard, Jim Uzzell, James Schroeder, and others throughout the years. Without everyone's support, we may have had the source code, but not the talent to further its development. As it is now, just about all the work has been done by Tim. He inquired about my assistance with the TIPI interface to the master DSR a few months back, but I was so far behind the times and really far behind on the DSR coding, I would have been a hindrance to where he has the current work. Beery
  17. If someone wants to ever add more information to the GenASM docs, I have the original Word Files that were used to generate those docs. Most of it is Paul's original text converted from a much older (unix???) document program, however the docs on the Video I think I put together on everything I could find/learn. There is an outside chance some of the XOP video opcodes could need an update as there were some things Jim Uzzell and Clint Pulley may have added or requested over the years. Beery
  18. When I wrote Windows 9640, I had done quite a bit of disassembly of various pieces of MDOS along with a number of questions to Paul to understand various pieces of memory. While using Bruce Hellstrom's memory CPU/VDP viewer and it also has a built-in disassembler (assembly source code is also out there), you could watch the timer decrement from a >06 to >00, and if there were other tasks in an active state, it would switch to the next task. You could also control the amount of time allotted by a task by changing the value of that one byte to give it a shorter or longer lifespan. I passed some code on to Bruce, and from it, Bruce wrote a mouse driver for both the Geneve Mouse, as well as a separate driver for an RS232 based mouse. It created a "control register" area in memory that would return mouse button movement/position, mouse button status, etc. to ease mouse useage. I'm not sure if Mike Maksimik implemented the mouse driver in CFORM, but I think Al Beard did with his GenBench Shell package. Now, many years later, Windows 9640 itself wasn't all that great of a program, but it did have some useful functions with its XOP that were part of the program. It wasn't until after I released Windows 9640, did Lou Phillips show me what @webdeck had been doing with GEME which was truly some great unfinished work. I still look at his code from time to time, and have tried to do some things such as a new program with his code base, but things got sidetracked. I did write some other code years later that demonstrated the capability to do a TSR type program that installed within MDOS that could be activated by a keypress. I don't recall who made the inquiry anymore, but I spent one afternoon putting the pieces together and writing some example code demonstrating the capability. That example I think is on the MAME HD image (directory TSR??) that some have, as well as in the Files section of the Yahoo Geneve group dump. Beery
  19. And I am sitting here watching Season 1, Episode 3 of NEXT where an AI is learning and expanding it's reach...............
  20. 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
  21. Tim, Did some more testing. With MDOS 7.00 in Rompage mode, with DM2K I can copy two directories deep from WDS2 to DSK0 no issue. With MDOS 7.00 in normal mode, with DM2K I can NOT copy the first file under the the marked directory (with subdirectories --- aka MDOS source). It chokes on the first file, as the MDOS directory is not made so it can't copy the file to the TIPI. This sounds like a limitation of the master DSR in GPL mode. At least now, there is a way to backup hard drive files on spinning devices out over to the TIPI versus using floppy disks. Beery
  22. 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
  23. Thanks for the update.
  24. That's pretty impressive. Is it individual frames you have buffered, then moving to the display screen? Do you recall what the resolution and frames per second were?
  25. I should also add I was trying to copy a directory that additional sub directories underneath. Beery
×
×
  • Create New...