Classic99 Updates

[Tursi]

7 hours ago, retroclouds said:

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

It wasn't a hint, you'll find it repeated over and over in this thread. It has been the intended mechanism since the very first Windows version of Ami99.

 

7 hours ago, retroclouds said:

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

80k is the size of the CPU+VDP dump.  Classic99 doesn't have a SAMS dump function in it... or does it? I don't remember.

 

7 hours ago, retroclouds said:

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

Why not just open and write the file yourself from your code? Then you can write out exactly what you want in the exact format you want, or just dump a PROGRAM image file to get memory.

 

7 hours ago, retroclouds said:

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.

It's always been my standpoint that writing software /specifically/ for Classic99 is something I stand against. It may be inconvenient for some devs, but when Classic99 becomes a platform, it increases my workload. I become the go to for any issue related to that feature as the code author shrugs it off with "that's part of Classic99".

 

7 hours ago, retroclouds said:

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

I don't care how much data you write, I care how many features I need to support.  

 

[Antharian]

4 hours ago, Tursi said:

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

Haha... it's afforded me a good reason to learn more about the insides of how the 99/4a works than I have ever imagined. I've really enjoyed moving through your system.

 

I had an hour to mess around this evening and I was able to find the final bug.  It was in exactly the same spot. I thought I had initialized all the variables in the System area, but I missed nmiMask, which triggered spurious interrupt events when ever the skip_interrupt would finally drain during the first 6 operations.

 

Thank you very much for providing this amazing port and for humoring me as I poke around in it.

 

-A

[Tursi]

5 hours ago, Antharian said:

Haha... it's afforded me a good reason to learn more about the insides of how the 99/4a works than I have ever imagined. I've really enjoyed moving through your system.

 

I had an hour to mess around this evening and I was able to find the final bug.  It was in exactly the same spot. I thought I had initialized all the variables in the System area, but I missed nmiMask, which triggered spurious interrupt events when ever the skip_interrupt would finally drain during the first 6 operations.

 

Thank you very much for providing this amazing port and for humoring me as I poke around in it.

 

-A

I saw that! I accepted the merge request, but please don't get carried away right now. There's super high risk of merge conflicts and intent conflicts and I don't want to play that game or waste people's time saying "no thanks right now". I know it's moving slow, but it'll get there.

 

Unless you want to figure out why the %$##@ Allegro needs different transparency flags on each platform. That part is ticking me off.  It's the next thing I need to resolve.

 

[Tursi]

This made me play with it a bit. I didn't solve anything, but I confirmed that Windows, Mac and Linux are working correctly but still require different flags. I also found that I was using an underpowered power supply for my Raspberry PI - when I used the correct one I was able to get 60fps out of Classic99 if the Window was kept reasonably close to 1:1... the 4:1 that it launches with was still rather slow. (Also, heard audio working for the first time ). That does suggest that the PI isn't using hardware acceleration, and likely neither is the Mac or Linux build. Will need to think some about how to improve that... if I can get the rendering up to speed on the PI it looks like the rest is fine.

 

[Antharian]

3 hours ago, Tursi said:

That does suggest that the PI isn't using hardware acceleration, and likely neither is the Mac or Linux build. Will need to think some about how to improve that... if I can get the rendering up to speed on the PI it looks like the rest is fine.

Dunno if you have added the allegro.cfg file to your system (leaving it right next to the classic99 binary is good enough for it to find it for testing purposes) and then setting the logging level to debug in the [trace] section and forcing the graphics driver to opengl rather than default in the [graphics] section, should produce a pretty detailed log file right next to it called allegro.log.

 

My local build, I added a few thing to tv.cpp and the wndFlags to specify opengl as well as bringing in some includes:

#ifdef __APPLE__
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
#include <GLUT/glut.h>
#else
#ifdef _WIN32
  #include <windows.h>
#endif
#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glut.h>
#endif

  ...
  
static const int wndFlags =  ALLEGRO_WINDOWED        // or ALLEGRO_FULLSCREEN_WINDOW | ALLEGRO_FRAMELESS
                          |  ALLEGRO_RESIZABLE
#ifdef ALLEGRO_LINUX
                          |  ALLEGRO_GTK_TOPLEVEL    // needed for menus under X
#endif
                          |  ALLEGRO_OPENGL_3_0          // or ALLEGRO_DIRECT3D or ALLEGRO_OPENGL
                          |  ALLEGRO_OPENGL_FORWARD_COMPATIBLE
                          |  ALLEGRO_GENERATE_EXPOSE_EVENTS;    // maybe?
  
  ...
  
al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS, 1, ALLEGRO_SUGGEST);
al_set_new_display_option(ALLEGRO_SAMPLES, 4, ALLEGRO_SUGGEST);

 

I'm seeing the OpenGL system initialize correctly.  As for my Raspberry's, I'll try to fiddle with them this weekend a bit.

 

** edit -

Having backed all of those changes out and just looking at the logging with everything at default, I am still seeing OpenGL initialize correctly. It looks like Allegro tries to do the right thing without jumping through hoops. 

Edited March 4, 2022 by Antharian

[Tursi]

19 hours ago, Antharian said:

My local build, I added a few thing to tv.cpp and the wndFlags to specify opengl as well as bringing in some includes:

Having backed all of those changes out and just looking at the logging with everything at default, I am still seeing OpenGL initialize correctly. It looks like Allegro tries to do the right thing without jumping through hoops. 

I'm only working on it for like an hour a month right now, so I haven't really tried anything beyond "does this work?" But yeah, Allegro is supposed to select the appropriate hardware acceleration with the settings provided. But it's supposed to support alpha with those settings too, and it's supposed to maintain an image, but I still need different settings between Windows and Linux, and neither works right on the PI.

 

Not being able to see what was wrong was why I ditched Allegro and went to my own code in the first place, but at the moment I'm sure this is solvable without a bunch of custom platform code. I have not tried the Allegro examples on the PI yet to see if they also misbehave.

 

The log tips are probably helpful when I get that far, though.

 

[oddemann]

OK... So I am trying to play TOD... BUT... I was just trying.

How do I load the game in Classic99? Did the press 1... Do I need to link to a audio file?

[+jedimatt42]

1 hour ago, oddemann said:

OK... So I am trying to play TOD... BUT... I was just trying.

How do I load the game in Classic99? Did the press 1... Do I need to link to a audio file?

 

 

When I pick the Tunnels of Doom cart from the cartridge / Games menu... I get to this selection, so it wants me to press 2.  And then in the 

 

 

type in PENNIES or QUEST and hit enter... 

 

 

[oddemann]

lol... so bad... kinda did not see DISK ? hahahaha just the number ? that's bad... Yes... well... lets just forget this... nothing to see here!
New mistake will soon follow, hahahahaha

[Tursi]

Classic99 399.055

 

- treat DF128 files as headerless files by default in FiadDisk
- add ?X option to force headerless files
- fix up readability issues Word noted in the manual
 

The change to DF128 files is probably not going to hit anyone too hard, but it's important to be aware of. DF128 was the format that the TIFILES creators decided would be used for interchange with PC files - thus, files with no header were DF128 by default. Classic99 always meant to treat them this way, but it didn't before now - it would always write the header.

 

The new code is loosely tested and should work correctly. In addition, DF128 files WITH a header are still detected correctly. But this does make the options a little more important. 

 

If you MUST write a header with a DF128 output file, you now must use the ?T or ?V override to force it. (ie: DSK1.?T.DF128HEADER )

 

If you want to write some other file type with no header, because you're crazy or something, use ?X to nix the header. (This might be useful with PROGRAM SAVE type files if you know why you want it, can't think of a use anywhere else).

 

The DF128 behaviour is controlled by the existing setting "Read Windows files without ext. as DF128" (I should really drop the word 'read' there now). It should be ON by default. If you turn it off, then the above rules go away, except for ?X.

 

http://harmlesslion.com/software/classic99

 

[+jedimatt42]

These device parameters are interesting. I've been meaning to someday implement the ?W. for TIPI. 

 

What was the motive to default writing DF128 as headerless? TIPI already reads headerless files as DF128, but doesn't allow writing headerless files. Which I realize makes it difficult to have the 4A create a file for consumption by software on another platform. 

 

I'd like to reserve an alternative to ?W for TIPI to do Unix end-of-line using ?U instead. Not asking for Classic99 to implement that, just asking that it not use ?U to mean anything contradictory. 

 

[Tursi]

I actually always meant it to work that way... but when I implemented it I was overwhelmed with the amount that needed to work, and didn't really want yet another code path to test. But I was asked yesterday about any path to write headerless files (exactly for the reason you mention), and decided to go for it. It will still read files WITH a header correctly, but it won't write them unless forced. Terminal emulators using TIFILES would do the same, which would allow TIs to save and serve files for other machines as well, so it's correct usage (IMO).

 

You answered my question about TIPI and DF128. I left it alone in Classic99 yesterday because I wasn't sure.

 

I was good with ?U on the surface, but when I thought it through, I started to see problems. In my opinion ?W really means "host" in the cross-platform ecosystem. The purpose of the flag is to read and write text files for interworking with the host system -- there's little reason to read and write text files in a non-native format. Classic99 was a strictly Windows emulator, so it was easy to remember. But easy to remember isn't a good reason to lock into a bad design for the future. So to that I'd ask - does it make sense to enforce a line ending type from inside the emulator, where they don't know what the host type is, or should it just mean "host" text format? I think I'd rather change the letter (if necessary) than have TI software that only works on Windows or only works on Linux - that's starting to get silly.

 

 

 

 

[+jedimatt42]

34 minutes ago, Tursi said:

...

 

I was good with ?U on the surface, but when I thought it through, I started to see problems. In my opinion ?W really means "host" in the cross-platform ecosystem. The purpose of the flag is to read and write text files for interworking with the host system -- there's little reason to read and write text files in a non-native format. Classic99 was a strictly Windows emulator, so it was easy to remember. But easy to remember isn't a good reason to lock into a bad design for the future. So to that I'd ask - does it make sense to enforce a line ending type from inside the emulator, where they don't know what the host type is, or should it just mean "host" text format? I think I'd rather change the letter (if necessary) than have TI software that only works on Windows or only works on Linux - that's starting to get silly.

 

 

 

 

 

I look at TIPI as network appliance, and not a host operating system. It neighbors the user's PC which may be a Windows, Mac, Linux or Amiga... 

 

Outside of emulation, like in TIPI, I have a SMB share and expect most users would want ?W to write a windows end-of-line type file to use in notepad or whatever those folks do. But I personally use a linux system, and Windows CRLF is a touch of pain. If you look at TIPI as having a host, then it is a linux system. So if I always wrote text for the host, the files would be troublesome for windows users (99% of the community) through the SAMBA share. 

 

I'm all for requiring users to know what they are doing. But provide good defaults.. So the alternative approach I would use, is for there to be no ?U, but an entry you can write to PI.CONFIG to control the end-of-line for ?W operations. 

 

I have ?W and ?U implemented for Variable record files. I need to add the Display type restriction I suppose. Removing ?U and using a config item is trivial. 

 

Do you treat ?W with FIXED record files with any optimization? stripping trailing whitespace on the right? or just write the bytes that are sent? I think the TI Disk controller allows for the record to fall short, and it pads with 0 when filling in the block. I imagine none of that padding is desirable in the ?W case... ? 

 

 

 

[Tursi]

The problem isn't software that users write for themselves, but software that people write for others. It's unreasonable to say "This TI program only works under Linux but you can modify it..." Or at least, less than desirable.

 

I think your alternative of a config setting makes sense, and indeed that would be an approach for me to mirror in Classic99v4 (with the default being the host, since Classic99 would know).

 

The intent originally was that DV80 files were text files, and nothing else was. But since that didn't work right, the default settings are to never write host text files unless forced to, and to read host text files by filename extension (.TXT or .OBJ). There are options for writing DV80, all DV, DF80 or all DF explicitly as host text files, but that's really for special cases and not general use.

 

The one thing about the ? options is they are strict overrides, and the emulator doesn't question you very much - it doesn't even check the open mode. The resulting file may well be unusable depending on the options forced.  The restrictions only apply to the emulator attempting auto-detection on reads.

 

As far as writing goes, Classic99 does no interpretation of the record length, so yeah. Fixed record files would write all the spaces as well AND THEN the line ending. Not sure if that's really actually ideal, but Classic99 is treating the line ending as a record separator... I'm not going to think to hard about whether that's right, but I think it is since one might expect a DF80 to have 80 characters of meaningful information.

 

10 OPEN #1:"DSK1.?W.DUMMY",OUTPUT,FIXED 80,DISPLAY
20 PRINT #1:"HELLO"
30 CLOSE #1

 

 

[Tursi]

Classic99 399.056

 

As always, quick little tweaks lead to side effects... 055 was writing PROGRAM image files with no head too, due to not matching any of the conditions and an accidental 'else'.

 

- rename disk option for DF128 to reflect new behaviour
- fix critical bug saving program image files

 

NOTE: v55 has a critical file system bug. Do not use nor store it.
 

Please update to v56.

 

http://harmlesslion.com/software/classic99

 

Edited March 13, 2022 by Tursi

[oddemann]

!

Edited March 14, 2022 by oddemann
Please delete!

[Tursi]

Classic99 399.057

 

The new DF128 handling revealed a long standing bug in the PROGRAM LOAD handler that didn't properly validate headers. This is fixed now.

 

If you have PROGRAM files that used to load and don't now (refuses in v57, or crashes in v56), the header is probably corrupt. You can send it to me and I can probably fix it - but the most common cause is renaming V9T9 files without using a V9T9 aware tool. I recommend stock TIFILES format for files in a folder to avoid this sort of issue.

 

http://harmlesslion.com/software/classic99

 

[+arcadeshopper]

fyi at least version 399.057 the URI. is borked..

 

I can CALL TIPI("PI.HTTP://myti99.com/SNEK")  and it loads and works off the web

but URI1. set to myti99.com or HTTP://myti99.com/ both get me a reboot.. 

 

debug log:

Handling CALL TIPI("URI1.SNEK")
Load URL is 'myti99.comSNEK'
Web Send Request failed, code 12007
CALL TIPI load failed, reboot.

 

[Tursi]

A /reboot/? Reboot of what? Windows? That doesn't make any sense.

 

I don't remember ever supporting URI1...

 

Oh, that's right, the TIPI implementation is not supported.

 

[+arcadeshopper]

5 minutes ago, Tursi said:

A /reboot/? Reboot of what? Windows? That doesn't make any sense.

 

I don't remember ever supporting URI1...

 

Oh, that's right, the TIPI implementation is not supported.

 

a reboot of the ti in emulation.. says right there in your debug log

pretty sure it worked before.. /shrug

[Tursi]

So Winsock error 12007 means that the server name or address could not be resolved. That makes perfect sense since you can see in the log it's trying to look up "myti99.comSNEK" as a domain address.

I see the reboot in the debug statement is what you were talking about - that's cause TIPI resets the TI when a load fails. Bad terminology on my part to put it in the debug statement.

 

But I don't see that URI1 is borked. Where's your test with the slash included at the end?

 

[Tursi]

Just tested here with URI2 set to "http://myti99.com/" and that loaded URI2.SNEK fine. It's just a raw concatenation, so if you omit the slash, you'll get what you see in the debug log.

 

Does the real TIPI insert a slash there automatically?

 

[+arcadeshopper]

Just now, Tursi said:

So Winsock error 12007 means that the server name or address could not be resolved. That makes perfect sense since you can see in the log it's trying to look up "myti99.comSNEK" as a domain address.

I see the reboot in the debug statement is what you were talking about - that's cause TIPI resets the TI when a load fails. Bad terminology on my part to put it in the debug statement.

 

But I don't see that URI1 is borked. Where's your test with the slash included at the end?

 

ok I see what happened, I edited the ini but had classic99 open, which overwrote my edit when I exited.. undoing my change.. 

DOH

 

works with the full url and ending slash

 

 

[+arcadeshopper]

1 minute ago, Tursi said:

Just tested here with URI2 set to "http://myti99.com/" and that loaded URI2.SNEK fine. It's just a raw concatenation, so if you omit the slash, you'll get what you see in the debug log.

 

Does the real TIPI insert a slash there automatically?

 

yep..  though I had my url without the HTTP:// which doesn't work either    anyway nbd long as we know

 

[Tursi]

Okay, I'll add the slash.