Jump to content
IGNORED

Classic99 Updates


Tursi

Recommended Posts

7 hours ago, Tursi said:

No. It's showing you the actual RAM chip (not the 9900's view). The RAM chip is unaffected by the mapper settings. :)

 

We may be misunderstanding each other or I may not understand AMS. If AMS >F8000 is mapped to CPU >2000 (perhaps I am stating that backwards), should not changes to CPU >2000 – >2FFF be reflected in AMS >F8000 – >F8FFF. If so, that is not happening. When fbForth 2.0 starts up and detects 1 MiB AMS, the upper 32 KiB of AMS (>F8000 – >FFFFF) is mapped to CPU >2000 – >3FFF and >A000 – >FFFF. I would expect to see changes to that CPU space to show up in the correspondingly mapped AMS RAM, but it does not. Am I missing something?

 

...lee

Link to comment
Share on other sites

14 minutes ago, Lee Stewart said:

 

We may be misunderstanding each other or I may not understand AMS. If AMS >F8000 is mapped to CPU >2000 (perhaps I am stating that backwards), should not changes to CPU >2000 – >2FFF be reflected in AMS >F8000 – >F8FFF. If so, that is not happening. When fbForth 2.0 starts up and detects 1 MiB AMS, the upper 32 KiB of AMS (>F8000 – >FFFFF) is mapped to CPU >2000 – >3FFF and >A000 – >FFFF. I would expect to see changes to that CPU space to show up in the correspondingly mapped AMS RAM, but it does not. Am I missing something?

 

...lee

 

The mapping was matching my own expectations, page 0 is >00000, page 16 is >10000, page 40 is >28000, etc.

Link to comment
Share on other sites

3 hours ago, Lee Stewart said:

 

We may be misunderstanding each other or I may not understand AMS. If AMS >F8000 is mapped to CPU >2000 (perhaps I am stating that backwards), should not changes to CPU >2000 – >2FFF be reflected in AMS >F8000 – >F8FFF. If so, that is not happening. When fbForth 2.0 starts up and detects 1 MiB AMS, the upper 32 KiB of AMS (>F8000 – >FFFFF) is mapped to CPU >2000 – >3FFF and >A000 – >FFFF. I would expect to see changes to that CPU space to show up in the correspondingly mapped AMS RAM, but it does not. Am I missing something?

 

...lee

Your description is correct, but my testing is limited as I haven't written any AMS software. As always, give me a debug log. ;) You can dump the AMS registers in the newest version of Classic99 (399.15) by typing "AMS", which will show you what's mapped where by dumping it to the debug log.

 

When I start FBForth (2.0:12), I do see it tweaking AMS. At the end, this is what I see in the debug. And note that if I have misinterpreted this here, that's just me getting it backwards:

 

AMS Mappers:
0: >0000 (0000 -> 000000) *
1: >0100 (1000 -> 001000) *
2: >F8F8 (2000 -> 18F8000)
3: >F9F9 (3000 -> 19F9000)
4: >0400 (4000 -> 004000) *
5: >0500 (5000 -> 005000) *
6: >0600 (6000 -> 006000) *
7: >0700 (7000 -> 007000) *
8: >0800 (8000 -> 008000) *
9: >0900 (9000 -> 009000) *
A: >FAFA (A000 -> 1AFA000)
B: >FBFB (B000 -> 1BFB000)
C: >FCFC (C000 -> 1CFC000)
D: >FDFD (D000 -> 1DFD000)
E: >FEFE (E000 -> 1EFE000)
F: >FFFF (F000 -> 1FFF000)
(* = not mappable)

I think this explains what you're seeing though. If you're writing duplicate values to the registers as this suggests, then you're running into a partial implemention in the debugger. Honestly, I slapped this in for Adamantyr and didn't expect anyone else to even blink. Anyway - you can see the addresses it's claiming are mapped are far greater than you expect. This is because Classic99, as shipped, is currently running a 32MB AMS card, which I did to support someone else's project. It didn't break anything that I could see, so I left it.

 

Unfortunately, to make the debugger patches as quick as possible, I restricted them to 1MB of space. This was mostly because the 32MB stuff was embroiled in ifdefs that I didn't have time to re-understand. So, Lee, FBForth is actually writing the data aimed at >2000 all the way up at >18F8000 in the 32MB RAM, which you can't access in the debugger.

 

So, technically it's working, and technically the debugger is still incomplete. If it's useful to you guys, I can bump the priority to clean up that system so that the size you configure is really the size you get, but I've spent too much time on it this week already. :)

 

 

 

  • Like 2
Link to comment
Share on other sites

7 hours ago, Tursi said:

If it's useful to you guys, I can bump the priority to clean up that system so that the size you configure is really the size you get, but I've spent too much time on it this week already. :)

 

That would be nice, but I am not requesting that because, ultimately, my AMS mapping scheme (copied from the TurboForth implementation) needs to be checked against a 1 MiB AMS on real iron.

 

...lee

Link to comment
Share on other sites

14 hours ago, Lee Stewart said:

That would be nice, but I am not requesting that because, ultimately, my AMS mapping scheme (copied from the TurboForth implementation) needs to be checked against a 1 MiB AMS on real iron.

I'm sure it's okay. 1MB only pays attention to one of those two bytes. ;)

 

Link to comment
Share on other sites

  • 1 month later...

So I have a strange situation with Classic 99:

I recently transferred a disk from my TI to my PC using HDX. The main program on the disk, ELFASM, loads, saves and runs just fine on real hardware, and lists normally when viewed with TI99dir. However, when I try to load it in RXB (or XB) using Classic99, the program crashes, and when I try to list it the first few lines are jumbled and the emulator then crashes. Weird.

I'm sure there must be a rational explanation here...

 

ADDENDUM: I just tested in js99er and there are no issues there.

 

ELF.dsk

  • Like 1
Link to comment
Share on other sites

16 hours ago, Vorticon said:

So I have a strange situation with Classic 99:

Thanks. I was misinterpreting the cluster list for fragmented files on image disks. New version 399.016 fixes it.

 

http://harmlesslion.com/software/classic99

 

(Files with only 1 or even 2 clusters were usually fine, but a third cluster would be off, and this file had 3 ;) )

 

 

Edited by Tursi
  • Like 6
Link to comment
Share on other sites

8 hours ago, Tursi said:

Thanks. I was misinterpreting the cluster list for fragmented files on image disks. New version 399.016 fixes it.

 

http://harmlesslion.com/software/classic99

 

(Files with only 1 or even 2 clusters were usually fine, but a third cluster would be off, and this file had 3 ;) )

 

 

Thanks!

Link to comment
Share on other sites

  • 1 month later...

@Tursi, Was there ever a resultion to a previous enhancement request to save MiniMemory locations from 7000 - 7fff and then be able to reload it again later? This would emulate the battery backup of the memory in the MM module. The Easy Debug has an option to save memory locations but that is only to Tape (CS1). 

 

I know that this was asked before but I could not find an answer or if it was ever implemented somehow.

 

Regards,Truper.

Edited by Truper
Had not finished my question.
Link to comment
Share on other sites

14 hours ago, Truper said:

@Tursi, Was there ever a resultion to a previous enhancement request to save MiniMemory locations from 7000 - 7fff and then be able to reload it again later? This would emulate the battery backup of the memory in the MM module. The Easy Debug has an option to save memory locations but that is only to Tape (CS1). 

MiniMemory non-volatile RAM has been implemented in Classic99 since August 2017. So yes, as far as I know! ;)

 

  • Like 1
Link to comment
Share on other sites

Oh, now I see that the MM memory stays in tact when the MM cartridge is removed. I had not noticed that before. Thank you for that.

 

Is there any way that the memory can be saved and then later restored, same as using the S (save) and L (load) options in Easy Bug?

 

Link to comment
Share on other sites

1 hour ago, Truper said:

Oh, now I see that the MM memory stays in tact when the MM cartridge is removed. I had not noticed that before. Thank you for that.

 

Is there any way that the memory can be saved and then later restored, same as using the S (save) and L (load) options in Easy Bug?

 

You can save all 64 KiB of CPU RAM/ROM space from the debugger with “Debug”-->“Dump RAM” (F10). Not sure how you would restore the MM RAM, however.

 

...lee

Link to comment
Share on other sites

42 minutes ago, Lee Stewart said:

You can save all 64 KiB of CPU RAM/ROM space from the debugger with “Debug”-->“Dump RAM” (F10). Not sure how you would restore the MM RAM, however.

Yep, tried that and I did get the memory dump file but could not find any way to restore it. ?

 

The dump included the MM RAM from 7000 -> 7FFF as well.

Link to comment
Share on other sites

16 minutes ago, Truper said:

Yep, tried that and I did get the memory dump file but could not find any way to restore it. ?

 

Though not a very convenient way to do it, you could extract the >7000 – >7FFF block into a memory image file that could be (re)loaded via file opcode 5 (LOAD). You probably would need an ALC routine to do this. Even better, would be to write such a routine that could also SAVE (opcode 6) the relevant memory image to a file. Someone may have already done this, but it might be fun to write such a program. ?

 

...lee

  • Like 1
Link to comment
Share on other sites

2 hours ago, Lee Stewart said:

 

Though not a very convenient way to do it, you could extract the >7000 – >7FFF block into a memory image file that could be (re)loaded via file opcode 5 (LOAD). You probably would need an ALC routine to do this. Even better, would be to write such a routine that could also SAVE (opcode 6) the relevant memory image to a file. Someone may have already done this, but it might be fun to write such a program. ?

Classic99's Save Memory option includes saving as EA#5 - but the MiniMemory doesn't include an EA#5 loader. The save is in the debugger under Make->Save Memory as Program. (Emulator must be breakpointed with F1 before it activates).

 

I guess just for MiniMem and maybe XB I can add EA#3. There aren't too many other use cases since it's usually easier to build software outside of the emulator, but good for testing and saving off old programs.

 

  • Like 1
Link to comment
Share on other sites

This may be useful with the Basic Support Module too, as it can have 2K of RAM, although looking at the one I have with that option, it looks like the RAM might actually be in the GROM space (4K of GROM in a 2532 and 2K of RAM in a 6116). Normally, that second socket would have a second 2532 to complete a full, 6K GROM. Note that this would be on an EGROM cartridge board--commonly used for true TI prototypes (as opposed to the much more common QUAL units).

Link to comment
Share on other sites

  • 2 weeks later...

Classic99 399.018

 

- Make the disk name more consistent on FIAD disks - it wasn't always returning just the folder or just 10 chars in sector or record emulation (DSK.DISKNAME.FILENAME always worked though)

- Make getting the disk name from a disk image not leak a file handle ;)

 

https://harmlesslion.com/software/classic99

 

  • Like 3
  • Thanks 1
Link to comment
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...