Jump to content
Tursi

Classic99 Updates

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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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. ;)

 

Share this post


Link to post
Share on other sites
13 hours ago, --- Ω --- said:

Tursi?  Is that you?  

 

Oh Crap!.jpg

Uncle Frank. Always was a bit nosey... ;)

 

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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

Share this post


Link to post
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!

Share this post


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

Oh thanks! It's working.

 

I love your signature!😂

Share this post


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

I love your signature!😂

I believe that comes (among other possibly places) from the Apple DOS 3.3 manual.  I know it says that in there.  Apple's manuals were rather witty back then.

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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

Share this post


Link to post
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?

 

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Classic99 399.017

 

- added the ability to save cart (and DSR) space in MakeCart for EA#5 and EA#3
- added the ability to write an EA#3 from MakeCart (uncompressed, with autostart if desired) 

 

http://harmlesslion.com/software/classic99

 

This seems to work for saving and restoring Minimemory. :)

 

  • Like 6
  • Thanks 2

Share this post


Link to post
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).

Share this post


Link to post
Share on other sites

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

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