Classic99 Updates

[+retroclouds]

By the way not many people know this but if you put a Basic program in RAM or GROM or VDP it will run fine as long as you have a header there for it to see it and then it will run it.

 

So it would be possible to write a 640K Basic Program and put it all into one Cartridge and only run this from a TI console and nothing else.

(Not using any simulator it is all built into the TI OS.)

This may sound weird, but I silently posed this question to myself a number of times in my younger years, whether it would be possible to run a BASIC program outside of VDP RAM. I really have no idea why. In any case, it would be really cool to see this demonstrated.

 

Yep, would interest me if it'd run considerably faster without the VDP overhead. Then again perhaps you would not notice if the VDP overhead

isn't that big compared to the speed of GPL -> BASIC processing.

[Tursi]

BASIC programs can not be run from CPU memory (RAM or ROM) unless you hack the GPL interpreter like some of the old pirated games do. I spent a long time studying the interpreter for this very reason and I am quite confident in my results.

 

BASIC programs CAN be tagged to run from GROM - I think we touched on this in the BOCC thread. There are some subtle differences, for instance, FCTN-4 is disabled automatically! I have not attempted this since nobody is building GROM carts yet but the support is there. Of course it'd be slightly slower in terms of memory access than VDP, but you probably wouldn't see the hit since comparably little time is spent fetching data compared to executing it. As far as I could tell the need to "seek" around GROM space (to run the interpreter versus loading the BASIC program) won't impact as the GPL interpreter goes through pretty much the same motions in terms of setting addresses whether it needs to or not.

 

The BASIC interpreter does not support multiple GROM bases, though, your program would only work in a single 40k base. Still, 40k of BASIC is a lot more than 16k.

Edited March 17, 2011 by Tursi

[Tursi]

The thread seems to have slipped a bit, let me put it back on topic. At 6:30 this morning, before I went to bed, I posted v347 of Classic99. I was just absolutely done with this after more than two weeks of updates.

 

There are a couple of bugs fixed, but most of this is UI for you people. You can configure disks in real time (folders and disk images), enable/disable GRAM blocks at will, and make E/A#5, 379-based ROM, or GROM-based versions of your loaded software (including a few little presents there). The TI BASIC ROM cart code will be delayed a little longer till Owen is done with his prizes. There some things I need to tweak up to make this code a little more useful (I want to enable loading Sometimes99er's fonts, for instance), but I just ran out of will to live (UI code does that to me ), so I stopped before it got serious!

 

One other big thing I changed (which is little to the code), is I finally hit a case myself where I needed the VRAM to look like there was a real disk controller, so that is now the default. That is, Classic99 will reserve a big chunk of VRAM by default. It doesn't DO anything with it, it just updates the pointer. You can change it as per a real machine with CALL FILES(). Unlike a real machine, CALL FILES(0) will free /all/ the VRAM and give you the old memory map. CALL FILES, though, has NO EFFECT on the Classic99 disk system, it's just to move the free VRAM pointer around. Don't forget you need to use NEW after CALL FILES for it to work.

 

Also, I have no software to test GRAM. It works the way I think it should work, but I guess something preexisting will need to try and use it to see if I got it right.

 

There are lots of and lots of goodies, nearly 3000 lines of new code, and I updated the manual to cover them all. Here's the official changelist. There are so many changes that I /do/ expect bugs in the new features, feel free to let me know what you find. Hopefully there's nothing too seriously blocking, so I can do something else for a while.

 

-Change free sectors on FIAD disks to make sector based programs willing to try to write

-open DSK images as binary to prevent read translation errors

-Add read/write breakpoints for VDP and GROM addresses

-Save file open information into the right buffer

-Check a file is open before reading or writing it (or restore or scratch)

-Fix bitmap mode masking

-Rework X instruction - more efficent and works correctly with jumps now

-Fixed case where X instruction may be skipped, depending on race

-Fixed case where cycles may be lost due to race condition

-Moved debug GUI buttons into drop-down menu

-Made fast-forward from debug GUI reset timers correctly

-Closing debug dialog should now clear all debug modes and restore normal operation

-Changed disk Open() methods to return the new FileInfo object used, fixes certain cases of lost state

-Added CHARA1 as a resource for the save RAM dialog

-added cycle counting to run result report

-Fixed LOAD opcode in FIAD disk not to load more than program says is valid (used to read whole of last sector or more if file was invalid)

-Made debugger memory change require a prefix for CPU and display a warning otherwise

-Implemented code to create Cartridge Images (GROM and 379) and E/A#5 program files from the Debug panel from loaded memory

-Cartridge image code supports injecting lower-case characters and Editor/Assembler utilities, as well as patching C99 programs

-Fixed uninitialized memory tracking for 32k expansion RAM

-Added 3.BIN extension for autoloading 379 style carts

-Clear all cartridge checks when using User->Open

-Fixed the Disk Class to run the DSR powerup only once

-Allow '0' for CALL FILES() (emulates CS1 mode)

-Make CALL FILES actually use up VDP RAM to closer resemble real disk system. You can override with CALL FILES(0)

-Added disk configuration dialog

-Added menu option to open a disk folder in Explorer (or disk image if you have something like TI99Dir configured)

-Added ability to make GROM writable (GRAM?) - not really tested as I have no software to test with

-Adde Help->Open Manual to open the PDF file

-Disable SID Blaster by default

-Don't check for a 6-byte header on 379 type files (bugfix)

-Fix reset race by disabling interrupts on reset (fixes 99/4 startup?)

-More accurate CPU instruction counting

-OPEN opcode shows the requested filetype in debug

-Included Line-by-Line assembler and Lines demo for Mini-Memory on DSK1

-Manual's TOC is now hyperlinked

 

http://harmlesslion.com/software/classic99

[unhuman]

Wow! Doing this update now!

 

OOOHHH! The new DSK support is going to be awesomes... A minor request "open disk" doesn't work with DSK support, but if it showed the directory ala TI99Dir - that'd be amazing... So very amazing!

 

And I finally read the instructions... I associated TI99Dir with .DSK and it attempts to open it - but it always gives the following error:

Can't read file or directory

<"C:\Users\Howie\Downloads\TI-99\EDUGAMES.dsk">

 

So, it tries... I'd certainly prefer to see integrated support - but - maybe I'm doing something wrong here...

 

And, in the help menu - cartridge is spelled incorrectly.

Edited March 18, 2011 by unhuman

[Tursi]

And I finally read the instructions... I associated TI99Dir with .DSK and it attempts to open it - but it always gives the following error:

Can't read file or directory

<"C:\Users\Howie\Downloads\TI-99\EDUGAMES.dsk">

 

Yeah, as far I know you are doing everything right, I've written Fred to ask what's wrong. It does the same thing when you drag and drop a disk image onto the EXE, so it's not Classic99's fault.

 

So, it tries... I'd certainly prefer to see integrated support

 

hehe.. sorry, I'm not writing a disk manager too!! We have a decent one.

 

And, in the help menu - cartridge is spelled incorrectly.

 

Well, it's been like that for years, so I will take a note and it can wait. hehe

[RXB]

The thread seems to have slipped a bit, let me put it back on topic. At 6:30 this morning, before I went to bed, I posted v347 of Classic99. I was just absolutely done with this after more than two weeks of updates.

 

There are a couple of bugs fixed, but most of this is UI for you people. You can configure disks in real time (folders and disk images), enable/disable GRAM blocks at will, and make E/A#5, 379-based ROM, or GROM-based versions of your loaded software (including a few little presents there). The TI BASIC ROM cart code will be delayed a little longer till Owen is done with his prizes. There some things I need to tweak up to make this code a little more useful (I want to enable loading Sometimes99er's fonts, for instance), but I just ran out of will to live (UI code does that to me ), so I stopped before it got serious!

 

One other big thing I changed (which is little to the code), is I finally hit a case myself where I needed the VRAM to look like there was a real disk controller, so that is now the default. That is, Classic99 will reserve a big chunk of VRAM by default. It doesn't DO anything with it, it just updates the pointer. You can change it as per a real machine with CALL FILES(). Unlike a real machine, CALL FILES(0) will free /all/ the VRAM and give you the old memory map. CALL FILES, though, has NO EFFECT on the Classic99 disk system, it's just to move the free VRAM pointer around. Don't forget you need to use NEW after CALL FILES for it to work.

 

Also, I have no software to test GRAM. It works the way I think it should work, but I guess something preexisting will need to try and use it to see if I got it right.

 

There are lots of and lots of goodies, nearly 3000 lines of new code, and I updated the manual to cover them all. Here's the official changelist. There are so many changes that I /do/ expect bugs in the new features, feel free to let me know what you find. Hopefully there's nothing too seriously blocking, so I can do something else for a while.

 

-Change free sectors on FIAD disks to make sector based programs willing to try to write

-open DSK images as binary to prevent read translation errors

-Add read/write breakpoints for VDP and GROM addresses

-Save file open information into the right buffer

-Check a file is open before reading or writing it (or restore or scratch)

-Fix bitmap mode masking

-Rework X instruction - more efficent and works correctly with jumps now

-Fixed case where X instruction may be skipped, depending on race

-Fixed case where cycles may be lost due to race condition

-Moved debug GUI buttons into drop-down menu

-Made fast-forward from debug GUI reset timers correctly

-Closing debug dialog should now clear all debug modes and restore normal operation

-Changed disk Open() methods to return the new FileInfo object used, fixes certain cases of lost state

-Added CHARA1 as a resource for the save RAM dialog

-added cycle counting to run result report

-Fixed LOAD opcode in FIAD disk not to load more than program says is valid (used to read whole of last sector or more if file was invalid)

-Made debugger memory change require a prefix for CPU and display a warning otherwise

-Implemented code to create Cartridge Images (GROM and 379) and E/A#5 program files from the Debug panel from loaded memory

-Cartridge image code supports injecting lower-case characters and Editor/Assembler utilities, as well as patching C99 programs

-Fixed uninitialized memory tracking for 32k expansion RAM

-Added 3.BIN extension for autoloading 379 style carts

-Clear all cartridge checks when using User->Open

-Fixed the Disk Class to run the DSR powerup only once

-Allow '0' for CALL FILES() (emulates CS1 mode)

-Make CALL FILES actually use up VDP RAM to closer resemble real disk system. You can override with CALL FILES(0)

-Added disk configuration dialog

-Added menu option to open a disk folder in Explorer (or disk image if you have something like TI99Dir configured)

-Added ability to make GROM writable (GRAM?) - not really tested as I have no software to test with

-Adde Help->Open Manual to open the PDF file

-Disable SID Blaster by default

-Don't check for a 6-byte header on 379 type files (bugfix)

-Fix reset race by disabling interrupts on reset (fixes 99/4 startup?)

-More accurate CPU instruction counting

-OPEN opcode shows the requested filetype in debug

-Included Line-by-Line assembler and Lines demo for Mini-Memory on DSK1

-Manual's TOC is now hyperlinked

 

http://harmlesslion.com/software/classic99

 

 

Well you can use RXB to do that. CAll POKEG or CALL MOVES both read or write to GRAM. You can PEEKG or POKEG at a space already a zero like CALL PEEKG(-16,VAR)::PRINT VAR

I know that that address is a zero and if you poke it there and it changes then you have a working GRAM in RXB 2001.

[Tursi]

Well you can use RXB to do that. CAll POKEG or CALL MOVES both read or write to GRAM. You can PEEKG or POKEG at a space already a zero like CALL PEEKG(-16,VAR)::PRINT VAR

I know that that address is a zero and if you poke it there and it changes then you have a working GRAM in RXB 2001.

 

Ah ha.. that's useful information. But I figured the fellow who asked for the feature could test it for me!

[Tursi]

Okay, so I tested with RXB, and sure enough the GRAM writes go to the wrong address (I was hoping the prefetch worked the same way as the VDP). So either you will have to do your GRAM writes one address lower than you want, or wait for the next version. I'll double check how RXB does these accesses and make it work there.

[Tursi]

I have a question now.. RXB does all its GRAM writes one at a time through the GPL interpreter, and that's pretty straight forward code:

 

Destination GROM:
0686 DB42 MOVB 2,@>0402(13) Write GROM address
0688 0402
068A DB60 MOVB @>83E5,@>0402(13)
068C 83E5
068E 0402
0690 0582 INC 2 Next address
0692 DB4B MOVB 11,@>0400(13) Write into GRAM
0694 0400
0696 1019 JMP >06CA Go on

 

From this code and RXB's behaviour, I can see that the address written is the address which the data is stored at, so that's easy enough. My question is two-fold, when the write occurs, what happens to the GROM:

 

A) What happens to the address counter - does it auto-increment?

B) (Bonus question) What ends up in the prefetch buffer of the system GROMs?

[sometimes99er]

Amazing. Excellent. Thanks.

[+retroclouds]

Thanks for the update Tursi! I see plenty of stuff I like

[RXB]

Fantastic work love the new Classic99. Ran this program to test GRAM with debugger on

and ran into a odd problem.

Here is the RXB program:

100 FOR B=0 TO 15

110 CALL PEEKG(-16,A)

120 CALL POKEG(-16,B)

130 PRINT A,B

140 NEXT B

150 RUN

 

So with the Clasic99 debugger on it says GRAM >FFF0 is always zero but FFF1 is the one

changing to the new number. So the problem seems to be the address is off by one address.

The address it is writting to is >FFF1 even though address -16 is >FFF0 not >FFF1 which is -15

In the TI address system >FFFF is -1 Decimal so >FFF0 is -16 not -15 and that would explain

why >FFF1 is changing but >FFF0 is not changing. Checked this on PC99 to make sure.

My PGRAMs are dead so can not check on TI to confirm.

[RXB]

I have a question now.. RXB does all its GRAM writes one at a time through the GPL interpreter, and that's pretty straight forward code:

 

Destination GROM:
0686 DB42 MOVB 2,@>0402(13) Write GROM address
0688 0402
068A DB60 MOVB @>83E5,@>0402(13)
068C 83E5
068E 0402
0690 0582 INC 2 Next address
0692 DB4B MOVB 11,@>0400(13) Write into GRAM
0694 0400
0696 1019 JMP >06CA Go on

 

From this code and RXB's behaviour, I can see that the address written is the address which the data is stored at, so that's easy enough. My question is two-fold, when the write occurs, what happens to the GROM:

 

A) What happens to the address counter - does it auto-increment?

B) (Bonus question) What ends up in the prefetch buffer of the system GROMs?

 

 

Well as a Programmer and not a hardware guy it is my understanding that the GROM is always autoincrementing.

I downloaded a PDF copy of TI INTERN and >08CE in ROM shows how it pops a stack address off the GROM table and Hbyte is in R9 and Lbyte is in R8.

>0696 1019 JMP >06CA

 

>06CA 0608 Dec 8 (R9 is Hbyte, R8 is Lbyte) He puts in notes End ? as Grom is neverending it increments back to >0000 when hitting >FFFF and the Dec is to make up for the fetch that increments stack I think.

I am real rusty on Assembly after 10 years away but it appears in the GPL interpeter that R6 is the subroutine for GPL version of Gosub and R8 & R9 are the address of GPL currently being interpeted.

 

 

*******************************************************************************

* Notes to GPL interpreter: *

* *

* In general the registers are used as follows: *

* *

* D: R3=Address, R2=Data, R4HByte=Flag VDP-RAM *

* S: R1=Address, R0=Data, R4LByte=Flag VPD-RAM *

* GPL code is located in R9 HByte, and R5 is flag at word commands *

* *

*******************************************************************************

This is from Intern and explains a little bit, like I said I am rusty on Assembly.

I will keep looking at it sorry can not be more help right now.

[Tursi]

The cases I asked about aren't covered in the console ROM since the GPL interpreter always sets the address before doing a write. Where-ever possible, I prefer to work from practice, and not theory. There's a lot of passionate misinformation out there, so before I make a questionable change, I always try to write test code to prove the real behaviour.

 

So, tonight I sat down and wrote some test programs on the real hardware. I only care what the console GROMs do. GRAMs are fake devices but since all devices respond to all GROM accesses, it needs to remain compatible with what the console GROMs do.

 

What I found was this:

 

1) Yes, GRAM writes cause autoincrement of the GROMs

2) No, the GROM prefetch operation is not affected by writes to GRAM, it behaves the same way as if a read was performed

3) And, of course, GRAMs expect to write to the address actually written, and not the post-incremented address like with the VDP. Which means GRAMs are kind of a hack since they'd have to either write to the internal address minus one, or not prefetch and increment the address like the GROMs do. (Classic99 does the first approach).

 

Since I was doing this anyway, I had some outstanding questions about the VDP's behaviour to resolve. In particular, I fixed up the way the address counter writes work (including partial writes), what the address counter does when you write to the VDP registers (it takes the 14-bit masked address and keeps it, but does not prefetch or autoincrement), and in what cases written data ends up in the prefetch buffer (all data written to the data port, no data written to the address port).

 

Since I messed with the VDP, I ran the Diagnostics cartridge checkerboard test to double-check, and was shocked to see it fail. After more than an hour I tracked it down to a bug in the cartridge - if you ran it on a real console with a disk controller, it would also fail. What happens is when the VRAM size is reduced, the algorithm used in the checkerboard test for /writing only/ skips addresses. The read code doesn't, so it ends up getting bad results. Resetting the VRAM pointer before running the test made it pass.

 

So, I have posted the new update, it should work for you for now:

 

-Update 'known issues' for Diagnostic Cart -- Checkerboard test fails when the disk system allocates VRAM. No fix intended - in the future you'll be able to disable the disk controller. If you need it now, use the debugger on the title screen to set >8370 to >3FFF

-Fix resource leak in Heatmap that would eventually lock up the emulator

-Simplified VDP address updates based on hardware observations

-Verified VDP prefetch and address register behaviour against hardware

-fixed GRAM write address (tesed against RXB's CALL POKEG)

-verified GROM address and prefetch behaviour during writes against hardware

 

http://harmlesslion.com/software/classic99

[RXB]

The cases I asked about aren't covered in the console ROM since the GPL interpreter always sets the address before doing a write. Where-ever possible, I prefer to work from practice, and not theory. There's a lot of passionate misinformation out there, so before I make a questionable change, I always try to write test code to prove the real behaviour.

 

So, tonight I sat down and wrote some test programs on the real hardware. I only care what the console GROMs do. GRAMs are fake devices but since all devices respond to all GROM accesses, it needs to remain compatible with what the console GROMs do.

 

What I found was this:

 

1) Yes, GRAM writes cause autoincrement of the GROMs

2) No, the GROM prefetch operation is not affected by writes to GRAM, it behaves the same way as if a read was performed

3) And, of course, GRAMs expect to write to the address actually written, and not the post-incremented address like with the VDP. Which means GRAMs are kind of a hack since they'd have to either write to the internal address minus one, or not prefetch and increment the address like the GROMs do. (Classic99 does the first approach).

 

Since I was doing this anyway, I had some outstanding questions about the VDP's behaviour to resolve. In particular, I fixed up the way the address counter writes work (including partial writes), what the address counter does when you write to the VDP registers (it takes the 14-bit masked address and keeps it, but does not prefetch or autoincrement), and in what cases written data ends up in the prefetch buffer (all data written to the data port, no data written to the address port).

 

Since I messed with the VDP, I ran the Diagnostics cartridge checkerboard test to double-check, and was shocked to see it fail. After more than an hour I tracked it down to a bug in the cartridge - if you ran it on a real console with a disk controller, it would also fail. What happens is when the VRAM size is reduced, the algorithm used in the checkerboard test for /writing only/ skips addresses. The read code doesn't, so it ends up getting bad results. Resetting the VRAM pointer before running the test made it pass.

 

So, I have posted the new update, it should work for you for now:

 

-Update 'known issues' for Diagnostic Cart -- Checkerboard test fails when the disk system allocates VRAM. No fix intended - in the future you'll be able to disable the disk controller. If you need it now, use the debugger on the title screen to set >8370 to >3FFF

-Fix resource leak in Heatmap that would eventually lock up the emulator

-Simplified VDP address updates based on hardware observations

-Verified VDP prefetch and address register behaviour against hardware

-fixed GRAM write address (tesed against RXB's CALL POKEG)

-verified GROM address and prefetch behaviour during writes against hardware

 

http://harmlesslion.com/software/classic99

 

 

OMG Great job. Thank you for the update.

Working on recovering the original XB Source code as years ago a SCSI hard drive died so only have some of it and have to hand edit it to be useful, just like old time 10 years ago editing by hand.

GPL was on the orignal 990 mini frame in GRAM/GROM as it was a safe place to put programs that would not be molested as it had a hardware write protect switch(it was basically a RAM board with power to keep the memory alive). I have a ol buddy that had the orignal 990 and almost everything made for it. He got it off a TI Auction and set it up in his basement. When he turned it on for me the house lights dimmed. His 990 had the 8' hard drives, a printer the sized of a large computer desk and all kinds of devices on tables with cables going to them. He also had Bubble memory cards. He did not have the 990 software to make his GRAM/GROM cards work. He did have the manuals for it.

[Tursi]

Working on recovering the original XB Source code as years ago a SCSI hard drive died so only have some of it and have to hand edit it to be useful, just like old time 10 years ago editing by hand.

GPL was on the orignal 990 mini frame in GRAM/GROM as it was a safe place to put programs that would not be molested as it had a hardware write protect switch(it was basically a RAM board with power to keep the memory alive). I have a ol buddy that had the orignal 990 and almost everything made for it. He got it off a TI Auction and set it up in his basement. When he turned it on for me the house lights dimmed. His 990 had the 8' hard drives, a printer the sized of a large computer desk and all kinds of devices on tables with cables going to them. He also had Bubble memory cards. He did not have the 990 software to make his GRAM/GROM cards work. He did have the manuals for it.

 

That's pretty impressive stuff... any chance any photos of that equipment survived?

[RXB]

Working on recovering the original XB Source code as years ago a SCSI hard drive died so only have some of it and have to hand edit it to be useful, just like old time 10 years ago editing by hand.

GPL was on the orignal 990 mini frame in GRAM/GROM as it was a safe place to put programs that would not be molested as it had a hardware write protect switch(it was basically a RAM board with power to keep the memory alive). I have a ol buddy that had the orignal 990 and almost everything made for it. He got it off a TI Auction and set it up in his basement. When he turned it on for me the house lights dimmed. His 990 had the 8' hard drives, a printer the sized of a large computer desk and all kinds of devices on tables with cables going to them. He also had Bubble memory cards. He did not have the 990 software to make his GRAM/GROM cards work. He did have the manuals for it.

 

That's pretty impressive stuff... any chance any photos of that equipment survived?

 

I can check he was part of P.U.N.N. User group here, the last officer running meetings died a few years ago. I can make a few phone calls.

[+Vorticon]

I noticed today that the default filtering in Classic 99 makes the characters appear very mushy and they lose definition. Turning filtering off results in the closest reproduction of TI graphics looks on a monitor. Ultimate Planet initially looked terrible with filtering on, and it took me a while to figure out why. I know, I know, RTFM

Out of curiosity, why was this feature included?

[Tursi]

Out of curiosity, why was this feature included?

 

Because I liked it when I first saw it.

 

I like the HQ4x filter more, now, but it's CPU intensive so it doesn't ship turned on. And in truth my taste lately has leaned to myself running with all the filters off so I see the actual pixels, too.

 

All the filters distort the image, though I would argue that if you grew up on NTSC TI's that the NTSC filter actually looks closest to true TI graphics, all aliased and noisy.

 

-----

 

In other news: Updated the fixes to the AMS card for RXB. V349:

 

-Fix AMS registers to map throughout the DSR space

-Set AMS to map mode by default

 

http://harmlesslion.com/software/classic99

[+retroclouds]

Out of curiosity, why was this feature included?

 

Because I liked it when I first saw it.

 

I like the HQ4x filter more, now, but it's CPU intensive so it doesn't ship turned on. And in truth my taste lately has leaned to myself running with all the filters off so I see the actual pixels, too.

 

All the filters distort the image, though I would argue that if you grew up on NTSC TI's that the NTSC filter actually looks closest to true TI graphics, all aliased and noisy.

 

-----

 

In other news: Updated the fixes to the AMS card for RXB. V349:

 

-Fix AMS registers to map throughout the DSR space

-Set AMS to map mode by default

 

http://harmlesslion.com/software/classic99

 

oh man, you are really rocking. Pushing all these updates

[RXB]

Out of curiosity, why was this feature included?

 

Because I liked it when I first saw it.

 

I like the HQ4x filter more, now, but it's CPU intensive so it doesn't ship turned on. And in truth my taste lately has leaned to myself running with all the filters off so I see the actual pixels, too.

 

All the filters distort the image, though I would argue that if you grew up on NTSC TI's that the NTSC filter actually looks closest to true TI graphics, all aliased and noisy.

 

-----

 

In other news: Updated the fixes to the AMS card for RXB. V349:

 

-Fix AMS registers to map throughout the DSR space

-Set AMS to map mode by default

 

http://harmlesslion.com/software/classic99

 

 

Ok as ussual you are ahead of me. I was working on the problem and pretty much at the conclusion the problem was DSR releated and was looking for my old Miller Graphics DSR as everyone seems to be using the cut down one that does not respond to anything but Assembly access. The cut down DSR became popular becuase it saved space, but you can not access many features in the TI console or subroutines as the cut down DSR does not support GPL. Hence I was sure this was the problem. How did you figure it out?

[Tursi]

I was receiving some offline messages asking about the AMS support and how it worked - in order to answer them I studied the Classic99 implementation of AMS until I understood what it was doing. Then I compared my observations with a couple of documentation sources and found they matched.

 

With the understanding of the card, I read through the XB AMSTest program, translating the CALL LOAD and CALL PEEK addresses to see what it was doing. That program jumps around WAY too much. Anyway, it was quickly obvious that it was using addresses that Classic99 did not respond to. I went back and looked at Thierry's schematics, and saw (as is normally the case) that the addressed were only partially decoded, and so the ranges for CRU and registers had to repeat through the memory space. I changed that and tested the program again, and it worked.

 

Since the program only counted 128k, and I couldn't quite work out how to extend it, I wrote my own quick program to count pages to make sure the whole 1MB worked. That's in the other thread if anyone wants it.

 

Now that I understand it, a future update can pull it into the mainline memory system - that'll help debugging.

[RXB]

I was receiving some offline messages asking about the AMS support and how it worked - in order to answer them I studied the Classic99 implementation of AMS until I understood what it was doing. Then I compared my observations with a couple of documentation sources and found they matched.

 

With the understanding of the card, I read through the XB AMSTest program, translating the CALL LOAD and CALL PEEK addresses to see what it was doing. That program jumps around WAY too much. Anyway, it was quickly obvious that it was using addresses that Classic99 did not respond to. I went back and looked at Thierry's schematics, and saw (as is normally the case) that the addressed were only partially decoded, and so the ranges for CRU and registers had to repeat through the memory space. I changed that and tested the program again, and it worked.

 

Since the program only counted 128k, and I couldn't quite work out how to extend it, I wrote my own quick program to count pages to make sure the whole 1MB worked. That's in the other thread if anyone wants it.

 

Now that I understand it, a future update can pull it into the mainline memory system - that'll help debugging.

 

 

Exellent work Tursi. I was working with my IO command to talk to the CRU of the AMS card and it was doing some vary strange things. I would get a response from one thing but another would fail, that is what made me think of finding the Miller Graphics GPL compatible DSR.

 

Thanks for the update and on a similar note I found a error in my AMS-TEST that did the same thing it only looked for a 128K AMS. Thanks again for the update.

Edited March 22, 2011 by RXB

[RXB]

Found a bug in Classic99. If you go to XB or RXB and type this:

 

10 OPEN #1:"DSK2.FILENAME",OUTPUT

20 PRINT #1:"TEST"

30 A=A+1 :: IF A=80 THEN END ELSE 20

 

Look at the file and it is DV 128, but the defualt for XB or RXB is 80 per page 138 of XB manual.

 

Defaults are:

Sequential

Display

Update

Variable

80 for Disk, 64 Cassette, 80 RS232, and 32 for Thermal Printer.

 

The default in Classic99 is 128 and this is incorrect. Could you fix this when you get time please.

[Tursi]

The default record length is dependent on the DSR - that's why it's different across all those devices.

 

Never liked programs that assumed defaults... But I will change it. Not sure where I got 128 from anyway (maybe I read "80" as hex.. hehe. In the meantime please update your programs!

 

Just to note, the default record length for "CLIP" is 254 and that won't change.