Jump to content
Tursi

Classic99 Updates

Recommended Posts

1 hour ago, OLD CS1 said:

Is the method for doing so with XB in the manual, or would it be similar (I assume you are effectively calling the internal module name?)

Answered my own question: changed the rom0 line to indicate 0004 rather than 0008 for the index to the Extended BASIC built-in cartridge.  Works a treat.

Share this post


Link to post
Share on other sites
On 5/3/2021 at 11:58 AM, OLD CS1 said:

Is the method for doing so with XB in the manual, or would it be similar (I assume you are effectively calling the internal module name?)

 

I assume a scheduled task (cron job) with a dead-man switch is in place.

I HAVE THOUGHT ABOUT THAT! ;)

 

Share this post


Link to post
Share on other sites
On 5/3/2021 at 1:05 PM, OLD CS1 said:

Answered my own question: changed the rom0 line to indicate 0004 rather than 0008 for the index to the Extended BASIC built-in cartridge.  Works a treat.

Yeah, you got it. I'm going to change that system in the future, since it's really fragile relying on indexes (especially now that the cartridges come from an external DLL), but it's not on the 'soon' list. ;)

 

  • Like 2

Share this post


Link to post
Share on other sites

Classic99 399.044

 

A bit of an update primarily to make debuggers and app players happy. ;)

 

- add support for "speed keys" always being available per INI
- keep title in app mode when speed is changed
- add support for CPU opcodes that can change speed, breakpoint, and debug
- slight shuffling of F keys F5-F8 to better align with Realms of Antiquity
- auto-open debugger when a breakpoint happens
- updated manual

 

http://harmlesslion.com/software/classic99

 

"Speed keys" let you have always-available function keys for CPU Normal, CPU Overdrive and System Maximum - they sit on top of F6, F7 and F8 respectively. It also enables F11 as a toggle between normal and system maximum, in a nod to MAME. This of course means these keys are NOT available to the TI side (but the FCTN-number equivalents are, of course).

 

To enable this, set emulation/enableSpeedKeys=1 in the INI (the easy way is start Classic99 then close it, so the new entries are created, then you can just search for enableSpeedKeys).

 

This little tables shows the layout of the hot keys in various modes. There are some small changes in the debug keys from previous versions as I wanted to get off F5 for always-on keys. 

Hotkeys:

            F1          F2          F3          F4          F5          F6          F7          F8          F9          F10         F11         F12         HOME
normal      Fctn-1      Fctn-2      Fctn-3      Fctn-4      Fctn-5      Fctn-6      Fctn-7      Fctn-8      Fctn-9      Fctn-10     Ctrl-1      Ctrl-2      Ctrl-U
Control     Paste       Copy                                Screenshot1*Screenshot2*Sprites*    Background*                                     Reset*      Debugger
SpeedKeys=1                                                             CPU Normal  Overdrive   Maximum                             Turbo
Debugger    Breakpoint  Step        Step Over               CPU Slow    CPU Normal  Overdrive   Maximum     Charset     Dump RAM    Turbo       LOAD

* - control key active only with debugger open

CPU opcodes were requested on and off and I decided that if I had done this before, I wouldn't have had to do the keyboard tweaks now. ;) So you can now convert some illegal opcodes into Classic99 debug opcodes.

 

To enable them, set debug/enableDebugOpcodes=1 in the INI (same easy way as above). That will activate these opcodes:

 

These instructions should be safe to leave in finished code and should have no effect on hardware. Instruction timing in Classic99 should be pretty much the same as hardware. (Follow instructions below for c99_dbg to make these statements true!)

Hex   Mneumonic  Purpose         Cycles
0110  c99_norm   CPU normal      6 (illegal opcode timing)
0111  c99_ovrd   CPU overdrive   6
0112  c99_smax   System Maximum  6
0113  c99_brk    Breakpoint      6
012r  c99_dbg    debug printf    16 (one illegal opcode and one jmp)

Debug printf needs a little explanation. The instruction itself is THREE words long.


In the first word, there are 16 possible hex opcodes – the ‘r’ in the opcode is where you put the register number you want to print, from 0-F. If you don’t want to print a register, use any one of them.


In the second word, and this is very important, place a dummy JMP instruction after the hex in order to branch over the argument. This should almost always be >1001. Note that Classic99 DOES NOT PARSE this opcode, but real hardware will. (If you turn the feature off, then it will behave like real hardware, so always test that way).


The third word is the address of the format string. You can look up printf format strings to see how to format it, but note that only types %d, %u, %c, %X and %x will be allowed (you should be able to use any format prefixes, though). The string must be NUL terminated (that is, the last byte must be 00), and it must be less than 128 bytes.


So for instance, if you have this string at >A000: The value of my register is: >%X\0


Then you encode your instruction to print R1 like so: 0121 1001 A000


The debugger will show: c99_dbg(1) >A000,R1

- The (1) is the offset specified in your JMP. (It does NOT verify that it really is a JMP though!) It’s just a reminder that you should see ‘1’ there.

- >A000 is the address of the format string in CPU RAM.

- R1 is the register passed to the format string.


Assuming R1 contains >8765, the debug will emit in the debug panel as: CODE: The value of my register is >8765
 

I thought for a while about various ways to get fancier than a single register, but it's probably better to use the debugger for looking at more serious data.

 

  • Like 7

Share this post


Link to post
Share on other sites
59 minutes ago, Tursi said:

Classic99.045

 

- fixes the flicker onscreen during overdrive

This fixes the flicker I was experiencing in all CPU modes.

  • Like 1

Share this post


Link to post
Share on other sites

I guess it was always feasible, I just saw it most in Overdrive ;)

 

Share this post


Link to post
Share on other sites

I like the debug instructions. An additional one that dumped all the registers to the log could come in handy. In the extreme you could have a instructions that caused user defined functions in a scripting language to be executed on the host. But when I need something like that I just change the code of my emulator, so that's not a request from me. 🙂

 

One thing I sometimes have trouble with, is when I need to continue execution from a breakpoint with a certain key or joystick button pressed, which can be difficult to coordinate if its a key (like tab) that does something else in Windows. Any solution for that?

  • Like 1

Share this post


Link to post
Share on other sites
18 hours ago, OLD CS1 said:

This fixes the flicker I was experiencing in all CPU modes.

Same here.  Thanks for the fix.

  • Like 1

Share this post


Link to post
Share on other sites
9 hours ago, Asmusr said:

I like the debug instructions. An additional one that dumped all the registers to the log could come in handy. In the extreme you could have a instructions that caused user defined functions in a scripting language to be executed on the host. But when I need something like that I just change the code of my emulator, so that's not a request from me. 🙂

 

One thing I sometimes have trouble with, is when I need to continue execution from a breakpoint with a certain key or joystick button pressed, which can be difficult to coordinate if its a key (like tab) that does something else in Windows. Any solution for that?

Remind me about the scripting language sometime after 4.0 is out, I really do NOT want that hanging over me right now. ;)

 

Breakpoints with keys active is occasionally an issue for me too... usually I can get away with forcing the value I want rather than the key actually being down.

 

Dumping registers to the log -- but you already have all the registers on the screen? Are you capturing the debug log with an external tool? The only correct answer to earn that feature is yes. ;)

 

  • Like 2
  • Haha 1

Share this post


Link to post
Share on other sites

The update history is messed up, but the description is fine.

 

If you care about the update history, read it here:

 

https://github.com/tursilion/classic99/commits/master

 

I pasted the wrong buffer into the update script, but that's all pretty old script. Need to replace it if I can ever stop updating the old version and get 4.0 out ;)

 

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)
15 minutes ago, Tursi said:

The update history is messed up, but the description is fine.

 

If you care about the update history, read it here:

 

https://github.com/tursilion/classic99/commits/master

 

I pasted the wrong buffer into the update script, but that's all pretty old script. Need to replace it if I can ever stop updating the old version and get 4.0 out ;)

 

I'm actually wondering if Classic99 v4.0 or Tilda will get released first. Probably Tilda ;-).

Edited by jrhodes
  • Like 1
  • Haha 3

Share this post


Link to post
Share on other sites
4 hours ago, jrhodes said:

I'm actually wondering if Classic99 v4.0 or Tilda will get released first. Probably Tilda ;-).

Shots fired across the bow! At both of them. :D

  • Haha 1

Share this post


Link to post
Share on other sites
Posted (edited)
4 hours ago, Tursi said:

Indeed! What's the prize? ;)

 

@PeteE & @Tursi, who ever releases first, i won't tease/bug/pester for at least 6 months. 🙂

Edited by jrhodes
  • Haha 2

Share this post


Link to post
Share on other sites

I was playing with AppMode tonight and have some suggestions:

  1. Config file option to prevent updating classic99.ini at program exit
  2. Option to lock full screen mode (or)
  3. Option to only allow specified video settings
    (for example, sections which can be cycled by the user called video0, video1, etc., with settings in each)
  4. A key press to quit the program when started or locked in full-screen
    (when no close gadget is available and ALT-F4 does not work)

Share this post


Link to post
Share on other sites

I don't know about /locking/ to full screen mode. What's wrong with a user preferring a window - why is your app so special that it deserves to dominate the machine? (Not you personally, just a rhetorical question.) On the other hand, since the one case of actually using AppMode so far opened the INI to the users, I suppose users like me who hate it can turn it off. ;)

 

There are no video settings anymore, so 3 is off the table. Classic99 full screen uses the desktop now.

 

The option to prevent writing the INI at exit makes sense... in fact that should probably be the AppMode default, although making it configurable doesn't bother me. Nothing that's in it can be changed in app mode, so re-writing it is a little pointless.

 

I thought I had put some kind of full-screen exit in there, but I can't seem to find one. I can enable Alt-F4 by configuration... it was not enabled in the first place because in the early days, I would still hit alt with function keys instead of number keys, and Alt-F4 to break BASIC wasn't meant to exit the emulator. ;)

 

 

  • Like 2

Share this post


Link to post
Share on other sites

Classic99 399.047

 

- change stretchMode values to defines
- add LockFullScreen switch
- add enableAltF4 switch
- add enableINIWrite switch
- add c00_quit debug opcode to CPU

- fix disassembly for c99_dbg opcode
- update manual

 

The new INI settings are meant for AppMode, as above.

 

emulation/enableINIWrite - default is '1' to allow it. Can be set to '0' and then the settings will never be written on close.

emulation/enableAltF4 - default is '0', ALT and F4 are TI keys. When set to '1', Alt+F4 will close the emulator like a good Windows app.

video/LockFullScreen - default is '0'. When set to '1' the app ignores StretchMode and won't let you exit out of full screen mode. Use with caution, if you don't have another way out you will have to kill the emulator to close it.

 

The new debug opcode gives AppMode programs a way to implement a 'quit' option - opcode 0x0114 (read as c99_quit) when enableDebugOpcodes is set to 1 will exit the emulator.

 

Manual is updated with all of the above.

 

http://harmlesslion.com/software/classic99

 

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites
5 hours ago, Tursi said:

why is your app so special that it deserves to dominate the machine? (Not you personally, just a rhetorical question.)

Because everyone full-screens every window, anyway. Have a 4k monitor? Browser is full screen. Without fail. :lolblue:

Share this post


Link to post
Share on other sites
1 hour ago, OLD CS1 said:

Because everyone full-screens every window, anyway. Have a 4k monitor? Browser is full screen. Without fail. :lolblue:

Oi, I did what you asked! ;)

 

And no. I have two 4k monitors. Never have a full screen window unless I am watching a movie or playing a 3D game. The monitor is larger than my field of view, so I literally can not comfortably use a full screen window. ;)

 

  • Like 3
  • Haha 1

Share this post


Link to post
Share on other sites
15 minutes ago, Tursi said:

Oi, I did what you asked! ;)

You did, and in record time, as well.  Makes for a nice little TI-99 game package; thank you!

 

16 minutes ago, Tursi said:

And no. I have two 4k monitors. Never have a full screen window unless I am watching a movie or playing a 3D game. The monitor is larger than my field of view, so I literally can not comfortably use a full screen window. ;)

You are obviously not one of my customers or family.  I had one lady who wanted multiple 19" monitors, as a specific request for specific reasons.  You see, she ran everything full screen, and 19" was the largest she could do and maintain a sane program size.  But since she needed to use multiple programs at once, she needed multiple screens.  I set her up with three 19" monitors and she was happy as a pig in slop.

 

She was not, by the way, the lady who needed a larger and higher-resolution monitor to accommodate all of her desktop icons.

 

I credit my abhorrence to full-screen applications to my exposure to the Amiga.  Windowing in AmigaOS is just so fluid and easy, and there is little need for programs to run full screen.  Any program which benefits from its own screen can either open a screen (or "virtual desktop") or be convinced to if it is an MUI program. Limited ChipRAM is also why I tend to close unused windows, now even with AmigaOS enhancements which render icons in FastRAM and even in Windows -- not just an old habit, but also keeps a cleaner work space.

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Tursi said:

The new debug opcode gives AppMode programs a way to implement a 'quit' option - opcode 0x0114 (read as c99_quit) when enableDebugOpcodes is set to 1 will exit the emulator.

This is also a very cool addition.  This will allow a program to completely quit out.  Now a TI game or program can run more like a native application and exit when it wants.  Nice!

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, OLD CS1 said:

Because everyone full-screens every window, anyway. Have a 4k monitor? Browser is full screen. Without fail. :lolblue:

I sometimes see people maximizing their windows, and I really have problems to understand why. Not because I don't like it, I fail to see the benefit. When I click on the maximize button, it is almost always because I missed the minimize button next to it.

 

If I had to work with maximized windows, I really could not imagine how to master that. I usually have 4-5 applications or windows running in parallel, like the VLC for watching TV, the Firefox, Thunderbird, a terminal window, and jEdit. Well, maybe a second terminal window. I mean, while I'm hacking my programs, I'd like to follow the show on TV, and also to watch new incoming mails. And I need to check whether the compile process is done.

 

My sister also tends to maximize the browser window, and I keep asking why she's doing that, when in most cases the contents don't adapt, and if they did, become basically unusable due to misplaced components and unreadably long lines. I wonder whether this depends on the technical background of the people.

 

Right now I have a 27" monitor with QHD resolution (2560x1440), and this is quite a good compromise, as it turned out. Bigger than FullHD, but not so large as 4K. I had a 4K monitor for three days; I actually put it back in its box and shipped it back. I had to face so many inconveniences with 4K that I could not imagine to seriously work with it. For instance, not all websites use relative sizes; one of the pages I regularly visit has a "width:1000px" for its main panel in its CSS (the news portal "Spiegel"). Also, fullscreen applications became extremely slow, while the VLC showing a HD TV program was at its limit, so the window for watching TV became much smaller on 4K.

 

 

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...