Classic99 Updates

[Tursi]

Classic99 v351

 

-Added SRAM to MPD

-Fix FIAD disk paths to always end with backslash

-Make MPD repair broken configuration bytes

-Fix lockup problem after browsing a disk folder

-Added TurboForth

-Numerous tweaks to P-Code card, still doesn't work. I don't think I have disk images for this!

-Updated long filename support - open as IV0 to get long filenames

 

http://harmlesslion.com/software/classic99

 

TF was the main reason for the release. But I also wanted to tweak the long filename support before anyone tried the old system.

[+retroclouds]

Thanks for the update Tursi

 

By the way, the disk images for the P-Code Card can be found in the development resources thread.

[Tursi]

Thanks for the update Tursi

 

By the way, the disk images for the P-Code Card can be found in the development resources thread.

 

Thanks! Grabbed them.

[+retroclouds]

Quick question: Would you consider adding a checkbox to the debugger called "Halt on bank-switch" ?

Probably something similar could be done by setting a range breakpoint for a write to >6000->7FFF for a specified bank.

But I l'd like to halt the program each time it's about to switch to another bank.

[Tursi]

Quick question: Would you consider adding a checkbox to the debugger called "Halt on bank-switch" ?

Probably something similar could be done by setting a range breakpoint for a write to >6000->7FFF for a specified bank.

But I l'd like to halt the program each time it's about to switch to another bank.

 

Yep, that will work. Just use a write breakpoint to ROM:

 

>(6000-7FFF)

 

That will breakpoint every time it's going to change.

 

For a particular bank, you should be able to use:

 

(6000-7FFF)=1

 

Replace '1' with the bank write you want to trap.

[+retroclouds]

Thanks Tursi, excellent!

[+Vorticon]

Classic99 v351

 

-Added SRAM to MPD

-Fix FIAD disk paths to always end with backslash

-Make MPD repair broken configuration bytes

-Fix lockup problem after browsing a disk folder

-Added TurboForth

-Numerous tweaks to P-Code card, still doesn't work. I don't think I have disk images for this!

-Updated long filename support - open as IV0 to get long filenames

 

http://harmlesslion.com/software/classic99

 

TF was the main reason for the release. But I also wanted to tweak the long filename support before anyone tried the old system.

Ahhh.... There is actually some life to the P-Code project in Classic 99. Excellent!

By the way, where can I find documentation for Turbo Forth? I have a couple of Forth books, but I'd like some kind of user manual specific to TF itself...

[Tursi]

I'm not sure if Mark is done his documentation for TurboForth yet, but search these very forums for plenty of starter information and recommended books on Forth.

[Tursi]

-Changed palette (not final yet)

-Added CLOCK device support

-Made Ctrl-Alt-Reset configurable

-Fixed Long Filename and >127 file option check boxes in file dialog

-Made disk path dialog box quote tolerant

-Fixed text entry/browse button when changing drive type

-Fixed Speech checkmark in menu to reflect configuration

-Fixed spelling of Help->Known issues

-Implemented by-sector file reads on disk images (not fully tested)

-Implemented PC99 disk image reading

-Fix crash bug getting file status on a non-existant file

-Removed unused code and fixed comments in ClipboardDisk.cpp

-Fixed manual so you can copy and paste from it (I think!)

 

http://harmlesslion.com/software/classic99

[OX.]

Tursi, could you set the Classic99 application window to focus? I would like to use it in the Gamebase TI-99/4A project and need the app window to focus on startup so I'm able to issue keyboard/menu commands using sendkeys.

 

OX.

[Willsy]

I'm not sure if Mark is done his documentation for TurboForth yet, but search these very forums for plenty of starter information and recommended books on Forth.

 

Indeed. The book is coming along nicely. In the meantime, people should check out the TurboForth mailing list over at YahooGroups for support. There's currently 38 members over there!

 

Mark

[Tursi]

Tursi, could you set the Classic99 application window to focus? I would like to use it in the Gamebase TI-99/4A project and need the app window to focus on startup so I'm able to issue keyboard/menu commands using sendkeys.

 

OX.

 

While I've noticed and dislike the focus issue, I don't have any explanation for why it happens.

 

I had a mechanism in Classic99 for automatically sending keys as part of a cartridge definition in the INI, though I just tried it and due to some refactoring it doesn't currently work. But if you tell me how you are setting up the temporary ROMs, it'd be easy to fix. If you are creating a Classic99.ini to define the ROMs and disks to load, it's even easier. How does your setup work?

[OX.]

Tursi, could you set the Classic99 application window to focus? I would like to use it in the Gamebase TI-99/4A project and need the app window to focus on startup so I'm able to issue keyboard/menu commands using sendkeys.

 

OX.

 

While I've noticed and dislike the focus issue, I don't have any explanation for why it happens.

 

I had a mechanism in Classic99 for automatically sending keys as part of a cartridge definition in the INI, though I just tried it and due to some refactoring it doesn't currently work. But if you tell me how you are setting up the temporary ROMs, it'd be easy to fix. If you are creating a Classic99.ini to define the ROMs and disks to load, it's even easier. How does your setup work?

 

I'm currently sending command line parameters with MESS for setup & disk or cart image path, then depending on which loading system a game needs to run from disk I issue the loading sequence via sendkeys (hence the need to focus on startup), this is all issued via a GEMUS script along with each particular loading sequence assigned to each game stored in an access database.

 

So it needs to know:-

 

A. The system required to load, ie, E/A assembler cart, Extended basic, Basic or Special (a way to load & run excessive memory games to expanded memory - typically ex tape games)

 

B. The Disk or Cart path

 

C. The Key-Sequence to load the given game, ie: OLD DSK1.GAME1{ENTER}[15]RUN{ENTER}

 

If it is possible to build a Classic99.ini file on the fly before each game execution with the above info then I should be able to get it to work, however all the previous setup for MESS is already done so I was just wondering if Classic99 could be used with the current Gamebase setup in the same way that MESS is used?

 

Here is a link to a Beta setup to give you some idea of the project - http://www.megaupload.com/?d=2N3IS79B

 

OX.

[Tursi]

Well, Classic99 doesn't have any command line support at the moment, so your existing method won't really work as-is anyway. Nor am I likely to support MESS command-line syntax, so you'd have to change your scripts anyway.

 

It's up to you, let me know what you need. Classic99 doesn't need the disk commands either, you can load files directly into RAM on startup. That's how Super Space Acer in the games section works - it's a disk game

 

The best way for Classic99 would be to create a temporary config file (not necessarily Classic99.ini, maybe something that is JUST the ROM entry section). This can contain the ROM, RAM, keypresses, and disk (I'd have to add the disk type). Then just specify it on the command line and I'll have the loader load it as well. Shouldn't be too hard to make that work.

 

Alternately, we use the RPK format from MESS, since I was going to add support for that anyway, and extend it to support all of Classic99's memory types (also was going to do that anyway).

 

Though I'm curious why you are suddenly changing from MESS to Classic99?

Edited May 23, 2011 by Tursi

[OX.]

Well, Classic99 doesn't have any command line support at the moment, so your existing method won't really work as-is anyway. Nor am I likely to support MESS command-line syntax, so you'd have to change your scripts anyway.

 

It's up to you, let me know what you need. Classic99 doesn't need the disk commands either, you can load files directly into RAM on startup. That's how Super Space Acer in the games section works - it's a disk game

 

The best way for Classic99 would be to create a temporary config file (not necessarily Classic99.ini, maybe something that is JUST the ROM entry section). This can contain the ROM, RAM, keypresses, and disk (I'd have to add the disk type). Then just specify it on the command line and I'll have the loader load it as well. Shouldn't be too hard to make that work.

 

Alternately, we use the RPK format from MESS, since I was going to add support for that anyway, and extend it to support all of Classic99's memory types (also was going to do that anyway).

 

Though I'm curious why you are suddenly changing from MESS to Classic99?

 

By ROM do you mean the System Rom, ie: Ext-Basic, E/A Assembler and by RAM do you mean the program to execute? If so then your suggestion for a temp config file would probably work, I don't know if you have a current methodology for parsing keypresses but I'm currently using this - http://www.bu22.com/wiki/gemus_script_reference/functions/run_emulator_send_keys via the gamebase frontend which I'm sure is compatible with the SendKeys() method syntax.

 

So if all's well then my next question is when?

 

Oh and the reason for adding Classic99 - it's nicer. Dedicated emulators are always better, the things stopping me using it in the project previously was the disk support (now added) and the startup/loading issues with Gamebase.

Edited May 24, 2011 by OX.

[Tursi]

Well, I make it a rule not to add support for third party apps, mostly because I don't have the time to support the code I do write, I don't want to take on code bases that I did not write. So I can't help you much with Gamebase.

 

When is a fine question, but I am not 100% clear on what yet. If you are telling me that I have free reign, then I have an idea that is in line with the plans (and I addressed it above - the RPK packages), that just leaves the question as to whether you can provide RPKs?

 

To be clear: your end goal is that the loaded game executes, right?

 

Alternately, if you just want bare minimum-works-now (almost), then just make your script build a Classic99.ini with a UserRom0 section before it loads (and any disk image needed configured as DSK1), and use a ROMx line with the 'K' type to send the keypresses you need. No command line needed in that case, and I'll fix 'K' for the next release. Just leave the config elements you don't want to touch out of the INI, and Classic99 will use defaults. I can build you an example if you like.

[sometimes99er]

-Changed palette (not final yet)

First of all thanks for updates and support on your emulator.

 

The change to the "cyan" color is a bit drastic (to me), but I guess one gets used to it. Now my game in development seems to have gotten a bit of "green acid" in the "light yellow" color (at least when you put them up like I do below). Old versions to the left. Just for your information.

 

 

[OX.]

Well, I make it a rule not to add support for third party apps, mostly because I don't have the time to support the code I do write, I don't want to take on code bases that I did not write. So I can't help you much with Gamebase.

 

When is a fine question, but I am not 100% clear on what yet. If you are telling me that I have free reign, then I have an idea that is in line with the plans (and I addressed it above - the RPK packages), that just leaves the question as to whether you can provide RPKs?

 

To be clear: your end goal is that the loaded game executes, right?

 

Alternately, if you just want bare minimum-works-now (almost), then just make your script build a Classic99.ini with a UserRom0 section before it loads (and any disk image needed configured as DSK1), and use a ROMx line with the 'K' type to send the keypresses you need. No command line needed in that case, and I'll fix 'K' for the next release. Just leave the config elements you don't want to touch out of the INI, and Classic99 will use defaults. I can build you an example if you like.

 

Most of the carts in the project are separate .bin files, eg gameC.bin gameG.bin game.gpl etc .. and the disks are mostly in V9T9 format, so can't really supply rpk's unless I do a lot of converting.

 

Yes, the end goal of the project is to pass the file path(s) to load and execute the game.

 

If you could build me an example cut down .ini with the necessary fields and 'K' type to execute keypresses that would be great.

 

Thanks, OX.

Edited May 25, 2011 by OX.

[Tursi]

-Changed palette (not final yet)

The change to the "cyan" color is a bit drastic (to me), but I guess one gets used to it.

 

The palette is not final, but the change on some colors is rather drastic.

 

I don't have good color vision myself. But, I compared a replacement palette proposed here on AtariAge in another base to the current Classic99 palette to my real TI on my development TV, and kept most of the new colors as looking closer. However, quite a number of the new colors are still wrong even to my eyes.

 

I'm heading to a convention in Pittsburgh in late June where I'll be sharing a room with two digital artists. So I'm planning to take my TI, and will have them compose a proper RGB palette for me. The problem with most of the existing palettes is they are based on the 9918 datasheet, which doesn't take into account the video output circuitry nor a television's input circuitry. In the real world, colors vary some because of all this, but I'll try to get Classic99 to match at least one real world case. (Once I have that, I can update my image converter to hopefully get better color reproduction against real machines).

[Tursi]

Most of the carts in the project are separate .bin files, eg gameC.bin gameG.bin game.gpl etc .. and the disks are mostly in V9T9 format, so can't really supply rpk's unless I do a lot of converting.

 

Depending on how smart your script is... I figured all you had to do was copy a lot of the files to a ZIP, if it can make zips. But in fairness, I don't expect to get RPK support real soon.

 

So, I fixed the keyboard paste from the INI, and built you a few examples. In this archive are examples of loading a cartridge, a TI BASIC program, two Extended BASIC examples, and an Editor/Assembler example. The E/A example uses a V9T9 disk image, the BASIC examples use files on the disk, and the cartridge example doesn't use any disk files, just the cartridge ROMs.

 

In each folder, besides the game itself, is Classic99 and a Classic99.ini tailored to that example. Just extract the whole RAR to a temporary folder, and run the Classic99.exe in each folder to see it start. You'll see that Classic99.ini is pretty minimal... even the joystick section is optional, but I put it there because you might want to let the joysticks be configurable in your front-end, otherwise they'll always default to the settings shown, that is, keyboard for joystick 1 and first PC joystick for joystick 2.

 

Please forgive the double-compression on the file. I used a solid RAR archive to keep file size down (this way the Classic99.exe is only effectively included in the archive once), but the AA forums refuse to accept RAR, so I wrapped it in a ZIP.

 

Classic99_Examples.zip

 

(note: the Classic99 included has the keyboard paste fixes, which I have to go upload now, so the INIs won't work with older versions).

[Tursi]

Classic99 v353

 

-Tweaking video code to try and better save audio (note: video record may be broken now)

-Fix Keys ROM type in INI file and add Other for easier cartridge loading

-Faster keyboard paste

-Fix Window focus on startup

 

http://harmlesslion.com/software/classic99

[OX.]

Most of the carts in the project are separate .bin files, eg gameC.bin gameG.bin game.gpl etc .. and the disks are mostly in V9T9 format, so can't really supply rpk's unless I do a lot of converting.

 

Depending on how smart your script is... I figured all you had to do was copy a lot of the files to a ZIP, if it can make zips. But in fairness, I don't expect to get RPK support real soon.

 

So, I fixed the keyboard paste from the INI, and built you a few examples. In this archive are examples of loading a cartridge, a TI BASIC program, two Extended BASIC examples, and an Editor/Assembler example. The E/A example uses a V9T9 disk image, the BASIC examples use files on the disk, and the cartridge example doesn't use any disk files, just the cartridge ROMs.

 

In each folder, besides the game itself, is Classic99 and a Classic99.ini tailored to that example. Just extract the whole RAR to a temporary folder, and run the Classic99.exe in each folder to see it start. You'll see that Classic99.ini is pretty minimal... even the joystick section is optional, but I put it there because you might want to let the joysticks be configurable in your front-end, otherwise they'll always default to the settings shown, that is, keyboard for joystick 1 and first PC joystick for joystick 2.

 

Please forgive the double-compression on the file. I used a solid RAR archive to keep file size down (this way the Classic99.exe is only effectively included in the archive once), but the AA forums refuse to accept RAR, so I wrapped it in a ZIP.

 

Classic99_Examples.zip

 

(note: the Classic99 included has the keyboard paste fixes, which I have to go upload now, so the INIs won't work with older versions).

 

Excellent, thanks Tursi - going to have a play now and get it to meld with Gamebase.

 

Update - Ive got it working with the carts and tried a few, but want to know if the rom type, load address & data length fields for the rom bank are absolutely needed in the [userCart] section - or if I left them blank would Classic99 read each rom file & auto-set the values the way MESS does? I know if the roms were supplied in an .rpk this would'nt be a problem but all the cart entries in Gamebase are seperate rom files per cart, It would mean having to add an extra entry for every cart and I would'nt know what values each would need.

Edited May 26, 2011 by OX.

[Tursi]

Update - Ive got it working with the carts and tried a few, but want to know if the rom type, load address & data length fields for the rom bank are absolutely needed in the [userCart] section - or if I left them blank would Classic99 read each rom file & auto-set the values the way MESS does? I know if the roms were supplied in an .rpk this would'nt be a problem but all the cart entries in Gamebase are seperate rom files per cart, It would mean having to add an extra entry for every cart and I would'nt know what values each would need.

 

They are absolutely needed, but MESS is not doing anything smart with the files - they are identified by filename. You can probably do the same.

 

The length is always the actual length of the file. If you can't determine this with your front end, just set the maximum length. Classic99 will complain if the file is smaller but that's only in the debug log, the user won't see it. The max length for ROMs is 2k, and for GROMs it's 40k.

 

All V9T9-style cartridge ROM types have a load address of >6000, so you can hard code that.

 

So:

 

If the type is C.BIN, the ROM type in the INI is 'C', the load address is 6000 and the maximum length is 2000.

If the type is D.BIN, the ROM type in the INI is 'X', the load address is 6000 and the maximum length is 2000.

If the type is G.BIN, the ROM type in the INI is 'G', the load address is 6000 and the maximum length is A000.

 

There aren't any other types in the standard V9T9 scheme, though Classic99 supports 3.BIN as an extension for Jon Guidry-style carts. For those the load address is 0000 and the maximum length is 20000 - though I don't expect you will come across any.

 

So if your front end can tell the file by name, you can write it like that. If you can't, Classic99 already has code for autodetect, I can add an autodetect mode to the INI too (it defeats the INI's purpose in most cases, but is fine here) -- so let me know.

[OX.]

Update - Ive got it working with the carts and tried a few, but want to know if the rom type, load address & data length fields for the rom bank are absolutely needed in the [userCart] section - or if I left them blank would Classic99 read each rom file & auto-set the values the way MESS does? I know if the roms were supplied in an .rpk this would'nt be a problem but all the cart entries in Gamebase are seperate rom files per cart, It would mean having to add an extra entry for every cart and I would'nt know what values each would need.

 

They are absolutely needed, but MESS is not doing anything smart with the files - they are identified by filename. You can probably do the same.

 

The length is always the actual length of the file. If you can't determine this with your front end, just set the maximum length. Classic99 will complain if the file is smaller but that's only in the debug log, the user won't see it. The max length for ROMs is 2k, and for GROMs it's 40k.

 

All V9T9-style cartridge ROM types have a load address of >6000, so you can hard code that.

 

So:

 

If the type is C.BIN, the ROM type in the INI is 'C', the load address is 6000 and the maximum length is 2000.

If the type is D.BIN, the ROM type in the INI is 'X', the load address is 6000 and the maximum length is 2000.

If the type is G.BIN, the ROM type in the INI is 'G', the load address is 6000 and the maximum length is A000.

 

There aren't any other types in the standard V9T9 scheme, though Classic99 supports 3.BIN as an extension for Jon Guidry-style carts. For those the load address is 0000 and the maximum length is 20000 - though I don't expect you will come across any.

 

So if your front end can tell the file by name, you can write it like that. If you can't, Classic99 already has code for autodetect, I can add an autodetect mode to the INI too (it defeats the INI's purpose in most cases, but is fine here) -- so let me know.

 

Hi Tursi, If you could add that cart autodetect mode please that would be great and save me a lot of bother

 

I've got a script to parse the rom names and run V9T9 carts from the info you gave but the autodetect feature would be very handy for the cases where the images are not V9T9 and ones that use non standard rom naming convention.

 

Gamebase has no way of removing entries in the Classic99.ini, only add or overwrite so I'm currently having to overwrite every ascending rom entry in the .ini from the previously executed game (eg:- rom2="",rom3="") so as not to confuse Classic99 with mixed rom banks, could you tell me if this would have any possible implications?

 

And finally I have an Arcturus sidecart rom image (adapted by yourself) which is a single file of Arcturus.bin of size 24K, any idea what the setup would be to run this?

Edited May 27, 2011 by OX.

[Tursi]

I've got a script to parse the rom names and run V9T9 carts from the info you gave but the autodetect feature would be very handy for the cases where the images are not V9T9 and ones that use non standard rom naming convention.

 

The autodetection is 100% based on the name -- if a file uses a non-standard naming convention, you have to figure it out and tell the emulator in all cases. If you determine it's a standard cart after all, you'd be better off renaming it.

 

Gamebase has no way of removing entries in the Classic99.ini, only add or overwrite so I'm currently having to overwrite every ascending rom entry in the .ini from the previously executed game (eg:- rom2="",rom3="") so as not to confuse Classic99 with mixed rom banks, could you tell me if this would have any possible implications?

 

Well, no, aside from use of disk space, but why aren't you creating an entirely new Classic99.ini each time? That would make more sense.

 

And finally I have an Arcturus sidecart rom image (adapted by yourself) which is a single file of Arcturus.bin of size 24K, any idea what the setup would be to run this?

 

Dunno. Doesn't sound like something I'd have released. Is it a converted GROM version? (Do you see a 'cart conv by Tursi' when it starts?). How do you load it on MESS?