Classic99 Updates

[+dhe]

>Classic99 doesn't seem to be able to read them no matter what I do

 

I've not had that problem.

 

Can you attach the disk your trying to use and a screen shot of the drive setup in classic99?

[+Lee Stewart]

Yeah—Classic99 used to be able to read PC99 disk images. In fact, the debug log for  QI399.053 correctly discovers it to be PC99 format, but gets no further:

Sector read: drive 3, sector 80, VDP >1154
No DSK marker, assuming PC99 track-based image...
Can't find PC99 start of sector indicator - corrupt dsk?
Can't read sector 80 on C:\Users\Public\TI-99-4A\TI FORTH Disks\PC99\CV019.DSK.

...lee

[Tursi]

On 2/3/2022 at 8:34 AM, jenorton said:

Hi:

 

I can't be the only one with this question, but, searching seems not to yield much.

 

This has to do with .dsk images in PC99 format (size is 260,240 bytes).

 

Classic99 doesn't seem to be able to read them no matter what I do, yet, the manual says it supports them.

 

Am I doing something wrong, or is this size not supported?  I've tried with both images downloaded from whtech as well as images from my copy of the CYC.

 

I can convert them with TI Image Tool, but, this is an extra step I'd like to avoid.

 

For example, if I try to load an  Extended Basic program with one of these disks selected, I get * I/O ERROR 06

 

If I convert with TI Image Tool, everything works ok.

 

Am I doing something wrong, oe these images actually not supported?

 

Thanks!

"It doesn't work" is not a statement that can be diagnosed.

 

Disk image support in Classic99 is second class in the first place, and the PC99 support is a hack on top of that. However, it works for me.

 

(edit)
 

With Lee's log snippet I am able to reproduce the issue. A bit surprised since I didn't think I'd touched that code anytime recently (and clearly not too many other people do either )

 

Looking at it as time permits.

 

 

Edited February 4, 2022 by Tursi

[Tursi]

22 hours ago, Lee Stewart said:

Yeah—Classic99 used to be able to read PC99 disk images. In fact, the debug log for  QI399.053 correctly discovers it to be PC99 format, but gets no further:

Sector read: drive 3, sector 80, VDP >1154
No DSK marker, assuming PC99 track-based image...
Can't find PC99 start of sector indicator - corrupt dsk?
Can't read sector 80 on C:\Users\Public\TI-99-4A\TI FORTH Disks\PC99\CV019.DSK.

...lee

That's not a correct detection so much as a failure to detect a V9T9 style disk, so it falls back. The word "assuming" is important.

 

 

[Tursi]

Found the bug. The compiler changed some years back so that comparing bytes out of a char buffer which are greater than 0x7f (which should be negative) gets promoted to int and so the comparisons don't work. I have a fix.

 

[Tursi]

Classic99 399.054

 

- fix detection of PC99 disks caused by signed char confusion.
- audit code for other potential cases - test the functions you use!
 

http://harmlesslion.com/software/classic99

 

[jrhodes]

Not a issue with the emulator, but i suppose this is a proper place to ask this:

@Tursi Could you please consider naming the zip file downloaded from your site after the release version, I.E. "Classic99 - v399.054.zip" , instead of just classic99.zip for all versions?

Edited February 4, 2022 by jrhodes

[RXB]

I personally just download Classic99.zip and delete the download, then I make a copy of that Classic99 configured for my computer with label of date saved.

[jrhodes]

I like to keep old releases of software, and i hate manually renaming files.

[RXB]

1 hour ago, jrhodes said:

I like to keep old releases of software, and i hate manually renaming files.

Ok so you want Tursi to do that for you? Hmmm....

 

[jenorton]

2 hours ago, Tursi said:

"It doesn't work" is not a statement that can be diagnosed.

 

Disk image support in Classic99 is second class in the first place, and the PC99 support is a hack on top of that. However, it works for me.

 

(edit)
 

With Lee's log snippet I am able to reproduce the issue. A bit surprised since I didn't think I'd touched that code anytime recently (and clearly not too many other people do either )

 

Looking at it as time permits.

 

 

Hi Tursi:

 

Sorry about not posting the debug log.

 

This is probably redundant now, but, here's my experience.  I will be more careful to say more than "it doesn't work":

 

DSR opcode >5 (LOAD) on PAB >096E, filename DSK1.LOAD
Loading to VDP >096F DSK1.LOAD on drive type Image
No DSK marker, assuming PC99 track-based image...
Can't find PC99 start of sector indicator - corrupt dsk?
Can't read sector 1 from C:\Users\josep\classic99\PHD5076.DSK, errno 0
Setting file error 6 on file buffer 54
DSR opcode >0 (OPEN) on PAB >096E, filename DSK1.LOAD
Opening DSK1.LOAD on drive type Image
PAB requested file type is IV254
Allocating file buffer 0
No DSK marker, assuming PC99 track-based image...
Can't find PC99 start of sector indicator - corrupt dsk?
Can't read sector 1 from C:\Users\josep\classic99\PHD5076.DSK, errno 0
Releasing file buffer 27
Setting file error 6 on file buffer 56
DSR opcode >5 (LOAD) on PAB >096E, filename DSK1.PHRASE
Loading to VDP >0971 DSK1.PHRASE on drive type Image
Can't find PC99 start of sector indicator - corrupt dsk?
Can't read sector 1 from C:\Users\josep\classic99\PHD5076.DSK, errno 0
Setting file error 6 on file buffer 58
DSR opcode >0 (OPEN) on PAB >096E, filename DSK1.PHRASE
Opening DSK1.PHRASE on drive type Image
PAB requested file type is IV254
Allocating file buffer 0
No DSK marker, assuming PC99 track-based image...
Can't find PC99 start of sector indicator - corrupt dsk?
Can't read sector 1 from C:\Users\josep\classic99\PHD5076.DSK, errno 0
Releasing file buffer 27
Setting file error 6 on file buffer 60
 

[Keatah]

2 hours ago, jrhodes said:

I like to keep old releases of software, and i hate manually renaming files.

Well you better get used to renaming files, because, that is part of archiving and curation and all that. Dear gawd..

[jenorton]

I don't mind about the file naming conventions.  Each one has his own ideas.

 

For example, the MAME developers name all the releases with version numbers.  Whereas, the MAMEUI developer just tells you which version is on the site and it is just named "mameui.7z".I don't mind renaming--Actually, I just try to keep the latest version around.

 

Funny about those naming things.  

[Tursi]

9 hours ago, jrhodes said:

Not a issue with the emulator, but i suppose this is a proper place to ask this:

@Tursi Could you please consider naming the zip file downloaded from your site after the release version, I.E. "Classic99 - v399.054.zip" , instead of just classic99.zip for all versions?

No thanks, I already have to put the version number in three places.  (Edit: Just to be fair, I did stop and think about it for a moment).

 

Classic99 is not developed for the sake of preservation, it is a development tool. You should be on the latest version and throw away older versions. If the latest version doesn't work, you should tell me so I can fix it.

 

Do you seriously have 153 copies of Classic99 sitting there?

 

7 hours ago, jenorton said:

This is probably redundant now, but, here's my experience.  I will be more careful to say more than "it doesn't work":

Thanks, yes, that level of detail would be perfect

 

Edited February 5, 2022 by Tursi

[Tursi]

I've made a few too many promises and that has prevented me from having any hobby time anymore... but last night I did a quick test to build Classic99 4.0 on the Raspberry PI 4. It needed a couple of (very) minor tweaks (missing include header), but it built and ran. I will need to do a little work as the video is not perfect (it's unusable at the moment), and it's slow, running at about 30% of real time, but it came up. (Didn't test audio though).

 

The Allegro library seems to handle transparent blits differently on every system, which is making that part a little awkward. Windows, Linux and Mac all need different flags to get stable video - which isn't supposed to be the case. Perhaps I'm doing something wrong, but I hope to bring the builds together soon.

 

At any rate, once the PI build works correctly, that'll probably be all the targets of interest to me. That'll be tested on Windows, Mac, Linux (Debian), Linux (WSL), and Linux (Raspbian). 

 

[Antharian]

I'm a real fan of the v4.0 effort (not to mention the original!)

 

In what little spare time I have, I've been looking over the code base and wondered if you have any formal style/process for pull requests or other contributions?

 

Or if you are even looking for contributors?

 

-A

[Tursi]

1 hour ago, Antharian said:

I'm a real fan of the v4.0 effort (not to mention the original!)

 

In what little spare time I have, I've been looking over the code base and wondered if you have any formal style/process for pull requests or other contributions?

 

Or if you are even looking for contributors?

I'm not really... in the past I've accepted contributions for small things, but large features just became my problem to maintain. Since they were usually for components I didn't own or understand, that was a problem.

 

While I understand the desire to speed up the process, right now is not a good time for contributing, as there is still so much I need to pull from the original codebase. Any part is still subject to massive design change, and there's still a fair bit to implement. But if you have ideas, we can talk.

 

It's probably best to check with me about any contribution before starting the effort anyway, to make sure it's not going to run afoul of plans I already have. I'm also likely to turn my nose up at changes made just for style's sake - for instance, for one project I originally shipped a three line Makefile, because that's all a single-file C program needs. Someone contributed what they described as a "proper" Makefile - a complex system almost 50 lines long which did exactly the same thing, but looked more like you expect a modern Makefile to look. I was unimpressed, and my reaction offended the contributor. I don't like offending people, but I also don't care for making things more complex than they need to be.

 

Other than that, I don't have any real rules, except that it's likely someday your contribution will be rewritten, especially if I have to support it. That's not a dig on your coding style, just what I need to keep everything in my mental cache. 

 

[dgrissom]

On 2/26/2022 at 4:21 PM, Tursi said:

I've made a few too many promises and that has prevented me from having any hobby time anymore... but last night I did a quick test to build Classic99 4.0 on the Raspberry PI 4. It needed a couple of (very) minor tweaks (missing include header), but it built and ran. I will need to do a little work as the video is not perfect (it's unusable at the moment), and it's slow, running at about 30% of real time, but it came up. (Didn't test audio though).

Thanks, Tursi!

Looking forward to this!

[GDMike]

I'm thrilled with it as it is. Finding myself checking to make sure I'm using the latest but I think it's already over the top and successful. 

Thx for doing this back when you started. 

[+retroclouds]

@Tursi  Is there a way to write the classic99 debugger console to a file?
I'm using the classic99 debug opcodes to print debug info.
The problem is that the console is not that large and because of a flood of "AMS Register X now >YYYY" messages while running my program I can't see the relevant messages.
I vaguely remember there was a trick to use a microsoft windows message viewer, but can't remember if that was with classic99 or some other emulator.

 

By the way, the debug opcodes are really cool.

 

Here's a couple of ideas:

1. Could image having a debug opcode that tells you if you are running in the classic99 emulator.

2. The possibility to specify a message channel that gets redirected to some logfiles you specify in the classic99 config file. That way you could write certain kind of c99_dbg messages to different logfiles.

3. Opcode for dumping CPU or VRAM memory to a file 

4. Opcode for detecting what mode the CPU is running in: overdrive, normal, etc.

 

EDIT: this is not a wishlist (although after re-reading my post it kinda sounds like it. Just sharing ideas here)

Edited February 28, 2022 by retroclouds
Added clarification

[Tursi]

Yes, use Microsoft debugview - https://docs.microsoft.com/en-us/sysinternals/downloads/debugview

 

I hated the idea of debug opcodes when I started... but these ones got added to support Classic99 as an application platform, so while I was there I added the print one.

 

Detecting the Classic99 emulator and writing TI software to behave differently on it is a support issue for me, so not something I'm fond of considering. ("Why does it work differently on MAME?", followed by me needing to download the software, figure out how to use it, step through the code, and eventually discover it was intentional ). That said, there are a number of things in Classic99 that'll probably never be on real hardware - I sometimes recommend looking for the CLIP device.

 

You can already write up to 10 different logfiles (IIRC) using the log memory function in the debugger. Choose 10 addresses and use that for your logging functions.

 

I can't think of a good reason to rapidly and repeatedly dump 80k of memory to disk, overwriting the old data, so I would say use breakpoints for the spot you want memory to be dumped and then hit dump...?

 

Detecting the CPU mode gives me a little pause for consideration... though it really does take Classic99 further away from being a TI development tool. What is your use case?

 

[Antharian]

On 2/27/2022 at 3:52 PM, Tursi said:

Other than that, I don't have any real rules, except that it's likely someday your contribution will be rewritten, especially if I have to support it. That's not a dig on your coding style, just what I need to keep everything in my mental cache

One hundred percent understand, especially the "mental cache" concept on a code base that is this elaborate and likely prone to fly by night contributors!

 

So, I'm guessing a "code formatting/indentation" PR is probably just what you are looking for!  JK!

 

I've was tracking down the bug that causes Classic99v4 to hang on a black screen occasionally during start.  I partially tracked it down to some variables that are not initialized, thus at times point to memory locations that have old values in them. (System.h : hold).  Initializing this in System.cpp with all the others brought the clean startup rate much higher, but there is still another location that is eluding me and gets the boot process into a loop.  Watching the TI CPU registers in pCPU I can clearly see the loop, but not the cause.

 

Truly love your project and have even more mad respect after touring around inside of it! 

 

As someone who does all of their dev work in OSX or Linux (I have zero windows pc's) , I look forward to having a native tool for developing my pet TI projects and would love to contribute in any way that makes your life easy.

 

Thanks again!

 

-A

[+retroclouds]

On 3/1/2022 at 7:29 PM, Tursi said:

Yes, use Microsoft debugview - https://docs.microsoft.com/en-us/sysinternals/downloads/debugview

 

I hated the idea of debug opcodes when I started... but these ones got added to support Classic99 as an application platform, so while I was there I added the print one.

 

Detecting the Classic99 emulator and writing TI software to behave differently on it is a support issue for me, so not something I'm fond of considering. ("Why does it work differently on MAME?", followed by me needing to download the software, figure out how to use it, step through the code, and eventually discover it was intentional ). That said, there are a number of things in Classic99 that'll probably never be on real hardware - I sometimes recommend looking for the CLIP device.

 

You can already write up to 10 different logfiles (IIRC) using the log memory function in the debugger. Choose 10 addresses and use that for your logging functions.

 

I can't think of a good reason to rapidly and repeatedly dump 80k of memory to disk, overwriting the old data, so I would say use breakpoints for the spot you want memory to be dumped and then hit dump...?

 

Detecting the CPU mode gives me a little pause for consideration... though it really does take Classic99 further away from being a TI development tool. What is your use case?

 

Thanks for the hint on Microsoft debugview. Works like a charm, and has great possibility to filter on what I exactly need.

 

 

The idea for the additional opcodes comes from a need for automatically testing my development work on Stevie.

With great power comes great responsibility, so I would not be too worried about someone abusing the debug opcodes and dumping too much stuff.

(actually in my case I would need to dump a lot more than 80k, as I'm using quite some SAMS banks).

 

Basically I have a pipeline in mind where I assemble my binary and then automatically run a testsuite on classic99 that goes through predefined(recorded) actions.

I have plenty of asserts in my assembly code that all point to the same "crash" routine that shows CPU register contents, PC, WP, etc.

So I thought it would be great if in that crash routine I could also automatically dump memory to a file triggered by a debug opcode.

That dump could then again automatically be picked up for further processing (e.g. looking for certain error patterns in my data structures).

 

Doing so I could automate a lot of the manual testing I'm currently doing.

 

Detecting what mode classic99 is running in, comes from the idea of putting Stevie in overdrive mode (or even let the user configure the mode in Stevie). But it should play along nicely and return to the mode it was previously in when Stevie is terminated.

 

All things considered, nothing to worry about. For most of the stuff there are potential workarounds, just thought about sharing some ideas. ?

Edited March 3, 2022 by retroclouds
Screenshot added

[Tursi]

17 hours ago, Antharian said:

I've was tracking down the bug that causes Classic99v4 to hang on a black screen occasionally during start.  I partially tracked it down to some variables that are not initialized

Haha, you say that like I knew it was still happening.

 

All variables should be initialized, so that's probably the first step - update the class constructors to put something meaningful in /everything/. Not doing so in the first place was an oversight on my part, partially caused by the amount of old code I was trying to pull in all at once.

 

[Tursi]

18 hours ago, Antharian said:

As someone who does all of their dev work in OSX or Linux (I have zero windows pc's) , I look forward to having a native tool for developing my pet TI projects and would love to contribute in any way that makes your life easy.

 

I do feel the debugger will be one of the harder parts to get working nicely cross platform, but I'm abstracting as much of it as I can