Jump to content
IGNORED

Trying to learn TI programming


Pheonix

Recommended Posts

My bad, I was miss-remembering what I read on it. It was a DIY kit to build a controller, and not a MOD.

 

So, it would take a totally new HW design to get HD on the TI-99/4A. From what I've been reading, there's nothing stopping the TI from handling it if the HW & DSR are set up right. I'm mainly just curious at this point. I want to replace the SSSD drive in my PEB with a standard 3.5" & 5.25" drive, and don't really want to worry about only using DD floppies (so the drive won't choke,) or modding the drive not to detect HD disks. That's the issue I'm facing with my Amiga. Get an adapter to use a PC floppy, and you have to either MOD the drive, Use only DD disks, or use tape to block the HD hole to prevent the drive from trying to go into HD mode (which the Amiga can't handle.) So, I have several options for installing a 5.25" & 3.5" drive, but they are all DD and not HD. I can live with that. Don't really want to MOD a 3.5" floppy (and finding a DD drive is problematic.) Now, I'm just faced with the fact, that none of those options are easy to find for sale (did a quick search.)

 

On the HDFC card, is it a HW issue or SW issue that stops the TI-99/4A from using HD drives? Is MyArc still around, or would it be safe(ish) to re-write the DSR & put them on EPROM(s)?

Link to comment
Share on other sites

 

On the HDFC card, is it a HW issue or SW issue that stops the TI-99/4A from using HD drives? Is MyArc still around, or would it be safe(ish) to re-write the DSR & put them on EPROM(s)?

 

Software. The HFDC is capable of high density provided the 9216 data separator has been replaced with its 9216B counterpart. If the AU and cluster allocation calculations in the HFDC DSR were updated, it would be able to use high density diskettes properly. Unfortunately, the DSR source we have is incomplete, and there wasn't enough interest on the TI side to make the appropriate changes at that time. Myarc is irrelevant.

 

Keep in mind that you don't need to follow every disk/DSR convention to be compatible with most software. There are quite a few examples of this already, including TIPI and Classic99, where behind the scenes things are done differently yet the end result might be the same or better.

Edited by InsaneMultitasker
Link to comment
Share on other sites

OK, next question... Anyone know what would be involved in replacing the ROM (DSR,) of the HFDC card? Also, are there enough of them out in the wild to justify fixing the DSR to have full support across the board? Would hate to find or create a fix only to not be able to find one to apply it too :(

 

Back on my project. Loading the Font & Screens (there are 2, help & main,) as data files works great. The only issue left is that it is rather large (15 sectors.) Though, the font file itself is 8 sectors. Since 4 sectors (1 K,) of that is reverse text of the first 4 sectors, could shave quite a bit by calculating the reverse text instead of loading it. Could also save quite a bit by calculating placement instead of loading directly as well. Cut out the gaps, remove the reverse text, then Load it to >0000 as the VDP buffer. Then pull >0720 to >0A1F out and place it back at >0C00 to >0EFF (main screen.) Then pull >0400 to >071F out and put it back at >0800 (That's the help screen & color table.) Finally pull >0000 to >03FF out, invert every byte, and place it back at >0400 (the Reverse text.) Takes longer to load, but less space (4 sectors, 1 K) on disk. May even be able to really shave it down if I compressed it, though that would entail moving it all out, then decompressing it into the appropriate locations. Would probably decompress it while pulling it out, then move it back in reversing the text as appropriate.

  • Like 1
Link to comment
Share on other sites

I imagine it would be possible to do like the old TRS-80 machines did and couple a WD1773 with the WD1771 that's normally there and then write a DSR that supports the change, but I don't believe anyone has ever taken that step.

The CorComp controller is quite similar to the TI original one, but the CorComp uses a WD 2793 controller instead of the 1771.

Link to comment
Share on other sites

@Pheonix: Why do you actually bother with the HFDC?

 

I have an HFDC, used it for quite some time twenty years ago, until I got my ASCSI card. The HFDC can only work with MFM drives (one of which I usually bring along for my students - here, hold it for a moment, 20 MiB for 1.3 kg). Beside the ASCSI card I have a DDCC-1 controller for DD disks.

 

What I would recommend as a project is to make use of a modern floppy controller (as far as modern can go here, dedicated controllers are almost unobtainium) and to write a DSR for it.

Link to comment
Share on other sites

The HFDC because the HW is already in place (other than possibly replacing one chip,) for HD support. So, the one chip & an updated DSR would get it working. But it's just a theory right now. Also, just because it is multi-function, doesn't mean a separate HDD card can't be used instead of the HFDC. I don't have access to a MFM HDD, but I do have plenty of SCSI & IDE drives to work with. As far as I can find out, the HFDC card is the only one to even come close to supporting HD drives. But again, if they can't be found, then it isn't worth the effort of getting the DSR fixed.

 

Project is back on old for the next 3 days. I'm only going to be at home for a few hours each day to sleep :( But I have a plan set out for when I get back.

Link to comment
Share on other sites

That's where I'm at Greg. $325 is a lot of cash. I'm using one of my hfdc cards , but only as a means to have an 80 track drive on my second system which the primary controller is a Corcomp. I have mfm drives but they're a pain in the ass. Power hogs also. If a emulator ever surfaces I will bring one of my 9640's out of hibernation.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

My project, despite having made quite a bit of progress, is currently on hold again :( I hope to get back to it once my situation changes a bit (shouldn't be too long.) On other issues, my A2000 is now fully functional (though I still need to install the OS,) but my A4000 has to wait till I find another HDD. The one I was going to use won't fit with the 68 to 50 pin adapter. Finding a 50 pin drive that the seller doesn't want a ridiculous price for is proving difficult. Really, a 15K RPM 72 GB 80 pin drive is $7.99, but they want $179 for a 50 pin 5.2K RPM 2 GB drive?? Sorry, off that soap box now....

Got the relocation system & protected loading working now. The current loader examines the first file to get the load/start address, then moves the actual Option 5 loader there. It loads the first file last, then uses a tiny (10 bytes,) loop at >8300 to move it from VDP RAM and jump to the start. Less complicated than the Scratch Pad loader that was pointed out to me. The menu info file will probably have that information, so no extra reading of the file will be needed. The BASIC loaders will just be moved to >2600 and run from there, as a BASIC program won't reside there.

 

At this time, I'm actually copying it twice. Using similar >8300 code to copy it the second time. Actually royally messed things up because the first block of a test program loaded into the upper part of RAM and I actually tried copying the loader over my own program. That had very interesting results. Suffice it to say, it did not do what I wanted. So, if the starting address is over a certain value (>E000 for now, will depend on how large my final program is in the future,) I copy it twice. I also found a program that loaded into the >2000 address space, so I've also removed all reference calls, (VMBR & VMBW for example,) and use direct access (>8C02 and such.) Always preferred those anyway.

 

More to come when I get back onto the project.

  • Like 1
Link to comment
Share on other sites

  • 5 months later...

Sorry I've been inactive on this for so long. I got my 4000 mostly put together, still want to install the implant card, but looking for ROMs for it. Also got my 3dfx system mostly put together (floppy failure,) and was working on my real TI hardware. Got it mostly finished for now :) Recently installed a MyArc DDCC-1 with 80 track mod, a 5.25" DD 80 track drive, & a 3.5" HD drive. Also have a 32k RAM card installed. The problem I have is that the program I worked so hard on doesn't want to work right on real HW, just emulation. So, I'm starting over :( I probably won't comment here again until I've caught up again. So far, I've got the overly complex OPT5 loader working on real HW, and am going to compare it to what I do to find the problem. This will be followed by getting my 2 BASIC loaders working right. Then I'm going to get the relocation & extended prep work done on that. Finally, I'll get the basic Menu system back to where I was.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...