InsaneMultitasker
-
Posts
4,516 -
Joined
-
Days Won
1
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by InsaneMultitasker
-
-
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.
-
3
-
-
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.
-
9
-
-
On 6/10/2020 at 8:45 PM, Ksarul said:
I'm attaching the final version (along with the schematics) here. Hopefully that helps you and others building their own boards.
HRD 4000B Construction Guide (Final-2).pdf 4.53 MB · 108 downloads A3-Horizon 4000B RAMDisk Schematics (Final-1).pdf 300.3 kB · 101 downloads
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.
-
11 hours ago, Shift838 said:
This would reduce the price of the card by about $20 doing this while allowing connection of a 44 pin IDE as well as a 40 pin. I can add a power header on the card as well to be able to plug in power if needed (CF 2 IDE & SD 2 IDE requires power)
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.
-
1
-
-
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.
-
2
-
2
-
-
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.
-
2
-
-
2 hours ago, mizapf said:
So was my Geneve already improved when I bought it in 1990? (concerning the heat sinks, not the battery or SRAM expansion, that was me)
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.
-
3
-
-
7 hours ago, F.G. Kaal said:
Then I found a problem with the 7805 voltage regulator (M76) close to the CPU DRAM chips. This one got very hot. The voltage regulator problem is also mentioned in this topic by the way! After a few minutes the output voltage of this regulator dropped to 3.1 Volt. After swithing the PEB off for a few minutes to let things cool down I could boot MDOS again.
This can be easely fixed by replacing the voltage regulator(s).
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.
-
5
-
-
9 minutes ago, RickyDean said:
Oh @InsaneMultitasker, going into your Github above, as I move to your wiki at https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a/wiki, I find an issue. When I click on the hotlink
- GenCFG - Geneve configuration/formatter with disk and 'ramHD' partition support; see MDOS 7.30 release (https://www.9640news.com/mdos/mdos-7-30-released/)
I get a page not found report. FYI.
Thanks for your contributions to our hobby.
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".
-
1
-
Th first post of this topic has links to the release posts.
-
1
-
-
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)
-
1
-
-
3 hours ago, FarmerPotato said:
I looked through some TI source code and (longtime TI-990 engineer) Dave Pitts' C runtime for 990. It is full of "@R1*2(R13)" type addressing modes. But no "@0(R13)". It seems like an unspoken rule that R0 shall not be used for parameter passing! I did not find any *R13 either.
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.
-
2
-
-
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
-
6
-
2
-
-
9 minutes ago, OLD CS1 said:
Spell-checker checked out on you.
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
-
1
-
-
When you know words are misspelled but neither Word 365 nor LibreOffice report the offenses.
-
1
-
-
25 minutes ago, apersson850 said:
I think it is the only issue. The p-system doesn't use anything but the sector access routine. It implements it's own file system on the disk
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.
-
5
-
-
On 5/8/2020 at 6:07 AM, apersson850 said:
On the second line, the MOV @SRHADR,R1 is supposed to get the address of the found subprogram in the DSR. The address SRHADR is >83D2, which works with the console's operating system, when it uses its DSRLNK routine to find the proper DSR. This is a clever trick to make the DSR code smaller.
The p-system, however, uses a more efficient method to call a DSR than the regular DSRLNK routine does. With this method, the address of the desired program in the DSR program isn't available at >83D2, so this clever trick backfires.
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-
1
-
-
1 hour ago, apersson850 said:
That I could very much believe in. Do you want me to look up the small DSR I wrote, that is compatible with the p-system? Or some verbal description? Both, maybe?
Here's a link to a post where I described what the issue is.
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.
-
1
-
-
5 hours ago, apersson850 said:
Is there any specific advantage with using CLR @0(R13) and SETO @0(R13) compared to smaller and quicker CLR *R13 and SETO *R13?
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.
-
3
-
-
5 hours ago, apersson850 said:
Was anything done to mitigate the incompatibility with the p-system? Although I made my own "ROS stub" to make it compatible, it would have been nice if the standard one would work too, since my verison only supports the p-system.
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
-
3
-
-
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 -
On 7/24/2021 at 4:01 PM, InsaneMultitasker said:
Does someone have a copy of the CHART file that is required to interpret the TST program results? I've been asked to incorporate it into the distribution. In the meantime, I had a few free clock cycles today:
- Post #1 has been cleaned up to show only the most recent release files
- CFG now prohibits the user from selecting the "transparent color" for foreground/background
- When loading/saving ROS, the file IO routine error trap now informs the user there was a disk/file error
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.
-
2
-
1
-
On 9/7/2023 at 11:54 PM, retroclouds said:
It’s incredibly stable (thanks @Ksarul) and it has so many features that I even’t have touched on.
100% agree on the stability factor.
-
2
-
Usually, I discover that I need something shortly after I get rid of it. Fortunately, this was not one of those times!!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Horizon RAMdisk ROS and CFG Development
in TI-99/4A Development
Posted
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.