Jump to content
IGNORED

Classic99 Updates


Tursi

Recommended Posts

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.

 

 

I have put some thought into fixing something in XB that has always bugged me.

Programs are EA and XB but only the small ones, there is no reason why I could not make all XB programs as I/V 254 that way no one would ever be confused again by XB programs.

Only Basic would be at this disadvantage. The GPL code that selects either Program or I/V 254 is pretty goofy and making them all I/V254 would make all XB programs run from RAM instead of VDP and would speed up all XB programs by quite a bit.

 

What do you think, cataloging a disk with XB and EA and Basic is a real pain, this would cut down alot of the pain. Also the Basic programs would still run from XB just fine.

Link to comment
Share on other sites

Only Basic would be at this disadvantage. The GPL code that selects either Program or I/V 254 is pretty goofy and making them all I/V254 would make all XB programs run from RAM instead of VDP and would speed up all XB programs by quite a bit.

 

I agree with most of the assertion about how it figures it out, but XB relocates PROGRAM images into RAM anyway as long as it's there, so there's no speed difference to be had. I spent a lot of time looking at this when I wrote the code that loads bitmapped images -- although I wrote it for IV/254 files, I also tested against PROGRAM image files and they get moved to CPU RAM.

Link to comment
Share on other sites

Only Basic would be at this disadvantage. The GPL code that selects either Program or I/V 254 is pretty goofy and making them all I/V254 would make all XB programs run from RAM instead of VDP and would speed up all XB programs by quite a bit.

 

I agree with most of the assertion about how it figures it out, but XB relocates PROGRAM images into RAM anyway as long as it's there, so there's no speed difference to be had. I spent a lot of time looking at this when I wrote the code that loads bitmapped images -- although I wrote it for IV/254 files, I also tested against PROGRAM image files and they get moved to CPU RAM.

 

I would not change the loading side at all, that would be exactly the same. But the SAVE side would alway pick I/V254 so evenually all XB programs would be converted from PGM Image to I/V254. This is directly from the XB source code:

 

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

[1947] * OLD STATEMENT

[1948] * A normal load:

[1949] * Get a program from an external device to VDP and

[1950] * reinitialize the program pointers. Also update the line

[1951] * pointer table, since the memory size of the machine on

[1952] * which the program was created doesn't have to be the

[1953] * same as on the current system!!!! Then check if ERAM

[1954] * existed, move it to ERAM if does exist (in relocated

[1955] * from)

[1956] * Load a sequential file:

[1957] * When program is bigger than 13.5K and ERAM exists,

[1958] * maximum-length record reads are preformed to read the

[1959] * file and each record is copied into the ERAM as it is

[1960] * read.

[1961] ***********************************************************

 

So there is a slight speed up vs program Image as a table re write is not needed for the I/V254 files. Also tons of pointers do no not have to be changed and reset after the move.

I does seem real goofy that XB even used the Basic method for loading and saving files, only to stay backwards compatiable. No bonus exists for saving in Program Image format.

Matter of fact from GPL a huge number of factors have to be run. But the prescan in I/V254 seems slower, I will have to look into this.

 

 

Link to comment
Share on other sites

Well, I finally ditched Windows XP on my main PC yesterday. It had slowed to a crawl after I reinstalled Windows, and no amount of driver updates could revive it, including updating the BIOS. It was 5 years old, and in PC terms this was an eternity. So I was faced with either buying a new PC (about $1300), try installing Win 7 ($200), or install Ubuntu from a Linux magazine ($14.99). So I chose the latter, as I could always revert to the 2 other options if it did not work out. It worked out great as now my PC is back to its old speed, at least for a P4. How is this relevant to this topic you say?

Well, I was able to run Classic 99 under Ubuntu using Codeweavers' Crossover Games, and it worked really well except that speech was a little subpar. Pretty nifty! The execution speed is similar to Windows as far as I can tell.

On a side note, between Crossover Office, Crossover Games, and Dosbox Linux, and was able to use most of my old Dos/Win software with no compromise, while gaining the flexibility, speed and slickness of Linux. The latter has really come a loooong way from a decade ago as far as ease of installation and use. My first Linux experience was with Slackware Linux in the 1990's, and at the time installation was a very labor intensive proposition, not to mention X Window configuration, and you truly still needed a Dos/Win machine for real work or fun.

Next on my list is TIDIr and Asm99a :)

Link to comment
Share on other sites

Well, I finally ditched Windows XP on my main PC yesterday. It had slowed to a crawl after I reinstalled Windows, and no amount of driver updates could revive it, including updating the BIOS. It was 5 years old, and in PC terms this was an eternity.

Nice. :)

 

Apart from software reasons ... I've had my own, family and friends PCs go slow. I noticed a symptom of the fans starting to kick in earlier. I monitored temperatures, did a good clean, and performance was sometimes much better afterwards. Also I've made some graphic cards perform better adding extra, but cheap cooling. I'm not an expect at either, so go Google it, if you have further questions.

 

;)

Link to comment
Share on other sites

Well, I finally ditched Windows XP on my main PC yesterday. It had slowed to a crawl after I reinstalled Windows, and no amount of driver updates could revive it, including updating the BIOS. It was 5 years old, and in PC terms this was an eternity.

Nice. :)

 

Apart from software reasons ... I've had my own, family and friends PCs go slow. I noticed a symptom of the fans starting to kick in earlier. I monitored temperatures, did a good clean, and performance was sometimes much better afterwards. Also I've made some graphic cards perform better adding extra, but cheap cooling. I'm not an expect at either, so go Google it, if you have further questions.

 

;)

Believe me I Google the heck out of the issue, and while a few out there had similar issues, no one had a specific answer, although clearly drivers were at fault here. My PC is a Dell, so it is conceivable that they had some proprietary driver installed that is no longer available. Regardless, the issue is now moot :) Going forward, I will be building my own PC's like I used to a decade ago, that way I'll have total control over the components and it will likely be cheaper!

Link to comment
Share on other sites

Only Basic would be at this disadvantage. The GPL code that selects either Program or I/V 254 is pretty goofy and making them all I/V254 would make all XB programs run from RAM instead of VDP and would speed up all XB programs by quite a bit.

 

I agree with most of the assertion about how it figures it out, but XB relocates PROGRAM images into RAM anyway as long as it's there, so there's no speed difference to be had. I spent a lot of time looking at this when I wrote the code that loads bitmapped images -- although I wrote it for IV/254 files, I also tested against PROGRAM image files and they get moved to CPU RAM.

 

I would not change the loading side at all, that would be exactly the same. But the SAVE side would alway pick I/V254 so evenually all XB programs would be converted from PGM Image to I/V254. This is directly from the XB source code:

 

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

[1947] * OLD STATEMENT

[1948] * A normal load:

[1949] * Get a program from an external device to VDP and

[1950] * reinitialize the program pointers. Also update the line

[1951] * pointer table, since the memory size of the machine on

[1952] * which the program was created doesn't have to be the

[1953] * same as on the current system!!!! Then check if ERAM

[1954] * existed, move it to ERAM if does exist (in relocated

[1955] * from)

[1956] * Load a sequential file:

[1957] * When program is bigger than 13.5K and ERAM exists,

[1958] * maximum-length record reads are preformed to read the

[1959] * file and each record is copied into the ERAM as it is

[1960] * read.

[1961] ***********************************************************

 

So there is a slight speed up vs program Image as a table re write is not needed for the I/V254 files. Also tons of pointers do no not have to be changed and reset after the move.

I does seem real goofy that XB even used the Basic method for loading and saving files, only to stay backwards compatiable. No bonus exists for saving in Program Image format.

Matter of fact from GPL a huge number of factors have to be run. But the prescan in I/V254 seems slower, I will have to look into this.

 

If I understand correctly you have access to the original XB source code? Would you mind sharing or is there some kind of agreement preventing that?

I think getting the source code out there would be a very important step in preserving XB history. And it would be lots of fun taking a peek and learning from the documented source code. :)

Link to comment
Share on other sites

Only Basic would be at this disadvantage. The GPL code that selects either Program or I/V 254 is pretty goofy and making them all I/V254 would make all XB programs run from RAM instead of VDP and would speed up all XB programs by quite a bit.

 

I agree with most of the assertion about how it figures it out, but XB relocates PROGRAM images into RAM anyway as long as it's there, so there's no speed difference to be had. I spent a lot of time looking at this when I wrote the code that loads bitmapped images -- although I wrote it for IV/254 files, I also tested against PROGRAM image files and they get moved to CPU RAM.

 

I would not change the loading side at all, that would be exactly the same. But the SAVE side would alway pick I/V254 so evenually all XB programs would be converted from PGM Image to I/V254. This is directly from the XB source code:

 

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

[1947] * OLD STATEMENT

[1948] * A normal load:

[1949] * Get a program from an external device to VDP and

[1950] * reinitialize the program pointers. Also update the line

[1951] * pointer table, since the memory size of the machine on

[1952] * which the program was created doesn't have to be the

[1953] * same as on the current system!!!! Then check if ERAM

[1954] * existed, move it to ERAM if does exist (in relocated

[1955] * from)

[1956] * Load a sequential file:

[1957] * When program is bigger than 13.5K and ERAM exists,

[1958] * maximum-length record reads are preformed to read the

[1959] * file and each record is copied into the ERAM as it is

[1960] * read.

[1961] ***********************************************************

 

So there is a slight speed up vs program Image as a table re write is not needed for the I/V254 files. Also tons of pointers do no not have to be changed and reset after the move.

I does seem real goofy that XB even used the Basic method for loading and saving files, only to stay backwards compatiable. No bonus exists for saving in Program Image format.

Matter of fact from GPL a huge number of factors have to be run. But the prescan in I/V254 seems slower, I will have to look into this.

 

If I understand correctly you have access to the original XB source code? Would you mind sharing or is there some kind of agreement preventing that?

I think getting the source code out there would be a very important step in preserving XB history. And it would be lots of fun taking a peek and learning from the documented source code. :)

 

I am the orginal source of many things you can download from the WHT FTP site. I purchased and gave away the TI Technical Manual to Don O'Neil after I bought it and many others. I sent the TI Extended Basic Source code GROMs and ROMs to many people. And downloaded then to the WHT FTP server, but they do not seem to be there anymore. I searched and they are gone. My SCSI drive died so I lost my only Software copy, and the Hard Copy was loaned to a buddy that his girlfriend set on fire along with his house. Many of the PDFs you see on that site were from my original photo copies I made of let people make.

The only way you can get the source code that is left is RXB V2001 on the site or in CYC or PC99 has the Source code of RXB but all of original XB is still there, just patched by GKXB or my RXB patches. I left the orginal code there by putting * in front to indicate a comment.

Link to comment
Share on other sites

Hi, thanks for the update. It's much appreciated :)

 

ok, I'll search on the WHT FTP site. Perhaps it's still there, sometimes it can be a bit hard to find stuff there and I may have overlooked it.

Don't have access to the CYC and I know that the stuff on there can't be shared so have to respect that.

 

Ok, pushing my luck here ... Have you ever seen the source code of the USCD Pascal system ?

If I'm not mistaking part of it is written in assembly language, part in GPL and another part in USCD Pascal. :)

Link to comment
Share on other sites

Well, I was able to run Classic 99 under Ubuntu using Codeweavers' Crossover Games, and it worked really well except that speech was a little subpar. Pretty nifty! The execution speed is similar to Windows as far as I can tell.

 

Eh, people tell me the speech is pretty subpar anyway, hehe!

 

I'd never heard of Crossover Games before -- is that a free or commercial package? It would be good to offer people an alternative to Wine for Classic99.

Link to comment
Share on other sites

Hi, thanks for the update. It's much appreciated :)

 

ok, I'll search on the WHT FTP site. Perhaps it's still there, sometimes it can be a bit hard to find stuff there and I may have overlooked it.

Don't have access to the CYC and I know that the stuff on there can't be shared so have to respect that.

 

Ok, pushing my luck here ... Have you ever seen the source code of the USCD Pascal system ?

If I'm not mistaking part of it is written in assembly language, part in GPL and another part in USCD Pascal. :)

 

I have seen the Assembly source code of Pascal somewhere, but never the GPL part of Pascal. I thought I saw that on the WHT FTP.

 

Here is the Source code of RXB Version 2001

 

I will release RXB Version 2011 and source when I am done.

MyZipFile1.zip

  • Like 1
Link to comment
Share on other sites

Well, I was able to run Classic 99 under Ubuntu using Codeweavers' Crossover Games, and it worked really well except that speech was a little subpar. Pretty nifty! The execution speed is similar to Windows as far as I can tell.

 

Eh, people tell me the speech is pretty subpar anyway, hehe!

 

I'd never heard of Crossover Games before -- is that a free or commercial package? It would be good to offer people an alternative to Wine for Classic99.

It's commercial unfortunately, although mine came bundled with Crossover Office Pro ($69). I would not recommend buying the standalone version though as it currently supports very few games, and most of what I tried outside of the sanctioned list did not work properly, especially graphically intensive ones. Some of the supported games were WOW, Starcraft 2, StarTrek online, Spore and Half Life. The PlayOnLinux software on the other hand is free and has a much larger list of supported games. I also use Oracle's Virtual Box which allows me to emulate a Win XP environment in a window. Between all of these utilities, I can pretty much run all of my current Windows software under Linux except for some of the games.

Edited by Vorticon
Link to comment
Share on other sites

Here's your modified "classic99.ini" file and new .BIN files. You need to use a hex editor to merge the rxb20012.grm - rxb20016.grm files into a single grom file "RXB2001G.bin". Rxb2001.grm and rxb20011.grm need to be seperate files called RXB2001C.bin and RXB2001D.bin.

 

Whoops forgot to mention the first 6 bytes need to be removed before merging. These bytes also help in figuring out the order of merging the various files.

 

rxb2001.grm FF0A20006000 --> removed and named to <filename>C.bin

rxb20011.grm FF0920006000 --> removed and named to <filename>D.bin

rxb20012.grm FF082000E000 \

rxb20013.grm FF072000C000 \

rxb20014.grm FF062000A000 > removed and merged in the order of rxb20016 + rxb20015 + rxb20014 + rxb20013 + rxb20014

rxb20015.grm FF0520008000 /

rxb20016.grm 000420006000 / (FA5672AE23A3 - yours)(replaced with a working one)

| |

---------------- GRAM/RAM to load - 1st byte - FF next; 00 done

- 2nd byte - 00 RAM; 01-08 GRAM Bank; 09-0A ROM >6000 Bank 0/1

| |

------------ Length

| |

-------- Address

 

(Hope the ASCII art works out here)

 

It also looks like your 20016.grm is corrupt. Not sure if Classic99 supports the ".grm" gram kracker format, need to re-read the docs again. Tursi please jump in and reply if it does.

 

 

OK have been using the RXB 2001 that was sent as a attachement to use RXB in Classic99. But nothing I do works to put GROMs in Classic99.

 

Obviously when looking over your comments everyone just takes for granted I know all this stuff, but of course I do not.

1. How do you remove the header from a File?

2. What hex editor? Where is the Hex editor? Notepad will not open Bin files.

3. How are you combining the files, again with this Hex editor?

 

I have to admit this is confusing as heck. First off everyone here keeps calling XB ROMs GROMs? They are ROMs why are they calling them GROMs?

Also the original method of loading GRAMs or GROMs by GramKracker made a lot more sense then method being suggested.

Seems this method is very complicated to modify for use something already with a built in loading method standard.

All the info was in the first 8 bytes of the file to load it.

You did not need any other data and it works with ANY type of loading AMS, XB, MBX, GRANDRAM, GRAMULATOR, PGRAM, GRAMKRACKER, DSR, VDP, RAM and SuperSpace or SuperCart or all of them.

The Swedish GPL Assembler Package that was for the German GRAM cards could do anything you could think of, this should have been the standard.

Edited by RXB
Link to comment
Share on other sites

OK have been using the RXB 2001 that was sent as a attachement to use RXB in Classic99. But nothing I do works to put GROMs in Classic99.

 

Obviously when looking over your comments everyone just takes for granted I know all this stuff, but of course I do not.

1. How do you remove the header from a File?

2. What hex editor? Where is the Hex editor? Notepad will not open Bin files.

3. How are you combining the files, again with this Hex editor?

 

1. You do not have to remove any headers from any files for Classic99.

2. He is talking about a hex editor on your host system - Windows or Mac or whatever you use. This is an invaluable tool for directly manipulating binary files.

3. You do not need to combine the files for Classic99.

 

I addressed points 1 and 3 in my reply to Torrax, but I guess you didn't see that.

 

Please open the Classic99 documentation - it's a PDF file in your Classic99 install folder. Towards the end of the document you will find a description of the Classic99.ini file. You will need to add a User entry for your custom cartridge.

 

A user entry starts with a User header in square brackets, the word User and a number. The first entry MUST be number 0, and numbers MUST be sequential with no gaps. So, at the end of the file, assuming there are no other User cartridges defined, enter:

 

[user0]

 

Next, to be detected, you MUST specify a name, as Name= followed by the name you want to appear in the Classic99 menu under Cartridges->User. Like so:

 

Name=RXB Test

 

Next, you enter one line for each ROM or GROM file that you want to load for this cartridge. You have to tell Classic99 exactly what the file is and where to put it, Classic99 will ignore any header that may or may not be on the file, except for attempting to detect it. If there is a GRAM-Kracker or other header on the file, you must load to the same address as is in there, otherwise the header can't be detected. (Normally, this is the only way to do it anyway).

 

So, for instance, if you have one 40k GROM file to be loaded at >6000, you would enter:

 

rom0=G|A000|6000|c:\mypath\RXBTEST.GRM

 

As far as I know, RXB requires two bank-switched ROM files just like regular Extended BASIC, they would be specified like so:

 

rom1=C|2000|6000|c:\mypath\RXB_ROMC.BIN
rom2=X|2000|6000|c:\mypath\RXB_ROMD.BIN

 

Rom lines, like the User header, must start with 0 and increment without any gaps. The syntax is:

 

rom#=TYPE|SIZE|LOAD ADDRESS|PATH ON DISK

 

See the manual for the various types. You can have up to 16 ROM files if you have, for example, broken up the GROMs into separate files. Just list each one with the appropriate load address.

 

Alternately, Classic99 can auto-detect the files if they are packed up into V9T9 format and naming convention. For that you do need to combine the files and strip the headers, if present. That's more than I can go into right now, though, you have to be comfortable working on the raw binary files themselves.

 

Also the original method of loading GRAMs or GROMs by GramKracker made a lot more sense then method being suggested. Seems this method is very complicated to modify for use something already with a built in loading method standard. All the info was in the first 8 bytes of the file to load it.

 

I gave you all the facilities you need in the emulator to use that software, specifically because you were having these problems. You don't have to use the mechanisms I have provided, just load whatever that software was and use it. I don't have a GramKracker and Classic99 doesn't emulate it - even if I did I don't have permission to distribute their software. But since I added GRAM emulation for you, there's no reason it shouldn't work.

Edited by Tursi
Link to comment
Share on other sites

Only Basic would be at this disadvantage. The GPL code that selects either Program or I/V 254 is pretty goofy and making them all I/V254 would make all XB programs run from RAM instead of VDP and would speed up all XB programs by quite a bit.

 

I agree with most of the assertion about how it figures it out, but XB relocates PROGRAM images into RAM anyway as long as it's there, so there's no speed difference to be had. I spent a lot of time looking at this when I wrote the code that loads bitmapped images -- although I wrote it for IV/254 files, I also tested against PROGRAM image files and they get moved to CPU RAM.

 

OMG such a simple solution. Address in GROM:

 

>8E56 GT * Not enough memory in VDP

>8E57 BR GSAVE * Go save in I/V 254 format

 

Just change it to this:

 

>8E56 B GSAVE * Go save in I/V 254 format

 

Now it will always load both formats but only save in I/V 254 format.

As for the speed difference a smaller program will always load faster especially as it is loaded as a single chunk.

But still has to have it moved to ERAM and all the pointers change to run properly. I do not think in Classic99 you will see any speed change at all.

 

 

Link to comment
Share on other sites

I have RXB working using the DL that Torrax posted... I can load either 2001 or 2002. If you'd like, I can email you a zipped folder of my working ini and MODS folder... but I'm sure you'll have it up and running in no time flat. =)

 

By the way, I really like the look of the editor in RXB. Much better than the cyan I've been staring at for years. =)

 

Could you still do that. My Gawd all I ever get for all my efforts myelf is a blank Classic99 screen and the debugger does not indicate anything at all is wrong.

 

It says expected file size difference in RXB1 and that is the only indication that it even has the remotest probelm.

 

I do not think the problem is the .ini file as it sees the RXB module but all I get when RXB is loaded is a cyan screen, obviously locked up.

 

Again I will attach the .ini and the RXB files. I have tried 8 versions so far including the originals that are on the CYC CD.

 

I wish I jknew what is going wrong, I have read the docs over and over. I am not a DOS person, I wrote Assembly for older machines but that was before DOS. It was CPM that DOS copied, they changed alot and that was back in 1976.

MyZipFile.zip

Link to comment
Share on other sites

OK have been using the RXB 2001 that was sent as a attachement to use RXB in Classic99. But nothing I do works to put GROMs in Classic99.

 

Obviously when looking over your comments everyone just takes for granted I know all this stuff, but of course I do not.

1. How do you remove the header from a File?

2. What hex editor? Where is the Hex editor? Notepad will not open Bin files.

3. How are you combining the files, again with this Hex editor?

 

1. You do not have to remove any headers from any files for Classic99.

2. He is talking about a hex editor on your host system - Windows or Mac or whatever you use. This is an invaluable tool for directly manipulating binary files.

3. You do not need to combine the files for Classic99.

 

I addressed points 1 and 3 in my reply to Torrax, but I guess you didn't see that.

 

Please open the Classic99 documentation - it's a PDF file in your Classic99 install folder. Towards the end of the document you will find a description of the Classic99.ini file. You will need to add a User entry for your custom cartridge.

 

A user entry starts with a User header in square brackets, the word User and a number. The first entry MUST be number 0, and numbers MUST be sequential with no gaps. So, at the end of the file, assuming there are no other User cartridges defined, enter:

 

[user0]

 

Next, to be detected, you MUST specify a name, as Name= followed by the name you want to appear in the Classic99 menu under Cartridges->User. Like so:

 

Name=RXB Test

 

Next, you enter one line for each ROM or GROM file that you want to load for this cartridge. You have to tell Classic99 exactly what the file is and where to put it, Classic99 will ignore any header that may or may not be on the file, except for attempting to detect it. If there is a GRAM-Kracker or other header on the file, you must load to the same address as is in there, otherwise the header can't be detected. (Normally, this is the only way to do it anyway).

 

So, for instance, if you have one 40k GROM file to be loaded at >6000, you would enter:

 

rom0=G|A000|6000|c:\mypath\RXBTEST.GRM

 

As far as I know, RXB requires two bank-switched ROM files just like regular Extended BASIC, they would be specified like so:

 

rom1=C|2000|6000|c:\mypath\RXB_ROMC.BIN
rom2=X|2000|6000|c:\mypath\RXB_ROMD.BIN

 

Rom lines, like the User header, must start with 0 and increment without any gaps. The syntax is:

 

rom#=TYPE|SIZE|LOAD ADDRESS|PATH ON DISK

 

See the manual for the various types. You can have up to 16 ROM files if you have, for example, broken up the GROMs into separate files. Just list each one with the appropriate load address.

 

Alternately, Classic99 can auto-detect the files if they are packed up into V9T9 format and naming convention. For that you do need to combine the files and strip the headers, if present. That's more than I can go into right now, though, you have to be comfortable working on the raw binary files themselves.

 

Also the original method of loading GRAMs or GROMs by GramKracker made a lot more sense then method being suggested. Seems this method is very complicated to modify for use something already with a built in loading method standard. All the info was in the first 8 bytes of the file to load it.

 

I gave you all the facilities you need in the emulator to use that software, specifically because you were having these problems. You don't have to use the mechanisms I have provided, just load whatever that software was and use it. I don't have a GramKracker and Classic99 doesn't emulate it - even if I did I don't have permission to distribute their software. But since I added GRAM emulation for you, there's no reason it shouldn't work.

 

I have a letter from Crig Miller stating I can use GK XB. As for a Hex Editor you will have to forgive me as I am not a PC DOS person and know very little about it. It is very much like me talking about GRAM devices and you have no clue what I am talking about. So I got the RXB2000 to work but so far nothing I do will get RXB2011 to work. I can load GRAM but will have to write a save program in Assembly as so far none work.

 

So back to the point when you know something you use everyday it is very much different then those that have never worked with something ever. I am most likely the last GPL programmer left.

I would like to make a EA cart that has all the options of selecting and loading any bank of the AMS and changing banks until you do a EXECUTE. For testing AMS programs this would be a big bonus.

The flow chart would look like this:

 

Start of program to us AMS > Put AMS in MAP mode>>>>>Memory area to use 0 to F(0 is >0000 and F is >F000) >>>>>Ask for Banks to use>>> continue to loop asking unless SPACE BAR.

 

As you can selectively load any area of memory(Of course >0000 and >4000 are not possible) you can continue to load willy nilly in any fashion you want to test.

Executing a address will return properly to EA if you use a RTWP and restore the registers at >8300. Actually just save >8300 to >83FF and put it back when done.

This will put you back at the EA cart where you left off as the GROM address is still there and you can execute the next program.

Edited by RXB
Link to comment
Share on other sites

OMG such a simple solution. Address in GROM:

 

>8E56 GT * Not enough memory in VDP

>8E57 BR GSAVE * Go save in I/V 254 format

 

Just change it to this:

 

>8E56 B GSAVE * Go save in I/V 254 format

 

Now it will always load both formats but only save in I/V 254 format.

As for the speed difference a smaller program will always load faster especially as it is loaded as a single chunk.

 

That's actually a pretty cool little hack. :)

 

I'm still unconvinced how valuable it is, but I see your points and I think that you found it is cool!

Link to comment
Share on other sites

As for a Hex Editor you will have to forgive me as I am not a PC DOS person and know very little about it.

 

It's neither PC nor DOS. It's a program that lets you load a file and directly manipulate the bytes in it. I've had one on every system I've ever used, including my TI, but I do a lot of that. :) Also, Google is your friend - search for the term.

 

But again, you don't need it if you are not comfortable doing that level of file manipulation.

 

It is very much like me talking about GRAM devices and you have no clue what I am talking about. So I got the RXB2000 to work but so far nothing I do will get RXB2011 to work. I can load GRAM but will have to write a save program in Assembly as so far none work.

 

I wouldn't say that. I've been programming the TI for thirty years. I know what a GRAM device is. I just never had any serious need of one, and there's no need for one on an emulator save nostalgia or comfort with existing tools, since you can edit and replace the GROMs at will. :)

 

You'll get there, though. It's a bit of a learning curve if you aren't used to text-based configuration files. I'll get the GUI eventually but I'm sure you'll have it down pat before then.

 

So back to the point when you know something you use everyday it is very much different then those that have never worked with something ever. I am most likely the last GPL programmer left.

 

I think you are right there, though I've written bits of GPL code here and there (like the loader for my E/A cartridge conversion tool). I'm about to do my biggest project there, though, so I will probably need a good GPL assembler. Any recommendations?

 

Executing a address will return properly to EA if you use a RTWP and restore the registers at >8300. Actually just save >8300 to >83FF and put it back when done.

 

Try to make it work with a standard B *R11 -- that is the standard for returning to the E/A cart today, so it would be nice not to have two standards.

Link to comment
Share on other sites

Do you mean this:

4.5.7 EXECUTE MACHINE LANGUAGE

XML

Syntax definition: XML IMM

 

Example: LABl XML >05

 

Definition:

Begin execution of 9900 machine language.

Use the IMM field to tell where.

 

Status bits affected: I B I GT I cond I carry I OVF

 

Execution results: Execute 9900 machine language directly.

 

Application Notes: The immediate field of the XML instruction

is split into a left nybble (table number) and

a right nybble (index into table ) . There are 16

table addresses defined in the CPO address space.

See Table 4. 5.1 for a list of these hardcoded values

(note that they have been arranged so as to insure

that at least one table exists in any conceivable

plug-in fast ROM ) . The left nybble specifies wh ich

of the 16 tables to get the Branch address from.

 

The right nybble is then used to determine which

of the 16 addresses in the table to use. Each table

can contain up to 16 2-byte entry-point addresses.

Note that one can have less if one wishes. As an

example of XML,

 

XML >24

causes a branch to the address contained in the

fifth entry of Table 2.

 

Upon entry to a routine, the 9900 workspace

pointer is set to >83EO and the 9900 ST is set to an

unknown value. To return control t o the interpreter,

make sure WP is still >83EO and execute a "B *Rll ft.

GPL execution will continue out of the GROM from

which he XML was seen, at the address specified by

the internal GROM address .

 

To do a keyboard scan in 9900 Assembly Language, do a

BL to a subroutine located at location >OOOE in console

ROM.

 

Op Code: >OF

 

Format type: 2

 

4-55

 

This above is from the GPL Manual and there is no B *R11 in GPL but there is XML to >F0 which is the address at >8300

Or a XML to each area of memory at many of which say Future Expansion like >8000 or >7000, but >2000 and >8300 are fully supported now.

I could not properly cut and paste the XML Table from page 4-56 from the GPL Manual.

As long as >83E0 Workspace for the GPL interpeter is never changed then this would work like a B *R11

 

I am working on the EA Cart AMS support right now and should be done with it within a week or so.

 

Things like RXB new commands like CALL KEYON("yY",5,K,S,Line#,Line#) will take a little longer. (This is like a built in ON GOTO with in CALL KEY with true for first line and false for second line number)

And of course a CALL KEYSUB("Nn",0,K,S,Line#) is a CALL KEY with a built in GOSUB if true. These would speed up XB by quite a bit and cut back the if then else statements.

 

And you can chain them CALL KEYSUB("Nn",0,K,S,1100,"Yy",0,K,S,1500,"",0,K,S,800) the last one would be any key, and no key is pressed then it goes to next statement.

 

I am really surprized no one ever thought of this.

 

By the way I use the Ryte Data GPL Assembler only becuase it is 100% the same as the GPL manual from TI. The others are valid but have some bugs.

Edited by RXB
Link to comment
Share on other sites

This above is from the GPL Manual and there is no B *R11 in GPL

 

There's no RTWP in GPL either, I was directly addressing the comment I quoted. :)

 

I could not properly cut and paste the XML Table from page 4-56 from the GPL Manual.

As long as >83E0 Workspace for the GPL interpeter is never changed then this would work like a B *R11

 

That's okay, I don't need huge quotes... just a reference to the document in case I don't already know it. I've spent a lot of time inside the machine! I have the Cyc and all of WHTech on my hard drive here, so I have quick access to most documentation out there, plus the internet covers a lot of the rest! I even found some articles on GPL you wrote back in the day. ;)

 

I am working on the EA Cart AMS support right now and should be done with it within a week or so.

 

What are the odds it will still fit in a single 6k GROM when you are done? It seems useful for a project I am currently doing.

 

By the way I use the Ryte Data GPL Assembler only becuase it is 100% the same as the GPL manual from TI. The others are valid but have some bugs.

 

Hmm. Don't like buggy tools. Thanks for the suggestion. :)

Link to comment
Share on other sites

This above is from the GPL Manual and there is no B *R11 in GPL

 

There's no RTWP in GPL either, I was directly addressing the comment I quoted. :)

 

I could not properly cut and paste the XML Table from page 4-56 from the GPL Manual.

As long as >83E0 Workspace for the GPL interpeter is never changed then this would work like a B *R11

 

That's okay, I don't need huge quotes... just a reference to the document in case I don't already know it. I've spent a lot of time inside the machine! I have the Cyc and all of WHTech on my hard drive here, so I have quick access to most documentation out there, plus the internet covers a lot of the rest! I even found some articles on GPL you wrote back in the day. ;)

 

I am working on the EA Cart AMS support right now and should be done with it within a week or so.

 

What are the odds it will still fit in a single 6k GROM when you are done? It seems useful for a project I am currently doing.

 

By the way I use the Ryte Data GPL Assembler only becuase it is 100% the same as the GPL manual from TI. The others are valid but have some bugs.

 

Hmm. Don't like buggy tools. Thanks for the suggestion. :)

 

 

Yea only a few GPL articles were published. We had some news letters that went out here in Portalnd but those never got published, do not know anyone that has copies of the P.U.N.N. here.

 

No such thing as a 6K GROM, only 6K chips that TI used. All GROM/GRAM is 8K it was just limited to 6K by hardware. (PROMs were 6K, 8K PROMs were to expensive to use so that is why they were 6K only)

With every device made for GRAM they are all 8K just like every single Emulator for the TI.

 

What project are you doing? Do you need a EA Cart? I had planed to use the AMS routines built into RXB and the Super EA with AMS to just access them but I may have opened up enough space to do that now.

And yea I am pushing the limit of 8K for the EA Cart.

 

And the Ryte Data GPL Assembler is the best GPL Assembler, but is very sparse on tools that RAG or German or Swedish GPL Assemblers have.

Link to comment
Share on other sites

Tursi, you might want to check the GPL Programmers Guide right here in the development resources thread :)

 

What am I checking it for? Somehow my question to RXB got a little off track, I think. :) I was just asking for his opinion of the best GPL assembler - I've been hand-assembling GPL for years. So I'm a bit confused all of a sudden.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...