Cartridge

[Panther]

I'm trying to get a program to work from a cartridge, something I've never done before.  I've managed to create something that runs fine in an emulator (Alitrra), but not on real hardware.  At $BFFA, I have the following:

00 0A 00 04 F0 BF

 

My program is configured to start at A000, and at BFF0 (the init address) I just have an rts instruction.  Apparently this isn't adequate somehow.  It tries to run, but crashes after outputing random parts of data from my program.

 

 

[Rybags]

The second byte should be A0, not 0A (assuming your run addres is $A000)

 

Altirra has settable behaviours for stuff like BRK, and illegal / lockup instructions which might explain why it works there.

[Panther]

1 hour ago, Rybags said:

The second byte should be A0, not 0A (assuming your run addres is $A000)

A typo on the forum post, yes, it's A0.  I'm running Altirra with illegal instructions enabled, BRK handling, and fast boot disabled.  If my method of handling the cartridge configuration bytes is sound, then the problem must be elsewhere in the code, but something that's only affecting when run from the A000 address range instead of 2000 as an exectuable.  It's probably not my relocated display list since I do get a display, just not with what I'm expecting.

 

[Rybags]

Maybe put some test code in e.g. VBlank that cycles the background colour or something.

Altirra accuracy is to the point that real hw is almost indistinguishable so the behaviour should be the same.

[Panther]

It turns out that display lists can't reside in ROM, except in Altirra.

[_The Doctor__]

@phaeron

1 minute ago, Panther said:

It turns out that display lists can't reside in ROM, except in Altirra.

?

[Panther]

Moving the display list to RAM instead of ROM fixed the issue on the real hardware.  I don't see any mention of this being an issue though.

 

[phaeron]

That's because it's not an issue, display lists work perfectly fine from ROM or any other address on the real hardware. The self-test menu uses this.

 

[Panther]

Or, I did something that corrupted the ROM area that by some odd chance corrupted just the display list.  Yes, I do have it working from ROM now.  Sorting the rest of the issues.  This is my first time ever dealing with a cartridge.

 

[Panther]

Messing with PORTB bit 1 definitely does different things in Altirra than real hardware.  Altirra doesn't have a problem with messing with this while running a program from cartridge, but not an actual Atari.  Maybe there's some option in Altirra that modifies this behavior that I didn't see.

 

[flashjazzcat]

What are you expecting to happen, and what are you observing happening?

[Panther]

56 minutes ago, flashjazzcat said:

What are you expecting to happen, and what are you observing happening?

I was attempting to enable Basic and check for the presence and version of it, but this is obviously not something to do when running from a cartridge that occupies the same memory space.  On real Atari hardware this is partially corrupting my program.  It still runs, but causes some garbage to display and crashes.  In Altirra, it runs just fine.

 

[flashjazzcat]

Is internal BASIC actually present in the emulated machine?

[phaeron]

In order to check the BASIC ROM from a cartridge, the cartridge must have support for disabling itself. The cartridge has priority over internal BASIC in the XL/XE MMU, so attempting to enable internal BASIC while the cartridge is enabled won't do anything.

 

A case where you will see different behavior is when soft-loading a cartridge into computer RAM, instead of running it from cartridge RAM/ROM. In that case, you will be able to enable internal BASIC as that has priority over main RAM. If you're using a system where you can load a cartridge onto the computer over SIO without a physical cartridge, then you're likely running under this case.

 

The other case where you can run into issues is with GINTLK. The Atari XL/XE OS will intentionally lock up the computer if it sees the cartridge enable state change from stage 2 VBI. Make sure that interrupts are disabled or GINTLK is updated first. In Altirra, you'll see the same behavior with the Atari OS. The built-in AltirraOS doesn't do this because it can't guarantee the same check timing as the Atari OS.

 

[Panther]

10 hours ago, phaeron said:

In order to check the BASIC ROM from a cartridge, the cartridge must have support for disabling itself. The cartridge has priority over internal BASIC in the XL/XE MMU, so attempting to enable internal BASIC while the cartridge is enabled won't do anything.

 

A case where you will see different behavior is when soft-loading a cartridge into computer RAM, instead of running it from cartridge RAM/ROM. In that case, you will be able to enable internal BASIC as that has priority over main RAM. If you're using a system where you can load a cartridge onto the computer over SIO without a physical cartridge, then you're likely running under this case.

 

The other case where you can run into issues is with GINTLK. The Atari XL/XE OS will intentionally lock up the computer if it sees the cartridge enable state change from stage 2 VBI. Make sure that interrupts are disabled or GINTLK is updated first. In Altirra, you'll see the same behavior with the Atari OS. The built-in AltirraOS doesn't do this because it can't guarantee the same check timing as the Atari OS.

 

I did get this working yesterday by having the cartridge copy everything into RAM and executing from there.  I didn't realize a cartridge could disable itself though, and I'lll look into how that can be done.  My code disables the interrupts when doing these checks though, so that wasn't a problem.  Thank you for the info.  I was surprised that everything ran perfectly in Altirra but I wasn't getting the same results on a physical machine.

[Panther]

I also found that part of my problem was the Chinese fake SST EEPROM I was using. 

I solved that by first loading my program into a ROM slot of U1MB for testing, then burned an old classic EPROM.  I need to find some decent EEPROMs or FLASH chips that I can use.

 

[Rybags]

What's wrong with the Eeprom - 2K instead of 8K or something?

[Panther]

4 minutes ago, Rybags said:

What's wrong with the Eeprom - 2K instead of 8K or something?

It was just plain unstable.  It also has a different ID than what it should, according to my programming software, and the label is rubbing off...

 

[stepho]

20 hours ago, Panther said:

It was just plain unstable.  It also has a different ID than what it should, according to my programming software, and the label is rubbing off...

 

That's typical of a 2K or 4K chip being sold as an 8K chip.

[Panther]

It did program and verify with 8KB of data, so it was at least similar to what it was supposed to be, but definitely not reliable.  When the paint starts coming off you know something is wrong.