Jump to content
Tursi

Classic99 Updates

Recommended Posts

OMG, the "Amiga System Programmers Guide", the number one book for me ! Okay, "Hardware" before that. "Libraries and devices" was a monster

 

Oi, I wanted all those reference guides SO badly... had to make do with snippets downloaded from questionable BBSs. ;)

 

I didn't get my first PC until '95 myself... only ran Win 3.1 for about 2 months before my Win95 disk arrived. (Though I was familiar with it from work.)

Edited by Tursi

Share this post


Link to post
Share on other sites

Zip Drives cost money, my friend, something I did not have very much of, as a private in the military! (In fact I never finished paying for that Amiga, I lost touch with the fellow who sold it to me before the last payment, because he was nice enough to make the payments very small and they lasted a long time!).

Meh... I mowed yards for mine, solider ;) There is a funny story to go along with how I nearly got my first Zip drive for Christmas or birthday. If I make it to the Faire I will share it.

 

I don't intend to go back to the Amiga. The reason I finally gave up and bought a PC was so that I could develop for a platform with a large number of users. (And yet I keep writing TI software, hehe.) I haven't even booted my old workbench for a long time now, mostly because I lost most of my software. :/ I still have my BBS though, CNET was awesome. ;)

 

CNet was great for both the Amiga and the C64. Great system. When I wrote my BBS software I had a number of influences: Color64, CNet, Spitfire (DOS), Wildcat (DOS), and another C64 BBS that I cannot remember but was amazing.

 

Anyway. I apologize if this has been asked and answered already, but I suppose you no longer have the source for Ami99.

 

I still have and use my Amigas. My pride and joy is my 4000D with a 50MHz 060 and 152MB of RAM, CD-RW, and a Zip drive. I am working on getting USB in this box. It is also on the network, and has a Picasso IV SVGA card. I have two PPC cards sitting here which do not work, and I expect sometime to send them both off to England for repair to hopefully come up with one good card.

 

Okay, enough of that. I am going to download and play with the newest Classic99. 'night, all!

 

EDIT: My friend reminds me that I did not have my own PC until 2000-ish. And even then it was relegated to being a Internet Connection Sharing box with Windows 98.

Edited by OLD CS1

Share this post


Link to post
Share on other sites

Hehe.. nice. Anyway, sorry, I don't have the original Ami99 code. I didn't have source control until several years after porting it to the PC. It wasn't useful anyway, it had no disk support, it only supported graphics mode 1, no sound, ASCII-only keyboard input, no joystick, no 9901, no timing, and no sprites. Just a 9900 (with plenty of bugs) and a basic implementation of the 9918's default graphics mode.

 

I'm pleased with what it has become though. I'm glad I changed my mind about abandoning it.

Share this post


Link to post
Share on other sites

From the latest classic99 changelog:

 

* Improved debugger support for multi-bank cartridges - most addresses and address ranges will also accept a : at the end to specify a specific ROM bank. Cartridge ROM only for now.

* Changed disassembly history to include cartridge bank when applicable

 

 

Thanks! That will be very useful in my next multi-bank cartridge project. :cool:

Share this post


Link to post
Share on other sites

Normally I like to keep my updates to something I can do in a day or so, but this one set is turning into a pretty big update. Probably I will release shortly (not just yet) without trying to get /everything/ done.

 

But I've been working in a vaccuum, so wanted to say what's being worked on so far.

 

-Some minor bugfixes to FIAD disks

-Major bugfix to DSK image reading

-Minor bugfix to all disk access (this fixes Owen's issue with Wycove Forth)

-VDP and GROM read/write breakpoints

-Fix to bitmap mode character masking

-Fix to 'X' instruction when JMPs are used

-Another 'X' fix to ensure the instruction isn't randomly skipped ;)

-Reorganization of the Debug dialog to make room for future plans

-Fix uninitialized memory tracking for the 32k card

 

The big one is I've been adding memory saving modes - this will replace my old MakeCart program. I finished E/A#5 saving a couple of nights ago - this was for Walid as I promised about 3 years ago that I'd make my program able to create E/A#5 program images for his SkyChart program. ;) Tonight, I finished the saving of 379-style bank-switched cartridges. Still have to add saving of GROM cartridges, and saving TI BASIC restore cartridges like we created for Owen's project!

 

What I like about doing it in Classic99 is that it becomes possible to be very flexible. You can prepare the system any way you like, breakpoint, and make it save off (there are some caveats, it's not /quite/ that simple). It should be quicker and easier than using TI's SAVE utility for E/A#5, and of course the automatic 379 cartridge creator is new. In addition, I've added additional features not available in MakeCart, like automatic saving of VDP memory as well.

 

post-12959-129992927844_thumb.jpg

 

I also want to get the disk dialog coded before release, but I have to say I'm getting tired of writing GUI code, and I still have a lot of work to update the documentation. ;) Anyway.. the next release will hopefully be useful to people!

 

Note: it's not out yet!

Share this post


Link to post
Share on other sites

Normally I like to keep my updates to something I can do in a day or so, but this one set is turning into a pretty big update. Probably I will release shortly (not just yet) without trying to get /everything/ done.

 

But I've been working in a vacuum, so wanted to say what's being worked on so far.

 

-Some minor bugfixes to FIAD disks

-Major bugfix to DSK image reading

-Minor bugfix to all disk access (this fixes Owen's issue with Wycove Forth)

-VDP and GROM read/write breakpoints

-Fix to bitmap mode character masking

-Fix to 'X' instruction when JMPs are used

-Another 'X' fix to ensure the instruction isn't randomly skipped ;)

-Reorganization of the Debug dialog to make room for future plans

-Fix uninitialized memory tracking for the 32k card

 

The big one is I've been adding memory saving modes - this will replace my old MakeCart program. I finished E/A#5 saving a couple of nights ago - this was for Walid as I promised about 3 years ago that I'd make my program able to create E/A#5 program images for his SkyChart program. ;) Tonight, I finished the saving of 379-style bank-switched cartridges. Still have to add saving of GROM cartridges, and saving TI BASIC restore cartridges like we created for Owen's project!

 

What I like about doing it in Classic99 is that it becomes possible to be very flexible. You can prepare the system any way you like, breakpoint, and make it save off (there are some caveats, it's not /quite/ that simple). It should be quicker and easier than using TI's SAVE utility for E/A#5, and of course the automatic 379 cartridge creator is new. In addition, I've added additional features not available in MakeCart, like automatic saving of VDP memory as well.

 

post-12959-129992927844_thumb.jpg

 

I also want to get the disk dialog coded before release, but I have to say I'm getting tired of writing GUI code, and I still have a lot of work to update the documentation. ;) Anyway.. the next release will hopefully be useful to people!

 

Note: it's not out yet!

 

 

Is this Cartridge Creator only for ROMs, as I am the only GPL programmer I know of it would be nice to have some access to what you are doing, I do Assembly sometimes but only when GPL needs the speed for something. After all Assembly is a real pig for memory.

 

The idea for RXB was to make a Cartridge that can do it all. Only thing missing is a Format Disk routine but everything else you can think of is there. Great job by the way on Classic99, I am still working with PC99 right now as not figured out how to get RXB into Classic 99 yet. Getting GPL object code into a Emulator is almost impossible as no thought of such a thing ever occurred to the Emulator people.

Edited by RXB

Share this post


Link to post
Share on other sites

 

The big one is I've been adding memory saving modes - this will replace my old MakeCart program. I finished E/A#5 saving a couple of nights ago - this was for Walid as I promised about 3 years ago that I'd make my program able to create E/A#5 program images for his SkyChart program. ;)

What?! So soon??? Thanks man! I'm going to try it out as soon as I get a chance this week. I have to admit that with all the goodies included in Classic 99, I'm having a much harder time justifying developing on real hardware... The debugger itself is worth its weight in gold!

Share this post


Link to post
Share on other sites

Oh sir, thou art incredibly groovy!

 

<from underneath table>

Any idea when you will look at the system timing/speech core? :D

Share this post


Link to post
Share on other sites
Is this Cartridge Creator only for ROMs, as I am the only GPL programmer I know of it would be nice to have some access to what you are doing, I do Assembly sometimes but only when GPL needs the speed for something. After all Assembly is a real pig for memory.

 

How do you distribute your GPL code? Did you see my GROM simulator? (Drop your GPL code onto an AVR and go... I mean to make up some PCBs here eventually..)

 

The cartridge creator function can save as E/A #5 PROGRAM image files, 379-style bank switched ROMs, and GROM (either 6k or 8k versions). All save versions save and restore RAM only so require a 32k console to run on.

 

Getting GPL object code into a Emulator is almost impossible as no thought of such a thing ever occurred to the Emulator people.

 

Um.. I don't think you read the documentation. If you name your GROM file with the V9T9 convention (NAMEG.BIN), and it loads at >6000, you can just select Cartridge->User->Open. If it loads anywhere else or you don't want to go through the file selector every time, just add it as a User cart in the Classic99.ini file -- the documentation will show you what to do, but something like this:

 

[user1]

Name=My GROM Cart

G|6000|1800|Mods\MyGromCart.Bin

Share this post


Link to post
Share on other sites
What?! So soon??? Thanks man! I'm going to try it out as soon as I get a chance this week. I have to admit that with all the goodies included in Classic 99, I'm having a much harder time justifying developing on real hardware... The debugger itself is worth its weight in gold!

 

hehe. Thank you! I do consider it a bit of a success that I very rarely have to hack the emulator itself when I'm hacking away on the TI anymore - I used to all the time. They say when the programmer uses a tool it makes a better tool. I hope that's true!

 

That email about the save program stuff has sat at the top of my Inbox since it was posted. It's nice to finally clear it as done. ;)

 

I finished all the save modes last night, now on to some other annoying GUI work. And just so you all understand the sacrifice, it's a damn nice weekend outside, hehe.

 

Any idea when you will look at the system timing/speech core?

 

It's climbing in priority. It's another major project though, and it's hard to get solid blocks of time (I should not be using the ones I am right now, really.) Disk always had priority over it, and Disk isn't quite done yet.

 

Anyway, it's the VDP core rewrite that you need to watch for. I will be redoing the VDP core and recentering the timing around the VDP scanlines, that will enable me to fix some of the currently unsolvable issues in timing and particularly speech, it'll also let me get audio DAC emulation back in and many other little improvements. (Right now all timing is based on CPU cycles, which means when the CPU is halted, such as by a full speech FIFO, the entire system falls apart. I tried a few times to hack around that with no real success).

Share this post


Link to post
Share on other sites

 

... The idea for RXB was to make a Cartridge that can do it all. Only thing missing is a Format Disk routine but everything else you can think of is there. ...

 

If you can get the Format Disk routine in there, it'll do almost anything XB v2.5 can do. ;)

 

Not being real familiar with RXB, can it Read/Write sectors?

 

Tony

 

 

Yea I have CALL SECTOR(pathname,R/Wflag,#sectors,sectorstring)

 

pathname = "DSK1." or "SCS1." or "SCS1.DIR.ADIR.BDIR.CDIR" the pathname can be up to 255 long, but WSD only handles up to 39, on the SCSI I have directorys up to 4 deep.

R/Wflag = 0 is Write and any other number is read.

#sectors = 1 to 32 sectors, but uses the lower 8K as a buffer so with the AMS you can buffer the entire DSDD disk to the AMS for multiple copies. I have a RXB program that does this.

Sector string handles a hex string from "0000" to "FFFFFFFF" so this is way past the address values of the TI as I was thinking ahead of any hardware the comes out. (Nothing worse then being obsolete 3 weeks after release)

 

I may add a change to SECTOR to handle numbers or strings for sector but the problem is when you go over 32767 in the TI you go back to zero so that is why it uses only sector strings in hex. I always stay in the TI frame work of design.

Edited by RXB

Share this post


Link to post
Share on other sites
Is this Cartridge Creator only for ROMs, as I am the only GPL programmer I know of it would be nice to have some access to what you are doing, I do Assembly sometimes but only when GPL needs the speed for something. After all Assembly is a real pig for memory.

 

How do you distribute your GPL code? Did you see my GROM simulator? (Drop your GPL code onto an AVR and go... I mean to make up some PCBs here eventually..)

 

The cartridge creator function can save as E/A #5 PROGRAM image files, 379-style bank switched ROMs, and GROM (either 6k or 8k versions). All save versions save and restore RAM only so require a 32k console to run on.

 

Getting GPL object code into a Emulator is almost impossible as no thought of such a thing ever occurred to the Emulator people.

 

Um.. I don't think you read the documentation. If you name your GROM file with the V9T9 convention (NAMEG.BIN), and it loads at >6000, you can just select Cartridge->User->Open. If it loads anywhere else or you don't want to go through the file selector every time, just add it as a User cart in the Classic99.ini file -- the documentation will show you what to do, but something like this:

 

[user1]

Name=My GROM Cart

G|6000|1800|Mods\MyGromCart.Bin

 

Thanks for reply.

 

Can I use RXB in the GROM Simulator and use the AMS at the same time as all the commands for AMS are built into RXB, AMSPASS, AMSOFF, AMSON, AMSMAP, AMSINIT, AMSBANK?

 

Ok let me explain about getting GPL code into a Emulator. On a real TI99/4A I use RYTE GPL ASSEMBLER to create GPL Compressed Object code. Then I use GPL*LOADER by Marty Kroll to load that Object into GRAM then use the GRAM device to save the Cartridge.

Do you see the problem? NO EMULATOR ALOWS WRITING TO GRAM OR DO SAVE GRAM FILES EXIST AS NO GRAM DEVICES EXIST. You can not load into what does not exist to something else that does not exist to save with. No GRAM device exists.

So I get stuck at the Object code and no way to put it into Cartridge format. So unless I get my PGRAM fixed I am now forced to take the List file and type in hundreds of thousands of bytes one at a time into a sector program to re-write the old cartridge into the new one that can be used.

 

This is a little short sighted on the part of all emulators as RYTE DATA and MILLER GRAPHICS were some of the very first companies to exist as third party for the TI99/4 and TI99/4A. Cartridge creators are what made the TI popular in the first place I bought my TI in 1983 for that reason.

 

I love the looks and feel of Classic99, I just need to work with it more as it does not explain to my understanding how to do things in it, maybe I am just thick. I do have learning disablities in some ways. I read to learn so documentation has to be very good for me.

I have never used V9T9 but use PC99, that may be why I have problems with .bin? Do I just tack that onto the GRAM file name and good to go? As when I tried that it crashed Classic99.

Share this post


Link to post
Share on other sites

Classic99 is capable of a whole lot and I'm sure Tursi can work this out, if it is not already available. But as an aside note, (and while I don't use it at all except for occasional Geneve emulation) the Multi-emulator MESS emulated the GRAM Kracker, assuming there is no other option.

 

Compared to Classic99, MESS is a jumbled up "mess" of bad design principles. Classic99 is a clean, swift, actively supported emulator which is the best available for 99.999 % of purposes. I only mention the other emulator because it emulates a GRAM device.

Share this post


Link to post
Share on other sites

Classic99 is capable of a whole lot and I'm sure Tursi can work this out, if it is not already available. But as an aside note, (and while I don't use it at all except for occasional Geneve emulation) the Multi-emulator MESS emulated the GRAM Kracker, assuming there is no other option.

 

Compared to Classic99, MESS is a jumbled up "mess" of bad design principles. Classic99 is a clean, swift, actively supported emulator which is the best available for 99.999 % of purposes. I only mention the other emulator because it emulates a GRAM device.

 

 

Thanks I have never given MESS much of a shot at use as you are right it is a MESS to work with from the looks of the docs.

 

You have to admit is is odd that GRAM is not supported as there were like 70 companies making Carts or GRAM devices for the TI.

Where do you think all those cartidges came from?

 

The only reason why Assembly became popular is you did not need a license to use it, but to use GPL you had to purchase a license from TI and the GPL package.

I started GPL after the license requirement was dropped by TI, and got Miller Graphics (Craig Miller) to give me permission to use any products they made as my own.

(Still have the letter from Crig Miller)

 

Also the Classic99 is very clean and good looking. I just need to work with it more. I wish it had 80 column support as GPL like Assembly is much better in 80 columns.

Presently I can take text and round about put it into .dsk and run the GPL Assembler, just stuck at getting the object code into GRAM with no GRAM devices.

Share this post


Link to post
Share on other sites

We like to use Notepad++ and assemble using Classic99. :) 80 column editors?? How about complete and total freedom with Notepad++ and syntax coloring using Classic99 as an assembler? :) It accepts .txt suffixes. I do all my assembly this way.

 

As to your other comments/questions, Tursi will have to address them, as I am not an expert. Good luck!!!

Share this post


Link to post
Share on other sites

Ok I am at my wits end. I did everything for the last 4 hours to get my GROM files to work with Classic99. They work in TI994aW and PC99 but for the life of me can not get it to work in Classic99?

 

What the heck am I doing wrong?

 

I had included a Zip of the Classic99.ini and the GROMs by changing the .GRM to .BIN but it just ignores everything I do.

 

Any help please as I would really like to start using Classic99 and drop using PC99 as I have to use it in a Virual PC Windows 98 system.

MyZipFile.zip

Edited by RXB

Share this post


Link to post
Share on other sites

The best I can do is quote the Classic99 manual pp.33 and 34: Hope this helps... if not, Tursi can inform you better. =)

 

rom0 string (0-15 for a total of 16 ROMs per cartridge)

Contains notes for loading the cartridge. This is a pipe-limited row of data, formatted like so:

T|AAAA|LLLL|filename

T is the single character ROM type. Most carts only use G, C and X types.

C CPU ROM

D DSR ROM

E DSR ROM bank 2 (used for p-code)

G GROM*

P P-Code GROM

R CPU RAM - this is loaded like CPU ROM but is not flagged as read-only!

S Speech ROM

V VDP RAM

X XB Bank 2 ROM (called 'D' in V9T9 notation)

A AMS memory, RLE encoded (NOT WORKING CORRECTLY)

K Paste string for the keyboard after boot (to autostart tasks, not a filename)

3 Packed banks with a '379 style decoder. Similar to XB style but more banks and

all in one file. Note that this assumes a load at >6000, so you are specifying

the offset in the banking space, with bank 0 at >0000, bank 1 at >2000, etc.

SuperSpace carts (CRU >400) can be loaded this way for now, too, but will

likely split them up later. Max size is 64k.

(* GROM is special - to support multiple GROM bases, you can now load GROMs into different

memory bases - up to 16 of them! By default, GROMs load into memory base 0. Append a hex

number 1-F after the G to specify a different base (like: G1). The console will detect these and

add them to the start menu! Note that not all GROMs will work at alternate bases. Also note, in

the real console, the console GROMs appear at all bases, so you can't load alternate bases at

less than >6000. Classic99 does not support using this with cartridges that include CPU ROM.

Each GROM base is offset 4 from the previous, ie: GROM Read is >9800, >9804, >9808, etc.)

AAAA - load address in hexadecimal

LLLL - length of data in hexadecimal (will override actual size of file)

filename - filename on disk to load

This system supports both raw ROM files, and ROM files with a 6 byte GRAM Kracker style

header. The header is detected by checking if the first byte is >00 or >FF, and if the 5th and 6th

bytes represent the load address. The header will be ignored if detected - the data in this INI file

is considered authoritative.

Share this post


Link to post
Share on other sites

Rich is lookig for a way to load OBJECT code, not an image file.

I'm pretty sure he's the only guy actually assembling actual GPL code any longer.

 

Obviously I've never seen GPL object code.. :) I assumed the output of any GPL assembler would be the raw GPL bytes. "Object code" is not always a format that requires further linking, especially on older systems, so coming in from the outside it's easy to draw the wrong conclusion.

 

If you tell me a bit about the format I can tell you how hard a loader would be. But it appears the reason no "emulator people" have thought about it is that it's not especially well known that yet another file format exists. ;)

Share this post


Link to post
Share on other sites
Ok let me explain about getting GPL code into a Emulator. On a real TI99/4A I use RYTE GPL ASSEMBLER to create GPL Compressed Object code. Then I use GPL*LOADER by Marty Kroll to load that Object into GRAM then use the GRAM device to save the Cartridge. Do you see the problem? NO EMULATOR ALOWS WRITING TO GRAM OR DO SAVE GRAM FILES EXIST AS NO GRAM DEVICES EXIST. You can not load into what does not exist to something else that does not exist to save with. No GRAM device exists.

 

I'm starting to figure you guys out! :) Classic99 used to allow writing to GROM, but I disabled it in the early days because nobody needed it, and some programs would write to GROM when they crashed, corrupting it. I guess I see three options from my point of view:

 

1) allow writing to GRAM to make the GPL*LOADER work

2) allow Classic99 to understand the "GPL Object Code" format and load it directly as if it were GROM

3) write an external linker that converts the GPL Object code to an image file in one step

 

This is a little short sighted on the part of all emulators as RYTE DATA and MILLER GRAPHICS were some of the very first companies to exist as third party for the TI99/4 and TI99/4A. Cartridge creators are what made the TI popular in the first place I bought my TI in 1983 for that reason.

 

I understand now what you are saying, but I think it's unfair to call it short sighted. I've been in the TI community as a programmer since '83 myself and I never knew there was a GROM object file format that required an additional linker step. It's just not super well known, probably because so few people programmed in GPL. (I've hand-assembled all the GPL I've done myself!)

 

I love the looks and feel of Classic99, I just need to work with it more as it does not explain to my understanding how to do things in it, maybe I am just thick. I do have learning disablities in some ways. I read to learn so documentation has to be very good for me.

 

Nah, we're still here to try and help you through. Nobody else has read the docs anyway. ;)

 

I have never used V9T9 but use PC99, that may be why I have problems with .bin? Do I just tack that onto the GRAM file name and good to go? As when I tried that it crashed Classic99.

 

Until I get more information it will be hard for me to say, let's piece it together!

Share this post


Link to post
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.

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...