Classic99 Questions

[RXB]

Ok number one.

Why can I not do:

DELETE "DSK2.FILENAME" in XB?

 

Number two.

Why does my RXB AMSINIT, AMSBANK, AMSON, AMSOFF, AMSPASS, and AMSMAP routines not work?

 

I have all the setting configured for AMS but nothing happens, what am I missing?

 

On my RXB2001.dsk is AMSTEST and this is exactly the same program that Paul Schippnick wrote

and sent me. I duplicated the program he wrote in Assembly into GPL and it works in PC99,

and my own TI fine. But it crashes and says no AMS is there.

 

Number three.

My BATCH file for USER crashes so much it almost sets it self on fire.

Will have to re-write it for Classic99. (BATCH tries to DELETE files)

 

I am surprized that Sector will read disks but can not write to them.

I suppose same problem as DELETE.

Edited March 16, 2011 by RXB

[Tursi]

Why can I not do: DELETE "DSK2.FILENAME" in XB?

 

Classic99's DSR does not support the DELETE opcode. It was my decision to leave actual file management to the operating system - so if you want to delete a file, use Explorer. Same for renaming a file, and the PROTECT opcode is also not supported.

 

Why does my RXB AMSINIT, AMSBANK, AMSON, AMSOFF, AMSPASS, and AMSMAP routines not work?

 

This I can't say. If you give me the code you are using and a step-by-step to reproduce the problem I can look into it. I did not write AMS so the only test program I have is the included Monopoly.

 

I am surprized that Sector will read disks but can not write to them. I suppose same problem as DELETE.

 

Think about it for a moment -- where would the written sectors go? There is no actual TI disk there. You are reading a FAT32 or NTFS file system, not a TI one.

 

Sector read is emulated for the first 129 sectors because many programs use this to get a directory instead of opening "DSK1.". But all the information is generated on the fly from the directory, and most of it's fake data just to make directories work. Sector 0 and 1 are completely made up on the fly. Writing back to them would not make much sense. The next 127 sectors are created from the files in the folder (if there are enough files). If you try to read any sector past that point, it will fail.

 

Actual low-level sector editting is usually only necessary for working on actual disks. The file-by-sector I/O is fully supported for read and write.

 

If you have software that absolutely requires TI format floppy disk layout, then you will need to use disk images. Note that disk image support in Classic99 right now is experimental. In the next release it is official, but will remain read-only by default until I'm certain it isn't going to be corrupting people's disks.

 

Personally I don't like the limitations of the TI disk system. They were okay 30 years ago, but today I have more than 127 files. This is why it is so late coming to my emulator.

[RXB]

Why can I not do: DELETE "DSK2.FILENAME" in XB?

 

Classic99's DSR does not support the DELETE opcode. It was my decision to leave actual file management to the operating system - so if you want to delete a file, use Explorer. Same for renaming a file, and the PROTECT opcode is also not supported.

 

Why does my RXB AMSINIT, AMSBANK, AMSON, AMSOFF, AMSPASS, and AMSMAP routines not work?

 

This I can't say. If you give me the code you are using and a step-by-step to reproduce the problem I can look into it. I did not write AMS so the only test program I have is the included Monopoly.

 

I am surprized that Sector will read disks but can not write to them. I suppose same problem as DELETE.

 

Think about it for a moment -- where would the written sectors go? There is no actual TI disk there. You are reading a FAT32 or NTFS file system, not a TI one.

 

Sector read is emulated for the first 129 sectors because many programs use this to get a directory instead of opening "DSK1.". But all the information is generated on the fly from the directory, and most of it's fake data just to make directories work. Sector 0 and 1 are completely made up on the fly. Writing back to them would not make much sense. The next 127 sectors are created from the files in the folder (if there are enough files). If you try to read any sector past that point, it will fail.

 

Actual low-level sector editting is usually only necessary for working on actual disks. The file-by-sector I/O is fully supported for read and write.

 

If you have software that absolutely requires TI format floppy disk layout, then you will need to use disk images. Note that disk image support in Classic99 right now is experimental. In the next release it is official, but will remain read-only by default until I'm certain it isn't going to be corrupting people's disks.

 

Personally I don't like the limitations of the TI disk system. They were okay 30 years ago, but today I have more than 127 files. This is why it is so late coming to my emulator.

 

 

Ok I understand about the Disk support, guess I can make a Classic99 version that does not need most DSK or HD support.

That would go for SECTOR and other Disk support also so I get it.

 

Ok here is the code for RXB AMS support in a Attached file of the Source code for all AMS routines I use in RXB.

 

CALL AMSSUB simply moves 24 bytes from GROM that is a Assembly program in byte format into scratch pad RAM at >8300

I use STORE as a pointer to change the place SBO is at to >1D00 or >1D01 or >1E00 or >1E01

this changes the Assemlby OPCode to the only change I need in the Assembly program for it to work.

The XML >F0 is the Execute command in GPL so just runs what ever is at >8300 as a Assembly program.

It returns and I go back into GPL.

The ISRON and ISROFF does the same thing with a smaller program, but stores the Address at >8318 or fetches it.

This either turns on or off the ISR Hook.

 

Hope you can figure out what is going. Thanks.

RXBAMSSRC.txt

[Tursi]

hmm.. being written in GPL, it will take me all day to step through this code. I can only step through assembly instructions, which means I'd have to walk the interpreter.

 

I've re-run the AMS examples programs that come with Classic99, and both Monopoly and AMSTest work (although AMSTest does not work without a full reset first....).

 

Can you narrow down the error you are seeing to a single example, preferably in assembly (but I'll accept GPL if you can keep it under a dozen instructions)?

 

Also, please download the new version which I just posted, just in case you're seeing an old bug I forgot about.

[RXB]

hmm.. being written in GPL, it will take me all day to step through this code. I can only step through assembly instructions, which means I'd have to walk the interpreter.

 

I've re-run the AMS examples programs that come with Classic99, and both Monopoly and AMSTest work (although AMSTest does not work without a full reset first....).

 

Can you narrow down the error you are seeing to a single example, preferably in assembly (but I'll accept GPL if you can keep it under a dozen instructions)?

 

Also, please download the new version which I just posted, just in case you're seeing an old bug I forgot about.

 

Well I posted the GPL Code in RXB with the Assembly that it uses and works fine on a TI and in PC99

This attachment is the RXB version of the Paul Schippnick AMS TEST program he wrote in Assembly but I just converted all the commands to GPL.

It crashes right off the bat and says no AMS installed. So something in the GPL interface of Classic99 is off.

AMSTEST.txt

[Tursi]

I am not saying you did not find a bug. I am saying that I can not troubleshoot the example code you are giving me. I can't walk through a GPL program instruction by instruction, and walking the assembly interpreter for GPL takes too long.

 

So please write me a small assembly program that demonstrates the AMS problem you are seeing. Without that I can't help you.

 

There may be an error in the GPL interpreter - but it is very well exercised and so the odds are less than the other options. There may be a bug in AMS, or the AMS implementation may not work the same way RXB expects. But you will have to help if you want this functionality corrected sooner. I didn't write AMS in Classic99, so I can't discuss very well the way it's supposed to operate.

 

Otherwise.. I'll just have to play with it when I get time. This XB program should help a little, but it will be very slow going.

[Tursi]

There's been a bit of a thread on the side about the AMS function in Classic99, and having gone through the code and looked at some more of the documentation, it really seems like everything's on the up and up with the emulation there. I went through the AMS test code again, now that I have some understanding of the mapper function.

 

The reason it was failing turned out to be fairly simple. Joe coded the register map to only work from >4000 to >401F, instead of repeating through the entire DSR space. For some reason, this application poked the registers at the END of DSR space, from >5FE0 to >5FFF. Thierry's schematics say it should repeat, so I fixed that, and the test runs.

 

 

It only detects 128k, and it looks like that is in fact the maximum that this program recognizes, but it jumps around so much I was not inclined to try and make it test more. Classic99 emulates a full 1MB, which means each register can have a full 8 bit offset. (In fact, it emulates 1MB no matter what you configure for size in the ini...)

 

A second problem is that Classic99's AMS defaulted to pass-through for compatibility, and RXB never actually turns on the mapping! (LI R12,>1E00, SBO 2). This left the chip in passthrough mode, which may not have been the default. I've changed this behaviour, but if it breaks anything else I'll have to change it back.

 

I did my own quick little memory test to verify this is in fact true (that 1MB works).. this test just runs all the pages through >2000 to do it's verification:

 

100 REM VERIFY 1MB AMS
110 CALL AMSON
120 REM WRITE PAGES
130 FOR I=0 TO 255
140 CALL LOAD(16388,I):: REM SET PAGE AT >2000
150 CALL LOAD(8192,I):: REM STORE DATA AT >2000
160 NEXT I
170 REM READ THEM BACK
180 ERR=0
190 FOR I=0 TO 255
200 CALL LOAD(16388,I):: REM SET PAGE
210 CALL PEEK(8192,A):: REM READ DATA
220 IF A<>I THEN PRINT "MISMATCH PAGE";I;" GOT";A :: ERR=ERR+1
230 NEXT I
240 CALL AMSOFF
250 PRINT "TEST COMPLETE."
260 IF ERR=0 THEN PRINT "1MB PAGES VERIFIED"

 

and that also works now. Will upload v349 but that's all this week.

 

 

RXB is pretty nice, by the way. Not sure why I like it already. Maybe just the color scheme.

 

This probably counts as an RXB bug, btw! Even with these fixes, if I run RXB after a program that sets the mapper to passthrough mode, RXB can't see the mapper anymore. I've changed Classic99 to reset the mapper on File->Reset, but I don't know if that's how the real card behaves, the schematics suggest no. At any rate, it's better to explicitly set the mapper on than to assume it is, if you can!

Edited March 22, 2011 by Tursi

[RXB]

There's been a bit of a thread on the side about the AMS function in Classic99, and having gone through the code and looked at some more of the documentation, it really seems like everything's on the up and up with the emulation there. I went through the AMS test code again, now that I have some understanding of the mapper function.

 

The reason it was failing turned out to be fairly simple. Joe coded the register map to only work from >4000 to >401F, instead of repeating through the entire DSR space. For some reason, this application poked the registers at the END of DSR space, from >5FE0 to >5FFF. Thierry's schematics say it should repeat, so I fixed that, and the test runs.

 

 

It only detects 128k, and it looks like that is in fact the maximum that this program recognizes, but it jumps around so much I was not inclined to try and make it test more. Classic99 emulates a full 1MB, which means each register can have a full 8 bit offset. (In fact, it emulates 1MB no matter what you configure for size in the ini...)

 

A second problem is that Classic99's AMS defaulted to pass-through for compatibility, and RXB never actually turns on the mapping! (LI R12,>1E00, SBO 2). This left the chip in passthrough mode, which may not have been the default. I've changed this behaviour, but if it breaks anything else I'll have to change it back.

 

I did my own quick little memory test to verify this is in fact true (that 1MB works).. this test just runs all the pages through >2000 to do it's verification:

 

100 REM VERIFY 1MB AMS
110 CALL AMSON
120 REM WRITE PAGES
130 FOR I=0 TO 255
140 CALL LOAD(16388,I):: REM SET PAGE AT >2000
150 CALL LOAD(8192,I):: REM STORE DATA AT >2000
160 NEXT I
170 REM READ THEM BACK
180 ERR=0
190 FOR I=0 TO 255
200 CALL LOAD(16388,I):: REM SET PAGE
210 CALL PEEK(8192,A):: REM READ DATA
220 IF A<>I THEN PRINT "MISMATCH PAGE";I;" GOT";A :: ERR=ERR+1
230 NEXT I
240 CALL AMSOFF
250 PRINT "TEST COMPLETE."
260 IF ERR=0 THEN PRINT "1MB PAGES VERIFIED"

 

and that also works now. Will upload v349 but that's all this week.

 

 

RXB is pretty nice, by the way. Not sure why I like it already. Maybe just the color scheme.

 

This probably counts as an RXB bug, btw! Even with these fixes, if I run RXB after a program that sets the mapper to passthrough mode, RXB can't see the mapper anymore. I've changed Classic99 to reset the mapper on File->Reset, but I don't know if that's how the real card behaves, the schematics suggest no. At any rate, it's better to explicitly set the mapper on than to assume it is, if you can!

 

 

Yea I orignally copied the Paul Schippnick Assembly routines from SAMS that was the upgrade from the 64k AMS to a 128K AMS and forgot to set the variable from E=32 for 128K to 256 for 1024K easy fix.

 

on line 7055 E=32 just change it to E=256 and then you have a 1024K AMS. I plan on writting a bunch of RXB SAMS support programs people can run.

[Tursi]

Any chance you can also fix RXB to explicitly turn mapping mode on? (I got the impression you were making updates to it anyway). That way it will work in all situations.

[RXB]

Any chance you can also fix RXB to explicitly turn mapping mode on? (I got the impression you were making updates to it anyway). That way it will work in all situations.

 

 

When you start up RXB it only uses memory it has. Type:

SIZE

it returns XB program and string and Disk Buffer space used.

CALL INIT :: SIZE

it returns Lower 8K assembly space free and used.

CALL AMSINIT :: SIZE

it returns Lower 8K AMS banks available for use.

 

The CALL AMSINIT turns on MAP mode then turns it off. You would use CALL AMSBANK(#,#) to set up the pages you want open and that leaves the mapper on.

 

The reason I do this is for the User to not end up locked up in a bank in Mapped mode when the Pass mode bank had what he started with.

Also if I give the User access to High banks that is going to result in some horrid lock ups.

 

For High memory I was thinking of putting a mapper and contol into RXB Editor Assembler for the Assembly people.

Say like Turn on mapper and select a bank to load into and as the loader is in GRAM/GROM you can load any banks at all without conflicts.

And instead of a Load and Run option to run the programs I can give you a Execute address. Say like set >A000 as always the start address to run programs from.

Or I could just have them type in the address.

 

I thought about it and if you want to use a CALL LOAD to change the mapper registers then just use CALL AMSON and map it yourself, but of course banks

2,3 are for lower 8k and banks 10,11,12,13,14,15 are for upper 24K and are the PASS mode defaults. I think the Editor Assembler way is better for your purposes.

For the XB programers I really want it to be clean and simple and for the EA programmers give them everything possible.

Edited March 23, 2011 by RXB

[Willsy]

When writing to the mapper registers at >40xx is it only the upper byte that is significant?

 

I think the answer is yes, but I'd like someone less stupid than me to confirm it!

[RXB]

When writing to the mapper registers at >40xx is it only the upper byte that is significant?

 

I think the answer is yes, but I'd like someone less stupid than me to confirm it!

 

 

Well here is the package I recieved from Asgard to start programming with my free 128K AMS.

MyZipFile.zip

[Tursi]

Any chance you can also fix RXB to explicitly turn mapping mode on? (I got the impression you were making updates to it anyway). That way it will work in all situations.

 

 

When you start up RXB it only uses memory it has. Type:

SIZE

it returns XB program and string and Disk Buffer space used.

CALL INIT :: SIZE

it returns Lower 8K assembly space free and used.

CALL AMSINIT :: SIZE

it returns Lower 8K AMS banks available for use.

 

The CALL AMSINIT turns on MAP mode then turns it off. You would use CALL AMSBANK(#,#) to set up the pages you want open and that leaves the mapper on.

 

The reason I do this is for the User to not end up locked up in a bank in Mapped mode when the Pass mode bank had what he started with.

Also if I give the User access to High banks that is going to result in some horrid lock ups.

 

For High memory I was thinking of putting a mapper and contol into RXB Editor Assembler for the Assembly people.

Say like Turn on mapper and select a bank to load into and as the loader is in GRAM/GROM you can load any banks at all without conflicts.

And instead of a Load and Run option to run the programs I can give you a Execute address. Say like set >A000 as always the start address to run programs from.

Or I could just have them type in the address.

 

In that case, the AMSTEST program that you provided needs to have one of that CALL AMSINIT or CALL AMSBANK functions added, because if the card is in passthrough mode it doesn't work.

 

I changed the emulator based on your assertion that this program should work out of the box. I think you can understand why it's important that the emulation be correct! So to be clear, then, the AMS card should power up in Passthrough mode, yes?

[Tursi]

When writing to the mapper registers at >40xx is it only the upper byte that is significant?

 

According to the schematics and all the code I studied, yes. Like most 99/4A hardware, it appears to latch only on even addresses.

 

I don't have such a card, though, so I can't confirm it on real hardware. But the schematics on Thierry's page describe a chip with only 8-bit registers.

[RXB]

Any chance you can also fix RXB to explicitly turn mapping mode on? (I got the impression you were making updates to it anyway). That way it will work in all situations.

 

 

When you start up RXB it only uses memory it has. Type:

SIZE

it returns XB program and string and Disk Buffer space used.

CALL INIT :: SIZE

it returns Lower 8K assembly space free and used.

CALL AMSINIT :: SIZE

it returns Lower 8K AMS banks available for use.

 

The CALL AMSINIT turns on MAP mode then turns it off. You would use CALL AMSBANK(#,#) to set up the pages you want open and that leaves the mapper on.

 

The reason I do this is for the User to not end up locked up in a bank in Mapped mode when the Pass mode bank had what he started with.

Also if I give the User access to High banks that is going to result in some horrid lock ups.

 

For High memory I was thinking of putting a mapper and contol into RXB Editor Assembler for the Assembly people.

Say like Turn on mapper and select a bank to load into and as the loader is in GRAM/GROM you can load any banks at all without conflicts.

And instead of a Load and Run option to run the programs I can give you a Execute address. Say like set >A000 as always the start address to run programs from.

Or I could just have them type in the address.

 

In that case, the AMSTEST program that you provided needs to have one of that CALL AMSINIT or CALL AMSBANK functions added, because if the card is in passthrough mode it doesn't work.

 

I changed the emulator based on your assertion that this program should work out of the box. I think you can understand why it's important that the emulation be correct! So to be clear, then, the AMS card should power up in Passthrough mode, yes?

 

Yes. If the AMS is in PASS mode that is not a problem as the normal banks are 2,3 for lower 8K and 10,11,12,13,14,15 for Upper 24K. This is why when I use CALL AMSINIT it just loads the registers with the pages that should be there already and does not error out.

Now AMSMAP will check the banks and tests to see if it can map all of them from 0 to 255 that is the only check on the AMS my RXB does, if a better test is needed then the AMSTEST XB program is needed.

That is why when AMSMAP is used it says * NO AMS DETECTED * as the error report I built into RXB. So only AMSMAP will report a probelm. I will add AMSINT and AMSMAP to the AMSTEST program.

Edited March 24, 2011 by RXB

[RXB]

Ok so the write to GRAM has a problem.

When you go to Options and select GRAM and select the bank like say >E000 and it puts the check mark in the slot but when you look a second time it takes it out and puts it at >0000 always no matter where you put the original check mark.

Next it crashes when you try to write to GRAM with anything exect RXB POKEG?

I am including the GPL*LOADER and my OBJECT file. Just go to RXB or EA and run the program and type in the name of the file ORXB7 and it should load but says no GRAM. The program GPL*LOADER only writes to base GRAM bank 1 or what ever bank is presently active.

The object file OSRXB7 is the new version of Editor Assembler. I should be able to load it then load Miss/1 and save the >E000 GRAM file as a single file.

 

I will also incude the Miss/1 in the attachment. So the steps are:

1. EA or RXB EA option 5

2. DSK#.GPL@LOADER

3. DSK#.OSRXB7

4. ENTER TO EXIT THE GPL*LOADER AFTER SUCCESSFUL LOAD OF GRAM FILE OSRXB7

5. EA OR RXB EA

6. DSK#.MISS/1

7. SELECT CART MODULE AND SAVE TO DISK.

8. YOU NOW HAVE A GRAM >E000 TO >FFFF RXB EA CART IN .grm format ready to use.

MyZipFile.zip

[Willsy]

Any chance you can also fix RXB to explicitly turn mapping mode on? (I got the impression you were making updates to it anyway). That way it will work in all situations.

 

 

When you start up RXB it only uses memory it has. Type:

SIZE

it returns XB program and string and Disk Buffer space used.

CALL INIT :: SIZE

it returns Lower 8K assembly space free and used.

CALL AMSINIT :: SIZE

it returns Lower 8K AMS banks available for use.

 

The CALL AMSINIT turns on MAP mode then turns it off. You would use CALL AMSBANK(#,#) to set up the pages you want open and that leaves the mapper on.

 

The reason I do this is for the User to not end up locked up in a bank in Mapped mode when the Pass mode bank had what he started with.

Also if I give the User access to High banks that is going to result in some horrid lock ups.

 

For High memory I was thinking of putting a mapper and contol into RXB Editor Assembler for the Assembly people.

Say like Turn on mapper and select a bank to load into and as the loader is in GRAM/GROM you can load any banks at all without conflicts.

And instead of a Load and Run option to run the programs I can give you a Execute address. Say like set >A000 as always the start address to run programs from.

Or I could just have them type in the address.

 

In that case, the AMSTEST program that you provided needs to have one of that CALL AMSINIT or CALL AMSBANK functions added, because if the card is in passthrough mode it doesn't work.

 

I changed the emulator based on your assertion that this program should work out of the box. I think you can understand why it's important that the emulation be correct! So to be clear, then, the AMS card should power up in Passthrough mode, yes?

 

The card should definitely, 100% power up in pass-thru mode. That is the default behaviour.