XB256

[senior_falcon]

Hi Jacques:

 

Can you run XB256 and 256DEMO in Classic 99?

 

To be sure everything worked properly, I downloaded the zipped folder at the top of this page. The zipped folder contains XB256 and 256DEMO which are TI Extended BASIC programs, a PDF of the docs, and a Win994a disk image. I started TELCO on the TI side and Hyperterminal on the PC side, both set to 1200 baud 8-N-1. I had no trouble sending XB256 and 256DEMO (once I went to 1200 baud - 2400 seemed to not work, though it used to in the past) I loaded and ran XB256 with no problems. (When you run XB256 nothing happens that you can see - maybe I should have changed the cursor shape or something like that.) Then I loaded and ran 256DEMO and it worked like it should.

 

I don't know anything about PC99 or the TI994W emulator and can't offer any suggestions about them. XB256 does a CALL FILES(2) from assembly language. Possibly there is some incompatibility with your disk controller. The code used is from TML and was tested back in the day with a Myarc controller and it worked fine. You shouldn't need to convert anything to text and back to transfer these files.

 

Let me know if this works. If it doesn't I have some ideas, but let's try plan A first.

 

Harry

[jacquesg]

Hi Jacques:

 

Can you run XB256 and 256DEMO in Classic 99?

 

To be sure everything worked properly, I downloaded the zipped folder at the top of this page. The zipped folder contains XB256 and 256DEMO which are TI Extended BASIC programs, a PDF of the docs, and a Win994a disk image. I started TELCO on the TI side and Hyperterminal on the PC side, both set to 1200 baud 8-N-1. I had no trouble sending XB256 and 256DEMO (once I went to 1200 baud - 2400 seemed to not work, though it used to in the past) I loaded and ran XB256 with no problems. (When you run XB256 nothing happens that you can see - maybe I should have changed the cursor shape or something like that.) Then I loaded and ran 256DEMO and it worked like it should.

 

I don't know anything about PC99 or the TI994W emulator and can't offer any suggestions about them. XB256 does a CALL FILES(2) from assembly language. Possibly there is some incompatibility with your disk controller. The code used is from TML and was tested back in the day with a Myarc controller and it worked fine. You shouldn't need to convert anything to text and back to transfer these files.

 

Let me know if this works. If it doesn't I have some ideas, but let's try plan A first.

 

Harry

 

I have never used Classic 99.

 

PC99 has two utility files, RSECTOR and WSECTOR, that are used to transfer disks to and from a TI-99/4A by copying sectors over a serial connection. I found it strange that after I got XB256 and 256DEMO over to my TI-99/4A and they would not run but they ran after I copied the disk over to PC99. When I reversed the process and transferred the disk back to the TI the programs again would not run. It is obvious that XB256 ran but the problem was when I tried to run 256DEMO either by using line 10 or using RUN in command mode. The disk controller light comes on but it does not seem to find the file. It just hangs and I have to turn off the TI. I have no problem in running TML on the TI.

 

Later today I will make a fresh start and transfer the two programs direct to my TI usung MagicFM. The only reason that I used a transfer of a text file was that I initally thought that 256DEMO program perhaps got corrupted and this was another way of moving the program. This will be my plan A.

 

Jacques

[lucien2]

It is obvious that XB256 ran ...

It just hangs and I have to turn off the TI.

 

I reproduced this problem with MESS 0.136 and the floppy controllers "Texas Instruments SD" or "SNUG's BwG".

 

With MESS 0.136 and the floppy controller "MyArc's HDFC", it runs fine.

[senior_falcon]

OK, here's something to try out. The attached zipped folder has the same files as the one at the beginning of this thread with one additional file:

XB256NCF which skips the CALL FILES(2) from assembly.

From the command line type:

CALL FILES(2)

OLD DSKn.XB256NCF

RUN

Then you should be able to RUN "DSKn.256DEMO"

 

Let me know if this works.

 

Harry

XB256.zip

[lucien2]

Let me know if this works.

 

Sorry, no improvement.

 

I also tried it with PC99 and V9T9 with the TI disk controller: Same problem (freeze when loading 256DEMO).

The CPU is lost in a loop at addresses >4690 .. >4B76.

[senior_falcon]

I am confused about when this fails.

First, LOAD and RUN XB256. Does the cursor come back? I had assumed it was failing at that point.

If the cursor comes back then enter this simple program:

10 CALL LINK("SCRN2")::CALL LINK("DISPLY",1,1,"TEST")

20 GOTO 20

You should see TEST printed in the upper left of the screen. Fctn 4 should break the program. (Haven't tested this program - I'm on the wrong computer)

If that works then try saving the program. Did it save and did the cursor come back?

If it saved OK then type NEW and try loading the program you just saved. Does the cursor come back? Is the program there and does it run?

If all that works then try the following: OLD DSKn.256DEMO

Does the cursor come back? Is the program loaded?

Try running the program. Does it run?

With this information I can at least figure out where it is failing.

[lucien2]

Load of XB256: OK.

 

Test program: OK.

 

Save of the test program: Same crash as the loading of 256DEMO. (No cursor coming back)

[senior_falcon]

So there is something happening to prevent disk access. Let's try to isolate the problem a little more:

From XB:

CALL FILES(2)

OLD DSKn.XB256NCF

Remove the CALL LINK("XB256") from line 10

RUN

Does the cursor come back?

OLD DSK7.256DEMO

Does the cursor come back?

CALL LINK("XB256")

Does the cursor come back?

RUN

Does the demo run?

Edited March 9, 2013 by senior_falcon

[lucien2]

Yes, all steps are working. The demo runs!

[senior_falcon]

Now follow the steps in my previous post. Then break the program with Fctn 4. Now try to save or load something to disk. Does it crash?

[lucien2]

Yes, same crash, even after a NEW.

[senior_falcon]

From XB:

CALL INIT

CALL FILES(2)

CALL LOAD(-31888,43,255)

Then try to save or load a program. Do you get the same crash?

[lucien2]

You found it!

 

Same crash, with or without CALL FILES(2).

 

CALL FILES(9) writes >2BB3 at >8370 and works. Writing >2BFF makes it crash, I don't understand that.

 

 

I tried to reverse the order: First CALL LOAD(-31888,43,255), then CALL FILES(2). It crashes directly after CALL FILES.

[senior_falcon]

OK, I might have an answer for this. Try this:

CALL INIT

CALL FILES(2)

CALL LOAD(-31888,43,255)

CALL LOAD(-31976,43,255,43,255)

Then try to save or load a program. Does it crash?

[lucien2]

Yes, it still crashes.

 

I stepped a bit in the DSR with the PC99 debugger. It reads the VDP pointed by the value at >8370.

When CALL FILES(2) is executed, it writes >39DD at >8370 and it writes >00AA,>3FFF,>1102 at >39DD in VDP.

 

So, after CALL LOAD(-31888,43,255) (@>8370 = >2BFF), I wrote >00AA,>3FFF,>1102 at >2BFF.

 

It does not crash anymore. SAVE and OLD works.

 

But if I do that after running XB256, I always have an I/O ERROR 04 or 64 (Out of table or buffer space on the device)...

 

Those bytes are documented here: ftp://whtech.com/magazines/smartprogrammer/sp8405.pdf

[senior_falcon]

When a program starts to run in XB256 it will write >80 768 times to VDP memory starting at >2C00 which will clear screen2 and overwrite the header you just wrote

You could try this which might work:

Change the value at >8370 to >2BF7

Write those bytes (>00AA,>3FFF,>1102) to the VDP starting at >2BF7

Now the header is below >2C00 and won't be changed when the screen clears.

One problem is that I have no idea where the disk buffers are kept in VDP with this controller. Right after XB256 starts up (assuming it does) but while still in screen1, try opening 2 files and then read and write to them. Then have the program CALL LINK("SCRN2") If the buffers are in the same place as the TI the screen should be blank. If not there will be garbage on the screen

[senior_falcon]

Will have a revised version soon (maybe tonight) that should work with all controllers.

[lucien2]

Change the value at >8370 to >2BF7

Write those bytes (>00AA,>3FFF,>1102) to the VDP starting at >2BF7

 

Here are the results of some tests. I'm not sure which disk controller is used by PC99 by default (TI?)

 

Oops, I think I did all these tests with >2B7F instead of >2BF7...

 

PC99

1. CALL FILES(2)

2. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F

3. OLD XB256NCF -> OK

4. RUN -> SYNTAX ERROR with CALL LINK("X")

 

PC99

1. CALL FILES(2)

2. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F

3. OLD XB256 -> OK

4. RUN -> OK

5. Replace >2BFF from >8370 by >2B7F

6. OLD 256DEMO -> I/O ERROR 04

 

PC99

1. CALL FILES(2)

2. OLD XB256NCF -> OK

3. RUN -> SYNTAX ERROR with CALL LINK("X")

 

MESS

1. CALL FILES(2)

2. OLD XB256NCF -> OK

3. RUN -> OK

4. OLD 256DEMO -> crash

 

PC99

1. OLD XB256 -> OK

2. RUN -> OK

3. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F

4. RUN -> NO PROGRAM PRESENT

 

PC99

1. OLD XB256 -> OK

2. RUN -> OK

3. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F

4. OLD 256DEMO -> I/O ERROR 04

 

PC99

1. CALL FILES(2)

2. OLD XB256 -> OK

3. RUN -> OK

4. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F

5. OLD 256DEMO -> OK

6. RUN -> OK !!!

 

PC99

1. CALL FILES(2)

2. OLD XB256 -> OK

3. RUN -> OK

4. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F

5. OLD TEST1 -> OK

6. OLD TEST2 -> OK

7. 10 CALL LINK("SCRN2")

8. 20 GOTO 20

9. RUN -> screen blank

 

PC99

1. CALL FILES(2)

2. OLD XB256 -> OK

3. RUN -> OK

4. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F

5. 10 OPEN #1:"DSK1.TEST1"

6. 20 PRINT #1:"TEST"

7. 30 OPEN #2:"DSK1.TEST2"

8. 40 PRINT #2:"TEST2"

9. 50 CALL LINK("SCRN2")

10. 60 GOTO 60

11. RUN -> I/O ERROR 04 IN 30

 

PC99

1. CALL FILES(2)

2. OLD XB256 -> OK

3. RUN -> OK

4. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F

5. 10 OPEN #1:"DSK1.TEST1"

6. 20 PRINT #1:"TEST"

7. 30 CALL LINK("SCRN2")

8. 40 GOTO 40

9. RUN -> garbage on screen

[lucien2]

Now the same test that worked with >2B7F, but with >2BF7 instead:

 

PC99

1. CALL FILES(2)

2. OLD XB256 -> OK

3. RUN -> OK

4. Write >2BF7 at >8370 and (>00AA,>3FFF,>1102) at VDP >2BF7

5. OLD 256DEMO -> I/O ERROR 04

[jacquesg]

Here are the results of some tests. I'm not sure which disk controller is used by PC99 by default (TI?)

 

 

 

I can run XB256 and 256DEMO from my PC99 setup as DSK4. My setup has a MYARC DC. this DC is useful because it allows a DSK5 as a RAM disk. I use it to contain the FW and other files files. I am not sure that PC99 has a default DC.

 

Jacques

[+Retrospect]

On 2/27/2013 at 11:46 PM, RXB said:

My XB to GPL compiler is about half done before I gave up.

The reason is the TI community is all about Assembly or C or Forth, so what is the point of a GPL compiler.

 

Anyway what I did was use the SAMS as a buffer for Variables names and storage.

This allowed me to tackle any size program and compile into GPL.

 

I made videos on the process. Hope it gives you ideas:

 

http://www.youtube.com/watch?v=TQzp25sSa1A&list=UUULwPKqrRFCtNv5_xMuOqQw&index=3

 

 

 

Good luck

 

Rich

Well, I know this is an old post I'm dragging back up here ... but I do have something to say about it.  

 

A GPL compiler could output a Cartridge image that works on a stock console, am I right?  Well I think it would be fantastic.

XB256 with it's compiler IS fast yes, and yes, GPL is slower, however, there is still a point.  We can't just throw something away in the TI community just because there's something else, something faster, etc etc...... I'm gonna use this example:  Rasmus is much better than me at programming great arcade games.  But does it stop me doing it too?  Hell no.  I just keep going, and going, and going ... I will NEVER stop.  So the point i'm making is this : you make an XB- GPL compiler and I will reward it with at least TEN games if not more, this will not be difficult for me to do.  

 

I'll be coding for XB256 and the GPL compiler at the same time.  And that's just ONE programmer.  Do it Rich.     This is the last time I'll push for it I promise, specially as this is entirely the wrong thread for it (Harry you have my apologies for that!).  

@RXB