Classic99 Updates

[Tursi]

Cool that it's partly there, though, and based on your benchmark results, it makes a difference.

 

Owen, I think as long as the disk doesn't spin down between records (and it looks like it shouldn't), you should be fine.

[Opry99er]

Thanks guys. Good stuff...

[Willsy]

Tursi,

 

Wondering if I could badger you to add support to Classic99 for the new "any character, any colour" 80 column mode that is built into the latest generation of F18s. I'm very interested in developing a Forth library to allow that mode to be used in Forth programs - however, I don't have any real-iron actually assembled and won't for the forseeable - it's all in the loft!

 

TF currently is 80 column aware, including the code editor, however, it's two colour only. That won't change but I'd like to write a programming library to allow the full colour features of the new 80 column mode to be utilised. It's a fabulous facility, and I want to start using it!

 

I need to start looking at how this mode is actually used from a programmers point of view (VDP registers and VDP memory layout). I'll post a seperate thread to Matthew on that if/when you manage to add support.

 

Sorry to hound you - I know you've got a big list of "WIBNIs" to add to Classic99, but this is a really nice feature, and if it's built into classic99 it'll help push the adoption of the F18.

 

Cheers

 

Mark

[Tursi]

Sorry, I just don't have time to implement large new features right now, that'll include coming to understand graphics modes. There are so many hacks in that system (Classic99's graphics engine) for half-implemented things now that I have to draw a line in the sand.

 

JS99er supports most of the F18A features, you may well be able to try it there?

 

I want that stuff, too, but there are getting to be too many pre-requisites to plugging them in, I need to spend time on the framework.

Edited May 7, 2015 by Tursi

[atrax27407]

I would be willing to test your stuff on my v9938 system.

[Tursi]

I'm not sure Classic99 will run on a 9938.

 

(ducks and runs)

[Tursi]

Enough little tweaks have piled up, so before I poof for a while I figured I'd let it out there. V381. (I'll be at 400 soon and have no excuse not to rebuild ).

 

-safer and more correct triggering of the LOAD interrupt

-Fix Day of Week from clock to be 0-6 - CorComp manual lied

-FIAD disks search entire index sector to work around one form of copy protection (Still technically not the same as TICC, and may fail in particular cases)

-TICC now supports DSK.DISKNAME.FILENAME (not tested on disks other than DSK1)

-removed old bigfilehack filenames and implemented address register read and write (Read untested)

-Allow high ascii as a terminator in filenames

-Fix directory listings that return errors

-Write the Disk DSR buffer header to VRAM. This makes P-Code work with the Classic99 DSR.

-Fix VDP disk buffer header for Corrupt DSK RAM option

-fix EOF flag

-fix off-by-one in header of variable length FIAD files for bytes in last sector

 

http://harmlesslion.com/software/classic99

[Asmusr]

I noticed a bug a long time ago that I think I reported but never described how to reproduce: Open the debugger at the color bar screen and place breakpoints at >900 and >ABE (beginning and end of interrupt routine). Press F1 to go to >ABE. As soon as you leave the ISR by pressing F2 at >ABE you're back at >900 and can never get out.

[Tursi]

That's useful! I've occasionally had a problem with breakpoints confusing something and getting the machine into an interrupt loop. Having an easy way to reproduce it like that should help, thanks!

[Tursi]

Got it! That's a long standing bug that always bothered me, because it only happened under breakpoints.

 

The cause was if you breakpointed at the beginning of a VDP interrupt handler before the LIMI 0 runs. The core is supposed to skip interrupts for one instruction after the vector, but for the vertical blank, Classic99 wasn't setting the flag. The code path that it normally took meant it worked anyway, but if you breakpointed, when you released the breakpoint, it re-evaluated the interrupt, determined it was active, and triggered to vector again. The effect was that the return address got changed to the entry point of the interrupt routine. If you F2 step over the LIMI 0 at >900 and watch R14, you'll see it happen.

 

The fix was easy - make sure the skip flag was set on a vector branch. Interestingly, I must have noticed this when I reworked the LOAD interrupt not long ago, because that interrupt specifically set the flag. Centralized it to where it belongs and retested, and checked the other vector opcodes (which appear to be right). That fix will be in the next release.

 

In the meantime, the workaround is to always set your breakpoint AFTER the LIMI 0.

[Tursi]

The big updates in this one are the additions of Harry Wilhelm's wonderful programming tools (thank you Harry!), and the ability once again to paste copied text, even from the forum.

 

After seeing more problems with it (and it wasn't working for me either), I found myself wondering why pasting to Notepad worked (copying out I understood). So I grabbed the source to Notepad2, which I use, and had a peek at their function. Then I felt really stupid. They just pull the text out in Unicode format, and copy it. Unicode is not only the only pure text clipboard format that IE now stores on a copy (there's no longer a plain text copy, which is why even 'enhanced clipboard' stopped working), but I never saw it because when I enumerated the formats, it's text name is "Data Object". Anyway, all the clipboard hacks have been removed, we now try first Unicode then plain text, and paste whichever we get. It seems to work now and there's no reason to expect this one to break.

 

Lots of little tweaks, and I revised CPU cycle counting (which is not the same as timing). There are a few things I need to verify on hardware, but I think it's pretty close now (I was comparing run speed against YouTube videos ). In particular I implemented a bit-shifting DIV algorithm which appears to give the right values and has the right range of possible CPU cycles - again, this needs to be tested on hardware (a few key tests will identify if it's right). I documented every opcode in cpu9900.cpp with the datasheet's noted cycles and a breakdown of the memory accesses, as well, as part of that review.

 

Little bugfixes and tweaks. Enhanced sprites are still broken (sorry, I didn't get to that). Documentation is updated too.

 

-Updated RXB to RXB2015E and added support folder
-Added Harry Wilhelm's Playground, XB256, XB256 Compiler and Missing Link 2.0, and documentation
-Added USCD Pascal disks for pCode emulation
-Reworked Clipboard support for Unicode - no longer need 'enhanced' hack
-Fixed debugger VDP memory view to properly work with F18A extra RAM
-Improved disk directory sizes (thanks to Lee!)
-Directory listings now REQUIRE trailing period (like TI disk controller)
-Fix debugger run-away that would break a run if the program breakpointed on an interrupt handler before LIMI 0
-tweak LOAD interrupt processing
-Cycle counting overhaul - all opcodes reverified and documented
-Cycle counting on memory accesses revised.
-possible hang on reset during speech fixed
-Changed name of 'X' flag to 'XOP' flag (it was confusing me)
-made reset use the general interrupt trigger function
-StopIdle properly place in interrupt handler (not used yet)
-changed DIV to use a likely algorithm that produces timing results in the correct range - need to test on hardware.
-removed hack in LDCR and STCR that was setting /no/ flags for word operations - the datasheets all say only parity is unchanged for word. Need to test on hardware.
-added Read-before-write to the only four opcodes that have an unnecessary one: MOV, MOVB, CLR and SETO.
-Documentation updated

 

http://harmlesslion.com/software/classic99

[globeron]

Great stuff!

[Asmusr]

-added Read-before-write to the only four opcodes that have an unnecessary one: MOV, MOVB, CLR and SETO.

 

Does this mean that it now takes 4 additional clock cycles to write a byte to the VDP in Classic99?

[Tursi]

No, that timing was already there. It was done on the write function instead of the opcode, which means it may have triggered at the wrong time. The new implementation is less naïve, but that required me to add a manual read-before-write to those opcodes.

[Tursi]

I promised a small update to make the UberGROM emulation usable by others, and while I was in there I ran down the todo list for anything that could be knocked out quickly.

-updated debugger help window to note bank select syntax
-added ability to mask watch values for breakpoints
-RXB properly listed as 2015E
-added ability to configure UberGROM EEPROM - carts are now properly loadable
-Edit->Paste now works in TI-99/4 and v2.2
-added GROM access timing - Ahl benchmark timing in TI BASIC now matches console

http://harmlesslion.com/software/classic99

The main push was adding the ability to configure an UberGROM cart, which was previously impossible due to lack of an EEPROM type. All functions should work, but be aware the debugger can't help you much (it will not properly show UberGROM memory or any register info), and of course the I/O features are not hooked up to anything internally (the ADC returns intentionally random data, for instance).

Besides that, the UberGROM emulation does not support the recovery program or the GROM wrap bit. All else should work fine.

But, to demonstrate, this INI entry runs Gazoo's XB27 cart. Type 'U' is UberGROM Flash (GROM) data, and type 'T' is the UberGROM EEPROM space. Type '8' is the standard 378-style non-inverted cart ROM.

The one gotcha is that the 128k flash file is here loading only 120k, as that is the GROM space available. The last 8k in the distribution file is the AVR code, which Classic99 will omit even if you make a mistake and put the full size (but with a debug warning).

[usercart27]
name="XB27"
rom0=U|0000|1E000|C:\classic99\xb27\Programming files\XB27 Suite 128k Flash 051315.bin
rom1=8|0000|80000|C:\classic99\xb27\Programming files\XB27 Suite 512k Rom 051315.bin
rom2=T|0000|1000|C:\classic99\xb27\Programming files\XB27 Suite EEprom 051315.bin

Edited August 29, 2015 by Tursi

[Willsy]

This is very cool - thanks! I'm going to have to RTFM to see what the additional zero in the second hex field of rom0 and rom1 is.

 

I'm way behind on this stuff. Ability to mask breakpoint values is very cool - nice job!

 

Did you update the copyright years yet? Version 382 says copyright 2013!

[Tursi]

This is very cool - thanks! I'm going to have to RTFM to see what the additional zero in the second hex field of rom0 and rom1 is.

 

It's a hexadecimal number, it's just larger than 64k. The fields are pipe delimited, not fixed-width. You can use fewer than 4 digits too. 1E000 is 120k and 80000 is 512k.

 

 

 

Did you update the copyright years yet? Version 382 says copyright 2013!

 

No, I noticed that after I finished uploading the new zip, and since every change means rebuilding the zip and copying in the source files (I should automate that...)... anyway, I have 75 years to get around to it if I die tomorrow.

[ramidavis]

Hey Tursi, is there any way you could think of adding cassette port functionality to Classic99?

Right now, i run the few tape/game programs i have in win994a simulator as .TITape files. Would be easier to mount them in Classic99.

Thanks for a great emulator, Tursi!

[Willsy]

Hey Tursi, is there any way you could think of adding cassette port functionality to Classic99?

Right now, i run the few tape/game programs i have in win994a simulator as .TITape files. Would be easier to mount them in Classic99.

Thanks for a great emulator, Tursi!

 

Is there any reason why they are tape files? If they are BASIC or Extended BASIC programs you should be able to save them to a Win994A Disk file, and from there it's easy to export it out of the .TIDisk file into Classic99.

[agmadama]

Hi,

Not sure if I am doing something wrong here but when I try to enter Stretch Mode - DX Full (any resolution or color depth) I just get a resize of my desktop resolution and Classic99 stays in a window (see pic below).

My PC is Windows 8.1 with an Nvidia 610GT graphics card. I have both DX9 and DX11 installed and using the latest 8/29 release of Classic99. Other emulators seem to go into full screen ok (things like Dosbox, VICE, PCEM, V9T9, etc..)

Thanks!

 

 

 

[Tursi]

Hey Tursi, is there any way you could think of adding cassette port functionality to Classic99?

Right now, i run the few tape/game programs i have in win994a simulator as .TITape files. Would be easier to mount them in Classic99.

Thanks for a great emulator, Tursi!

 

Thanks!

 

I've thought about it many times. But it's a lot of work, and I don't think very many people are shipping new software on cassette.

 

What is a TITape file? Is it a wave file?

[Tursi]

Hi,

Not sure if I am doing something wrong here but when I try to enter Stretch Mode - DX Full (any resolution or color depth) I just get a resize of my desktop resolution and Classic99 stays in a window (see pic below).

My PC is Windows 8.1 with an Nvidia 610GT graphics card. I have both DX9 and DX11 installed and using the latest 8/29 release of Classic99. Other emulators seem to go into full screen ok (things like Dosbox, VICE, PCEM, V9T9, etc..)

Thanks!

 

 

 

 

I haven't really supported full screen mode for quite a few years, I'm not up to speed on what happens with the latest. I'll try to reproduce your issue but I don't promise any fixes at the moment, I developed a dislike of changing my monitor resolution when I went to multimonitor many years ago and prefer to maximize windows to going full screen. My personal preference affects the development.

[ramidavis]

 

Thanks!

 

I've thought about it many times. But it's a lot of work, and I don't think very many people are shipping new software on cassette.

 

What is a TITape file? Is it a wave file?

The .TITape format is used by the Win994a Simulator suite. It is a format representing inline, raw data, just as would be written/read to CS1/2.

I am a bit of a purist when it comes to emulation. I have Morphy and Atlantis saved to .TITape files for use in Win994a simulator, becuase i can prove that they are really tape software. For morphy, i first took the FIAD's and imported them to a .TIDisk, then loaded them up in Win994a Simulator, ran the loader prep program, and let it write the VDP util out to CS1, then saved the game its self, after that, to the .TITtape. The result is i can now load the game from tape, under a emulated bare bones system.

 

Atlantis, i downloaded from a thread on this forum, changed the OPEN #1 line to look at CS1, then imported the data file and game itself to a .TIDisk. The Win994a Simulator has a disk manager built in, and supports exporting a file to a .TITape. First i exported the game (changed for CS1), then the data behind it.

End result: I now have a emulated copy of the game that loads exactly like the original.

[Asmusr]

It would be cool if Classic99 allowed you to load an E/A#3 object file (like those produced by WinAsm99) directly from Windows into TI memory without the need to go through E/A and the TI file system. This would also allow you to use the first >700 bytes of lower memory. If you had a shortcut key to load and run the last file again it would speed up the development-assemble-test cycle a lot.

[Tursi]

The .TITape format is used by the Win994a Simulator suite. It is a format representing inline, raw data, just as would be written/read to CS1/2.

I am a bit of a purist when it comes to emulation. I have Morphy and Atlantis saved to .TITape files for use in Win994a simulator, becuase i can prove that they are really tape software. For morphy, i first took the FIAD's and imported them to a .TIDisk, then loaded them up in Win994a Simulator, ran the loader prep program, and let it write the VDP util out to CS1, then saved the game its self, after that, to the .TITtape. The result is i can now load the game from tape, under a emulated bare bones system.

 

Unless you have details on the file format, you may be out of luck on that. The Win994a author refused to share details on his custom file formats, and the cartridge images, at least, are non-trivial. Pretty much all the other emulators use raw binary images for data files (and I believe MESS can read WAVE files for tape), but the images for Win994A are compressed and encoded in a proprietary manner.

Edited September 1, 2015 by Tursi