(c)1990 Golden Triangle, Inc. (c)1990 Wilson Van Alst All rights reserved. Fm: CORY HAWKINS To: MIKE NUGENT MIKE Well, I just read my recent Portable 100 and would like to say "amen" to ROM WITH A VIEW. I too, would like to see such a ROM package - in fact I've talked to a few people on the Club 100 BBS about it. "My" concept of it grows out of Tracy Allens Extram, it's software, and the ROMBO carrier. The Rombo allows you to access 64k ROM in two 32k sections - a pseudo "bank". In this you could load up several of the many public domain software available. The kicker is that they DON'T NEED TO BE REWORKED TO RUN FROM THE OPTION ROM SLOT!!! Here's how; Using the software for the Extram, you can call the image of the program into RAM where it can run normally. This saves RAM space because you only load the programs as you need them. In effect - a ROMDISK. Totally portable! - 0 - Fm: Tony Anderson To: CORY HAWKINS A "customized ROM", via the ExtRAM approach, has been available since the ExtRAM came out. It's only up to each user to decide what he wants in his system, and make it so. The "ROM" approach is considerably different. First, there is the matter of deciding what should go into it. An early attempt to put together a "Forum Utility ROM" became a disaster when it couldn't be decided (by committee) what should be included. Accepting input from potential users makes it almost impossible to come up with a final consensus that everyone will accept. Then there is the matter of securing the rights to existing programs, or writing new ones as needed. There are then two approaches to take; writing the programs in pure assembly language, or compiling existing programs via RBASIC, which requires a PC for the work, and about $300 for the software. To actually burn the ROM's, you can figure on $100-$200 more, for the hardware. You could spend up to $1000, just to produce the first ROM, if you were starting from ground zero. Instructions on how that can be done to a user's own selection of programs has been available in our library and on the message board for some time. There is even a ROM menu shell available in Lib. 8 that details on how to use it, along with offers of help; so far with no takers. The advantage of the ROM approach, is that a number of features could be added to the machine that there wasn't room for in the original ROM - new stuff that augments the machine, not a rework of old, already existing stuff. - A problem there is securing the rights. Every author considers he should receive some reward for his work, and he _should_; but many authors are also unrealistic as to how much that should be, in relationship to marketing and production costs. When you've got ten contributors, each wanting 25% of the gross sales, it won't work. I think the idea is a good one; but Mike's offer is not unique, it's been made before, and nothing has happened yet. I fear that Mike's proposal will suffer the same fate - general apathy. - 0 - Fm: CORY HAWKINS To: Tony Anderson Tony - Your comments on the ROM idea are well taken. It's true that finding a consensus of programs would be next to impossible. And the ExtRAM does indeed provide for all those "custom" ideas. I was taken by the 64k availability with the ROMBO and tried to capitalize on both. The problem, for me, comes in trying to use the ExtRAM to operate programs FROM the option slot. I don't posses the knowledge to rework existing programs or write one from the ground up. So, the Idea comes that might work quite well to solve all those problems you and I mentioned... A NEW LIBRARY CATAGORY ON M100SIG!!! One that would contain programs that are designed to run FROM the option slot when loaded into an ExtRAM. This then would provide the chance to truely have thier own "customized" ROM. I have no Idea how easy or hard it is to open up a new library but it might be just the way to go!? - 0 - Fm: Tony Anderson To: CORY HAWKINS Well, there are a few problems with that... first of all, we don't currently have any libraries available for such a project, and there is no indication that CIS plans on expanding library facilities in the near future, indeed the contrary. As they add new services, resources get spread thinner and thinner. As for making programs available in a form that will run =FROM= the Extram, that presents several problems. First, the way a program runs FROM a ROM, or the ExtRAM in rom emulator mode, is that they start out with CALL 0, which means that the program starts running from the lowest address in the ROM. Now, obviously, you couldn't have TWO programs available that start from the same address, so in order to have more than one program in the ROM, you'd have to start out with some sort of menu program at the beginning, and then add the various other programs at different addresses that the menu could jump to. This means that every program in such a library would have to be written so that they would "fit" like a jigsaw puzzle, so that you could have more than one program in the ExtRAM. That would involve a huge amount of work, trying to accomodate all the possibilities; like program A first, followed by program C; then B, or whatever combination was chosen. They can't ALL run from zero, nor can they all be designed to run from any competing addresses which might be used by other programs. Bottom line on that approach, is that each combination requires customization. Now, the second consideration is that the programs have to be either in compiled BASIC, or rewritten in assembly language. I don't know of any forum member who is capable of writing assembly language programs who would be willing to "convert" numerous programs for others use; it's a long and tedious proceedure. As for compiling them, the only fully-operational compiler that is available is RBASIC from King Computer Services in LA ($300 last I heard), which requires a PC to operate in (another $500 investment). Who's willing to spend the money to make existing programs available for others in that form? I don't see how we can make this happen. - 0 - Fm: Mike Nugent (TMN East) To: CORY HAWKINS Thanks for your input, Cory! The knowledge to put such a thing together actually resides right here on the M100SIG (although I _am_ the smartest [and best looking] guy at P100!). - 0 - Fm: CORY HAWKINS To: Mike Nugent (TMN East) Again, I like the custom ROM idea, but Tony Anderson had a few comments that you should note (if you haven't already. My response to him is to open a new library with programs that run FROM the option ROM slot when installed in an ExtRAM. That way everyone could design thier own option ROM using those programs. Seems an ideal solution to me!!! Especially to those of us who don't know enough programing to write our own. - 0 - Fm: Mike Nugent (TMN East) To: CORY HAWKINS Your idea of programs that run directly from the extRAM may be a good one; it'll depend quite a bit on extablishing some sort of standard, and that'll be pretty much up to the programmers here. I've seen Tony's messages, and I know just where he's coming from. I've watched as various ideas were discussed and eventually more or less forgotten. The same thing could happen again. It's not likely to ever have any commercial success, because you can rarely get enough people to agree on one thing to make it worthwhile. Still, I'm interested in getting people to reconsider, and to offer suggestions. Just wanna see what kind of things come up. - 0 - Fm: Tony Anderson To: Mike Nugent (TMN East) It appears that the standard ROM in a Model 100 is a standard, plug-in, 27C256. Consequently, I'd like to see a new ROM be made available, and a couple of things I'd like to see in it, are: 1. A fix for the documented DATE$ bug. Phil Wheeler once commented that he had explored the differences between the Model 100 and 102 ROM's, and found that in the 102 ROM, they had simply NOP'ed out the offending code that caused the bug. Which would mean that a new version of the ROM could be burned which would eliminate that bug completely. 2. Around the turn of the century, if there are still any Model 100 fans around, another new ROM could be made available which would change the "19" in the standard calendar format to "20", so we could continue to use calendar functions into the next century. The "19" is hard-coded into the ROM, and would only have to be changed to make the calendar functions correct for the next 100 years. However, all this is not likely to happen, since Tandy won't release the rights to manufacture/distribute a new version of the ROM, most likely claiming prior restraints in their software license from MicroSoft. And MicroSoft won't be interested in such a project for a discontinued machine, with such limited sales expectations; and they will indicate they've licensed Tandy for that sort of thing, and Catch-22. - 0 - Fm: C. Davey Utter To: Tony Anderson Could there be a software fix for "20" problem or does the "hard-coding" preclude that? - 0 - Fm: Tony Anderson To: C. Davey Utter I don't think there's any hook where you can grab the calendar routine to change the leading two figures of the year. I haven't explored that personally, but no one has ever mentioned that as a possibility. Most likely Paul Globman would know more about that, since he's explored the menu display routines extensively. For the Model 100, at least, seems it would be easiest to modify and burn a new ROM. For the 102 and probably the 200, it would be more difficult; I believe the ROM is soldered in place in those models. - 0 - Fm: Mike Nugent (TMN East) To: Tony Anderson I recently developed a date bug fix (for a client) that will work through the end of the century. When I get a chance I'll upload it here. Basically, it takes the date you type in, stores the year-one's digit, then on every clock interrupt, copies it into the address where the Model T stores its year-one's digit. (Could do year-tens, too, but being the '90's, it ain't necessary now.) The date bug has something to do with interrupts, and I wouldn't know how to fix it "properly" in an updated ROM. But my brute force method above could be put into the background task on a new ROM and would work just fine. My code also automatically increments the year on January 1. (Tandy's 102 "fix" leaves that up to the user.) So on a 102, my code adds a new feature. I don't know how many people would want to have their ROM's replaced (i.e., having their machines "hacked up"), and Tandy's/Microsoft's stance wouldn't help matters. But if we can adapt the extRAM to the task, it becomes a software fix. Furthermore, Tandy can't complain if we have software that copies their ROM code into RAM and messes with it, because you're not selling their code--only a program that patches it! I had to do that with Dvorak. The installer copies parts of ROM into RAM, splices in my own stuff, and then tucks the resulting code into a BASIC REM line. I don't sell even a tiny bit of their code. Just some more thoughts. Thanks for yours! - 0 - Fm: Tony Anderson To: Mike Nugent (TMN East) Well, that's a good idea, and I imagine that approach would be so small, just a couple of instructions, that it's something you could hide in the function key definition table. Clever approach. Of course, it wouldn't work with _mine_, which always seems to revert back to 1985 or some such... (grin) There is a file in the library - Library 7 - called DATEBG.FIX which offers several other solutions from early attempts to deal with the problem, and some additional information on what causes it, if you want to go exploring, or just have an inquiring mind. NOPing a new ROM would essentially just do what they did in the 102; almost wipe out the "automatic" parts of the calendar routine, so you have to set it manually. If your code were patched into an ExtRAM version, I would think it would run up against the same interrupt problem, unless you disabled interrupts before calendar/clock update, and re-enabled them on exit, to eliminate the problem. I _think_ that's what Phil said the problem was, ultimately, no DI instruction. - 0 - Fm: C. Davey Utter To: Tony Anderson Could not the ROM be redone just to reflect the change over to the "20" and then we could use the existing methods of coping with the year bug, i.e. a single statement to reset the year everytime a program is run? That's been working unnoticed for me for years (except for Jan. 1st). - 0 - Fm: Tony Anderson To: C. Davey Utter Yes, that can be done - on an individual basis. I'm sure that if anyone did it as a commercial project, he'd be in for a couple of lawsuits. But I think Mike may have a workable solution, since the "fix" would really only require a couple of machine language instructions - pokes, if you will. It may be possible to eliminate both the DATE$ bug _and_ change the year display in the menu at the same time. - 0 - Fm: Mike Nugent (TMN East) To: Tony Anderson Well, it still takes a bit of code, Tony, in order to determine when to increment the year on New Year's Eve. I don't have the source code handy, but I think it took about 34 bytes to do the whole job. As far as the interrupt problem, while the date might be advanced by the bug, my brute force fix would correct it on every background scan (every 4 milliseconds). So it wouldn't be wrong for any appreciable length of time. And for your machine, we'd simply have to make it update both of the year digits, to keep you out of the 80's! - 0 - Starting message #: 30230 Starting date: 08-Oct-90 22:27:04 Participants: CORY HAWKINS 72567,454 MIKE NUGENT 71426,1201 Tony Anderson 76703,4062 C. Davey Utter 70055,522