InsaneMultitasker

ROS 8.42c has 16 bytes available in the affected DSR segment. My proposed fix requires 10 bytes. There are additional uses of >83D2 within ROS, for auto-start and some of the CALLs that are executed via the MENU or via BASIC. I don't think these will affect the PCODE card. Does the ROS autostart feature override the PCODE startup? If so, the ROS autostart bypass key (SHIFT) might be an option to cede control to the PCODE card, for a manual dual-boot configuration. I am ready to compile the fix into a usable ROS file for you to test before I move to release stage. If interested, let me know when you would like to try it.

I've been asked about the Scotty reference; here is the relevant clip from Star Trek The Next Generation episode Relics. I have fond memories of meeting Mr. Doohan at a Gencon convention in Milwaukee, where he stayed 45+ minutes after closing to see all of us who were still waiting in line to meet him. I have the card and photo he signed that day. Such a gracious person.

I had one of those "aren't you glad you are too busy to quickly complete tasks" moments this week. Yesterday, I was searching for an empty 3-ring binder when I came across my old Sony Handycam DCR-PC100. In the same plastic tub were a few digital tapes and 8MB memory sticks (and a PCMCIA card reader!) with vacation, wedding, and various other memories from 20+ years ago. I never got around to transferring anything to a computer probably for lack of time and maybe even due to hard drive capacities/cost. I started to refamiliarize myself with the device. Everything worked quite nicely except the batteries, no real surprise there. Alas, I could not figure out how to transfer the files. SVideo and composite did me no good. I found a cable labeled "serial" that had a USB square connector that plugged into the camera but the other end was a 6-pin connector that didn't look familiar to me. After fast-forwarding through a few of the tapes I started to get ready for bed and that's when it came to me: could this be a firewire cable? My old Shuttle SB51G Pentium 4 has firewire at the front of the case, like this: A few weeks ago, I had torn down my SB51G with the intent of recycling it. I had not yet wiped the hard drive so I put all the parts back together, fired up the PC, logged into Windows XP, and plugged the firewire cable into the port. I was pleasantly surprised that Windows Movie Maker launched and asked me how I wanted to capture the video from the camera!! After mucking around a bit, I successfully transferred my first video and now I have another new project. Usually, I discover that I need something shortly after I get rid of it. Fortunately, this was not one of those times!! Here's a picture representative of the camera. The 120x zoom was really fun to use during a trip to the Canadian Rockies.

I added these two documents to Github and updated the wiki links. I will upload previous guides and manuals that I have collected. I'll post another reply when that happens, and if someone has additional files or better copies of the same file(s), I would be more than happy to add/replace.

the 4GB IDE flash looks like a great option and the price is right. Even with the maximum partition size (248MB) and using all allowable partitions (4 or 8, I forget the max per drive), you will only use at most half of the CF capacity. Seems like one of each port is a reasonable approach, maybe even a good compromise and keeps things "simple". For reference, with my SCSI card configuration I use a SCSI2SD device with 7 available partitions and I typically only use 1-2, with others used for backup or testing. Of course, each person will use the IDE card and storage differently.

Just a quick comment: there were a few iterations of the dsrlnk that made their way through the list server long ago. Some of the participants are still active in this forum. If the conversations were preserved, they may be of some value as well. I do not recall if the final iteration was well documented.

It's good to have replacements, especially for cards that were never fully populated. Based on my not-infallible recollection of repair work, the hard-to-find chips that failed were typically the 9216B, 9223, 9226, DS1000 and 9234 in order from most often to least often replaced. I may have 1-2 spares of a few of these chips having exhausted most of my stock over time. The logic chips, particularly those connected to the edge connectors like the LS240 and LS374 and especially the LS31/LS32, were always prime suspects for a failed card. These are still available though not always the brands, like National parts, that were best suited for the circuit.

Improved enough for the card to operate under general usage. The regulators are original components. The two heat sinks may have been added at build time or later, in response to the failures experienced by other owners without proper heat sinks. The regulator above the LED is missing a heat sink but you can see that someone scraped away the blue/green top layer, which may have been an intentional attempt to let the card draw away some of the heat.(Not a good idea). It is hard to tell from the picture but I would guess (and expect) the capacitors are original parts as well.

This is a common problem with the original Geneve cards, especially those without heat sinks or without thermal compound between the heat sink and regulator. Be sure to use both with your replacement, unless you decide to use the DC-to-DC converters as discussed in prior posts. The DC-to-DC converters are cool to the touch. The VDP RAM on the other side of the card is subject to eventual failure, especially the chip adjacent to the regulator. A proper heat sink will mitigate the heat issue in most cases. I replaced the regulator with a DC-to-DC converter on my 24/7/365 Geneve because the VRAM kept failing over time. This is especially noticeable with Extended BASIC and other VDP-intensive programs. And since most disk DSRs also use VDP, failure can cause file content corruption in extreme cases.

Good catch. I removed the link t0 v7.30 and updated the forum links in the GenCFG section. The old links still resolved e.g.,"atariage.com\forums" but it seemed better to refresh with the correct construct "forums.atariage.com".

Th first post of this topic has links to the release posts.

Source code for the most recent release of GENCFG has been uploaded to the Horizon Ramdisk github repository. These are text files without an extension, copied directly from my TIPI 'native text' folder, so they are immediately viewable and searchable via github. Horizon-Ramdisk-ti994a/GENCFG at master · horizonramdisk/Horizon-Ramdisk-ti994a (github.com)

I've seen various DSR routines and in particular, MDOS, pass error codes and other values via R0. The "@Rxx*2(R13)" construct is a nice, clear alternative.

Updated Horizon Ramdisk User Manual, with a copy uploaded to Github. The next ROS and/or CFG release will be version 8.43, to address a few of the logged issues since 8.42c. And to loosely paraphrase Scotty, there will be "no bloody a,b,c or d" nor other letters of the alphabet added to future version numbers. HORIZON RAMDISK USER OPERATING MANUAL 9-12-2023.pdf

lol, indeed. Apparently, some formatting or style setting is affecting the spellcheck routine. If I copy the plain text into a new Word doc, the editor finds the mistakes. Alas, I forgot just how obnoxious Microsoft has made a once-simple task; instead of a fixed location, the Editor's spell check window happily moves around the screen to each misspelled word. After accepting 50 or so TI-specific terms, my eyes have had enough. The Editor can check itself out permanently and I'll leave the rest of my questionable words as-is. /rant

When you know words are misspelled but neither Word 365 nor LibreOffice report the offenses.

I added an entry to the issue tracker with a link back to this thread. Today I made a few edits to the user guide and reviewed the open issues. My goal is to update the repository before I make any more code changes.

This is in response to the conversation from the 4000B topic. I re-read our posts from a few pages back. If I understand the PCODE startup process, the system identifies the peripherals and caches the sector IO subroutine address. The problem with the Horizon Ramdisk ROS is the common entry point and the use of >83D2 (SRHADR), since the latter doesn't exist as "defined" once the PCODE system is operational. Instead of reworking the level 2 table and its common operation, would a simple fix like this suffice? The proposed change would bypass SRHADR for sector routine >10. The follow-up question is whether the common entry point the only stumbling block? NEXT0 DATA NEXT1,SECPCO, TEST,>0110,SECIO Sector Input/Output ;pcode fix secpco lwpi hiws li r1,next0 ;intercept >10 and bypass >83D2 usage jmp tstpco ; common entry from the subprogram table for >10,>11...>15 TEST LWPI HIWS Load our workspace MOV @SRHADR,R1 Get pointer to CALL table tstpco MOV @6(R1),R11 Get address of CALL program MOVB @>834C,R2 Get drive # for this CALL

Ah, right under my nose, so to speak. I will post a response in the development topic. I found my notes and what might be as solution for the PCODE system, provided my assumptions are correct.

The SAMS detection seems to work ok in Classic99. I don't have a real SAMS card to test on real iron so barring anyone seeing a problem with the routine, I'll keep it in CFG for the next release.

None from an execution perspective. It's just an old habit of mine for readability. When a routine passes info between multiple registers, my eye catches the "@xx(R13)" and helps me to not miss R0 along with other register passing. If I was concerned about space or speed, I would use the *R13 approach or forgo the entire routine and its workspace.

When I looked at the issue long ago, there wasn't sufficient space to do anything about the problem. Since then, some code has been moved around and although I don't know if it is possible to correct, we can certainly revisit. As I recall, you wrote up some good information about this n the past. If you know where to find that information and / or could submit the details as an issue in the ramdisk github repository, that would be very helpful. Here is a link to the issue tracker: https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a/issues

I am revisiting code for a simple, non-destructive SAMS detection routine. The Horizon RAMdisk configuration program (CFG) tests for SAMS but it gets tripped up if a previous program modified the mapped pages to something besides the default. Since SAMS doesn't map memory into the DSR space >4000-5FFF, the new routine reads/writes the corresponding register and if the value doesn't change, I assume SAMs is not present. Will this routine pose any problems for the larger capacity cards or general usage? ; Non-destructive simple test for SAMS ; ; Copy mapper value for >4000-4FFF bank, ; modify it and if mapper register changes, assume SAMS ; Caller's R0 is modified. 0=no sams, <>0 SAMS ; H0101 data >0101 SAMSDT DATA PLAYWS,$+2 clr @0(R13) li r12,>1E00 sbo 0 mov @>4008,R2 ;save whatever was in the mapper for >4000-4fff a @H0101,@>4008 ;change the value c r2,@>4008 ;is it still the same? jeq noams ;yes. can't be SAMS seto @0(R13) ;no, assume SAMS mov r2,@>4008 ;restore, for futureproofing noams sbz 0 rtwp

Still looking for CHART. Anyone? It seems that I never uploaded these last few changes to Github, so I'm sorting through the code today. There is also a problem with SAMS detection if a previously run program changed the default mapping, so I may end up removing that routine for the time being. SAMS detection is neat but not necessary for program operation. There is also an experimental option that tries to pull ROS from Github via TIPI but I don't think that Github allowed me to pull the binary file in that fashion, so I'll probably disable that too.

100% agree on the stability factor.