Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


InsaneMultitasker last won the day on August 18

InsaneMultitasker had the most liked content!

Community Reputation

1,936 Excellent

About InsaneMultitasker

  • Rank
    River Patroller

Profile Information

  • Gender
  • Interests
    TI-99/4A, Geneve, terminal emulation and BBSs, Anime ;)

    Employee of Cecure Electronics (1990s) where I repaired and upgraded Myarc & TI hardware.

    Geneve librarian for Milwaukee Area TI User Group

    SysOp of HeatWave BBS, operating on real hardware at 38.4Kbps. See signature for current Telnet address.

    Author of S&T BBS Software and other TI/Geneve programs

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for sharing. I'll need to poke at the handful of groups (including the files and bug tracker database sections for the Geneve group) and pull down anything I want to keep. Yahoo certainly did the groups no favors over the years. Sad.
  2. This may not qualify as "strange" per se: a TI-99/4a on my high school Geometry teacher's desk which later resulted in being allowed to submit an XB-based Geometry program for my end-of-semester project.
  3. Yes, I do, and I believe that version 4.04 source is available on the WHT ftp site and/or the Geneve Yahoo download area. (The interpreter is a bit finicky. For example, it kept telling me a subprogram was not found until I moved it to a different line number. Early suspicion is that the subprogram name search is looking pseudo-alphabetically and gets tripped up when names are out of order. )
  4. Does anyone use Myarc Advanced BASIC these days? I found and fixed two bugs this past week: 1. When used inside a program, the RUN command generated a "LINE NOT FOUND" if a line number wasn't provided. For programs that re-run themselves to reset, this was a nasty little bug. The line number table was being tested incorrectly during run-time mode (it works fine in immediate mode). Fix in 168.RTCMDS 2. If a program was auto-loaded from device.LOAD or via the OS command line, the CTRL-C breakpoint pointer was never set. (ctrl-c is used in place of FCTN-4 to halt a program). Modified the startup routine to always set the pointer. Fix in 164.cmdint56n. (I am not clear on why CTRL-C was used as it is periodically used in programs for input, which in turn now halts the program; was it for MDOS task convention, simplicity, or some other reason?) 3. Changed the internal name from "Myarc Advanced BASIC" to "Geneve BASIC". Version 4.06. I have a few more bugs and annoyances that I am trying to hunt down as I play with the BBS in this environment.
  5. Quite possible and likely. JJs de/encrypt program made the encryption mostly irrelevant but for backward compatibility, the routine remains in the OS. The simple XOR process may be related to a different program that was written to obscure title screen and credits, thus thwarting people's efforts to edit out program credits, authorship, copyright, etc.
  6. If memory serves correctly, the Geneve "encryption" is a simple XOR of each byte in the file. When the OS loads an 'encrypted' program it is therefore a simple operation to 'decrypt', requiring no key or special computations.
  7. If at first you don't succeed, you may be trying to successfully perform a demonstration at the Chicago TI Faire. Corollary: a failed demonstration at the Chicago TI Faire will always succeed after the allotted time has expired.
  8. I thought it was a safety measure intended to minimize accidental GROM page access when in 9640 mode (OS, XOPs, interrupts etc). If grom access was enabled at all times, writing to the port addresses and their mirror addresses could trash bytes in the 8 gram pages. Was it designed this way up front or was the effect found later and fixed with this weird page requirement? Lou might remember, not sure anyone else would know...
  9. lol, true, though my workbench would probably have a few choice words to say if it weren't an inanimate object!
  10. In a nutshell: TI: up to 10 x 800K ramdisks, using ROS 8.34 or above. 10 x 400K ramdisks using ROS 8.14F. Geneve: one 3.2MB RAMdisk using FORM3MEG //or// MDOS 7.00 allows both an 800K ramdisk (for booting) and the remaining space can be formatted to look like a hard drive (I have compiled all of MDOS on a RAMdisk). The latter option is delayed until I figure out what is wrong with MDOS 7.00... Jim, we should amend the Phoenix references as I don't think any of that works with the Geneve these days, save for the dual ramdisk option - and even that would need to be tested.
  11. Hi Beery, For now I am just playing* with the assembly code in an attempt to better learn and understand some MDOS mysteries. Getting back into some programming has brought up thoughts of whether or not to migrate HW to ABASIC, and whether or not to change my mind about retiring the system this year. I would say it is too early for me to make any decisions and I'll just play by ear. (*My programming time is limited to at most one day a week due to job demands and the changes I'm making to further improve my health, like more cardio, etc.)
  12. One more key piece of information is that the TI Mode program "GPL" accounts for this one byte offset during the initialization and load processes. At initialization, GROM0/1/2 are copied into pages >38,>39,>3A with a one byte offset. The same process occurs when GPL loads a GROM cartridge file into one of the GRAM/GROM banks. ROM is copied without an offset. If I remember correctly, programs like BOOT for the TI won't properly load cartridges into the Geneve. Here is some relevant info from J.P. Hoddie's programming notes:
  13. Very good information and insight. One question: for item number one, did you mean to say an additional 2k (for a total of 8k) or am I misunderstanding the intent of this statement?
  14. Speaking of things taking a long time, this weekend I had the urge to revisit running BBS software on the Geneve using Myarc Advanced BASIC. The advantages include all-assembly interpreter so it is quite fast, 48K of assembly routine space, and 56k of program space. I forget how much stack space is available - probably 48k. Back in 2013 I fixed a bug that inhibited passing parameters with CALL LINK but I had trouble with IO routines. Well, thanks to some suggestions from Beery I was able to find a solution. Here is the SysOp side of the BBS running in 80 columns natively in Advanced BASIC. (For my testing I am using the 2004 distribution package). The top status line is still formatted for 6 lines of 40 column text (3 x 80). (Full boot time is about 8 seconds, roughly 3 times faster than the current HW running in Extended BASIC. ) (Clarification: The BBS is XB/assembly hybrid but all of the core file IO, rs232, and screen display support is done via assembly for maximum speed)
  15. The address is 63D1, not 64d1. BOOT checks this address for the gosub/branch to the autoload routine via 648e.(the comment is misleading). A special interrupt routine handles updating the load filename. I'm pretty sure the person who provided the XB loader routine, Paolo Bagnaresi, knew a bit about GPL and XB.
  • Create New...