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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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