Subject: Re: [TI994A] Test Program.

From: Marc Hull <[email-masked]>
Date: Sun, 16 Jun 2013 14:08:48 -0700 (PDT)

Hopefully.  That is what sparked this quest anyway.  As I see it, anything designated as read only or write only in the console might be accesable from the peb in the opposite fashion.  All kinds of extra memory and devices could be mapped in.

Maybe Mike could test the behavior of the other MM objects?

------------------------------
On Sun, Jun 16, 2013 1:56 PM CDT James Abbatiello wrote:

>On Sun, Jun 16, 2013 at 1:31 AM, Tursi <[email-masked]> wrote:
>
>> **
>>
>>
>> Read Cycles did not trigger the sound chip at all (CS never went low). The
>> rumors of this issue being "fixed in later hardware" might actually
>> predate
>> the QI. I don't have a 99/4 to try with anymore, but that's interesting!
>>
>Neat.  The circuit that masks out the reads looks like it covers not only
>>8400->87FF (sound chip write) but also >8C00->8FFF (VDP write),
>>9400->97FF (speech synth write), and >9C00->9FFF (GROM write).  Could
>somebody theoretically map something read-only in any of those address
>ranges?
>
>-- 
>James Abbatiello

---

From: James Abbatiello <[email-masked]>
Date: Wed, 19 Jun 2013 01:08:13 -0400

On Sun, Jun 16, 2013 at 5:08 PM, Marc Hull <[email-masked]> wrote:

> **
>
>
>
>
> Hopefully. That is what sparked this quest anyway. As I see it, anything
> designated as read only or write only in the console might be accesable
> from the peb in the opposite fashion. All kinds of extra memory and devices
> could be mapped in.
>

Mapping a read-only device in a formerly write-only area may work.  But I
don't think the other way around is going to be easy.  Any attempt to write
to >8800 and the processor is going to do a read-before-write so you'll end
up incrementing the VDP's read pointer.  I've heard something about certain
instructions that don't perform the read-before-write which might be
helpful.  Does anyone have details on that?

Writing to >9000 or >9800 looks worse.  First the processor would do the
phantom read from the speech synth or the GROM.  Then you'd do a write and
I think that (due to the way the address decoding is done) the speech
synth/GROM would see that write just as if you'd written to >9400 or >9C00.

I wonder about writing to the console ROM area at >0000->1FFF.  It wouldn't
activate the multiplexer so I'm not sure what shows up on the PEB bus.
Would you see only a write of the even byte?  If so that still might be
usable for something.

-- 
James Abbatiello

---

From: Jeff White <[email-masked]>
Date: Wed, 19 Jun 2013 08:55:18 -0400

Yes, the read-before-write is a stickler.  8800 and 8C00 are mapped to the same VDP port 0, just the first is for reads, and second writes.

What I would suggest is using 8C01 and 8801 for read and write ports of some imaginary device. Block even byte access, and the VDP will not respond to read-before-write.  The VDP is on the internal 16-bit bus, unlike sound, GROM, and speech on the mux-demux.

This does have some penalty, such as not using MOVB and similar with register (Rx) addressing.  However, using MOV @>8C01,R3 would read the port into the odd (low or least significant) of R3.  MOVB @>8C01,R3 would place it in the even (high or most significant) byte of R3.

Recall, reads of 8C00 at the VDP are blocked on this imaginary device.

The opposite way:  MOVB R3,@>8801.  Crikey, not going to work.  It reads 8801 (blocked) and 8800 (VDP) before the write to 8801 (imaginary device) and 8800 (blocked).

However:

LWPI >8800
LI R0,>xxnn

should put nn into 8801 without reading 8800.

Not sure any of the above will work, since I am probably missing something the console does.  However, Mechatronics 80-column, Dijit AVPC, and SNUG EVPC operate on the same ports as console VDP through the side port connector.

Jeff White

On 19 Jun 2013, at 01:08, James Abbatiello <[email-masked]> wrote:
> Mapping a read-only device in a formerly write-only area may work.  But I don't think the other way around is going to be easy.  Any attempt to write to >8800 and the processor is going to do a read-before-write so you'll end up incrementing the VDP's read pointer.  I've heard something about certain instructions that don't perform the read-before-write which might be helpful.  Does anyone have details on that?
> 
> Writing to >9000 or >9800 looks worse.  First the processor would do the phantom read from the speech synth or the GROM.  Then you'd do a write and I think that (due to the way the address decoding is done) the speech synth/GROM would see that write just as if you'd written to >9400 or >9C00.
> 
> I wonder about writing to the console ROM area at >0000->1FFF.  It wouldn't activate the multiplexer so I'm not sure what shows up on the PEB bus.  Would you see only a write of the even byte?  If so that still might be usable for something.
> 
> -- 
> James Abbatiello
>

---

From: James Abbatiello <[email-masked]>
Date: Thu, 20 Jun 2013 00:24:39 -0400

On Wed, Jun 19, 2013 at 8:55 AM, Jeff White <[email-masked]> wrote:

> **
>
>
> Yes, the read-before-write is a stickler.  8800 and 8C00 are mapped to the
> same VDP port 0, just the first is for reads, and second writes.
>
>
The VDP has two chip select pins, CSR and CSW for reading from the VDP and
writing to the VDP respectively.  CSW is enabled for writes to >8Cxx.  I
think CSR is enabled for any access to >88xx.  If that's the case then
performing a write to >88xx would be a bad idea since you'd end up with
both the CPU and the VDP trying to drive the data bus (or at least D0-D7
anyway since the VDP is only hooked to that half).

> However, using MOV @>8C01,R3 would read the port into the odd (low or
> least significant) of R3.
>

You can't do that, can you?  Word accesses ignore the least significant bit
so this the same as accessing >8C00, right?

-- 
James Abbatiello

---

From: Jeff White <[email-masked]>
Date: Thu, 20 Jun 2013 09:33:23 -0400

On 20 Jun 2013, at 00:24, James Abbatiello <[email-masked]> wrote:
> The VDP has two chip select pins, CSR and CSW for reading from the VDP and writing to the VDP respectively.  CSW is enabled for writes to >8Cxx.  I think CSR is enabled for any access to >88xx.  If that's the case then performing a write to >88xx would be a bad idea since you'd end up with both the CPU and the VDP trying to drive the data bus (or at least D0-D7 anyway since the VDP is only hooked to that half).

A15 when 1 disables the hardware select decoder.  With regards to when A15 is 0, that would require study of the schematics.  If it is as you describe, the problem has been there all along.  Not sure if it is harmful to write to >88xx.

> However, using MOV @>8C01,R3 would read the port into the odd (low or least significant) of R3.
> 
> You can't do that, can you?  Word accesses ignore the least significant bit so this the same as accessing >8C00, right?

Correct.  I just did it that way to indicate that the low byte is what I want, and in the low byte of R3.  What is read into the even byte, I do not know

Jeff White

---

From: James Abbatiello <[email-masked]>
Date: Thu, 20 Jun 2013 12:39:29 -0400

On Thu, Jun 20, 2013 at 9:33 AM, Jeff White <[email-masked]> wrote:

>> Yes, the read-before-write is a stickler.  8800 and 8C00 are mapped to
>> the same VDP port 0, just the first is for reads, and second writes.
>>
>>
> A15 when 1 disables the hardware select decoder.  With regards to when A15
> is 0, that would require study of the schematics.  If it is as you
> describe, the problem has been there all along.  Not sure if it is harmful
> to write to >88xx.
>
>
I'm not following you.  A15 only exists after the mux.  The VDP doesn't see
that at all.

-- 
James Abbatiello

---

From: Jeff White <[email-masked]>
Date: Thu, 20 Jun 2013 13:55:03 -0400

On 20 Jun 2013, at 12:39, James Abbatiello <[email-masked]> wrote:
> I'm not following you.  A15 only exists after the mux.  The VDP doesn't see that at all.

Yes, it is after the mux.  But A15 is sent to 1 of the 3 enable lines !G2 of the 74LS138 that decodes to the Sound, VDP, GROM, and Speech selects.  If A15 is 0 and the other enable lines are active, the LS138 can work.  If A15 is 1, the LS138 outputs are hi-Z. 

Jeff White

---

From: "Tursi" <[email-masked]>
Date: Thu, 20 Jun 2013 23:35:25 -0700

Some years ago, I acquired a collection of TI stuff from a fellow in San 
Francisco. One of the things he wanted me to be aware of was a set of Civil 
War Simulation games by Salmo Software.

These originally shipped on Cassette tape, but I also have DSK versions. 
Last night, while working out what was wrong with Classic99, I fixed my disk 
transfer utility, and transferred the disks over.

I do not know a lot about how to play them. They are mentioned in Cyc, but I 
wasn't able to find much out about them. I can get you started, but someone 
may have to spend a little more time to work out the games.

They seem to be two player simulations of various battles. The North and the 
South each enter a secret code of their choice -- this is a password so that 
one player can't enter moves for the other. A menu appears after codes are 
entered, and I get a bit uncertain there. You can enter a mode where you 
move crosshairs around with the arrow keys (and diagonals around them) and 
'lock' onto pieces with 'L', but I'm a little unclear what else you have to 
do.

The three disks are SHILO, GETTYSBURG and BULLRUN. They are Extended BASIC 
auto-run disks (so install into DSK1 and autostart, or run DSK1.LOAD). They 
expect their data files to be in DSK1. The XB code looks like it was adapted 
from cassette fairly trivially - there's still mention of loading your data 
tape in CS1 in some of them. But that is all taken care of.

I was asked to release these, and I do apologize for how long it took, but 
enjoy!

Screenshots and download at Atari Age: 
http://atariage.com/forums/topic/213662-some-new-old-software/page__gopid__2778551#entry2778551

if you can't download from AtariAge, I've also temporarily put the zip here: 
http://harmlesslion.com/temp/Salmo_CivilWar.zip

----

A second thing I wanted to post.. one of my original TI disks that I still 
have is Barry Traver's XXB, which I was using to do raw sector writes from 
Extended BASIC. I went looking for docs on the PC and could not find the 
disk on WHTech, so I thought it might be lost too, and so have uploaded it, 
just in case it's useful to someone.

It's basically a set of CALL LINKs to extend Extended BASIC with things like 
raw disk access and 40 column text. Docs are included.

Same link as above, or download from here: 
http://harmlesslion.com/temp/xxb.dsk

---

From: Tony Knerr <[email-masked]>
Date: Fri, 21 Jun 2013 04:29:10 -0400

Note that Barry Traver's XXB is also a part of XB v2.5 & 2.6.

Tony