a7800 and 7800basic - Question on expected behavior

[Dissy614]

I came across a situation with the a7800 emulator (v5.2) that surprised me, and was wondering if this is expected behavior or not.

 

Specifically regarding the "cart type" bytes in the .a78 header, bit 1 "supergame bank switched" and bit 2 "supergame RAM at $4000"

It seems when bit 2 is on to enable RAM and bit 1 is off, a7800 does not actually enable the RAM.  With both bits on, it does.

 

While working on a 7800basic project I added a line for "set romsize 32kRAM", which sets bit 1 off and bit 2 on, as this configuration does not use bank switching but should support RAM, but was not honored by the emulator.

 

My next test was to use "set romsize 128kBANKRAM" as that is the smallest size supported with bank switching, however 7800basic did not enable bit 2 of the header to enable RAM.

I suspect that's a bug in 7800basic.  (I'm using v0.20 which is a version or two behind, but the changelog doesn't mention this issue)

Because my final test was to include two romsize lines in my program, first "set romsize 32kRAM", and right after "set romsize 128kBANKROM"

For the purposes of assembly the second option took precedence as expected and set bit 1, but for some reason the first option is what changed the a78 header being written to include bit 2 set as well.

 

At this point a7800 worked as expected, adding RAM at $4000, and with bank switching enabled.

This is what lead me to suspect a7800 ignores bit 2 (RAM) if bit 1 isn't set, possibly (mis)assuming one has a dependency on the other.

 

On one hand I might just be missing something I should be doing to "force" RAM support without bank switching in the emulator.

On the other hand I had really hoped to keep my development environment as close to the intended hardware I was going to use.

On a third hand, enabling bank switching even if not currently used does sound like a wise practice I should be adopting...

(On a forth hand, I might need to borrow some more hands!)

 

[RevEng]

Some preamble... There were a lot of aspects of the a78 header that were left undefined for years, and while we've tamed some of them, some inconsistencies remain.

 

The supergame ram bit (bit 2, aka EXRAM) isn't a base for the banked ram bit (bit 5 aka EXRAM/X2), so 7800basic is doing the expected thing here. You don't add on a banked ram device to a ram device in a cart, rather it's an entirely different sort of implementation. That's the thinking, anyway.

 

Having two different romsizes will lead to unexpected issues, since compile time flags are being set for both formats. I've just added code to my local repo so 7800basic will error out if a second "set romsize" is encountered.

 

Regarding 32k+ram being non-functional in a7800... The emulator only presently implements mappers that had finished game roms published that are using those mappers, instead of just allowing a mix-and-match of features. The emulator  was forked from Mame, so this link to physical implementations makes sense in that context. I'm looking to lift this somewhat in some future release, and 32k+ram should be part of that. But it requires a big overhaul of the header parsing, and the way the emulator manages the bootstrapping of those hardware features in separate object classes.

 

In the meantime, using 128k+ram and not bankswitching for testing doesn't have any downsides IMO, except maybe wasting a handful of rom bytes for the bankswitch code.

[+Karl G]

In my experiments making a BASIC interpreter with 7800BASIC, I used romsize 32kRAM, and was able to access the extra RAM when running under a7800 with no issues.

 

@Dissy614 - exactly what issues are you seeing when running a 32k + RAM game under a7800?

[+Pat Brady]

1 hour ago, Karl G said:

In my experiments making a BASIC interpreter with 7800BASIC, I used romsize 32kRAM, and was able to access the extra RAM when running under a7800 with no issues.

This has been my experience too (except my project does not use BASIC).

[Dissy614]

2 hours ago, RevEng said:

Regarding 32k+ram being non-functional in a7800... The emulator only presently implements mappers that had finished game roms published that are using those mappers, instead of just allowing a mix-and-match of features. The emulator  was forked from Mame, so this link to physical implementations makes sense in that context. I'm looking to lift this somewhat in some future release, and 32k+ram should be part of that. But it requires a big overhaul of the header parsing, and the way the emulator manages the bootstrapping of those hardware features in separate object classes.

That makes sense. 

My 32k+ram hardware is just a breadboard setup on my bench, I'm not using a 'donor' cart or anything.

Also initially I missed seeing "128kRAM" as an option.  This is why I went to "128kBANKRAM" followed by the second romsize statement.

 

Thank you for the explanation!

 

3 hours ago, RevEng said:

In the meantime, using 128k+ram and not bankswitching for testing doesn't have any downsides IMO, except maybe wasting a handful of rom bytes for the bankswitch code.

Agreed.  

There is a Concerto cart heading cross-country towards me right now, so in a week even the lack of hardware issue will be moot :}

 

 

[Dissy614]

1 hour ago, Karl G said:

In my experiments making a BASIC interpreter with 7800BASIC, I used romsize 32kRAM, and was able to access the extra RAM when running under a7800 with no issues.

 

@Dissy614 - exactly what issues are you seeing when running a 32k + RAM game under a7800?

Hmm, odd.  For me "32kRAM" retained the FF values after writing to the $4000+ area.  

After changing to "128kRAM", prior to the memcpy the values at $4000+ were now zeros instead of FF, and after the memcpy it showed the proper values copied.

 

 

[+Karl G]

24 minutes ago, Dissy614 said:

Hmm, odd.  For me "32kRAM" retained the FF values after writing to the $4000+ area.  

After changing to "128kRAM", prior to the memcpy the values at $4000+ were now zeros instead of FF, and after the memcpy it showed the proper values copied.

 

 

I am now seeing the same behavior you are with the latest versions of 7800BASIC and a7800, but I know for certain that this was not previously the case, so presumably it must be a regression with one of those packages,

 

Here's trivial demo that saves a value to $4000, then reads it back to use for the background color. Should be dark red if it is stored and retrieved successfully, otherwise sandy-colored for $FF.

 

32kramtest.78b

32kramtest.78b.a78

[+Karl G]

Update: I went back to 7800BASIC version 0.19, and this test program compiled with this version DOES work correctly on a7800. I have not tested on any of the versions in-between to see at what point this stops working, however.

 

32kramtest.78b.a78

[Trebor]

15 minutes ago, Karl G said:

I am now seeing the same behavior you are with the latest versions of 7800BASIC and a7800, but I know for certain that this was not previously the case, so presumably it must be a regression with one of those packages,

 

Here's trivial demo that saves a value to $4000, then reads it back to use for the background color. Should be dark red if it is stored and retrieved successfully, otherwise sandy-colored for $FF.

 

32kramtest.78b 216 B · 0 downloads

32kramtest.78b.a78 128.13 kB · 0 downloads

 

2 minutes ago, Karl G said:

Update: I went back to 7800BASIC version 0.19, and this test program compiled with this version DOES work correctly on a7800. I have not tested on any of the versions in-between to see at what point this stops working, however.

 

32kramtest.78b.a78 128.13 kB · 0 downloads

Both are producing a red screen for me under A7800 v5.2.

[+Karl G]

5 minutes ago, Trebor said:

 

Both are producing a red screen for me under A7800 v5.2.

I went back to test, and if I run a7800 from the command line, everything works correctly. If I compile with Atari Dev Studio and have the emulator automatically launch then it does not work correctly, however. It also does not work correctly if I run the bundled version of a7800 from ADS from the command line. I have no idea what the difference could be because both the version I installed and the version that comes with ADS are version 5.2 as well.

[Trebor]

13 minutes ago, Karl G said:

I went back to test, and if I run a7800 from the command line, everything works correctly. If I compile with Atari Dev Studio and have the emulator automatically launch then it does not work correctly, however. It also does not work correctly if I run the bundled version of a7800 from ADS from the command line. I have no idea what the difference could be because both the version I installed and the version that comes with ADS are version 5.2 as well.

Is the latest Atari Dev Studio (v0.8.3) being utilized? 

The below was mentioned on January 4:

 

[+Karl G]

59 minutes ago, Trebor said:

Is the latest Atari Dev Studio (v0.8.3) being utilized? 

The below was mentioned on January 4:

 

Yes; I have the latest version. This particular computer has never had a previous version of ADS on it, either. Maybe the issue doesn't happen on Windows?

[Dissy614]

59 minutes ago, Karl G said:

Update: I went back to 7800BASIC version 0.19, and this test program compiled with this version DOES work correctly on a7800. I have not tested on any of the versions in-between to see at what point this stops working, however.

 

32kramtest.78b.a78 128.13 kB · 4 downloads

Thank you for the verification.

I noticed both of your .a78 files are 128kb in file size.  Both of these work for me in a7800.

When I compile your code in 0.22 I end up with a 32kb size file, and that does not work (sandy bg color)

 

Just for funsies, I changed "32kRAM" to "128kRAM" in your code and compiled it again under 0.22

This resulted in a 128kb sized file, and is a byte-for-byte match to your rom in your first post.

 

 

[+Karl G]

13 minutes ago, Dissy614 said:

Thank you for the verification.

I noticed both of your .a78 files are 128kb in file size.  Both of these work for me in a7800.

When I compile your code in 0.22 I end up with a 32kb size file, and that does not work (sandy bg color)

 

Just for funsies, I changed "32kRAM" to "128kRAM" in your code and compiled it again under 0.22

This resulted in a 128kb sized file, and is a byte-for-byte match to your rom in your first post.

 

 

Good catch. I was trying different combinations and attached the wrong thing. It looks like it doesn't work for me regardless of which version of 7800BASIC I use to compile, after all, so my best guess would be a a7800 regression.

 

32kramtest.78b.a78

[Trebor]

3 hours ago, Karl G said:

Good catch. I was trying different combinations and attached the wrong thing. It looks like it doesn't work for me regardless of which version of 7800BASIC I use to compile, after all, so my best guess would be a a7800 regression.

 

32kramtest.78b.a78 32.13 kB · 0 downloads

Receiving the sandy/yellow screen with the above file under A7800 v5.2. 

Noticed the header was changed to just 'ram@4000', as opposed to both 'SuperGame' and 'ram@4000' in the header with the previous files posted.

If the header is updated to also include 'SuperGame' along with 'ram@4000' to the above file, the red screen is experienced again.

[+Pat Brady]

55 minutes ago, Karl G said:

Good catch. I was trying different combinations and attached the wrong thing. It looks like it doesn't work for me regardless of which version of 7800BASIC I use to compile, after all, so my best guess would be a a7800 regression.

 

Huh. Mine (again, not using BASIC) still works in a7800 5.2.

 

7iX-2022-03-05.a78

[RevEng]

1 hour ago, Pat Brady said:

Huh. Mine (again, not using BASIC) still works in a7800 5.2.

The header has supergame flagged, so it's being interpreted as a shortened two-bank supergame. This works with a7800, and is a work-around for this particular issue, but I'd expect some devices might have problems with it.

[+Pat Brady]

2 hours ago, RevEng said:

The header has supergame flagged, so it's being interpreted as a shortened two-bank supergame. This works with a7800, and is a work-around for this particular issue, but I'd expect some devices might have problems with it.

My 7800header script specifies only "supergameram." I had not noticed until now that 7800header automatically sets the "supergame bank switched" flag even though of course a 32K cartridge does not use bank switching.

 

It does not work on Concerto. I have a bodged 128K version for that. I have not tried unsetting the bank switched flag.

[RevEng]

3 hours ago, Pat Brady said:

My 7800header script specifies only "supergameram." I had not noticed until now that 7800header automatically sets the "supergame bank switched" flag even though of course a 32K cartridge does not use bank switching.

Ah. The current version of 7800header doesn't do that, so you can avoid that with an update.

 

Historically that header bit was a ram modifier for the supergame format, hence the name, so 7800header would auto-add supergame if you chose supergameram. After some of the header thread discussions, we moved over to it being ram@4000 or EXRAM, instead of being a supergame modifier. At that point I updated the 7800header behaviour, and renamed the option to "ram@4000". (though the alias "supergameram" still works.)

 

[edit] come to think about it, the previous 7800header behaviour probably was the cause of Karl's 32k+ram test working too. He likely got the unintended 32k supergame hack.