Classic99 Updates

[Tursi]

Sorry, I did promise sector writes, didn't I? They worry me a bit, at least with PC99 disks. I may leave those write protected, but I'll take a note. Tim has been helping with the archiver errors so I may do new work tommorrow.

 

Save states are a long ways out, although I agree they will be nice to have. General disk image writes are also a long way out, as I have to write a full disk sector allocation system for that. (Sometimes I consider that implementing the DSR would be faster, but I need that code anyway).

 

But ultimately the rate of development depends on my free time and other committments. As the 6 months since the last release shows, I've been pretty busy. :/

 

Still, the requests are appreciated, because they help remind me what other people consider important.

 

[Tursi]

With some help from Tim, we sorted out the disk issue causing Archiver to fail to create compressed files! So that works out. I also took a quick shot at running the pCode Card, and that also works now (that was from fixing 'X' last release). And then, because I'd promised but forgotten, this version adds writing raw sectors to disk images. (Only raw sectors, no file write support). Please use that with care, it has only had minimal testing!

 

So, the update for 364:

 

-Fix SBR Information request to correctly return number of sectors, and properly read record count as 16-bit. This fixes Archiver and compressed files!

-P-Code card works (previous fix to 'X' instruction fixed it)

-Implement disk 'write protect' option

-Implement raw sector writes to image disks

 

http://harmlesslion.com/software/classic99

Edited January 17, 2013 by Tursi

[+Lee Stewart]

With some help from Tim, we sorted out the disk issue causing Archiver to fail to create compressed files! So that works out. I also took a quick shot at running the pCode Card, and that also works now (that was from fixing 'X' last release). And then, because I'd promised but forgotten, this version adds writing raw sectors to disk images. (Only raw sectors, no file write support). Please use that with care, it has only had minimal testing!

 

So, the update for 364:

 

-Fix SBR Information request to correctly return number of sectors, and properly read record count as 16-bit. This fixes Archiver and compressed files!

-P-Code card works (previous fix to 'X' instruction fixed it)

-Implement disk 'write protect' option

-Implement raw sector writes to image disks

 

http://harmlesslion....tware/classic99

 

Thanks, Tursi! I'll try out the sector writes in a bit.

 

...lee

[kl99]

wow, great!

[OX.]

Hi Tursi, apologies for reporting this so late but it seems a bug has crept in reading (I think) pc99 disk images since version 363, only just noticed when running "The Haunted Mine" in Gamebase, in 363 and 364 it simply can't see the file whereas in 362 it still works fine.

[Tursi]

I don't plan to download the gamebase, can you please attach the disk?

[Willsy]

Hi Tursi, apologies for reporting this so late but it seems a bug has crept in reading (I think) pc99 disk images since version 363, only just noticed when running "The Haunted Mine" in Gamebase, in 363 and 364 it simply can't see the file whereas in 362 it still works fine.

 

Is there any message in the debugger output window?

[OX.]

Here's the output from the debugger screen - Initializing AMS mode 2, size 1024k

Loading file from resource: Type D, Bank 0, Address 0x1100, Length 0x01A0

Loading file from resource: Type S, Bank 0, Address 0x0000, Length 0x8000

Loading file from resource: Type P, Bank 0, Address 0x0000, Length 0xF800

Loading file from resource: Type G, Bank -1, Address 0x0000, Length 0x6000

Loading file from resource: Type C, Bank -1, Address 0x0000, Length 0x2000

Loading file (C:\GameBase\TI99-4Av2\system\phm3026c.bin) from disk: Type C, Bank 0, Address 0x6000, Length 0x2000

Loading file (C:\GameBase\TI99-4Av2\system\phm3026d.bin) from disk: Type X, Bank 0, Address 0x6000, Length 0x2000

Loading file (C:\GameBase\TI99-4Av2\system\phm3026g.bin) from disk: Type G, Bank 0, Address 0x6000, Length 0x8000

Loading file from resource: Type K, Bank 0, Address 0x0000, Length 0x0000

Starting Sound

Sample rate: 22050hz, Buffer size: 44160 bytes

Starting Disk

Starting Video

Video Thread began...

Starting video loop

Client rect now 1088 x 832

Timer thread began...

Speech Buffer thread began...

CPU thread began...

Starting Window management

Setting top of VRAM to >37D7 (3 files)

Loading to VDP >096F DSK1.LOAD on drive type Image

Can't find file LOAD on c:\gbgame\0\cug006.dsk.

Setting file error 7 on file buffer 36

Opening DSK1.LOAD on drive type Image

PAB requested file type is IV254

Allocating file buffer 0

Can't find file LOAD on c:\gbgame\0\cug006.dsk.

Releasing file buffer 18

Setting file error 7 on file buffer 38

Loading to VDP >096F DSK1.MINE on drive type Image

loading 0x2E69 bytes

 

which is followed by "I/O error 50" on screen.

 

disk "CUG006" is attached, XB used to load using RUN"DSK1.MINE".

CUG006.ZIP

Edited January 18, 2013 by OX.

[Tursi]

Looks like the disk system succeeded but that the file is corrupt.

 

Loading to VDP >096F DSK1.MINE on drive type Image

loading 0x2E69 bytes

 

The I/O error is a 2 digit code. The first digit is the operation (LOAD in this case), the second is the code returned from the disk system (0 normally means 'device not found', but it clearly found DSK1 since it tried to load).

 

The first thing I notice when I look at the disk is that it's an IV254 file, not a PROGRAM image (which means it should not have loaded successfully.. it should have failed and fallen back on the larger file format.)

 

When Extended BASIC tries to load a file, first it tries to load as a standard PROGRAM image file. If it fails, then it tries again as an IV254, which is the format used for programs that don't fit in the available VDP memory. In this case, Classic99 is not detecting the file type difference and so it's allowing the image load, even though it's not a PROGRAM image file. The XB interpreter then fails trying to make sense of the loaded program, as it's in the wrong format.

 

This was caused by my fix for the TI Assembler and affects disk image files only - basically PROGRAM image loads from disk images are not being type checked right now. Does not affect individual files. The only likely place this will break is Extended BASIC programs stored as IV254 (in general >12k or using RXB). Saves are still safe, you just can't reload them! I have the line of code isolated but I won't be able to fix it until at least Monday. Definitely will, though, thanks for the report.

[OX.]

Will look forward to the update as 364 certainly seems more stable in other respects, thanks Tursi.

 

Also you should really download Gamebase TI99 and see what your missing

Edited January 18, 2013 by OX.

[+hloberg]

Tursi,

I got a couple questions I can't seem to find in the info in Classic99.

1.) are there any command line start up options?

2.) can you go full screen and maintain the aspect ratio (with bars on the side or something of the like)?

the 1st question pertains to the second. I would like to start up Classic99 straight into full screen with aspect ratio kept.

By the way, don't consider this a request if it doesn't do this. I see you already have enough on your request plate as it is, just curious.

[Tursi]

1.) are there any command line start up options?

 

No, sorry.

 

2.) can you go full screen and maintain the aspect ratio (with bars on the side or something of the like)?

 

No, again. All full-screen modes are full-stretch. The last time I touched full screen nobody had wide-screen monitors.

 

the 1st question pertains to the second. I would like to start up Classic99 straight into full screen with aspect ratio kept.

By the way, don't consider this a request if it doesn't do this. I see you already have enough on your request plate as it is, just curious.

 

You can configure it in the Classic99.ini file to start up in full screen (or just exit while full screen by pressing Alt-F4 - Classic99 will remember that setting), but some people have reported problems with doing so. I've just looked at that and there is a problem with it locking up starting fullscreen (it's a bad order of operations relating to DirectX startup). I've got that fixed for the next release.

 

Fixing the aspect ratio is a different issue.. the DirectX full-screen modes are all hard coded for 4:3 monitors, so all of the render code expects to completely fill the window, whatever it is. I'll keep aspect ratios in mind when I re-write that code, but for now, I'm not going to tweak the aspect ratio question.

 

 

[Tursi]

Bugfix up!

 

-Fix loading of Extended BASIC programs in I/V254 mode from disk image files

-Fix starting in full screen mode not to hang

-Clear VDP registers 0 and 1 on reset per the 9918 datasheet

 

http://harmlesslion.com/software/classic99

 

[OX.]

Thanks Tursi

[Tursi]

Also you should really download Gamebase TI99 and see what your missing

 

I downloaded the first one and decided I've seen most of it. I've been in the TI community since it was a shiny new machine. Besides, I'm more interested in the development side than the playing side.

[+Lee Stewart]

@Tursi...

 

I tried the sector write feature you just implemented. There are no problems as far as I can tell. This will make it possible to stay in one system when I get back to messing around with TI Forth. (I'm not quite finished with the floating-point stuff for TurboForth.) Before, I was stuck writing Forth blocks in Mess and going back to Classic99 for everything else, especially debugging! Kudos! :thumbsup:

 

...lee

[OX.]

Hi Tursi, this ones been bugging me for a while now, certain games (like the one attached) feel slightly jerky like the timing isn't quite right using Classic99, I'm not sure what causes it, wether it's my setup or if it's a bug or design issue in Classic99, try running the example in MESS and notice how much smoother it runs. Is this fixable?

panic.zip

[sometimes99er]

Yep, Classic99 seems a bit more jerky than MESS with the sprites at this end too. Full screen scrolling was somewhat fixed earlier with Classic99. Was the update moved from top of display to just after the bottom of the display ?

[Tursi]

The timing isn't quite right in Classic99, that's easy. Timing is CPU based and the video update is based on CPU cycles. Which is completely wrong. I moved the timing of setting the video interrupt to after the display is generated which fixed sprite collision detection for objects moved during vblank and improved your scrolling (probably for similar reasons), but it didn't change the overall timing of the system.

 

MESS uses a single thread to generate everything, so things always happen in a predictable order. Classic99 is multi-threaded and, like real life, more than one thing can happen at a time. Unlike real life, however, Classic99 uses an unreliable timesource. The best timesource in the Classic99 system should be the video display, since no matter what the rest of the system is doing, the TV still scans lines. Until I do that, though, things are always going to be a little strange at times.

 

I'll take a peek at MESS later, but I don't really see anything that's a quick fix here. The software is functioning, it's just real time that's wrong.

[OX.]

Thanks Tursi, tbh I prefer using Classic99 to MESS although in the cases where the timing difference is obvious I use MESS as it's more accurate, If Classic99 had the timing sorted it would have the advantage for me bar the odd time I need to use disk writes and save states in MESS.

[Rod Van Orden]

Lee:

I am having some difficulty setting up Classic99 with the UCSD p-System

files. I have the DSK files, but I'm stuck on how to set up Pascal on the drives.

The message I get when selecting the Editor is: EDITOR.SYSTEM not found.

 

Rod

[+Lee Stewart]

Lee:

I am having some difficulty setting up Classic99 with the UCSD p-System

files. I have the DSK files, but I'm stuck on how to set up Pascal on the drives.

The message I get when selecting the Editor is: EDITOR.SYSTEM not found.

 

Rod

 

I've never used it, so I'm not sure whether I can help. I am not sure how the P-System writes to disk. If it writes normal files that can be seen with a Disk Manager cartridge, that won't work with Classic99. The only writing that Classic99 can do as of v365 is sector writing. This is why I can now use TI Forth on Classic99. If I want to write files, I can set up one of the disks as FIAD instead of DSK. If the P-Sysytem is using sector writes, it should work. Perhaps someone more knowledgeable will respond.

 

...lee

[Tursi]

I don't know a lot about the p-System but I tagged it as working recently when booting the disks let me go through the menus, which never happened before. However, there are reports on my forum that there are still issues, and without a real pCode card to examine the differences, I am not certain where to go with it. It is a rather low priority, getting it to work, for me, is more a curiousity thing.

 

[Opry99er]

Tursi, recently downloaded the latest version of Classic99. Some EXCELLENT updates since my last download!!! Of course, that was nearly 3 years ago. =)

 

Everything works perfectly, the new features are awesome! I started playing around with some code again yesterday---flipping on Classic99 to cyan and "BEEP" on my laptop brought me some intense joy. I'm extremely rusty, but it felt good to set up some print loops and SPRITEs just to see if I still "had it". It was one of those cool experiences you have after you've been removed for a long time from something you love.

 

Thanks for all you do, man.

[+acadiel]

Hey, It's Owen! *jumps up and down* - Hey dude!!!