CantStopClicking

I can't say where I came up with those but I'm pretty sure I found them on WHTech. However, they probably weren't out in the open but, more likely within a ARC file or a DSK image that I happened to stumble upon by accident. I started saving any documents like that to a special folder for later print conversion (before I had print a solution). Of course, I didn't start doing that until I realized there was a lot more documents I wanted in PDF. Then I thought to myself, hmm... maybe I need to do something like -> save them somewhere I can find them again!!! hehe I'd be more than happy to share what I find with you. I really try to keep my eye out for the original Writer files, cuz it don't get any better than that! Especially with those beat up internal docs that are hard to read and/or missing pages. I kinda figure that since most of the internal TI doc's were still "work in progress" that maybe, just maybe, the electronic form existed in order to make updates. That's just a wild theory, hunch, and/or hope. No proof what-so-ever that it's even the case at all. -D

Holy crap, that's a lot of work for sure! Totally can appreciate your efforts on the Psion manual. I hate cleaning up scanned documents but if it's gotta be done, whatever the personal reason may be, so be it! I'd tend to partially disagree that this isn't the original document, as it IS the original document just printed on a newer printer (PDF in this case). Unfortunately, there's no direct way to print from TI-Writer Formatter to PDF, so I have to make a bunch of temporary technology changes in between, but none of the text was altered, it's exactly as it was printed from a TI with TI-Writer cartridge and a real printer (and from the original files from TI). I have to agree, it's not original because it wasn't printed and purchased from TI back in the day. Now, could I go into the TI-Writer files and fix the typo's? Hell yeah! But, I don't have time to, and that would definitely make them not original. The few internal TI documents that I have are laiden with typo's and technical errors and that's where I just can't fill in the gaps. If a piece of assembly code has a typo, I have no idea how to fix it. Trust me, I'd so much rather have a corrected print but the time involved is WAY over my head. Collaboration could be a good solution though. What I'd REALLY love to do is have a JAVA based TI-Writer Formatter and skip a WHOLE lot of steps of my conversion process. I'll probably end up starting a new topic for that when I'm ready to participate/help cuz I really think it would be worthwhile. Even some more simplistic like, TI-Writer to Word converter would suffice. The ugly and nasty problems begin when the TI-Writer document contains DOT matrix printer codes (ESC). Those do not port well with anything currently available today, that I could find. Although, I did come up with a not-quick-and-dirty solution! Anyhow, I want to make sure it's clear the documents I've proposing to provide, are EXACT printouts of the original TI files, zero alteration. I'm just providing a way to print TI-Writer Formatter files to PDF. -LOL- maybe that's what I shoulda said in the first message. Cheers! -D

Ahh, thank you for the explanation and the disassembly. It'll probably take me a week to even begin to understand that but, that's okay! I need examples like this; as my brain just doesn't like assembly. I don't know what else to do but beat into submission with a club. I've been trying to read up on disk controller programming and I must say it's VERY sparse documentation wise. It appears TI absolutely did not want anyone programming the disk controller at the lower levels. Got any pointers for documents to read up on? Specifically the lowest level. -D

<as so eliquently put in the movie; "Dude Where's my Car?"> Dude! Sweet! Thank you for posting a walk through example. That'd taken me years to figure out. Technically speaking... since I wanted to do that about 20+ years ago, it HAS been years! -D

Thanks Chris! Sure has sucked not being able to participate for soo long, but hopefully, I can squeeze some TI & AtariAge time in before school starts back up in Sept. -D

or sadly, died...

I'd also LOVE to have the head step times bumped up (down) to either 6ms or 3ms. The Teac 3.5 datasheet says they are 3ms. My CorComp FDC let's me change it and it's a huge difference in less chattering (more leads to advanced wear theoritcally) on the 3.5's. However, I have no idea whether the CC is doing 3ms or 6ms. The documentation says one thing, and the software says the other. Regardless, it makes a big difference, especially when you're pulling a long directory listing (crunch crunch crunch as the head seeks back and forth) on a diskette. I'm happy with the CC box but I'd like to change the TI one. Gazoo, is there specific code that can be changed to experiment with the different XXms settings? I don't personally utilize the 80 track eprom's as anything I do on floppies is strictly 40-track for compatibility with others. I use HDX for EVERYTHING I can (and do I love it). I'd like to bit fiddle with the original TI ROM's to just change the milliseconds, nothing else. And I certinaly don't expect you to do that for me... however, I'm not smart enough (yet) to figure it out without some pointers. If you're willing/able? -D

I don't know where to post this so I just started a new topic. I apologize in advance if this isn't the right place or proper etiquette. I've been away for almost a year now. I've lurked here and there but definitely have not participated in conversations. It's a long story and I'd prefer to just forget about the last year (or five) if at all possible and I certainly won't waste bits on it. I have to thank Omega for kicking me into gear and actually getting me back on here. How ironic is that... since I urged him to get back into the TI a couple years ago. LOL Anyhow, I see lots has happened and hope to poke my nose in here and there. I'm still super busy with life but one major hurdle is over and I'd like to get back on the TI and do some sh*t! I left some people hanging when I exited last year and I'll do my best to follow up with them as time allows. If you're of them, please accept my apologies. Okay, that's it, just really wanted to say Hi and I miss ya all! -Dano

Thanks for the feedback. I'll have to admit that I did zero correction to typo's on the original documents. I guess maybe I should back up a little and add that, these are original TI-Writer formated documents that I've run across and wanted to "re-print" them with modern printers. As easy as this may sound, it's not. So, the point is, these were not reproduced by me (as in typing them in by hand). These are direct print from TI-Writer to PDF (minus the 50 steps in between). Does that make any sense?? The goal, for me, was to have; 1) extremely legable print, 2) searchable, 3) printable, and 4) ability to cut & paste if one so desired. If I had more time, I'd correct typo's but, holy crap, my head hurts just thinking about that... (but the perfectionist in me desires it!) -D

I've been doing some manual conversions and thought I'd upload one of them here and get a little feedback on the quality and useability of it. It took quite a bit of massaging to get the TI-Writer document to a searchable PDF and I'd like to do more but would like to hear feedback regarding the print. I don't want to do a lot and have to change my process (cuz it's tedious). But if everyone is cool with the output, then I'll work on more. Here's my first example: Peripheral Expansion System: Theory of Operation and Technical Training Manual Cheers! -Dano "Long Live the TI-99/4A!" PS: Why do this? Cuz I hate crappy scans! Peripheral Expansion System - Theory of Operation.pdf

I second that. Tried it once, broke my PLCC socket, that was the last time. Unfortunately, I thought I had a good puller but, I just bought another one and the action is much smoother. I think my previous one was broken to begin with. It required an extreme amount of effort. The new one still bends the pins though, errr.... I use a sharp dental pick (one end straight the other has a 45 degree bend). I use that tool every time I touch electronics, super handy, tiny, and fairly strong. Cheers!

Sure, why not! Do you mind sharing both the ROM image and disks? Having carts in EA5 format is pretty handy. -Dano

Damn! You guys have been busy! Got caught up with family stuff so I'm just checking in and I've got a lot of catching up to do. I'm excited! I bought a new PLCC puller and OMG it works a million times better than my old one. But, will have to wait til tomorrow to try anything out. Cheers! -Dano

Ok, cool. I had best luck with the EEprom1.bin file set. About 50/50 on the apps that functioned. MDM5 did reset, I remember that. DMII seemed to work just fine. TIW+EA worked mostly, but was getting weird DSR errors here and there. I've forgotten the rest (more like have it all jumbled up in my head). I'm going to redo my tests again on my other cartridge board and see if I get different results. I'm trying to avoid killing the PLCC sockets in both carts so I mainly have been using one but cycling through the four 49c040's I have on hand. And I'll update my answers to your questions then. I don't want to put mis-information out there that leads us down a wrong path. Thanks for your patience... Let me do some tests before you make too many more changes. I'd like to see if I can sync up with Greg so we at least are at the same point and compare. -D

Ok, well my tests are not working at all. I get the XB selection, if I choose #2, it will sometimes access DSK1, sometimes won't. All commands lock up XB but I do get to an initial XB prompt. If I go to TI basic and do a CALL MENU, instantly locks up every time. I'm definitely getting different results than Greg. I'm suspecting the PLCC is part of the problem but don't know. I've got two cartridge boards I'm working with and four 49C040's. Is there any way to test the ROM to make sure it's being fully seen, like a CRC on it? From the TI, so we know that when the 49C040 gets moved from the programmer to the cartridge that it's actually seeing something there. I know our tests are "kind of" doing that but there's no way for me to tell if the TI is actually seeing all the lines to the 49C040 (and inherently the code that's been flashed to it). I'll mess with this more tomorrow. Have I said, I thoroughly hate PLCC sockets now?

I forgot to mention that I did this and didn't seem to make much of a difference in results BUT, I did notice it helped "re-spring" the legs. I used a nice sharp dental pick. I'm totally amazed at how much I use that pick for electronics. I think I'm going to invest in a PLCC socket. They're spendy but it'll save my chips and sockets during testing. Guess I better get something on eBay and raise some more TI funds.

Greg, can you do a CRC on the files you've burned? I get XB 2.7 to work but soon as I enter any command it locks up or goes back to the menu screen. But, I'm still on version EEprom.bin and EEprom1.bin pair. Here's the CRC's for the set I'm currently using: 128FLASH.BIN - E7641F1C 512KROM.bin - 1DD502D6 EEprom.bin - 89F0C52E (partial TI menu 1, 2, and 3; with or without 512kROM) EEprom1.bin - DDD646E8 (full A-Z menu; with 512kROM) <=- This one seems to be working so-so, some items on the menu work, some don't. But the most stable so far.

I'm regressing my testing. And trying to create a little spreadsheet with the tests and results. I think I'm losing my mind with file versions. I'm relying on CRC's (that I'm remembering in my head - bad idea). My last test I re-ran because my flash got corrupted somehow (or I did something stupid in my brain dead state - very possible). I re-inserted the ROM (49c040) but this time I decided NOT to fully seat it, I just pressed it in to be even with the top of the PLCC socket, and all of a sudden things started working. This is with the file set from Gazoo with EEprom.bin and EEprom1.bin pair (which I converted to hex - so if you see me state .hex instead of .bin they're the same) RFC: Is it possible we can put some version numbers on the zip's that are being uploaded, that would help my organization and threads of testing, and correlation of results back to here (AA)? Just looking for unique names so we're (me) not getting confused on which tests are producing which results with which files. EDIT: I'm really only after the unique filename for the zip archive, so I can try and keep a incremental changelog. Just something simple like _1, _2, or whatever cuz once downloaded and sitting in a directory, order is gone. More testing....

I feel your pain. One of my purchases was the exact same deal but auction was for 20 some floppy drives. And guess what they were packed with???? FREAKIN' SHREDDED PAPER MIXED WITH LOOSE FLOPPY DRIVES!!!!! ARE you kidding me? None of the drives worked right, full of shredded paper and dust jammed in every possible place. Shredded paper and floppy drives, what in the world was this seller thinking??? Now, I specifically state, I want working drives and if they arrive non-working I will be asking for a refund and not a return. That usually either gets the seller to say "don't buy my auction then" or "I'll make sure they're extra safe" and they'll know up front I'm not going to mess around with returns for stuff like that. For sellers; Taking careful pictures of stuff you sell so the buyer doesn't do a switch-a-roo on you for a return for parts he stole and swapped out with bad parts. Ultraviolet ink is also another idea I've have floating around in my head but haven't gone that far yet. I just take good high quality photo's before I post, that's my insurance policy so far. LOL I still love the ability to find just about anything on eBay though. Never could have done this back in the day before internet. Cheers! -Dano

(UPDATE: Just to clarify, these results are without the ROM chip installed) Test File EEprom.hex (which I'm going to call it xxxtest_4) This is the EEprom.hex file of the EEprom1.hex pair; Test file EEprom1.hex; Now this one is interesting! It by-passed the TI Color Bar screen and went straight to the A-Z menu. I'll test each item and report back after some food! I can see things are going to get fun here quick! :-)) Never mind, I realize testing the other options are pointless without the ROM (like Gazoo said, duh...) Well, except for option Z - TI Basic (which does work too btw) UPDATE: Menu Options B - TIW and C - DMII do seem to function. TIW+EA has a few oddities, got a DSR error using #5 RUN (not #6 RUN PROGRAM FILE - which worked as expected) be back with more results...

Oh, another question. Is there a preference for PEB being attached or not during testing? Most of my tests have been with the PEB fired up. PEB consists of standard TI FDC, RS232 (HDX), Flex, and 32k. No other modifications what-so-ever (ie no F18A, nada).

Ok, finally getting back to this, my apologies. I care for my parents so they come first in the scheme of things. Anyhow, this tests produces the same results as previous test did. Same menu options (2 - XB v2.7, 3 - Review Module Library), same blue screen, same soft lock when choosing option 2. And option 3 for review does the same, lock up, sound generator solid. Moving on to the next test. EDIT: IGNORE THIS MESSAGE - I THINK I USED THE OLD FLASH FILE ON THE TEST

I think I might have rubbed him wrong at some point because he never answered any of my bug reports. Well one, and implied that it was my system that was the problem but then the next update fixed it. I really hope that I didn't offend him, it certainly wasn't the intent. I'm just good at finding bugs (and I'm not proud of it). LOL I'll try hitting him up again, it's been at least a year. Who knows maybe my emails are going straight to the spam folder and he's never even getting them. I totally couldn't live without his software and hardware mods rock!

One thing I forgot to mention the other day. I was going through some documentation on AVR Studio and they talk about calibrating the internal RC oscillator. Which, they state is needed if you are planning on timing critical events using the internal clock. They say that in order to use the calibration bit, it needs to be set in EEPROM and has to be read by software in order to correctly utilize it. Would this have anything to do with the odd interaction of the AVR and the external 49C040? Here's an example doc from Atmel (although this wasn't the one I was looking at before but you'll get the picture). http://www.atmel.com/Images/doc2555.pdf Just throwing some thoughts out there...

Sweet, thank you! I gotta fiddle with that now. :-)))