nibbler Snake Snake for Mini Memory (a Nibbler Arcade Version in Assembly)

[Tursi]

23 hours ago, tmop69 said:

@Tursi I'm curious how you implemented this command mod. Is a change in the disk/basic rom? Since it's a very useful addition it would be nice to add also in the MiSTer TI99 core.

No, I wrote the Classic99 DSR, it is not derived from the TI DSR at all. (In fact, it actually consists largely of a set of fixed addresses which are intercepted by the emulation, and the DSR itself runs almost entirely in the emulator's C code). Since it doesn't require any TI RAM to function, CALL FILES(0) works fine (except a lot of clever software fails if you don't leave breadcrumbs in the VDP, so I had to add that back in).

 

However, you would not easily be able to replicate this with the real TI DSR, as it uses VDP RAM for buffers and status information. It tends to break more than it helps, so even I don't really use it...

[ti99iuc]

Call Files (0) saved me a lot of time to start games on classic99 and be able to test them. I remember robopods from the casette tape was one of them. The original game from cassette tape was not present, only modified versions of it, classic99 able to me to preserve the game as in original tape ? I loved and still love the call files (0) possibility. 

 

Also surprised when I have discovered that CALL FILES (0) was also possible on the real thing using Rxb2020 by Rich @RXB

 

It also helper a lot in dumping software from cassette tapes without have boring sessions to split the listing in to parts to be saved on disk. 

 

So, W CALL FILES (0) and this nice community of 99ers 

 

Love you guys ??

Edited November 16, 2021 by ti99iuc

[speccery]

Perhaps a bit off-topic, but with regards to CALL FILES(0) my ET-PEB board does not use any VDP RAM for buffers, in fact I haven't even implemented CALL FILES. I have not worked on that project for a while, except now that I wanted to play Snake Snake and discovered and fixed a bug related to this. I looked at the scratchpad RAM pointer to the top of RAM useable by BASIC, and with ET-PEB is the top of VDP RAM, i.e. 16383. This is not a surprise, as my simple and stupid DSR does not allocate RAM on the TI side. The file buffers are kept in the RAM of the microcontroller. That probably means the ET-PEB will not support some software as its not leaving any breadcrumbs behind either, like @Tursi mentioned for classic99.

[Asmusr]

21 hours ago, ti99iuc said:

Also surprised when I have discovered that CALL FILES (0) was also possible on the real thing using Rxb2020 by Rich

I'm confused because I thought FILES was a DSR subprogram that didn't depend on the version of BASIC but on the disk controller? But even a real disk controller could implement CALL FILES(0) since it means that no files can be open, so there shouldn't be any need to allocate buffers, or what? 

[RXB]

15 minutes ago, Asmusr said:

I'm confused because I thought FILES was a DSR subprogram that didn't depend on the version of BASIC but on the disk controller? But even a real disk controller could implement CALL FILES(0) since it means that no files can be open, so there shouldn't be any need to allocate buffers, or what? 

Cool thing about GROM/GRAM is when in control it can over ride the DSR in cards like Disk Controller or Hard Drive Controller or RAMDISK.

I put a RXB command that runs from PROGRAM MODE or EDIT MODE in RXB and added features that do not exist in normal CALL FILES

 

          FILES          subprogram                            PAGE  F1
          -------------------------------------------------------------
 
          Format         CALL FILES(number)
 
                         CALL FILES(numeric-variable)
 
          Description
 
          The FILES subprogram differs from the Disk Controller FILES
          on the CorComp, TI, Myarc or Parcom versions. All of these
          require a NEW after CALL FILES. NEW is executed after the
          FILES subprogram in RXB, so there is no need to use NEW.
          Also RXB FILES accepts values from 0 to 15 unlike the other
          FILES routines that can only accept 0 to 9. Each open file
          reduces VDP by 534 bytes, plus each file opened will use
          518 bytes more. Only RXB has a valid CALL FILES(0) or a
          CALL FILES(15) that works.
 
          Programs
 
          FILES opens usual buffers.    | >CALL FILES(3)
                                        |
          FILES ends the program and    | >100 CALL FILES(1)
          executes NEW.                 |
                                        | 
          Only possible in RXB          | >100 CALL FILES(15)
                                        | >SIZE
                                        |
          Only possible in RXB          | >CALL FILES(0)
                                        | >SIZE
                                        |
                                        

          Will display 5624 Bytes of Stack free and 24488 Bytes of
          Program space free. At this point up to 15 files may be
          open at the same time. Not recommended but possible now.
          Also 0 files now is possible in RXB.

          Options
          See XB for even more powerful applications made easy.
          For example CALL XB("DSK1.LOAD",1)  will do a 
          CALL FILES(1) then NEW then RUN "DSK1.LOAD" AUTOMATICALLY

[Tursi]

17 minutes ago, Asmusr said:

I'm confused because I thought FILES was a DSR subprogram that didn't depend on the version of BASIC but on the disk controller? But even a real disk controller could implement CALL FILES(0) since it means that no files can be open, so there shouldn't be any need to allocate buffers, or what? 

Possibly, if you didn't want disk to work at all. But you could just turn off the PEB too.  That said, the TI Disk controller still uses some VDP RAM to indicate that it has already initialized itself - that includes the number of buffers allocated. So you'd still need somewhere to store that information.

[RXB]

6 minutes ago, Tursi said:

Possibly, if you didn't want disk to work at all. But you could just turn off the PEB too.  That said, the TI Disk controller still uses some VDP RAM to indicate that it has already initialized itself - that includes the number of buffers allocated. So you'd still need somewhere to store that information.

Actually if you do use RXB on real iron you can do a CALL FILES(0) and still open a file as XB does not understand you should not.

You can test this on a real TI and see everything works the same as it should.

Problem is even in Program mode or Edit mode will assume it is a temporary buffer and over write it on garbage collection.

Also turning off PEB would kill the 32K for use. I took over a month of research to create CALL FILES(0) to CALL FILES(15) in testing.

Edited November 17, 2021 by RXB

[ti99iuc]

All I can say is that it works really well. I loaded about 10 software with CALL FILES (0) using TI99 with RXB2020, Cassette Tape and PEB for saving to disks. 
It was lovely perfect

Edited November 17, 2021 by ti99iuc

[Tursi]

4 minutes ago, RXB said:

Cool thing about GROM/GRAM is when in control it can over ride the DSR in cards like Disk Controller or Hard Drive Controller or RAMDISK.

I'm not quite clear that I understand the VDP layout with CALL FILES(0)... disk still works, so where are the VDP buffers being stored by the TI disk controller? It works fine with Classic99's DSR, but Classic99's DSR doesn't care about the VDP layout. When I do CALL FILES(0) with the TI controller (in Classic99) and try to load a PROGRAM file, it just spins in the DSR (the TI controller has very little error checking about memory layout). This is with RXB2020D, in case it's already been fixed.

 

What I noticed is that for all values of CALL FILES except 0, it was being passed to the disk controller card. But for 0, RXB was setting the top of VRAM itself but not creating the disk controller's little header block in VDP. The next time a call went to the DSR it got lost looking for that data.

 

Is that already fixed in a later version?

[RXB]

38 minutes ago, Tursi said:

I'm not quite clear that I understand the VDP layout with CALL FILES(0)... disk still works, so where are the VDP buffers being stored by the TI disk controller? It works fine with Classic99's DSR, but Classic99's DSR doesn't care about the VDP layout. When I do CALL FILES(0) with the TI controller (in Classic99) and try to load a PROGRAM file, it just spins in the DSR (the TI controller has very little error checking about memory layout). This is with RXB2020D, in case it's already been fixed.

 

What I noticed is that for all values of CALL FILES except 0, it was being passed to the disk controller card. But for 0, RXB was setting the top of VRAM itself but not creating the disk controller's little header block in VDP. The next time a call went to the DSR it got lost looking for that data.

 

Is that already fixed in a later version?

As it should as you did CALL FILES(0) right?

Would you expect it to work after using CALL FILES(0)?

I could set up a header but it would be using some bytes for it and the idea was to get the max memory possible without any file access.

After all you did type CALL FILES(0) so if you do something stupid like open a file, you did screw up on purpose how should I fix stupid?

[RXB]

As for RXB version 2020E was released but I guess no one is using it. 

Every report is RXB 2020C or 2020D so far only person I see using 2020E is Greg.

Working on RXB 2022 now and should release a beta.

Will take a look at CALL FILES and see what I can do...

[Tursi]

2 hours ago, RXB said:

Actually if you do use RXB on real iron you can do a CALL FILES(0) and still open a file as XB does not understand you should not.

You can test this on a real TI and see everything works the same as it should.

 

1 hour ago, RXB said:

As it should as you did CALL FILES(0) right?

Would you expect it to work after using CALL FILES(0)?

I could set up a header but it would be using some bytes for it and the idea was to get the max memory possible without any file access.

After all you did type CALL FILES(0) so if you do something stupid like open a file, you did screw up on purpose how should I fix stupid?

 

I don't think you should be calling me stupid, Rich... you said it works. ti99iuc also said it works. That's why I tried it.  No file access is what I expected.

 

As for the version 2020D was the last version you sent me for Classic99

 

Edited November 17, 2021 by Tursi

[HOME AUTOMATION]

I don't think RXB meant to imply that you were being stupid, but rather that the expectation was exceptionable within the context as perceived.

 

       -DA-

[RXB]

1 hour ago, Tursi said:

 

 

I don't think you should be calling me stupid, Rich... you said it works. ti99iuc also said it works. That's why I tried it.  No file access is what I expected.

 

As for the version 2020D was the last version you sent me for Classic99

 

LOL sorry just pointing out if you do something you know is going to crash and not expect it to crash what would you call that?

If you have a 32K or SAMS this is never needed so I guess I did something stupid for console only.

I would have set a flag but >8370 (HIVDP) would need to be checked each time line is edited or program sequenced.

CALL FILES(0) was mostly needed for CASSETTE loading or saving, not DISK or HARDDRIVES, this was the request that made this change.

So stupid me made a routine designed for CASSETTE but works with DISK or HARD DRIVES too.

I just assumed no one would do a CALL FILES(0) then attempt to open files too?

 

[senior_falcon]

19 hours ago, RXB said:

Actually if you do use RXB on real iron you can do a CALL FILES(0) and still open a file as XB does not understand you should not.

You can test this on a real TI and see everything works the same as it should.

 

Rich, you don't seem to be aware of this post. Therefore, it logically follows that some nefarious person has hacked into your account and is posting this kind of foolishness with the sole intention of making you look bad. I think you should look into this.

[RXB]

Ok after Tursi pointed out something about CALL FILES(0) I found a fix for RXB:

 

 

[GDMike]

On 11/17/2021 at 2:48 PM, Tursi said:

how should I fix stupid?

I'm watching this..I can relate!

[HOME AUTOMATION]

On 11/17/2021 at 4:22 PM, HOME AUTOMATION said:

I don't think RXB meant to imply that you were being stupid, but rather that the expectation was exceptionable within the context as perceived.

    @Tursi

Perhaps, I too should attempt to acquit myself ...after all, it was your tool I used to create the image ...mostly!

 

 

I imagine you could add-to/modify your tool to handle similar programs' conversions, should some pop-up.?

 

        P.S. As a result of the way I used this, a couple bytes at >A000  are over-written before the game starts.

 

Edited November 19, 2021 by HOME AUTOMATION

[Tursi]

11 hours ago, RXB said:

Ok after Tursi pointed out something about CALL FILES(0) I found a fix for RXB:

That seems like a good solution!

 

CALL FILES(0) in Classic99 is a case of the emulation being able to bend the laws of physics a bit - in this case because the Classic99 DSR has access to unlimited memory not attached to the hardware it can operate even with no buffers available. The real machine can't do that.

 

It does introduce a discrepancy... CALL FILES(0) will be different in Classic99 between RXB and normal XB. I think that's okay (and it's far better than crashing), just be aware of it in case people ask in the future. I will tell them that RXB is designed for real hardware so the Classic99 hack doesn't apply there.

 

[HOME AUTOMATION]

Oops ...left out the Sorry!

 

 Sorry.

 

[RXB]

58 minutes ago, Tursi said:

That seems like a good solution!

 

CALL FILES(0) in Classic99 is a case of the emulation being able to bend the laws of physics a bit - in this case because the Classic99 DSR has access to unlimited memory not attached to the hardware it can operate even with no buffers available. The real machine can't do that.

 

It does introduce a discrepancy... CALL FILES(0) will be different in Classic99 between RXB and normal XB. I think that's okay (and it's far better than crashing), just be aware of it in case people ask in the future. I will tell them that RXB is designed for real hardware so the Classic99 hack doesn't apply there.

 

Thanks, this fix will work in Classic99 or MESS or Real Hardware.

It looks to see if HIVDP (>8370) value is above the address which would be CALL FILES(1) and of course could only be a CALL FILES(0)

So OPEN #1:"DSK.DSKNAME.FILENAME",OUTPUT would crash with ERROR OUT OF MEMORY if you used CALL FILES(0)

[speccery]

On 11/19/2021 at 8:16 PM, Tursi said:

That seems like a good solution!

 

CALL FILES(0) in Classic99 is a case of the emulation being able to bend the laws of physics a bit - in this case because the Classic99 DSR has access to unlimited memory not attached to the hardware it can operate even with no buffers available. The real machine can't do that.

 

It does introduce a discrepancy... CALL FILES(0) will be different in Classic99 between RXB and normal XB. I think that's okay (and it's far better than crashing), just be aware of it in case people ask in the future. I will tell them that RXB is designed for real hardware so the Classic99 hack doesn't apply there.

 

..except that with ET-PEB this is what happens, no buffers get allocated on the side of the machine, since the card has it's own memory and does not use VDP memory for any buffers (the DSR space 4000..5FFF is actually RAM, containing the DSR but also transfer buffers; in addition the MCU can use nearly half of the 512K SRAM as this is not visible to the console which only sees 256K as SAMS RAM).

[.mad.]

can anyone (TURSI) tell me how to add the minimemnv.bin to the classic99 ini file.

 

i can only get the disk version of SnakeSnake to work if i select minimem from the App menu.

*this option creates and reads the minimemnv.bin file.

 

but i want to load it from GameBase with sendkeys.

[usercart0]
rom0="C|6000|2000|C:\GameBase\TI99-4A\Emulators\Classic99\MiniMem_C.Bin"
rom1="G|6000|A000|C:\GameBase\TI99-4A\Emulators\Classic99\MiniMem_G.Bin"
rom2="?|????|????|C:\GameBase\TI99-4A\Emulators\Classic99\minimemNV.bin"
rom3=
rom4="K|0000|0000|xX1CALL FILES(0)\nOLD DSK1.SNAKEBX\n\nRUN\n")
name=Gamebase
[Disk1]
Path=c:\gamebase\ti99-4a\games\snakesnake.dsk

 

thanks!

Edited December 19, 2022 by .mad.

[Tursi]

Looks like I didn't update the manual. The file type for NV RAM is 'N'. For Minimemory the load address is "7000" and the size is "1000", so "N|7000|10000|filename" should get you there.

 

[.mad.]

thanks

i tried that, but i still can't get the game to work loading minimem cart manually.

it stays on a green screen after RUN is typed.

 

when loading from the APP menu it works.

i can only GUESS it has something to do with the NVRAM file.

 

i have setup to load at DSK1

SNAKEBX

which then loads

DSK1.SNAKE-0

SNAKESNAKE.dsk