Subject: Detect if running on (classic99) emulator

From: "killroy732000" <[email-masked]>
Date: Thu, 11 Feb 2010 19:50:59 -0000

Hi TI friends,

would it be possible for an assembler or extended basic program 
to detect if it is running on a real TI-99/4A or in a specific emulator, e.g classic99 ?

This question comes to mind now that Owen has written the first extended basic program that actively uses the CLIP device.

Possible options:
* Check if the CLIP device is available ?
* Check a specific memory location ?
* Check for specific/fake opcode ?
* ...

Cheers
Filip

---

From: ti99_forever <[email-masked]>
Date: Thu, 11 Feb 2010 12:43:11 -0800 (PST)

ON ERROR for the device?
use the STATUS DSR opcode?
I've got code (on my real TI) demonstrating the latter. Used it to detect the existence of a file on a disk.
Wonder if CLIP actually supports the STATUS opcode?

--- On Thu, 2/11/10, killroy732000 <[email-masked]> wrote:

> From: killroy732000 <[email-masked]>
> Subject: [TI994A] Detect if running on (classic99) emulator
> To: [email-masked]
> Date: Thursday, February 11, 2010, 2:50 PM
> Hi TI friends,
> 
> This question comes to mind now that Owen has written the
> first extended basic program that actively uses the CLIP
> device.
> 
> Possible options:
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>     [email-masked]
> 
> 
>

---

From: Owen Brand <[email-masked]>
Date: Thu, 11 Feb 2010 16:46:52 -0500

In my program, "CLIP" is opened just like "DSK1". Tursi added this  
feature to my program for me, therefore I will let him chime in on  
specifics.

Owen Brand
Opry99er.com

On Feb 11, 2010, at 3:43 PM, ti99_forever <[email-masked]>  
wrote:

> I've got code (on my real TI) demonstrating the latter. Used it to  
> detect the existence of a file on a disk.

---

From: mark wills <[email-masked]>
Date: Thu, 11 Feb 2010 19:39:19 -0800 (PST)

You can check if the CLIP device is available with ON ERROR

10 ON ERROR 100
20 OPEN #1:"CLIP.",OUTPUT,DISPLAY,VARIABLE 80
30 PRINT #1:"Testing 123..."
40 CLOSE #1
50 END
100 PRINT "ERROR-CLIP device not available"
110 END

>Sent: Thu, 11 February, 2010 20:50:59

---

From: mark wills <[email-masked]>
Date: Thu, 11 Feb 2010 19:49:12 -0800 (PST)

I wonder if there are any UN-USED table entries in the XMLLNK tables (there are a few of them) in the Console ROM.

If so, Classic99 could patch one of those *unused* entries, and a user program could check for it (not run it, just check it)... If you find it, you're on Classic99.

If you could determine that you are running on Classic99, then (by implementing unused 9900 op-codes) it would be possible to do thinks like:

* Maximise the display window
* Halt the processor (breakpoints)
* Switch on/off Turbo mode
etc

Actually, that might be a simpler idea... Unlike some processors, the 9900 ignores op-codes that it doesn't recognise. Therefore, ONE instruction could be implemented, such that it (for example) sets R15 to >FFFF

; are we running in classic99?
CLR R15
C99TST
MOV R15,R15
JNE YES
; No...
....

On Classic99, R15 would be set, on a real TI, it wouldn't...

Then your software becomes 'host aware' - Next step, CyberDyne Corp, and THE RISE OF THE MACHINES!!!!

>
>From: ti99_forever <[email-masked]>
>Sent: Thu, 11 February, 2010 21:43:11
>Subject: Re: [TI994A] Detect if running on (classic99) emulator
>
> >
>
>
>
>
>  >
>>      
> 
>ON ERROR for the device?
>>--- On Thu, 2/11/10, killroy732000 <filip.van-vooren@ gmx.net> wrote:
>
>>> From: killroy732000 <filip.van-vooren@ gmx.net>
>>> To: TI994A@yahoogroups. com
>>> ------------ --------- --------- ------
>>> 
>>> Yahoo! Groups Links
>>> 
>>> 
>>>     TI994A-fullfeatured @yahoogroups. com
>>> 
>>> 
>>> 
>
>
>

---

From: Owen Brand <[email-masked]>
Date: Thu, 11 Feb 2010 22:56:32 -0500

Fascinating stuff mate... :). You learning alot in the last couple  
days?  Your posts are pointed and direct, as though you are conjuring  
up some Tashkent programming magic Hmmm.....  ;). Look forward to  
updates

Owen Brand
Opry99er.com

On Feb 11, 2010, at 10:49 PM, mark wills <[email-masked]>  
wrote:

> I wonder if there are any UN-USED table entries in the XMLLNK tables  
> (there are a few of them) in the Console ROM.
>
> If so, Classic99 could patch one of those *unused* entries, and a  
> user program could check for it (not run it, just check it)... If  
> you find it, you're on Classic99.
>
> If you could determine that you are running on Classic99, then (by  
> implementing unused 9900 op-codes) it would be possible to do thinks  
> like:
>
> Actually, that might be a simpler idea... Unlike some processors,  
> the 9900 ignores op-codes that it doesn't recognise. Therefore, ONE  
> instruction could be implemented, such that it (for example) sets  
> R15 to >FFFF
>

---

From: mark wills <[email-masked]>
Date: Thu, 11 Feb 2010 20:37:49 -0800 (PST)

Hiya! Well the ideas expressed below have been percolating for a while, and I have discussed them Turwsi before (as, I'm sure, have others)... It's a matter of Tursi getting the time to add all this stuff... He's doing a great job, so I try to go easy on him!

Yeah, I'm doing quite a bit of coding at the mo. Yesterday was working in XB. I actually tried working in Notepad++ and pasting into Classic99 - it was quite comfortable.

This Sunday I have the mother of all coding days planned. I plan to hit TurboForth pretty hard and take a scalpel to the code. I need to get it working as a two bank cartridge (Classic99 to the rescue!) and move code into the second bank... I feel it will be a fight... Wish me luck!

I'll be getting up early, having breakfast, going to the shops and stocking up on chocolate bars and cola, and then HIT IT. I'll no doubt have some good music playing at the same time. I'm rather partial to Chris Rea.

M

>
>From: Owen Brand <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Sent: Fri, 12 February, 2010 4:56:32
>Fascinating stuff mate... :). You learning alot in the last couple days?  Your posts are pointed and direct, as though you are conjuring up some Tashkent programming magic Hmmm.....  ;). Look forward to updates
>
>Owen Brand
>Opry99er.com
>
>On Feb 11, 2010, at 10:49 PM, mark wills <markrobertwills@ yahoo.co. uk> wrote:
>
>
>>>
>>
>>
>>  >>
>>
>> 
>>>>      
>>

---

From: Insane Multitasker <[email-masked]>
Date: Thu, 11 Feb 2010 22:39:11 -0600

Ask the user?  :)

INPUT "Using (R)eal TI or (E)mulator? ":REALTI$

> would it be possible for an assembler or extended basic

> program 

> to detect if it is running on a real TI-99/4A or in a

> specific emulator, e.g classic99 ?

    

 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/

---

From: Owen Brand <[email-masked]>
Date: Thu, 11 Feb 2010 23:41:44 -0500

Hmmmm.... well, glad to hear you are doing something with that talent  
of yours.  :). As for music, I suggest a little Louis Armstrong or  
maybe a bit of Pink Floyd.... The "Animals" album always inspires  
me...  :)

Owen Brand
Opry99er.com

On Feb 11, 2010, at 11:37 PM, mark wills <[email-masked]>  
wrote:

> Hiya! Well the ideas expressed below have been percolating for a  
> while, and I have discussed them Turwsi before (as, I'm sure, have  
> others)... It's a matter of Tursi getting the time to add all this  
> stuff... He's doing a great job, so I try to go easy on him!
>
> Yeah, I'm doing quite a bit of coding at the mo. Yesterday was  
> working in XB. I actually tried working in Notepad++ and pasting  
> into Classic99 - it was quite comfortable.
>
> This Sunday I have the mother of all coding days planned. I plan to  
> hit TurboForth pretty hard and take a scalpel to the code. I need to  
> get it working as a two bank cartridge (Classic99 to the rescue!)  
> and move code into the second bank... I feel it will be a fight...  
> Wish me luck!
>
> I'll be getting up early, having breakfast, going to the  shops and  
> stocking up on chocolate bars and cola, and then HIT IT. I'll no  
> doubt have some good music playing at the same time. I'm rather  
> partial to Chris Rea.
>
> M
>
> days?  Your posts are pointed and direct, as though you are  
> conjuring up some Tashkent programming magic Hmmm.....  ;). Look  
> forward to updates
>
> Owen Brand
> Opry99er.com
>
>> I wonder if there are any UN-USED table entries in the XMLLNK  
>> tables (there are a few of them) in the Console ROM.
>>
>> implementing unused 9900 op-codes) it would be possible to do  
>> thinks like:
>>

---

From: Owen Brand <[email-masked]>
Date: Thu, 11 Feb 2010 23:52:23 -0500

:) Hehe--- yea... That sounds easy enough.  :). I intend to utilize  
the CLIP feature in several of my programs. One  thing I plan to do is  
implement it into Lemonade Stand to "freeze" the gamestate.  Bear with  
me....

Add a feature to output my own "code" that will act as a  
"password".... That way, the user will not have to play all 30 days of  
the game at once.  It will scan all appropriate variables, and kick  
out a "password" like "4dZ136m&f" This will save to CLIP and the user  
will be able to paste that in to reinstate the gameplay at the day and  
money amount they had to end their game with... There will be an  
"Enter Password" screen at the beginning. :)

Owen Brand
Opry99er.com

On Feb 11, 2010, at 11:39 PM, Insane Multitasker  
<[email-masked]> wrote:

> Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Si 
> gn up now.
>

---

From: mark wills <[email-masked]>
Date: Thu, 11 Feb 2010 21:09:28 -0800 (PST)

But that would limit the game to Classic99 only!

You could still generate the hash-code, just save it to a disk file instead. Then it will work on the real deal, and *ALL* emulators ;-)

I've decided Sunday will be a Funk day. Bootsy Collins, Level 42 and dodgy 70's Philadelphia type Funk (think Starsky and Hutch).

>Sent: Fri, 12 February, 2010 5:52:23
>:) Hehe--- yea... That sounds easy enough.  :). I intend to utilize the CLIP feature in several of my programs. One  thing I plan to do is implement it into Lemonade Stand to "freeze" the gamestate.  Bear with me....
>
>
>Add a feature to output my own "code" that will act as a "password".. .. That way, the user will not have to play all 30 days of the game at once.  It will scan all appropriate variables, and kick out a "password" like "4dZ136m&f" This will save to CLIP and the user will be able to paste that in to reinstate the gameplay at the day and money amount they had to end their game with... There will be an "Enter Password" screen at the beginning. :)  
>
>Owen Brand
>Opry99er.com
>
>On Feb 11, 2010, at 11:39 PM, Insane Multitasker <insane_m@hotmail. com> wrote:
>
>
>>>
>>
>>
>>  >>
>>
>> 
>>>>      
>> 
>>>>
>>
>>Ask the user?  :)
>>
>>________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now.

---

From: Owen Brand <[email-masked]>
Date: Fri, 12 Feb 2010 00:19:23 -0500

It will display on the screen as well as having a COPY TO CLIP  
function--- like the BYTEs in the converter program.  :). Real TI  
users can just write it down like in the old days.  :)

Owen Brand
Opry99er.com

On Feb 12, 2010, at 12:09 AM, mark wills <[email-masked]>  
wrote:

> You could still generate the hash-code, just save it to a disk file  
> instead. Then it will work on the real deal, and *ALL* emulators ;-)
>
> I've decided Sunday will be a Funk day. Bootsy Collins, Level 42 and  
> dodgy 70's Philadelphia type Funk (think Starsky and Hutch).
>
>
>
> the CLIP feature in several of my programs. One  thing I plan to do  
> is implement it into Lemonade Stand to "freeze" the gamestate.  Bear  
> with me....
>
> "password".. .. That way, the user will not have to play all 30 days  
> of the game at once.  It will scan all appropriate variables, and  
> kick out a "password" like "4dZ136m&f" This will save to CLIP and  
> the user will be able to paste that in to reinstate the gameplay at  
> the day and money amount they had to end their game with... There  
> will be an "Enter Password" screen at the beginning. :)
>
> Owen Brand
> Opry99er.com
>
>> Sign up now.

---

From: R Halter <[email-masked]>
Date: Fri, 12 Feb 2010 03:49:10 -0600

Owen Brand wrote:
> 
> Add a feature to output my own "code" that will act as a "password".... 
> That way, the user will not have to play all 30 days of the game at 
> once.  It will scan all appropriate variables, and kick out a "password" 
> like "4dZ136m&f" This will save to CLIP and the user will be able to 
> paste that in to reinstate the gameplay at the day and money amount they 
> had to end their game with... There will be an "Enter Password" screen 
> at the beginning. :)  

Why not just implement a "save" feature?  Just create a save file on the 
media of the player's choice (CS1, DSKx, CLIP, etc.).  Wouldn't that be 
easier than trying to come up with a password-generating subroutine?

-- 
"Hugo!  Jesus Christ is not a weapon!"
  -- Hurley's mother, "Lost"

---

From: Owen Brand <[email-masked]>
Date: Fri, 12 Feb 2010 06:21:33 -0500

I already have the password thing worked out...  :) it's simple and  
just cryptic enough to keep people fromvstartibg on day 3 with 50  
million dollars.  :). If none of you have had the opportunity to play  
"Faxanadu" on the NES, please, get an emulator and play it.....   
Combine that game with Tunnels of Doom and you have the makings of my  
Beryl Reichardt game concept... Faxanadu had the most intricate, long  
and miserable passwords you had to write out by hand..... 46  
characters, I think.... Caps, lower case, numbers, symbols..... What a  
freaking mess!!!

Owen Brand
Opry99er.com

On Feb 12, 2010, at 4:49 AM, R Halter <[email-masked]> wrote:

> "password"....

---

From: tursi <[email-masked]>
Date: Sun, 14 Feb 2010 14:11:25 -0800 (PST)

> * Check for specific/fake opcode ?

If an emulator was written completely correctly, it should be 
indistinguishable from the real machine via software. Of course, no such 
emulator exists today. ;) There are always idiosyncrases you can look for.

Now, I actually wrote that CLIP code for Owen, and to ensure that it would 
not fail on a real machine, I simply wrapped the file system access with 
ON ERROR. So on a real machine, the system would simply fail to open the 
CLIP device, and say so. And that's how you always deal with things like 
that -- the TI is an expandable system. You can't assume any DSR exists 
(or at least, you shouldn't). So check for error!

If we want to talk an emulation standard, I would like to propose that we 
use the DSR system, since that would be most compatible with the real 
machine. Perhaps a read-only device called EMULATION, that returns a D/V80 
record including the name and version of the emulator.

Then, code just has to open that device. If it fails to open, then it's 
either a real machine (or an emulator that doesn't support it). If it 
succeeds, you can even read what emulator it is, if you like.

Of course, if you want to tell without the emulator authors supporting a 
common standard (impossible to enforce), then you need to fingerprint each 
emulator -- find idiosyncrasis specific to each. For instance, MESS and 
Win994A always set the sprite collision flag together with the vertical 
blank flag, so you could put two overlapping sprites at the top of the 
screen, then poll the VDP status register. If the bits are not set 
separately, you know it's not real hardware. (You'd have to test over a 
few frames to be sure). Timing is another good one, if you can find a test 
that's very different from hardware (beware of file access, else you might 
detect RAMdisks ;) ).

Classic99's enhancements will always be detectable from software, 
otherwise there is no point to doing them IMO. If you want more, perhaps 
the best approach is to just ask the user if they are using emulation or 
not. :)

---

From: tursi <[email-masked]>
Date: Sun, 14 Feb 2010 14:12:28 -0800 (PST)

> use the STATUS DSR opcode? I've got code (on my real TI) demonstrating 
> the latter. Used it to detect the existence of a file on a disk. Wonder 
> if CLIP actually supports the STATUS opcode?

If a device doesn't exist, then DSRLNK sets the error code, not the 
(non-existant) DSR ;)

---

From: tursi <[email-masked]>
Date: Sun, 14 Feb 2010 14:27:21 -0800 (PST)

Forgive the negative attitude of this post, I mean it in a positive 
manner, but I'm going to explain why I'm not behind these ideas:

> (there are a few of them) in the Console ROM. If so, Classic99 could 
> patch one of those *unused* entries, and a user program could check for 
> it (not run it, just check it)... If you find it, you're on Classic99.

Classic99 doesn't tie itself to any particular ROM or version of ROM.. 
since the ROM is interchangable, it's not safe to change or reliable to 
read a byte of ROM to determine what you're looking at.

> like: * Maximise the display window * Halt the processor (breakpoints) * 
> Switch on/off Turbo mode etc

There have beena few requests for this sort of thing. My problem keeps 
coming back to the reason I don't build an uber-upgrade for the console... 
I want software that runs on the real machine, not an emulation or some 
hardware mod. I don't mind enhancements, like the CLIP device or the synth 
that I used to run, since they make nice experimentation and make movement 
of code easier, but suddenly we're getting into software specifically 
written for the emulator, that I'm less keen on supporting.

At lot of the extended ideas that I put into Classic99, like the text file 
support, I want to migrate to the REAL machine someday soon. Classic99 
lets me vet these ideas and get them working well while I learn the 
hardware side in the background.

> Actually, that might be a simpler idea... Unlike some processors, the 
> 9900 ignores op-codes that it doesn't recognise. Therefore, ONE 
> instruction could be implemented, such that it (for example) sets R15 to 
> >FFFF

This sort of thing might be okay... but won't it break on the Geneve, 
when the opcode is no longer ignored?

I guess I just haven't seen an application with a strong enough need to be 
emulation aware yet. :) If someone can convince me why we desperately need 
emulation-only TI software, well, hell, I have a whole list of 
enhancements to give you. ;)

---

From: "Matthew" <[email-masked]>
Date: Mon, 15 Feb 2010 01:34:02 -0000

> succeeds, you can even read what emulator it is, if you like.

This sounds like a good way to do this.  Any chance you might write up a formal spec and possibly detail the format and information returned in the emulation record?  A key/value pair format would be my suggestion which allows for a flexible set of parameters.

Matthew

---

From: "Beery" <[email-masked]>
Date: Mon, 15 Feb 2010 01:39:31 -0000

Can you test for some odd behaviour of rom or ram at some particular address?

---

From: ti99_forever <[email-masked]>
Date: Sun, 14 Feb 2010 18:03:02 -0800 (PST)

At this point, it would be just like walking up to a regular TI and doing a "SAVE CRACK" and getting an error returned.

In asm a non-existent DSR returns an error in a memory location, likely at >8350. It should be documented in the Editor/Assembler manual, or you could look at DSRLNK code.

--- On Sun, 2/14/10, Matthew <[email-masked]> wrote:

> From: Matthew <[email-masked]>
> Subject: [TI994A] Re: Detect if running on (classic99) emulator
> Date: Sunday, February 14, 2010, 8:34 PM
> This sounds like a good way to do this.  Any chance
> you might write up a formal spec and possibly detail the
> format and information returned in the emulation
> record?  A key/value pair format would be my suggestion
> which allows for a flexible set of parameters.
> 
> Matthew
> 
> 
> 
>

---

From: "Matthew" <[email-masked]>
Date: Mon, 15 Feb 2010 02:03:22 -0000

> 
> There have been a few requests for this sort of thing. My problem keeps 

This same thing has bugged me for a long time, and still does.  The urge to enhance the system, make it faster, expand the RAM, make uber devices, etc., but to what end?  If there is no software out there that takes advantage of it, and if everyone is off doing their own thing, then it is all for not.

I always wanted my TI to have more color, be faster, and have better resolution.  Today, with software and hardware emulation, it could have those things, but then it would no longer be a TI.  Without a company "owning" the system and making the rules and new hardware, there is nothing that defines what is and is-not a standard system or upgrade.  Also, what happens to the original 99/4A, would everyone really abandon it for a new upgraded VHDL-based "99/4A like" computer?

I think the allure is the nostalgia of the system, and everyone's story is going to be a little different.  But you can't uber-upgrade the past, and there would be no emotion tied to some form of an "enhanced" system, let alone software to run and people with enough interest to write new programs.

Having said that, there are a few enhancements I would like to see "standardized" across emulators and possibly new hardware, as I don't think these things take away from the original system.

* A standard for RAM paging in both the expansion unit and cartridge port

* A standard hard disk subsystem

* Enhanced graphics that is backward compatible, based on the 9938 or 9958

Last, in the Win994a simulator, Cory Burr already took advantage of some of the op-code gaps and added new instructions for stack manipulation.  He also added a stack pointer register to the simulator.  I believe he also added instructions for paging, but I cannot remember the details right now.  It would be nice to review these enhancements and possibly accept them as standards for emulators.

Anyway, just my opinions and two cents.

Matthew

---

From: "Tursi" <[email-masked]>
Date: Sun, 14 Feb 2010 19:42:55 -0800

> This sounds like a good way to do this.  Any chance you might write up a 
> formal spec and possibly detail the format and information returned in the 
> emulation record?  A key/value pair format would be my suggestion which 
> allows for a flexible set of parameters.
>

Of the current emulators, only Classic99, MESS, and Sim994a are currently 
being updated, I believe. If Fred and Mike want to add support, then maybe 
it's worth it, but Win994A still won't support it, nor will classic 
emulators like PC99 and V9T9. (Also, I suspect the MESS team may be adverse 
to adding hardware that doesn't exist, but we can try. ;) ).

I'm still not convinced of the value of this, and honestly, I am leaning a 
little bit against it. What is the software going to do if it detects the 
emulator? Software that needs to be changed to work on an emulator at all 
needs to be fixed in the emulator, IMO. If it's additional features you 
want, the emulator should provide means to detect it. (For instance, 
detecting Win994A's extra RAM is a simple case of doing a memory check - 
write it and read back. Detecting Classic99's CLIP is the same as detecting 
any other device - try to open it and check for success - same as you would 
do trying to open DSK4). If my plans all come to fruition, in a couple years 
CLIP may work on the real console, too, so why restrict it to emulation?

Someone convince me why we need this? :)

---

From: mark wills <[email-masked]>
Date: Sun, 14 Feb 2010 20:52:29 -0800 (PST)

Yeah I like that idea. It's something the other emulator authors code also implement...

>Sent: Mon, 15 February, 2010 2:34:02
>--- In TI994A@yahoogroups. com, tursi <yahoogroup@ ...> wrote:
>

---

From: mark wills <[email-masked]>
Date: Sun, 14 Feb 2010 21:00:40 -0800 (PST)

That should read: It's something the other emulator authors code *could* also implement...

>
>From: mark wills <[email-masked]>
>Sent: Mon, 15 February, 2010 5:52:29
>Subject: Re: [TI994A] Re: Detect if running on (classic99) emulator
>
> >
>
>
>
>
>  >
>>      
> 
>>From: Matthew <matthew@mundomateo. com>

---

From: mark wills <[email-masked]>
Date: Sun, 14 Feb 2010 21:07:20 -0800 (PST)

>Someone convince me why we need this? :)

I totally respect your opinion, and largely agree with it.

I too agree, that adding functionality over and above what a real TI can do would be silly - it's no longer an emulator, it's a virtual hybrid machine!

Where I'm coming from is purely from the cross development side. It would be nice to (for example) have 9900 code invoke the debugger and halt. *Most* of the time though, the functions already built into the debugger are enough. There are one or two occasions when it isn't, but in fairness, the recent additions to the debugger (conditional breakpoints etc) have largely removed that requirement.

Re using CLIP: I think you are right. Just try to open the device... If it barfs, you're on the real deal.

It would be nice to switch on TURBO mode of Classic99. Maybe a TURBO device? Write any value to the device... If, say, the least significant bit is set, set the TURBO on and hear those fans spin! If LSB not set, go back to normal speed. Again, this would be compatible with a real machine, provided the author writes robust code with error checking...

Highjacking the subject here: Is real RS232 on the Classic99 road-map? I think I saw a mention of it in the README some time back.

---

From: ti99_forever <[email-masked]>
Date: Sun, 14 Feb 2010 21:14:16 -0800 (PST)

I proved some months ago that you can simply branch to the debugger in your 9900 code... and return from the debugger to your code. To me that is a lot nicer than setting breakpoints when your code is relocatable.

--- On Mon, 2/15/10, mark wills <[email-masked]> wrote:

From: mark wills <[email-masked]>
Subject: Re: [TI994A] Re: Detect if running on (classic99) emulator
To: [email-masked]
Date: Monday, February 15, 2010, 12:07 AM

It
 would be nice to switch on TURBO mode of Classic99. Maybe a TURBO device? Write any value to the device... If, say, the least significant bit is set, set the TURBO on and hear those fans spin! If LSB not set, go back to normal speed. Again, this would be compatible with a real machine, provided the author writes robust code with error checking...

---

From: ti99_forever <[email-masked]>
Date: Sun, 14 Feb 2010 21:16:01 -0800 (PST)

But I suppose you are talking the Classic99 debugger... ;) Now if you could "emulate" that the same way as the TIBUG debugger, that might be nice. IIRC, the TIBUG loads its entry point at the load interrupt...

--- On Mon, 2/15/10, ti99_forever <[email-masked]> wrote:

From: ti99_forever <[email-masked]>
Subject: Re: [TI994A] Re: Detect if running on (classic99) emulator
To: [email-masked]
Date: Monday, February 15, 2010, 12:14 AM

 

        

It

---

From: mark wills <[email-masked]>
Date: Sun, 14 Feb 2010 21:30:46 -0800 (PST)

With a machine code instruction there would be no need to set breakpoints. What could be nicer than

MOV @>8348,R0
ANDI R0,>0001
JEQ SOMEWHERE
BREAK
...
...

>Sent: Mon, 15 February, 2010 6:14:16
>--- On Mon, 2/15/10, mark wills <markrobertwills@ yahoo.co. uk> wrote:
>
>
>>From: mark wills <markrobertwills@ yahoo.co. uk>

---

From: mark wills <[email-masked]>
Date: Sun, 14 Feb 2010 21:31:55 -0800 (PST)

Yeah, sorry, was talking about cross development, using Classic99 debugger.

IIRC TI994W already has a couple of psuedo instructions... Can't remember now ;-)

>Sent: Mon, 15 February, 2010 6:16:01
>--- On Mon, 2/15/10, ti99_forever <ti99_forever@ yahoo.com> wrote:
>
>
>>From: ti99_forever <ti99_forever@ yahoo.com>

---

From: ti99_forever <[email-masked]>
Date: Sun, 14 Feb 2010 21:37:57 -0800 (PST)

I thought we were trying to NOT extend the machine...

 BLWP @>FFFE works pretty well enough on the real machine with TIBUG, why not have an address that trips the Classic99 debugger that could be "loaded" into the Load Interrupt via a stub program (or in your own code)? Something nonsensical for a real machine? I dunno... I need a vacation.

From: mark wills <[email-masked]>
Subject: Re: [TI994A] Re: Detect if running on (classic99) emulator
To: [email-masked]
Date: Monday, February 15, 2010, 12:30 AM

MOV @>8348,R0
ANDI R0,>0001
JEQ SOMEWHERE
BREAK
...
...

 

        

It

---

From: "Tursi" <[email-masked]>
Date: Sun, 14 Feb 2010 21:37:54 -0800

These, except the debugger, are compatible with ideas I had for the real 
machine... but again it kind of came down to software support.

The CLIP device I can implement in my (someday) ethernet server-based 
device, so that will someday be real if I get around to it.

Your idea of a TURBO device is interesting, because accelerated virtual CPUs 
was part of that design concept... maybe I could do them via a DSR too.... 
not what you wanted, though, hehe... sorry. Maybe I can implement a 
breakpoint mode that toggles turbo instead, that would be compatible with my 
vision.

Yes, real RS232 is on the roadmap. It's priority keeps bumping up and down, 
we'll see. :)

--------------------------------------------------
From: "mark wills" <[email-masked]>
Sent: Sunday, February 14, 2010 9:07 PM
To: <[email-masked]>
Subject: Re: [TI994A] Re: Detect if running on (classic99) emulator

> I too agree, that adding functionality over and above what a real TI can 
> do would be silly - it's no longer an emulator, it's a virtual hybrid 
> machine!
>
> Where I'm coming from is purely from the cross development side. It would 
> be nice to (for example) have 9900 code invoke the debugger and halt. 
> *Most* of the time though, the functions already built into the debugger 
> are enough. There are one or two occasions when it isn't, but in fairness, 
> the recent additions to the debugger (conditional breakpoints etc) have 
> largely removed that requirement.
>
> It would be nice to switch on TURBO mode of Classic99. Maybe a TURBO 
> device? Write any value to the device... If, say, the least significant 
> bit is set, set the TURBO on and hear those fans spin! If LSB not set, go 
> back to normal speed. Again, this would be compatible with a real machine, 
> provided the author writes robust code with error checking...
>
> Highjacking the subject here: Is real RS232 on the Classic99 road-map? I 
> think I saw a mention of it in the README some time back.

---

From: "Tursi" <[email-masked]>
Date: Sun, 14 Feb 2010 21:41:41 -0800

> I proved some months ago that you can simply branch to the debugger in 
> your 9900 code... and return from the debugger to your code. To me that is 
> a lot nicer than setting breakpoints when your code is relocatable.
>

Well, I think he's talking about the Classic99 debugger, which is external 
to the system and can break on memory accesses, including trapping reads or 
writes (including hardware) for particular values.

---

From: "Tursi" <[email-masked]>
Date: Sun, 14 Feb 2010 21:44:07 -0800

> With a machine code instruction there would be no need to set breakpoints. 

You're using 4 bytes of memory and 16 cycles for code that is a "do-nothing" 
in the final runtime, though. So I'd say "not using 4 bytes of memory and 16 
CPU cycles for a NOP" ;)

I see your point, I just don't agree. If you want functionality like that in 
Classic99, just use one of the XOP vectors and set a breakpoint at its 
target. :) That's what most real debuggers do anyway.

---

From: "Matthew" <[email-masked]>
Date: Mon, 15 Feb 2010 05:49:09 -0000

> Someone convince me why we need this? :)

You already explained part of the reason:

* For detecting Win994a's extra RAM is a simple case of doing ...
* Detecting Classic99's CLIP ...

On and on and on.  Having a pseudo device that returns the details of what features are present makes it so software developers don't have to run through a huge list of "checks" to figure out all the enhancements available.  Currently you would probably have no less than 3 or 4 different checks to make for all the various memory paging schemes out there.

Emulators already have these extra features and everyone is doing it their own way.  There is also real paging, I believe, via hardware like those uber RAM cards that are like gold to everyone out there (I've never seen one let alone owned one, and I think most TIers will be buried with theirs.)  So each RAM card has its own way of doing thing too I'm sure.

The point is, all of these enhancements are useless if there is no formal specification as to what is the correct, accepted, and documented way to do some of this stuff (and to know if the enhancement is available).  The DSR idea you suggested means that a real hardware implementation could respond to the query as well, which is awesome.  What gives you, me, or anyone else the "right" to make up the "official" spec?  Nothing really, except that if anyone takes the time to work out and document the details, that's usually more effort than anyone else is willing to do and that person becomes the custodian and maintainer by default and popularity.

As for a practical example, I can't think of many right now, mostly because our community is small compared to other classic systems, and not many people are writing new software.  However, interest in the 99/4A is growing recently thanks to the enthusiasm of a lot of people, and some new people over on the Atari forum have been asking for tools and what they need to get started.  It would be nice to say "yeah, we only have 32K of slow-ass RAM to work with, but we can page it out up to 8MB".  I'm pretty sure the MSX, C64, and all the other classic systems have such a thing already available and worked out.

Actually, for two examples of real software that could use a standard way of detecting features would be Pitfall and Adam's CRPG.  In both cases I could see them taking advantage of loading all the data from disk into paged RAM to make access much faster (or instant).  Then, if the paged RAM was not available, they could still read from the disk as they are now.  And for the CRPG, I could see having paged RAM a requirement so the world could be much bigger and the game more rich.

Also, if we standardized on certain things, then the hardware might just become a reality.  Look at what Jon and you did with the cartridge ROM kits.  Jon simply took charge, and with help from others made them up, and (most importantly) made them available to everyone at a very good price.  That format is going to become the "standard" simply because it is being done and is available.  People can buy the kits, experiment, make programs, and sell games in cartridge format.  And if someone writes a program that requires one of those devices then it is no big deal because by now everyone probably has one, and if they don't you can get one for about $10.

Anyway, I think having a standard specification for the "enhancements" is all good.  Whether the emulator developers decide to support it is up to them, but at least it would be there, worked out and documented.

Matthew

---

From: mark wills <[email-masked]>
Date: Sun, 14 Feb 2010 22:01:56 -0800 (PST)

Regarding halting, and invoking the debugger, I was thinking:

I'm pretty sure that the 9900 does not read the LSB when decoding instructions. Therefore BREAK could be implemented as a NOP with the LSB set. A real TI would see a NOP, but an emulator could (having decoded a NOP) check to see if the LSB is set, and behave accordingly.

In assembly, a simple EQU directive and an inline DATA word suffice.

In actuality, NOP is psuedo instruction, and compiles to JMP $+2. The opcode is >1100

Therefore NOP is >1102

Well, since we can only jump to even word boundaries, any JMP instruction with the LSB set could invoke the debugger:

BREAK EQU >1103 * JMP $+2 with LSB of offset set

In your code:
LI R0,...
MOV R0,...
INC R3...
DATA BREAK  <-- invoke debugger

The real TI would read that DATA BREAK as JMP $+2 - thus compatability with the real machine is maintained. For this particular example at least ;-)

M

>
>From: Tursi <[email-masked]>
>Sent: Mon, 15 February, 2010 6:37:54
>>------------ --------- --------- --------- --------- --
>>From: "mark wills" <markrobertwills@ yahoo.co. uk>
>>To: <TI994A@yahoogroups. com>

---

From: "Tursi" <[email-masked]>
Date: Sun, 14 Feb 2010 23:08:57 -0800

> On and on and on.  Having a pseudo device that returns the details of what 
> features are present makes it so software developers don't have to run 
> through a huge list of "checks" to figure out all the enhancements 
> available.  Currently you would probably have no less than 3 or 4 
> different checks to make for all the various memory paging schemes out 
> there.
>

CLIP is a standard TI DSR, so I disagree a little with the example. You read 
and write to it the same way you would any other device. You detect it the 
same way you would any other device. And although we did one little utility 
that uses it AS a clipboard, generally the intent was that it's just a 
transfer mechanism. ;)

As for the complications with all the memory paging schemes - I agree with 
you. This is why I am against implementing new features in Classic99 that 
are not compatible with real hardware. Win994A had a number of existing 
mechanisms to choose from for memory expansion, and the author chose not to 
use them. The stack functions create a new virtual machine rather than 
extend the existing one.

Trying to develop and maintain an emulation support device would quickly get 
out of hand, IMO. What extensions are "features"? Do we list bugs, too? (For 
example, Win994A does not properly handle the VDP address if you don't set 
the prefetch bit, but read anyway. Classic99 doesn't handle speech quite 
right.) Which emulators will support it? Will there be bugs in the 
implementation of this feature? How do we keep it up to date? Who will write 
software that uses it anyway, and will that software be usable on real 
machines?

Just too many options for my liking.

I can see where it might be useful... but even in real life, someone needs 
to build the card. Then everyone would need to adopt it. One thing I decided 
with my TI work some time ago was not to create anything that /requires/ 
people to adopt. Maybe that stance is the biggest reason I'm against it.

> The point is, all of these enhancements are useless if there is no formal 
> specification as to what is the correct, accepted, and >documented way to 
> do some of this stuff (and to know if the enhancement is available).

I agree with that, which is why I am against such enhancements. CLIP is just 
another file device, it doesn't change the system any more than adding a 
RAMdisk does.

> As for a practical example, I can't think of many right now, mostly 
> because our community is small compared to other classic systems, and not 
> many people are writing new software.  However, interest in the 99/4A is 
> growing recently thanks to the enthusiasm of a lot of people, and some new 
> people over on the Atari forum have been asking for tools and what they 
> need to get started.  It would be nice to say "yeah, we only have 32K of 
> slow-ass RAM to work with, but we can page it out up to 8MB".  I'm pretty 
> sure the MSX, C64, and all the other classic systems have such a thing 
> already available and worked out.
>

Not from what I've seen. There are systems for such things, yeah.. but they 
have limited support. Most people work on the base system. That's where the 
challenge is for most of these communities -- what can you make the system 
do? Not what can you add to it?

Let's be honest. With today's tech, it's trivial to make add-ons for super 
fast CPUs, HD-versions of the 9918 with 32-bit color, and every possible 
add-on you can imagine. But there will always be less software than for the 
base system, and simply creating software for such add-ons means you are 
leaving people out.

There WILL be people who want to go that way, cause it's fun to see what you 
can make it do. It's just not the path I really want to take. That's why my 
plans for uber-VDPs and co-processors has fallen and been replaced by a 
device interface. The only VDP enhancement I haven't ruled out is a new 9938 
with HD output (but still standard resolution). (Even then I'm leaning 
towards 9918A since the 9938 enhancement isn't widespread).

We already have several schemes for paged RAM. If they are all unacceptable, 
I'd like to see us use a DSR based version. Then it works for everyone - 
floppy based to massively RAM backed to emulation -- only the performance of 
it varies. I haven't studied the existing schemes so I can't really say 
which I prefer.

> Anyway, I think having a standard specification for the "enhancements" is 
> all good.  Whether the emulator developers decide to support it is up to 
> them, but at least it would be there, worked out and documented.
>

I'm resistant to standards being defined before the software support is 
there for them. Jon's cartridge was great and all, but all he did was extend 
the /existing/ standard used by XB and Atari. Even though I felt the wiring 
should be the other way around, because it was the existing standard I could 
get right behind that. :) Before he even released it, he convinced me of the 
value by requesting my help re-working some rare cartridges whose PALs were 
failing to work with the new standard. We couldn't reproduce the PALs easily 
but the new circuit was very simple. So that's not exactly the same as just 
jumping up and saying "this is how it should be". We had good cause before 
we really got anywhere on finalizing it. :)

I don't mean to shoot you down.. it's just not something I am really eager 
to work on, and with the size of my tasklist, I'll be busy a while! :)

---

From: "Ksarul" <[email-masked]>
Date: Mon, 15 Feb 2010 12:33:40 -0500

Note, you can always buy a nice, new SAMS RAM card from Tex*In Treasures,
Matthew, then you will have one of those wonderful über RAM cards for your
use (and program development, since that memory format is also compatible
with the SNUG SGCPU card and it is the most available today).

Jim Fetzner

<SNIP>
Emulators already have these extra features and everyone is doing it their
own way. There is also real paging, I believe, via hardware like those uber
RAM cards that are like gold to everyone out there (I've never seen one let
alone owned one, and I think most TIers will be buried with theirs.) So each
RAM card has its own way of doing thing too I'm sure.

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 10:27:55 -0700

How does one implement an XOP, and then use the XOP?  What is the 
general or specific reasons one might want to write an XOP for general 
use or for a specific use?  What are the benefits?  What are the negatives?

Bill S

Tursi wrote:
>  
> 
>  > With a machine code instruction there would be no need to set 
> breakpoints.
>  > What could be nicer than
>  > MOV @>8348,R0
>  > ANDI R0,>0001
>  > JEQ SOMEWHERE
>  > BREAK
>

---

From: "Matthew" <[email-masked]>
Date: Mon, 15 Feb 2010 17:32:06 -0000

> that uses it AS a clipboard, generally the intent was that it's just a 

Don't get me wrong, the CLIP device is very cool and I'm sure I'll take advantage of it a lot (I didn't even know about it until yesterday...)  But, to know that it is available I still have to code a check for it, that and all the other miscellaneous "features" I might want to take advantage of.  It would quickly get out of hand.

Correct me if I'm wrong, but I thought your suggestion of a "emulator" DSR was also doing things in a TI-standard way?  I guess I'm not quite sure how that would be a problem.  The emulator exposes the device, and it can be tested for in code.  Then, my assumption is that a physical computer that has enhancements could also make the DSR available, so the scheme works in both hardware and emulation.  Am I missing something?

> use them. The stack functions create a new virtual machine rather than 

I agree.  My suggestion was to do three things:

1. Document the existing schemes for things like RAM paging.

2. Settle on a community-derived standard for RAM paging and other features, ensuring that such things *could* be done with the real hardware.

3. Make the features of a machine available via the DSR idea you proposed.

> software that uses it anyway, and will that software be usable on real 

To me a "feature" or "enhancement" is something that can be done with real hardware in an acceptable way, that is, via the cartridge / side ports, the PEB, serial port, etc.  A "modification" is something that you have to open the box to do, but is still within the realm of real hardware, for example putting 32K on the 16-bit bus, removing wait states, adding interrupts, etc.  As for things that will never exist in real hardware or that are unique to a specific emulator/simulator, like the stack pointer in Win994a, I'd call that "virtual hardware" and I don't think there should be any effort to support or standardize on those kinds of things.

As for the bugs of a platform, I don't think it would necessary to track that in the DSR's blob of information, and that level of support would be up to the the software developer.  But having the emulator name and version would at least allow the software to make the decision as to whether or not to work around an emulator's bugs.

> people to adopt. Maybe that stance is the biggest reason I'm against it.

Well, if it is available and reasonable, I don't have anything against conforming.  Take an enhanced RAM card for example.  I simply can't get one, and if I made my own it would not work with anything other than software I wrote.  Also, I'm not going to copy any of the existing old cards either because it seems everyone wants to also own the rights to that old defunct hardware and not share that either.  Those cards were also designed with technology of the day, and a modern design would be more desirable anyway.

If a standard bank-switching RAM card was available for a reasonable price ($20 to $50), I'd buy one in a second, or I'd at least have the design to make my own with a reasonable amount of effort.  I think you would see that everyone would jump on such hardware and there would be very little "forcing" at all.  Look at Jon's cards.  He's doing a second run of 250, and the original run of 100 sold out in no time.  Having 350 cards out there is a far cry from forcing.  And look at that CF7+ card...  The only place you can get one is by luck on ebay.  Frustrating.

> another file device, it doesn't change the system any more than adding a 

And I didn't think your DSR idea would change the system either?

> there for them. 

What, write software without a spec??  :-)  I'd like to have some hardware spec first so I know what I'm supposed to code.

> Jon's cartridge was great and all, but all he did was extend 

What he did was make it available, and people are snatching them up.  It does not modify the hardware, and I would have no problem writing software that requires one of Jon's boards.

> to work on, and with the size of my tasklist, I'll be busy a while! :)

I hear you.  I'm simply talking about working out a formal document that defines how we should do hardware viable "features", and how software would detect and use the features.

Matthew

---

From: "Matthew" <[email-masked]>
Date: Mon, 15 Feb 2010 17:37:16 -0000

I can?  I was not aware that I could buy such a thing any more.  Any idea how much it would cost?

Matthew

---

From: "LARRY CORREA" <[email-masked]>
Date: Mon, 15 Feb 2010 09:37:21 -0800

Hello from Larry,

I can vouch for the SAMS Ram cards. I bought one from Mike and it went together well. Brd quality is excellent. I did however find that it could be improved.

If you are interested on what I did. e-mail me privately. [email-masked]<mailto:[email-masked]>

Larry

  ----- Original Message ----- 
  From: Ksarul<mailto:[email-masked]> 
  To: [email-masked]<mailto:[email-masked]> 
  Sent: Monday, February 15, 2010 9:33 AM
  Subject: [TI994A] Über RAM, was: Detect if running on (classic99) emulator

  Note, you can always buy a nice, new SAMS RAM card from Tex*In Treasures, Matthew, then you will have one of those wonderful über RAM cards for your use (and program development, since that memory format is also compatible with the SNUG SGCPU card and it is the most available today).

  Jim Fetzner

  <SNIP>

---

From: "LARRY CORREA" <[email-masked]>
Date: Mon, 15 Feb 2010 09:39:44 -0800

Just go to text'n treasures site.

Larry

  ----- Original Message ----- 
  From: Matthew<mailto:[email-masked]> 
  To: [email-masked]<mailto:[email-masked]> 
  Sent: Monday, February 15, 2010 9:37 AM
  Subject: [TI994A] Re: Über RAM, was: Detect if running on (classic99) emulator

  Matthew

---

From: Owen Brand <[email-masked]>
Date: Mon, 15 Feb 2010 12:45:59 -0500

80 bucks assembled

Owen Brand
Opry99er.com

---

From: "Matthew" <[email-masked]>
Date: Mon, 15 Feb 2010 17:45:35 -0000

You would typically use XOP if you were writing a debugger.  Basically the XOP instruction reads a specified word from memory and treats that word as an instruction itself without affecting the location of the instruction pointer.  In a debugger XOP is typically used to replace a specific real instruction in order to implement a break point at that instruction.

If someone does not beat me to it, I'll dig up an example since I can't remember the details off the top of my head.

Matthew

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 11:11:27 -0700

Mathew,

I'm asking these questions because my only experience with XOP usage is 
on the Geneve, and they were a "God send" for developing MDOS Forth+.  I 
was hoping similar XOP routines could be developed for X4th99, and 
thereby allow even more use of Forth+ code in X4th99.  In Forth+ they 
use a separate workspace, so can be used anywhere in Forth+ or by the 
user of Forth+.  Does this seem feasible for TI applications?

Bill S

Matthew wrote:
>  
> 
> You would typically use XOP if you were writing a debugger. Basically 
> the XOP instruction reads a specified word from memory and treats that 
> word as an instruction itself without affecting the location of the 
> instruction pointer. In a debugger XOP is typically used to replace a 
> specific real instruction in order to implement a break point at that 
> instruction.
> 
> If someone does not beat me to it, I'll dig up an example since I can't 
> remember the details off the top of my head.
> 
> Matthew
> 
> --- In [email-masked] <mailto:TI994A%40yahoogroups.com>, fdos 
> <fdosbrs@...> wrote:
>  >

---

From: "Matthew" <[email-masked]>
Date: Mon, 15 Feb 2010 18:58:37 -0000

XOP is an assembly / machine level instruction, I have no idea how it would be incorporated into a high level language.  I'm not familiar with Forth+, MDOS, the Geneve, or X4th99, so I cannot say anything intelligent about it.  Maybe in Forth+ there was something called "XOP" that was not related to the assembly instruction of the same name?

Hmm, actually, I'm wrong about XOP, I was remembering it as the X (execute) instruction, XOP is different.

To answer your original question, XOP could be used as a means to do software interrupts, except on the 4A the vector table is mapped to ROM so we can't change the vectors.  XOP works similar to BLWP except with XOP you don't need to know where you are going in memory, you only need to know the vector number 0 - 15.

Matthew

--- In [email-masked], fdos <fdosbrs@...> wrote:
> > <fdosbrs@> wrote:

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 12:10:53 -0700

Mathew,

XOP is the assembly instruction for "extended operation" in TMS9995 
parlance just as it is in the TMS9900.  So not a strange Forth word at all.

Hmmm.  Are XOP vectors predefined" or can they be defined by the 
programmers?  If not can more XOP vectors be added and coded?

Bill S

Matthew wrote:
>  
> 
> XOP is an assembly / machine level instruction, I have no idea how it 
> would be incorporated into a high level language. I'm not familiar with 
> Forth+, MDOS, the Geneve, or X4th99, so I cannot say anything 
> intelligent about it. Maybe in Forth+ there was something called "XOP" 
> that was not related to the assembly instruction of the same name?
> 
> To answer your original question, XOP could be used as a means to do 
> software interrupts, except on the 4A the vector table is mapped to ROM 
> so we can't change the vectors. XOP works similar to BLWP except with 
> XOP you don't need to know where you are going in memory, you only need 
> to know the vector number 0 - 15.
> 
> Matthew
> 
>  > > --- In [email-masked] <mailto:TI994A%40yahoogroups.com> 
> <mailto:TI994A%40yahoogroups.com>, fdos
>  > > <fdosbrs@> wrote:
>  > > >
>  > > > > in the final runtime, though. So I'd say "not using 4 bytes of 
> memory
>  > > > > and 16
>  > > > > CPU cycles for a NOP" ;)
>  > > > >
>  > > > > I see your point, I just don't agree. If you want functionality 
> like
>  > > > > that in

---

From: "Ksarul" <[email-masked]>
Date: Mon, 15 Feb 2010 14:54:05 -0500

I seem to remember that you only had XOP 0 and 1 available with the 9900. .
.and that 1 wasn't available with some masks of the 9900 CPU.  I'll have to
go hunting for where I saw that reference though.

Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
fdos
Sent: Monday, February 15, 2010 2:11 PM
To: [email-masked]
Subject: Re: [TI994A] Re: XOP questions

Mathew,

Bill S

Yahoo! Groups Links

---

From: "Matthew" <[email-masked]>
Date: Mon, 15 Feb 2010 19:50:08 -0000

In the 9900, the interrupt vector table is from >00 to >39 and the XOP vector table from >40 to >7F for a total of 16 interrupt vectors and 16 XOP vectors.  Those locations are hard wired into the CPU.

Hmm.  After reading the E/A manual for XOP on page 125, it seems that the vectors 1 and 2 are set to redirect to RAM locations:

XOP 1 -> PC = >8300, WP = >83A0
XOP 2 -> PC = >FFF8, WP = >FFD8

That was nice of them, since XOP 1 directs the CPU to code starting at address >8300 which is the start of scratch pad RAM.  And XOP 2 redirects to >FFF8 which is at the top of the standard 32K RAM expansion.  XOP 1 is said to not be available on all machines, but XOP 2 is always available.

I would like to see all the addresses in the ROM from >40 to >7F, maybe there are others we could use.

Matthew

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 13:01:06 -0700

It seems that XOP 2 is the one we need to use.  Does that mean we can 
only have one XOP routine or can it have multiple uses by some means or 
another?

Bill S

Matthew wrote:
>  
> 
> In the 9900, the interrupt vector table is from >00 to >39 and the XOP 
> vector table from >40 to >7F for a total of 16 interrupt vectors and 16 
> XOP vectors. Those locations are hard wired into the CPU.
> 
> Hmm. After reading the E/A manual for XOP on page 125, it seems that the 
> vectors 1 and 2 are set to redirect to RAM locations:
> 
> That was nice of them, since XOP 1 directs the CPU to code starting at 
> address >8300 which is the start of scratch pad RAM. And XOP 2 redirects 
> to >FFF8 which is at the top of the standard 32K RAM expansion. XOP 1 is 
> said to not be available on all machines, but XOP 2 is always available.
> 
> <mailto:TI994A%40yahoogroups.com>
>  > > > > > > Classic99, just use one of the XOP vectors and set a 
> breakpoint
>  > > at its

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 13:02:20 -0700

Jim,

I'll wait for further clarification?

Bill S

Ksarul wrote:
> From: [email-masked] <mailto:TI994A%40yahoogroups.com> 
> [mailto:[email-masked] <mailto:TI994A%40yahoogroups.com>] On 
> Behalf Of
> fdos
> To: [email-masked] <mailto:TI994A%40yahoogroups.com>

---

From: "Tursi" <[email-masked]>
Date: Mon, 15 Feb 2010 12:42:54 -0800

> Don't get me wrong, the CLIP device is very cool and I'm sure I'll take 
> advantage of it a lot (I didn't even know about it until yesterday...) 
> But, to know that it is available I still have to code a check for it, 
> that and all the other miscellaneous "features" I might want to take 
> advantage of.  It would quickly get out of hand.
>

Why would the CLIP device be specially taken care of? Do you also check for 
RAMdisks, hard drives, the CF7, DSK4, and other non-original devices? Do you 
check for a thermal printer versus parallel versus serial before you print, 
and verify they exist, or just ask the user for a device and try it?

The only real difference I am seeing is instead of doing:

-Open CLIP device
-Branch if error
-Use device

You want to do:

-Open DEVICESUPPORT device (or EMULATION etc)
-Branch if error (to what, though?)
-Read supported devices record(s)
-Parse record
-Close device
-See whether CLIP is supported
-Branch if not
-Open CLIP device
-Branch if error
-Use device

Basically, my point is that in the single device test case, the argument 
breaks down. And although I am trying I can't see how the multi-device test 
case is actually any less code than just trying, since you still need to 
have all the code and error handling for every device you wish to support 
anyway.

And what does your code do on a system where the DEVICESUPPORT device 
doesn't exist? Do you simply assume that everything in it also does not 
exist? That would break on systems that have implemented the device in 
question but not the enumerator, causing an artificial dependence.

> Correct me if I'm wrong, but I thought your suggestion of a "emulator" DSR 
> was also doing things in a TI-standard way?  I guess I'm not quite sure 
> how that would be a problem.  The emulator exposes the device, and it can 
> be tested for in code.  Then, my assumption is that a physical computer 
> that has enhancements could also make the DSR available, so the scheme 
> works in both hardware and emulation.  Am I missing something?
>

You are dead-on correct with this. My concern lies more in how this will be 
used, and how much value it's actually adding. In other words, why is it 
actually better than what we have today? I see maintenance issues 
(especially with physical implementations) and what bothers me more, I see 
code specifically written for virtual systems, which fragments the community 
some.

My other concern lies with inconsistent support of the concept. Some 
emulators will have it, some won't. Some systems may have it, some won't. 
Any may have any combination of devices.

I'm asking for a practical test case where the use of this is more effective 
than simply testing for presence. In all modern systems, testing for 
presence is how a device is detected. In a physical implementation, you'd 
have to pretty much do the same anyway (testing for every possible device), 
since the TI is a plug-and-play system. Only in emulation can the emulator 
really "know" out of the box what it has or doesn't have.

> And I didn't think your DSR idea would change the system either?

It doesn't. From a system integration point, or compatibility point, it's 
fine. But I don't see the value add.

You don't need me, either, though. Other specifications have been declared 
in the community that I have chosen not to align with.

> What, write software without a spec??  :-)  I'd like to have some hardware 
> spec first so I know what I'm supposed to code.

You haven't told me what you want to code yet that requires the spec! ;)

> What he did was make it available, and people are snatching them up.  It 
> does not modify the hardware, and I would have no problem writing software 
> that requires one of Jon's boards.
>

It's also self-contained, and I can still make cartridges that do NOT use 
Jon's board, and nobody needs to do anything to run my cart. You don't need 
to buy "Jon's Cart" in order to run Pitfall, you just buy Pitfall. It's not 
the same as expecting everyone to install a "system enumerator" card.

I just don't like the only applications I can imagine using it. You need to 
convince me of an application where it solves a problem to get me on board. 
:)

If you want to define a RAM board -- then let's define a RAM board, the 
enumerator doesn't solve that. A RAM board has some value (though personally 
I think new software should just use a swap file if it can get away with 
it - then RAMdisks give the best speed but floppy users can still use it, 
and we just need to define a new fast RAMdisk, hiding the implementation 
behind the DSR. ;) )

> I hear you.  I'm simply talking about working out a formal document that 
> defines how we should do hardware viable "features", and how software 
> would detect and use the features.
>

I don't think we are solving any problems here - in fact I haven't really 
got on page yet with what the problem is, so trying to convince me the 
solution is correct is premature. :)

I feel like you're getting into this because I got "clever" with my CLIP 
usage in Owen's program. All he has to do is change it to ask the user for a 
device to save to instead, and then it's a completely standard tool that can 
still use CLIP, as well as DSK1, RS232, PIO, etc. ;) The TI DSR is /meant/ 
to be extended with devices and is /intended/ to be device agnostic. You 
don't need to know what's behind a DSR, that's the whole point.

At any rate, I'm interested in hearing what Michael and Fred, and for that 
matter Cory, if he's around, think about adding support for a DSR-based 
feature enumerator to their emulators. It's only valuable if everyone would 
be willing to implement it. Otherwise, it's definitely pointless.

---

From: "Tursi" <[email-masked]>
Date: Mon, 15 Feb 2010 12:46:37 -0800

> use or for a specific use?  What are the benefits?  What are the

XOP is basically a single word BLWP. However, I'll preface this by noting
that my suggested use to Mark is NOT a normal use and that advice was
tailored to the Classic99 debugger (since with that you could break even on
ROM jumps, meaning you don't need any special program setup). More
generally, however, because it's a single word, it is ideal for replacing
words in program code to simulate a breakpoint.

When XOP is encountered, it takes two arguments. The source argument may be
any addressing mode, for those that take two words, the second word follows
the instruction normally. This is the data for the XOP and is passed to the
subroutine. The second argument is a value from 0-15, and indicates an
offset into the XOP lookup table, which is hard-wired to exist at >0040 in
the ROM.

Each offset in the XOP table is a 4 byte BLWP-style reference - the first
word is a new workspace register, the second is the new address. The source
data address is placed into the new R11, old workspace in the new R13, old
PC in the new R14, and old Status register in the new R15. The 'X' bit in
the status register is then set and execution branches to the vector
address. You return from an XOP subroutine with RTWP.

Because the vector in the TI-99/4A is located in ROM, there is limited
support. The E/A manual says that all consoles support XOP 2, which branches
to >8300 with a WP of >83A0. Some consoles support XOP 1, which branches to
 >FFF8 with a WP of >FFD8. The rest of the table is of questionable value:

XOP    WP    PC
0    280A    0C1C
1    FFD8    FFF8   <- supported on some consoles
2    83A0    8300  <- supported on all consoles
3    1100    06A0
4    0864    06A0
5    0864    C90D
6    8300    C342
7    D11D    C180
8    DB46    0402
9    DB60    83ED
10  0402    5820
11  011B    837C
12  0300    0002
13  0300    0000
14  D25D   1105
15  D109    09C4

Of course, depending on the version of ROM in your console, the
non-supported values may differ. This does reduce the value of the XOP
instruction a fair bit.

Back to my example, with the Classic99 debugger you can use one of the
unsupported XOP vectors, and just break when it gets there - even though the
vector may not be useful (unfortunately if you want to resume you must use
one that puts the WP in RAM). You can then manually jump to a convenient
RTWP to resume code execution by changing the PC.

You'll find notes on XOP in the Editor/Assembler manual on pages 41 (flag
note 3), 43 (3.1.3.7 describing the X flag), 76 (5.9 describing the XOP
opcode format), 125 (7.19 describing XOP itself), and 136 (7.20.4 describing
how XOP is used). Page 233 (14.5) also described DXOP, which lets you define
your own opcode for an XOP in the TI Editor/Assembler. Thierry also has an
excellent discussion of XOP in the TI here:
http://nouspikel.group.shef.ac.uk//ti99/tms9900.htm#XOP

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 14:24:42 -0700

Tursi,

Thank you very much for this clear and precise explanation.  I will also 
check all the references and Thierry's website for more details now that 
I have a basic understanding.  Afterwards I may have more specific 
questions to ask.  Unless I decide it's not useful for my purpose.

Bill S

---

From: "epergrem" <[email-masked]>
Date: Mon, 15 Feb 2010 21:29:52 -0000

It's a great DIY project also.  Very easy board to solder.  You want save much doing the work yourself, but you'll have the fun to go with your snappy new card.

It's also not rare, so if you write software that requires it, then anyone can buy the board.

Ernie

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 15:06:16 -0700

I support this DIY project 100%.  I did two with my poor eyesight and 
unsteady hands, and both boards tested without a flaw, and one is in use 
the other is backup, so anyone who can solder just a bit can do it.  And 
X4th99 is coming, so be ready!

Bill S

epergrem wrote:
>  
> 
> It's a great DIY project also. Very easy board to solder. You want save 
> much doing the work yourself, but you'll have the fun to go with your 
> snappy new card.
> 
> --- In [email-masked] <mailto:TI994A%40yahoogroups.com>, Owen 
> Brand <owenbrand@...> wrote:
>  >
>  > 80 bucks assembled
>  >
>  > Owen Brand
>  > Opry99er.com
> 
>

---

From: "LARRY CORREA" <[email-masked]>
Date: Mon, 15 Feb 2010 14:32:08 -0800

I second that emotion. 

Larry C
  ----- Original Message ----- 
  From: fdos<mailto:[email-masked]> 
  To: [email-masked]<mailto:[email-masked]> 
  Sent: Monday, February 15, 2010 2:06 PM
  Subject: Re: [TI994A] Re: Über RAM, was: Detect if running on (classic99) emulator

  Bill S

  epergrem wrote:
  > --- In [email-masked]<mailto:[email-masked]> <mailto:TI994A%40yahoogroups.com<mailto:TI994A%40yahoogroups.com>>, Owen 

  Yahoo! Groups Links

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 16:21:51 -0700

Who's the funny guy here?  I never speak emotionally--only factually, my 
facts, of course. :-)

Bill S

LARRY CORREA wrote:
>     *From:* fdos <mailto:[email-masked]>
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Sent:* Monday, February 15, 2010 2:06 PM
>     *Subject:* Re: [TI994A] Re: Über RAM, was: Detect if running on
>     (classic99) emulator
> 
>      > --- In [email-masked] <mailto:[email-masked]>
>     <mailto:TI994A%40yahoogroups.com <mailto:TI994A%40yahoogroups.com>>,
>     Owen
>         (Yahoo! ID required)
>     <mailto:[email-masked]>
> 
> 
> 
>

---

From: Owen Brand <[email-masked]>
Date: Mon, 15 Feb 2010 18:30:06 -0500

>  X4th99 is coming, so be ready!

Bill, I'll buy a SAMS card from Mike when your software comes out.   
This is the kind of thing that would make me buy hardware, although I  
have resisted moving beyond a reasonably "stock" system.  I can't wait  
to see docs and some demos. :)

Owen Brand
Opry99er.com

On Feb 15, 2010, at 6:21 PM, fdos <[email-masked]> wrote:

>>    unsteady hands, and both boards tested without a flaw, and one  
>> is in
>>    use
>>    the other is backup, so anyone who can solder just a bit can do  
>> it.
>>    And

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 16:52:21 -0700

Owen,

Your policy is a good one, and I agree.  If one has no other use for a 
specific piece of hardware other than a piece of software you would like 
to use, but it's not available yet, then waiting until it is available 
makes sense.

I do believe the time is coming when memory beyond 32K will make sense 
for other developers also.  We can see how you guys are pushing the 
limits now, and I'm sure one of the reasons for holding back is how to 
use the extended memory easily.  X4th99 will do that.

My real TI/Geneve hardware systems are getting close to the state that I 
need them, so I will be getting back to the software development that I 
love to do, as I believe you do also.  Other than CALL 
LINK("CHAIN",FILE$) I believe that I'll be able to finish TI BASIC+ in a 
few months (baring any other disasters), as the remaining work looks to 
be pretty easy.  And if you've noticed I've managed to debug a serious 
flaw in X4th99 without lifting a finger or even realizing the bug 
existed.  Now how fabulous is that? :-)  Where else can such a thing happen?

Bill S

Owen Brand wrote:
> Bill, I'll buy a SAMS card from Mike when your software comes out.  This 
> is the kind of thing that would make me buy hardware, although I have 
> resisted moving beyond a reasonably "stock" system.  I can't wait to see 
> docs and some demos. :)
> 
> Owen Brand
> Opry99er.com <http://Opry99er.com>
> 
> On Feb 15, 2010, at 6:21 PM, fdos <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>>>    *From:* fdos <mailto:[email-masked] 
>>> <mailto:[email-masked]>>
>>> <mailto:[email-masked] <mailto:[email-masked]>>
>>>> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>> Opry99er.com <http://Opry99er.com>
>>>>
>>>>
>>>
>>>
>>> <mailto:[email-masked]>[email-masked] 
>>>    <mailto:[email-masked] 
>>> <mailto:[email-masked]>>
>>>
>>>
>>>
>>>
>>
>>
>> <http://groups.yahoo.com/group/TI994A/>
>>
>> <http://groups.yahoo.com/group/TI994A/join>
>>    (Yahoo! ID required)
>>
>> <mailto:[email-masked]>[email-masked] 
>> <mailto:[email-masked]>
>>
>> <http://docs.yahoo.com/info/terms/>
>>
>

---

From: Owen Brand <[email-masked]>
Date: Mon, 15 Feb 2010 20:43:14 -0500

Bill... Is this like regular Forth in that the compiled Forth files  
can be run on a non-SAMS system?  I know it is required to use your  
X4th99 for programming, but are the applications output by the code  
also reliant on the SAMS card?  I think the answer is no, but I want  
to be sure.

Owen Brand
Opry99er.com

On Feb 15, 2010, at 6:52 PM, fdos <[email-masked]> wrote:

>> This
>>>>   *Subject:* Re: [TI994A] Re: Ãœber RAM, was: Detect if runni 
>>>> ng on
>>>>   (classic99) emulator
>>>>
>>>>> It's also not rare, so if you write software that requires it,  
>>>>> then
>>>>> anyone can buy the board.
>>>>>
>>>>> Ernie
>>>>>

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 19:36:00 -0700

Owen,

X4th99 is a programing environment that includes, in addition to normal 
vocabularies, binary code libraries--not source code libraries.  It 
means you have immediate use and testing of any Forth words you create 
using live links to binary code.

You can create applications and FSAVE/BSAVE them, but anyone else 
wanting to use those applications would have to have X4th99 installed. 
Just like TI BASIC or TI XB are required to "RUN" programs created with 
them.  You will also be allowed to create an application that includes 
all of X4th99 or just the X4th99 kernel and any necessary binary code 
libraries.  X4th99 will be freeware, so everyone can have it if they 
have the minimum 256K of AMS/SAMS (which is not included ;-).

Bill S

Owen Brand wrote:
> On Feb 15, 2010, at 6:52 PM, fdos <[email-masked] 
> <mailto:fdosbrs%40frontiernet.net>> wrote:
> 
>  > Owen,
>  >
>  >> Opry99er.com <http://Opry99er.com <http://Opry99er.com>>
>  >>
> <mailto:fdosbrs%40frontiernet.net>
>  >> <mailto:[email-masked] <mailto:fdosbrs%40frontiernet.net>>> 
> wrote:
>  >>
> <mailto:fdosbrs%40frontiernet.net>
>  >>>> <mailto:[email-masked] <mailto:fdosbrs%40frontiernet.net>>>
>  >>>> *To:* [email-masked] <mailto:TI994A%40yahoogroups.com> 
> <mailto:[email-masked] <mailto:TI994A%40yahoogroups.com>>
>  >>>> <mailto:[email-masked] <mailto:TI994A%40yahoogroups.com> 
> <mailto:[email-masked] <mailto:TI994A%40yahoogroups.com>>>
> <mailto:[email-masked] <mailto:TI994A%40yahoogroups.com>>
>  >>>>> <mailto:[email-masked] <mailto:TI994A%40yahoogroups.com> 
> <mailto:[email-masked] <mailto:TI994A%40yahoogroups.com>>>
>  >>>>>> Opry99er.com <http://Opry99er.com <http://Opry99er.com>>
>  >>>>>
>  >>>>>
>  >>>>
>  >>>>
> <mailto:TI994A-fullfeatured%40yahoogroups.com>>TI994A-
>  >>>> [email-masked] <mailto:fullfeatured%40yahoogroups.com>
> <mailto:TI994A-fullfeatured%40yahoogroups.com>>
> <mailto:TI994A-fullfeatured%40yahoogroups.com>
> <mailto:TI994A-fullfeatured%40yahoogroups.com>>>
>  >>>>
>  >>>>
>  >>>>
>  >>>>
>  >>>
>  >>>
>  >>> <http://groups.yahoo.com/group/TI994A/ 
> <http://groups.yahoo.com/group/TI994A/>>
>  >>>
>  >>> <http://groups.yahoo.com/group/TI994A/join 
> <http://groups.yahoo.com/group/TI994A/join>>
>  >>> (Yahoo! ID required)
>  >>>
> <mailto:TI994A-fullfeatured%40yahoogroups.com>>TI994A-
>  >>> [email-masked] <mailto:fullfeatured%40yahoogroups.com>
> <mailto:TI994A-fullfeatured%40yahoogroups.com>>
>  >>>
>  >>> <mailto:[email-masked] 
> <mailto:TI994A-unsubscribe%40yahoogroups.com>>
>  >>>
>  >>> <http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/>>
>  >>>
>  >>
>  >
>  >

---

From: mark wills <[email-masked]>
Date: Mon, 15 Feb 2010 19:37:32 -0800 (PST)

Isn't XOP a no-no on the TI? I thought I read in the editor assembler manual that it should not be used?

Thou Shalt Not Use Thy Holy XOP, Lest Thy Be Smite In Twain.

:-)

----- Original Message ----
> From: fdos <[email-masked]>
> Sent: Mon, 15 February, 2010 19:11:27
> > --- In [email-masked] , fdos 
> > wrote:
> >  >

---

From: mark wills <[email-masked]>
Date: Mon, 15 Feb 2010 19:41:30 -0800 (PST)

>XOP 1 is said to not be available on all machines, but XOP 2 is always available.

Ah! So that's the reason for thy holy commandment...

What do they mean 'not available on all machines'? Do they mean

1) Because scratch pad might not be mapped to >8300 (impossible without major ROM/GROM re-writes)
2) Because the vector might point somewhere else

I think probably 2. However, I think the chances of them having changed the vector in ROM is very very small. Anyone got a V2 console they can check?

M

>Sent: Mon, 15 February, 2010 20:50:08
>Subject: [TI994A] Re: XOP questions
>
> >
>
>
>
>
>  >
>>      
> 
>>--- In TI994A@yahoogroups. com, fdos <fdosbrs@... > wrote:
>>>
>>> Mathew,
>>> 
>>> > --- In TI994A@yahoogroups. com <mailto:TI994A% 40yahoogroups. com>, fdos 
>>> > <fdosbrs@> wrote:
>>> >  >
>>> >  > Mathew,
>>> >  >
>>> >  > > --- In TI994A@yahoogroups. com <mailto:TI994A% 40yahoogroups. com> 
>>> > <mailto:TI994A% 40yahoogroups. com>, fdos
>>> >  > > <fdosbrs@> wrote:
>>> >  > > >

---

From: mark wills <[email-masked]>
Date: Mon, 15 Feb 2010 19:46:37 -0800 (PST)

It can have multiple uses, by simply stashing a flag somewhere before you call XOP.

When control is transferred to the routine by XOP, you retrieve your flag and determine the course of action to be taken...

----- Original Message ----
> Sent: Mon, 15 February, 2010 21:01:06
> >  > > > > --- In [email-masked] 
> > 
> >  > > , fdos
> >  > > > > wrote:
> >  > > > > >

---

From: mark wills <[email-masked]>
Date: Mon, 15 Feb 2010 20:44:00 -0800 (PST)

Bill

Thinking about it, you can probably get more mileage from BLWP.

Don't forget, you can use BLWP Rx - this is only 2 bytes, whereas the 'standard' BLWP is 4 bytes.

You could implement single step quite easily in Forth, my modifying NEXT.

You would:

Identify an instruction in NEXT to be replaced.
Replace that instruction with a BLWP Rx (the value in Rx points to a vector)
The vector is initialised to run your debugger (maybe just do a .S and KEY)
Execute the saved instruction
Loop

This is just an example.

In actual fact, if I were implementing single-step in Forth, I would actually load a new NEXT over the old one, the new one including a branch to the single-stepper/debugger.

When the user has finished de-bugging, he can re-boot or re-load the original NEXT.

Mark

>Sent: Mon, 15 February, 2010 22:24:42
>>> http://nouspikel. group.shef. ac.uk//ti99/ tms9900.htm# XOP
>>> 
>>> 
>>> 
>>> 
>>>

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 22:24:30 -0700

OK, so it can work the way I need it to, I just have to learn how to 
code for it and implement it.

Bill S

mark wills wrote:
> When control is transferred to the routine by XOP, you retrieve your 
> flag and determine the course of action to be taken...
> 
>  > From: fdos <[email-masked] <mailto:fdosbrs%40frontiernet.net>>
>  > > I would like to see all the addresses in the ROM from >40 to >7F, 
> maybe
>  > > there are others we could use.
>  > >
>  > > Matthew
>  > >
>  > > --- In [email-masked] <mailto:TI994A%40yahoogroups.com> , fdos
>  > > wrote:
>  > > >
>  > > > Mathew,
>  > > >
>  > > > parlance just as it is in the TMS9900. So not a strange Forth 
> word at
>  > > all.
>  > > >
>  > > > > software interrupts, except on the 4A the vector table is 
> mapped to
>  > > ROM
>  > > > > > > If someone does not beat me to it, I'll dig up an example 
> since I
>  > > > > can't
>  > > > > > > > general or specific reasons one might want to write an 
> XOP for
>  > > > > general
>  > > > > > > > use or for a specific use? What are the benefits? What 
> are the
>  > > > > negatives?
>  > > > > > > >
>  > > > > > > > Bill S
>  > > > > > > >
>  > > > > > > > Tursi wrote:
>  > > > > > > > >
>  > > > > > > > >
>  > > > > > > > > You're using 4 bytes of memory and 16 cycles for code 
> that is a
>  > > > > > > > > "do-nothing"

---

From: fdos <[email-masked]>
Date: Mon, 15 Feb 2010 22:29:10 -0700

I understand that single-step is just an example.  I suppose the 
question to ask is, which is quicker (XOP or BLWP as both use RTWP)?

Bill S

mark wills wrote:
> In actual fact, if I were implementing single-step in Forth, I would 
> actually load a new NEXT over the old one, the new one including a 
> branch to the single-stepper/debugger.
> 
>     *From:* fdos <[email-masked]>
>     *To:* [email-masked]
>     *Sent:* Mon, 15 February, 2010 22:24:42
>     *Subject:* Re: [TI994A] Re: XOP questions
> 
>      
> 
>     Tursi,
> 
>      > offset into the XOP lookup table, which is hard-wired to exist at
>      >0040 in
>      > the ROM.
>      >
>     <http://nouspikel.group.shef.ac.uk//ti99/tms9900.htm#XOP>
>      >
>      >
>      >
>      >
>      >

---

From: ti99_forever <[email-masked]>
Date: Mon, 15 Feb 2010 22:18:50 -0800 (PST)

Wouldn't be too different, they are both context switches...
XOP just loads R11 with your "data", BLWP doesn't, so it is possible that XOP is slower (likely)...

--- On Tue, 2/16/10, fdos <[email-masked]> wrote:

> Date: Tuesday, February 16, 2010, 12:29 AM
> > Don't forget, you can use BLWP Rx - this is only 2
> bytes, whereas the 
> > 'standard' BLWP is 4 bytes.
> > 
> > When the user has finished de-bugging, he can re-boot
> or re-load the 
> > original NEXT.
> > 
> > Mark
> > 
> > 
> > 
> > 
> >     Thank you very much for this
> clear and precise explanation. I will also
> >     check all the references and
> Thierry's website for more details now
> >     that
> >      >> How does one implement an
> XOP, and then use the XOP? What is the
> >      >> general or specific
> reasons one might want to write an XOP for
> >     general
> >      >> use or for a specific
> use? What are the benefits? What are the
> >      >> negatives?
> >      >
> >      > XOP is basically a single
> word BLWP. However, I'll preface this
> >     by noting
> >      > that my suggested use to Mark
> is NOT a normal use and that advice was
> >      > tailored to the Classic99
> debugger (since with that you could
> >     break even on
> >      > ROM jumps, meaning you don't
> need any special program setup). More
> >      > generally, however, because
> it's a single word, it is ideal for
> >     replacing
> >      > words in program code to
> simulate a breakpoint.
> >      >
> >      > When XOP is encountered, it
> takes two arguments. The source
> >     argument may be
> >      > any addressing mode, for
> those that take two words, the second
> >     word follows
> >      > the instruction normally.
> This is the data for the XOP and is
> >     passed to the
> >      > subroutine. The second
> argument is a value from 0-15, and
> >     indicates an
> >      > offset into the XOP lookup
> table, which is hard-wired to exist at
> >      >0040 in
> >      > the ROM.
> >      >
> >      > Each offset in the XOP table
> is a 4 byte BLWP-style reference -
> >     the first
> >      > word is a new workspace
> register, the second is the new address.
> >     The source
> >      > data address is placed into
> the new R11, old workspace in the new
> >     R13, old
> >      > PC in the new R14, and old
> Status register in the new R15. The
> >     'X' bit in
> >      > the status register is then
> set and execution branches to the vector
> >      > address. You return from an
> XOP subroutine with RTWP.
> >      >
> >      > Because the vector in the
> TI-99/4A is located in ROM, there is
> >     limited
> >      > support. The E/A manual says
> that all consoles support XOP 2,
> >     which branches
> >      > to >8300 with a WP of
> >83A0. Some consoles support XOP 1, which
> >     branches to
> >      > >FFF8 with a WP of
> >FFD8. The rest of the table is of
> >     questionable value:
> >      >
> >      > XOP WP PC
> >      > 0 280A 0C1C
> >      > 1 FFD8 FFF8 <- supported
> on some consoles
> >      > 2 83A0 8300 <- supported
> on all consoles
> >      > 3 1100 06A0
> >      > 4 0864 06A0
> >      > 5 0864 C90D
> >      > 6 8300 C342
> >      > 7 D11D C180
> >      > 8 DB46 0402
> >      > 9 DB60 83ED
> >      > 10 0402 5820
> >      > 11 011B 837C
> >      > 12 0300 0002
> >      > 13 0300 0000
> >      > 14 D25D 1105
> >      > 15 D109 09C4
> >      >
> >      > Of course, depending on the
> version of ROM in your console, the
> >      > non-supported values may
> differ. This does reduce the value of
> >     the XOP
> >      > instruction a fair bit.
> >      >
> >      > Back to my example, with the
> Classic99 debugger you can use one
> >     of the
> >      > unsupported XOP vectors, and
> just break when it gets there - even
> >     though the
> >      > vector may not be useful
> (unfortunately if you want to resume you
> >     must use
> >      > one that puts the WP in RAM).
> You can then manually jump to a
> >     convenient
> >      > RTWP to resume code execution
> by changing the PC.
> >      >
> >      > You'll find notes on XOP in
> the Editor/Assembler manual on pages
> >     41 (flag
> >      > note 3), 43 (3.1.3.7
> describing the X flag), 76 (5.9 describing
> >     the XOP
> >      > opcode format), 125 (7.19
> describing XOP itself), and 136 (7.20.4
> >     describing
> >      > how XOP is used). Page 233
> (14.5) also described DXOP, which lets
> >     you define
> >      > your own opcode for an XOP in
> the TI Editor/Assembler. Thierry
> >     also has an
> >      > excellent discussion of XOP
> in the TI here:
> >      > http://nouspikel. group.shef.
> ac.uk//ti99/ tms9900.htm# XOP
> >      >
> >      >
> >      >
> >      >
> >      >
> >      > ------------ ---------
> --------- ------
> >      >
> >      > Yahoo! Groups Links
> >      >
> >      >
> >      >
> >      >

---

From: ti99_forever <[email-masked]>
Date: Mon, 15 Feb 2010 22:28:11 -0800 (PST)

Yep, I remember reading that section of the EA manual and dumping the table, then coding a test program just to test the different XOPs, and there are a few that were usable (IIRC, 6) - on that particular console, at least.

You know what'd be fun? How about a little program to dump our XOP vectors and we can post them for comparison? I'd really like to know how common or different they are.

If we can have a statistical sample prove that certain vectors are reliable, then anyone with a console outside the norm, oh well, SOL! Get another $5 console! ;)

Seriously, I'd like to see your XOP vectors... please?

--- On Mon, 2/15/10, Tursi <[email-masked]> wrote:

> Date: Monday, February 15, 2010, 3:46 PM
> XOP for general
> > use or for a specific use?  What are the
> benefits?  What are the
> > negatives?
>

---

From: "Tursi" <[email-masked]>
Date: Mon, 15 Feb 2010 22:44:09 -0800

> I think probably 2. However, I think the chances of them having changed 
> the vector in ROM is very very small.
> Anyone got a V2 console they can check?

They mean #2. Since the Editor/Assembler manual was printed before the V2 
ROMs came out (and the big changes there are in the GROM anyway), they 
probably aren't talking about that version. But there are small variations 
apparently in the base ROM.

> When control is transferred to the routine by XOP, you retrieve your flag 
> and determine the course of action to be taken...

There's no need to stash any flags - the source argument's address is passed 
to your subroutine in R11, just use that. :)

---

From: "Tursi" <[email-masked]>
Date: Mon, 15 Feb 2010 22:45:46 -0800

> 'standard' BLWP is 4 bytes.

Thierry's page explains the main reason that you might use XOP instead of 
BLWP -- XOP does not require any registers to contain particular values, 
making it much more useful for such things as debuggers, which can't 
guarantee the state of the registers. :)

---

From: Owen Brand <[email-masked]>
Date: Tue, 16 Feb 2010 11:21:37 -0500

Ahh, good info Bill, thanks!!!  Makes things a bit more clear now. :)

Owen Brand
Opry99er.com

On Feb 15, 2010, at 9:36 PM, fdos <[email-masked]> wrote:

>>>>>> *Subject:* Re: [TI994A] Re: ÃƒÅ“ber RAM, was: Detect i 
>>>>>> f runni
>>>>>> ng on
>>>>>> (classic99) emulator
>>>>>>
>>>>> <http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/ 
>>>>> >>
>>>>>
>>>>
>>>
>>>

---

From: mark wills <[email-masked]>
Date: Tue, 16 Feb 2010 08:41:26 -0800 (PST)

Dear all,
 
The last remnants of the TIUG UK are arranging what looks like will be the last ever TI Faire in the UK.
 
Dates are not set yet, but looks to be some time in September.
 
Would any of our American and European friends be interested in attending? I will be going, and there is talk of the BBC Click team being there.
 
I'm sure a great time will be had by all, and I would love to see some visitors from foreign shores.
 
Mark

---

From: Keith Bergman <[email-masked]>
Date: Tue, 16 Feb 2010 13:42:34 -0500

Oh man.... tempting!  No way could I pull that off, but hopefully we can all
be there in spirit, and via video...

On Tue, Feb 16, 2010 at 11:41 AM, mark wills <[email-masked]>wrote:

> Would any of our American and European friends be interested in attending?
> I will be going, and there is talk of the BBC Click team being there.
>
>
>

---

From: "Beery" <[email-masked]>
Date: Tue, 16 Feb 2010 19:05:44 -0000

If on a Geneve, the windows source code has the details on how to implement an XOP if you want a library of utilities.  It would/could use similar logic on the TI-99/4A if you had ram in the >0000 to >1FFF space, except one's code would have to typically reside in the 32K ram area.

It's something I think that could be implemented with a Gram Kracker or other low ram memory devices, but in a stock TI-99/4A, then you are prevented from building the Geneve typie XOP libraries.

Beery

---

From: ti99_forever <[email-masked]>
Date: Tue, 16 Feb 2010 11:31:01 -0800 (PST)

But a Gram Kracker only implements GROM in the low memory area.

You can replace the ROMs with RAMs. Anders Persson (who did the UCSD turtlegraphics library) modded his TI-99 to have 64k RAM. Really wish he'd have documented it...

--- On Tue, 2/16/10, Beery <[email-masked]> wrote:

> From: Beery <[email-masked]>
> Date: Tuesday, February 16, 2010, 2:05 PM
> If on a Geneve, the windows source
> code has the details on how to implement an XOP if you want
> a library of utilities.  It would/could use similar
> logic on the TI-99/4A if you had ram in the >0000 to
> >1FFF space, except one's code would have to typically
> reside in the 32K ram area.
> 
> It's something I think that could be implemented with a
> Gram Kracker or other low ram memory devices, but in a stock
> TI-99/4A, then you are prevented from building the Geneve
> typie XOP libraries.
> 
> Beery
> 
> benefits?  What are the negatives?
> > 
> > Bill S
> > 
> > Tursi wrote:
> > >  
> > > 
> > >  > With a machine code instruction there
> would be no need to set 
> > > breakpoints.
> > >  > What could be nicer than
> > >  > MOV @>8348,R0
> > >  > ANDI R0,>0001
> > >  > JEQ SOMEWHERE
> > >  > BREAK
> > > 
> > > You're using 4 bytes of memory and 16 cycles for
> code that is a 
> > > "do-nothing"
> > > in the final runtime, though. So I'd say "not
> using 4 bytes of memory 
> > > and 16
> > > CPU cycles for a NOP" ;)
> > > 
> > > I see your point, I just don't agree. If you want
> functionality like 
> > > that in

---

From: tursi <[email-masked]>
Date: Tue, 16 Feb 2010 11:37:22 -0800 (PST)

> You can replace the ROMs with RAMs. Anders Persson (who did the UCSD 
> turtlegraphics library) modded his TI-99 to have 64k RAM. Really wish 
> he'd have documented it...

Bootstrapping sounds like it'd be hard.. unless it was switchable? :)

Thierry's page documents how to replace the console ROMs with flash, which 
gives some moddablity.

This discussion, especially the Geneve useage, makes me realize that XOP 
is very much like the software interrupt on many other processors. 
Interesting.

---

From: "Matthew" <[email-masked]>
Date: Tue, 16 Feb 2010 20:17:41 -0000

I'm kicking around the idea of replacing my ROMs with RAM.  This is my thinking so far:

1. replace ROMs with sockets

2. put ROMs, RAM, and a small micro-controller on a circuit board that plugs into the sockets added in step 1

3. at power-up, keep the CPU in a reset state while the micro-controller copies the contents of the ROMs into the RAM

4. release the reset on the CPU

This lets you have the original ROM images in place to keep the machine 100% compatible, but since there is RAM from >0000 to >2000 now, you can do whatever you want as far as patching bugs, using interrupts, XOPs, etc..

I suppose it would even be simple to have a write-protect switch that makes the RAM function just like the ROM, since I suppose it is possible that at some point some code out there tries to write to the ROM addresses.  On Thierry's page that you mentioned he states that the ROMs are wired to respond to writes as well as reads.  I think that makes my idea even easier.  I only need a way to suspend the CPU at power up.

Matthew

---

From: "sconner3uk" <[email-masked]>
Date: Tue, 16 Feb 2010 20:23:56 -0000

The 9995-based Cortex computer had RAM shadowing the ROM. Part of the power-up routine read each memory location in ROM, wrote the same value back which wrote it to the RAM, then switched the ROM off. It is then up to you what you want to do - leave it as a 'stock' system, modify the operating system, or load your own system right over the top of it.

Stuart.

--- In [email-masked], ti99_forever <ti99_forever@...> wrote:
> --- On Tue, 2/16/10, Beery <bmiller@...> wrote:
> 
> > From: Beery <bmiller@...>
> > --- In [email-masked],
> > fdos <fdosbrs@> wrote:
> > >

---

From: "sconner3uk" <[email-masked]>
Date: Tue, 16 Feb 2010 20:31:33 -0000

If you had, say, a Horizons RAMDisk with a DSR in RAM, simply tack the 'copy' routine onto the end of the RAMDisk power-up routine?

Stuart.

--- In [email-masked], "Matthew" <matthew@...> wrote:
> --- In [email-masked], tursi <yahoogroup@> wrote:
> >

---

From: ti99_forever <[email-masked]>
Date: Tue, 16 Feb 2010 12:54:40 -0800 (PST)

Not sure how he did it, thinking it was off the CRU to switch between the ROM/RAM. Anders was pretty genius, miss him on the list...

Yes, XOP is the TI version of the x86 INT instruction.

--- On Tue, 2/16/10, tursi <[email-masked]> wrote:

> From: tursi <[email-masked]>
> Date: Tuesday, February 16, 2010, 2:37 PM

---

From: tursi <[email-masked]>
Date: Tue, 16 Feb 2010 13:26:06 -0800 (PST)

> 4. release the reset on the CPU

That's a pretty neat idea... I did a little testing with Classic99 and it 
looks like there are no console bugs in normal use that cause writes to 
the ROM (at least in BASIC)

I sort of envisioned doing a bank switch.. using a spare CRU line or 
similar to toggle a latch, and the latch controls whether the ROM or RAM 
responds. That way your software can switch when it gets control.

---

From: "Matthew" <[email-masked]>
Date: Wed, 17 Feb 2010 01:02:06 -0000

> responds. That way your software can switch when it gets control.

So to keep a compatible system you would copy the ROM code into memory expansion, hit the CRU, they copy back to the RAM that is now at the ROM addresses?  Kind of slick and avoids a micro-controller.

I think I'll have to give that a try.

Matthew

---

From: tursi <[email-masked]>
Date: Tue, 16 Feb 2010 18:53:40 -0800 (PST)

> So to keep a compatible system you would copy the ROM code into memory 
> expansion, hit the CRU, they copy back to the RAM that is now at the ROM 
> addresses?  Kind of slick and avoids a micro-controller.

Yeah, that, or, if you don't mind the copy being slower and/or don't want 
to dedicate 8k of RAM to the copy, you can copy in smaller blocks, 
switching back and forth (I figured 256 bytes was a fair tradeoff.)

> I think I'll have to give that a try.

Oooh... should be cool to see if it works. :)

---

From: mark wills <[email-masked]>
Date: Tue, 16 Feb 2010 19:55:08 -0800 (PST)

Sounds like a brilliant idea and very do-able. A little PIC jobby for a couple of $ would most likely do the job.

Put me down for one, please ;-)

And I think you're right - move the RAMs onto the little uController board, and have it plug into the board as a complete unit. That way you reduce the number of wires you have to solder onto the TI board (maybe you only have to connect HOLD or RESET or whatever it's called on the 9900). You can also un-do the mod simply and restore the console back to 'as god intended'.

Once you have 64K ram, you have some serious capabilities... Like... Oooh, I dunno... Writing you're own DOS... ;-)

M

>Sent: Tue, 16 February, 2010 21:17:41

---

From: mark wills <[email-masked]>
Date: Tue, 16 Feb 2010 20:02:21 -0800 (PST)

Another nice idea. This could be done as discrete logic, presumably...

Decode the address...
1) If address within ROM space AND bus cycle=READ THEN ... do nothing...
2) If address within ROM space AND bus cycle=WRITE THEN DISABLE_ROM, WRITE

Since 1) does nothing, it could be discarded.

The logic, which disables the ROM during a write cycle, would go via an inverter to the RAM chips ENABLE signal, such that when the ROM is disabled, the RAM is enabled.

This would take care of writing to the RAM that shadows the ROM. But how do you run code from RAM, since ROM would be enabled on a READ cycle?

I guess three solutions:

1) Have a toggle switch to force the enable of the ROM high via a pull-up
2) Have a latch that you can write to - nice, but where to address it? 
3) A flip flop... A write to a certain memory address (outside ROM space) enables ROM. Write again to disable.

3 means more chips - memory decoders etc...

Hmmm... It's a VERY interesting concept I would love a 64K ram console...!

>
>From: sconner3uk <[email-masked]>
>Sent: Tue, 16 February, 2010 21:23:56
>>--- In TI994A@yahoogroups. com, ti99_forever <ti99_forever@ ...> wrote:
>>>
>>> --- On Tue, 2/16/10, Beery <bmiller@... > wrote:
>>> 
>>> > From: Beery <bmiller@... >
>>> > --- In TI994A@yahoogroups. com,
>>> > fdos <fdosbrs@> wrote:
>>> > >

---

From: fdos <[email-masked]>
Date: Tue, 16 Feb 2010 21:32:47 -0700

Mark,

The WHT AT keyboard unit provided an option for 64K or EPROM or RAM 
replacement of the TI console ROM, bank switchable in 8K pages.  The CRU 
bank switching technique is in a hardware document on WHTECH.

Bill S

mark wills wrote:
>  
> 
> Sounds like a brilliant idea and very do-able. A little PIC jobby for a 
> couple of $ would most likely do the job.
> 
> And I think you're right - move the RAMs onto the little uController 
> board, and have it plug into the board as a complete unit. That way you 
> reduce the number of wires you have to solder onto the TI board (maybe 
> you only have to connect HOLD or RESET or whatever it's called on the 
> 9900). You can also un-do the mod simply and restore the console back to 
> 'as god intended'.
> 
> Once you have 64K ram, you have some serious capabilities... Like... 
> Oooh, I dunno... Writing you're own DOS... ;-)
> 
> M
> 
> 
> 
>     *From:* Matthew <[email-masked]>
>     *Sent:* Tue, 16 February, 2010 21:17:41
>     *Subject:* [TI994A] Re: XOP questions
> 
>      
> 
>     2. put ROMs, RAM, and a small micro-controller on a circuit board
>     that plugs into the sockets added in step 1
> 
>     3. at power-up, keep the CPU in a reset state while the
>     micro-controller copies the contents of the ROMs into the RAM
> 
>     This lets you have the original ROM images in place to keep the
>     machine 100% compatible, but since there is RAM from >0000 to >2000
>     now, you can do whatever you want as far as patching bugs, using
>     interrupts, XOPs, etc..
> 
>     I suppose it would even be simple to have a write-protect switch
>     that makes the RAM function just like the ROM, since I suppose it is
>     possible that at some point some code out there tries to write to
>     the ROM addresses. On Thierry's page that you mentioned he states
>     that the ROMs are wired to respond to writes as well as reads. I
>     think that makes my idea even easier. I only need a way to suspend
>     the CPU at power up.
> 
>     Matthew
> 
>     --- In TI994A@yahoogroups. com <mailto:TI994A%40yahoogroups.com>,
>     tursi <yahoogroup@ ...> wrote:
>      >

---

From: Owen Brand <[email-masked]>
Date: Tue, 16 Feb 2010 23:45:04 -0500

Just found a diskette and a manual for something called "Command  
DOS".... No idea what this is, but I thought I'd ask.  :)

Owen Brand
Opry99er.com

On Feb 16, 2010, at 10:55 PM, mark wills <[email-masked]>  
wrote:

> Sounds like a brilliant idea and very do-able. A little PIC jobby  
> for a couple of $ would most likely do the job.
>
> board, and have it plug into the board as a complete unit. That way  
> you reduce the number of wires you have to solder onto the TI board  
> (maybe you only have to connect HOLD or RESET or whatever it's  
> called on the 9900). You can also un-do the mod simply and restore  
> the console back to 'as god intended'.
>
> 3. at power-up, keep the CPU in a reset state while the micro- 
> controller copies the contents of the ROMs into the RAM
>

---

From: fdos <[email-masked]>
Date: Tue, 16 Feb 2010 22:42:03 -0700

Owen,

This is a PC DOS like environment that requires a Super Cart or similar 
device.  It's more than a command line disk manager, as it has an E/A 
like editor, can load DF80 object programs and some EA5 programs, also 
has batch processing capabilities, and many other useful features.

Bill S

Owen Brand wrote:
> On Feb 16, 2010, at 10:55 PM, mark wills <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>>  
>>
>> Sounds like a brilliant idea and very do-able. A little PIC jobby for 
>> a couple of $ would most likely do the job.
>>
>> (maybe you only have to connect HOLD or RESET or whatever it's called 
>> on the 9900). You can also un-do the mod simply and restore the 
>> console back to 'as god intended'.
>>
>>     machine 100% compatible, but since there is RAM from >0000 to
>>     >2000 now, you can do whatever you want as far as patching bugs,
>>     using interrupts, XOPs, etc..
>>
>>     that makes the RAM function just like the ROM, since I suppose it
>>     is possible that at some point some code out there tries to write
>>     to the ROM addresses. On Thierry's page that you mentioned he
>>     states that the ROMs are wired to respond to writes as well as
>>     reads. I think that makes my idea even easier. I only need a way
>>     to suspend the CPU at power up.
>>
>>     Matthew
>>

---

From: mark wills <[email-masked]>
Date: Tue, 16 Feb 2010 22:03:24 -0800 (PST)

It occurs to be Bill, that a Forth system, with the ability to:

1) Read disk directories
2) Format disks
3) Type text files
4) Copy/move files
5) Delete files
6) Load files

Would make an EXCELLENT DOS ;-)

Need batch facilities? Write your own Forth words to do what you want, and you're off...!

Mark

----- Original Message ----
> Sent: Wed, 17 February, 2010 6:42:03
> Subject: [TI994A] Command DOS
> 
> Owen,
> 
> > On Feb 16, 2010, at 10:55 PM, mark wills 
> > > wrote:
> > 
> >>  
> >>
> >>     *From:* Matthew 
> >>     --- In TI994A@yahoogroups. com ,
> >>     tursi wrote:
> >>     >

---

From: fdos <[email-masked]>
Date: Tue, 16 Feb 2010 23:49:43 -0700

Yes, if you have a full 32K to load and execute EA5 programs, and/or 
load in a bunch of DF80 programs, etc.  Oh, X4th99 with AMS/SAMS could 
do that.  Already in the plan. :-)

Bill S

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 17 Feb 2010 13:05:51 -0000

Hello, 

> record including the name and version of the emulator.

however, MESS does not know what a DSR is; DSR is a concept that is one layer above MESS. 

What I could imagine is an emulated expansion card that is plugged into the emulated P-Box. Or a cartridge. Still, if we try to open a device like "EMULATION", this would require that we have a DSR ROM written for the TI, including all that stuff that we found in real cards. Should not be a big problem, though.

That's not a policy thing ... an emulator does not "know" what it's doing. This is the reason why I cannot provide such features which would make life a lot easier, for instance, interfacing with the system clipboard. It's just unclear where the data should go or come from.

Michael

P.S.: I did not follow the last posts - is CLIP a device linked to the clipboard? I did not consider that yet ... could be a good way for MESS to make use of the clipboard (by some "magical cartridge" or expansion card).

---

From: ti99_forever <[email-masked]>
Date: Wed, 17 Feb 2010 05:17:10 -0800 (PST)

I just don't know why a text device such as CLIP cannot be linked to the RS232 device, which was the text device to link the TI to the outside world, ala RS232.CLIP or something. This would return an error on a real TI, but the DSR could be extended to support a CLIP device (either/or on a real TI/on an emulated device).

--- On Wed, 2/17/10, Michael Zapf <[email-masked]> wrote:

> From: Michael Zapf <[email-masked]>
> Date: Wednesday, February 17, 2010, 8:05 AM
> 
> 
> Hello, 
> 
> What I could imagine is an emulated expansion card that is
> plugged into the emulated P-Box. Or a cartridge. Still, if
> we try to open a device like "EMULATION", this would require
> that we have a DSR ROM written for the TI, including all
> that stuff that we found in real cards. Should not be a big
> problem, though.
> 
> That's not a policy thing ... an emulator does not "know"
> what it's doing. This is the reason why I cannot provide
> such features which would make life a lot easier, for
> instance, interfacing with the system clipboard. It's just
> unclear where the data should go or come from.
> 
> Michael
> 
> P.S.: I did not follow the last posts - is CLIP a device
> linked to the clipboard? I did not consider that yet ...
> could be a good way for MESS to make use of the clipboard
> (by some "magical cartridge" or expansion card).
> 
> 
> 
>

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 17 Feb 2010 13:54:57 -0000

> I just don't know why a text device such as CLIP cannot be linked to the RS232 device, which was the text device to link the TI to the outside world, ala RS232.CLIP or something. This would return…

Right, in that case you would have to patch the ROM of the emulated RS232 card. Assume that you open something like RS232.CLIP; this will activate the DSR search procedure (which is in the console ROM, not in MESS), which will do some accesses to the ROM of the RS232 device to find out that this is an invalid option (which is in the RS232 card ROM, also not in MESS).

Strictly speaking, in MESS I can only emulate electronic circuits; anything else comes from the ROMs. So this would require to design a circuit that detect this invalid option.

Patching a ROM dump just to make it different from the original is not a good idea in my opinion (no, actually a rather bad idea). I would really vote for a completely new device. 

Michael

---

From: ti99_forever <[email-masked]>
Date: Wed, 17 Feb 2010 09:36:16 -0800 (PST)

--- On Wed, 2/17/10, Michael Zapf <[email-masked]> wrote:

> Date: Wednesday, February 17, 2010, 8:54 AM
> 
> 
> 
> 
> ti99_forever <ti99_forever@...> wrote:
> >
> > I just don't know why a text device such as CLIP
> cannot be linked to the RS232 device, which was the text
> device to link the TI to the outside world, ala RS232.CLIP
> or something. This would return an error on a real TI, but
> the DSR could be extended to support a CLIP device
> (either/or on a real TI/on an emulated device).
> 
> Right, in that case you would have to patch the ROM of the
> emulated RS232 card. Assume that you open something like
> RS232.CLIP; this will activate the DSR search procedure
> (which is in the console ROM, not in MESS), which will do
> some accesses to the ROM of the RS232 device to find out
> that this is an invalid option (which is in the RS232 card
> ROM, also not in MESS).
> 
> Strictly speaking, in MESS I can only emulate electronic
> circuits; anything else comes from the ROMs. So this would
> require to design a circuit that detect this invalid
> option.
> 
> Patching a ROM dump just to make it different from the
> original is not a good idea in my opinion (no, actually a
> rather bad idea). I would really vote for a completely new
> device. 
> 
A circuit to detect *what* invalid option. The DSR detects it. And we already have different versions of the RS232 ROM out there. Just because MESS doesn't support it is not a valid argument. PC99 supports the multiple patched ROMS.
I should be able to just patch the MESS ROM, and the DSR detects it. MESS shouldn't care. Unless, as you say, MESS is just such a different system when it comes to emulation - seems a bit inflexible to me.

---

From: tursi <[email-masked]>
Date: Wed, 17 Feb 2010 11:15:17 -0800 (PST)

> however, MESS does not know what a DSR is; DSR is a concept that is one 
> layer above MESS. What I could imagine is an emulated expansion card 
> that is plugged into the emulated P-Box. Or a cartridge. Still, if we 
> try to open a device like "EMULATION", this would require that we have a 
> DSR ROM written for the TI, including all that stuff that we found in 
> real cards. Should not be a big problem, though.

That's what a DSR is, software running on the console to provide device 
services. MESS doesn't need to know what it is, but you need to implement 
emulated hardware to provide it. I'm not exactly sure how you think my 
emulator works to think that a DSR just magically appears to me. ;)

> That's not a policy thing ... an emulator does not "know" what it's 
> doing.

It's safe to assume that I probably have some clue what an emulator is and 
how they work. ;)

At some point the emulator DOES "know" what it's doing, otherwise it can't 
talk to the PC hardware. For example, at some point you know that you are 
talking to a disk image and not a physical FDC, and you have to transition 
to PC-based code to access the file.

The policy comment I made was whether it was acceptable to the MESS team to:

a) identify the machine to running software as BEING an emulator and NOT 
real hardware
b) add hardware to the emulator that does not exist in real life, even as 
a design

Particularly 'A' is likely to stir policy debate, since B is arguably 
already done anyway. ;)

> P.S.: I did not follow the last posts - is CLIP a device linked to the 
> clipboard? I did not consider that yet ... could be a good way for MESS 
> to make use of the clipboard (by some "magical cartridge" or expansion 
> card).

CLIP is a DSR that interfaces to the clipboard, yes. In Classic99, since I 
run a custom DSR already, it's part of the same DSR used for disk access, 
at CRU >1000... but this isn't important.

The CLIP device supports read and write of DISPLAY format records only, 
with any record size. It supports both sequential and random access, but 
this is made easy by Classic99's abstraction functions, which work in 
RAM and flush all data when closed (rather than specific design). On the 
Windows side, it only reads and writes CF_TEXT format data.

On Classic99 this is easy, since the DSR links from TI mode to PC mode 
already. This may be a little trickier in MESS, but you could define a 
custom card and fake the hardware to provide your linkage. Unfortunately I 
would not be able to give you a DSR to start with, since my DSR is simply 
a list of names and vectors, and Classic99 jumps to simulation of the file 
system when the card is active and the PC jumps to a particular address 
(ie: there is no actual DSR code in the Classic99 DSR card).

---

From: "sconner3uk" <[email-masked]>
Date: Wed, 17 Feb 2010 18:55:12 -0000

The Cortex uses a bit in a CRU-addressed latch + some discrete logic to enable/disable the ROMs. The code to actually switch is quite nice - it runs from workspace RAM to (presumably) avoid any glitches as the switch occurs (more of a problem with the 9995 with its instruction prefetch than with the 9900?)

LI R0,>0360     (RSET instruction to reset I/O devices)
LI R1,>1D00+Offset1   (SBO instruction to reset the keyboard)
LI R2,>1D00+Offset2   (SBO instruction to disable ROM)
LI R3,>045B     (B *R11 instruction)
BL R0           (jump to code in workspace, return to code in RAM)

S. 

--- In [email-masked], mark wills <markrobertwills@...> wrote:
> >From: sconner3uk <ti99@...>
> >>> --- On Tue, 2/16/10, Beery <bmiller@ > wrote:
> >>> 
> >>> > From: Beery <bmiller@ >

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 17 Feb 2010 21:35:36 -0000

Hello Tursi,

> It's safe to assume that I probably have some clue what an emulator is and 

I won't doubt that :-) sorry, I did not mean to address you but everyone reading this thread.

> Particularly 'A' is likely to stir policy debate, since B is arguably 

b) is OK for me; I guess no one will complain about that. What about a CRU line? Could be the easiest way but hard to query from Basic.

> [CLIP] This may be a little trickier in MESS, but you could define a 

If we can agree on the functionality and interface, it should not be too difficult to write a DSR. I could use special addresses (as in the disk controller) which link to the clipboard. Hmmm. But continuing to think on that, this could still be a challenge as this must be platform-independent, and I even don't know how this is done in Linux, let alone Windows or MacOS.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 17 Feb 2010 22:45:30 -0000

> I should be able to just patch the MESS ROM, and the DSR detects it. MESS shouldn't care. Unless, as you say, MESS is just such a different system when it comes to emulation - seems a bit inflexibl…

No problem. 

You can patch the ROM - but you'll get a warning on startup because ROMs are verified with a hash code. And that is reasonable - the mission of MESS is to preserve the systems in their original state. There was a hot discussion on the MESS forum about the fact that the skip_warnings flag has been removed, and frankly, I found the discussion heavily irritating (search for it in the forum if you are interested), but this is what I also have to accept in the end. 

I try to make MESS more comfortable, but I hope I can make you understand to some degree what is the mission and what is reasonable to do and what not. This is not always the same as what seems to be desirable from a user's view, but ... it's not *my* emulator.

Michael

---

From: mark wills <[email-masked]>
Date: Wed, 17 Feb 2010 20:42:46 -0800 (PST)

NICE!

----- Original Message ----
> Sent: Wed, 17 February, 2010 19:55:12
> The Cortex uses a bit in a CRU-addressed latch + some discrete logic to 
> enable/disable the ROMs. The code to actually switch is quite nice - it runs 
> from workspace RAM to (presumably) avoid any glitches as the switch occurs (more 
> of a problem with the 9995 with its instruction prefetch than with the 9900?)
> 
> --- In [email-masked], mark wills wrote:
> >
> > The logic, which disables the ROM during a write cycle, would go via an 
> inverter to the RAM chips ENABLE signal, such that when the ROM is disabled, the 
> RAM is enabled.
> > 
> > This would take care of writing to the RAM that shadows the ROM. But how do 
> you run code from RAM, since ROM would be enabled on a READ cycle?
> > 
> > I guess three solutions:
> > 
> > >From: sconner3uk 
> > >The 9995-based Cortex computer had RAM shadowing the ROM. Part of the 
> power-up routine read each memory location in ROM, wrote the same value back 
> which wrote it to the RAM, then switched the ROM off. It is then up to you what 
> you want to do - leave it as a 'stock' system, modify the operating system, or 
> load your own system right over the top of it.
> > >
> > >>Stuart.
> > >
> > >>--- In TI994A@yahoogroups. com, ti99_forever wrote:
> > >>>
> turtlegraphics library) modded his TI-99 to have 64k RAM. Really wish he'd have 
> documented it...
> > >>> 
> > >>> 
> > >>> --- On Tue, 2/16/10, Beery wrote:
> > >>> 
> > >>> > From: Beery 
> > >>> > fdos wrote:

---

From: mark wills <[email-masked]>
Date: Wed, 17 Feb 2010 20:50:07 -0800 (PST)

>This is not always the same as what seems to be desirable from a user's view, but ... it's not *my* emulator.

And this is a point of concern for me.

I worry that at some point, you personally will come up against a 'wall' whereby *you* as the maintainer of TI emulation in MESS want to implement certain functionality, and will be prevented from doing so, either because of architectural or ideological limitations.

At that point, what will *you* do? Branch off and create your own emulator, or just live with it? Either way, I worry it will be quite frustrating for you...

:-(

----- Original Message ----
> Sent: Wed, 17 February, 2010 23:45:30
> --- In [email-masked], ti99_forever wrote:
> 
> > A circuit to detect *what* invalid option. The DSR detects it. And we already 
> have different versions of the RS232 ROM out there. Just because MESS doesn't 
> support it is not a valid argument. PC99 supports the multiple patched ROMS.
> > I should be able to just patch the MESS ROM, and the DSR detects it. MESS 
> shouldn't care. Unless, as you say, MESS is just such a different system when it 
> comes to emulation - seems a bit inflexible to me.
> 
> 
> No problem. 
> 
> You can patch the ROM - but you'll get a warning on startup because ROMs are 
> verified with a hash code. And that is reasonable - the mission of MESS is to 
> preserve the systems in their original state. There was a hot discussion on the 
> MESS forum about the fact that the skip_warnings flag has been removed, and 
> frankly, I found the discussion heavily irritating (search for it in the forum 
> if you are interested), but this is what I also have to accept in the end. 
> 
> I try to make MESS more comfortable, but I hope I can make you understand to 
> some degree what is the mission and what is reasonable to do and what not. This 
> is not always the same as what seems to be desirable from a user's view, but ... 
> it's not *my* emulator.
> 
> Michael
> 
> 
> 
> 
>

---

From: "Tursi" <[email-masked]>
Date: Wed, 17 Feb 2010 22:02:50 -0800

> I try to make MESS more comfortable, but I hope I can make you understand 
> to some degree what is the mission and what is reasonable to do and what 
> not. This is not always the same as what seems to be desirable from a 
> user's view, but ... it's not *my* emulator.
> Michael

It seems you occasionally hit walls on that aspect.. have you ever 
considered forking it and MAKING it your emulator? Strip out the other stuff 
and just start with a nice stable TI Emulator?

That is one advantage of the open license. ;)

---

From: "Tursi" <[email-masked]>
Date: Wed, 17 Feb 2010 21:49:36 -0800

> If we can agree on the functionality and interface, it should not be too 
> difficult to write a DSR. I could use special addresses (as in the disk 
> controller) which link to the clipboard. Hmmm. But continuing to think on 
> that, this could still be a challenge as this must be 
> platform-independent, and I even don't know how this is done in Linux, let 
> alone Windows or MacOS.
>

If you want to implement a CLIP device that matches mine, go for it any way 
you feel fits your architecture. I implemented it in Classic99 because it's 
useful to me, and the new file architecture I built makes such things 
easy... there's no hardware backing it anyway so really, the only thing that 
should be standardized is the DSR interface, which is already standardized 
by TI. I specified the only things that matter to my DSR -- that it only 
accepts DISPLAY format data, anything else is okay including random access, 
and it reads and writes CF_TEXT format to the Windows clipboard. There was 
never any expectation that other emulators would choose to copy it.

My point is that if you do decide to write a DSR, then you will need to 
write code for all the various record-based opcodes (or at least the ones 
you want to support). The simplest case would probably be OPEN, CLOSE, READ 
and WRITE with Sequential records (since random access will require 
buffering to be reliable). You might be able to adapt another DSR. But for 
how the hardware behind it looks -- there's no need to have a standard for 
that because it really is nonsensical to do so, IMO. Alternately you can do 
like Classic99 does, and jump out early and fake the interface, but I got 
the impression you were against that approach. :)

---

From: ti99_forever <[email-masked]>
Date: Wed, 17 Feb 2010 22:31:24 -0800 (PST)

Random access? To a clipboard-like thingy? Strange... assumed it would be text (display) sequential, supporting OUTPUT (to wipe the contents of a clipboard for example) and APPEND (well, to append).

--- On Thu, 2/18/10, Tursi <[email-masked]> wrote:

> Date: Thursday, February 18, 2010, 12:49 AM
> >> custom card and fake the hardware to provide your
> linkage. Unfortunately 
> >> I
> >> a list of names and vectors, and Classic99 jumps
> to simulation of the 
> >> file

---

From: "Tursi" <[email-masked]>
Date: Thu, 18 Feb 2010 00:09:28 -0800

> Random access? To a clipboard-like thingy? Strange... assumed it would be 
> text (display) sequential, supporting OUTPUT (to wipe the contents of a 
> clipboard for example) and APPEND (well, to append).
>

My new DSR code buffers everything in RAM, and performs all file operations 
on RAM while the file is open, flushing only when it's closed. Thus, it's 
trivial to provide random access to even the clipboard - the contents are 
buffered when it's opened and after that it's just accessing the records in 
RAM. Helps reduce bugs, too, since all the main operations are common 
between the devices. This is fair as well, since the state of any file is 
technically undefined while it's open. For a transient device like the 
clipboard, though, it may be occasionally useful to know that it's only 
written on file close.

I did it this way to make it easier to add support for disk images and any 
other device that may catch my fancy (such as the Windows text file 
support). ;) For each device, I only need to implement a buffer and flush 
function, and everything else just works. ;) (At least for record-based 
access).

---

From: mark wills <[email-masked]>
Date: Thu, 18 Feb 2010 00:49:23 -0800 (PST)

Presumably extra DSRs can be created for other host-OS services/features?

For example, WINPRT - provides access to the default installed printer in Windows. (Win994A provides this by patching PIO to the Windows printer - makes getting PDF copies of TI docs very easy ;-)

Or maybe (better) PRINT - Windows/Linux agnostic...

If you had enough 'virtual' cards, you'd run out of CRU addresses... Still, you could have a virtual PEB that you 'plug' 'boards' into...

Mark

----- Original Message ----
> Sent: Thu, 18 February, 2010 9:09:28

---

From: "Tursi" <[email-masked]>
Date: Thu, 18 Feb 2010 02:33:15 -0800

> For example, WINPRT - provides access to the default installed printer in 
> Windows. (Win994A provides this by patching PIO to the Windows printer - 
> makes getting PDF copies of TI docs very easy ;-)
>

Classic99 only uses one CRU address for all devices right now. So far as the 
printer goes, yeah, I had planned to support printing to the Windows printer 
through PIO as well, I have the notes handy for emulating a color Epson 
printer, just that it's a big task (I suppose I could start with text-only).

I suppose I could let PIO be PIO and define a separate device for the 
Windows printer, but I was just going to use a configuration option. Many 
PCs these days don't even have parallel ports anymore anyway. ;) Same deal 
with the RS232/Modem emulation.

The tricky part comes when I start adding the real cards, and deciding how 
to arbitrate between them. ;)

> If you had enough 'virtual' cards, you'd run out of CRU addresses... 
> Still, you could have a virtual PEB that you 'plug' 'boards' into...

Yes.. but not necessary to do a separate card per device if they're virtual 
devices anyway. ;)